← Back to team overview

openerp-brazil-team team mailing list archive

Re: RES: Tropicalização

 

Boa noite, Pedro.
Se desejar, você pode ter acesso a todas os mensagens deste assunto no
endereço https://lists.launchpad.net/openerp-brazil-team/msg00145.html.<https://lists.launchpad.net/openerp-brazil-team/msg00145.html>
 Todos
os assuntos: https://lists.launchpad.net/openerp-brazil-team/threads.html.<https://lists.launchpad.net/openerp-brazil-team/threads.html>

Acho que entendi a sua colocação a respeito do CNPJ e endereço mas então
para que serviria a estrutura da empresa? Seria para relacionar empresas
diferentes de um mesmo grupo?
Entendo também que você exprimiu o que está na legislação mas e na prática?
Não ocorre da matriz comprar produtos e pedir para entregar em outro
endereço?

Quanto ao problema de homônimos estudando o as versões All-in-One (Windows)
e o HEAD do repositório e tive uma surpresa.
O atributo name de res_partner parece não ser mais uma restrição do tipo
unique (vide:
http://bazaar.launchpad.net/~openerp/openobject-server/trunk/revision/1742#bin/addons/base/res/partner/partner.py).<http://bazaar.launchpad.net/~openerp/openobject-server/trunk/revision/1742#bin/addons/base/res/partner/partner.py>


Lembrete: parceiro (pode ser cliente ou fornecedor  - me esqueci numa
postagem anterior...).


-- 
Joe Bertoli Pimentel
joe.b.pimentel@xxxxxxxxx
2009/5/18 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<openerp-brazil-team-bounces%2Bpedro.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
>
>
> _______________________________________________
> 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
>

Follow ups

References