Retorno 240 Bancoob - Problema no Nosso Número

[Valdir Dill]

Bom dia,

A linha 537 ACBrBancoob.pas (função procedure TACBrBancoob.LerRetorno240) está assim "NossoNumero := Copy(Linha,38,7);"
Ou seja, está buscando o nosso número das posições 38 a 44.
Porém, no arquivo de retorno (anexo), esse dado está vindo das posições 40 a 46.

No arquivo anexo tem dois títulos baixados. Vejamos apenas o primeiro: o nosso número desse título é 0000453. A leitura retorna 0000004.

Será que há algum erro no Acbr ou é o banco que mudou esse layout de retorno?

Obrigado.

3180_00265012_20180820_C240_00.ret

[sidnei_alves1]

Estou com problema também com o nosso numero, olhei o manual do banco a posição correto pelo que vi seria 38 a 57. ou seja 10 posições

conforme segue o layout no xls.

esse topico tambem outro amigo ja tinha informado o problema. 

teria como alterar os fontes do svn? e que sempre que atualizo ai esqueço que mudei manual ai perto as mudancas

desde já agredeço.

 

Layouts para troca de informações.xls

Editado 21 Agosto, 2018 por sidnei_alves1
Inclusão de novas informações para solução do problema.

[Valdir Dill]

Acredito que na ACBrBancoob.pas teriam que ser alterado as linhas: 
88 - de "fpTamanhoMaximoNossoNum := 7;" para "fpTamanhoMaximoNossoNum := 10;" e
537 - de "NossoNumero := Copy(Linha,38,7);" para "NossoNumero := Copy(Linha,38,10);"

Unit alterada em anexo.

Obs.: não sei dizer se essa alteração, principalmente da linha 88 não vá gerar outros problemas, talvez na emissão. Estou apenas postando as alterações que fiz aqui e resolveram para a leitura do retorno. Mas acho que os moderadores devem analisar e, se for o caso, atualizar os fontes.

Obrigado.

ACBrBancoBancoob.pas

[José M. S. Junior]

Bom dia, chegou a verificar se essa alteração não afetaria a leitura de retorno do CNAB400?

[Valdir Dill]

4 minutos atrás, José M. S. Junior disse:

Bom dia, chegou a verificar se essa alteração não afetaria a leitura de retorno do CNAB400?

Não. Não tenho como testar com cnab400. Até porque o Sicoob está abolindo essa opção. Os convênios (pelo menos os novos) dessa cooperativa agora são aceitos apenas com cnab240. 

Obrigado.

[José M. S. Junior]

Ok, vamos validar para atualização no SVN, Obrigado...

[Valdir Dill]

15 minutos atrás, José M. S. Junior disse:

Ok, vamos validar para atualização no SVN, Obrigado...

Só um detalhe que acho que precisaríamos analisar @José M. S. Junior. Veja o que você me diz.

É o seguinte: no arquivo de retorno do banco, o título que mencionei (número 455), nosso número com 10 dígitos, ele retorna assim: "0000004551", ou seja, o "1" é o DV, correto? Com tamanho 7, esse de fato é o DV desse título.

Porém, quando gero o boleto com a mudança proposta, ou seja, colocar o tamanho máximo do nosso número para 10, o ACBR gera o boleto assim: "0000004550", ou seja, com DV=0. Pela lógica isso vai dar erro na hora do banco processar o arquivo remessa, pois, se, mesmo já no novo layout (tamanho 10), o banco aceitou com DV=1, então, se enviar com DV=0, será rejeitado, entendeu?

Ainda não tive como testar isso.

 

Editado 21 Agosto, 2018 por valdirdill

[José M. S. Junior]

Sim ,me recordo que já foi alterado o tamanho desse campo em algum momento, justamente por isso... O Campo Nosso Numero não pode conter o dígito verificador pois o mesmo é calculado pelo componente, ou seja, se informar o digito o componente vai calcular novamente e haverá inconsistência... 

O digito verificado é calculado no momento da geração da remessa ou emissão do boleto.

[Valdir Dill]

Bom dia,

Consegui fazer um testes de remessa.

Ao gerar o arquivo remessa e tentar enviar com tamanho setado em 10 no nosso número, ocorre erro (anexo) de nosso número inválido.

O erro ocorre porque o DV acaba não sendo incluído e fica errado com 10 no tamanho máximo. Com tamanho 7 ele calcula tudo correto. Porém, aí no tratamento do arquivo de retorno, o valor de ACBrBoleto1.ListadeBoletos.Objects.NossoNumero acaba ficando errado porque ele lê apenas 7 dígitos, ou seja, das posições 38 a 45.

Enfim, se colocar tamanho máximo 10, corrige o tratamento do retorno, mas gera erro na remessa. Se colocar 7, resolve a remessa, mas cria erro no tratamento do retorno.

O que talvez pudesse ser uma solução seria mudar a linha 537 da acbrBancoBancoob.pas de "NossoNumero := Copy(Linha,38,7);" para "NossoNumero := copy(Linha,38,10);" e não deixar o tamanho máximo do nosso num em 7. Isso corrigiria o tratamento do retorno e não influenciaria diretamente na remessa pois essa linha é somente do retorno. Porém, isso geraria uma exceção na "procedure TACBrTitulo.SetNossoNumero ( const AValue: String );".

Sinceramente travei. Não tenho mais ideias para acerta isso, hehe!

Se alguém tiver uma sugestão...

Obrigado.

cb220801.rem

[José M. S. Junior]

Bom dia, ao ler o campo nosso número no retorno, não deve ler o ultimo campo que é o digito verificador, por isso a leitura do retorno verifica uma posição a menos, mas precisa saber o tamanho exato de como é retornado esse campo, considerando os zeros a esquerda...

[sidnei_alves1]

Aqui tinha que ajusta pra pegar as 10 posições no retorno senão não pega o Nosso numero correto, as 10 posições é o numero informado pelo sistema sem digito.

[José M. S. Junior]

Bom dia, vamos verificar a melhor forma... baseado no manual. Obrigado!

[José M. S. Junior]

Favor verificar resposta no tópico, trata-se do mesmo assunto: