Reformulação de Boletos
Sugestão de Autoria de Claudemir Todo Bom
Contents
Análise do mecanismo atual de boletos
- obrigatoriedade de um convênio por conta
- códigos para geração CNAB possuem muita coisa hardcoded gerando necessidade de ajustes mesmo para quando utilizar bancos já suportados, dependendo de variações e modalidades
- jboleto teve o desenvolvimento descontinuado (o domínio jboleto.org está abandonado, inclusive)
Necessidades e Features interessantes
Implementar código que comporte as diversas nuances possíveis dos sistemas de cobrança, sendo alguns problemas:
- modalidades de cobrança (registrada, simples, impressão pelo banco);
- dígitos verificadores para "Nosso Número";
- carteiras de cobrança ( O BB possui uma "variação de carteira" );
- emissão de boletos de "bancos correspondentes";
- verificação em tabelas de CEPs das praças atendidas por cada banco (alguns bancos recusam sacados com CEPs de praças que não são atendidos por eles);
- impressão do boleto após retorno do banco;
- envio do boleto por e-mail;
- adição de informações de outras partes do sistema à página do boleto;
- emissão de guias de recolhimento de taxas (formato similar a água/luz/telefone/impostos);
Possibilidade de ter mais de um convênio por conta bancária, ou mesmo emissões em diferentes modalidades para um mesmo convênio
Ideias e alternativas
Impressão do boleto
A impressão do boleto em si não é complicada, é um simples preenchimento de campos, a maior dificuldade reside na composição do "campo livre", que varia inclusive entre diversas opções de um mesmo banco (o BB tem pelo menos 3 formatos pra ele).
Desafio 1
Providenciar um método melhor para a impressão dos boletos
Sugestões
Imagino que temos 3 opções:
1. O projeto Jrimum possui um módulo chamado Bopepo com uma implementação de classes para a emissão do boleto e uma forma de personalização do layout através de formulários em formato pdf, que podem ser criados a partir de arquivos .odt (Open/LibreOffice).
2. Como dito no primeiro parágrafo, a formatação dos boletos não é complicada e pode ser possível fazê-la através do Jasper com informações coletadas durante a geração dos dados do boleto, tornando os módulos que atualmente cuidam do CNAB, responsáveis também pela geração das informações para a impressão do boleto, tornando mais simples a adição de bancos não suportados por uma biblioteca externa (jrimum/jboleto)
3. Copiar e refatorar o código do jBoleto para dentro do nosso projeto para podermos estender ele internamente.
Facilidades para a extensão e configuração
A adição de um banco que não tenha muitas demandas não é complicada, bastando copiar e editar o módulo de um banco existente. O maior problema é que parece que todos os bancos tem demandas diferentes e casos diferentes. Algumas identificadas:
- Banco do Brasil
- variação da carteira
- 3 formatos de boleto/CNAB
- Safra
- emissão de boletos de "bancos correspondente"
- consulta em tabela de CEPs
- Sicoob / Bancoob
- impressão de boletos registrados só pode ser feita após o recebimento do arquivo de retorno (nosso número é sempre gerado pelo banco)
- emissão de boleto de "banco correspondente"
- essa lista tende a aumentar ...
O código para cada banco pode ser genérico o suficiente para atender todos os casos daquele banco, porém muitos precisarão de diversos parâmetros para que tomem as decisões adequadas. Alguns são mais simples, como por exemplo o BB que pode tomar a decisão do formato do boleto/cnab através do tamanho do número do convênio, ou outros que podem decidir pela carteira ou pela definição de ser ou não registrado.
Mas alguns podem precisar de parâmetros adicionais, como o próprio BB, que tem o parâmetro "variação da carteira", ou o já citado banco Safra, onde o código precisa determinar se deve emitir um boleto do próprio Safra, ou um do Bradesco em um formato especial.
Desafio 2
Encontrar uma forma para que a janela de configuração da cobrança possa saber quais são e permitir a edição dos parâmetros que um determinado módulo de banco precisa para operar.
Sugestão
Alimentar os parâmetros em uma tabela, o preenchimento desta tabela pode ser auxiliado por uma das seguintes formas:
0. os parâmetros de um determinado banco suportado podem ser fornecidos através de uma sub-aba da configuração do banco (similar ao que ocorre para os códigos de retorno atualmente), ou através de um método na classe que implementa o banco (MBancoExemplo.java) que informa quais são os parâmetros que ele precisa para trabalhar e valores default.
1. ao preencher e salvar o registro das definições básicas de cobrança (atualmente no registro da conta), um callout ou validador (ainda não verifiquei qual fecha melhor) preenche uma aba com registros a serem editados pelo usuário (baseado no método do item 0), possivelmente com um campo "ajuda" em readonly para que o usuário saiba alimentar estes parâmetros.
2. Utilizar um campo e um mecanismo de edição alternativo (similar ao das taxas de impostos) que consulte a relação de parâmetros (vide item 0) e formatar uma tela para a edição dos mesmos.
Em todas as situações, parte do código atualmente presente no MLBRBoleto.java deve ser migrado para os módulos de cada banco, já que muitas decisões a serem tomadas no momento do preenchimento do boleto são específicas a cada bancco.
Múltiplas carteiras / modalidades / convênios
Geralmente os clientes bancários tem a opção de utilizar diversas modalidades de cobrança, com ou sem registro, com ou sem a impressão do boleto, convênios diferentes, etc. A atual implementação do LBR suporta apenas um conjunto de opções por conta bancária.
Desafio 3
Criar uma forma de permitir que diferentes opções sejam utilizadas simultaneamente no sistema.
Sugestão
Criação de uma nova janela com o título "Configurações de Cobrança", os registros desta janela recebem as configurações que atualmente estão na configuração da conta bancária e implementam o recurso da "aba de parâmetros adicionais" citada na sugestão do desafio 2.
Cada registro da janela "Configurações de Cobrança" estará associado a um banco e conta cadastrado.
Para a emissão dos boletos/CNAB, ao invés de selecionarmos a conta, selecionaremos a "configuração de cobrança"
Como opção para automatizar o processo de emissão de boletos / CNAB, o cadastro do parceiro (na aba cliente) pode ter a definição da "configuração de cobrança" mais adequada para ele, de acordo com a necessidade do usuário. Esta mesma "configuração de cobrança" também pode vir a ser preenchida/alterada no pedido e na fatura, similar a como ocorre com a definição da forma de pagamento.
Melhorar o suporte ao CNAB400
Atualmente o sistema utiliza campos dinâmicos para cada função do CNAB400, mas é sabido que algumas posições são idênticas entre todos os bancos, pode ser mais amigável utilizar nomes específicos ao invés de CNABFieldNN para absolutamente tudo.
Além disso, pode vir a ser necessário cancelar ou dar baixa de um boleto registrado emitido, autorizar a bonificação de juros/mora, conceder abatimento, acionar ou cancelar o protesto, alterar número, valor, vencimento.
Desafio 4
Remodelar ou melhorar a composição e armazenamento dos registros CNAB400
Sugestão
Criar campos no banco e na classe para lidar com os campos "padronizados" do CNAB400. As lacunas restantes (que também serão campos no banco) devem ser prenchidas de acordo com as especificações de cada banco.
Desafio 5
Implementar instruções CNAB400
Sugestão
Criar uma "fila de instruções", e permitir que o usuário alimente esta fila com diversas finalidades. A formatação inicial deve ser tratada pelo módulo que cuida de cada banco, que atualmente gera apenas a instrução "01 - remessa de títulos". Esta fila deve ser lida na hora de gerar o arquivo CNAB400 e as instruções devem fazer parte deste arquivo.
