openerp-brazil-team team mailing list archive
-
openerp-brazil-team team
-
Mailing list archive
-
Message #00177
Re: RES: Tropicalização
Obrigado, Pedro.
Agora, entendi os diagramas...
Sobre o problema do mesmo CNPJ: as secretarias (regionais) não possui o
mesmo número de sua Prefeitura?
Celso.
-------- Mensagem original --------
De: Pedro L B Maschio <pedro.bicudo@xxxxxxxxxxxxxxxxx>
Para: 'Celso Canaan' <celso.canaan@xxxxxxxxxxxx>, 'OpenErp Brasil'
<openerp-brazil-team@xxxxxxxxxxxxxxxxxxx>
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
References