[16.0][MIG] l10n_br_base

[mileo]

Testing https://github.com/OCA/oca-port

[rvalyi]

@mileo prós 8-10 módulos mais básicos do repo, (como esse) seria ideal fazer que nem na v13, fazer uma etapa intermediária na v15. Quase que não custa nada de fazer a migração em 2 passos mas manda um sinal bem melhor para quem se ferrou com a v15 (por examplo através de uma implementação feita por um parceiro oficial; não é pouca gente que tá se ferrando) e que assim poderia enxergar alguma saída pela OCA (já que não poderia migrar para a v16 já). Do nosso lado a gente não pretende manter nada na v15, mas TB não iremos blocar caso alguém cuida de fazer os ports e backports na v15. E mesmo se a v15 tiver apenas 10 ou algum dia talvez até 20 módulos já seria alguma para essa galera que foi se perder na v15 sem procurar sobre o projeto antes.

Alem disso seria bom segurar um pouquinho a onda da 16.0 para limpar ainda alguns detalhes na 14.0 (inclusive que vem de vcs). Pois a partir do momento que a gente começa a fazer os merges na 16.0 para valer, considerando os nossos recursos ficaria inviavel fazer backports e frontports com a 12.0 mais. Manter 2 versões ja é o máximo que a gente consegue fazer e não seria bem vc que poderia demostrar o contrario (estão mais de um ano sem revisar quase nada nem resolver nenhum bug no projeto). Então algumas semanas ou meses ainda antes de desligar a 14.0 da 12.0 não faria mal. Se vc ainda considerar que vai levar alguns meses para ter o modulo account_reconciliation_widget na 16.0 tb não adiantaria muito ter os módulos de localização do account tão cedo (o base poderia ate ser um pouco antes). Quem tiver com fogo no rabo pode ajudar na migração do account_reconciliation_widget eu acho que seria muito bem vindo.

cc @renatonlima @marcelsavegnago @netosjb @felipemotter @mbcosta

[mileo]

@mileo prós 8-10 módulos mais básicos do repo, (como esse) seria ideal fazer que nem na v13, fazer uma etapa intermediária na v15. Quase que não custa nada de fazer a migração em 2 passos mas manda um sinal bem melhor para quem se ferrou com a v15 (por examplo através de uma implementação feita por um parceiro oficial; não é pouca gente que tá se ferrando) e que assim poderia enxergar alguma saída pela OCA (já que não poderia migrar para a v16 já). Do nosso lado a gente não pretende manter nada na v15, mas TB não iremos blocar caso alguém cuida de fazer os ports e backports na v15. E mesmo se a v15 tiver apenas 10 ou algum dia talvez até 20 módulos já seria alguma para essa galera que foi se perder na v15 sem procurar sobre o projeto antes.

Alem disso seria bom segurar um pouquinho a onda da 16.0 para limpar ainda alguns detalhes na 14.0 (inclusive que vem de vcs). Pois a partir do momento que a gente começa a fazer os merges na 16.0 para valer, considerando os nossos recursos ficaria inviavel fazer backports e frontports com a 12.0 mais. Manter 2 versões ja é o máximo que a gente consegue fazer e não seria bem vc que poderia demostrar o contrario (estão mais de um ano sem revisar quase nada nem resolver nenhum bug no projeto). Então algumas semanas ou meses ainda antes de desligar a 14.0 da 12.0 não faria mal. Se vc ainda considerar que vai levar alguns meses para ter o modulo account_reconciliation_widget na 16.0 tb não adiantaria muito ter os módulos de localização do account tão cedo (o base poderia ate ser um pouco antes). Quem tiver com fogo no rabo pode ajudar na migração do account_reconciliation_widget eu acho que seria muito bem vindo.

cc @renatonlima @marcelsavegnago @netosjb @felipemotter @mbcosta

@rvalyi não iremos nesse momento investir em uma versão intermediária, como a 15.0, a não ser que tenha algum cliente que invista nisso.

Nosso foco nesses próximos dias será revisar os PRs da v14 e migrar os módulos básicos da localização para a v16.

Somente um comentário, sem solicitação de mudança

[mileo]

/ocabot migration l10n_br_base

[rvalyi]

A gente ta se esforçando para que os módulos centrais da localização funcionam com bancos multi-pais, nisso
tem que filtrar apenas os registros pros quais partner.country_id.code.upper() == "BR" e senão chamar super.

Eu tb acho melhor falar no docstring o que a gente faz no override do que fazer o papagaio do docstring original.
Poderia ser algo do tipo:
""'"In Brazil the address format is street_name, street_number (comma instead of space)"""

[mileo]

Solved

Solved

[douglascstd]

[REPROVADO] Testes Funcionais
Não aparece na view do contact o campo para Instant Payment Method (PIX)

APROVADO

Outros testes realizados:

Inserção e validação do CNPJ:

Configuração Localicalização Brasil:

Inserção e validação da inscrição estadual

[mileo]

[REPROVADO] Testes Funcionais Não aparece na view do contact o campo para Instant Payment Method (PIX)

APROVADO

Outros testes realizados:

Inserção e validação do CNPJ:

Configuração Localicalização Brasil:

Inserção e validação da inscrição estadual

@douglascstd obrigado pela revisão, mas esse campo é adicionado somente pelo módulo l10n_br_account:

https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_account/views/res_partner_view.xml#L21-L28

[mileo]

/ocabot merge nobump

Histórico reescrito com PR da v15

[OCA-git-bot]

This PR looks fantastic, let's merge it!
Prepared branch 16.0-ocabot-merge-pr-2164-by-mileo-bump-nobump, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at c08b2cf. Thanks a lot for contributing to OCA. ❤️