-
-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[14.0][IMP] l10n_br_account_payment_brcobranca: Aprimoramento nos laçamentos das tarifas #2961
base: 14.0
Are you sure you want to change the base?
[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 |
410aaab
to
9d74da9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
É 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
cb62b04
to
066401a
Compare
Ainda esta em draft? |
Sim, ainda não tá legal para entrar na branch principal, eu penso em simplificar a proposta, remover a parte do lançamento contábil da tarifa e deixar apenas o registro delas que antes não era exibido no retorno e nem associado ao contas a receber. Também tenho que ver as questões que o @mbcosta comentou. Em breve pretendo voltar nesse assunto. |
066401a
to
540ba62
Compare
…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.
540ba62
to
bf3ed67
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