openerp-brazil-team team mailing list archive

[Cilene Oliveira <cos2410@xxxxxxxxx>]

Ok Grabriel,

nos ja agradecemos muito pela ajuda ate qui, nos ainda vamos analisar melhor
suas ultimas colocaçoes e contribuiçoes. Espero que daqui para o fim do ano
a gente ja consegue deixar o OpenERP bem usavel no Brasil.

Raphaël Valyi
http://www.akretion.com


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
>
>