Feature/cnab multiple payments

[mileo]

Descrição do problema/nova funcionalidade deste Pull Resquest(PR):

Comportamento atual antes do PR:

Comportamento esperado depois do PR:

• Esta mudança não altera a estrutura do banco de dados, portanto não precisa de script de migração.

--
Eu confirmo que eu assinei a CLA e li as recomendações de como contribuir:

• https://odoo-community.org/page/cla
• https://odoo-community.org/page/Contribute

[mbcosta]

ola @mileo @gabrielcardoso21

Acredito que o que levou a esse PR seria a seguinte situação:
"Por exemplo a empresa XPTO tem os seguintes pagamentos a realizar hoje:

1. BOLETO: Lojas.com
2. Pagamento Salário: Fulano
3. DAS: referente ao mês anterior
4. Outra conta da empresa "TED mesma titularidade
5. TED: Para pró-labore do sócio Fulano.
6. GPS: Referente a folha

Na modelagem atual seriam 6 ordens de pagamento, 6 arquivos de remessa.
Fica inviável de usar.
"

Pelo que vi aqui vocês criaram uma forma de agrupar tudo o que é referente ao Pagamento criando um Modo de Pagamento/account.payment.mode que possui dentro o TED, DAS, ISS e Pagamento de Utilitário para que assim seja criada uma Ordem de Pagto única. Achei ruim a implementação basicamente porque dentro de um Modo de Pagamento foi criado um novo objeto account.payment.mode.line que possui os campos name e payment_mode_id, quer dizer que dentro de um Modo de Pagto existem outros Modos de Pagtos, algo que não parece fazer sentido e pode ser confuso de explicar até para o usuário final, acredito que pode existir uma solução melhor, por isso gostaria de fazer algumas perguntas:

Inicialmente pensei que a necessidade seria criar um arquivo de remessa único com as 6 formas mas pelo o que foi feito parece que a necessidade seria apenas de juntar os referentes aos pagamentos (TED, DAS, ISS e Pagamento de Utilitário) sem a necessidade de ter a Cobrança junto na criação do arquivo de Remessa com Lote, seria isso ?

As remessas de Pagamentos são criadas diretamente na tela de Ordem de Pagamento sem um "documento de origem" ( como no caso da cobrança onde a Fatura gera as Linhas da Ordem de Pagto ) e até por isso vocês viram a necessidade de unifica-los e assim facilitar para o usuário final que vai criar apenas uma Ordem de Pagamento ?

Uma possível sugestão que tenho por enquanto baseado no que foi feito seria usar o os campos Code e Payment Type do objeto account.payment.method relacionado para fazer um "domain" e tornar visíveis ou invisíveis os campos referentes a Cobrança/CNAB 240 e 400/inbound ou ao CNAB 240 de Pagto/outbound "limpando" a tela ao deixar apenas os campos específicos de cada um e nesse caso incluindo os campos referentes a TED, DAS, ISS e Pagamento de Utilitário e etc para serem parametrizados, isso é dentro de apenas um Modo de Pagto estariam os campos para configurar o TED, DAS, ISS e Pagamento de Utilitário e etc; seria preciso incluir um campo de tipo Seleção nas linhas de Ordem de Pagto quando fosse o caso do CNAB 240 de Pagto/outbound para permitir a Seleção e identificação de quando é um TED, DAS, ISS e Pagamento de Utilitário e etc, o que vocês pensam sobre isso ?

Algo a se considerar também é se não poderia ser um problema agregar todos essas formas em um único Modo de Pagamento, tanto na solução feita no PR quanto na minha sugestão, por exemplo na utilização de relatórios padrões ou herdados que usam o campo Modo de Pagamento.

cc @renatonlima @rvalyi

[mileo]

ola @mileo @gabrielcardoso21

Acredito que o que levou a esse PR seria a seguinte situação:
"Por exemplo a empresa XPTO tem os seguintes pagamentos a realizar hoje:

1. BOLETO: Lojas.com
2. Pagamento Salário: Fulano
3. DAS: referente ao mês anterior
4. Outra conta da empresa "TED mesma titularidade
5. TED: Para pró-labore do sócio Fulano.
6. GPS: Referente a folha

Na modelagem atual seriam 6 ordens de pagamento, 6 arquivos de remessa.
Fica inviável de usar.
"

Pelo que vi aqui vocês criaram uma forma de agrupar tudo o que é referente ao Pagamento criando um Modo de Pagamento/account.payment.mode que possui dentro o TED, DAS, ISS e Pagamento de Utilitário para que assim seja criada uma Ordem de Pagto única. Achei ruim a implementação basicamente porque dentro de um Modo de Pagamento foi criado um novo objeto account.payment.mode.line que possui os campos name e payment_mode_id, quer dizer que dentro de um Modo de Pagto existem outros Modos de Pagtos, algo que não parece fazer sentido e pode ser confuso de explicar até para o usuário final, acredito que pode existir uma solução melhor, por isso gostaria de fazer algumas perguntas:

Inicialmente pensei que a necessidade seria criar um arquivo de remessa único com as 6 formas mas pelo o que foi feito parece que a necessidade seria apenas de juntar os referentes aos pagamentos (TED, DAS, ISS e Pagamento de Utilitário) sem a necessidade de ter a Cobrança junto na criação do arquivo de Remessa com Lote, seria isso ?

Sim, a cobrança não precisa estar necessariamente junto. A ideia é que o fluxo de pagamentos saída seja unificado.

As remessas de Pagamentos são criadas diretamente na tela de Ordem de Pagamento sem um "documento de origem" ( como no caso da cobrança onde a Fatura gera as Linhas da Ordem de Pagto ) e até por isso vocês viram a necessidade de unifica-los e assim facilitar para o usuário final que vai criar apenas uma Ordem de Pagamento ?

Pare esta prova de conceito sim, mas em um segundo momento as informações deverão vir de outros módulos do sistema, como por exemplo a fatura.

Uma possível sugestão que tenho por enquanto baseado no que foi feito seria usar o os campos Code e Payment Type do objeto account.payment.method relacionado para fazer um "domain" e tornar visíveis ou invisíveis os campos referentes a Cobrança/CNAB 240 e 400/inbound ou ao CNAB 240 de Pagto/outbound "limpando" a tela ao deixar apenas os campos específicos de cada um e nesse caso incluindo os campos referentes a TED, DAS, ISS e Pagamento de Utilitário e etc para serem parametrizados, isso é dentro de apenas um Modo de Pagto estariam os campos para configurar o TED, DAS, ISS e Pagamento de Utilitário e etc; seria preciso incluir um campo de tipo Seleção nas linhas de Ordem de Pagto quando fosse o caso do CNAB 240 de Pagto/outbound para permitir a Seleção e identificação de quando é um TED, DAS, ISS e Pagamento de Utilitário e etc, o que vocês pensam sobre isso ?

Sim, foi isso que implementamos, entretanto a visão ainda não foi customizada para cada caso.

Algo a se considerar também é se não poderia ser um problema agregar todos essas formas em um único Modo de Pagamento, tanto na solução feita no PR quanto na minha sugestão, por exemplo na utilização de relatórios padrões ou herdados que usam o campo Modo de Pagamento.

cc @renatonlima @rvalyi

[mbcosta]

ola @mileo

"Sim, foi isso que implementamos, entretanto a visão ainda não foi customizada para cada caso." A sugestão que fiz seria sem o objeto account.payment.mode.line e a necessidade de ter Modos de Pagamento dentro de um Modo de Pagamento.

Mas como a resposta sobre o "documento de origem" foi "Pare esta prova de conceito sim, mas em um segundo momento as informações deverão vir de outros módulos do sistema, como por exemplo a fatura." é isso seria incluir dois Modos de Pagamentos a serem selecionados pelo usuário o Modo Principal e a linha que seria outro Modo de Pagamento ou !?!? o mesmo !?!?! ( ex.: no caso Cheque e !?!? Cheque !?!? ou Boleto X e !?!? Boleto X !?!? ), algo que parece não fazer muito sentido escolher dois modos de pagamentos, por isso eu acredito que podemos tentar abordar o problema de outra forma:

Minha sugestão seria criar no Diário/Account Journal ( acredito que em comum todos esses Modos de Pagamento devem usar o mesmo Diário ) um boolean ex.: "Gerar Arquivo de Remessa com Lotes", quando a opção estiver marcada ao criar uma nova Ordem de Pagamento também seria criado um novo objeto ex.: CNAB.REMESSA.LOTES em uma estrutura semelhante ao que existia na importação l10n_br.cnab/l10n_br.lote/l10n_br.evento mas nesse caso seria ESSE_NOVO_OBJETO/payment.order/payment.order.line assim as linhas desse novo objeto seriam as Ordens de Pagamento, isso ficaria transparente ao usuário, ele poderia acessar pelo menu apenas esse novo objeto, seria preciso sobre escrever os métodos de mudanças de status na Ordem de Pagamento e criar um campo/link/one2many para redirecionar para esse novo objeto, aparentemente isso parece atender o problema e juntaria tantos os boletos quanto os pagamento sem a necessidade de grandes alterações em objetos,métodos e visões herdadas. O que vocês pensam sobre isso ?

[gabrielcardoso21]

@mbcosta, bom dia.

Obrigado pelas sugestões, o que você disse faz bastante sentido. Penso que não é realmente necessário criar um novo objeto para o arquivo com mais de um lote do CNAB 240, visto que a única diferença do agrupamento é que se colocam mais lotes dentro do mesmo arquivo. Essa diferenciação pode confundir o usuário e acabar atrapalhando ao invés de ajudar. Sobre a eliminação do account.payment.mode.line, concordo que a nomenclatura do modelo pode levar a confundir os conceitos, e aceito sugestões de mudança. Continuo preferindo, porém, que o modelo com essa função continue existindo, pois essa abstração pode ser usada em outros casos para resolver problemas similares. Sugiro também que seja incluído no modelo um campo many2many com o modelo ir.model.fields, com o domínio filtrando os campos da linha de pagamento, para que se possa escolher dinamicamente quais campos esconder se esse tipo de pagamento for selecionado.

[mbcosta]

ola @gabrielcardoso21 , alterar a nomeclatura do objeto account.payment.mode.line não vai alterar o fato de que dentro dele ser feita uma ligação com outro account.payment.mode https://github.com/odoo-brazil/l10n-brazil/blob/feature/cnab-multiple-payments/l10n_br_account_payment_order/models/account_payment_mode_line.py#L17 o que significa ter dentro de um Modo de Pagamento outros Modos de Pagamentos.

"Continuo preferindo, porém, que o modelo com essa função continue existindo, pois essa abstração pode ser usada em outros casos para resolver problemas similares. " Quais ?

Tenho outra sugestão para resolver esse problema que acredito que vai atender as especificações:

• Criar um campo ex.: cnab_lot do tipo Boolean dentro do objeto account.payment.mode ( melhor do que dentro do Diário como havia sugerido antes por permitir diferentes configurações )

• Criar um campo ex.: lot_payment_mode_ids do tipo many2many dentro do objeto account.payment.order

• Criar um campo ex.: payment_mode_id do tipo many2one dentro do objeto account.payment.line ( e outros "related" com o "store=True" que precisem ser registrados )

• Quando for criada uma Ordem de Pagamento e o Modo de Pagto tiver marcado com o campo boolean deixamos invisível o campo payment_mode_id ( original do modulo account_payment_order ) no account.payment.order e visível o campo lot_payment_mode_ids mostrando na visão/tela ao usuário que aquela Ordem de Pagto é composta de mais de um Modo de Pagto e na criação da linha/account.payment.line preenchemos o payment_mode_id do objeto account.payment.line

• Ao criar essa nova Ordem o programa deverá buscar se já existe alguma com o mesmo Diário/account.journal e com o Modo de Pagto com o boolean preenchido( acredito que também será preciso usar como filtro o Metodo de Pagto, a confirmar, pois isso fará com que não seja possível unificar as Cobrança/Ordens de Débito com os Pagamentos/Ordens de Credito ), se sim será apenas adicionado na Ordem de Pagmento existente o Modo de Pagamento no campo many2many e na criação da account.payment.line o campo payment_mode_id podendo assim diferenciar os Modos de Pagamento

Dessa forma teremos seis Modos de Pagamentos porém somente uma Ordem de Pagamento e um arquivo de Remessa, o que pensam sobre isso ?

[gabrielcardoso21]

ola @gabrielcardoso21 , alterar a nomeclatura do objeto account.payment.mode.line não vai alterar o fato de que dentro dele ser feita uma ligação com outro account.payment.mode https://github.com/odoo-brazil/l10n-brazil/blob/feature/cnab-multiple-payments/l10n_br_account_payment_order/models/account_payment_mode_line.py#L17 o que significa ter dentro de um Modo de Pagamento outros Modos de Pagamentos.

"Continuo preferindo, porém, que o modelo com essa função continue existindo, pois essa abstração pode ser usada em outros casos para resolver problemas similares. " Quais ?

Tenho outra sugestão para resolver esse problema que acredito que vai atender as especificações:

• Criar um campo ex.: cnab_lot do tipo Boolean dentro do objeto account.payment.mode ( melhor do que dentro do Diário como havia sugerido antes por permitir diferentes configurações )
• Criar um campo ex.: lot_payment_mode_ids do tipo many2many dentro do objeto account.payment.order
• Criar um campo ex.: payment_mode_id do tipo many2one dentro do objeto account.payment.line ( e outros "related" com o "store=True" que precisem ser registrados )
• Quando for criada uma Ordem de Pagamento e o Modo de Pagto tiver marcado com o campo boolean deixamos invisível o campo payment_mode_id ( original do modulo account_payment_order ) no account.payment.order e visível o campo lot_payment_mode_ids mostrando na visão/tela ao usuário que aquela Ordem de Pagto é composta de mais de um Modo de Pagto e na criação da linha/account.payment.line preenchemos o payment_mode_id do objeto account.payment.line
• Ao criar essa nova Ordem o programa deverá buscar se já existe alguma com o mesmo Diário/account.journal e com o Modo de Pagto com o boolean preenchido( acredito que também será preciso usar como filtro o Metodo de Pagto, a confirmar, pois isso fará com que não seja possível unificar as Cobrança/Ordens de Débito com os Pagamentos/Ordens de Credito ), se sim será apenas adicionado na Ordem de Pagmento existente o Modo de Pagamento no campo many2many e na criação da account.payment.line o campo payment_mode_id podendo assim diferenciar os Modos de Pagamento

Dessa forma teremos seis Modos de Pagamentos porém somente uma Ordem de Pagamento e um arquivo de Remessa, o que pensam sobre isso ?

@mbcosta realmente essa solução resolve os problemas sem perdas na usabilidade. Tendo um tempo vejo se consigo implementar. Obrigado, novamente, pelas sugestões.

[mbcosta]

Qual o motivo de ter esse campo aqui ? Já que uma linha só poderá ser associada a um Payment Mode, e caso seja preciso essa informação pode ser obtida pelo campo order_id

[gabrielcardoso21]

Por causa da usabilidade. Eu não consegui uma forma de ajustar o domínio dinamicamente pelos modos de pagamento selecionados no order_id. Quando coloquei no onchange o domínio dinâmico não funcionou, e quando coloquei "[('id', 'in', order_id.payment_mode_ids)]" deu um erro de javascript. Com o campo related readonly foi o único jeito que funcionou.

[mbcosta]

Sim isso "[('id', 'in', order_id.payment_mode_ids)]" não funciona, minha pergunta tem relação com a criação da Ordem de Pagto somente através da Fatura por isso não havia entendido a necessidade de ter esse campo aqui, mas me parece que o que você fez tem relação com a questão do "documento de origem", isso é você precisa desse campo pois alguns casos seriam cadastrados diretamente na tela/objeto account.payment.order seria isso mesmo ? Como o @mileo escreveu isso "Pare esta prova de conceito sim, mas em um segundo momento as informações deverão vir de outros módulos do sistema, como por exemplo a fatura." seria importante já identificar esses casos adicionando dados de demo do que é feito através de uma Fatura/account.invoice é o que não é, até para serem usados no testes e confirmando se realmente existe o caso de cadastro direto na Ordem de Pagto, já que também será necessário sobre escrever o método create_account_payment_line do objeto account.invoice ( https://github.com/OCA/bank-payment/blob/12.0/account_payment_order/models/account_invoice.py#L67 ) para identificar quando será preciso criar uma nova Ordem de Pagto/account.payment.order ou incluir a linha em uma já existente no caso do Modo de Pagto relacionado estiver com o campo is_cnab_lot marcado.

[mbcosta]

Qual o motivo de ter esse campo aqui ? Já que uma linha só poderá ser associada a um Payment Mode, e caso seja preciso essa informação pode ser obtida pelo campo order_id

[gabrielcardoso21]

Por causa da usabilidade. Eu não consegui uma forma de ajustar o domínio dinamicamente pelos modos de pagamento selecionados no order_id. Quando coloquei no onchange o domínio dinâmico não funcionou, e quando coloquei "[('id', 'in', order_id.payment_mode_ids)]" deu um erro de javascript. Com o campo related readonly foi o único jeito que funcionou.

[mbcosta]

No caso do account.payment.line pode existir a questão de se cadastrar uma linha diretamente na tela, mas no caso do objeto bank.payment.line por ser criado automaticamente existe alguma necessidade de existir aqui ?

[mbcosta]

Ao invés de juntar esses diferentes códigos não seria melhor separa-los, criando um objeto para cada um ex.: cnab.release.form.code, cnab.service.type.code, cnab.ted.finality.code e cnab.doc.finality.code ? E assim adiciona-los nos objetos como campos sem o objeto intermediario l10n_br.cnab.configuration e tornando a própria parametrização mais clara e com menor possibilidade de erro de cadastro

[mbcosta]

ola @gabrielcardoso21 uma questão importante aqui seria se existe um padrão nesses códigos entre os bancos, até onde sei os Pagamentos só existem no CNAB 240 que em teoria seria mais padronizado, vocês encontraram diferenças desses códigos entre os bancos ? Porque se não existirem eu acredito que seria melhor deixa-los como campos do tipo Seleção, eu vi um problema semelhante no caso dos Códigos de Retorno como encontrei diferenças https://github.com/odoo-brazil/l10n-brazil/blob/12.0-mig-l10n_br_account_payment_cobranca/l10n_br_account_payment_order/data/l10n_br_cnab_return_move_code_data.xml#L5 acabei achando melhor criar um novo objeto para assim permitir novas implementações através de cadastro, seria importante identificar se isso também ocorre aqui