openerp-brazil-team team mailing list archive

[Joe Pimentel <joe.b.pimentel@xxxxxxxxx>]

Não consegui... regras de segurança da empresa ... :(


-- 
Joe Bertoli Pimentel
joe.b.pimentel@xxxxxxxxx

2009/5/18 Raphaël Valyi <rvalyi@xxxxxxxxx>

> Pessoal,
>
> reuniao com o a communidade OpenERP agor no irc
> #openobject no servidor freenode.
> Se for atras de um firewall, use http://www.mibbit.com como cliente IRC.
>
> Raphaël Valyi.
>
>
> 2009/5/18 Luiz Franca <luiz@xxxxxxxxxxxxxxxxxxxxx>
>
>> Joe,
>>
>> com relação as classes pessoa fisica e pessoa juridica eu explico.
>> Considerando que o cpf/cnpj está na classe res.partner.address, um
>> "endereço" não pode ser ao mesmo tempo física e jurídica, por este motivo
>> criei outras classes para evitar que sempre ficassem campos que nunca seriam
>> usados em determinado partner. Pensei tambem em não criar outra classe,
>> aproveitando os campos que são semelhantes data fundação/aniversario,
>> identidade/inscr.estadual, etc, porem, achei inicialmente que não seria
>> muito conveniente.
>>
>> A sua ideia tambem me resolve um problema que existe, (talvez pela minha
>> ignorância). Como não existe mais a relação one2one no OpenERP, tive que
>> criar estas classes utilizando a relação one2many, o que naturalmente me
>> permite ter mais de um objeto "pessoa física"/"pessoa juridica" para um
>> mesmo objeto res.partner.address. Se não juntarmos  as classes
>> fisica/juridica à classe address, teremos que resolver este problema da
>> relação one2many.
>>
>> De qualquer maneira, podemos tambem ouvir a opinião de mais pessoas para
>> podermos construir um projeto robusto que atenda as necessidades de todos.
>>
>>
>> --
>> Luiz Fernando Maciel França
>> Sig Informática Ltda.
>> Rua João Pereira Amorim, 700
>> Bairro Jardim Arizona
>> 35.700-373 - Sete Lagoas - MG - Brasil
>> (31)3773-1043
>> Skype: lfmfsig
>>
>>
>> 2009/5/17 Joe Pimentel <joe.b.pimentel@xxxxxxxxx>
>>
>>> Bom dia,
>>>
>>>
>>> [...]
>>>
>>>
>>> Considerações em relação ao módulo base_brasil:
>>>
>>> Não sei se pelo exposto acima, o motivo da separação do partner em duas
>>> classes diferentes (física e jurídica) não deixaria de existir. Não sei se
>>> já existe uma forma de habilitar / desabilitar campos na view de acordo com
>>> o conteúdo de outros campos mas se existir, os campos diferentes existentes
>>> em relação a uma ou outra modalidade (PJ/PF) seriam habilitados ou
>>> desabilitados dependendo do conteúdo do campo tipo_pessoa (conforme código
>>> apresentado pelo Luiz França):
>>>          'tipo_pessoa': fields.selection([('F', 'Física'), ('J',
>>> 'Jurídica')], 'Tipo de pessoa', required=True),
>>>
>>> Apenas acredito que teríamos que colocar todos esses atributos na classe
>>> que herda diretamente do res_partner.
>>>
>>> Um abraço a todos,
>>>
>>> --
>>> Joe Bertoli Pimentel
>>> <joe.b.pimentel@xxxxxxxxx>
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-brazil-team<https://launchpad.net/%7Eopenerp-brazil-team>
>> Post to     : openerp-brazil-team@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-brazil-team<https://launchpad.net/%7Eopenerp-brazil-team>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-brazil-team<https://launchpad.net/%7Eopenerp-brazil-team>
> Post to     : openerp-brazil-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-brazil-team<https://launchpad.net/%7Eopenerp-brazil-team>
> More help   : https://help.launchpad.net/ListHelp
>
>