openerp-brazil-team team mailing list archive

[RONALDO PADULA <ronaldopadula@xxxxxxxxx>]

Ok Joe, é que eu estou analisando alguns módulos básicos para algumas dicas
futuras, e minha dúvida na impementaçao é justamente o mapeamento de
atributos. Acredito que sia interssante após a feitio da localização
brasileira, ao trabalhar os módulos mapear as necessidades e estudar se o
módulo antende integralmente ou em partes. E perguntei apenas pra ter
certeza se realmente havia sido interrompida a reflexão sobre esta questão
de dados cadastrais ou se eu que estava dormindo no ponto. de qualquer forma
eu estou estudando o OpenERP em ingles pra entender mais sobres o que tremos
disponivel lá fora pra ajudar na reflexão e adaptação do mesmo aqui dentro.
Valeu pela sua colocação

2009/9/8 Joe Pimentel <joe.b.pimentel@xxxxxxxxx>

>
> Ronaldo,
>
> Quem estava implementando o código referente as discussões era o Luiz
> França.
> Não sei exatamente qual foi a situação final que ele implementou e parece
> que o código não está no trunk do repositório de forma que já fica meio
> complicado analisar.
> Acho que devemos partir do wiki (que realmente não tinha concluído
> totalmente o assunto) e da thead tropicalização e concluir na implementação
> que está sendo efetuada agora.
>
> Quanto aos questionamentos, são muitos numa única thread. Sugiro que você
> quebre em um questionamento por thread fica mais fácil para todos os que
> conhecem mais de cada assunto responderem e para futuras pesquisas na lista.
>
> Por exemplo, que tipo de metodologia você está se referindo para o cadastro
> de parceiros? Se for referente a implementação de atributos na classe de
> parceiros creio que a forma mais desejável de fazê-lo é: uma vez
> identificando que a classe já existente, (neste caso do projeto original
> openerp/server/bin/addons/base/res/partner/partner.py - classe res_partner)
> não fornece todos os atributos desejados, efetuar uma herança desta classe
> no módulo que estamos desenvolvendo e adicionar os atributos e lógica
> compatíveis com o funcionamento desejado.
>
> Atenção: O mapeamento de atributos da classe e a herança de objetos do
> OpenERP não se faz diretamente pelos elementos da linguagem python mas
> através da implementação da camada de persistência (ORM). Veja os atributos
> _inherit para herança e _columns para os atributos. Já para os
> relacionamentos você pode observar nos atributos da classe a existência das
> expressões fields.many2one, fields.one2many, fields.many2many.
>
> Os itens que vão compor o cadastro de parceiros você pode verificar pelos
> atributos da classe citada acima mais os atributos incluídos na classe que
> herda daquela no nosso projeto (openerp.pt-br-localiz/l10n_br/partner.py).
>
> -- Este é o entendimento que tenho por enquanto e aqui me desculpem se
> errei em algo pois não implementei nenhum módulo ainda.
>
> --
> Joe Bertoli Pimentel
> joe.b.pimentel@xxxxxxxxx
>
>
> 2009/9/8 Ronaldo Padula <ronaldopadula@xxxxxxxxx>
>
> Caro Joe, eu verifiquei toda a discussão a respeito da tropicalização
>> relacionadas ao cadastro de parceiros. Entedi bem o que foi exposto, mas
>> ainda acho que técnicamente fica incompleta, ou de fato a discussão não
>> esgotou o assunto. Resumindo... qual a metodologia está sendo apllicada para
>> este cadastro de parceiros? Há uma relação de dados completas sobre a forma
>> com que se dará esta transformação do cadastro? Eu entendi bem o que foi
>> discutido em relação ao CNPJ e CPF, mas há mais coisas em um cadastro como
>> esse que deve ser Verificado! Digo isso porque estou matutando aqui a forma
>> que se tem para cadastrar no OpeERP comparadas há alguns manuais de gestão
>> que tratam do assunto. Voc~e poderia nos dar uma pincelada básica de quais
>> ítens irão compor este formulário de cadastro?
>>
>> Obrigado!
>>
>>
>>
>> Joe Pimentel escreveu:
>>
>>> Gabriel, o que levou a proposta 3.1 foi  a thread de discussão
>>> "Tropicalização".
>>> Tivemos várias contribuições do pessoal, das quais eu destaco duas (Pedro
>>> Bicudo Maschio) que foram particularmente esclarecedoras:
>>>
>>> https://lists.launchpad.net/openerp-brazil-team/msg00176.html
>>> e
>>> https://lists.launchpad.net/openerp-brazil-team/msg00184.html
>>>
>>> Eu procurei no wiki resumir o que conversamos sob cada aspecto  mas
>>> talvez se você der uma olhada na thread completa, posso ter falhado em
>>> perceber alguma observação pertinente.
>>>
>>>
>>> --
>>> Joe Bertoli Pimentel
>>> joe.b.pimentel@xxxxxxxxx <mailto:joe.b.pimentel@xxxxxxxxx>
>>>
>>> 2009/9/7 Gabriel C. Stabel <gstabel@xxxxxxxxx <mailto:gstabel@xxxxxxxxx>>
>>>
>>>
>>>
>>>    Joe,
>>>    ...
>>>
>>>
>>>    2. Razão Social:
>>>    /"Nome do Parceiro (Nome para Pessoa Física, Razão Social para
>>>    Pessoa Jurídica)
>>>    Atributo já existente (a principio pensou-se em criar um novo
>>>    atributo para Razão Social mas ao longo das conversas concluiu-se
>>>    que nao seria necessário, podendo-se utilizar o atributo name da
>>>    classe res.partner para isso)."/
>>>
>>>    Essa é uma questão complicada. Vejo 3 opções:
>>>    3.1. Usar o name do res.partner.
>>>    3.2. Usar o name do res.partner.address cujo type é invoice. Pois
>>>    esse é o contato "principal" no que diz respeito a fatura (é o
>>>    default da invoive).
>>>    3.3. Criar um campo razao_social em res.partner.
>>>
>>>    Não acho legal o 3.1 (a idéia de vocês) porque muitas vezes a
>>>    razão social não tem nada a ver com o nome que as pessoas se
>>>    referem ao parceiro. Logo forçar as pessoas a associarem a razão
>>>    social ao nome do parceiro não é uma boa.
>>>
>>>    O 3.2 parece interessante, pois além de definir a razão social
>>>    fica associado ao endereço oficial da empresa (que é outra questão).
>>>    Mas me dá a impressão que ficará muito "solto", já que não podemos
>>>    mudar o label para "Razão Social" pois só será razão social nesse
>>>    caso, nos outros casos continuará sendo "Nome".
>>>    Contra esse tb pesa o problema de que o contact da fatura
>>>    precisará ser o mesmo da razão social. Se mudar o endereço de
>>>    fatura, o cara vai ter que mudar a razão de lugar.
>>>
>>>    Sempre tentamos usar o que está pronto, o que pesa contra o 3.3.
>>>
>>>
>>>    .
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>
>
> --
> Joe Bertoli Pimentel
> joe.b.pimentel@xxxxxxxxx
>
>
>
> --
> Joe Bertoli Pimentel
> joe.b.pimentel@xxxxxxxxx
>
> _______________________________________________
> 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
>
>