João Vitor Bogo

Boa tarde, na unit ACBrBoletoRet_Cora não estava sendo processado o 'EMV' do PIX no retorno, apenas adicionei 1 linha (Que já existia quando estava incluindo) na consulta detalhada também Segue anexo ACBrBoletoRet_Cora.pas

Bom dia, ainda nessa unit, encontrei outro problema, a function TRetornoEnvio_Bradesco.DateBradescoToDateTime(const AValue: String): TDateTime não está processando corretamente a data, pois o Bradesco envia ela cortando o primeiro dígito quando ele é zero, no caso por exemplo a data '8062026' está falhando na conversão. Segue novamente a unit com os ajustes ACBrBoletoRet_Bradesco.pas

Boa tarde, passando só pra comentar que eu fiz uma mudança referente à baixa e aqui está o arquivo ACBrBoletoW_Sisprime_API.pas

Bom dia Estou fazendo alguns testes na emissão do boleto do Bradesco, e tive uma falha na unit que faz a leitura do Retorno, o JSON está sendo retornado com o campo assim: "dataVencto": "15/06/2026" Então a leitura desse campo era feita da seguinte maneira: ARetornoWS.DadosRet.TituloRet.Vencimento := LJsonObject.AsDateTimeBr['dataVencto']; O que fazia com que desse erro na conversão da string. Eu fiz o ajuste para ler assim e agora está funcionando normalmente: ARetornoWS.DadosRet.TituloRet.Vencimento := DateBradescoToDateTime(LJsonObject.AsString['dataVencto']); Segue anexo o arquivo com a modificação ACBrBoletoRet_Bradesco.pas

Boa tarde, Estou contribuindo com a implementação da cobrança via API REST do banco Sisprime do Brasil (código FEBRABAN 084) no ACBrBoleto. As duas units em anexo são novas e adicionam suporte ao webservice cobexpress.com.br, que a Sisprime usa para registro, consulta, baixa e alteração de boletos. Versão usada: ACBr LibD29 (Delphi 12). Documentação oficial: "Documentação da Integração SISPRIME" (Layout Cobrança Sisprime, versão 2.0, 23 páginas — fornecida pela cooperativa). (Em Anexo) URLs oficiais: - Homologação: https://homologa-ws.cobexpress.com.br/webservice/enviar-boleto e /consultar-boleto - Produção: https://sisprimebr.cobexpress.com.br/webservice/enviar-boleto e /consultar-boleto Arquivos novos: ACBrBoletoW_Sisprime_API.pas — gerador de requisições. Implementa autenticação JWT HS512 (token assinado com a chave de acesso geral da cooperativa, com a chave da conta indo dentro do payload em "hash"), monta o JSON do título com os campos exigidos pela Sisprime (codigo_pagador, tipo_inscricao_pagador, inscricao_pagador, nome_pagador, endereço completo, percentuais de juros e multa, etc) e cuida de normalizar os campos textuais com TiraAcentos pois o servidor rejeita acentos no campo Município (resposta "codigo_inconsistencia=134, O campo [Município Pagador] não contém uma Cidade válida"). O mapeamento de operação para ocorrencia_remessa segue a convenção CNAB do banco: tpInclui=01 (registro), tpAltera=06 (alteração de vencimento), tpBaixa e tpCancelar=02 (baixa/cancelamento), tpConsulta e tpConsultaDetalhe usam o endpoint consultar-boleto. ACBrBoletoRet_Sisprime_API.pas — parser de retorno. Trata o detalhe específico da Sisprime de devolver TODAS as respostas encapsuladas em array JSON (formato [{...}]), removendo os colchetes externos antes de chamar TACBrJSONObject.Parse para evitar Invalid class typecast. No caso de rejeição (status_retorno diferente de 0), itera o array "inconsistencias" devolvido pelo servidor e cria uma TACBrBoletoRejeicao por item, com codigo_inconsistencia e descricao_inconsistencia preservados (a descrição genérica "Entrada Rejeitada" sozinha não ajuda em diagnóstico). Para o registro com sucesso, popula NossoNumero, LinhaDig, CodBarras, SeuNumero (a partir de numero_documento) e NossoNumeroCorrespondente com o id_boleto (UUID que a Sisprime usa em consultas posteriores). Para a consulta, popula EstadoTituloCobranca a partir de descricao_situacao e os dados PIX (qr_code) quando presentes. Observações sobre a integração: 1. A autenticação não é OAuth2 — é JWT HS512 montado a cada requisição (token expira em 600s). A chave geral é o segredo HMAC; a chave da conta vai como hash no payload. As duas chaves são fornecidas pela cooperativa após homologação. Não há certificado PFX nem mTLS. 2. O algoritmo HMAC precisa ser referenciado como THashSHA2.TSHA2Version.SHA512 (o enum TSHA2Version é nested no record THashSHA2 em System.Hash). Castar inteiro 512 para esse enum é silenciosamente errado e o servidor responde "status_retorno=-10, Assinatura Inválida". 3. A Sisprime registra o banco 084, mesmo código FEBRABAN do Uniprime Norte do Paraná. As duas cooperativas coexistem no enum TACBrTipoCobranca (cobBancoSisprime e cobUniprimeNortePR). Por padrão, GetTipoCobranca(084) retorna cobUniprimeNortePR — o uso de Sisprime requer setar TipoCobranca explicitamente como cobBancoSisprime no Cedente, antes do EnviarBoleto. 4. Os dois endpoints aceitam apenas POST com Content-Type application/json. O token vai dentro do corpo JSON (não no header Authorization). Validações que fiz contra o ambiente de homologação: - Registro de boleto: status_retorno=0, "Entrada Confirmada", retornando id_boleto, linha_digitavel e codigo_barras. - Consulta de boleto: status_retorno=0 com descricao_situacao preenchida e qr_code (PIX) quando aplicável. As duas units são compatíveis com o ACBrBancoSisprime.pas existente (parte CNAB do banco, sem alterações) e com a infraestrutura ACBr existente (ACBrBoleto.pas, ACBrBoletoWS.pas). Disponível para responder dúvidas, anexar logs de homologação ou ajustar o que for solicitado na revisão. Abraço. ACBrBoletoW_Sisprime_API.pas ACBrBoletoRet_Sisprime_API.pas DOCUMENTAÇÃO DA INTEGRAÇÃO SISPRIME.pdf

Bom dia, pessoal! Estou em processo de homologação de cobrança com o Banco Safra (API REST, carteira eletrônica) e, durante os testes, me deparei com dois problemas no fluxo de envio e consulta de boletos. O suporte de homologação do Safra confirmou que o conteúdo enviado pelo componente estava divergente do formato esperado por eles. Foi necessário ajustar a unit ACBrBoletoW_Safra.pas em dois pontos para que tanto o registro quanto a consulta funcionem corretamente. --- ## Problema 1 — POST de registro enviava conta sem dígito verificador em homologação O método RequisicaoJson montava o campo conta de forma diferente entre os ambientes: em produção, ContaDigito era concatenado ao número da conta; em homologação, era omitido. Trecho original: LConta := IfThen(Boleto.Configuracoes.WebService.Ambiente = tawsProducao, inttostr(StrToIntDef(aTitulo.ACBrBoleto.Cedente.Conta, 0)) + aTitulo.ACBrBoleto.Cedente.ContaDigito, inttostr(StrToIntDef(aTitulo.ACBrBoleto.Cedente.Conta, 0))); O efeito era que, em homologação, o JSON enviado continha o número da conta sem o dígito verificador, e o banco gerava um código de barras inconsistente com o que ele próprio esperava no checklist de validação. O suporte confirmou que o campo conta deve conter número + DV nos dois ambientes. A correção foi remover o IfThen e sempre concatenar o ContaDigito: LConta := inttostr(StrToIntDef(aTitulo.ACBrBoleto.Cedente.Conta, 0)) + aTitulo.ACBrBoleto.Cedente.ContaDigito; Após essa alteração, o POST passou a registrar com sucesso e o banco gerou código de barras e linha digitável corretos. --- ## Problema 2 — GET de consulta não localizava o boleto recém-registrado Logo após o registro bem-sucedido, o componente faz uma consulta no endpoint GET /boletos para confirmar o estado do título. A função DefinirParametros montava a query string lendo apenas Cedente.Conta, sem o ContaDigito: LConta := aTitulo.ACBrBoleto.Cedente.Conta; ... Consulta.Add('conta=' + LConta); Como o POST registra com conta + DV (após o fix do Problema 1), mas a consulta enviava só o número da conta sem o DV, o banco não encontrava o registro e respondia com 503 Service Unavailable e a mensagem genérica "Ocorreu um erro na requisição". Foi necessário aplicar a mesma serialização do POST também na consulta: LConta := IntToStr(StrToIntDef(aTitulo.ACBrBoleto.Cedente.Conta, 0)) + aTitulo.ACBrBoleto.Cedente.ContaDigito; Com isso, o valor enviado na URL bate exatamente com o que o banco recebeu e armazenou no POST, e a consulta passa a retornar o título normalmente. --- ## Como reproduzir 1. Configure uma conta Safra em homologação com Cedente.Conta e Cedente.ContaDigito separados. 2. Registre um boleto via Boleto.EnviarBoleto. 3. Em seguida, execute ConsultarBoletos. Segue arquivo com as modificações incluindo as modificações do post : ACBrBoletoW_Safra.pas

Bom dia, apenas passando pra saber se existe algum feedback sobre esse tópico, visto que não teve mais nenhuma atualização no ACBR sobre isso

Boa tarde, Identifiquei quatro divergências entre o que o componente envia e o Swagger oficial da API de Cobrança do Safra Negócios. Algumas causam rejeição (HTTP 503/422) em ambiente HML dependendo do beneficiário. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1. Safra-Correlation-ID é constante com GUID fixo Linha 101, o GUID é reutilizado em todas as requisições. O Safra loga requests repetidos com o mesmo correlationId e pode responder 401/503 genérico. A spec exige um GUID único por request para rastreabilidade. Atual: C_IDENTIFICADOR = 'Safra-Correlation-ID: 41fa65a3-1a71-4437-a169-5bd209eb2d3a'; Sugerido: const C_IDENTIFICADOR = 'Safra-Correlation-ID: '; procedure TBoletoW_Safra.DefinirAuthorization; var LGuid: TGUID; begin FPAuthorization := C_AUTHORIZATION + ': Bearer ' + GerarTokenAutenticacao; CreateGUID(LGuid); FPIdentificador := C_IDENTIFICADOR + LowerCase(Copy(GUIDToString(LGuid), 2, 36)); end; ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2. "agencia" e "conta" enviados como string — Swagger define number Swagger registro-boleto-request define agencia e conta como type: number. Confirmado nos exemplos oficiais do Postman de Instrução/Baixa e no data.json de registro. Atual (linhas 254–255): LJson.AddPair('agencia', aTitulo.ACBrBoleto.Cedente.Agencia); LJson.AddPair('conta', LConta); Sugerido: LJson.AddPair('agencia', StrToIntDef(OnlyNumber(aTitulo.ACBrBoleto.Cedente.Agencia), 0)); LJson.AddPair('conta', StrToInt64Def(OnlyNumber(LConta), 0)); ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3. "numero" (nosso número) enviado como string — Swagger define number Swagger define documento.numero como type: number. Atual (linha 280): LJsonDocumento.AddPair('numero', Copy(OnlyNumber(aTitulo.ACBrBoleto.Banco.MontarCampoNossoNumero(aTitulo)), 1, 15)); Sugerido: LJsonDocumento.AddPair('numero', StrToInt64Def(Copy(OnlyNumber(aTitulo.ACBrBoleto.Banco.MontarCampoNossoNumero(aTitulo)), 1, 15), 0)); ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4. Campo "mensagem" (objeto singular) divergente do Swagger O Swagger define mensagens como array de objetos com posicao (string enum '1' ou '2') e descricao. O código atual envia objeto singular, chave errada e string vazia. Atual: LJsonMensagem.AddPair('posicao', TP_MENSAGEM_RECIBO); // integer LJsonMensagem.AddPair('mensagem', Copy('', 1, 72)); // chave e valor errados AJson.AddPair('mensagem', LJsonMensagem); // objeto singular Sugerido: procedure TBoletoW_Safra.GeraMensagem(AJson: TACBrJsonObject); const TP_MENSAGEM_RECIBO = '1'; // string enum conforme Swagger TP_MENSAGEM_FICHA = '2'; var LJsonMensagem : TACBrJSONObject; LJsonArray : TACBrJSONArray; begin if Assigned(aTitulo) and Assigned(AJson) then begin LJsonArray := TACBrJSONArray.Create; LJsonMensagem := TACBrJSONObject.Create; LJsonMensagem.AddPair('posicao', TP_MENSAGEM_RECIBO); LJsonMensagem.AddPair('descricao', Copy(aTitulo.Mensagem.Text, 1, 72)); LJsonArray.AddElementJSON(LJsonMensagem); AJson.AddPair('mensagens', LJsonArray); // array "mensagens" end; end; Bonus: passa a enviar efetivamente o texto de aTitulo.Mensagem.Text em vez de string vazia. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Segue anexo o arquivo com a modificação + arquivo ZIP com os detalhes do banco SAFRA Safra.rar ACBrBoletoW_Safra.pas

Boa tarde, Estou com uma demanda para permitir a configuração de ativar ou desativar as notificações do cliente na API do Asaas. No cenário atual, identifiquei que esse campo não está sendo enviado na requisição. Além disso, analisando a estrutura utilizada (ACBr), não encontrei nenhuma propriedade disponível que permita informar esse parâmetro. Pelo trecho do código (conforme anexo), é possível ver que os dados enviados estão limitados aos campos padrão (name, cpfCnpj, email, phone, address, etc.), sem opção para controle de notificações.

Isso é uma demanda que também tenho

Boa tarde, estou utilizando o ACBrBoleto com o banco Sicoob para emissão e consulta de boletos. A comunicação com a API está funcionando normalmente, porém surgiu uma necessidade relacionada ao histórico do título retornado pelo banco. O Sicoob retorna no JSON um array chamado listaHistorico, contendo os eventos ocorridos com o título, por exemplo: Pelo que observei no código, o ACBr faz a leitura desse array internamente apenas para capturar algumas informações específicas. Porém o array completo do histórico não é exposto no componente, apenas alguns campos específicos são preenchidos nas propriedades do título. Necessidade no meu sistema No meu sistema existe uma regra de negócio onde preciso verificar se no histórico do título existem determinados eventos, por exemplo: Se existir tipoHistorico = 7 → preciso gerar um lançamento específico Se existir tipoHistorico = 6 → preciso gerar outro lançamento Ou seja, eu precisaria ter acesso ao array completo listaHistorico no Delphi, e não apenas aos campos que o ACBr já mapeia. Dúvida Existe alguma forma de acessar/alimentar esse array retornado pelo Sicoob através do ACBr? Caso não exista hoje, o caminho correto seria alterar o componente para mapear esse array em uma estrutura (lista de históricos) dentro do título? Agracederia se alguém da equipe puder me orientar qual seria a melhor abordagem nesse caso.

Bom dia, estou tendo vários problemas com isso após a atualização do ACBR, vários documentos estão estourando essa exception na hora da conversão

Fiz o post as 17:11 e o commit foi pro SVN as 17:24, aparentemente está tudo certo então

Bom dia, na revision 44597 foi adicionado o seguinte código para o cancelamento da NFSe da Sil Tecnologia O problema é que isso faz com que a tag seja fechada antes e esse valor fique de fora, fazendo o XML ficar fora de estrutura. A solução é tranquila, só alterar a posição dessa aspas simples SilTecnologia.Provider.pas Segue unit em anexo

Só pra deixar comentado também, em Olímpia nós estamos conseguindo enviar sem os campos da Reforma Tributária (que estão em vermelho à partir da página 27 do PDF de exemplo que a prefeitura forneceu) Manual_Integracao_NFSE_Nacional.pdf

Pessoal, bom dia. Em relação ao Banco Inter via API, gostaria de saber se mais alguém está enfrentando os seguintes problemas na geração de boletos: 1) QR Code dos boletos “embaralhado” Tenho um cliente específico em que ocorre uma situação estranha (nos demais clientes isso não acontece): o QR Code do boleto X, na prática, corresponde ao boleto Y. Ainda não consegui identificar a causa desse comportamento nem o que pode estar provocando essa inconsistência. 2) Boletos sendo gerados sem informação de PIX Outro ponto observado é que alguns boletos estão sendo gerados sem a informação de PIX. (Não consegui simular essa falha de forma consistente, as vezes eu emitia o boleto do mesmo título e vinha as informações do PIX, porém em outras não) Para testar, fiz uma pequena alteração na unit do ACBr, passando a preencher o campo formasRecebimento no JSON conforme a documentação do Inter: https://developers.inter.co/references/cobranca-bolepix#tag/Cobranca/operation/emitirCobrancaAsync Após essa alteração, todos os boletos passaram a ser gerados com PIX (não sei afirmar se foi coincidência ou efeito direto da mudança). No entanto, o problema dos QR Codes embaralhados continua ocorrendo. Sobre a alteração do 2º Item, segue anexo o a unit modificada ACBrBoletoW_Inter_API.pas Sobre o 1º Item, mais alguém já passou por isso ou imagina qual seria o motivo?

Boa tarde, estou tendo um problema na impressão que está fazendo a informação sair duplicada como no exemplo a seguir: Pelo que eu pude depurar, o problema acontece por quê: na unit PadraoNacional.LerXml existe a seguinte procedure que lê as informações dos serviços Ela além de salvar individualmente a informação do filho, está replicando isso para o campo 'Outras Informações' da NFSe com a linha NFSe.OutrasInformacoes := NFSe.OutrasInformacoes + sLineBreak + xInfComp; Então na unit ACBrNFSeXDANFSeRLRetrato dentro da procedure a seguir, é feito tanto a lentira do campo 'Outras Informações' como também do 'XInfComp' (Claro, se cair no else de baixo, que é o caso que está acontecendo comigo) Gostaria de discutir com vocês a melhor solução pra esse caso, obrigado.

Eu acho que o problema vai ser no layout 1.0 do próprio padrão nacional, pq esses problemas que eu tive foram todos em produção utilizando esse modelo, porém agora testando no layout 1.01 (em homologação, pq em produção ainda não está ativo) funcionou normalmente

Bom dia, eu estou gerando a NFSe com o padrão nacional para o município de Curitiba, até então quase tudo está OK, a Nota está sendo transmitida e processada porém sem as informações de 'ISS' Eu pedi para o cliente gerar uma NFSe pela prefeitura, para poder comparar o XML que estamos gerando pelo sistema com o XML gerado por lá, o que eu vi de diferente foi o seguinte: No XML emitido pela prefeitura, existe um 'node' inteiro antes do node do 'DPS', que nesse caso contém as informações de ISS Porém no XML gerado pelo sistema, o único Node existente é o do 'DPS' Acredito que é por isso que as informações de ISS não estão indo para a prefeitura como deveria. Eu reparei na unit PadraoNacional.GravarXml que existe a função a seguir: Na teoria, ela seria a responsável para gerar exatamente esse node que estou precisando, porém ao colocar um ponto de depuração dentro dessa função, reparei que nunca está passando aí. Vi que dentro do Provider do Padrão Nacional, a parte que faz a chamada de gerar o XML é assim: E essa função 'GerarXML' está fazendo gerar apenas o node do DPS e não o node com as informações do ISS que eu acredito que precisaria gerar para enviar à prefeitura. A minha dúvida é: O quê eu estou fazendo de errado nesse caso, e o quê precisaria fazer para gerar as informações do ISS corretamente? Obs: O ACBR está atualizado e os componentes já foram recompilados.

Boa tarde, está com um erro de código no bloco de consulta do 'customer', a string que monta a URL está sendo formatada errada, então a consulta está retornando todos os clientes e consequentemente todas as cobranças estão ficando pro mesmo cliente, o correto é ajustar de: para: Garantindo que assim o CNPJ/CPF seja passado, retornando o ID correto

Boa tarde, atualizei os fontes e agora pelo que eu testei aparentemente está tudo correto

por quê foi dessa maneira que bateu com o código de barras que foi gerado pelo proprio Asaas, vou encaminhar os detalhes em privado

Outro detalhe que encontramos foi que, a unit ACBrBancoAsaas, estava com o tamanho máximo da conta com 6 digitos, porém a nossa própria conta bancária aqui da empresa possui 7 dígitos, então foi necessário fazer uma alteração tanto na unit de 6 para 7 no tamanho da conta, e também de '12' para '11' a quantidade de zeros na função 'DefineCampoLivreCodigoBarras' Segue anexo com a alteração ACBrBancoAsaas.pas

Bom dia, já vou atualizar os fontes para fazer os testes, mas já adianto que pelas modificações que eu vi, ainda não foi postado nada referente ao seguinte bloco que eu comentei sobre a instrução 'deleted' que vem no JSON de consulta detalhe Outro detalhe, ao consultar um título, a informação referente ao campo 'ValorPago' está incorreta (no meu ponto de vista), está pegando o 'originalValue', que na teoria é o valor original do título quando foi enviado ao banco, ao invés do que foi realmente pago (que deveria ser o netValue) Vou agora atualizar os componentes e realizar mais alguns testes, volto no final da tarde caso tenha mais alguma coisa pra adicionar

Boa tarde, só queria adicionar um comentário à respeito da consulta detalhe da unit de retorno Atualmente, só existe no 'tpCancelar' tratando a informação se o título foi 'deleted' ou não. Isso também deve ser analisado no 'tpConsultaDetalhe' pois essa informação também vem no JSON de retorno (pois o cliente pode fazer isso direto pelo banco)