Mauro Gomes

@Henrique - Interativa S. o código que foi disponibilizado no dia 15/06/26 com a correção deste e de outros problemas ainda está sob análise do time do ACBr e por isso não foi publicado oficialmente no SVN do ACBr. Você tem a opção de baixar as 2 Units da API do Bradesco e atualizar na tua máquina para usar estas correções, segue o post:

@Gabriel Fonseca Borel se você abrir os 2 PDFs que postei em 15/06/26 vai ter em cada um uma tabela de mensagens de erro, no PDF do boleto comum se chama "Tabela 5 – Mensagem/Causa", e no PDF do QRCode se chama "Tabela 4 – Causa". Porém este código "CBTT0004" não existe em nenhuma das documentações do Bradesco (para surpresa de zero pessoas, a DOC do Bradesco é problemática mesmo). Não sei o que você estava tentando fazer e nem que tipo de boleto está usando (Comum ou QRCode) quando recebeu este erro, mas tem um Post em 26/05/26 do @TiagoFZ que recebeu exatamente esta mensagem, ele disse que estava enviando com dados bancários errados que o gerente passou. Acho que suas opções são abrir um chamado com o suporte do Bradesco ou confirmar com o gerente se os dados estão corretos, pois a mensagem da API não deve ajudar a descobrir o problema.

@thi4182 eu tentei usar o SandBox com dados próprios do meu cliente, mas sem sucesso, é obrigatório usar os dados 'FAKE' que vem naquele exemplo na Collection do Postman, é tão ridículo que precisa configurar um CPF pra funcionar. Nunca vi um ambiente de SandBox tão inútil pra testar um sistema, porque depois que você fizer dar certo na SandBox precisa reconfigurar tudo novamente pra testar em Produção com os dados reais, então pra quê serve testar na SandBox? Desisti de usar a SandBox e testei tudo em produção com boletos de 1 real e depois fiz a baixa. Não sei o que passa na cabeça de quem faz um ambiente desses, é bizarro demais.

Em relação a este problema com o valor nominal do título, eu consegui identificar o seguinte padrão de quando ele aceita e quando rejeita: Eu vi acontecer com a API de Boleto Comum nos campos: vlNominalTitulo, vlJuros e vlAbatimento. Esta API exige que o valor numérico seja enviado com 2 casas decimais, mas não aceita que o número esteja entre aspas "". Por exemplo, se enviar o campo "vlNominalTitulo":"250.00" com o tipo String a API vai retornar o erro: "ErrorCode=422 / Result=Erro na conversão de campos" Se tentar fazer o input dos campos com valor Double diretamente no componente TACBrJSONObject, vai funcionar apenas para boletos que tenham centavos com números não zerados (como 250.35), porém o valor (250.00) perde as casas decimais na saída do JSON como se fosse um valor inteiro, retornando outro erro de validação por parte da API. Ou seja, se enviar o campo "vlNominalTitulo":250 com o tipo numérico a API vai retornar este erro: ErrorCode=400 / Result={ "errors" : [ "Campo (vlNominalTitulo) deve conter somente números com duas casas decimais (Ex 1000.00)." ] O componente TACBrJSONObject usado pelo ACBr não aceita formatação em campos numéricos, então mesmo que o valor seja um Double ele vai mandar como inteiro no JSON se o valor tiver os centavos zerados, e vai ofender a famigerada regra de validação da API do Bradesco. Acho que uma possível solução prática seria alterar o componente TACBrJSONObject e adicionar mais um parâmetro de casas decimais de saída no JSON para os valores Double, desta forma teríamos a padronização do valor com a quantidade de casas decimais exigida pela API, sendo que em outros campos de percentual ela exige passar cinco casas decimais ao invés de duas. Acho que vale a pena testarem se esta solução resolveria definitivamente o problema.

Eu precisei fazer a integração com a API do Bradesco e vi que a versão atual do componente não funcionava, achei este tópico e peguei os fontes que a Marcia Magall postou em 22/05/26, e a partir destes fontes alterados por ela eu baixei o manual do Bradesco para boleto QRCode e Comum, e comecei a testar com credencial em produção o conjunto de Registro+Alteração+Consulta para os dois tipos de boleto. Recebi alguns erros, por exemplo, quando tentei registrar um boleto com valor de abatimento no boleto comum e o abatimento foi zerado, assim como outras mensagens de erro de conversão ou validação que a API retornava. O código que peguei funcionava o registro para alguns casos e dava erro em outros, por exemplo, funcionava o registro dos boletos se mandasse o percentual de juros, mas se mandasse como valor ao dia dava erro de conversão. Todos os casos que percebi não funcionar foram ajustados. O Bradesco foi de longe um dos piores bancos que já analisei, o ecossistema deles é caótico, a documentação não bate 100% com a realidade da API, os contratos JSON não tem um padrão de nomenclatura, usam padrões diferentes de formatação numérica dentro do mesmo contrato, diversos erros retornam como HTTP 400 ou 500 sem mensagem de validação e te obriga a ficar fazendo tentativa e erro pra conseguir descobrir o que precisa ser corrigido. A parte da alteração foi a pior, pois exige que envie todos os campos possíveis com valor zerado e mude o valor somente do campo que deseja alterar, se faltar um campo ele já recusa a chamada da alteração. Depois de terminar a sequência de testes o componente ficou com estas funcionalidades retornando com sucesso: Registro de boleto com QRCode e Comum (com juros em valor e também em percentual, com abatimento e sem abatimento); Baixa de Boleto com QRCode e Comum. Alteração de boleto com QRCode e Comum (Vencimento e Valor Abatimento estão Ok) - Obs: faltou implementar demais campos: Desconto, Juros, Protesto, etc. Consulta detalhada de boleto com QRCode e Comum. Consulta de listagem de boletos pagos com índice de paginação, com QRCode e Comum. Diversas correções que eu fiz no componente estão com comentários explicando o motivo de ter alterado e qual o cenário causava o problema. Tenho os registros dos Logs de envio/retorno do componente para todas as operações que foram testadas em produção. Fiz o possível para manter o código compatível com a API LEGADA, mas não tenho como testar essa compatibilidade, nem mesmo sei se este LEGADO ainda está disponível pra uso. Estou a disposição do time responsável pela tarefa ACBR-9418 para ajudar com qualquer teste ou documentação que precisarem. API_Cobrança_DOWNLOAD_V1.6.1.pdf API_Cobrança_QRCode_DOWNLOAD_V1.0.3.pdf ACBrBoletoW_Bradesco.pas ACBrBoletoRet_Bradesco.pas

Achei muito boa a sua argumentação, realmente é mais vantajoso convergir para o TEF.

Bom dia Italo. Acho que é uma ótima ideia, já baixei as alterações e testei, funcionaram perfeitamente. Obrigado e um grande abraço.

Olá Italo, agradeço sua resposta, eu baixei a atualização que você enviou, e percebi que você fez um teste para ver se a prefeitura era do RJ para não remover as linhas, mas continua removendo para todas as outras. Desta maneira o problema continuará ocorrendo para as Prefeituras de todo o Brasil que enviarem um XML de resposta pelo WebService que contenha um CR+LF no arquivo. Eu tenho, por exemplo, a Prefeitura de Duque de Caxias onde ocorre exatamente o mesmo problema. Este código do componente do ACBr promove uma espécie de "mutilação" da resposta da Prefeitura, pois como ele remove as quebra de linha da resposta as palavras ficam emboladas no texto, a primeira palavra da linha 02 fica colada com a última palavra da linha 01, a assim por diante em todas as linhas. Conforme comentário do Daniel Simões a resposta do WebService nunca deveria ser alterada, mas preservada integralmente como foi recebida. Por isso eu perguntei a vocês qual era a finalidade de remover estes caracteres de uma resposta do WebService, veja no código como os caracteres de CR e LF são eliminados, o texto resultante disso ficará deformado, quando você junta duas palavras acaba criando uma terceira palavra que nem existe. // Remover quebras de linha // if (FProvedor <> proRJ) then begin FPRetornoWS := StringReplace(FPRetornoWS, #10, '', [rfReplaceAll]); FPRetornoWS := StringReplace(FPRetornoWS, #13, '', [rfReplaceAll]); end; Como eu não sabia o motivo de ter que fazer isso na resposta, eu criei a Propriedade Booleana para desligar esse comportamento, e caso alguém quisesse continuar fazendo isso, poderia configurar como True. Coloquei o padrão como False porque entendi que não faz sentido alterar um XML de resposta do WebService. Outro detalhe importante: se veio um CR+LF no XML de resposta dividindo várias linhas, porque trocar por vazio? Se a lógica é retirar o caractere especial, deveria trocar por pipe ou por um ponto e vírgula, ou por qualquer coisa menos trocar por vazio, que causa a ligação indevida das palavras e deformação das informações do XML da NFSe. Se você chegar a conclusão que essa troca não faz sentido, nem precisa usar uma propriedade, simplesmente pode excluir essas linhas do código do componente e não fazer mais isso. Observe que isso não é um problema da Prefeitura do RJ, o caso inicial que tratamos da quebra de linha no envio do RPS já está resolvido, eu já entendi que não pode mexer e eu não quero mexer nisso. Este problema do retorno afeta as prefeituras em todo o Brasil que devolverem uma quebra de linha na resposta. A solução seria remover esse código do ACBr ou parametrizar para quem quiser fazer isso ou não, se for o caso de preservar essa troca no código. Mas deveria trocar por um caractere que represente a quebra e não trocar por vazio. Por favor poderia analisar estes detalhes? Obrigado e um abraço.

Olá Daniel, agradeço sua resposta, mas acho que talvez você não tenha entendido completamente o post, você ainda está se referindo à assinatura do XML antes do envio, essa parte já ficou esclarecida nos posts anteriores, nós já entendemos que não podemos manter as quebras de linha no XML dos RPS e que tudo tem que ser retirado, este assunto já foi superado, não queremos mais mexer com isso. Esta alteração que estou propondo não modifica em nada o XML que será assinado e enviado, ela serve exclusivamente para evitar a retirada da quebra de linha do RETORNO apenas, pois está tratando um problema de modificação do Retorno do WebService da Prefeitura. Atualmente o ACBr corta os caracteres de quebra de linha e embola o texto original do XML que foi retornado pelo WebService, quando o mesmo possui as quebras de linha. Este problema já existia no código do ACBr e esta proposta é para corrigi-lo. A propriedade criada TGeralConf.RetirarRetornoCRLF em ACBrDFeConfiguracoes.pas serve para sinalizar este tratamento no RETORNO do WebService e não no envio, por isso tem este nome. Eu até indiquei no meu post que se o local estivesse inadequado poderiam indicar outro local para colocar a propriedade, ou mesmo se o nome estiver ruim, podemos chamar de outro nome mais adequado. Se fosse o caso poderíamos simplesmente remover o código que altera o XML recebido e corta os caracteres sem ter a propriedade para controlar isso, pois não faz sentido mudar um retorno da Prefeitura, mas não sabemos se em algum caso causaremos problemas nesse tratamento com o código legado, por isso criei a propriedade para permitir que alguém possa manter o comportamento anterior caso seja necessário, mantendo a retrocompatibilidade. Vale ressaltar que este problema existe para todas as prefeituras e não apenas para o RJ, pois corta o XML de retorno do WebService em todos os casos. Gostaria de lhe pedir que por favor se puder fazer uma releitura do post considerando que as alterações propostas mudam apenas o tratamento do retorno do WebService, conforme você já havia afirmado que o componente não deveria fazer isso, esta alteração se propõe a resolver este problema: Agradeço sua atenção ao assunto.

Boa tarde a todos. Gostaria de pedir ao @Italo Jurisato Junior que avaliasse minhas correções sobre o problema da eliminação das quebras de linhas retornadas no XML pelos servidores da Prefeituras. Os fontes alterados seguem anexos neste post, as alterações foram: No arquivo "Fontes\ACBrDFe\ACBrDFeConfiguracoes.pas" = na classe "TGeralConf" foi incluída uma nova propriedade Booleana chamada "RetirarRetornoCRLF", a fim de permitir desligar a remoção das quebras de linha das respostas (apenas no RETORNO). Eu até pensei em colocar isso na configuração da NFSe, mas eu vi que já existiam outras duas propriedades chamadas "RetirarAcentos" e "RetirarEspacos", achei que seria mais coerente colocar junto destas, caso este não seja o melhor local, favor me indicar outro. No arquivo "Fontes\ACBrDFe\ACBrNFSe\ACBrNFSeWebServices.pas" = foi alterada a função "TNFSeWebService.ExtrairRetorno()", para testar a propriedade "RetirarRetornoCRLF" e somente remover as quebras de linha das respostas caso o valor seja TRUE. Adicionalmente fiz outra correção na remoção das quebras de linha, pois o código anterior tinha o problema de "cortar" a resposta, uma vez que trocava as quebras por vazio (''), fazendo com que o texto original do XML ficasse todo embolado. Nesta correção, mesmo removendo as quebras de linha, caso esteja configurado como TRUE, elas são trocadas por um pipe '|', impedindo que duas palavras em linhas diferentes se juntem e embole o texto. A seguir segue a explicação dos motivos das minhas alterações: O problema original: O problema original pode ser verificado quando você emite uma Nota Fiscal de Serviços pelo site da Prefeitura e inclui quebras de linha no texto, em seguida solicita a consulta das notas por Data e recebe essa nota em uma resposta com o XML da Nota. O código anterior simplesmente "cortava" a resposta da Prefeitura, pois trocava as quebras por vazio (''). Como exemplo, caso na Nota Original estivesse escrito: primeira linha segunda linha O retorno gravado no XML pelo ACBr era: primeira linhasegunda linha Desta forma o sentido do texto se perdia devido a junção de palavras que antes eram separadas por quebras de linha. Eu acredito que esse problema não deve ter sido diagnosticado antes porque as quebras de linha são removidas no envio dos RPS, então nunca retornará uma quebra que não existe. Mas quando você apenas lê a nota emitida pela Prefeitura com a quebra de linha, o problema fica evidente. A correção do problema: Para corrigir o problema, eu percebi que se tratava de duas questões: A primeira questão era permitir escolher remover ou não as quebras de linha da resposta. Isso se resolveu facilmente com a criação de uma propriedade Booleana. Eu usei a lógica para determinar o comportamento padrão: como a resposta é um XML retornado pela Prefeitura, não encontrei motivo para remover ou alterar esse retorno, então pela lógica deixei a propriedade = FALSE como padrão, ou seja, nenhuma quebra de linha será removida por padrão. Caso alguém tenha a necessidade de remover as quebras basta mudar para TRUE. A segunda questão era para quem marcou a propriedade como TRUE para remover as quebras, deveria fazer isso de maneira consistente, ou seja, sem causar a perda do sentido do texto ao juntar as palavras, sendo necessário trocar obrigatoriamente as quebras de linha por alguma coisa diferente de vazio (''). Eu fiz um teste trocando por um pipe (|) e percebi que o DANFSe do ACBr imprimiu corretamente as quebras de linha do texto, pois reconheceu o pipe como quebra, então acho que essa foi a melhor opção. Análise do código: Dentro da função eu vi que tinham vários códigos fazendo troca da quebra de linha, tentei entender o objetivo de cada um para fazer um ajuste consistente, vejam como ficou: function TNFSeWebService.ExtrairRetorno(GrupoMsgRet: String): String; var AuxXML, XMLRet: String; begin // Alguns provedores retornam a resposta em String // Aplicado a conversão de String para XML FPRetornoWS := StringReplace(StringReplace(FPRetornoWS, '&lt;', '<', [rfReplaceAll]), '&gt;', '>', [rfReplaceAll]); FPRetornoWS := StringReplace(FPRetornoWS, '#9#9#9#9', '', [rfReplaceAll]); //proCONAM // Remover quebras de linha do RETORNO if FPConfiguracoesNFSe.Geral.RetirarRetornoCRLF then begin // removendo a quebra de linha e trocando por |(pipe) FPRetornoWS := StringReplace(FPRetornoWS, #13#10 , '|', [rfReplaceAll]); FPRetornoWS := StringReplace(FPRetornoWS, '&#xD;&#xA;', '|', [rfReplaceAll]); FPRetornoWS := StringReplace(FPRetornoWS, '&#xd;&#xa;', '|', [rfReplaceAll]); // trocando a TAG <br> por |(pipe) FPRetornoWS := StringReplace(FPRetornoWS, 'lt;brgt;' , '|', [rfReplaceAll]); // trocando estes caracteres isoladamente FPRetornoWS := StringReplace(FPRetornoWS, #13 , '|', [rfReplaceAll]); FPRetornoWS := StringReplace(FPRetornoWS, #10 , '|', [rfReplaceAll]); FPRetornoWS := StringReplace(FPRetornoWS, '&#xD;' , '|', [rfReplaceAll]); FPRetornoWS := StringReplace(FPRetornoWS, '&#xd;' , '|', [rfReplaceAll]); FPRetornoWS := StringReplace(FPRetornoWS, '&#xA;' , '|', [rfReplaceAll]); FPRetornoWS := StringReplace(FPRetornoWS, '&#xa;' , '|', [rfReplaceAll]); end; if (FProvedor <> proNFSeBrasil) then FPRetornoWS := StringReplace(FPRetornoWS, '&amp;' , '', [rfReplaceAll]); FPRetornoWS := RemoverDeclaracaoXML(FPRetornoWS); //( ... Continua ... ) Em primeiro lugar não mexi nas trocas que não estavam relacionadas com a quebra de linha, eu vi que existem outros códigos sendo eliminados da resposta, mas como eu não tenho condições de testar por não saber para que servem e nem a qual prefeitura atendem, achei melhor não mexer e deixar como estava. Os códigos #13 e #10 estavam sendo tratados isoladamente para eliminação, alterei para que a troca fosse do conjunto #13#10 pelo 'pipe', mas mantive depois a troca dos caracteres isolados, talvez alguma prefeitura mande desse jeito, então continuará funcionando. Percebi que havia a eliminação da TAG br (do XML e HTML), por isso inclui na lista de trocas pelo 'pipe', mas não consegui testar por não saber qual prefeitura retorna com TAG's. Acredito que funcionará de maneira semelhante por se tratar de caractere de quebra de linha. Solicito a gentileza de avaliar as minhas correções, e em caso de aprovação, incorporá-las ao ACBr. Obrigado, Att, Mauro Gomes. ACBrDFeConfiguracoes.pas ACBrNFSeWebServices.pas

Olá Daniel, eu gostaria de tirar uma dúvida com você, por gentileza. Eu fiz um teste emitindo uma NFS-e direto pelo site da Prefeitura, e digitei as quebras de linha, e é claro que funcionou porque o ambiente é deles. Em seguida consultei a nota gerada pelo ACBr para ler o XML retornado, e percebi que veio sem quebra de linha com as palavras do texto "coladas", nem um espaço entre as linhas. Eu abri o código fonte da "ACBrNFSeWebServices.pas" e vi que dentro do método TNFSeWebService.ExtrairRetorno() na linha 1050 tinha este código: FPRetornoWS := StringReplace(FPRetornoWS, #10 , '', [rfReplaceAll]); FPRetornoWS := StringReplace(FPRetornoWS, #13 , '', [rfReplaceAll]); Eu comentei estas duas linhas e repeti a consulta, e o XML da NFS-e retornado agora tinha as quebras de linha que foram enviadas pela prefeitura, e o texto estava perfeito com todas as divisões de linha. A minha pergunta é: Qual seria a necessidade de eliminar as quebras de linha da resposta no retorno? Eu entendi que para enviar é obrigatório por causa da assinatura e de manter os padrões, mas no caso do retorno estamos recebendo um XML retornado pelo WebService da Prefeitura. Se você puder analisar a questão eu te agradeço pela atenção. Um abraço.

Olá Roberto. Concordo que a estética não ficou ideal, mas pra mim é melhor do que tudo embolado em uma linha só, sendo mais difícil de ler. Eu fiz um outro teste que o resultado estético ficou melhor, foi adicionando uma linha inteira de traços sublinhados "_" (95 caracteres) no lugar da quebra de linha, assim forçando deixar uma linha vazia pra escrever na linha debaixo. Veja a imagem: O texto ficou assim: TESTE DE SERVICO. _______________________________________________________________________________________________ LINHA 02. _______________________________________________________________________________________________ LINHA 03. _______________________________________________________________________________________________ Eu achei que a estética ficou melhor do que usando os pontos, deu a impressão de que a área onde escrevemos os serviços ficou "pautada".

Boa tarde. Eu consegui fazer um teste que resolveu parcialmente o meu problema, eu li no manual em PDF na descrição do campo discriminação dos serviços, que diz o seguinte: "Este campo é impresso num retângulo com 95 caracteres de largura e 24 linhas de altura" Então eu escrevi uma função que divide o texto em linhas, e para cada linha formata a largura com 95 caracteres, completando com "." pontos e separando por um espaço, dentro de uma String única e contínua. Gerei uma nota de teste com o seguinte texto: TESTE DE SERVICO. ............................................................................. LINHA 02. ..................................................................................... LINHA 03. ..................................................................................... E na impressão pelo site da prefeitura do Rio de Janeiro/RJ e ficou direitinho, com todas as linhas separadas, vejam a imagem: Porém na impressão pelo ACBr ficou tudo numa linha só, mas como eu utilizo somente a impressão da prefeitura não tem problema pra mim. Desta forma eu consegui contornar o problema sem ter que mexer no ACBr. Eu repeti o teste na prefeitura de Duque de Caxias/RJ, e funcionou de maneira idêntica, apesar de ser outro provedor, os sistemas destas duas são incrivelmente semelhantes. Não sei se em outras prefeituras vai funcionar da mesma maneira, apesar de não ser a melhor solução, contorna o problema.

Olá Roberto, Este manual que indica o uso do pipe se refere ao envio de arquivo TXT para importação dos RPS através de upload pelo site da Prefeitura do Rio. Existe outro manual referente ao uso dos webservices para o envio automatizado dos RPS, nesse manual não existe essa referência ao pipe como quebra de linha. https://notacarioca.rio.gov.br/files/manuais/NFSe_layout_rps_xml.pdf Eu fiz a emissão de 04 notas de serviço para testar, e nenhuma delas funcionou a quebra de linha. Eu testei usando 1 pipe, 2 pipes, #xA e #xD#xA, com as seguintes descrições de serviços: TESTE DE SERVICO.|LINHA 02.|LINHA 03. TESTE DE SERVICO.||LINHA 02.||LINHA 03. TESTE DE SERVICO.#xALINHA 02.#xALINHA 03. TESTE DE SERVICO.#xD#xALINHA 02.#xD#xALINHA 03. Deveria ter saído da seguinte maneira: TESTE DE SERVICO. LINHA 02. LINHA 03. Mas saiu tudo em uma linha com os caracteres no meio. Roberto, você disse que testou usando o pipe e funcionou, poderia me dizer como foi que você fez esse teste?

Olá Daniel, obrigado pelo seu esclarecimento. Eu não sabia que era uma exigência remover as quebras de linha antes de assinar o XML.