João Vitor Bogo

Pessoal, bom dia. Contexto: a prefeitura de Urupês/SP (IBGE 3556008), provedor Fiorilli, desligou o WebService antigo (layout ABRASF, IssWeb-ejb/IssWebWS/IssWebWS). A emissão em produção passou a retornar: O ACBrNFSeXServicos.ini distribuído já prevê isso — as cidades Fiorilli têm a URL nova apenas comentada, com a observação "A URL abaixo deve ser utilizada a partir de 01/02/2026". Porém, ao migrar na prática, descobrimos que só descomentar a URL não funciona. Segue o que validamos empiricamente contra a produção de Urupês/SP: 1) Com Versao=2.00 (como as seções das cidades estão hoje) + URL nova: o modo APIPropria nem chega a ativar. A seção [Fiorilli] do ini tem Params=APIPropria:... e Versao=1.00, mas a versão da cidade prevalece sobre a do provedor, e o gate em ACBrNFSeXConfiguracoes.pas (if not (FVersao in [ve100, ve101]) and FAPIPropria then FAPIPropria := False) desativa o APIPropria. Resultado: continua usando o provider ABRASF 2.0 contra a URL antiga. 2) Com Versao=1.00 + URL nova: o provider TACBrNFSeProviderFiorilliAPIPropria ativa, a DPS é gerada e assinada, mas o WS rejeita o envelope: Causa: o writer 1.00 (TNFSeW_FiorilliAPIPropria.CriaElementoDPS) coloca o elemento raiz <DPS> no namespace ConfigMsgDados.LoteRps.xmlns (fiorilli.com.br/nfse-nacional), mas o WS exige o raiz no namespace nacional. 3) Com Versao=1.01 + URL nova: emissão autorizada com sucesso (o writer TNFSeW_FiorilliAPIPropria101 gera o raiz <DPS> no namespace http://www.sped.fazenda.gov.br/nfse). Nota gerada, número e chave de 50 dígitos retornados normalmente. Importante: todos os testes acima foram feitos apenas contra a produção de Urupês/SP (3556008) — não validamos as demais prefeituras Fiorilli. Como a versão do IssWeb pode variar de município para município, o comportamento pode não ser idêntico em todas. Sugestão: atualizar o ACBrNFSeXServicos.ini — no mínimo a seção de Urupês/SP, onde o cenário está confirmado: ativar a ProRecepcionar do IssWebWSNacionalPortType e definir Versao=1.01 na seção da cidade. Para as demais cidades Fiorilli (ex.: Urânia/SP, que está com a mesma pendência no ini), fica a sugestão de ajustar o comentário padrão avisando que a migração exige Versao=1.01, não apenas a troca da URL — validando caso a caso conforme os relatos chegarem. Observação adicional (IBS/CBS): o WS da Fiorilli rejeita o grupo IBSCBS da DPS quando enviamos o cIndOp da tabela do Padrão Nacional: Só conseguimos emitir omitindo o grupo IBSCBS (CST vazio — o grupo é opcional em 2026). Deve estar relacionado ao bloco de overrides comentado em Fiorilli.GravarXml.pas ("Reescrito a geração do grupo IBSCBS do DPS pelo fato do provedor ainda estar usando o layout definido na NT 003 versão 1.2") — fica o registro para quando esses overrides forem reativados. Para quem for migrar: o WS novo também passa a validar regras que o ABRASF não exercitava — recebemos L124 (situação perante o Simples Nacional divergente do cadastro da prefeitura — a DPS envia opSimpNac, que no ABRASF não ia no XML) e N-E0370 (grupo obra obrigatório para as atividades 07.02.01, 07.02.02, 07.04.01, 07.05.01/02, 07.06.01/02, 07.07.01, 07.08.01, 07.17.01 e 07.19.01). Obrigado! ACBrNFSeXServicos.ini

Bom dia, encontrei mais 2 problemas O Primeiro é o ValorDocumento quando o título é com QRCode, atualmente ele tenta ler o campo 'valorMoedaBol' porém em todos os casos onde há liquidação (dos títulos que eu consultei), esse campo não existe, o que existe é o valMoeda O Segundo é o ValorMulta atualmente está sempre lendo o valor como se fosse um valor fixo em R$, o problema é que isso vai variar de acordo com a instrução que está sendo enviada ao banco, por exemplo se eu estou usando uma Taxa Mensal de 2% o campo "valMulta": 200 é interpretado como R$ 2.00 de multa, o que é incorreto nesse caso, pois seria 2% a porcentagem de multa Segue unit com todos os ajustes, incluindo os citados anteriormente nesse tópico.ACBrBoletoRet_Bradesco.pas

Bom dia pessoal, encontrei uma inconsistência na leitura do retorno de consulta detalhe do Santander (API) na unit ACBrBoletoRet_Santander_API.pas e queria propor o ajuste. Cenário: Na consulta detalhe (tpConsultaDetalhe), quando o título foi pago via PIX, o Santander devolve no bloco writeOffData o status = "BAIXADO" com writeOffDescription = "BAIXA DE PAGAMENTO VIA PIX". O código já trata isso reclassificando o estado para liquidado: if (ARetornoWS.DadosRet.TituloRet.EstadoTituloCobranca = 'BAIXADO') and (LJSONObject.ValueExists('writeOffDescription')) and (LJSONObject.AsString['writeOffDescription'] = 'BAIXA DE PAGAMENTO VIA PIX') then ARetornoWS.DadosRet.TituloRet.EstadoTituloCobranca := 'LIQUIDADO'; O problema é que esse trecho altera só o EstadoTituloCobranca (texto). O CodigoEstadoTituloCobranca, porém, já tinha sido preenchido mais acima a partir do status original "BAIXADO", que via RetornaCodigoOcorrencia vira '09': if (LSituacao = 'ATIVO') then Result := '02' else if (LSituacao = 'LIQUIDADO') then Result := '06' else if (LSituacao = 'BAIXADO') then Result := '09' else Result := '99'; A linha de proteção logo abaixo não conserta, porque ela só atua quando o código está vazio: if EstaVazio(ARetornoWS.DadosRet.TituloRet.CodigoEstadoTituloCobranca) then ARetornoWS.DadosRet.TituloRet.CodigoEstadoTituloCobranca := RetornaCodigoOcorrencia(...); Como o código já estava '09', o EstaVazio dá falso e ele permanece '09'. Ou seja: o retorno fica com estado textual LIQUIDADO e código de ocorrência 09 (baixa) — divergentes. Quem consome o CodigoEstadoTituloCobranca (que é o campo canônico pra automação) trata um pagamento PIX como baixa genérica e o título não é dado como liquidado/pago. O ajuste Quando reclassifico o estado pra LIQUIDADO, preciso reclassificar o código junto, na mesma condição — não dá pra depender do EstaVazio porque o campo já vem preenchido. Troquei a linha única por um begin..end setando os dois: if (ARetornoWS.DadosRet.TituloRet.EstadoTituloCobranca = 'BAIXADO') and (LJSONObject.ValueExists('writeOffDescription')) and (LJSONObject.AsString['writeOffDescription'] = 'BAIXA DE PAGAMENTO VIA PIX') then begin ARetornoWS.DadosRet.TituloRet.EstadoTituloCobranca := 'LIQUIDADO'; ARetornoWS.DadosRet.TituloRet.CodigoEstadoTituloCobranca := '06'; end; O '06' é exatamente o que o próprio RetornaCodigoOcorrencia('LIQUIDADO') devolveria, então mantém coerência com o resto da unit. Os dois campos passam a contar a mesma história: PIX pago → LIQUIDADO / 06. Faz sentido pra subir? Abraço. Segue anexo a modificação: ACBrBoletoRet_Santander_API.pas

Boa pergunta, na teoria pra quem usa 2 casas continua de boa, o schema que ajustei deveria aceitar os dois jeitos, então a prefeitura deveria ler por exemplo 5.2300 igualzinho a 5.23. Pra ser sincero eu não tenho nenhum outro cliente com alíquota de 2 casas em Campinas pra testar isso na prática agora. Pela lógica funciona (o valor é o mesmo e o schema ficou mais flexível), mas eu mesmo ainda não vi uma emissão real de 2 casas rodando depois da alteração. Se alguém aí tiver esse caso e quiser confirmar...

Bom dia, já havia sido postado o tópico Porém eu vi que uma parte do ACBR já foi atualizada mas mesmo assim ainda não está sendo impresso os valores do tributo em percentual (algumas notas preenchem apenas a % em vez do Valor) Então eu refiz essas mesmas alterações na unit ACBrNFSeXDANFSeRLPadraoNacional.pas Segue anexo ACBrNFSeXDANFSeRLPadraoNacional.pas

Ao emitir NFS-e para prestador, cuja **alíquota efetiva do ISS possui 4 casas decimais** (ex.: `4,2947%`), a prefeitura de Campinas rejeita a emissão com: A mesma nota, emitida manualmente pelo portal da prefeitura, é aceita normalmente. A Unit ISSCampinas.GravarXml.pas configura o formato da alíquota com **2 casas decimais**: procedure TNFSeW_ISSCampinas203.Configuracao; begin inherited Configuracao; FormatoAliq := tcDe2; // <-- trunca 4,2947 para 4,29 ... end; A tag `<Aliquota>` é gerada por esse `FormatoAliq` na base ABRASFv2 (`ACBrNFSeXGravarXml_ABRASFv2.pas`, método `GerarValoresServico`). Com `tcDe2`, a alíquota efetiva `4,2947` é gravada como `4,29` no XML enviado. Campinas calcula a **alíquota retida mínima** do Simples Nacional a partir do PGDAS (no caso, `4,2947`) e rejeita porque o valor informado (`4,29`) é **menor** que o mínimo indicado. A diferença é exclusivamente a precisão da alíquota: `4,29` (truncada) versus `4,2947` (efetiva). ## Correção sugerida São necessárias duas alterações, ambas no lado do ACBr (que distribui tanto o provider quanto o schema): ### 1. Formato da alíquota procedure TNFSeW_ISSCampinas203.Configuracao; begin inherited Configuracao; FormatoAliq := tcDe4; // permite a alíquota efetiva do Simples (4 casas) ... end; Após a mudança, o XML passa a enviar `<Aliquota>4.2947</Aliquota>`. ### 2. Schema — `Schemas/NFSe/ISSCampinas/2.03/nfse.xsd` O tipo `tsAliquota` está restrito a 2 casas decimais e total de 4 dígitos, o que faz a validação local do ACBr barrar a alíquota de 4 casas com: Erro de Validação: 1838 - Element 'Aliquota': [facet 'fractionDigits'] The value '4.2947' has more fractional digits than are allowed ('2'). <xsd:simpleType name="tsAliquota"> <xsd:restriction base="xsd:decimal"> <xsd:totalDigits value="4" /> <xsd:fractionDigits value="2" /> <xsd:minInclusive value="0" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="tsAliquota"> <xsd:restriction base="xsd:decimal"> <xsd:totalDigits value="5" /> <xsd:fractionDigits value="4" /> <xsd:minInclusive value="0" /> </xsd:restriction> </xsd:simpleType> ## Teste Com as duas alterações aplicadas, a NFS-e que vinha sendo rejeitada por L999 foi aceita pela prefeitura de Campinas em ambimente de Produção enviando a alíquota com 4 casas (`4,2947`). Segue anexo os 2 arquivos com a alteração ISSCampinas.GravarXml.pas nfse.xsd

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.