[14.0][ADD] New module l10n_br_cnab_structure #2168
Conversation
|
@netosjb aqui talvez seja interessante deixar o campo editavel para poder informar o campo sem precisar entrar no wizard.
|
|
Faltou rodar o pre-commit ? |
ah na verdade naquele momento eu não tava no modo edição, mas esse campo é permitido escrever diretamente nele sim, o que faltou foi por um invisible no botão do wizard quando não tiver no modo de edição 😅 |
Não entendi tbm, depois vou revisar isso, mas usei o pre-commit localmente, depois que as outras PR dependente forem aprovadas focamos os esforços aqui para deixar tudo verdinho. Por enquanto que a PR está em rascunho a ideia apenas para demostrar o conceito do módulo. Essa PR ela fica quebrada, não dá de testar no runboat pois ela depende de mais 3 PRs, mas para fim de testes, vou abrir mais uma PR que agrega todas as outras, que ai assim vai ser possível os testes funcionais. |
antoniospneto
force-pushed
the
14.0-cnab-structure
branch
from
8addc88 to
0fcec8a
Compare
| start_pos, end_pos = self._get_conf_positions_240() | ||
| return line[start_pos[conf_field] : end_pos[conf_field]] | ||
|
|
||
| def _get_lines_from_file(self, file): |
There was a problem hiding this comment.
É coisa boba, mas esse parametro file aqui não é desnecessário? Visto que ele é sobrescrito já na primeira linha do método.
There was a problem hiding this comment.
boa @hirokibastos, realmente não tem necessidade, vamos ajustar.
|
@felipemotter @antoniospneto parabéns pelo trabalho, obrigado pelo vídeo explicando o PR, interessante a forma que vocês abordaram o problema e bem interessante o visualizador de TXT, mas é preciso dizer que a forma de implementação do CNAB na OCA vem sendo discutida, pelo o que vi e lembro, desde de 2015 e em 2017 houve um encontro da comunidade onde isso foi debatido, alguns queriam colocar nos módulos da localização o código que faria o mapeamento de cada CNAB ( https://github.com/odoo-brazil/odoo-brazil-banking/tree/8.0/l10n_br_account_banking_payment_cnab/febraban https://github.com/odoo-brazil/odoo-brazil-banking/blob/8.0/l10n_br_cnab_import/file_cnab240_parser.py ) e outros queriam usar bibliotecas externas, pelo o que lembro a primeira opção foi rejeitada porque seria melhor ter a implementação do CNAB "encapsulada" em uma biblioteca especifica, algo parecido com o CEP, NFe, etc; isso resulta em menos código na localização por ser necessário apenas um modulo que na medida do possível é simples e pequeno para integrar essa lib X; alterações, manutenções e atualizações ficam restritas a partes especificas e separadas do código, o que ajuda na gestão do repositório e isso atende o conceito de modularizarão, uma atualização de uma biblioteca especifica não afeta diretamente o repositório da localização e uma lib em python ou ruby ou outra linguagem em teoria pode ter mais contribuidores do que algo especifico do Odoo, também ficou definido que Localização deve permitir a possibilidade de uso de mais de uma biblioteca para o CNAB, a partir disso acredito que além da funcionalidade em si a arquitetura passou a ser também parte da especificação. No vídeo vocês comentam sobre a possibilidade de juntar Bank Lines, isso foi evitado no CNAB pelo menos o de Cobrança até agora porque essas linhas e a payment.lines representam as linhas do CNAB onde cada uma tem um numero sequencial, acredito que o melhor é deixar isso como espelho do arquivo gerado mantendo a separação se esse for o caso do arquivo, até por motivo de rastreabilidade( lembro que havia uma recomendação mesmo no account_payment_order para não juntar as linhas quando o campo communication_type fosse do tipo "Estruturado", pelo o que entendo um comunicação que segue uma sequencia ), mas é importante ouvir vocês sobre isso. Vi que na importação do arquivo existe um fluxo de Aprovação, eu gostaria de entender o que os levou a não importar de uma vez, se tem algo que precisa ser feito ou verificado nesse momento? O wizard que existia antes também era dessa forma porém no BRCobranca acabei decidindo alterar e importar de uma vez o aquivo sem fluxo, por uma questão de usabilidade diminuindo a quantidade de cliques para realizar uma tarefa mas principalmente por uma questão levantada de possibilidade de Fraudes, o que nos levou a pensar no que pode ser feito na implementação para evitar ou se possível não permitir ou ao menos registar tudo que possa ser usado para realização de fraudes, como vocês viram o CNAB é algo antigo que usa simples arquivos TXT e alguém com acesso pode altera-los, existem formas de proteger o arquivo fora do Odoo com pastas do tipo Somente Leitura/readonly, mas como o repositório é publico e terceiros podem estar usando é importante alertar sobre o problema tanto para a OCA , desenvolvedores do projeto e a comunidade se prevenirem de possíveis acusações de BUGs ou Falhas que podem vir a facilitar possíveis fraudes quanto esses terceiros/desenvolvedores ou mesmo "usuário funcional com um bom conhecimento técnico e pouca experiência python" entenderem a responsabilidade envolvida já que em casos onde é descoberta uma fraude existe uma cadeia de responsabilidades legais onde cada um responde por ação ou omissão, entendo a ideia de facilitar a implementação via tela do odoo mas é preciso deixar claro que como qualquer trabalho existe um grau de responsabilidade envolvido, principalmente no caso de comunicação com Banco, acredito que isso precisa estar claro para todos os desenvolvedores até para eles se protegerem de acusações de cooperação ou conivência nesses casos, por isso foi incluído em determinados campos de configuração do CNAB o parâmetro Tracking para assim registrar quem é quando fez uma determinada alteração para em caso de uma auditoria ou investigação seja possível rastrear as responsabilidades de cada um, também foi colocado um aviso no README sobre um problema que esse parâmetro tem em não registrar alterações nos campos do tipo Many2many e a recomendação para usar um modulo que corrigi essa falha já que é justamente o campo que define os Códigos de Retorno que devem gerar Baixas/Liquidações https://github.com/OCA/l10n-brazil/blob/14.0/l10n_br_account_payment_order/readme/CONFIGURE.rst. Sobre isso é importante destacar que na forma como vocês estão implementando se for preciso atender essa questão de monitorar campos importantes do CNAB vocês terão que incluir ou mail.tread e o parâmetro Tracking ou devido a quantidade de campos incluir a dependência do modulo auditlog https://github.com/OCA/server-tools/tree/14.0/auditlog e incluir arquivos data configurando esse modulo, e aqui existe uma vantagem na implementação que "encapsula" uma biblioteca porque dessa forma uma alteração no padrão dos arquivos CNAB é muito mais difícil de ser feita, alguém mal intencionado teria que ter o acesso ao servidor que roda a aplicação o que não é comum e entre Usabilidade X Segurança/Consistência de Dados eu acredito que o melhor é optar por Segurança/Consistencia de Dados. Nesse encontro da comunidade em 2017 eu não conhecia bem o CNAB e nem as possíveis formas de implementa-lo na OCA e por isso apenas acompanhei o debate e não pude ajudar, a partir de 2018, orientado pelo @rvalyi e o @renatonlima , eu passei a ver e trabalhei no sentido de atender as especificações acima para deixar os módulos que existiam no repositório odoo-brazil-banking genéricos sem uma ligação direta com uma Lib ou código especifico de um CNAB dentro dos módulos( https://github.com/odoo-brazil/odoo-brazil-banking/pulls?q=is%3Apr+author%3Ambcosta+is%3Aclosed odoo-brazil/odoo-brazil-banking#68 ) e foi feito algo funcional mas a implementação do BRCobranca estava fora da OCA (https://github.com/akretion/odoo-boleto-cnab/tree/8.0 ), somente a partir de Junho de 2020 eu passei a ver com mais profundidade visando atender todas as especificações e assim incluir o modulo na OCA, gastei mais tempo do que o esperado e muitas vezes que achei estar próximo de terminar aparecia alguma nova variável que alterava a estrutura e era preciso repensar partes da implementação, o problema do CNAB é a falta de padrão entre eles, por isso para evitar que outras pessoas gastem horas/dias/meses eu me coloco a disposição de vocês ou outras pessoas que queiram implementar o CNAB na OCA para conversar via RFC ou mesmo marcar uma vídeo conferencia( agendando antecipadamente ) para explicar o que foi feito e como abordar essa implementação do CNAB dentro da OCA. Minha conclusão é que como no passado a ideia de incluir a estrutura do CNAB diretamente nos módulos na Localização OCA foi recusada e a diferença que vejo é que vocês estão colocando isso na tela como cadastro e com arquivos Data ( https://github.com/Engenere/l10n-brazil/blob/14.0-cnab-structure/l10n_br_cnab_structure/data/l10n_br_cnab.line.field.csv ) ao invés de colocar no código como havia sido feito no odoo-brazil-banking ( https://github.com/odoo-brazil/odoo-brazil-banking/blob/8.0/l10n_br_account_banking_payment_cnab/febraban/cnab_240/cnab_240.py https://github.com/odoo-brazil/odoo-brazil-banking/blob/8.0/l10n_br_account_banking_payment_cnab/febraban/cnab_240/bancos/itau.py )e vendo que o Processador do CNAB foi chamado "OCA Processor" acredito que revisão será a mesma que foi feita no passado e o PR vai acabar sendo recusado e recomendado a integração com uma biblioteca existente ou nova, o que é o que hoje eu também penso devido os pontos já falados, mas claro vocês podem argumentar e buscar convencer os PSCs e outros desenvolvedores sobre o porque isso deveria ser revisto e o PR aprovado. Gostaria de pedir desculpas a vocês porque acredito que o README do l10n_br_account_payment_order deveria explicar melhor essa questão e pretendo incluir algo para tornar isso mais claro, todo esse debate acabou ficando restrito a um pequeno grupo de pessoas e penso que uma conversa em um RFC ou uma conversa informal de uma ou duas horas poderiam ter esclarecido diversas dúvidas de vocês e poupado horas/dias de desenvolvimento, por isso como escrevi acima estou a disposição para falarmos via vídeo conferencia, o CNAB de Pagamento é algo pendente que acredito que todos gostariam que seja incluído na Localização. Se efetivamente a proposta for recusada as recomendações que posso fazer são as seguintes:
Python PHP NodeJS Eu recomendaria buscar incluir no BRCobranca, acredito que o Kivanio não irá recusar um PR nesse sentido, vocês já atualizaram o Banco AILOS conhecem a estrutura tanto da API quanto dos módulos na OCA e na API podemos colocar um repo Fork enquanto o código não for integrado no repo principal, além de fortalecer essa biblioteca que já é usada dentro da OCA, mas essa decisão cabe a vocês, se seguirem nesse caminho existe um repo que parece ser um fork do BRCobranca feito a uns 7 anos atras mas que parece ter a estrutura e o código em ruby do SISPAG do Itau no 240 talvez ajude a ver como pode ser feito https://github.com/eduardordm/cnab240 . |
Olá pessoal, esse é o nosso módulo para comunicação entre a empresa e o banco usando arquivos CNAB, de início focado apenas para pagamentos a terceiros e usando CNAB 240. Apesar do foco inicial, a estrutura já foi pensada para usar outros formatos CNAB e também para em um futuro talvez ser uma alternativa ao BRCobrança.
Como o BRCobrança não atenderia as necessidades dos pagamentos a terceiros, teríamos que elaborar uma ferramenta diferente. Assim surgiu a ideia de fazer algo que permitisse a configuração de qualquer banco ou serviço diretamente pela view. As vantagens ao abordar o CNAB dessa forma são:
Como é um módulo denso, achamos que um vídeo ajudaria a entender melhor o módulo, portanto praticamente todo o processo de configuração e usabilidade está demonstrado a seguir: https://www.youtube.com/watch?v=ljommELunlA
Toda a base do módulo foi testada e elaborada implementando o SISPAG do Itaú, que é baseado em CNAB 240. Já estão incluídas as transferências via PIX e TED. ( testado e homologado junto ao banco)
Existem algumas coisas a serem melhoradas, mas para uma versão inicial achamos que já é uma funcionalidade interessante para a localização. Essa já é uma versão utilizável e não apenas uma POC, faltando apenas os testes, mas para isso gostaríamos de uma análise da comunidade antes de fazê-los. Qualquer sugestão ou ajuda com o código é bem vinda.
O nome do módulo está em aberto, esse foi só o que a gente achou que se encaixa melhor.
Depende das PRs #2147 #2156 e #2158
Iremos comentar sobre a escolha do payment_way em breve, mas queríamos postar o quanto antes o módulo.
Fizemos a PR #2170 completa com todas as dependências junto para ser possível fazer testes funcionais pelo runboat.
cc @marcelsavegnago @rvalyi @douglascstd @mbcosta @renatonlima @mileo