Geração do código de barras para carteira 17 com convenio de 7 posições para BB
gilvangobbato opened this issue · comments
Boa tarde.
Estou realizando alguns testes na geração de boletos com a biblioteca, porém encontrei um pequeno problema, que não sei se é erro meu ou da maneira como a biblioteca está gerando.
Ao utilizar a carteira 17 ele está gerando o código com 49 dígitos.
Depurei os fontes e percebi que ele está adicionando duas vezes o convenio no código gerado.
Ex: 001962510000044750000000 Convenio: 1234567 Convenio de novo: 234567 Número: 0000000011 Carteira: 17
Código completo com 49 posições: 0019625100000447500000001234567234567000000001117
Código completo com os dígitos verificadores fica com tamanho de 50 posições: 00197625100000447500000001234567234567000000001117
Verificando o código da Caelum, verifiquei que o problema pode ser este:
private String getNossoNumeroParaCarteiras17e18(Beneficiario beneficiario) {
int indice = beneficiario.getCarteira().equals(CARTEIRA_17) ? 1 : 7;
return getNossoNumeroFormatado(beneficiario).substring(indice);
}
Pois se a carteira é 17 está pegando um índice de 1, e na verdade deveria ser o índice de 7. Porem se alterar o código neste momento, poderá ocorrer problemas com outras carteiras. Por exemplo, com uma carteira 18, o código acima funciona perfeitamente, se alterado, ele não funciona mais. Não me aprofundei muito no problema, gostaria de saber se é um erro da biblioteca ou se eu estou utilizando ela incorretamente?
Obrigado
Oi @gilvangobbato, está com cara de bug mesmo! Adicionei a label.
Se conseguir chegar a uma solução primeiro, manda um pull request?
Certo, no momento estou trabalhando com outros bancos, mas amanhã vou olhar isso com calma e se eu chegar em uma solução eu informo.
Obrigado
Gilvan,
você está utilizando como "Nosso número" o valor com ou sem o convênio?
Estou me referindo ao método public Beneficiario comNossoNumero(String nossoNumero) da classe Beneficiario.
Ex.:
Com o convênio -> 26700010000000101 (17 dígitos)
Sem o convênio -> 0000000101 (10 dígitos)
Me deparei com o mesmo problema quando utilizei no nosso número um valor com 17 dígitos. Ele lança uma exceção:
br.com.caelum.stella.boleto.exception.CriacaoBoletoException: Erro na geração do código de barras. Número de digitos diferente de 44. Verifique se todos os dados foram preenchidos corretamente.
at br.com.caelum.stella.boleto.bancos.CodigoDeBarrasBuilder.validaTamahoDoCodigoDeBarrasCompletoGerado(CodigoDeBarrasBuilder.java:54)
Pode não ser um bug, não olhei a fundo, mas vi que tem um caso de teste para convênio com carteira 17 e convênio de 7 dígitos do BB, e aparentemente ele está correto. Talvez seja necessário um pouco de javadoc / documentação para esclarecer o valor que deve ser utilizado em "Nosso número" (quantos dígitos, etc).
Estou com dificuldade em gerar boleto com esse cenario. tenho o convenio de 7 digitos e carteira 18 alguem descobriu se do jeito q ta é realmente bug.
Para a carteira 17, com convênio de 7 dígitos, o seguinte teste passa:
@Test
public void testCarteira17ComConvenioSeteDigitosMaior1000000ComNossoNumeroCom10PosicoesENumeroConvenio() {
this.banco = new BancoDoBrasil();
this.boleto = this.boleto.comBanco(this.banco);
Beneficiario beneficiario = Beneficiario.novoBeneficiario()
.comNossoNumero("0000000001")
.comNumeroConvenio("2670001")
.comCarteira("17");
this.boleto.comBeneficiario(beneficiario);
assertEquals("00197386000000040000000002670001000000000117", this.banco.geraCodigoDeBarrasPara(boleto));
}
Porém esse cenário somente será válido se no boleto for válido informar o campo Nosso número com 10 posições, o que estaria errado, dado que estamos fornecendo somente uma parte do Nosso número.
Na especificação (página 20) diz que o campo Nosso número terá 17 posições(7 dígitos do número do convênio + 10 dígitos atribuídos pelo cliente), então o mesmo deveria informado explicitamente dessa forma para ser exibido igual quando o boleto for gerado de fato.
Nesse cenário ao informar o campo Nosso número diretamente com 17 posições o teste abaixo falha, gerando o código de barras diferente de 44 posições.
@Test
public void testCarteira17ComConvenioSeteDigitosMaior1000000ComNossoNumeroCom17DigitosENumeroConvenio() {
this.banco = new BancoDoBrasil();
this.boleto = this.boleto.comBanco(this.banco);
Beneficiario beneficiario = Beneficiario.novoBeneficiario()
.comNossoNumero("26700010000000001")
.comNumeroConvenio("2670001")
.comCarteira("17");
this.boleto.comBeneficiario(beneficiario);
assertEquals("00197386000000040000000002670001000000000117", this.banco.geraCodigoDeBarrasPara(boleto));
}
Qual dois dois cenários são válidos? Se alguém puder confirmar se é esse mesmo o erro, eu envio o PR.
@manoel180 , o cenário acima é o que ocorre com a carteira 18?
exatamente, so que na carteira 18 ele gera normalmente a linha digitavel.
@alterwaycwb ainda não teve validação na minha análise acima.
Tb estou recebendo essa exceção ao montar o nosso número conforme exigência do BB:
FORMATO “NOSSO NÚMERO” PARA CONVÊNIOS ACIMA DE 1.000.000 (UM MILHÃO): A composição do nosso número deve obedecer as seguintes regras:
CCCCCCCNNNNNNNNNN convênios com numeração acima de 1.000.000, onde:
"C" - é o número do convênio fornecido pelo Banco (número fixo e não pode ser
alterado)
"N" - é um sequencial atribuído pelo cliente
comNossoNumero(conta.getNumeroConvenio() + String.format("%010d", tituloCobranca.getId()));
@EdenirAnschau vc mencionou ter PR. Importa-se em disponibilizar?
@gilbertoca Não cheguei a enviar o PR.
A classe BancoDoBrasil não consegue gerar o código de barras corretamente quando o objeto beneficiário possui nosso número com 17 posições e NumeroConvenio.
Para o cenário dessa issue eu acho que resolve se informar para o beneficiário o nosso número com 10 posições e o número do convênio com 7 posições:
Beneficiario beneficiario = Beneficiario.novoBeneficiario()
.comNossoNumero("0000000001")
.comNumeroConvenio("2670001")
.comCarteira("17");
O que tá errado já que o nosso número é composto por 17 posições e isso pode dar problema se precisar do nosso número em algum outro momento. Então do jeito que está atualmente nunca será possível vc informar no nosso número com 17 posições.
@EdenirAnschau @Turini Gostaria de consolidar meu entendimento sobre a geração do código de barras para boleto de cobrança. O que entendi no manual do BB(janeiro/2016) em relação ao código de barras foi o seguinte.
Leiaute com 2 campos (44 posições):
- obrigatório, FEBRABAN com 19 posições;
- campo livre, determinado pela modalidade de cobrança utilizada pelo cliente com 25 posições.
A classe BancoDoBrasil deveria atuar na composição do campo livre seguindo o item 2.3.2, que diz " Os padrões do BB estão identificados nos Anexos VII, VIII, IX e X".
Cada anexo é regido pelo número do convênio e não pela carteira como se vê atualmente na classe.
O cliente recebe um número de convênio, podendo ser de 4, 6 ou 7 posições - e cada algoritmo de formação do campo livre leva isso em consideração.
Boleto Registrado:
- Anexo VII, convênio 4 posições
[convênio + complemento + agência + conta + carteira] - Anexo VIII, convênio 6 posições
[convênio + complemento + agência + conta + carteira] - Anexo IX, convênio 7 posições
[000000 + convênio + complemento + carteira]
Finalmente, Boleto Sem Registro:
- Anexo X, convênio 6 posições
[convênio + complemento + carteira]
@edenir-anschau @Turini @mariofts @tiagojco , boa notícia:
Após análise, por amostragem, informamos que os boletos enviados estão
emconformidade com as especificações técnicas adotadas pelo Banco do
Brasil, e portanto validados.Boletos Validados
Olá, qual script php vocês sugerem para eu suar para geração de boletos para Banco do Brasil Carteira 17 com Registro e Convênio 7 dígitos.
@gilbertoca Você pode confirmar pra mim se no pr #205 esse bug foi corrigido?
Sim @angeliski ! Já usava em produção o código que contribui, apenas troquei (no pom) para a versão atual. Obrigado, viu!
Show de bola @gilbertoca. Vou encerrar essa issue então.
Qualquer dúvida ou problema, estamos a disposição.
:)