Luciano Rodrigues Pereira

Pois é, mas ListaConsultaRetornoWeb.Count retornou 1. Como posso saber se esse item da lista é um retorno de verdade ou não?

1. Eu vou fazer as requisições uma a uma. Não é só em relação de registro, não é isso? Consulta também devo fazer boleto a boleto? No Sicredi mesmo demora muito, 1 segundo a consulta de cada boleto, é uma eternidade. 2. Só gostaria de saber se o ACBr faz um loop na lista, enviando ele mesmo um a um. Pois além de desconhecer esse processo de API com múltiplos registros, aconteceu comigo o seguinte: Na alteração do vencimento de um boleto do Sicredi com desconto, onde vou prorrogar o vencimento e quero que o novo vencimento seja o novo prazo também para o desconto, eu tive de mandar as duas operações, uma para mudar a data do desconto e outra para mudar o vencimento. Adicionei as duas operações na Lista e fiz um só Boleto.Enviar() e deu certo e acredito que a API do Sicredi não receba vários registros de uma única vez, por isso perguntei se o ACBr não faz ele mesmo um loop da Lista.

Eu vi no manual que existem esses campos no Titulo do ACBr Cobrança, mas usei-os e nenhum deles foi impresso no boleto. Qual a função deles? Existe um modelo de boleto que eles são impressos? Titulo.Informativo Titulo.Detalhamento Titulo.Referencia Titulo.TextoLivre

Quando envio o comando Boleto.Enviar(); ele está enviando digamos, o registro de 1000 boletos, pois adicionei 1000 boletos em TituloNaLista; 1. Mas eu posso ter um código HTTP de erro ou sucesso para o comando, mas no ACBr o código de Retorno é o resultado da tentativa de registro de cada item da Lista. Até mesmo porque eu posso ter sucesso em uns e outros não e aí códigos diferentes para cada um. 2. Quando o Boleto.Enviar() que é um boolean retorna verdadeiro e quando retorna falso? se depende no sucesso ou não da operação de cada item da Lista? 3. Quando eu faço Boleto.Enviar() neste exemplo, ele envia o registro de 1000 boletos em uma única requisição??? Ou faz ele próprio um loop de envio para cada item da lista? Porque eu não conheço API que receba várias registros de uma única vez, ela teria de receber um Json e não valores de campos com por exemplo ?codigo=15&nome=Luciano. Só conheço assim, sempre registros um a um. Grato, pelo seu atendimento.

Estou testando com o Sicredi, mas a dúvida vale para todos o bancos e acredito que a resposta seja a mesma. Quando faço uma consulta de movimentação da carteira p/período (tpConsulta), o ACBr retorna ao menos 1 registro em ListaConsultaRetornoWeb, mesmo que não haja movimento, ou seja ele nunca retorna com Count = 0 Como posso saber se houve ou não movimento em ListaConsultaRetornoWeb? Às vezes esse retorno de 1 registro pode ser um movimento ou não, pois mesmo que não haja movimento ele traz um registro também com código 200 (ok) como abaixo: 16/08/24 10:51:59:470 - Retorno Envio: TBoletoW_Sicredi_APIV2 16/08/24 10:51:59:470 - C digo do Envio: 200 1.1 OK 16/08/24 10:51:59:470 - Retorno Envio: {"items":[],"hasNext":false} 16/08/24 10:51:59:470 - Cookies: 16/08/24 10:51:59:470 - 16/08/24 10:51:59:470 - 16/08/24 10:51:59:470 - 16/08/24 10:51:59:470 - Header: 16/08/24 10:51:59:470 - HTTP/1.1 200 OK x-content-type-options: nosniff content-security-policy: default-src 'none';script-src 'self' 'unsafe-inline' 'unsafe-eval';object-src 'none';style-src 'self';img-src 'self';form-action 'self';connect-src 'self';plugin-types application/pdf application/x-shockwave-flash;reflected-xss block;script-nonce 7fc62a3de2273498ec5cc43b3197a34dd567916c strict-transport-security: max-age=31622400; includeSubDomains; preload; always; x-content-type-options: nosniff strict-transport-security: max-age=15724800; includeSubDomains x-frame-options: DENY x-xss-protection: 1 ; mode=block referrer-policy: no-referrer expires: Fri, 16 Aug 2024 13:51:59 GMT cache-control: max-age=0, no-cache, no-store pragma: no-cache date: Fri, 16 Aug 2024 13:51:59 GMT content-disposition: inline content-type: application/json server: **** transfer-encoding: chunked

Ou seja, verificar o código de erro de acordo com cada banco. Pior que os bancos muitas vezes dão o mesmo erro 400, para várias situações diferentes. aff... horrível essa falta de padronização Vou tentar de outra forma, usando o tpConsultaDetalhe. Desta forma o retorno pode trazer a situação do boleto como BAIXADO, LIQUIDADO, PROTESTADO ou ainda apenas registrado. Tem como via ACBr identificar essas situações independente do banco, para eu não ter de ficar à toda operação ficar testando um código de retorno para cada banco? Eu atualmente faço assim. Existe uma forma melhor usando o ACBr, que já identifique a situação do boleto independente do banco? stCobranca:= UpperCase(TituloRet.EstadoTituloCobranca); if Pos('LIQUIDADO', stCobranca) > 0 then LiquidaBoletoWS(TituloRet, seuNumero) else if Pos('BAIXADO', stCobranca) > 0 then BaixaBoletoWS(SeuNumero); Mas e para os boletos que constam apenas ainda como registrados? Já vi banco que retorna "EM SER", outros "EM CARTEIRA" e se já estiver vencido "VENCIDO", etc. não dá para eu fazer um teste como esse acima.

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?