openerp-brazil-team team mailing list archive

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

Bom dia,

Gostaria de parabenizar a todos pelo nível das contribuições para este
assunto que, sem dúvida, é uma das decisões fundamentais da tropicalização.

Pelo que entendi até agora (em relação ao OpenERP como está hoje e não ao
módulo base_brasil):

Nome do Parceiro - atributo já existente.
Será necessário quebrar a restrição do atributo name  (Nome) da classe
res_partner?
A princípio, pelas observações subseqüentes da lista, não é necessário.
Segundo o meu entendimento o atributo name  da classe res_partner seria
então utilizado pelo usuário apenas para identificar o cliente.
Unicidade? Sim, respeitando a restrição existente no módulo base. Assim
nossas customizações pode ser efetuadas por herança desta classe.
Mandatório? Sim. pelo mesmo motivo acima.


Razão Social - Não existe este atributo.
É necessário? No meu entendimento não (me corrijam se eu estiver errado).
Este seria o mesmo atributo do Nome do Parceiro. Para resolver os problemas
referentes a filiais / departamentos com Nome de Parceiro diferentes
utilizariamos a estrutura da empresa (eu preferiria chamar de estrutura do
parceiro pois pode ser aplicado também para PF).
Quando desejarmos a Razão Social do Parceiro utilizariamos o campo Nome do
próprio parceiro (departamento, filial, dependente - no caso de PF) e quando
desejarmos a Razão Social do Parceiro Principal (Matriz ou responsável)
utilizaríamos o campo Nome do Parceiro Principal (segundo a estrutura do
parceiro).
Unicidade? Já que manteríamos o name da classe res_partner, teríamos que
manter esta restrição. (Pessoal: aqui podemos ter algum problema?)


CNPJ/CPF - Não existe ainda este atributo (a não ser que utilizemos o código
do cliente para isso).
É necessário? Sim.
Poderíamos utilizar o código do cliente para isso? Acredito que não. Muitas
empresas já podem ter uma codificação para os clientes e processos
dependentes desta codificação.
Onde vamos criá-lo? Eu acredito que o CNPJ/CPF tem um mesmo comportamento em
termos de dependência da Razão Social e deveria andar junto com ela (pelo
que já foi exposto aqui na lista em relação a orgãos públicos e filiais).
Deve ser mandatório? Não. Como já foi
Unicidade? Não estou bem certo. Eu manteria (baseado no esquema de
hierarquia) mas pode ser quebrado caso exista uma justificativa.
Mandatório? Não.


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.

Acho que é isso e espero não ter falado muita besteira  mas ... se falei,
por favor me indiquem.

Um abraço a todos,

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


2009/5/15 Luiz Franca <luiz@xxxxxxxxxxxxxxxxxxxxx>

> Boa tarde Marcelo,
>
> 2009/5/15 marcelo.ferrari <marcelo.ferrari@xxxxxxxxxxxx>
>
>>  Boa tarde a todos!
>>
>> Gostaria de compartilhar com vocês algumas questões que acredito que devem
>> ser levadas em conta nessa questão do CPF/CNPJ  e endereço.
>>
>> Bem, no caso de o CNPJ passar a ser uma restrição única, o que ocorreria
>> no caso de empresas (clientes / fornecedores / etc) estrangeiras, ou fora do
>> Brasil, pois eles não possuem esse tipo de chave. Ai vem o problema: se é
>> restrição unica, poderá haver mais de uma com o cnpj nulo ou branco, isto é,
>> este campo poderia ficar vazio?.
>>
>>
> Pode existir uma restrição que permita vários partners sem CNPJ, mas se
> houver um CNPJ, tem que ser único.
>
>>  Com relação a utilizar um único campo para CNPJ e CPF, aqui na empresa
>> onde trabalho, nosso ERP possui um campo unico para essa informação,
>> entretanto os dados fica armazenados da seguinte forma:
>> CNPJ: 012.345.678/0001-99
>> CPF: 123.456.789/0000-99
>> (no caso de pessoa fisica o intervalo que define a filial fica como 0000.
>> Outra situação, o CNPJ deverá sempre iniciar com 0 (zero).)
>>
>> e para empresas estrangeiras usa-se 000.000.000/0000-00, pois não possuem
>> CNPJ, ficando a identificação a cargo do código sequencial. Neste caso,
>> existe um identificador que indica que a empresa é estrangeira e então a
>> restrição da chave não é aplicada pelo programa.
>>
>> Outra questão que dever ser levado em conta é que na emissão da Nota
>> Fiscal, quando o endereço de entrega for diferente do endereço do cliente
>> que fez a compra, deve constar também o CNPJ do endereço de entrega. Isso
>> quer dizer que toda empresa tem que ter um endereço PRINCIPAL e pode ter
>> MUITOS endereços de entrega, cobrança, comercial, etc. So para ilustrar
>> segue um exemplo:
>>
>> Digamos que uma empresa distribuidora de cimentos faça a venda para uma
>> Construtora. Esta é o Cliente para quem a NF é emitida, entretanto a
>> construtora manda entregar a mercadoria no endereço da OBRA. Assim, os
>> endereços da obras devem ser configurados como "endereço de entrega", mas o
>> endereço fiscal fica valendo o "principal".
>> O mesmo vale para as secretarias dos órgãos governamentais: O Cliente é o
>> órgão principal, tal como uma Prefeitura, e as secretarias são possíveis
>> endereços de entrega.
>>
>> Em nosso sistema de CRM que desenvolvemos aqui temos um campo para colocar
>> a descrição que pode ser dada aquele endereço de entrega, assim, o Parceiro
>> (cliente / fornecedor / etc) tem apenas um cadastro e os endereços a ele
>> ligados, quanstos forem necessários com suas respectivas descrições.
>>
>>
> É exatamente esta a ideia que o OpenERP utiliza, por isto tem duas classes
> 'res.partner' e 'res.parner.address'. Neste caso então o CNPJ fica melhor no
> 'Partner.Address' uma vez que cada endereço pode tem um cnpj diferente.
>
>>
>> --
> 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
>
> _______________________________________________
> 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
>
>