l10n-brazil
l10n-brazil copied to clipboard
OCA
[14.0][l10n_br_fiscal][l10n_br_account] fix commercial partner
fix para https://github.com/OCA/l10n-brazil/issues/2071
Caso do documento fiscal para consistencia é esperado que o partner_id do documento fiscal seja o destinatario real e nao um contato do destinatario (ou emitente real e nao contato do emitente) como permite um pedido de venda ou invoice do Odoo por examplo. Se espera que na tabela do documento fiscal, vc ve a mesma coisa do que numa NFe e que seja consistente com o SPED por examplo, sem ter que fazer gambiarras SQL para saber se o partner_id é um contato ou o "parceiro commercial" mesmo. Por isso acrescentei a restrição na visao do documento fiscal "puro".
Caso da NFe A NFe se basea no documento fiscal e com esse commit vai então usar o parceiro commercial tambem.
Uso em mixins, por examplo Vendas, Compras...
Esses mixins herdam de l10n_br_fiscal.document.mixine l10n_br_fiscal.document.mixin.methods. Nisso eles nao criam documentos fiscais. Isso so acontece depois quando um invoice é criado. Nisso não é grave se o partner_id dos pedidos de venda ou de compram apontam pro contato do parceiro e nao o parceiro commercial. A unica coisa que importa é que os mixins se baseam no commercial_partner_id na logica deles, por examplo para saber se uma venda é do mesmo estado ou não. Por isso eu acrescentei o commercial_partner_id nos mixins.
Caso dos Invoices
O caso do invoice é semelhante ao uso em Vendas ou Compras onde o Odoo permite que partner_id seja um contato.
Mas os invoice tb herda do mixin l10n_br_fiscal.document.invoice.mixin. Esse mixin é usado pelo l10n_br.fiscal_document tambem e permite que vc enxerga um documento fiscal atraves das views dos account.move/invoice pelo sistema do _inherits. Por isso eu acrescentei o commercial_partner_id nesse mixin tb apesar que quando esse mixin é usado dentro do documento fiscal o partner_id ja sera o proprio commercial_partner_id,
Agora quando o documento fiscal é criado ou escrito atraves do create ou write do Invoice/Invoice line, em vez de passar o mesmo partner_id do que no invoice, a gente cuida agora de passar o commercial_partner_id nor documento fiscal. Nisso ele pode ser diferente entre o fiscal document e o invoice, mas sendo o commercial_partner_id no documento fiscal tudo vai funcionar como esperado.
cc @marcelsavegnago @renatonlima @mbcosta @netosjb @felipemotter
Hi @renatonlima, some modules you are maintaining are being modified, check this out!
os testes que falham falham no modulo payment_pagseguro por conta dos testes Javascript. Não tem a ver com minha alteração aqui...
Chegou a testar para o cenário de uma empresa B2B e B2C, que hora fatura para a empresa e hora para o contato?
@mileo quel tal nesse caso que vc menciona a gente acrescentar alguma propriedade na empresa. E ai se a empresa for optar por esse sistema (caso raríssimo), ai no partner_id do invoice ela deveria escolher realmente a entidade PF ou PJ da venda e não apenas escolher qualquer contato como o Odoo deixa fazer.
E ai, onde onde eu botei apenas commercial_partner_id neste PR, a gente poderia usar algum commercial_partner_id_especial que sobrecarregaria o commercial_partner_id mas retorna sempre o proprio partner_id se essa propriedade para funcionar assim tiver escolhida. Ai o Odoo passaria o partner_id do invoice pro documento fiscal independente do parent_id ou se for PF ou PJ (como antes dessa PR). No caso de uma venda ou compra, a empresa deveria ter o mesmo cuidado de escolher bem a quem seria relacionado o documento fiscal e não botar apenas o contato.
O que acha?
@mileo tipo algo assim https://github.com/akretion/l10n-brazil/commit/aa18f452e593090c15bd9d6cc336d3b863c64b3e ?
Chegou a testar para o cenário de uma empresa B2B e B2C, que hora fatura para a empresa e hora para o contato?
Neste caso vc se refere a um contato que em um momento compra para a entidade comercial que ele está vinculado e em outro momento ele compra para ele próprio? Se sim, nativamente bastaria o contato ter um outro cadastro e sinceramente entendo que seria o correto. Porém, teriamos problema com CPF duplicado e ai teriamos que rever algumas coisas.
Sinceramente eu não vejo como solução mudar o fluxo padrão do Odoo neste caso.. acho que teriamos muitos problemas com isso. Mas sim acho que cabe uma revisão em relação ao cadastro de pessoa física.
Mas é vdd que no caso raríssimo de uma empresa como o @mileo mencionou ela poderia até preferir da forma como tá hoje... Vc chegou a ver essa minha proposta akretion@aa18f45 ?
Basicamente deixa esse comportamento configurável, mas usando o commercial_partner_id por padrão. Isso quase que sem complexidade adicional.
Esse commit https://github.com/OCA/l10n-brazil/commit/aa18f452e593090c15bd9d6cc336d3b863c64b3e atendi sim a necessidade.
Inclusive depois da pra colocar no contexto alguma manipulação caso a empresa faça os dois casos. Ou ainda algo na operação fiscal que manipule isso.
Hoje se você vai faturar para a empresa, você seleciona na fatura/pedido o parceiro (empresa), e se você vai faturar para um contato você seleciona o parceiro na fatura/pedido
Hoje se você vai faturar para a empresa, você seleciona na fatura/pedido o parceiro (empresa), e se você vai faturar para um contato você seleciona o parceiro na fatura/pedido
@renatonlima Mas você entende que esse não é o comportamento esperado certo ? Pro usuário que está digitando o pedido, além de informar a empresa é importante também informar qual foi o contato (comprador) que está negociando o pedido desta empresa. Essa forma nativa do odoo é bem interessante, pois não precisamos de dois campos para isso.
Concordo com @marcelsavegnago e o @rvalyi e acho essa PR uma ótima solução.
@rvalyi Pelo que vi os commits já estão acertados certo ? a PR está pronta para merge ?
eu vou fechar essa PR por enquanto ja que tem um substituto aqui https://github.com/OCA/l10n-brazil/pull/2520 esse substituto não considera porem https://github.com/OCA/l10n-brazil/pull/2075#issuecomment-1210632461 e poderia ser interessante considerar.