[14.0][IMP] l10n_br_account_payment_brcobranca: Aprimoramento nos laçamentos das tarifas #2961
Conversation
|
@antoniospneto vi que o @CristianoMafraJunior aprovou. Mas ainda ta de rascunho ou ta OK para revisão do lado de vcs? |
|
opa @rvalyi a principio tá tudo certo, só to testando um pouco em produção, vou esperar mais uns dois dias, se não tiver nenhum chamado vou por a pr aqui como pronta, valeu! |
|
Pessoal, eu encontrei um pequeno problema, no itaú o valor da tarifa não tá somado ao valor pago pelo cliente, fazendo com que sempre fique um saldo em aberto no contas a receber, vamos fazer a correção ok |
antoniospneto
force-pushed
the
14-0_l10n_br_account_payment_brcobranca
branch
from
410aaab
to
9d74da9
Compare
|
Olá, pessoal. Gostaria de informar que a melhoria desta PR tem se mantido estável em produção nos últimos dias, sem registrar nenhum problema. Segue abaixo um retorno processado que inclui as tarifas: Agora a PR está pronta para ser revisada. Se alguém tiver alguma dúvida ou quiser fazer sugestões, sinta-se à vontade para expressar suas opiniões. A feedback de vocês é sempre valioso. |
|
Aqui um exemplo da uma tarifa cobrada na baixa simples: Sem a PR o valor da tarifa não era exibido nesses casos, ficava sempre zerado. |
There was a problem hiding this comment.
LGTM sobre a parte tecnica. @mbcosta alguma objeção com essa PR?
Ai tb @antoniospneto é bom não esquecer que futuramente seria bom usar esse modulo https://github.com/OCA/bank-payment/tree/14.0/account_payment_order_return pros retornos. Mas enfim sei la bem menos prioritario do que migrar para a v16 por examplo.
|
This PR has the |
| @@ -24,6 +24,16 @@ class AccountJournal(models.Model): | |||
| help="Enable automatic payment return reconciliation.", | |||
| default=False, | |||
| ) | |||
| floating_days = fields.Integer( | |||
There was a problem hiding this comment.
É melhor colocar um nome de campo menos genérico e mais especifico exemplo bank_floating_days, bank_days_to_fund_avaiable, bank_days_to_credit, ou outro nome. Também é importante saber se esse é o mesmo campo referente quando o Cliente faz o Pagamento e o Banco tem uma quantidade de dias para compensar o valor, quer dizer existe apenas um campo ou diferentes campos entre um referente a cobrança da Tarifa feita pelo Banco e outro referente ao valor Pago pelo cliente? Porque nesse segundo campo até onde sei isso é algo que pode ser negociado com o Banco e varia dependendo da negociação entre a empresa e o banco. Durante os testes do UNICRED acabei vendo no arquivo de retorno que eram informados dois campos de data referentes ao Pagamento um de quando era feito o Pagamento e o segundo quando esse valor se tornava um Credito disponível para empresa. foi debatido algo semelhante sobre esse atraso do crédito e isso foi resolvido basicamente pegando a data de quando o Credito se tornava disponível, então apenas para entender melhor no arquivo de retorno desses bancos existe apenas uma Data de Cobrança ou existe também a Data efetiva do Débito/Credito? Outro ponto esse campo não deveria estar no modulo l10n_br_account_payment_order para permitir o uso pelos outros modulos do CNAB afim de evitar duplicação de campos?
| break | ||
| elif "occurrence_date" in row: | ||
| self.move_date = row["occurrence_date"] + datetime.timedelta( | ||
| days=self.journal.floating_days |
There was a problem hiding this comment.
Todas as Ocorrências que não são de Liquidação, campo real_payment_date, devem somar a Data referente ao 'Dias para Compensação de Credito/Debito', tem certeza? Quando for um Ocorrência de Protesto ou outra qualquer isso não vai acabar registrando uma Data errada?
| if cod_ocorrencia == "02": | ||
| account_move_line.cnab_state = "accepted" | ||
| elif cod_ocorrencia == "03": | ||
| # TODO - algo a mais a ser feito ? |
There was a problem hiding this comment.
Por favor se um TODO não foi resolvido ou se existe algum comentário no código peço que seja mantido, eu incluo isso tanto para referencia sobre pendencias quanto para esclarecer pontos sobre o código para min e para outros desenvolvedores
|
valeu @antoniospneto , alguns pontos:
"Pessoal, eu encontrei um pequeno problema, no itaú o valor da tarifa não tá somado ao valor pago pelo cliente, fazendo com que sempre fique um saldo em aberto no contas a receber, vamos fazer a correção ok" Isso evitaria esse problema e também evita futuras regressões. Seria bom que esse arquivo de Liquidação seja baseado em um real apenas para confirmar uma questão inicial que é esse Valor da Tarifa é informado e cobrado já nesse momento ou apenas informado e no momento da liquidação é efetivamente cobrado, para confirmar que o Valor da Tarifa não está sendo duplicado, acredito que é o caso de já ser cobrado inicialmente mas é importante a confirmação para tirar qualquer dúvida |
…id field of account_payment_line Para corrigir o bug foi removido o valor de 'payment_line_ids' que é o campo inverso do move_line_id na relação. Sem essa correção o sistema estava substituindo a referencia do contas a receber da fatura que estava atrelada a linha da ordem de pagamento. Essa substituição acabava ocorrendo ao fazer o processamento do retorno, na criação dos lançamentos contabeis.
antoniospneto
force-pushed
the
14-0_l10n_br_account_payment_brcobranca
branch
from
cb62b04
to
066401a
Compare
Objetivo
Esta PR propõe aprimorar o tratamento de tarifas cobradas pelos bancos, assegurando o registro de todas as tarifas identificadas no retorno bancário, independentemente da ocorrência à qual estão vinculadas. Antes desta atualização, o sistema registrava tarifas apenas nas ocorrências de liquidação. A mudança visa capturar e registrar de forma abrangente todas as tarifas associadas a diferentes tipos de ocorrências bancárias.
Exemplos de Casos Previamente Não Cobertos:
A ocorrência de tarifas depende do banco e do acordo firmado com o cliente. Existem múltiplas possibilidades de cobranças de tarifas, como alterações de vencimento, abatimentos e baixas. Não é necessário que o nome da ocorrência contenha explicitamente a palavra "TARIFA" para que uma tarifa seja aplicada.
Observações
Um novo campo, floating_days, foi adicionado ao diário do banco para indicar o número de dias necessários para o banco processar os recebimentos. Isso porque, no caso de uma tarifa sem liquidação de cobrança, muitas vezes não dispomos de uma data de liquidação ou de crédito/debito para usar como referência. Assim, na ausência da data de liquidação, a tarifa será registrada na data da ocorrência somada aos dias de flutuação.
Adicionamos diversos testes unitários para prevenir regressões.
Esta PR está em modo rascunho enquanto validamos as mudanças em ambiente de produção.
cc @CristianoMafraJunior @rvalyi @mbcosta @marcelsavegnago @mileo