[16.0][MIG] l10n_br_sale_stock #3532
Conversation
|
Hi @renatonlima, @rvalyi, |
Ok, antes eu vou sugerir umas melhorias no módulo |
antoniospneto
force-pushed
the
16.0-mig-l10n_br_sale_stock
branch
5 times, most recently
from
8f62943 to
cfbc894
Compare
|
ufa agora os testes passaram, mas ainda vou organizar e revisar o meu ultimo commit, talvez eu abra pr menores, vou fazer isso nos proximos dias. |
mais uma vez valeu demais @antoniospneto ! |
antoniospneto
force-pushed
the
16.0-mig-l10n_br_sale_stock
branch
from
cfbc894 to
664b340
Compare
|
/ocabot migration l10n_br_sale_stock |
…l10n_br_sale_stock module to accomodate to the increased modulrity in OpenERP 7 where sale modules doesn't force you to install the stock module aymore
…r_account e l10n_br_account
…br_crm, l10n_br_data_base, l10n_br_data_zip e l10n_br_sale_stock
…stock e corrigido métodos onchange do objeto stock.picking
…emo nos arquivos __openerp__.py de todos modulos da localização
Currently translated at 52.9% (9 of 17 strings) Translation: l10n-brazil-14.0/l10n-brazil-14.0-l10n_br_sale_stock Translate-URL: https://translation.odoo-community.org/projects/l10n-brazil-14-0/l10n-brazil-14-0-l10n_br_sale_stock/pt_BR/
Currently translated at 58.8% (10 of 17 strings) Translation: l10n-brazil-14.0/l10n-brazil-14.0-l10n_br_sale_stock Translate-URL: https://translation.odoo-community.org/projects/l10n-brazil-14-0/l10n-brazil-14-0-l10n_br_sale_stock/pt_BR/
Currently translated at 64.7% (11 of 17 strings) Translation: l10n-brazil-14.0/l10n-brazil-14.0-l10n_br_sale_stock Translate-URL: https://translation.odoo-community.org/projects/l10n-brazil-14-0/l10n-brazil-14-0-l10n_br_sale_stock/pt_BR/
Currently translated at 70.5% (12 of 17 strings) Translation: l10n-brazil-14.0/l10n-brazil-14.0-l10n_br_sale_stock Translate-URL: https://translation.odoo-community.org/projects/l10n-brazil-14-0/l10n-brazil-14-0-l10n_br_sale_stock/pt_BR/
Currently translated at 100.0% (17 of 17 strings) Translation: l10n-brazil-14.0/l10n-brazil-14.0-l10n_br_sale_stock Translate-URL: https://translation.odoo-community.org/projects/l10n-brazil-14-0/l10n-brazil-14-0-l10n_br_sale_stock/pt_BR/
When Picking has a Sale Order related the Partner used to create the Invoice should be the partner_invoice_id of Sale, because the Partner of Picking can be the partner_shipping_id of Sale Order. [FIX] l10n_br_sale_stock: Get Fiscal Partner
When mapping the Line Fiscal Operation and Taxes the Partner of the object can be or not the Partner to Invoice, in case of Picking with related a related SO, it should use the partner_invoice_id field in Sale because the Partner of Picking can be the partner_shipping_id of the SO.
…nstead of partner object
antoniospneto
force-pushed
the
16.0-mig-l10n_br_sale_stock
branch
from
664b340 to
62d1148
Compare
|
Por favor, solicito ao @antoniospneto e aos outros PSC do projeto @OCA/local-brazil-maintainers considerar o Bloqueio ou mesmo o Fechamento desse PR com o objetivo de forçar a Revisão do PR [14.0][REF] l10n_br_sale_stock: Extraction referent the creation of the module sale_stock_picking_invoicing os motivos são:
Isso não é um trabalho de dias, semanas ou meses são anos que estamos buscando fazer essa Extração e melhorar essa implementação, houveram PRs e Issues questionando o módulo porque acabavam faltando campos quando a criação ocorria através do Picking, eu tenho buscado orientar e resolver a maior parte dos Issues referentes a implementação de Criação de Faturas através do Picking e também criando tanto os PRs de Migração, Melhorias, Manutenções e Correções; diante disso peço que seja avaliada essa questão simplesmente para evitar gastar tempo em uma implementação que está sendo melhorada de forma efetiva. |
|
Pessoal hoje eu não tenho muito interesse no módulo 10n_br_sale_stock acabei fazendo a migração dele pois é dependencia do Mas de qualquer forma eu posso ajudar a revisar a PR do @mbcosta mas confesso que o faturamento pelo picking é um assunto que estou pouco acostumado. |
como comentei no #2469, eu acho que a mudança é bastante segura e que vale a pena faze-la ainda na 14 no intuido de melhorar a sincronia com a v16... |
|
Obrigado @antoniospneto e @rvalyi por considerarem o PR, entendo que existe um foco maior na v16 principalmente para permitir a migração de outros módulos, estou vendo de atualizar e resolver tanto a migração do sale_stock_picking_invoicing quanto do l10n_br_sale_stock e espero ter isso resolvido o mais breve possível para migrar outros módulos. Antonio sobre isso "o faturamento pelo picking é um assunto que estou pouco acostumado." apenas um resumo: Até a v8 o Odoo tinha nativamente essa funcionalidade, ao remover trouxe um problema para a Localização porque muitos Casos de Uso no Brasil precisam emitir uma Fatura/Documento Fiscal sem relação com um Pedido de Vendas ou Compras, casos como:
Assim depois da v8 foi preciso resolver isso dentro da OCA, buscando um modulo para fazer isso encontramos o stock_picking_invoicing, desde de então acabamos mantendo o módulo e também evitando que alterações propostas pela comunidade internacional acabassem causando algum problema no Caso de Uso Brasil, esse modulo para muitos casos não é opcional muitas Empresas podem não precisar ou querer usar o l10n_br_sale_stock ou o l10n_br_purchase_stock mas vão precisar usar o stock_picking_invoicing e o l10n_br_stock_account devido a esses casos de Fatura/Documento Fiscal criadas a partir de uma Movimentação de Estoque mas Sem relação com Pedido de Vendas ou Compras, aqui é até importante dizer que o stock_picking_invoicing está sem Mantenedor definido e acredito que seria importante que pelo menos 2 ou mesmo 3 desenvolvedores da Localização fossem mantenedores para evitar problemas. Os módulos l10n_br_purchase_stock e l10n_br_sale_stock realmente são opcionais, e pelo o que vejo acabam sendo usado por questões de processos e formas de trabalho de cada empresa, exemplo:
Então podemos ter casos de uso onde uma empresa pode usar o l10n_br_stock_account mas não usar o l10n_br_sale_stock e nem o l10n_br_purchase_stock, ou usar todos ou usar apenas o l10n_br_sale_stock ou apenas l10n_br_purchase_stock, para isso ser possível esses módulos precisam estar separados, e como para a Localização é importante manter o stock_picking_invoicing, por ter muitos casos onde isso não é opcional, é preciso que essa separação também ocorra no repo account-invoicing. Existia um problema no l10n_br_sale_stock e l10n_br_purchase_stock que era justamente a falta de compatibilidade entre a Fatura criada a partir do Pedido de Vendas ou Compras com a criada pela Ordem de Separação/Seleção/Picking eu já havia tentando resolver por exemplo o caso do "payment_mode_id" com um hasattrs para evitar criar um "glue module" apenas para copiar esse campo e também de forma dinâmica mas sem sucesso, o @renatonlima acabou precisando criar um módulo para resolver a Comissão, então com alteração feita esse problema acaba sendo resolvido e eu acredito que agora os módulos podem ser considerados com o status Estável/Mature, o que deve garantir menos Issues e PRs relacionados, até em módulos que dependem do l10n_br_sale_stock ou l10n_br_purchase_stock. |
Reabertura do #3371