Skip to main content

Brazilian Payment Order

Beta License: AGPL-3 OCA/l10n-brazil Translate me on Weblate Try me on Runboat

O modulo implementa a parte comum da infra-estrutura necessária para o uso do CNAB 240 ou 400 localizando o modulo https://github.com/OCA/bank-payment/tree/12.0/account_payment_order onde o Modo de Pagamento é usado para as configurações especificas de cada CNAB e a Ordem de Pagamento para o envio de Instruções CNAB, também é incluído grupos de acesso para permissões de segurança e o registro do LOG de retorno. Porém a implementação foi pensada para permitir que seja possível usar diferentes bibliotecas para gerar e tratar o retorno do CNAB, por isso é preciso instalar um segundo modulo que vai ter essa função, portanto a ideia é que aqui estará tudo que for comum para a implementação mas não irá funcionar sem esse segundo modulo.

Table of contents

Installation

This module depends on:

  • l10n_br_base

  • account_payment_order

  • account_due_list

  • account_cancel

Configuration

Verifique se o Banco e o tipo CNAB usado 240 ou 400 possuem os Códigos de Instrução do Movimento e os Códigos de Retorno do Movimento em:
  • Faturamento > Configurações > Administração > CNAB Código de Movimento de Instrução

  • Faturamento > Configurações > Administração > CNAB Código de Retorno do Movimento

Caso seja preciso cadastrar por favor considere fazer um PR nesse modulo acrescentando em l10n_br_account_payment_order/data/cnab_codes/banco_X_cnab_Y_Z.xml assim em proximas implementações já não será preciso cadastra-los.

Informe os dados do CNAB usado no cadastro do:

  • Faturamento > Configurações > Administração > Modos de Pagamento

Verifique as permissões de acesso dos usuários que vão utilizar o CNAB, existe o Usuário e o Gerente CNAB.

IMPORTANTE: Como o CNAB envolve dinheiro e o caixa da empresa a segurança e a rastreablidade são fundamentais e como as configurações especificas de cada CNAB estão no Modo de Pagamento/account.payment.mode foi incluído nele o objeto mail.thread que registra alterações feitas em campos importantes, porém campos many2many não estão sendo registrados pelo track_visibility( ver detalhes aqui l10n_br_account_payment_order/models/account_payment_mode.py#L59), e um campo especifico e importante que armazena os Codigos de Retorno do CNAB que devem gerar Baixa/Liquidação é desse tipo, portanto as alterações referentes a esse campo não estão sendo registradas. No repositorio https://github.com/OCA/social/tree/12.0 da OCA existe um modulo para corrigir isso o https://github.com/OCA/social/tree/12.0/mail_improved_tracking_value , por isso considere e é RECOMENDADO incluir esse modulo na implementação para corrigir esse problema. A inclusão da dependencia desse modulo aqui está pendente de aprovação.

Usage

Ao criar uma Fatura/account.invoice que tem um Modo de Pagamento do tipo CNAB e se o campo auto_create_payment_order estiver marcado as linhas referentes as Parcelas serão criadas automaticamente em uma nova Ordem de Pagamento ou adicionadas em uma já existente que esteja no estado Rascunho, também é possível incluir manualmente, a geração do arquivo e o tratamento do arquivo de retorno dependem da instalação de um segundo modulo onde é definida a biblioteca a ser utilizada.

Known issues / Roadmap

  • Verificar a questão do campos many2many que não estão sendo registrados pelo track_visibility e se será incluída a dependendecia https://github.com/OCA/social/tree/12.0/mail_improved_tracking_value ( confirmar o problema na v14 ).

  • Processo de Alteração de Carteira, falta informações sobre o processo.

  • Mapear e incluir os codigos dos bancos de cada CNAB 240 / 400, aqui devido a quantidade de possibilidades se trata de um “roadmap” constante onde contamos com PRs de outros contribuidores que irão implementar um caso que ainda não esteja cadastrado, apesar do codigo permitir que o cadastro seja feito na tela nesses casos.

  • Processo de “Antecipação do Título junto ao Banco” ou “Venda do Título junto a Factoring” ver as alterações feitas na v14 https://www.odoo.com/pt_BR/forum/ajuda-1/v14-change-in-payment-behavior-how-do-the-suspense-and-outstanding-payment-accounts-change-the-journal-entries-posted-177592 .

  • Com a separação do método que importa o arquivo do que registra o retorno do CNAB os arquivos e visões referentes foram comentados e estão aguardando um retorno da KMEE a respeito se serão apagados, extraidos para outro modulo, ou se de alguma forma deverão ser integrados ( detalhes em l10n_br_account_payment_order/models/__init__.py#L18 l10n_br_account_payment_order/__manifest__.py#L47 )

  • Confirmar a necessidade de ter a definição da Sequencia do “Nosso Numero” em três lugares diferentes:
    • Cadastro da Sequencia no cadastro da Empresa, o campo é o mesmo usado no Modo de Pagamento porém nesse caso só funciona se a empresa usar apenas um CNAB, caso passe a usar mais de um essa informação vai precisar ser movida de qualquer forma para o cadastro do Modo de Pagto, portanto não seria melhor deixar apenas a opção de informar isso no Modo de Pagto e remover essa opção no cadastro da Empresa ?

    • Numero Sequencial baseado no número da Fatura, até onde foi visto a sequencia do “Nosso numero” é independente da sequencia da Fatura, alguém sabe dizer se existe esse caso de uso ? Se sim, seria importante ter uma referencia sobre a qual caso se refere ex.: Banco X CNAB 240 e assim ficar claro para outros desenvolvedores o uso.

    • Cadastro no Modo de Pagto, deve ser mantido e é melhor ser feito apenas aqui para centralizar o cadastro e por segurança devido as permissões de acesso o usuário que pode cadastrar um Modo de Pagto pode não ter acesso ao cadastro da Empresa.

  • CNAB de Pagamento, verificar a integração com o PR https://github.com/OCA/l10n-brazil/pull/972 e a possibilidade de multiplos modos de pagamento na mesma Ordem de Pagamento https://github.com/odoo-brazil/l10n-brazil/pull/112

  • Verificar a possibilidade na v14 de remoção do ondele=’restrict’ no campo “move_line_id” e o campo “related” “ml_maturity_date” do account.payment.line no modulo dependente https://github.com/OCA/bank-payment/blob/14.0/account_payment_order/models/account_payment_line.py#L39 para permitir o processo de Cancelamento de uma Fatura quando existe uma Ordem de Pagamento já confirmada/gerada/enviada( detalhes l10n_br_account_payment_order/models/account_payment_line.py#L130 )

  • Funcionalidade de Agrupar Por/Group By não funciona em campos do tipo Many2Many, aparentemente isso foi resolvido na v15(verfificar na migração), isso é usado nos objetos referentes aos Codigos CNAB de Instrução e Retorno.

  • Confirmar se existem Bancos que usam os mesmos conjuntos de Codigos CNAB de Instrução e Retorno para caso não existir remover o many2many do Banco e deixar apenas o many2one.

Changelog

8.0.0.0.0 (2016-01-18)

  • [NEW] Primeira versão

8.0.1.0.0 (2017-07-14)

  • [NEW] Melhorias para suportar a geração de pagamento da folha de pagamento;

8.0.1.0.1 (2017-07-14)

  • [NEW] Refatoração e melhorias para suportar a geração de boletos através do br-cobranca (ruby)

10.0.1.0.0 (2018-08-29)

  • [MIG] Migração para a versão 10.

10.0.2.0.0 (2018-05-17)

  • [REF] Modulo unido com o l10n_br_account_payment_mode e renomeado para l10n_br_account_payment_order.

12.0.1.0.0 (2019-06-06)

  • [MIG] Inicio da Migração para a versão 12.0.

12.0.3.0.0 (2021-05-13)

  • [MIG] Migração para a versão 12.0.

  • Incluído a possibilidade de parametrizar o CNAB 240 e 400, devido a falta de padrão cada Banco e CNAB podem ter e usar codigos diferentes.

  • Incluído os metodos para fazer alterações em CNAB já enviados.

  • Incluído dados de demo e testes.

  • Separado o objeto que fazia o Retorno do arquivo e registrava as informações para ter um objeto especifico que registra o Log e assim os modulos que implementam a biblioteca escolhida podem ter um metodo/objeto especifico para essa função.

Bug Tracker

Bugs are tracked on GitHub Issues. In case of trouble, please check there if your issue has already been reported. If you spotted it first, help us to smash it by providing a detailed and welcomed feedback.

Do not contact contributors directly about support or help with technical issues.

Credits

Authors

  • KMEE

  • Akretion

Contributors

Other credits

The development of this module has been financially supported by:

  • KMEE INFORMATICA LTDA - www.kmee.com.br

  • AKRETION LTDA - www.akretion.com

Maintainers

This module is maintained by the OCA.

Odoo Community Association

OCA, or the Odoo Community Association, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.

This module is part of the OCA/l10n-brazil project on GitHub.

You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.

Metadata

Release files for odoo12-addon-l10n-br-account-payment-order 12.0.9.1.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Built distribution (wheel)

Table of built distributions (wheels) for odoo12-addon-l10n-br-account-payment-order 12.0.9.1.1
File Interpreter ABI Platform Actions
odoo12_addon_l10n_br_account_payment_order-12.0.9.1.1-py3-none-any.whl Python 3 none any Details for odoo12_addon_l10n_br_account_payment_order-12.0.9.1.1-py3-none-any.whl

Release files / odoo12_addon_l10n_br_account_payment_order-12.0.9.1.1-py3-none-any.whl

Download URL odoo12_addon_l10n_br_account_payment_order-12.0.9.1.1-py3-none-any.whl
Size 175.1 kB
Tags Python 3
SHA-256 checksum
How to use checksums
980a9d71d67a7fead24e962ca6f84d4eb1b3978ed4b1fc70316f7b5c59cb6521
BLAKE2b-256 checksum
How to use checksums
b3f436bf1b683ed6b783715c14dff1b231c50309c82c81649dc1b2cb374868c2
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/5.1.1 CPython/3.12.3

Security for odoo12-addon-l10n-br-account-payment-order 12.0.9.1.1

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Release history Release notifications | RSS feed

This release

12.0.9.1.1 This release

1 release file No provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page