openerp-brazil-team team mailing list archive

["Gabriel C. Stabel" <gstabel@xxxxxxxxx>]

P.s.: vou acabar essa discussão e vou me ausentar do grupo por um tempo.
Tenho questões pessoais para lidar, e não vou poder mais participar até o
final do ano.
Já retirei os assign em meu nome dos blueprints.

Abs,
Gabriel

2009/9/10 Gabriel C. Stabel <gstabel@xxxxxxxxx>

> Joe,
> li a discussão de vocês. Realmente o ideal seria o 3.1 (colocar a razão
> social no res.partner.name). Entretanto na prática isso seria um problema,
> como expliquei antes. Uma restrição indesejável. É muito comum o nome
> fantasia de uma empresa ser completamente diferente da razão social, e é o
> nome fantasia é que as pessoas lembram e se refem ao tratar de um
> parceiro/cliente.
>
> Até no caso de PF isso acontece, apesar de ser mais raro. A pessoa ser
> chamado de um "nome fantasia" (apelido, abreviação, etc) e legalmente o nome
> completo ser outro.
>
>
> Renato,
> gostei da sugestão de chamar de res.partner.legalname (no caso a opção
> 3.3). Como deverá servir para PF e PJ (no meio trunk estava errado, só PJ),
> é mais abrangente que res.partner.razão_social.
>
>
> Quando a criar um account.invoice.address_shipping_id, a idéia então seria
> essa:
>
> account.invoice.address_contact_id: endereço LEGAL da empresa para
> preencher o cabeçalho da NF.
> account.invoice.address_invoice_id: endereço de COBRANÇA que é o endereço
> que são enviados os boletos bancários.
> account.invoice.address_shipping_id: endereço de envio da MERCADORIA e da
> NOTA FISCAL?
>
> Quanto aos defaults desses campos:
> account.invoice.address_contact_id: contato onde  res.partner.address.type
> == 'default'
> account.invoice.address_invoice_id: contato onde  res.partner.address.type
> == 'invoice'
> account.invoice.address_shipping_id: contato onde  res.partner.address.type
> == 'shipping'
>
> era isso que tu tinha em mente?
> Gabriel
>
>
> 2009/9/10 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
>>>>
>>>>
>>>
>>
>