[14.0][IMP] l10n_br_account_payment_cobranca: add seg. R details

[DiegoParadeda]

Para o caso do boleto 240 do Santander alguns campos obrigatórios não estavam sendo preenchidas nas instruções de Baixa e Abatimento:

• codigo_multa
• percentual_multa
• tipo_mora
• valor_mora

Adicionei as duas instruções no trecho de código que popula esses campos, antes apenas a instrução de Registro passava no trecho.

Testes

• Erro com o código atual - operação de baixa/abatimento (cursor na pos 66)

• Com a alteração - operação de baixa/abatimento (cursor na pos 66)

[OCA-git-bot]

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

[mbcosta]

@DiegoParadeda entendo o problema porém a solução precisa ficar restrita ao caso que vocês está buscando resolver, Banco Santander CNAB 240
https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_account_payment_brcobranca/models/account_payment_line.py#L121

Veja o exemplo do caso UNICRED

https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_account_payment_brcobranca/models/account_payment_line.py#L17

Então isso precisa ser incluído aqui

https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_account_payment_brcobranca/models/account_payment_line.py#L105

Isso é importante porque na implementação do CNAB nós usamos como premissa

"O Banco X CNAB Y é assim e precisa disso ou daquilo mas os outros Bancos CNAB que ainda não foram implementados nós não sabemos"

e não a premissa

"O Banco X CNAB Y é assim então todos os outros Bancos serão iguais"

No inicio da implementação foi usada essa ideia de generalização mesmo para o CNAB 240 que era visto como Padronizado e se considerava o Itau 240 como "O Padrão" mas com o tempo e com outros casos sendo implementados foi visto que isso não era real, e se for feita essa abordagem de generalização, como a sua porque afeta todos os casos, isso pode passar a gerar erro em casos que já foram Homologados, Testados e portanto estão em Produção.

Essa "generalização" foi um dos principais problemas que tivemos na implementação do CNAB, e até levou um tempo "batendo-cabeça" até mudar essa visão e passar a considerar que apesar das Documentações e da FEBRABAN dizerem que usam "O Padrão" na verdade não existe esse "Padrão" e só assim foi possível ter uma implementação viável, considerando na arquitetura essa falta de "Padrão", porque antes o que acontecia era que muitos metodos acabavam "juntando tudo" ignorando essa questão das diferenças entre os Bancos/CNAB, mesmo as diferenças entre um mesmo Banco no 400 e 240, e ao alterar/corrigir/implementar um caso específico isso acabava afetando diversas partes do módulo aumentando o DIFF, dificultando a Revisão, e em mutos casos causando erros em outros em outros Banco/CNAB, já que na maioria da vezes o desenvolvedor está focado em um caso especifico ignorando todos os outros o que é o normal e esperado já que tem um custo grande de Tempo/Trabalho implementar todos os casos de uma vez para ter uma visão macro e juntar o que é comum, isso é feito depois e apenas nos casos onde temos a certeza que um determinado grupo de Banco/CNAB tem um mesmo comportamento, então por principio consideramos que cada caso Banco/CNAB pode esperar campos e valores diferentes, no README do l10n_br_account_payment_order tem um comentário sobre isso

[DiegoParadeda]

@mbcosta corrigido!

também repeti os testes

[mbcosta]

Valeu @DiegoParadeda parabéns pelo trabalho, obrigado por considerar a revisão

[DiegoParadeda]

Valeu @DiegoParadeda parabéns pelo trabalho, obrigado por considerar a revisão

Valeu @mbcosta!!

[rvalyi]

/ocabot merge patch

[OCA-git-bot]

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 14.0-ocabot-merge-pr-3624-by-rvalyi-bump-patch, awaiting test results.

[OCA-git-bot]

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