Boleto Santander - Nosso Número com ou sem dígito verificador

[mlgoncalves]

Pessoal, boa noite!

Esta semana implementei o uso de API de enviar boletos para o banco Santander. Até então utilizava o envio de arquivo remessa CNAB400.

Ocorre que tive um problema na leitura do nosso número retornado do banco, estava cortando o último dígito do nosso número que tinha enviado. Após estudar a rotina do CNAB400 e o JSON do boleto percebi que existem diferenças entre elas na montagem do nosso número e é exatamente aí que gerou o problema, que estou propondo agora que seja corrigido.

1) Vamos direto ao ponto. No manual do Santander (em anexo) diz assim: 

>> Nota 3: Forma de cálculo do dígito de controle

>> Nosso número

>> Campo opcional. Se igual a zeros, o sistema de cobrança do Banco atribuirá automaticamente o nosso número, se não for igual a zeros, observar instruções abaixo:

>> Composição

>> NNNNNNN-D onde:

>>NNNNNNN = Faixa seqüencial de 0000001 a 9999999. D = Dígito Verificador.

Significa que o nosso número é um numero sequencial seguido de um dígito verificador.

2) O gerador do arquivo CNAB400 ao anotar o nosso número adiciona o digito verificador, ou seja, o NossoNumero do componente é alimentado com o número sequencial e o próprio componente se encarrega de adicionar o dígito verificador completando assim a informação do nosso número, conforme descrito no manual (7 dígitos para o número sequencial e 1 dígito para o dígito verificador).

Trecho da unit ACBrBancoSantander que mostra o descrito acima e que está de acordo com o manual:

         wLinha:= '1'                                                         +  // 1- ID Registro
                  IfThen(Cedente.TipoInscricao = pJuridica,'02','01')         +  // 2 a 3
                  PadLeft(trim(OnlyNumber(Cedente.CNPJCPF)),14,'0')           +  // 4 a 17
                  PadRight(trim(Cedente.CodigoTransmissao),20,'0')            +  // 18 a 37
                  PadRight( SeuNumero ,25,' ')                                +  // 38 a 62
                  PadLeft(RightStr(NossoNumero,7),7,'0') + DigitoNossoNumero  +  // 63 a 70
                  IfThen(DataAbatimento < EncodeDate(2000,01,01),
                         '000000',
                         FormatDateTime( 'ddmmyy', DataAbatimento))           +  // 71 a 76
 

3) Quando no retorno dos dados do banco, arquivo retorno, o nosso número ocupa exatamente as mesmas posições da remessa, ou seja, 63 a 70. Então o componente do ACBr, unit ACBrBancoSantander, ao ler o retorno faz a seguinte atribuição que também está coerente com o que foi feito na remessa:

...

      with Titulo do
      begin
         SeuNumero   := copy(Linha,38,25);
         NossoNumero := Copy(Linha,63,07);
         Carteira    := Copy(Linha,108,1);

...

Nessa atribuição do NossoNumero, o componente descartou o último dígito (dígito verificador) mantendo apenas a primeira parte do nosso número, que é o número sequencial. 

Então tanto a REMESSA CNAB400 quando o RETORNO CNAB400 estão coerentes no tratamento do campo NossoNumero.

4) Vamos ao problema: ao gerar o JSON de envio pro branco, o componente está gerando o nosso número incompleto, ou seja, não está incluindo o dígito verificador como era de se esperar. O banco não confere se o último dígito é ou não o verificador, simplesmente acata em seu sistema, e no arquivo retorno CNAB400 esse mesmo número incompleto ocupa as 8 posições previstas no layout (um 0 (zero) foi acrescentado à esquerda) e o componente do ACBr descarta o último dígito como se fosse o dígito verificador, no momento da atribuição para a propriedade NossoNumero, ficando o NossoNumero errado no compomente.

Diante do exposto, entendendo que existe uma divergência na geração da informação do nosso número nos dois processos de envio de boleto, CNAB400 e API, sugiro corrigir a unit ACBrBoletoW_Santander_API, na linha 484, para acrescentar o dígito verificador que falta:

        Json.Add('bankNumber').Value.AsString := NossoNumero + ATitulo.ACBrBoleto.Banco.CalcularDigitoVerificador(ATitulo);

e corrigir a unit ACBrBoletoRet_Santander_API no tratamento do nosso número retornado, removendo o dígito verificador das diversas linhas da unit, como no exemplo:

         ARetornoWS.DadosRet.IDBoleto.NossoNum                      := copy(LJSONObject.AsString['bankNumber'], 1, length(LJSONObject.AsString['bankNumber']) -1);

 

Desse modo tudo fica logicamente correto, o NossoNumero enviado ao banco tanto pelo CNAB400 quanto pela API é retornado no CNAB400 e o componente lê e preenche corretamente a propriedade NossoNumero no momento do retorno, permitindo o uso padronizado para clientes com envios de boleto em canais diferentes.

Anexei as units já modificadas.

 

Diante disso, solicito que sejam validadas minhas considerações e atualizado o SVN caso sejam aprovadas.

 

Atc,

Marcelo Gonçalves

 

 

ACBrBoletoRet_Santander_API.pas ACBrBoletoW_Santander_API.pas Layout CNAB 400 posições Out de 2009.pdf

[Juliomar Marchetti]

No caso da API é um manual e para CNAB é outro

portanto precisa se basear no manual da API para as alterações estarem condizentes

[mlgoncalves]

Bom dia!

A documentação da API dos boletos está em https://developer.santander.com.br/api/documentacao/api-de-emissao-de-boletos#/ 

Nela não descreve como deve ser montado o Nosso Número (banknumber) mas somente como deve ser preenchido.

bankNumber

string

 

required

Nosso Número do boleto

>= 1 characters<= 13 characters

Example:

123

Match pattern:

^[0-9]{1,13}$

O único local que encontrei onde descreve sobre o campo é no manual citado acima. Então entendo que existe apenas uma definição para o campo.

Então o componente do ACBr não deveria ter o mesmo comportamento para o campo independente do canal de transmissão utilizado?

 

 

 

Editado 17 Abril por mlgoncalves

[mlgoncalves]

Consultei os boletos diretamente no site do banco Santander:

1424	0000000148890	18.000,00
F33108	0000000148911	3.336,91
1424	0000000149187	18.000,00
29112	0000000148938	1.952,24
3110	0000000149080	2.303,50
F32120	0000000149098	3.433,91
F35120	0000000149101	5.183,73
3110	0000000149110	2.303,50
40120	0000000149128	5.092,07  <<<---Até aqui os boletos tinham sido enviados pelo CNAB400, depois usando a API os boletos ficaram sem o dígito verificador.
F35120	0000000014923	8.117,71
F35120	0000000014924	6.521,23
33109	0000000014925	3.096,08
3148	0000000014926	5.771,17
2997	0000000014927	3.141,57
3181	0000000014928	2.248,87
F9120	0000000014929	9.927,83
33110	0000000014930	1.349,70
312	0000000014931	2.600,00

[Juliomar Marchetti]

Consegue questionar o banco sobre isso na API e no CNAB?

 

[mlgoncalves]

Mas questionar o que, exatamente?

No banco existe exatamente o que foi enviado. Não vejo o que questionar. Se enviar Nosso Número com DV fica com DV no banco (o DV é incluído automaticamente na geração do CNAB400), se enviar nosso número sem DV fica sem DV no banco (é o que ocorre na API, onde o DV deveria ser gerado automaticamente, mas não é).

 

Se mantiver essa situação no componente, deverei alterar a programação no meu sistema para:

....

NossoNumero recebe próximo número da sequencia;

se banco_santanter e transmissao_via_API então

      calcular o dígito verificador e adicionar no final do NossoNumero

fimse;

....

 

Não acho que isso deveria acontecer.

 

Editado 17 Abril por mlgoncalves

[mlgoncalves]

Pessoal, bom dia!

Ainda estamos com esse assunto em aberto. O questionamento que estou fazendo é de que os canais de envio de boleto para o banco Santanter (via arquivo remessa e via API) estão incompatíveis.

Se você envia através de arquivo remessa só pode receber via arquivo retorno. Se envia via API só pode receber via consulta da API.

É isso mesmo? Se sim, vida que segue, mas acho que deveria haver compatibilidade de dados entre os canais.

 

Exemplo do problema que está ocorrendo:

Preencher o componente com a informação do Nosso Número, por exemplo:

ACBrTitulo.NossoNumero := '14864';

Enviando o boleto via arquivo remessa, fica registrado no banco o nosso número: 148644 (ou seja, o componente adicionou automaticamente o dígito verificador 4 para depois incluir o nosso número na remessa)

Enviando o boleto via API, fica registrado no banco o nosso número 14864 (ou seja, o componente não adiciona o nosso número)

Daí pra frente é só inconsistências...

 

A proposta que gostaria de fazer era de padronizar, simples assim. Ou adiciona o nosso número automaticamente pelo componente, tanto na remessa quanto no envio via API ou não se adiciona o nosso número, ficando a cargo do programa fazer essa inclusão. Desse modo tanto a API ENVIO/CONSULTA quando a REMESSA/RETORNO estariam compatíveis.

 

Está coerente a minha colocação?

 

 

 

[mlgoncalves]

Pessoal,

Desistimos de tentar compatibilizar os dois canais de envio e recebimento de boletos do Santander. Assim sendo, desativamos o envio/recebimento através de CNAB e adotamos por padrão o uso da API.

Podem encerrar esse tópico.

 

[Juliomar Marchetti]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.