Skip to content
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

[RFC] Múltiplos Modos de Pagamento na mesma Fatura/Invoice #1850

Closed
mbcosta opened this issue Mar 30, 2022 · 7 comments
Closed

[RFC] Múltiplos Modos de Pagamento na mesma Fatura/Invoice #1850

mbcosta opened this issue Mar 30, 2022 · 7 comments
Labels
enhancement stale PR/Issue without recent activity, it'll be soon closed automatically.

Comments

@mbcosta
Copy link
Contributor

mbcosta commented Mar 30, 2022

Existe a possibilidade de criar uma Nota Fiscal com múltiplos Modos/Meios de Pagamentos exemplo:

Termos de Pagamento/account.payment.terms    -     30/60/90
Modos de Pagamentos/account.payment.mode   -     Dinheiro/Cartão de Crédito/Boleto

Isso está pendente de implementação e é muito usado no caso de NFCe, houveram algumas tentativas de se fazer isso, uma foi no caso de CNAB de Pagamentos odoo-brazil#112 ( revendo agora o que eu escrevi lá parece estar muito especifico para o caso do CNAB e não teria muito para acrescentar aqui mas os outros comentários e a experiencia de um caso real podem ajudar a entender o problema ), acredito que o melhor a ser feito e debater as especificações e se possível casos de uso, algumas das especificações que vi até o momento:

  • Isso deve ser feito em um modulo especifico? Aparentemente sim porque não seria o ideal incluir essa complexidade para os casos de uso onde a empresa usa apenas o caso simples, que é o que existe atualmente. Qual o nome ideal para o modulo? multiple_account_payment_mode_per_invoice ?

  • O modulo deveria estar na localização ou ser feito em outro repo da OCA ? Não sei dizer se em outros países existe essa necessidade mas o ideal seria ser feito no mesmo repo do account_payment_mode https://github.com/OCA/bank-payment e se necessário localizar, mas não vejo problema em fazer inicialmente no repo da localização e dependendo no futuro move-lo

  • Mesmo com o caso dos múltiplos modos de pagamento implementado o caso simples ainda deve continuar funcionando da mesma forma

  • Como parametrizar os múltiplos modos de pagamento de uma forma que os cadastros não fiquem repetitivos? Esse parece ser o principal problema dessa implementação

  • Os relatórios de outros módulos que incluem o Modo de Pagamento vão precisar considerar essa questão? Idealmente seria melhor não para evitar a necessidade de adaptar os diversos relatórios que usam o campo

  • Hoje quando o l10n_br_nfe e o l10n_br_fiscal estão instalados essas informações são colocadas de forma manual, até onde entendo deve continuar assim ou alguém acredita que isso deveria ser automatizado? Por isso estou considerando que na implementação debatida aqui os módulos l10n_br_account , l10n_br_nfe e o l10n_br_fiscal precisam estar instalados

  • Hoje o modulo l10n_br_account_payment_order inclui o campo account.payment.mode no objeto account.move.line https://github.com/OCA/l10n-brazil/blob/12.0/l10n_br_account_payment_order/models/account_move_line.py#L76 isso teria que ser movido para esse novo modulo para assim identificar qual o Modo de Pagamento de cada Parcela/account.move.line

Por enquanto a ideia que eu tenho sobre como fazer é adicionar no objeto account.paymento.mode um campo Boolean para saber quando é um caso de Múltiplos Modos de Pagamentos e poder assim diferenciar o caso simples, quando for esse caso incluir/mostrar linhas do Modo de Pagamento (associar um Modo de Pagamento a outros, algo que critiquei no PR mencionado mas não vejo outra forma de fazer ) onde seja possível informar a Sequencia de associação entre os modos e as linhas da Parcela, mostrar também na tela do Modo de Pagamento nesse caso a quais Termos de Pagamentos/account.payment.terms esse modo pode ser usado com uma validação para permitir associar apenas quando a quantidade de linhas de Modos sejam iguais a quantidade de linhas dos Termos( evitar o erro de ter mais ou menos Modos do que Termos de Pagto ou vice e versa ) e nas telas onde se informa o Modo de Pagamento a ser usado( sale.order, purchase.order, l10n_br_fiscal.document e account.invoice ) incluir um Dominio/Domain no campo do account.payment.terms para no caso do Modo ser do tipo Múltiplo mostrar apenas os Termos associados a esse Modo, dessa forma se evita a necessidade de criar um terceiro objeto ou amarrar de forma fixa o Modo aos Termos. Isso é apenas um rascunho e é importante ter relatos de casos de uso reais e outras especificações que alguém acredite ser necessária para ter essa implementação.

cc @renatonlima @rvalyi @mileo @gabrielcardoso21 @marcelsavegnago @netosjb @felipemotter

@marcelsavegnago
Copy link
Member

marcelsavegnago commented Mar 30, 2022

@mbcosta não sei se serve de referencia mas achei este módulo
https://github.com/ingadhoc/account-payment/tree/12.0/account_payment_group

Tem na versão 15.0 tbm

@marcelsavegnago
Copy link
Member

marcelsavegnago commented Mar 30, 2022

  • O modulo deveria estar na localização ou ser feito em outro repo da OCA ? Não sei dizer se em outros países existe essa necessidade mas o ideal seria ser feito no mesmo repo do account_payment_mode https://github.com/OCA/bank-payment e se necessário localizar, mas não vejo problema em fazer inicialmente no repo da localização e dependendo no futuro move-lo

Vejo de forma positiva a possibilidade de submeter para outro repositório OCA já que deste modo podemos garantir uma qualidade até maior considerando que outras pessoas poderiam ajudar na revisão e critica.

@felipemotter
Copy link
Contributor

felipemotter commented Mar 30, 2022

Fala @mbcosta !!! Essa é uma funcionalidade bem interessante, mas muitas vezes não necessário.

-Usabilidade:
Acredito que uma forma interessante de implementar os múltiplos modos de pagamento sem tornar o cadastro repetitivo, seria ter a opção de cadastrar ou não um modo de pagamento para cada linha dos termos de pagamento. Conversando com o @netosjb acreditamos que teria duas opções nesse sentido:

  1. Caso o campo do modo de pagamento na linha dos termos esteja vazio, ele sempre pegará o padrão da fatura. Do outro lado, se preenchido ele usará o modo especificado. Vantagens: direto e simples.
  2. Colocar na linha do termo de pagamento um booleano se a parcela terá um modo específico ou pegará o padrão da invoice, caso específico é ativado o field para selecionar o modo. Vantagens: para usabilidade, isso deixa mais visível e intuitivo para o usuário.

Além disso, o usuário poderia alterar esse modo de pagamento diretamente nas linhas dos recebíveis para os casos específcos. Acredito que dessa forma pode haver uma harmonia com a forma básica que já existe e vai trazer uma dinâmica bem ampla para qualquer caso que exista.

O caso dos relatórios, eu não sei exatamente como poderíamos lidar com isso, mas pode caber algum tratamento, porque fazendo da forma a cima, o campo de modo de pagamento na fatura seria um referencial para os termos e não necessariamente uma informação efetiva.

Também acho interessante isso ser um modo específico, porque acredito não ser necessário para muitas empresas.

Repositório:
Faço das suas palavras as minhas.

Forma automática na nfe:
Apesar de não lidar com múltiplos modos de pagamentos, fizemos a PR #1640 com um módulo específico para isso, ele é simples mas é o que estamos usando. Quebra um bom galho. Aliás, acho que valeria um merge, estamos dispostos a fazer modificações caso necessário.

@marcelsavegnago
Copy link
Member

marcelsavegnago commented Mar 31, 2022

@felipemotter vcs estão levando em consideração os multiplos modos de pagamento sendo informados no pedido de vendas e ordem de compra também ?

@felipemotter
Copy link
Contributor

Ele só lida com modo de pagamento único. O que falo é a forma automática de por a informação de pagamento na NF-e.

@rvalyi
Copy link
Member

rvalyi commented Mar 31, 2022

tb acho importante jogar isso para um modulo opcional, porque é o tipico de coisa que muda da v12 para a v14 e que se ficar dentro do modulo account iria atrapalhar a migração do caso que interessa 95% do pessoal.

@github-actions
Copy link

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Aug 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement stale PR/Issue without recent activity, it'll be soon closed automatically.
Projects
None yet
Development

No branches or pull requests

4 participants