OCA / l10n-brazil

Localização brasileira oficial do Odoo.
https://odoo-community.org/psc-teams/brazil-66
GNU Affero General Public License v3.0
237 stars 243 forks source link

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

Closed mbcosta closed 12 months ago

mbcosta commented 2 years ago

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 https://github.com/odoo-brazil/l10n-brazil/pull/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:

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 commented 2 years ago

@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 commented 2 years ago
  • 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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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[bot] commented 1 year ago

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.