openerp-brazil-team team mailing list archive

[Renato Lima <renatonlima@xxxxxxxxx>]

eu errei o nome do campo partner_delivery_id na verdade é
partner_shipping_id

2009/9/10 Renato Lima <renatonlima@xxxxxxxxx>

> Gabriel,
>
>
> Minha sugestão:
>
> Opção 3.3 - É interesante ter os campos
> res.partner.name - Nome Fantasia
> res.partner.legalname - Razão Social
>
> O sistema e todos os outros modulo funcionaria corretamente com o campo
> name (Nome Fantasia), inclusive o invoice, somente a impressão da nota em
> formulario (papel) ou o geração do aqui de exportação para NFe utilizaria o
> campo legalname (Razão Social)
>
>
> Sobre a Nota Fiscal(Invoice) os campos
>
>
> partner_id e o parceiro ( apartir dai quando imprimir a NF seria so pegar o
> legalname no cadastro)
>
> address_contact_id e o endereço do cadastro padrão do partner que preenche
> o cabeçalho da NF
>
> address_invoice_id é o endereço de cobrança que é o endereço que são
> enviados os boletos bancários
>
>
> Outro campo que deveria haver também seria o address_delivery_id que existe
> na ordem de venda e que também deveria exister na NF(invoice) porque se o
> endereço de entrega for diferente do enderço do cabeçalho
> (address_contact_id) da nota fiscal nas informações complementares deve
> haver registrado o local de entrega. estou trabalhando nisso logo faço o
> commit para apreciação e testes da galera !
>
>
> Renato Lima
>
>
> 2009/9/7 Gabriel C. Stabel <gstabel@xxxxxxxxx>
>
>> Joe,
>> 1. CNPJ_CPF:
>> O Renato implementou exatamente como vcs haviam definido, e eu fiz a
>> mascara a a validação em cima. Acho que isso está ok então.
>>
>> 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.
>>
>> Que acham? Alguem vê algo que deixei passar?
>>
>> Abs,
>> Gabriel
>>
>> 2009/9/7 Joe Pimentel <joe.b.pimentel@xxxxxxxxx>
>>
>>  Gabriel,
>>>
>>> Estas definições que fizemos anteriormente fazem algum sentido, no seu
>>> ponto de vista?
>>>
>>> http://openerpbrasil.bluwiki.com/go/Openerpbrasil/CNPJ_CPF
>>>
>>> e
>>>
>>> http://openerpbrasil.bluwiki.com/go/Openerpbrasil/Nome_Razao_Social
>>>
>>> --
>>> Joe Bertoli Pimentel
>>> joe.b.pimentel@xxxxxxxxx
>>>
>>> 2009/9/7 Gabriel C. Stabel <gstabel@xxxxxxxxx>
>>>
>>>> Sobre o seguinte Blueprint: “Demais dados "fiscais" brasileiros (de PF e
>>>> PJ)".
>>>>
>>>> https://blueprints.launchpad.net/openerp.pt-br-localiz/+spec/partner-dados-fiscais
>>>>
>>>> Pessoal,
>>>> precisamos definir onde e como serão dispostos os demais dados referente
>>>> a questão "fiscal" brasileira. Dados como Razão Social, Inscrão Estadual,
>>>> Municipal, etc, de pessoa juridica; e identidade, data de expedição, etc, de
>>>> pessoa física.
>>>>
>>>> Dados "fiscais" realmente não é a palavra correta... pois os dados não
>>>> são só sobre isso. Mas na prática esses dados são armazenados em um ERP, e
>>>> usados, especialmente para compra-e-venda, notas-fiscais, contratos, e
>>>> demais documentos do gênero.
>>>>  ...
>>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>