[14.0][REF] l10n_br_sale_stock: Extraction referent the creation of the module sale_stock_picking_invoicing

[mbcosta]

Extraction referent the creation of the module sale_stock_picking_invoicing.

Extração referente a criação do modulo sale_stock_picking_invoicing OCA/account-invoicing#1025 , durante a migração da v14 #1961 foi feito esse PR e essa questão foi levantada, porém havia a dúvida se fora da Localização Brasileira haveria interesse de usar essa implementação, mas recentemente essa questão foi respondida porque foi criado um PR para adaptar o modulo stock_picking_invoicing para funcionar com o Pedido de Vendas OCA/account-invoicing#1672 , e como idealmente o modulo stock_picking_invoicing é focado apenas em criar Faturas a partir da Ordem de Separação/stock.picking sem relação com Pedido de Vendas ou Compras ( "create invoices directly from picking, without having to use Sale or Purchase Orders." https://github.com/OCA/account-invoicing/blob/14.0/stock_picking_invoicing/readme/DESCRIPTION.rst ) e apesar de estar com uma dependência indireta do sale devido o modulo stock_picking_invoice_link https://github.com/OCA/stock-logistics-workflow/blob/14.0/stock_picking_invoice_link/__manifest__.py#L20 acredito que é melhor manter essa separação para isolar e modularizar as funcionalidades assim como acontece hoje na Localização, com isso uma parte do que existe aqui vai para esse novo modulo onde mantive os mesmo cabeçalhos de Licença, Mantedores, Contribuidores e Créditos.

Enquanto o PR do sale_stock_picking_invoicing não é aprovado esse PR vai estar com erro, portanto ele depende do OCA/account-invoicing#1025 mas pode ser testado localmente, caso seja aprovado vou ver de atualizar o HISTORY.rst sobre essa extração.

Foi preciso fazer uma correção no l10n_br_stock_account no método que cria a Fatura, quando o campo partner_id mapeado pelo métodos originais é diferente do _prepare_br_fiscal_dict() esse partner deve ter prioridade porque está sendo mapeado pelo método _get_partner_to_invoice, esse erro não era visto antes porque no l10n_br_sale_stock o campo era novamente informado https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_sale_stock/wizards/stock_invoice_onshipping.py#L20 se acharem melhor posso ver de extrair esse commit.

cc @renatonlima @rvalyi @mileo @gabrielcardoso21 @marcelsavegnago

[OCA-git-bot]

Hi @renatonlima,
some modules you are maintaining are being modified, check this out!

[rvalyi]

boa @mbcosta . Eu não tive tempo para analisar fundo, mas entendo o raciocínio e faz sentido faz tempo que a gente tinha esse assunto. Vamos ver o que é razoável fazer na v14 ou numa versão superior como a v16. Esse tipo de coisa a gente tem que se anticipar muito para ter uma chance de mudar porque depois a galera não querer mudar módulo "estavel". Na localização aqui a gente sempre meio que avisou que esses módulos ainda nao eram muito maduros (beta) e que por isso quem usava tinha que se preparar para seguir os potências refatores, mas no account-invoicing da 14 o pessoal com certeza deve ter a expectativa de algo mais estavel já.

Com eu disse eu ainda nao analisei detalhadamente a PR, é apenas uma consideração mais genérica. Parabéns pelo trabalho!

[mbcosta]

valeu @rvalyi , eu até busquei fazer essa extração durante a migração mas não havia um retorno se haveria algum interesse fora do Brasil, mas como apareceu aquele PR incluindo coisas referentes ao Sale no stock_picking_invoicing parece que o melhor vai ser fazer essa extração para não deixar essa questão em aberto lá no repo do account-invoicing. importante também dizer que isso pode ser feito de forma independente sem afetar o stock_picking_invoicing nem o l10n_br_sale_stock, mas recomendo já buscar fazer essa integração porque nos últimos dias eu revi a implementação e busquei resolver os principais problemas que são a divergências de dados entre a Fatura criada pelo Pedido de Venda com a que é criada pela Ordem de Separação, a necessidade de "glue" módulos para todos os N módulos que podem acabar incluindo novos campos nas Faturas e o Botão "Criar Fatura" que por estar invisível bloqueia o caso de "Down Payments", outro ponto é que o script de migração é simples hoje seria apenas a mudança do nome do campo sale_create_invoice_policy para sale_invoicing_policy, abaixo tem mais detalhes sobre essas alterações.

Foram feitas alterações importantes no PR do sale_stock_picking_invoicing que devem melhorar a implementação:

• Na criação da Fatura pela Ordem de Separação quando tem um Pedido de Venda associado o método agora chama o _prepare_invoice https://github.com/OCA/OCB/blob/14.0/addons/sale/models/sale.py#L571 e o _prepare_invoice_line https://github.com/OCA/OCB/blob/14.0/addons/sale/models/sale.py#L1642 para buscar alguns campos que existem apenas no sale.order e também para evitar a necessidade de 'glue' módulos ( pequenos módulos que acabam sendo criados para evitar dependências indiretas ) que incluem campos nesses métodos, por exemplo:

account_payment_sale https://github.com/OCA/bank-payment/blob/14.0/account_payment_sale/models/sale_order.py#L41
sale_commission https://github.com/OCA/commission/blob/14.0/sale_commission/models/sale_order.py#L64

Segue um exemplo com os dados de demonstração e os modulos account_payment_sale e sale_commission instalados:

Com isso a implementação se torna mais dinâmica, robusta e funcional já que qualquer modulo que seja instalado que adiciona novos campos no sale.order e usa esses métodos "prepare" para inclui-los na Fatura também serão incluídos na criação pela Ordem de Separação/stock.picking, um exemplo na Localização é o modulo l10n_sale_commission_stock que na v14 ainda é um PR em migração #2681 e que com essas alterações se torna desnecessário.

• Modulo ficou compatível com o caso 'Down Payments' Adiantamentos/Pagamentos de Entrada
  Hoje para forçar a criação da Fatura pela Ordem de Separação/stock.picking quando a "Politica de Faturamento de Vendas" esta como stock_picking a implementação torna o botão "Criar Fatura" invisível na visão do Pedido de Venda, mas isso acaba bloqueando o caso "Down Payments", com a alteração feita no sale_stock_picking_invoicing o método _get_invoiceable_lines retorna apenas as linhas que tem Produtos com o Type Service e se não tiver nenhum caso retorna mensagem de erro, com isso também foi possível remover uma alteração no campo qty_to_invoice https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_sale_stock/models/sale_order_line.py#L23

Segue imagens de teste com dados de demonstração:

• Tem dois commits no modulo l10n_br_stock_account
  1 - O partner_id mapeado pelos métodos do modulo stock_picking_invoicing deve ter prioridade sobre o que é mapeado pelo método Fiscal da localização
  2 - A Fatura passa a ser criada com partner_id e o partner_shipping_id preenchidos mesmo quando os valores são iguais, hoje nesse caso o partner_shipping_id é apagado mas estou considerando que o comportamento padrão e ter os dois campos preenchidos porque é isso que acontece quando se cria a Fatura pelo Pedido de Vendas, com isso se torna desnecessário sobre escrever o wizard https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_sale_stock/wizards/stock_invoice_onshipping.py

Se for melhor eu posso ver de extrair esses commits ou junta-los.

O erro ao rodar os testes aqui no PR são causados porque o modulo depende do sale_stock_picking_invoicing, mas já é possível testar localmente e rodar os testes da mesma forma como o CI executa esses testes.

[rvalyi]

trabalho MUITO top hein @mbcosta !

[mbcosta]

value @rvalyi obrigado, preciso ver se é possível fazer algo semelhante no caso do l10n_br_purchase_stock porque no caso do l10n_br_sale_stock acredito que com esse PR teremos algo melhor do que o que existe hoje no repo.

[mbcosta]

Force Push para:

• Incluir nos Dados de Demonstração Linhas de Seção e Notas
• Voltei o arquivo l10n_br_sale_stock/wizards/stock_invoice_onshipping.py para no caso de Pedidos Agrupados para concatenar os campos "manual_customer_additional_data" e "manual_fiscal_additional_data" ( TODO: Isso deveria ser feito no l10n_br_sale, já que existe a possibiliadde de agrupar Pedidos no modulo sale )

Segue exemplo de dois Pedidos de Vendas onde a criação da Fatura é feita a partir das Ordens de Separação/stock.picking mas em um caso o wizard é marcado para Não Agrupar( opção Coleta ) e o outro são Agrupados ( opção Parceiro/Produto )

Pedido 1

Pedido 2

Caso Não Agrupar

Fatura 1

Fatura 2

Caso da Fatura Agrupada

Existe uma questão que não está ligada diretamente com esse PR que é nesses casos de Documentos Fiscais com Linhas de Seção, Notas e Adiantamentos é preciso analisar se isso deve ser bloqueado ou verificar em outro PR o que deve ser feito para deixar isso funcional porque nos testes ao chamar o método action_post() isso acaba gerando erros:

l10n_br_nfe/models/document.py", line 807, in _check_product_default_code
f"The product {line.product_id.display_name} "
odoo.exceptions.ValidationError: The product False must have a default code or the product codeline field (nfe40_cProd) should be filled.

l10n_br_nfe/models/document_line.py", line 503, in export_fields_nfe_40_icms
self.nfe40_choice_icms.replace("nfe40", "")
AttributeError: 'bool' object has no attribute 'replace'

Deixei isso comentado nos testes do modulo, para ver os erros é só descomentar e rodar os testes( ao instalar o l10n_br_account e em seguida o l10n_br_sale_stock e o l10n_br_nfe já é possível ver os erros )

As linhas são lançadas vazias no documento Fiscal

É preciso avaliar os dados fiscais desse produto "Down Payments"

[mbcosta]

Incluído script de migração, o que permite testes em ambiente de homologação*, dados de demonstração com linhas de Seção e Notas, e teste com o caso Adiantamentos/'down Payments', para evitar o erro

l10n_br_nfe/models/document.py", line 807, in _check_product_default_code f"The product {line.product_id.display_name} "
odoo.exceptions.ValidationError: The product False must have a default code or the product codeline field (nfe40_cProd) should be filled.

esse PR depende do #3055

ainda pendente de solução erro

File "l10n_br_nfe/models/document_line.py", line 503, in export_fields_nfe_40_icms self.nfe40_choice_icms.replace("nfe40", "") AttributeError: 'bool' object has no attribute 'replace'

Mas como esse PR é sobre a extração do l10n_br_sale_stock acredito que esse problema de Linhas Seção, Notas e Adiamentos no modulo l10n_br_nfe deve ser visto em outro PR e aqui apenas comentar o teste com um TODO

[mbcosta]

Correção para não criar Linhas do tipo Seção, Nota e Adiantamentos no Documento Fiscal no PR #3064