Tamanho Nosso Numero Sicredi - Alteração SVN 09/03/2020

[marcianobandeira]

Boa tarde Senhores,

Passei a ter alguns problemas com a emissão de boletos do sicredi.

Ao analisar as últimas alterações no SVN notei que no dia 09/03/2020 houve uma mudança em relação ao tamanho máximo do nosso numero.

Antes da revisão do SVN era: 

fpTamanhoMaximoNossoNum := 8;

Após a revisão passou a ser: 

fpTamanhoMaximoNossoNum := 5;

Não sei se mais alguém passou a ter problemas com isso, também não consegui encontrar o tópico que motivou essa alteração.

 

Segue os dados da revisão em questão:

 

Revision: 19353
Author: juniorsantos
Date: segunda-feira, 9 de março de 2020 14:42:10
Message:
-- ACBrBancoSicred --
[-] Ajuste na Validação da função CalcularTamanhoMaxNossoNumero.
----
Modified : /trunk2/Fontes/ACBrBoleto/ACBrBancoSicredi.pas
Modified : /trunk2/Fontes/ACBrBoleto/ACBrBoleto-change-log.txt

 

Grato

[Juliana Tamizou]

Bom dia.

Creio que seja algo que foi discutido no chat dos assinantes do SAC Anual, onde as 3 primeiras posições não eram de fato livres e se fosse enviado 8 dígitos os 3 primeiros acabavam sendo ignorados.

Relativo aos problemas que vc está tendo, por favor  seja mais especifico, quais seriam?

Att.

[Valdir Dill]

12 minutos atrás, Juliana Tamizou disse:

Bom dia.

Creio que seja algo que foi discutido no chat dos assinantes do SAC Anual, onde as 3 primeiras posições não eram de fato livres e se fosse enviado 8 dígitos os 3 primeiros acabavam sendo ignorados.

Relativo aos problemas que vc está tendo, por favor  seja mais especifico, quais seriam?

Att.

Bom dia

 

24 minutos atrás, Juliana Tamizou disse:

Bom dia @Juliana Tamizou 

Vou me intrometer no post, pois tive problemas também nessa alteração nas rotinas do Acbr Sicredi. Eu acabei nem abrindo um tópico porque contornei a situação, a qual explico abaixo.

É o seguinte: não sei é o mesmo problema/situação que o colega @marcianobandeira  está enfrentando, mas nós aqui fazíamos assim:

Tomemos com exemplo o boleto número 57
Antes dessa atualização, enviávamos para o campo nossonumero do componente o número já formatado no padrão Sicredi. Desta forma: 20 2 00057 (sem os espaços, é claro).
Esse valor 20200057 também era gravado no BD local para controle depois da leitura das baixas e localização à qual conta a receber pertence cada boleto.
Porque é feito essa gravação com o número completo no padrão Sicredi? Porque a orientação do Sicredi é que a cada ano o usuários reinicie esse sequencial do boleto.
Então, no futuro, teremos o boleto 20200057 e 21200057. Se gravarmos apenas o sequencia do boleto, ficariam DOIS títulos com o mesmo número 00057, o que logicamente, daria problemas lá na frente.

Até antes desta atualização do Acbr, o nossonumero era alimentado nesse padrão de 8 dígios e tudo certo. Porém, como agora o tamanhomaximo ficou igual a 5, ao gerar o boleto, dá o erro.

Aqui contornamos isso da seguinte forma:
- Ao alimentar o componente, nossonumero := 00057
- No BD gravamos 20200057
- Quando vamos tratar as baixas, fazemos um copy dos 5 últimos digitos do campo do BD e tudo certo.

Espero ter sido claro na minha esplanação.

Obrigado.

 

[Juliana Tamizou]

Bom dia.

Entendo, a alteração  foi feita pois a implementação esta causando problemas para que as aplicações soubessem o tamanho máximo aceito por cada banco, erroneamente acabam achando que poderiam usar uma faixa maior.

Para obter o nosso número já formatado, vcs poderiam utilizar o comando MontarCampoNossoNumero().

Att.

[marcianobandeira]

Boa tarde,

Meu problema era no mesmo sentido do colega @valdirdill

Ocorria ao gravar o nosso numero completo e depois ter problema ao preencher o nosso numero no componente.

Contudo, agora ficou mais claro, acho que dessa forma como esta agora é melhor, já que antes o próprio componente fazia os tratamentos pegando apenas os 5 digitos deixando uma falsa sensação ao desenvolvedor de estar tudo ok.

Com a nova abordagem fica mais claro ao desenvolvedor.

Obrigado.

[Aggille Sistemas de Gestão]

Desde essa alteração, quando executo  método boletoAcbr.LerRetorno o componente dá a mensagem de que o tamanho máximo é 5...
Eu armazeno as informações separadas no banco, o numerdo formatado e sem formtação, e o envio tem funcionado porque
já vai com 5 digitos...porém o erro agora é na leitora do arquivo de retorno...

[Juliana Tamizou]

Bom dia.

No manual até cita 15 posições, mas mesmo formatado a quantidade seria 9, poderia por favor informar o conteúdo das posições 48 a 62 do seu arquivo retorno?

Att.

[Aggille Sistemas de Gestão]

segue arquivo de retorno....

48059324.CRT

[Juliana Tamizou]

Boa tarde.

Corrigido no commit 19504, favor testar.

Att.

[Aggille Sistemas de Gestão]

Maravilha...

testado e funcionando... obrigado pela costumeira rapidez...

sds

[Davidson Paiva]

Em 18/03/2020 at 08:45, Juliana Tamizou disse:

Bom dia.

Entendo, a alteração  foi feita pois a implementação esta causando problemas para que as aplicações soubessem o tamanho máximo aceito por cada banco, erroneamente acabam achando que poderiam usar uma faixa maior.

Para obter o nosso número já formatado, vcs poderiam utilizar o comando MontarCampoNossoNumero().

Att.

Juliana,

Editado 25 Março, 2020 por Davidson Paiva
faltou conteudo

[Davidson Paiva]

Juliana,

function TACBrBancoSicredi.MontarCampoNossoNumero (const ACBrTitulo: TACBrTitulo ) : String;
begin
  Result:= FormatDateTime('yy',ACBrTitulo.DataDocumento) + '/' +
           ACBrTitulo.CodigoGeracao + RightStr(ACBrTitulo.NossoNumero,5) + '-' +
           CalcularDigitoVerificador(ACBrTitulo);
end;

a função seria essa?

 

Ela por si não estoura os 5 caracteres?

Existe um jeito de eu usar a função direto ou preciso criar uma externa baseada nessa?

[Juliana Tamizou]

Bom dia.

14 horas atrás, Davidson Paiva disse:

Ela por si não estoura os 5 caracteres?

Não, uma vez que ela não altera o valor da propriedade NossoNumero somente monta o nosso número conforme a formatação exiigida pelo banco para a remessa e impressão.

14 horas atrás, Davidson Paiva disse:

Existe um jeito de eu usar a função direto ou preciso criar uma externa baseada nessa?

Você pode usa-la diretamente.

Att.

[Joel]

Bom dia pessoal tudo bem?

Encontrei este post e acho que tem relação com o problema que encontrei esta semana em um cliente onde o nosso número está beeem grande.

O meu problema se encontra no RETORNO, vi que estão com problema na emissão, mas eu não tenho este problema de emissão, mesmo com um número grande de nosso número.

Baseado no tamanho máximo do nosso número que consta 20 posições (posicao 38 a 57) no layout cnab240, reparei em varios layouts de outros bancos além do sicredi, precisei alterar o limite máximo de caracteres deste campo para o tamanho permitido 20.

unit ACBrBancoSicredi;

LINHA 94:     fpTamanhoMaximoNossoNum := 20; // fpTamanhoMaximoNossoNum := 5;   JOEL UNIONSYSTEM

Tive que alterar esta constante pois na unit ACBrBoleto; existe um validador que utiliza esta constante para comparar o tamanho do campo.

Na REMESSA, como este validador recebe apenas um número que passo para ele, ele não dá problema, porém no RETORNO ele vem com o ANO na frente do numero e um dígito verificador, e ai acaba estrapolando o tamanho validado pela função.

SetNossoNumero

      if Length(trim(wNossoNumero)) > wTamNossoNumero then
         raise Exception.Create( ACBrStr('Tamanho Máximo do Nosso Número é: '+ IntToStr(wTamNossoNumero) ));

 

LINHA 2040:          NossoNumero          := Trim(Copy(SegT,38, 20));          //Trim(Copy(SegT,38, 5)); JONES UNIONSYSTEM

Tivemos que alterar o copy de 5 para 20 pois nosso número já está passando de 5 posições.

Eu não vejo a obrigatoriedade de pegar apenas 5 posições já que o layout nos permite 20 posições para preencher, e como fazemos um TRIM , isso já 

seria o bastante para não termos problemas com espaços em branco.

Como estamos recortando da esquerda para direita, não vejo problema de quem tem um número pequeno pois sempre o início será recortado pelo copy, o problema está nos números grandes acima de 5 posições que estão sendo truncados. 

Segue em anexo arquivo ACBRBancoSicredi.pas para analise. 

Desde já agradeço a vossa atenção.

 

ACBrBancoSicredi.pas

[Juliana Tamizou]

Bom dia Joel.

Esta abordagem não é o ideal, vale lembrar também que mesmo formatado o nosso numero não terá as 20 posições..

No momento estamos trabalhando para incluir uma nova propriedade no componente de forma  a permitir que seja definido se serão lidas somente as posições ou o nosso numero com a formatação e DV.

Inclusive temos um tópico sobre isso no SAC

Att.

[Joel]

Olá Juliana, obrigado pelo retorno. 

No meu caso, não vou utilizar o nosso número para baixar meus títulos, utilizo o meu numero. o problema é que, como na leitura do retorno existe uma validação, o nosso numero juntando com o ano que é colocado na frente fica maior que o máximo de 5 posições determinado na constante  e no copy.  Acredito que fica com uns 9 digitos por ai, e acaba sendo barrado na validação que comentei, não deixando eu fazer o retorno. 

Teria como ser flexivel este tamanho será ne? Ou ao menos validar o tamanho máximo do layout.

Desculpe não havia visto este post, vou continuar por lá. 

* Fui para o outro tópico mas não  consigo comentar. Vi que estão já implementando algo devido ao dígito verificador, o meu problema não é o digito pois não utilizo nossonumero para baixar meus títulos, utilizo o meu numero alo assim. O problema que estou tendo é no tamanho máximo do campo que está me barrando. 

 

Editado 29 Abril, 2020 por Joel

[Juliana Tamizou]

Bom dia.

Sim, a ideia desta nova propriedade é resolver exatamente esta situação, fazendo a leitura do Nosso Numero formatado pelo banco (Prefixo e DV) ou somente as posições livres, desta forma resolveremos esta questão.

Att.

[Joel]

Opa bacana Juliana! 

Mais uma vez obrigado! 

Vamos estar no aguardo, enquanto isso vou contornando aqui hehe. 

Abraços! 

[infopointerp]

@Joel atualiza os fontes ai.

Aqui funcionou como esperado.

[Joel]

Bom dia chefe, bacana, vou ver se consigo atualizar e fazer um teste, segunda feira é aquela correria, então já viu ne hehe.

Muito obrigado, agradeço seu contato! 

[Juliana Tamizou]

Bom dia.

Sugiro a leitura deste tópico.

Att.