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