openerp-brazil-team team mailing list archive

["Pedro L B Maschio" <pedro.bicudo@xxxxxxxxxxxxxxxxx>]

Celso
O diagrama relaciona vários possíveis endereços para uma mesma entidade
Partner
http://doc.openerp.com/book/2/2_4_Leads/2_4_Contacts.html?highlight=class%20
diagram.
Isso ocorre com frequência quando temos uma empresa e vários endereços de
contato, por exemplo, o comprador que fica em Santos e outro que fica no Rio
de Janeiro. Acredito que esta relação seja importante para CRM, podendo-se
relacionar vários clientes (pessoas) em uma mesma empresa (Partner). Logo
abaixo, a próxima relação é Função (comprador, recebedor, diretor, etc.).

É bem diferente da discussão de CNPJ:
Na lei Brasileira, existe apenas um CNPJ por endereço, portanto, esta
relação deve ser única. Não é única em relação à razão social, é única em
relação ao endereço. No primeiro exemplo desta corrente de e-mail (o
primeiro que recebi, quando entrei para o grupo), estaria em desacordo com a
legislação, porque sugere que posso faturar para um e entregar para outro
(se eu entendi corretamente a proposta inicial).

Exemplo: posso ter um Partner, com endereço físico A e filial no endereço
físico B. Cada endereço tem um CNPJ distinto. Quando envio uma mercadoria e
fatura, devo emitir para aquele CNPJ que recebe o produto/serviço, não posso
emitir a fatura para o CNPJ do endereço A e enviar a mercadoria para o
endereço B.

Em um ERP, para ter a devida consistência, deve-se emitir um pedido para
endereço A, com CNPJ e razão social de A, e outro pedido para endereço B,
com CNPJ e Razão social de B.

Para consistência com OpenERP, sugiro que o Partner seja uma entidade
cliente, pode ser: empresa, grupo econômico, pessoa física, etc., é o nome
para o qual vendas e posteriormente o CRM reconhecem um cliente. Abaixo do
partner pode-se associar vários endereços (adresses). Cada endereço seria
composto de seu endereço físico, seu CNPJ ou CPF e sua razão social/nome.

Assim se "liquida" o problema de homônimos, pois duas pessoas podem ter o
mesmo nome, mas não o mesmo endereço ou o mesmo CPF. 

Como este é meu primeiro comentário e "peguei o bonde andando" espero ter
sido adequado

Pedro

-----Mensagem original-----
De:
openerp-brazil-team-bounces+pedro.bicudo=tgtconsult.com.br@lists.launchpad.n
et
[mailto:openerp-brazil-team-bounces+pedro.bicudo=tgtconsult.com.br@xxxxxxxxx
nchpad.net] Em nome de Celso Canaan
Enviada em: segunda-feira, 18 de maio de 2009 12:06
Para: OpenErp Brasil
Assunto: Re: [Openerp-brazil-team] Tropicalização

Obrigado, Joe.

Verifiquei no launchpad e não também não entendi.
Vi um diagrama  em
http://doc.openerp.com/book/2/2_4_Leads/2_4_Contacts.html?highlight=class%20
diagram), mas está um pouco confusa.

Celso.

-------- Mensagem original --------
De: Joe Pimentel <joe.b.pimentel@xxxxxxxxx>
Para: Celso Canaan <celso.canaan@xxxxxxxxxxxx>
Cc: OpenErp Brasil <openerp-brazil-team@xxxxxxxxxxxxxxxxxxx>

Olá Celso,

Diagrama de classes: Eu também estou com essa dúvida.


Acho que o ideal seria importarmos o OpenERP no programa Dia, mas pelo que
pude observar até agora,  não existe a funcionalidade de engenharia reversa
para o código do OpenERP. O que existe no Dia é, a partir de um diagrama
desenhado, conseguir gerar o código do módulo. 
Existe uma resposta no launchpad pra essa pergunta mas acho que não entendi
direito a resposta ou ela realmente não foi respondida de acordo
(https://answers.launchpad.net/openobject-server/+question/66205).

Tentei várias outras ferramentas UML mas apesar de conseguir importar o
código python, não obtive sucesso em exibir corretamente as relações entre
classes e seus atributos em nenhuma porque as relações de herança e
referência assim como as colunas não são código python mas sim atributos
mascarados como "_inherit = 'res.partner.address' " ou "_columns = {
'column':  fields.char('Número', size=10) }". 

Ou seja, acho que qualquer ferramenta UML terá que ter um plugin específico
para o OpenERP (ou para a camada de persistência que ele utiliza). 

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


2009/5/18 Celso Canaan <celso.canaan@xxxxxxxxxxxx>
        Bom dia...
        
        Nós não encontramos outra solução a não ser quebrar a restrição
        do nome.
        Como homônimo não é tão frequente, tratamos como exceção.
        Criamos e controlamos a entidade pessoa com um id e configuramos
        nosso
        Erp para  minimizar erros com redundâncias, emitindo avisos de
        confirmação e em alguns casos bloqueando.
        
        Uma dúvida: como vejo um diagrama de classes no OpenErp?
        
        Celso.
        
        -------- Mensagem original --------
        De: Luiz Franca <luiz@xxxxxxxxxxxxxxxxxxxxx>
        Para: Joe Pimentel <joe.b.pimentel@xxxxxxxxx>
        Cc: OpenErp Brasil <openerp-brazil-team@xxxxxxxxxxxxxxxxxxx>,
        marcelo.ferrari <marcelo.ferrari@xxxxxxxxxxxx>
        
        
        
        
        2009/5/17 Joe Pimentel <joe.b.pimentel@xxxxxxxxx>
               [...]
        
        
               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?)
        
        
               --
               Joe Bertoli Pimentel
        
        Concordo com voce Joe, acho que o nome do Partner deve ser a
        razão
        social.
        Para empresas/Filiais, existiria um partner e tantos address
        quanto
        fossem as lojas(filiais/matriz).
        Acredito que para as prefeituras /autarquias, seria a mesma
        coisa.
        Porem temos um problema quanto a pessoa física. Homônimos. como
        resolver?
        Não estou vendo outra alternativa a não ser quebrar a restrição
        Unique.
        Alguem tem alguma outra sugestão?
        
        []s
        --
        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
        Post to     : openerp-brazil-team@xxxxxxxxxxxxxxxxxxx
        Unsubscribe : https://launchpad.net/~openerp-brazil-team
        More help   : https://help.launchpad.net/ListHelp
        
        




_______________________________________________
Mailing list: https://launchpad.net/~openerp-brazil-team
Post to     : openerp-brazil-team@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-brazil-team
More help   : https://help.launchpad.net/ListHelp