openerp-brazil-team team mailing list archive

[Renato Lima <renatonlima@xxxxxxxxx>]

Pessoal,


Não se deve ter nenhuma restrição unique em Razão Social igual, pois existe
pessoas juridicas com a mesma Razão Social um dos casos que acontecem isso e
o caso de empresas que tem a Matriz e suas filiais. Sobre esses dados de
numero na junta comercial, cna e etc... devem estar em res.company e nao em
res.partner...




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

> É uma pena Gabriel a sua ausencia no projeto, mas eu entendo, pois ate o
> final do ano passado eu estava na mesma situação que você esta passando
> agora. te desejo sucesso em suas atividades e que você nao fique tão longe
> de nos ! rsrsrsrsrs
>
>
> Saudações,
>
>
> Renato Lima
>
>
> 2009/9/10 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>