[RFC] l10n_br_payment_order*: Use native payment object

[rvalyi]

Pessoal, não é so nesse repo que estamos dando uma limpa antes de carregar as coisas para v15/v16, o pessoal tb ta fazendo isso no modulo OCA account_bank_payment e isso vai no impactar aqui para os módulos de CNAB de cobrança e de pagamento:
OCA/bank-payment#979

Lembrando tb que quando der seria legal tb fazer um refactor para integrar o modulo https://github.com/OCA/bank-payment/tree/14.0/account_payment_order_return para lidar com os retornos de CNAB, pois tinhamos feito do nosso proprio jeito aqui antes de ter esse modulo account_payment_order_return maduro na OCA.

cc @renatonlima @mbcosta @antoniospneto @felipemotter @marcelsavegnago @mileo

[rvalyi]

cc @douglascstd

[rvalyi]

(o merge de OCA/bank-payment#979 foi feito)

[marcelsavegnago]

Eu estava acompanhando isso também. Acredito que independente de atualizar o repo bank-payment nos ambientes de clientes esta mudança deve impactar testes de novas PRs no repo da localização ou estou enganado?

[rvalyi]

so para esclarecer: até os 2 módulos l10n_br_account_payment e l10n_br_account_payment_brcobranca serem refatorados, nos testes desse repo, a gente forçou a usar uma revisão anterior do repo OCA/bank-payment e então do modulo account_payment_order, usando esse workaround #2289

[felipemotter]

@rvalyi nas nossas implementações estamos fazendo isso também. Como estavamos conversando no telegram, o refactor não será tão simples e se fosse para refatorar trazendo de volta os bank lines levaria certo tempo.

Eu havia começado o refactor e a forma mais crua já havia sido feita. Mas o problema de o pagamento ser confirmado desde o inicio já estava ocasionando erros nos testes. Esse é a branch que eu estava fazendo a poc: https://github.com/Engenere/l10n-brazil/tree/14.0-ref-br-pay-order

[mbcosta]

Pessoal procurei alterar os módulos da localização que dependem do account_payment_order para tornar possível ao menos funcionar com as alterações que foram feitas no account_payment_order, isso está no PR #2386 existem algumas considerações que fiz lá mas vou colocar aqui também:

Sobre a migração e uso do account.payment no caso CNAB, eu testei criando um banco de dados com os dados de demonstração sem essas alterações Confirmando duas Faturas Unicred e gerando uma Ordem de Debito até o fim e fazendo o retorno do CNAB de um caso e deixando a outra Ordem no estado Confirmado.

Caso sejam criados os account.payment, o que é feito pelo account_payment_order, apesar de existirem somente dois account.move o script de migração acaba criando vários account.payment o que fica errado, pois só deveriam existir dois Pagamentos

Existem outros problemas relacionados a implementação do account_payment_order o código considera que toda account.payment.line deve gerar um account.payment o que não é o caso do CNAB devido a possibilidade de mandar outras Instruções como "Alteração de Vencimento", "Desconto" e etc ( https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_account_payment_order/models/l10n_br_cnab_change_methods.py ), onde nesses casos não deve criar um account.payment e ao informar que o arquivo foi Enviado/File Uploaded ocorre uma Reconciliação dos account.payment criados o que também não é real no caso CNAB Cobrança porque o banco precisa antes Confirmar a Instrução e a reconciliação só deve ocorrer quando o Banco informa via CNAB que houve esse pagamento, o código não está considerando que existem recebimentos a prazo.

Por isso optei por sobre escrever o método draft2open do account.payment.order para que nos casos CNAB não seja criado o account.payment mantendo assim o mesmo comportamento que existe hoje e dessa forma ser possível atualizar o account_payment_order e deixar tanto o uso do account.payment quanto do modulo https://github.com/OCA/bank-payment/tree/14.0/account_payment_order_return para tratar o Arquivo de Retorno do CNAB no ROADMAP do modulo referenciando esse RFC e dessa forma também ter PRs específicos para essas mudanças.

[rvalyi]

pessoal, foi feito o merge do #2386 então tou fechando esse RFC