Luciano Rodrigues Pereira

OK, se "houver algo" volta rejeições. Essa é a questão, tem erro que impedem o boleto de ser registrado (falta de cpf, etc.) e o erro do "Boleto já registrado". É esse erro que quero identificar, para poder salvar a informação que o boleto já está registrado no meu BD. Pensei que seria pelo código de erro HTTP, mas acredito que não será padrão esse código de erro em todos os bancos, entendeu?

Eu já faço assim, acho que não me expressei bem, vamos lá, independente se é um a um ou vários e independente do banco. 1. Ao enviar o comando tpInclui para registrar o boleto eu recebo o erro "Boleto já registrado", eu vejo esse erro no log do ACBr. O que eu preciso é saber quando o retorno do banco é de "Boleto já registrado", sem ser pelo log, entendeu? Como eu pego essa informação de "Boleto já registrado" quando estou enviando um comando de Registrar Boleto (tpInclui)? Porque na verdade a operação não vai retornar como OK, vai retornar como um erro. Mas qual o código de erro? Eu preciso saber isso para todo e qualquer banco, mas parece que não existe um padrão entre os bancos. Pelo retorno do ACBr ( RetornoDetalhe:= dmBol.Boleto.ListaRetornoWeb[0]; ) eu consigo? existe alguma padronização no código de erro ou outro campo que especifique que o erro foi "Boleto já registrado"? Meu problema todo é a falta de padronização dos bancos. Se cada banco trouxer um código diferente de erro para a tentativa de registrar um boleto já registrado, como vou saber que se trata especificamente deste erro? porque se for esse erro, eu apenas registro no meu BD o boleto, uma vez que já está registrado. 2. Só para exemplificar, quando consulto um boleto e o mesmo não é encontrado no banco, muitos trazem o código de erro 404, mas no BB traz 400. Inferno isso!!!

Estou com um problema ao tentar registrar um boleto que vem com o retorno de "Boleto já registrado". Mandando registrar um a um tudo bem, é fácil, eu resolvo. O problema é quando eu vou mandar registrar por exemplo 1000 boletos. Eu preciso saber quais boletos ele informa que já estão registrados, para eu comparar com a informação do boleto do meu BD, e caso realmente seja o mesmo boleto, eu atualizo a informação no meu BD com os dados do registro. Como eu pego essa informação de boleto já registrado quando estou enviando um comando de Registrar Boleto (tpInclui)? Porque na verdade vai retornar com um erro. Mas o código de erro? Me parece que não existe um padrão entre os bancos. Pelo retorno do ACBr ( RetornoDetalhe:= dmBol.Boleto.ListaRetornoWeb[0]; ) eu consigo? existe alguma padronização? Meu problema todo é a falta de padronização dos bancos. Se cada banco trouxer um código diferente de erro para a tentativa de registrar um boleto já registrado, como vou saber?

Eu tenho o cadastro, lá tem os exemplos de retorno das chamadas e o retorno do Json está na imagem acima neste chamado e tem a dataRecebimentoTitulo":"08.07.2024" Você acrescentando a linha LListaRetorno.DadosRet.TituloRet.DataBaixa := DateBBtoDateTime(LItemObject.AsString['dataRecebimentoTitulo']); Eu rodei novamente o Trunck2 e ainda assim não vem a dataBaixa do ACBr. Porque isso está acontecendo não sei te dizer. Por isso estou usando a DataMovimento que é a data de liquidação ou baixa. Mas que seria interessante resolver essa dataBaixa, seria.

Vi que vocês já modificaram os fontes, mas a dataBaixa que vocês se referem à dataRecebimentoTitulo do Json continua sem vir. Então, destrinchando os fontes descobrir que: Na consulta do boleto a DataMovimento é a data de registro do boleto e na movimentação a DataMovimento é a data de liquidação ou baixa Pelo ou menos é assim que está acontecendo no ACBr. Não tenho a documentação do BB.

Eu até tinha cometido um erro: tinha utilizado LJsonObject ao invés de LItemObject. Mas fiz a correção e ainda assim não está trazendo a data da baixa, que é a data da liquidação.

No retorno da movimentação da carteira de cobrança do BB (dentro de ACBrBoletoRet_BancoBrasil_API.pas) não está trazendo a data de liquidação do título, apenas a data do crédito. No retorno da consulta individual de boleto, traz: Mas na consulta da movimentação por período não traz, só traz a data do crédito. E a informação da data de liquidação está no retorno do BB Eu até fiz a alteração para a correção, rodei o ACBrInstall_Trunk2, mas ainda assim não trouxe, não entendi, não sei o que posso ter feito errado. O fato é que é importante trazer essa data, porque uma coisa é a data que foi pago o título, outra coisa é a data de crédito. Dá para corrigir, ou ao menos dizer o que fiz de errado? uma vez que corrigi, rodei novamente o ACBrInstall_Trunk2 e mesmo assim não trouxe da data da liquidação (DataBaixa).

Sim, mas dá para eu pegar a mensagem de erro que está neste Json usando por exemplo o RetornoDetalhe.JSON ou RetornoDetalhe.ListaRejeicao[i].Mensagem? essa mensagem de erro fica armazenada em algum campo do RetornoDetalhe? Enfim, esse mensagem de erro que no Sicredi seria algo como error.message e no BB algo como erros.message, como pego? Se fosse tudo padronizado eu usaria error.message por exemplo, mas aqui em um é ERROR em outro já é ERRORS.

Como eu pego a mensagem de erro do Json de retorno da requisição. Abaixo tenho dois exemplos de log da ConsultaDetalhe de um título que já não existe mais no banco. Eles tem retornos diferentes, no Sicredi e no Banco do Brasil JSON={"timestamp":"2024-07-05T13:52:46.660+0000","error":"NOT_FOUND","code":"404","message":"título não encontrado."} ->> SICREDI Result={"errors":[{"code":"4678420.1","message":"Campo nosso número preenchido com dados inválidos."}]} --> BANDO DO BRASIL

Quando faço uma consulta à um boleto para saber se o mesmo está baixado ou liquidado ou quando faço uma consulta de movimentação de um período eu preciso saber o SeuNumero ou o NossoNumero para localizar o título no meu BD. E testando o Banco do Brasil estou com a seguinte situação 1. Na operação tpConsultaDetalhe não existe no Json de retorno o campo SeuNumero e aparentemente também não existe o NossoNumero, é isso mesmo??? como que o programador vai baixar ou liquidar um título sem um número de identificação? Nos fontes do ACBr conforme imagem em anexo, ele faz ARetornoWS.DadosRet.IDBoleto.NossoNum := LJsonObject.AsString['id'];. Mas não existe esse "id" no Json de retorno. Pelo ou menos no Log de retorno do ACBr não. 2. Na operação tpConsulta que consulta a movimentação da carteira (baixas e liquidações por exemplo) também não tem SeuNumero, mas tem o NossoNumero que é LItemObject.AsString['numeroBoletoBB'] e consequentemente o NossoNumeroCorrespondente que é o nosso número sem a formatação. Aqui já dá para eu resolver no meu BD com esse NossoNumeroCorrespondente. 3. Nos outros bancos, vai ter essa mesma dificuldade nos retornos, de não trazer nem o SeuNumero nem o NossoNumero?

Juliomar nem sei lhe dizer, mas a conclusão que cheguei é que praticamente nenhum banco (ou quase nenhum) trás as informações de Multa e Juros pagos separadamente. No máximo trazem MoraJuros como um campo só. Diante disso, nem vale a pena eu trabalhar com esse campo. Eu simplesmente comparo o valor pago com o valor cobrado. Se a diferença por positiva é o valor de MultaJuros, se for negativa é o valor de desconto. Se o banco não vai separar mesmo Multa e Juros, é bem mais prático eu fazer assim. Entendeu?

Rapaz eu nem sei o que sugerir, porque não faz é sentido setar o Tipo de ocorrência para ToRemessaNaoConcederDesconto, quando eu na verdade quero alterar a data limite do desconto. O que eu sugeriria na verdade, mas acredito que eu nem tenha acesso e nem sou a pessoa mais qualificada para isso, seria a criação de um Tipo de Ocorrência ToRemessaAlterarDataDesconto que não existe nos tipos de ocorrência do ACBr, mas também não sei se isso não vai impactar em todos os fontes dos boletos, sendo que muitas vezes vocês se referem ao tipo de ocorrência pelo nome, o que não daria problema, mas quando se referem ao número do tipo de ocorrência aí daria problema, principalmente se você jogar no meio das já existentes, se jogar para o final, aí não seria problema, pois seria um número que ainda não existe. A criação do tipo de ocorrência ToRemessaAlterarDataDesconto seria muito útil, pois já vimos que é um grande problema esse tipo de alteração, em todos os bancos, exatamente por não existir esse tipo. Eu tentei usar o ToRemesaAlterarDesconto mas deu erro de exception.

Banco do Brasil API, linha 237

Estou tentando pegar o valor de multa e juros pago na liquidação do boleto, mas está bem complicado. Este print do fonte do ACBr mesmo faz uma confusão com percentual e valor, não entendi foi nada.

Estou testando a API de cobrança (já em produção) do Banco do Brasil e estou com o seguinte problema: Tenho um boleto já registrado com vencimento em 18/06/2024 e com um valor de desconto para pagamento até o vencimento. Preciso alterar o vencimento e consequentemente a data limite do desconto para a nova data de vencimento. Envio 2 comandos, o primeiro para alterar o vencimento: TUDO CERTO. O segundo para alterar a data limite do desconto. AQUI O PROBLEMA. O fonte ACBrBoletoW_BancoBrasil_API.pas mostra que eu devo setar Titulo.OcorrenciaOriginal.Tipo para RemessaAlterarDataDesconto e não existe um ToRemessaAlterarDataDesconto, existe apenas ToRemessaAlterarDesconto que não funciona neste caso. Ainda de acordo com o fonte do BB, para alterar a data limite do desconto o número de Titulo.OcorrenciaOriginal.Tipo seria 53 (conforme print em anexo), mas 53 corresponde à ToRemessaNaoConcederDesconto. Meu ACBr está atualizado.

Eu sei, acho que você não entendeu o que estou tentando dizer. Eu só quis falar que a nomenclatura das propriedades no ACBr é confusa, porque eu informo a variação da carteira em Boleto.Cedente.Modalidade, ou seja a variação da carteira eu informo na propriedade MODALIDADE. E a Modalidade eu informo em Boleto.Cedente.CaracTitulo. Ou seja, para o ACBr a modalidade não é a modalidade, é a variação da carteira e a modalidade é a CaracTitulo. Entendeu? Isso não é confuso para você?

Estou ligando e deu tudo certo, eu me referi à confusão com os nomes: No ACBr eu tenho de informar a variação da carteira como a modalidade e a modalidade como Caract_Titulo. Entendeu?

Apanhei mas consegui homologar o BB. Para homologar eu precisava informar a variação da carteira 35 e a modalidade 1. E nos fontes do ACBr a variação da carteira é a Modalidade e a Modalidade é a Caract_Título. Que confusão...

Criei o app no portal developers do BB e estou no modo de testes e estou com as seguintes dúvidas: O erro que estou tendo agora é: "O cliente informado não é o titular do convênio de cobrança.", mas estou no modo de testes, então não entendi Para o modo de testes preciso informar a Agência, Conta, Código de cedente, Convênio, Modalidade e Carteira? eu informei. Na criação do app em Developers, quais as APIs devo selecionar? estou selecionando apenas a API Cobranças. Preciso da API Login BB (OAuth)? Eu usei o developer_application_key como token, fez al consulta OK (apesar do erro). Quando eu mandar o app para produção, será gerado um outro Acess Token? Vi na página do ACBr que existem 2 scopes: cobrancas.boletos-info e cobrancas.boletos-requisicao. Quando uso uma e quando uso outra? O código de cedente tem um dígito verificador, devo informar no formato xxxxx-D ? Vou precisar de um certificado digital tipo A1 para eu fazer as requisições junto à API do BB? Ou o certificado digital é apenas se eu for usar o serviço webhook? O WebHook não é quando o banco faz a requisição junto à minha API? neste caso me informando por exemplo as liquidações e baixas? Ou seja, ao contrário do que eu quero, que é eu fazendo as requisições junto à API do BB?

Juliomar, 2 dúvidas: 1. A senha do certificado informo onde? 2. O escopo é tudo isso abaixo ou só uma dessas linhas, conforme a operação? pergunto porque tem um sinal de "+" em cada linha como se fosse tudo isso o escopo. ACBrBoleto1.Cedente.CedenteWS.Scope := 'cobranca_boletos_consultar '+ 'cobranca_boletos_incluir '+ 'cobranca_boletos_pagador '+ 'cobranca_boletos_segunda_via '+ 'cobranca_boletos_descontos '+ 'cobranca_boletos_abatimentos '+ 'cobranca_boletos_valor_nominal '+ 'cobranca_boletos_seu_numero '+ 'cobranca_boletos_especie_documento '+ 'cobranca_boletos_baixa '+ 'cobranca_boletos_rateio_credito '+ 'cobranca_pagadores '+ 'cobranca_boletos_negativacoes_incluir '+ 'cobranca_boletos_negativacoes_alterar '+ 'cobranca_boletos_negativacoes_baixar '+ 'cobranca_boletos_protestos_incluir '+ 'cobranca_boletos_protestos_alterar '+ 'cobranca_boletos_protestos_desistir '+ 'cobranca_boletos_solicitacao_movimentacao_incluir '+ 'cobranca_boletos_solicitacao_movimentacao_consultar '+ 'cobranca_boletos_solicitacao_movimentacao_download '+ 'cobranca_boletos_prorrogacoes_data_vencimento '+ 'cobranca_boletos_prorrogacoes_data_limite_pagamento '+ 'cobranca_boletos_encargos_multas '+ 'cobranca_boletos_encargos_juros_mora '+ 'cobranca_boletos_pix '+ 'cobranca_boletos_faixa_nn_disponiveis';

Vi na documentação do Sicoob que é necessário o certificado digital do tipo A1 para o uso da API de cobrança. Como eu anexo esse certificado no componente do ACBr? Tem alguma propriedade no componente ACBrBoleto para informar a localização do certificado, é isso? em ambiente de rede eu teria então de compartilhar uma pasta onde está o certificado. E a senha do certificado, onde informo? tem outra propriedade no componente?

Mas a questão para enviar com acentuação mesmo, já foi resolvida?

Não entendi. 1. Então existe um loop de envio para a lista de boletos dentro do comando "enviar", óbvio. E esse envio de cada um da lista é feito via Thread, em segundo plano? 2. Se o ACBr faz via Thread, não vai fazer diferença eu enviar um a um ou enviar a lista inteira de uma só vez, pois vai ser tudo via thread. O que muda é só que se eu mandar a lista toda de uma só vez eu vou estar usando o loop do ACBr e se eu mandar um a um vou usar meu próprio loop, mas vai tudo para segundo plano, não? 3. Quando eu uso o ProgressBar eu trago tudo para primeiro plano. Você diz para eu trocar meu ProgressBar por uma mensagem na tela para continuar usando as threads? Mas para uma interface com o usuário tem o problema da thread liberar de imediato a interface enquanto faz o processo em segundo plano e o usuário poder fechar a janela ou o app e matar o processo sem saber, não? Me explica melhor essa sua estratégia, por favor.

Com exceção de tpConsulta, todos os demais comandos como tpInclui, tpAltera, tpBaixa e tpConsultaDetalhe usam a lista de boletos. Digamos que eu tenha que registrar 1.000 boletos. Eu adiciono os 1.000 boletos na lista e depois faço o ACBrBoleto1.enviar Ou envio um a um? Hoje eu faço um a um, ou seja, limpo a lista toda vez que faço a requisição de cada boleto. Isso porque eu não sei quanto tempo leva para fazer a requisição desta lista de uma vez só, porque se demorar o usuário terá a impressão que a aplicação está travada. Por isso faço um a um e uso uma Progressbar para acompanhar. Então eu pergunto: 1. Dentro do comando ACBrBoleto1.enviar ele faz um loop fazendo a requisição à API boleto à boleto que está na ListaDeBoletos? 2. O processo de enviar é feito em primeiro plano ou em segundo plano (via Threads)? Porque em segundo plano é bom que libera de imediato a interface da aplicação para o usuário. Em contrapartida, se o usuário que não sabe se o processo que está em segundo plano fechar a janela ou fechar o app ele mata o processo. Por isso não gosto de usar Threads, só quando crio um serviço que vai rodar em um servidor dedicado, mas para interface com o usuário não. 3. Vai fazer muita diferença em termos de tempo fazer um ACBrBoleto.enviar com uma lista de boletos populada com 1.000 boletos (usando o Loop interno do ACBr) ou fazer como estou fazendo, limpando a lista a cada boleto que vou fazer a requisição e enviando um a um (usando meu próprio loop) e acompanhando com a Progressbar? 4. O banco fala que cada requisição leva centésimo de segundo, mas nos testes com o ACBr demora bem mais que isso cada requisição. É por conta dos processos internos do ACBr? 5. Pela experiência de seus clientes, o tempo para uma requisição de uma lista de 1.000 boletos demora quanto tempo? Porque se levar uns 10 segundos vale a pena enviar a lista sem a ProgressBar, caso contrário é melhor enviar um a um e usar a ProgessBar para acompanhar o envio. Qual a melhor estratégia?

Também estou aguardando a solução. Em tempo, existe uma função no ACBr que troca os caracteres acentuados por sem acento?