openerp-brazil-team team mailing list archive

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

No meu entender, a estrutura Partner serve para organizar as informações
cliente (no caso de vendas, mas poderia ser a mesma coisa com fornecedor).
Suponho que isso caracterize uma única conta contábil para cada Partner.
Vamos imaginar que uma empresa tem só dois clientes, "Petrobras" (um Partner
com milhares de endereços), e outro Partner seria "Armarinhos José" (com um
único endereço), mas se cada res.partner for caracterizado como um CNPJ, a
mesma empresa teria milhares de clientes, o que tornaria a administração de
clientes mais complexa.  
 
Do ponto de vista de CRM:
- precisamos enxergar o cliente de forma unificada, pois se vou fazer uma
campanha, um acompanhamento de contatos, etc., preciso de uma estrutura do
cliente. 
Do ponto de vista de Apuração de resultado
- preciso somar o que faturamos e quanto custou atender um cliente, somando
todas a filiais (agrupando em uma conta contábil).
- para fornecedores, precisamos consolidar as entregas oriundas de vários
CNPJ em uma única conta contábil daquele fornecedor (isso já é praxe)
Do ponto de vista de Faturamento (NF/legal)
- Uma fábrica tem 2 portões, um matriz outro filial, mas é o mesmo cliente,
preciso consolidar em um só registro, não faz sentido considerar 2 clientes
 
Na prática, na minha empresa, quando faço uma compra, mesmo de pequenas
empresas, os fornecedores tem rejeitado a minha solicitação de faturar para
a sede mas entregar no meu escritório (o escritório não tem CNPJ). Em outras
empresas, vão mais além, já não me pedem o endereço, me pedem o CNPJ e o
sistema preenche os dados do endereço automaticamente, e não aceita
correções (inclusive é um "feature" que devemos incorporar no futuro no
OpenERP).
 
O problema fica mais complexo com a NF eletrônica e SPED Fiscal, porque a NF
passa a ser emitida pela Receita, com o endereço que eles tem no cadastro, e
não com o endereço do ERP. Nas empresas a que damos consultoria, que tem SAP
ou Oracle instalados, isso tem sido um grande problema porque o cadastro
está "sujo" com números de CNPJ errados, o que causou, em algumas empresas,
problemas a ponto de parar o despacho porque não conseguiam emitir a NFe.
 
Quanto a pessoa física, há empresas que tem utilizado o CPF como
identificador único do indivíduo, ou seja, o número do cliente no sistema é
o número do CPF e nào mais um número sequencial. Isso facilita os controles
de segurança da empresa, e deverá ser mais utilizado com a entrada futura da
assinatura eletrônica digital. Isso porque o CPF é o único cadastro que tem
um número de identificação único para cada cidadão em todo o território
nacional
 
Pedro 

 
  _____  

De: Joe Pimentel [mailto:joe.b.pimentel@xxxxxxxxx] 
Enviada em: terça-feira, 19 de maio de 2009 00:02
Para: pedro.bicudo@xxxxxxxxxxxxxxxxx
Cc: Celso Canaan; OpenErp Brasil
Assunto: Re: [Openerp-brazil-team] 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#b
in/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
<mailto: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