-
-
Notifications
You must be signed in to change notification settings - Fork 247
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][FIX] l10n_br_account_payment_order: trigger CNAB info load on payment_mode_id change #3213
base: 14.0
Are you sure you want to change the base?
[14.0][FIX] l10n_br_account_payment_order: trigger CNAB info load on payment_mode_id change #3213
Conversation
Hi @mbcosta, |
ea8839e
to
d0bb0ba
Compare
vale a pena dar uma pensada se não teria um fix mais limpo. Override do write é um pouco brutal... |
pois é eu tava pensando o mesmo, será que não vale a pena fazer um pequeno wizard para alterar o método de pagamento de uma fatura já postada? |
gosto da ideia do wizard. |
d0bb0ba
to
1c40371
Compare
Pessoal, atualizei o commit incluindo o IMP para esse novo Wizard. Foquei no modo simples, conforme descrito. |
l10n_br_account_payment_order/wizards/account_move_payment_mode.py
Outdated
Show resolved
Hide resolved
eea85fc
to
183e4d2
Compare
183e4d2
to
9baed09
Compare
Realizei a mudança aqui, valeu @antoniospneto bem melhor no menu de Ação |
9baed09
to
2bda539
Compare
Estou incluindo os testes unitários para cobrir o percentual desse novo wizard criado |
e8329fd
to
552f3cc
Compare
552f3cc
to
8da01be
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.
Não cheguei a testar, mas pelo código me parece tudo Ok, valeu @kaynnan
@mbcosta ok para vc esse? |
valeu @kaynnan eu procurei ver se era possível resolver com o onchange como você havia tentado, o erro do NewID acontece porque o onchange cria um objeto temporário que é esse que dava erro, mas é possível dentro do onchange obter o objeto real com um self._origin então é até possível resolver via onchange com algo como: EDIT: Referencia https://www.odoo.com/pt_BR/forum/ajuda-1/obtain-the-id-of-a-self-onchange-odoo-101202 @api.onchange("payment_mode_id")
def _onchange_payment_mode_id(self):
for record in self:
if record.state == "posted":
for line in record._origin.financial_move_line_ids:
line.payment_mode_id = record.payment_mode_id
record.with_context(
payment_mode=record.payment_mode_id,
)._origin.load_cnab_info()
def load_cnab_info(self):
payment_mode = self.payment_mode_id
# Se não possui Modo de Pagto não há nada a ser feito
if not payment_mode:
if self.env.context.get("payment_mode"):
payment_mode = self.env.context.get("payment_mode")
else:
return
Mas a criação das Linhas de Pagamentos ocorre logo em seguida, então caso o Usuário selecione um Modo de Pagamento errado acaba criando uma Ordem de Pagto/Linhas de Pagto errados gerando outro problema, talvez isso poderia ser resolvido com um pop-up de Warning pedindo a Confirmação do Modo de Pagto escolhido ao Usuário. Com o Wizard que você fez também funciona, porém é preciso verificar se a partir disso o campo Modo de Pagamento deve estar readonly porque mesmo com esse PR se o Usuário selecionar o Modo de Pagto direto no campo ao invés de usar o Wizard vai ocorrer o mesmo erro que você inclui no começo do PR, quer dizer o erro inicial persiste. Temos que avaliar se isso deve ser feito via Wizard, como foi feito porém tratando para não permitir o usuário selecionar o Modo de Pagto diretamente, ou via Onchange, talvez com menos código, o que seria melhor? É bom dizer também que existe uma diferença entre Erros do Código, responsabilidade dos Desenvolvedores, de erros de Cadastro, responsabilidade do Usuário, no caso do Modo de Pagamento até é possível alterar o campo com a Fatura não estando em Provisório, e acredito que nesse casos não foi considerado voltar a Fatura para Provisório porque já gerou um Documento Fiscal, é isso? Porque se fosse outro campo como o "Termos de Pagamento"/payment.terms isso já não seria possível por gerar as Linhas Financeiras aí o processo seria outro que é o Usuário Cancelar a Nota e gerar novamente com os dados corretos, nos podemos incluir Avisos, Validações e idealmente não deve ter mensagens de erro sem tratamento mas determinados erros precisam ser classificados para definir responsabilidades e custos. |
Talvez outra possível solução ao selecionar o campo pelo campo Modo de Pagto o método onchange chamar o Wizard criado com o valor já preenchido apenas para Confirmação |
Obrigado, @mbcosta, pela explicação. Enfrentamos o problema com um cliente que, após a postagem da fatura precisava alterar o modo de pagamento para o CNAB, porem esse processo do CNAB somente ocorre na ação do _post, cheguei a tentar uma solução pelo onchange mas me deparei com o mesmo erro de NewID, dessa maneira optei pelo Wizard. Qual caminho acha mais seguro/ideal para essa questão? |
@kaynnan pode ser pelo wizard mesmo apenas adiciona o metodo onchange no Modo Pagamento para no caso do state Posted e CNAB apagar o valor informado, quer dizer não permitir o preenchimento alterando o valor para False mas retornando um Warning orientando sobre o como alterar via Wizard, isso já deve evitar o erro do caso onde o usuário tenta informar o campo com um CNAB diretamente pelo campo ao invés de usar o wizard. Eu tentei ver se era possível chamar o wizard via onchange, porém existe apenas um modulo da OCA ainda na versão 8.0 OCA/web#579 que busca implementar isso. |
Pessoal não seria melhor fazer isso por linha de lançamento? Trabalhando no account.move.line e no wizard já existente? E ai já trabalhar os fluxos necessários, troca de banco, troca de forma de pagamento e etc? |
cc @marcelsavegnago @douglascstd
PR para corrigir um problema onde, ao alterar o Modo de Pagamento para um CNAB em uma fatura já postada, a visualização do PDF é impossibilitada devido às ações necessárias serem realizadas apenas no método
_post
ao chamar oload_cnab_info
, resultando o erro ao tentar visualizar o PDF:Realizei esse FIX no método
write
porque oonchange
não era suficiente, resultando em um erro relacionado ao métodohex()
sendo chamado em um objetoNewId
.