-
-
Notifications
You must be signed in to change notification settings - Fork 248
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
Comments
@mbcosta não sei se serve de referencia mas achei este módulo Tem na versão 15.0 tbm |
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. |
Fala @mbcosta !!! Essa é uma funcionalidade bem interessante, mas muitas vezes não necessário. -Usabilidade:
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: Forma automática na nfe: |
@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 ? |
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. |
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. |
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. |
Existe a possibilidade de criar uma Nota Fiscal com múltiplos Modos/Meios de Pagamentos exemplo:
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
The text was updated successfully, but these errors were encountered: