[16.0][MIG] l10n_br_sale_stock

[antoniospneto]

Reabertura do #3371

[OCA-git-bot]

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

[rvalyi]

Seria bom usar #2955 e OCA/account-invoicing#1857

[antoniospneto]

Seria bom usar #2955 e OCA/account-invoicing#1857

Ok, antes eu vou sugerir umas melhorias no módulo l10n_br_account pra melhorar os lançamentos contabeis que estão quebrando em alguns testes, quebrando a cabeça aqui ainda

[antoniospneto]

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.

[rvalyi]

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 !
Vc consegue partir de #2955 e usar OCA/account-invoicing#1857 (lembra como usa no test-requirements.txt?)

[rvalyi]

@antoniospneto https://github.com/OCA/maintainer-tools/wiki/Use-temporary-reference(s)-to-another-pull-request(s)

[antoniospneto]

/ocabot migration l10n_br_sale_stock

[mbcosta]

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:

• O PR torna desnecessário a migração do módulo [14.0][MIG] l10n_br_sale_commission_stock #2681 que apesar de ser simples representa os vários possíveis casos de necessidade de criar "glue modules" na implementação que existe hoje na v14 e nessa migração, podem existir diversos casos por exemplo account_payment_sale ou sale_commission, quer dizer se for feito o merge da forma que está a Localização ainda vai "precisar" ou tem a responsabilidade de migrar o l10n_br_sale_commission_stock na v14, v15 e v16 para ter isso funcionando e ainda resolver caso a caso os diversos campos específicos que podem não estar sendo copiados

• A melhoria feita 'é considerável, pode ser demonstrada é comprovada através dos Testes do código e na tela com Dados de Demonstração que permitem ver e testar os casos de uso sem necessidade de muitas parametrizações

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.

[antoniospneto]

Pessoal hoje eu não tenho muito interesse no módulo 10n_br_sale_stock acabei fazendo a migração dele pois é dependencia do l10n_br_delivery e do l10n_br_delivery_nfe, esses que são o meu foco.

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.

[rvalyi]

Pessoal hoje eu não tenho muito interesse no módulo 10n_br_sale_stock acabei fazendo a migração dele pois é dependencia do l10n_br_delivery e do l10n_br_delivery_nfe, esses que são o meu foco.

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