Criando Layouts
Para criar um novo Layout de Banco é preciso primeiramente baixar e ler a documentação oficial.
Como exemplo vou criar o Layout de remessa do Banestes, e tentar registrar cada etapa do desenvolvimento.
Encontre a documentação oficial do banco, neste caso acesse a página de documentação do Banco Banestes (http://www.banestes.com.br/downloads/index.html) vá no item 'Sistemas de Cobrança e Arrecadação' e depois escolha o layout apropriado, no caso usarei o 'Layout de Cobrança - CNAB 400 posições'
Do arquivo PDF baixada dia 21/02/2016, com 45 página as principais informações então:
Para gerar o arquivo CNAB 400 e processar o retorno é preciso definir a estrutura especificada as páginas
| Página | Secção | Título |
| 7 | 5.1.1 | Registro Header |
| 8 | 5.1.2 | Registro Transação |
| 13 | 5.1.6 | Registro Trailler |
| 13 | 6.1.1 | Registro Header |
| 14 | 6.1.2 | Registro Transação |
| 15 | 6.1.3 | Registro Trailler |
Note que há alguns tipos de registros opcionais, então logico, que estes devem ser implementados apenas quando necessário.
Também é muito importante entender bem os critérios de geração do nosso numero, neste caso está especificado no Anexo II (pág 16), que comporta 8 dígitos, com 2 dígitos verificadores.
Em todos os demais anexos, é sempre bom dar uma breve olhada, mesmo se não for usado, para que os campos do arquivo sejam preenchidos da forma correta.
Na secção 8.2.1 (Pág 31) tem a especificação do campo livre, de 25 dígitos, para a geração do boleto.
Eu já gostava muito de criar testes automatizados para facilitar validar compatibilidade e logica legada, mas depois que fiz a pós-graduação em engenharia de software, vi que é fundamental já para começar da forma certa garantindo assim qualidade:
Test Driven Development (TDD) ou em português Desenvolvimento guiado por testes é uma técnica de desenvolvimento de software que baseia em um ciclo curto de repetições: Primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. (https://pt.wikipedia.org/wiki/Test_Driven_Development)
Assim, peguei o exemplo da Caixa: https://github.com/impactro/Boleto-Test/blob/master/Caixa.cs
E criei um novo para o Banestes: https://github.com/impactro/Boleto-Test/blob/master/Banestes.cs
Eu já tinha pronto o boleto sem registro do Banestes, então a geração do campo livre já funcionava, e assim os parâmetros mínimos já estavam definidos, portanto antes de começar a mudar as coisas e revalidar, o teste me garante que as novas alterações serão compatível com o código já existente.
Na página 38 tem uma linha digitável válida de exemplo: 02190.00007 17800.006573 33154.021415 3 10270000007500
Usando o programa de descodificação: http://exemplos.boletoasp.com.br/BoletoNet/FuncTeste_DecodIPTE.aspx
E a tabela de fator de vencimento: http://exemplos.boletoasp.com.br/BoletoNet/FuncTeste_FatVenc.aspx
Temos a linha digitável: 021.9.3.1027.0000007500-0000017800006573315402141
Na página 31 há a descrição do campo livre, que é chamado de chave "Asbace", onde
1234567812345678901112312 NNNNNNNNCCCCCCCCCCCR021DD 0000017800006573315402141 Nosso Número: 178 Nº da Conta Corrente: 6573315 Carteira: 4 (Com registro) Da tabela de fator de vencimento tem-se que 1027 => 30/07/2000 E o valor: R$ 75,00 E como conclusão gera-se a linha digitável: 02190.00007 17800.006573 33154.021415 7 10270000007500 Mas note e compare com o exemplo..........: 02190.00007 17800.006573 33154.021415 3 10270000007500 Perceba que o digito de verificação deu 7, e não 3! E ai qual o problema??? A documentação do banco está errada, para variar! Por isso o processo de homologação é necessário sempre.
Mas na página 24 há outro exemplo melhor: 021.9.3.1159.0000013150-0001029700007730070402182 e neste tudo funciona certinho!
1234567812345678901112312 NNNNNNNNCCCCCCCCCCCR021DD 0001029700007730070402182 Nosso Número: 10297 Nº da Conta Corrente: 7730070 Carteira: 4 (Com registro) Da tabela de fator de vencimento tem-se que 1159 => 09/12/2000 E o valor: R$ 131,50 Linha Digitável Gerada: 02190.00106 29700.007734 00704.021823 3 11590000013150
Assim agora está validado as classes inicialmente desenvolvida, e agora pode-se começar a criar e modificar as demais classes para implantar a geração da remessa, pois todos os outros testes também foram validados.
A primeira etapa é criar uma nova classe exclusiva para tratar esse layout, no caso usei como base o CNAB400 do Itau (copiei e colei). Isso porque já é um banco bem estável e homologado a muito tempo, então a ideia é alterar o código do Itau para Virar o do Banestes.
Na Classe 'LayoutBancos', é preciso editar o metodo 'Init()' para dar suporte ao novo banco.
public void Init(CedenteInfo cedente, LayoutTipo modelo)
{
string[] cBanco = cedente.Banco.Split('-');
Bancos banco = (Bancos)CobUtil.GetInt(cBanco[0]);
if (modelo == LayoutTipo.CNAB400)
{
if (banco == Bancos.SANTANDER || banco == Bancos.BANESPA_SANTANDER)
cnab = new CNAB400Santander();
else if (banco == Bancos.BRADESCO)
cnab = new CNAB400Bradesco();
else if (banco == Bancos.ITAU)
cnab = new CNAB400Itau();
else if (banco == Bancos.BANCO_DO_BRASIL)
cnab = new CNAB400BB();
else if (banco == Bancos.SICREDI)
cnab = new CNAB400Sicredi();
else if (banco == Bancos.UniCred)
cnab = new CNAB400UniCred();
else if (banco == Bancos.BANESTES) // Em homologação
cnab = new CNAB400Banestes();
}
else // CNAB240
{
if (banco == Bancos.CAIXA_ECONOMICA_FEDERAL)
cnab = new CNAB240Caixa();
else if (banco == Bancos.SICOOB)
cnab = new CNAB240Sicoob();
}
if (cnab == null)
throw new Exception("Banco " + banco.ToString() + " não implementado para " + modelo);
cnab.Cedente = Util.Clone(cedente) as CedenteInfo;
}Em seguida é a parte mais trabalhosa, editar os enumeradosres de estrutura: 'CNAB400Header1Banestes' e 'CNAB400Remessa1Banestes', em geral há muitos campos parecidos, mas nunca são todos iguais.
Os campos fazem parte de um enumerador, onde cada membro recebe um atributo com as informações de tamanho e tipo de dados, como no exemplo abaixo
/// <summary>
/// Mensagem a ser impressa no campo instrução
/// </summary>
[RegFormat(RegType.PX, 40)] // 352-391
Mensagem,
/// <summary>
/// COMPLEMENTO DO REGISTRO
/// </summary>
[RegFormat(RegType.P9, 2)] // 392-393
Filler,
/// <summary>
/// COMPLEMENTO DO REGISTRO
/// </summary>
[RegFormat(RegType.P9, 1)] // 394-394
Moeda,A maioria dos campos virão da instancia do BoletoInfo, mas nem tudo está la, pois há campos exclusivos para cada banco, neste caso há o metodo 'SetRegEnumValue' que permite definir os campos individuais exclusivos de cada banco e layout
boleto.SetRegEnumValue(CNAB400Remessa1Banestes.Mensagem, "Mensagem a ser impressa..."); // 352-391Veja como ficou o teste unitário para homologação:
https://github.com/impactro/Boleto-Test/blob/master/Banestes.cs#L43
Eu não tenho acesso ao cliente, muito menos a conta do cliente junto ao banco, assim a homologação deve ser feita com ajuda do integrador, que tem acesso ao cliente, as vezes é o cliente que tem que passar o arquivo ao banco, há casos que é tudo por e-mail, ou dentro do bankline, ou com algum painel com senha.
A ideia é que o integrador, preencha o exemplo com dados do cliente, e gere os arquivos de remessa e boletos, envie isso ao banco pelo canal apropriado, e o banco irá fazer a critica, apontar possíveis erros, dai, esta resposta pode ser encaminhada a mim, e eu arrumo o que for preciso, mando novamente para o integrador uma nova versão atualizada, e o processo reinicia novamente até em fim estar tudo certo.