openerp-brazil-team team mailing list archive

[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