Luciano Rodrigues Pereira

Já está atualizado, valeu!

Acabei de fazer o SVN Update (19/11/2025 16:10:00) e o fonte do Banco do Brasil está com um erro. Fiz a correção, segue para publicação: ACBrBoletoRet_BancoBrasil_API.pas

"Depende de qual banco está falando". Essa é a questão, estava querendo saber de uma forma que eu não fique testando conforme cada banco, entendeu? Da forma que estou fazendo está funcionando para os bancos que estou trabalhando, mas pode haver outro que não se enquadre, por isso perguntei se o ACBr que já faz um tratamento conforme o banco, tem alguma propriedade no retorno da consultaDetalhe que informe a questão da baixa.

@Juliomar Marchetti pode encerrar o post, eu conferi e testei tudo e o ACBr já fez as implementações da movimentação da baixa, está tudo funcionando perfeitamente.

A francesinha do Itaú além de liquidações, também traz as baixas, só muda o filtro. é só fazer tipo_movimentacao = baixas e o ACBr só está tratando as liquidações. Fiz esses testes com o suporte do Itaú usando o Postman. Os resultados estão em anexo. Vou fazer as correções, testar e postar aqui, ok? francesinha 27-08.txt response0.json response1.json

Perfeito, pode fechar.

@Daniel InfoCotidiano as modificações funcionaram perfeitamente e também já corrigi meu sistema em relação à paginação da movimentação, muito obrigado pelas explicações. Como eu lhe disse aí no dia 16/10 neste mesmo post, o Itaú além de liquidações, também traz as baixas, só muda o filtro. E o ACBr só está tratando as liquidações. Vou fazer as correções, testar e postar aqui, ok?

Gostaria de saber da experiencia dos colegas, como ao consultar os detalhes de um boleto, vocês sabem se o boleto foi baixado? Para saber se foi liquidado é fácil, se valor_Pago > 0, mas e baixado? Isso de forma geral, independente do banco, pois eu não gostaria de ficar testando banco a banco, entendeu? Pelo CodigoEstadoTituloCobranca parece não dar certo, pois para uns bancos, o código é 6, outro pode ser 7. Pelo EstadoTituloCobranca também não, pois uns usam BAIXADO ou BAIXADA ou CANCELADO e por aí vai. Pela DataBaixa até funcionaria, pois apesar de alguns bancos usarem esse data para liquidados, os liquidados tem valor_Pago e os baixados o valor_pago é zero. Mas a CEF quando o boleto é baixado, não traz data nenhuma, nem DataBaixa, nem DataMovimentacao, nada! Eu atualmente estou fazendo assim, mas não sei se seria a melhor forma. stCobranca:= UpperCase(TituloRet.EstadoTituloCobranca); if ValorPago > 0 then LiquidaBoletoBD() else if (Pos('BAIXAD', stCobranca) > 0) or (Pos('CANCELAD', stCobranca) > 0) then BaixaBoletoBD(idTitulo, NossoNro, idCarteira); O ACBr já faz esse tratamento e guarda a informação que o boleto foi baixado em algum campo?

A alteração de boleto, como por exemplo alterar o vencimento, no banco Inter ainda não foi implementada. Posso implementar para subirem após os testes necessários. Segue a documentação do banco: API Cobrança (Boleto com Pix) | Portal do desenvolvedor Inter Empresas

Repare que o final da requisição do ACBr é "total_elements":54,"total_pages":2,"page_size":30,"page":0} ou seja, são 54 liquidações que estão em 2 páginas, pois cada página só tem 30 (porque não foi setado o valor de page_size), mas o ACBr só traz a página 0, então as outras 24 liquidações são perdidas. Por isso que deve-se setar o page_size logo para um número grande, já que o ACBr vai trazer apenas a página zero.

1. @Daniel InfoCotidiano, ainda precisa que eu faça algum teste com IndicadorPix = true? Eu já lhe encaminhei minhas credenciais de produção em outro e-mail e se você consultar a movimentação do dia 09/09/2025 (que corresponde ao log que lhe encaminhei), esses boletos liquidados neste dia têm desconto. No Postman vai mostrar. 2. Outra coisa, achei hoje com o suporte do Itaú outro problema com o ACBr.: Trata-se do page_size, o ACBr não o está setando. Conforme o Lauro, que dá suporte aos atendentes do suporte do Itaú, como funciona o page_size? ele especifica o número de elementos (boletos) que a requisição vai trazer por página. Digamos que minha requisição trouxe 54 boletos. Quando você não seta o page_size, ele só vai mostrar 30 por página. Então a página 0 vai trazer 30, e os outros 24 estarão na página 1. Eu testei buscando a movimentação do dia 27/08/2025. Usando o Postman, trouxe as 54 liquidações, mas como eu disse, em 2 páginas. Usando o ACBr trouxe 30 boletos (porque não foi setado o page_size), que é só a página zero. Para corrigir isso, é só setar o page_size para um número grande, tipo 10 mil, para que a requisição traga todos elementos em uma única página, que é a página zero. Estou anexando o log da requisição feita com o ACBr (que traz 30 liquidações) e o Json do Postman (que traz 54). O limite de page_size no postman é de 50, então os 50 primeiros estão no response0 (que é a página 0) e os 4 restantes estão no response1 (que é a página 1). 3. Outra coisa, francesinha não é só liquidação, você pode puxar baixados também, é só alterar o tipo_movimentacao = baixas, como mostro na imagem em anexo. Eu fiz esses testes com o suporte do Itaú. francesinha 27-08.txt response1.json response0.json

Eu não testei com indicador pix porque quando alguém paga via QRCode, o Itaú não retorna nenhum valor, nada, nem multa, juros, desconto, tarifa, absolutamente nada, então não tem o que testar. O que acontece quando alguém paga via QRCode um boleto do Itaú? A API do Itaú vai retornar esse boleto como "Baixado" e não vai retornar nenhum valor, pois essa liquidação vira um simples pix. Aí você vai ter de consultar a API do Pix para verificar esses valores, e vai ter de usar o txId, porque como virou um pix, não tem informações do título como nosso número. E se você está consultando a movimentação, a API do pix vai retornar todos os pixs realizados para a empresa, não só os dos boletos. Entendeu?, é horrível.

Pois é @Daniel InfoCotidiano, o Itaú é péssimo mesmo. Se você está com o arquivo .pas que eu passe, vai ver que eu descomentei tudo e corrigi, testei tudo com boletos com desconto e sem e deu tudo certo. Como eu disse, não tinha mesmo como dar certo esse bloco comentado, pois está cheio de erros como citei por exemplo: O Itaú cometeu o crime de criar um bloco Json acentuado, chamado "Tarifa de cobrança" (com 'ç'). E o bloco comentado estava procurando UpperCase(Descricao) = 'TARIFA DE COBRANÇA', sendo que o UpperCase() não converte ç em Ç, por isso usei o LeftStr(descricao, 16) = 'TARIFA DE COBRAN'. O desconto também estava buscando 'Desconto' quando o correto é 'Descontos' (no plural) e outros erros que explico onde descomentei. ValorPago também não é igual a valor_liquido_lancado, pois o valor_liquido_lancado já abate o valor da tarifa do boleto. O Bloco também estava puxando a tarifa como desconto, e por aí vai, está tudo explicado no bloco descomentado. Vou passar minhas credenciais de produção via e-mail, aí você poderá testar usando o Postman. Meu log é da movimentação do dia 09/09/2025. Outro problema neste fonte do Itaú, é que ele só puxa títulos liquidados não puxa baixados, você pode setar o Boleto.Configuracoes.WebService.Filtro.indicadorSituacao para isBaixado ou isLiquidado, o endpoint montado pelo ACBr só vai consultar Liquidados. Mas esse é um problema que posso resolver depois. Vamos resolver esses valores antes, pois estamos sem puxar a movimentação e para quem tem muitos boletos, é horrível consultar um a um. ApiCobranca_06102025.rar ACBrBoletoRet_Itau_API.rar

Fiz as correções necessárias na movimentação da cobrança do Itaú (ACBrBoletoRet_Itau_API.pas). ValorTarifa, ValorPago, ValorMoraJuros e ValorDesconto estavam completamente incorretos como estavam. Não estava trazendo os valores de Multa, Juros, Tarifa, etc. E o valor da tarifa do boleto estava vindo como valor de desconto, e o real valor de desconto não trazia, ValorPago estava igual ao valor_liquido_lancado, que é um valor já descontado o valor da tarifa. Enfim, os valores estavam todos errados. O bloco comentado tinha alguns erros que corrigi, por exemplo ValorTarifa estava buscando um bloco com Json com 'ç', sendo que o UpperCase() não converte ç em Ç, o desconto estava buscando 'Desconto' quando o correto é 'Descontos', e por aí vai. Está tudo explicado nos comentários das correções que fiz. Testei tudo, tanto usando a coleção do Postman disponibilizado pelo Itaú quanto usando o log das requisições do próprio ACBr, tudo já em produção e deu tudo certo, todos os valores vem agora corretos. Agradeço se a ACBr subir meu fonte ao menos para análise, e caso concorde com as alterações, publique-as. ACBrBoletoRet_Itau_API.pas

@Marco Roberto Crema Não muda credenciais, nem certificado, nada. É só uma nova rota. A francesinha também continua funcionando por enquanto. Mas como eu mencionei, a francesinha no ACBr não está trazendo as informações corretas. Então ao meu ver se for fazer a correção da francesinha no ACBr, é melhor já trabalhar com a nova rota.

@Juliomar Marchetti eu consegui o material do novo endpoint da movimentação do Itaú. É preciso uma conta no site do Itaú Developers, se não tiver, posso fornecer a minha. https://devportal.itau.com.br/nossas-apis/itau-ep9-api-boleto-v1-externo?tab=especificacaoTecnica#operation/get/boletos

Então @Juliomar Marchetti, fica a dica aí do novo endpoint da consulta da movimentação, porque como eu disse, a consulta do ACBr está usando a francesinha e assim mesmo não traz os valores de multa, juros, desconto, etc. e está trazendo o valor da tarifa do boleto como se fosse um desconto, independe se foi pago via QR Code ou código de barras. Usando a "francesinha", lá no ACBrBoletoRet_Itau_API.pas está assim: ListaRetorno.DadosRet.TituloRet.ValorDesconto := LJsonBoletoObject.AsCurrency['valor_decrescimo']; ListaRetorno.DadosRet.TituloRet.ValorDespesaCobranca := 0; ListaRetorno.DadosRet.TituloRet.ValorMoraJuros := 0; ListaRetorno.DadosRet.TituloRet.ValorOutrasDespesas := LJsonBoletoObject.AsCurrency['valor_acrescimo']; ListaRetorno.DadosRet.TituloRet.ValorPago := LJsonBoletoObject.AsCurrency['valor_liquido_lancado']; ListaRetorno.DadosRet.TituloRet.ValorRecebido := LJsonBoletoObject.AsCurrency['valor_liquido_lancado']; - Este 'valor_decrescimo' aí é o valor da taxa do boleto e não o valor de desconto. - E o 'valor_liquido_lancado', não é o ValorPago e nem o ValorRecebido, mas sim o valor recebido já abatendo o valor da taxa do boleto. Se quiser posso passar um log do ACBr para mostrar isso aí. Se quiser continuar a usar a francesinha teria de fazer essas correções, mas se quiser deixar 100% mesmo teria de deixar de usar essa francesinha e usar o novo endpoint. Se quiser posso passar a coletânea do Postman enviada pelo Itaú. Mesmo não estando trabalhando com o Itaú, eu só não vou fazer as alterações, porque não conheço à fundo assim os fontes do ACBr. Forte abraço, amigo.

Obviamente que não, eu apenas mencionei que o Postman foi usado para testar os endpoints, juntamente com o suporte para homologação do Itaú. O próprio Itaú disponibiliza a coletânea do Postman para testes. O Itaú não tem um material como um "Manual". Eu estou aqui com o intuito apenas de colaborar, pois para ser bem sincero eu já convenci meu cliente à trocar para o BB, por conta dessa problemática no Bolecode do Itaú.

Estou postando aqui à título de tentar ajudar quem trabalha com a API de boletos do Itaú. 1. Não usem o Bolecode (boleto hibrido). Quando um boleto é pago via QRCode e você for consultar esse boleto ou consultar a movimentação da carteira, esse título virá apenas com a informação de Baixado, informando que ele foi pago via pix, mas sem trazer qualquer informação de valores pagos, como multa, juros, desconto, valor total pago, etc. Então você não terá como liquidar o mesmo no seu sistema. 2. Em relação à movimentação, deixo aqui uma sugestão de correção para a ACBr. Eu não tenho conhecimento pleno do ACBr para eu mesmo fazer as devidas mudanças, senão eu mesmo as faria. O ACBr está usando como endpoint para buscar a movimentação a "francesinha", o Itaú está abandonando esse endpoint, já existe um novo endpoint, que além de ser mais fácil de usar e com mais recursos de filtro de pesquisa, traz informações importantes que a francesinha não traz. Fiz o processo de homologação com o Itaú usando o Postman com esse endpoint e funcionou perfeitamente. Inclusive você pode consultar um intervalo de datas e não um único dia. São muitas as melhorias em relação à francesinha. O Itaú infelizmente não possui um "manual", apenas o coletânea do Postman que se quiserem posso disponibilizar. Inclusive, olhando os fontes do ACBr, o ACBr não está trazendo valores de multa, juros, desconto, etc. e está trazendo o valor da tarifa do boleto como se fosse um desconto, independe se foi pago via QR Code ou código de barras. Seria interessante se o ACBr fizesse essa mudança, para quem trabalha com a API do Itaú. Este é um exemplo da consulta ao novo endpoint da consulta à movimentação: https://boleto.api.itau.com/boleto/v1/boletos?idBeneficiario=100700157868&codigoCarteira=109&data=2025-07-17,2025-07-17&view=basic&page=0&pageSize=20&situacao=pago

A API da Caixa retorna código 200 para qualquer requisição que você faça, com retorno com sucesso ou não. Aí o cara fica doido, como vou saber se foi realizada com sucesso ou não? Estou anexando alguns logs de exemplo. Não é um erro do ACBr, é um problema da API da CEF mesmo. Eu só gostaria de saber como vocês estão fazendo (e eu poderia fazer) para saber ser a requisição retornou com erro ou não, se foi feita com sucesso ou não, nas operações de tpInclui, tpAltera, tpBaixa e tpConsultaDetalhes. cef - consulta erro 200.TXT dijac alterar vencimento - Erro.txt dijac alterar vencimento - Erro2.txt

Quer dizer que se eu detectar algum problema em algum componente do ACBr e estiver sem tempo para fazer a correção ou implementação não posso apontá-la? Se eu estivesse com tempo eu implementaria, mas não é o caso. Com certeza se eu fosse um cliente Pro e fizesse a solicitação vocês implementariam. Bom, caso a ACBr queira fazer a correção/implementação seria benéfico para todos que usam a API do Itaú, só isso.

Minha assinatura não é Pro ou Corporativa, só quis chamar a atenção para o problema identificado. Porque afeta a todos.

Em todos os bancos o ACBr usa o tpConsulta para consultar a movimentação da carteira de cobrança dentro de um período. Mas no Itaú o ACBr está usando para buscar a movimentação de um único título e não existe uma terceira opção. Então a gente está ficando sem a movimentação da carteira que acho que todos concordam que é mais importante que a movimentação de um único título. Imagina se o cliente tem 100.000 títulos? Eu vou ter de consultar um a um todo dia, sendo que eu posso por exemplo hoje consultar a movimentação de ontem amanhã a movimentação de hoje e por aí vai. Então não seria melhor o ACBr muda esse tpConsulta para buscar a movimentação da carteira e não a movimentação de um único título? Dá para enviar essa questão para o SLA?

Conversei na época com o TI do Itaú que me explicou com detalhes o que acontece. O banco não considera isso um "problema". Mas existem muitas reclamações. O Itaú meio que mistura a API de cobrança com a API de Pix. Então quando alguém paga o boleto com o QRCode essa baixa vai para o BD do Pix e aí no BD do boleto fica só a informação "Baixa por ter sido liquidado" e mais nada. Para saber os detalhes dessa liquidação precisaria fazer uma outra requisição na API de PIX, só que lá você vai encontrar todos os PIX realizados para o cliente, não só o pagamento dos boletos. Entendeu? E como identificar o PIX do boleto dentro dos demais? Por isso não recomendo usar o boleto hibrido do Itaú. Eu mesmo nem estou usando API do Itaú ainda por outro "problema" agora com o ACBr. A API do Itaú tem requisição da movimentação. O que é a movimentação? É a movimentação da carteira dentro de um período como você sabe. E o ACBr faz essa requisição usando o tpConsulta mas isso nos outros bancos. No Itaú o ACBr usado o tpConsulta para buscar a movimentação de um único título (que é outra opção que tem na API do Itaú). Agora eu te pergunto: De que me interessa a movimentação de um único título? Me interessa saber os títulos que foram liquidados, baixados e protestados dentro de um período, tipo ontem, para eu não ter de ficar todo dia consultado título por título. Imagina se o cliente tem 100.000 títulos? E o ACBr só tem tpConsultaDetalhe que consulta um título e tpConsulta que consultaria a movimentação, mas que no Itaú está consultando a movimentação de um único título, não existe uma terceira opção. Então não seria melhor o ACBr muda esse tpConsulta para buscar a movimentação da carteira e não a movimentação de um único título?

Isso aí é exatamente o que eu disse @Juliomar Marchetti Eu não posso usar o ClientID, senão o ACBr troca o USUARIO_SERVICO de SGCBS02P para o ClientID e aí dá erro dizendo que esse campo está com 34 posições, sendo que o máximo seriam 8 posições. E o próprio manual na sua página 10 diz "Para todos os tipos de operação, deverá ser informado no campo USUARIO_SERVICO o valor SGCBS02P". Deu pra entender?