Bug dos boletos 2025, que pode ser já

[JoséQuintas]

Só pra lembrar
Mesmo que ainda não estejamos em 2025, nada impede de ser emitido um boleto hoje com vencimento em 2025.
Quem ainda não atualizou suas rotinas de boleto, o tempo tá acabando.

[Mario Mesquita]

Boa noite, pessoal.

Quintas, que bug de boleto é esse? Confesso que estou por fora.

Saudações,
Mario.

[JoséQuintas]

Não é nada complicado pra atualizar, mas será problema.
É parecido com todos os bugs de data.

Foi até bom ter postado isso, não reparei numa coisa antes.
Não reparei isso do final:
Vencimento a vista deve ser 15 dias a partir do processamento.
Perigoso isso, porque a vista vai poder pagar 15 dias depois.

Sobre o fator de vencimento, fiz assim:

Código: Selecionar todos

   ::nFatorVen   := ::dDatVen - Stod( "19971007" )
   DO WHILE ::nFatorVen > 9999
      ::nFatorVen -= 9000
   ENDDO

Chegando no 10.000, tira 9.000, o que dá os 1.000 iniciais da próxima data.
Mudando ou não a data inicial, o cálculo fica certo no ano que vém.
Tá resolvido até 2049, ou talvez pra eternidade.

[Mario Mesquita]

Boa tarde a todos.

Caraca, então isso vai estourar no início do ano que vem? Putz...

Mas o banco vai fornecer algo pra se ajustar os boletos?

Francamente nem lembro desse "fator"... vou ter que verificar isso na geração de boleto.

Saudações,
Mario.

[Mario Mesquita]

Voltei.

Não é que tem isso mesmo?

Código: Selecionar todos

STATIC FUNCTION Gera_Fator_Venc(xDt)
LOCAL xFator := ""

IF SETBAN->CODBANCO == "001"
   xFator := STRZERO( ((xDt - CTOD("03/07/2000")) + 1000), 4, 0 )
ELSEIF SETBAN->CODBANCO == "033" .OR. ;
       SETBAN->CODBANCO == "104" .OR. ;
       SETBAN->CODBANCO == "237"
   xFator := STRZERO( ((xDt - CTOD("07/10/1997")) ), 4, 0 )  // + 1000
ENDIF
//msginfo('Teste de fator venc. : '+xfator)
RETURN xFator

Então seria trocar as datas atuais por 22/02/2025?

Saudações,
Mario.

[JoséQuintas]

Ou igual eu fiz.
Não se trata da emissão, e sim do VENCIMENTO.
Se emitir hoje com pagamento em 6 parcelas, já precisa disso.

[Mario Mesquita]

Bom dia, pessoal.

Ajustei minha rotina de cálculo e está funcionando como está especificado.

Valeu o alerta, Quintas. Me salvou pq estava por fora disso e a p* do banco não alerta os clientes...

Saudações,
Mario.

[JoséQuintas]

Só reforçando:

Por um tempo, seriam duas rotinas.

A rotina atual vale para vencimentos abaixo de 22/02/2025.
Atenção à data do manual, A DATA NÃO VALE PRA CÁLCULO DIRETO, vai dar diferença de 1.000
Acho que só vão colocar a data direta no manual a partir do ano que vém.

cálculo pra vencimentos abaixo de 22/02/2025:
dVencimento - Ctod( "07/10/1997" ) // ou Stod( "19971007" )

cálculo pra vencimentos a partir de 22/02/2025:
dVencimento - Ctod( "22/02/2025" ) + 1000

Se quiser a data direta, pra não ter que somar 1000, lembre-se do equivalente:
dVencimento - ( Ctod( "22/02/2025" ) - 1000 )
A data de referência será 1000 dias antes dessa data.

A fórmula que mostrei resolve tudo do mesmo jeito.

Cuidado pra não confundir com simplesmente trocar uma data pela outra do manual, porque não é.

[SOSSOFT]

Vou ver o que eu fiz aqui, mas a solução do JoséQuintas parece ser a mais acertada

[developer]

Até 13/10/2049 funcionará no novo modelo, mas a fórmula do José é muito boa pois além de simples, fácil de entender, já prevê além desta data, se é que vamos estar por aí...

Código: Selecionar todos

nFatorVenc := dDataVenc - STOD( '19971007' )
DO WHILE nFatorVenc > 9999
   nFatorVenc -= 9000
ENDDO

[developer]

Porém tenho uma questão, como vocês estão agindo para "interpretar" o campo "fator de vencimento?"
A partir de 22/02/2025 qualquer valor neste campo vocês já assumem como sendo no sistema novo? Ou vocês adotam um prazo?
Sei que minha questão tem pouco uso, mas tem uso... mesmo que seja por um banco ou um sistema de pagamento de boleto, tipo casa lotérica, etc...
Não sei se entenderam minha questão...

[JoséQuintas]

NÃO É DATA DE EMISSÃO, Ë DATA DE VENCIMENTO.
Emitiu hoje pra 30/60 dias, o segundo pagamento já precisa estar atualizado.

O mais prático é como mostrei: passou de 9999, tira 9000.

A pergunta é até válida, mas ... sei lá...
Pode-se supor que deixaram até 999 como precaução.
Mas se não atualizar, como vai colocar 10.000 em 4 posições ? não dá.
Não vão conseguir emitir boleto sem a mudança.
Se emitir, talvez seja tudo rejeitado, por erro no dígito de controle.

Mas tem aquele bug dos bancos que encontrei.
Aceitam qualquer coisa, sem olhar data ou valor, desde que o dígito esteja certo.

[developer]

Vou explicar mais claramente o que é a minha questão, pois creio que o que eu escrevi ficou confuso.

Vamos supor que eu faça a leitura do código de barras de um boleto e o Fator de Vencimento é 1001
Como devo interpretar isso?

Como sendo 23/02/2025 ou como 04/07/2000?

Claro que o mais óbvio seja escolher 23/02/2025 pois é o nosso "tempo atual", porém pode haver uma situação que estou lendo um boleto antigo, que de fato a data de vencimento era 04/07/2000, entendeu? Não consigo imaginar agora mesmo uma situação que isso seria importante, mas gosto de prever possibilidades...

De fato seria uma situação inusitada, um boleto de 25 anos atrás não seria o caso, mas só me ocorreu que poderia surgir uma situação assim, improvável, mas possível, e não haveria nenhuma maneira de saber pois na leitura do código de barras não tem a informação da emissão do boleto ou outra forma de saber.

Sei lá... considerações... na prática isso seria muito improvável, mesmo, então o negócio é sempre interpretar já pelo sistema novo ( -9000 ). Quanto a "gerar" o boleto, não há dúvida, usar o sistema novo.

Eu percebi isso quando testava o boleto de exemplo do manual do Banco do Brasil: 00190500954014481606906809350314337370000000100

Onde o fator de vencimento é 3737, ou seja, no sistema novo interpretamos como sendo 22/08/2035, mas no manual o valor esperado é 31/12/2007 - achei curioso e me chamou a atenção. Claro que o manual precisa ser atualizado também.

Então por enquanto o que fiz para interpretar o Fator de Vencimento:

Código: Selecionar todos

IF nFator < 1000 .AND. nFator != 0
   Msg( "Fator de Vencimento inválido" )
ELSEIF nFator > 1000 .AND. nFator < 8121    // 01/01/2020
   dDataVencimento := CTOD( '29/05/2025' ) + nFator 
ELSEIF nFator != 0
   dDataVencimento := CTOD( '07/10/1997' ) + nFator 
ELSE
   dDataVencimento := CTOD( '' )
ENDIF

Com este código, que é uma solução simplificada provisória, estou dizendo que quando eu ler algum boleto com fator de vencimento acima de 8121, então vou interpretar com se referindo a 01/01/2020 e não como referindo a 22/08/2044.

Porém tem uma proposta para um processo contínuo, que resolveria permanentemente o problema, veja na imagem abaixo:

Link: https://slideplayer.com.br/slide/3364634/

Pelo que entendi, são 3000 posições anteriores em relação à Data Atual, e ainda tem que considerar 499 posições anteriores a isso como margem de segurança, sendo 5500 posições posteriores, meio confuso mas creio que dá para entender.

Agora vem a questão: Como implantar isso no código? Teria que pensar um pouco como fazer... seria algo que iria se ajustando e alterando automaticamente baseado na data atual?

O que vocês acham?

[JoséQuintas]

Entendi.
No final, precisam ser atualizados os leitores também.
Um boleto de 25 anos nem seria mais válido, porque os bancos cobram mensalidade pra boletos em aberto.
Teria sido gasto mais dinheiro do que a dívida.
Geralmente vão pra protesto.

É interessante isso:
Protestar é caro, deixar em aberto é caro.
Dependendo do valor da dívida, sai mais caro cobrar do que deixar pra lá.
Fiz protesto uma única vez, custou caro e não resolveu nada.

Esse é o Brasil de faz algum tempo.
Parece que a culpa é de quem não recebeu.