Antonio Gomes

Com os dados gravados mano, voce consegue gerar segunda via no seu sistema, no primeiro endpoint salva tudo, inclusive o txid

mas esse leiaute 810 é para ser usado quando é API ?

O nosso numero quando é por api, a gente nao gera cara, acho que é isso que ele está tentando explicar... O banco retorna isso tudo. Logo, a necessidade de recalcular, que ele está questionando, é um ponto a pensar, tem pix, api, precisa de fato recalcular isso? Pense... Uma vez, que a informação veio do banco, que detém a informação correta... até segunda ordem kkkkkkk

Dia desses me peguei com esse dilema do sicoob, após uma funcionária do banco ter dado o codigo do cedente com um numero a mais, e não ter dado falha no ato do registro (arquivo cnae240 ainda), logo, pude notar que mesmo o dv meu ter ido errado eles ajustaram a segunda via, com o mesmo dv que mandei, mas a linha digitavel ficava diferente da minha impressa. Eles tem o codigo do cedente correto, ao gerar segunda via, parece que processaram o numero certo. tudo isso, é para vc analisar, que ele entra no calculo do DV. Confere se parametrizou o objeto do boleto antes de rodar essa ação. repara o fonte que precisa para calcular o dv: if fpLayoutVersaoArquivo =-81 then LNossoNumero := PadLeft(copy(ACBrTitulo.NossoNumero,1,6), 7, '0') else LNossoNumero := PadLeft(trim(ACBrUtil.Strings.RemoveZerosEsquerda(ACBrTitulo.NossoNumero)), 7, '0') ; Num := PadLeft(ACBrTitulo.ACBrBoleto.Cedente.Agencia, 4, '0') + PadLeft(ACBrTitulo.ACBrBoleto.Cedente.CodigoCedente, 10, '0') + LNossoNumero; vc coloca no acbr o nosso numero completo com DV ou sem ? no ato da segunda via.

Pensei que era até alguma property do tipo variant ou olevariant viu.

Corrompeu nao? HD ?apaga essas linhas, se vc deixa salvo no dfm, refaz

Então, geralmente qdo tem documentação, a gente pega uma unit de outro banco, e monta uma nova unit e pede para adicionar. Cola aqui o documento.

Tem documentacao já?

parece haver uma espécie de parceria, da uma olhada aqui: https://docs.pagar.me/reference/boleto-1

Bem peculiar a esse problema:

Não tem, cabe ao desenvolvedor analisar o retorno por meio nao do codigo do retorno (200) mas se teve gravação do dado que precisa retornar, e não mais acionar o comando "incluir".

Ja discutimos sobre isso, o retorno naquele for do envio, se teve sucesso nao enviar, mas ele enviar, e analisar o retorno sem esperar do acbr, dá certo. tivemos a falha no C6, em dias de lentidão de internet o retorno fica deficitário. (aqui cabe aumento do timeout).

dê uma olhada no timeout, no retorno, se está gravado certo na primeira tentativa, não empilhe vários boletos no componente, prefira enviar uma a uma. Pois tem uma falha no codigo fonte, que vc precisa remover o boleto enviado, se tiver em uma lista, não é analisado hoje se teve retorno valido gravado, nosso numero ou codigo de barras, logo se voce aciona o envio de novo vai repetir o mesmo boleto e gravar errado no inter. Tem banco que retorna um erro de que ja mandou o mesmo boleto anterior, e nao aceita gravar novamente.

tem documentação? voce pode pegar uma unit e ir adaptando.