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.

Olá Roberto e Italo, Estou acompanhando o post e tenho a mesma necessidade que o Roberto (manter quebras de linha no XML enviado), mas para dois municípios diferentes, onde explicarei o caso a seguir. Em primeiro lugar gostaria de parabenizá-los pela solução apresentada até aqui, apesar de não estar 100% resolvida, está muito bem encaminhada. Meu problema: O meu caso é o seguinte: tenho um cliente cuja matriz está no Rio de Janeiro/RJ, e tem uma filial em Duque de Caxias/RJ, por isso preciso que esta solução funcione para estes dois municípios. A questão é que depois de emitida a NFSe é enviado o link da nota na prefeitura por SMS ou por e-mail para o celular do cliente, que vai clicar para abrir a nota. O problema é que não posso gerar um PDF, pois os celulares geralmente não abrem PDF de forma nativa (somente se instalar um App adequado), além de não ser possível enviar o PDF por SMS. Então neste caso dependo totalmente da exibição da nota pelo site das prefeituras. O meu sistema já está funcionando e emitindo Notas pelas duas prefeituras, mas a empresa reclama que as diversas linhas do campo de discriminação dos serviços ficam emboladas em uma linha contínua, exatamente como no exemplo postado pelo Roberto. Minha sugestão: Roberto, eu vi que você disse que criou uma variável EMITINDONFSRIODEJANEIRO para indicar a não exclusão da quebra de linha, mas eu gostaria de sugerir que criássemos uma propriedade booleana na Configuração do Município para indicar isso. Eu acho que a melhor opção seria que esta configuração estivesse presente no arquivo .INI para permitir configurar facilmente de acordo com a necessidade. Acredito que todos os desenvolvedores que, por qualquer motivo, tenham a necessidade de abrir a nota diretamente no site da prefeitura, certamente usarão esta solução para resolver o problema das quebras de linha. Desta maneira, a solução não pode ficar amarrada a uma prefeitura específica. Sobre o problema de quebra de linha: Existe um detalhe que eu não sei se todos já analisaram a respeito da diferença entre a NF-e e as notas de serviço. O problema de quebra de linha também existe na NF-e, mas ninguém percebe por causa da maneira como ela funciona. Na NF-e as notas são geradas pela empresa e enviadas para a SEFAZ, o XML e o DANFe em PDF devem ser enviados por e-mail, então o problema das quebras de linhas na NF-e foi resolvido padronizando a impressão no DANFe usando um ";" e imprimindo da maneira correta. No caso das notas de serviço a empresa não consegue gerar a nota, mas precisa enviar um RPS para ser convertido em NFS-e pela prefeitura, que retorna o XML para a empresa, mas a consulta e/ou impressão da nota é feita pelo site da prefeitura. Observem que a própria prefeitura envia um e-mail para o seu cliente com o link para abrir a nota, e se o texto não tiver com as quebras de linha fica muito estranho a impressão. Esse problema também acontece quando consultamos uma NF-e no site "nfe.fazenda.gov.br", o texto das informações complementares ficam embolados em uma linha contínua separada por vários ";" Vejam esse exemplo de uma consulta pelo site da NF-e cujo texto de várias linhas ficou embolado numa linha contínua: Informações Complementares de Interesse do Contribuinte Descrição Documento emitido por ME ou EPP optante pelo SIMPLES NACIONAL, nao gera direito a credito fiscal de IPI.;Permite o aproveitamento do credito de ICMS no valor de R$10,28 correspondente a aliquota de 3,07%, nos termos do ART. 23 da LC 123/2006.;Procon: Rua da Ajuda n.05, Centro-RJ Tel: 151 / ALERJ: R.Alfandega n.08, Centro-RJ Tel: 0800-2827060.;ICMS SUBST. TRIB. CONF. DEC. 27427 DE 17/11/00; Pedido Interno=23704 Conclusão do meu post gigante: Na minha humilde opinião, precisamos fazer um tratamento diferenciado entre NF-e e NFS-e no que diz respeito a quebra de linha no XML. Acho que será necessário promover algumas alterações nos componentes para flexibilizar esta questão, pois como são as prefeituras que geram a NFS-e, a solução atual de tentar resolver o problema pela impressão do DANFS-e fica inconsistente com a versão que o cliente vê no site da prefeitura, e apesar dessa solução funcionar bem na NF-e, não é adequada para a NFS-e. Eu tenho acompanhado o trabalho fantástico da equipe ACBr em criar componentes flexíveis, muito bem estruturados e facilmente configuráveis. Acredito que o projeto ACBr merece uma solução bem elaborada e que mantenha compatibilidade com a versão atual do código, para que não haja mudança nos sistemas existentes, mas que permita alterar o comportamento para quem desejar configurar a quebra de linha. Eu já estou estudando o código-fonte para tentar contribuir com esta solução, acho que o debate será muito produtivo. PS: peço desculpas pelo post muito grande, mas não conseguiria cortar o texto sem perder a sequencia do raciocínio.

Ok Henrique. Aproveito para deixar um item para contribuir com esta padronização. Eu fiz uma verificação nos manuais da NF-e onde constam os modelos de DANFe e tem apenas um campo chamado "Fatura/Duplicata" com uma banda toda em branco, ou seja, pela SEFAZ cada um pode imprimir como desejar esta informação (visto que são dados relevantes apenas para o emissor/destinatário, não interessam ao Fisco), portanto pelo que percebi não há a obrigação de imprimir os dados da Fatura e nem a forma de pagamento. A informação que seria realmente indispensável seria os desdobramentos das duplicatas. Sendo assim gostaria de que colocassem na pauta desta conversa a sugestão de inclusão de uma propriedade que realmente suprimisse a impressão da Fatura, poderia deixar ligada por padrão e apenas quem não quiser imprimir desligaria. Obrigado por sua atenção.

Isto foi apenas um teste, quando fiz a emissão meu sistema preencheu corretamente com "venda a prazo", não há erro conceitual. Eu configurei o ExibeCampoFatura como "false" e testei a impressão, depois eu troquei para "venda a vista" e depois para "outros" a fim de testar todas as situações possíveis na impressão. Pode ver que os PDF's que anexei nem imprimiram o campo Fatura, apenas o campo de duplicatas devido ao código que eu havia alterado. Quando te mandei o XML esqueci de voltar o código para venda a prazo, peço que por favor considere como "venda a prazo" e troque no XML. Mas não fez diferença o tipo de pagamento, a banda sempre sai impressa em todos os casos. O que eu queria era que a banda de fatura não fosse impressa, pois a informação relevante para mim são as duplicatas, vencimentos e valores, e isso sai na outra banda. Eu tenho alguns casos de notas que imprimem 2 páginas do DANFe somente por causa de 1 item que sai na segunda página, ou seja, acabo imprimindo mais uma página somente por causa de 1 item. Se não tivesse esse campo de Fatura haveria espaço para imprimir todos em 1 só página. Quem desenvolve sistemas sabe como os clientes são exigentes, reclamam que tem que imprimir uma folha a mais por causa de 1 item e que nós desperdiçamos o espaço do DANFe imprimindo a informação de Fatura que não serve para nada, pois o número é o mesmo da nota e o valor também. Eu argumentei que este layout é padronizado pela Receita Federal e que precisa ser assim, mas ele me mostra o DANFe de outras empresas que não tem este campo fatura, somente as duplicatas. Enfim, acho que todo desenvolvedor já recebeu algum pedido deste tipo dos seus clientes, onde precisaria que fazer uma configuração personalizada. Quando eu vi essa propriedade "ExibeCampoFatura" imaginei que ela pudesse suprimir a impressão da banda e resolver o meu caso, mas percebi que ela apenas ignorava os dados preenchidos na Tag <fat> e prenchia apenas a descrição do tipo de pagamento, foi por isso que eu alterei o código-fonte imaginando que estava com defeito, mas depois você me explicou que a função desta propriedade era outra. Eu não me incomodo de imprimir a banda Fatura, a maioria dos clientes nunca reclamaram disso, mas eu pensei em fazer uma configuração no meu sistema para indicar que o cliente não deseja imprimir esta banda, resolvendo a demanda de quem não quer a impressão.

Caro Henrique Leonardo, Minha versão do código SVN foi completamente baixada ontem (11/05/16 às 18:12h). Fiz uma verificação agora para ver se houve alguma mudança nestas classes e vi que não houve. Eu anexei um XML de testes com 20 linhas no campo de informações complementares, e gerei um PDF modelo retrato mostrando o defeito e outro mostrando a correção. Repeti o mesmo para o modelo paisagem. Com relação a sua explicação sobre a propriedade ExibeCampoFatura, vou retirar do código a alteração que fiz para suprimir a impressão da Banda. Gostaria de saber se o motivo da impressão da Banda Fatura somente com a forma de pagamento é uma obrigação no layout do Danfe? Pois somente será impressa uma das expressões: 'PAGAMENTO À VISTA', 'PAGAMENTO À PRAZO', 'OUTROS'; O espaço reservado para a impressão dos itens acaba diminuindo pela impressão de uma informação não relevante uma vez que logo abaixo estamos imprimindo as duplicatas com os respectivos vencimentos e valores. Estou apenas levantando uma questão a se pensar, talvez criar uma outra propriedade "ImprimirBandaFatura" para não se confundir com a propriedade atual que indica outra função. Att, Mauro Gomes 35160578134845000167550010000039761000039763-nfe.xml DANFe-Retrato-com-defeito.pdf DANFe-Retrato-Corrigido.pdf DANFe-Paisagem-com-defeito.pdf DANFe-Paisagem-Corrigido.pdf Prezado Juliomar, Seguem os fontes conforme solicitado. Informo que removi do código a alteração que fiz para suprimir a impressão da Banda de Fatura, conforme comentários do Henrique Leonardo. Att, Mauro Gomes. ACBrNFeDANFeRL.pas ACBrNFeDANFeRL.dfm ACBrNFeDANFeRLRetrato.dfm ACBrNFeDANFeRLRetrato.lfm ACBrNFeDANFeRLRetrato.pas ACBrNFeDANFeRLPaisagem.dfm ACBrNFeDANFeRLPaisagem.lfm ACBrNFeDANFeRLPaisagem.pas

Detectei um problema na impressão do DANFe em "Fortes Report" quando o campo "Informações Complementares" possui mais de 10 linhas, o modelo Retrato estava imprimindo o campo normalmente no fim da página (com 10 linhas) e outro campo "Continuação das Informações Complementares" era impresso também na 1ª página logo abaixo dos produtos. Eu abri o código fonte para verificar o problema, e percebi que este campo de continuação não quebrava a página antes da sua impressão. Realizei a inclusão de um evento "BeforePrint" no referido campo testando se estava na primeira página e promovendo a quebra e o problema foi resolvido. Abri os fontes do modelo Paisagem e vi que tinha o mesmo problema e fiz as correções. Adicionalmente eu percebi que se a propriedade "ExibeCampoFatura" do DANFe estiver como "false" o campo fatura é impresso sem as informações da fatura, porém continua ocupando um espaço desnecessário no DANFe. Para resolver acrescentei uma linha configurando a propriedade "visible" da banda de Fatura o valor do "ExibeCampoFatura", para não imprimir esta banda caso a propriedade "ExibeCampoFatura" estiver como "false" . Estou postando as classes alteradas e gostaria de solicitar a gentileza por parte dos mantenedores do código-fonte do ACBr que analisem minhas alterações e em caso de aprovação incorpore-as ao código oficial. Abaixo eu indico onde fiz as alterações e descrevo o que foi alterado. 1) ACBrNFeDANFeRLRetrato.pas Inclusão na linha nº 2031 do código "rlbFaturaReal.Visible := fExibeCampoFatura;" dentro do método "TfrlDANFeRLRetrato.AddFaturaReal" a fim de suprimir a impressão do campo Fatura sem os dados quando a propriedade ExibeCampoFatura for "false"; Inclusão na linha nº 2374 do código de um método "rlbContinuacaoInformacoesComplementaresBeforePrint()" a fim de promover a quebra de página antes da impressão do campo "Continuação das Informações Complementares" devido ao excesso de linhas a serem impressas. 2) ACBrNFeDANFeRLPaisagem.pas Inclusão na linha nº 2021 do código "rlbFaturaReal.Visible := fExibeCampoFatura;" dentro do método "TfrlDANFeRLPaisagem.AddFaturaReal" a fim de suprimir a impressão do campo Fatura sem os dados quando a propriedade ExibeCampoFatura for "false"; Inclusão na linha nº 2378 do código de um método "rlbContinuacaoInformacoesComplementaresBeforePrint()" a fim de promover a quebra de página antes da impressão do campo "Continuação das Informações Complementares" devido ao excesso de linhas a serem impressas. 3) ACBrNFeDANFeRL.pas Alteração na linha nº 772 do código "for i := 1 to (iTotalLinhas + 10) do" dentro do método "TfrlDANFeRL.InsereLinhas()" mudando o valor "+ 10" para "+ 20". Este código limitava a quantidade de linhas incluídas no campo para 10 linhas. Não sei os motivos deste limite de 10 linhas, mas o conteúdo do XML deste campo estava sendo cortado por este código, eu resolvi parcialmente este corte aumentando o limite para 20 linhas, mas se tiver mais de 20 linhas ainda ocorrerá o corte. Por favor analisar se faz sentido ter esse limite de linhas neste campo e qual deveria ser este número. Agradeço a atenção. Att, Mauro Gomes. ACBrNFeDANFeRL.dfm ACBrNFeDANFeRL.pas ACBrNFeDANFeRLRetrato.pas ACBrNFeDANFeRLRetrato.dfm ACBrNFeDANFeRLPaisagem.dfm ACBrNFeDANFeRLPaisagem.pas

Ok Juliomar, vou verificar. Nunca havia alterado o código de componente do ACBr antes, eu simplesmente peguei o código original, avaliei os erros e fiz funcionar. Mas não sei ao certo como é o padrão, vou analisar o exemplo que me indicou pra ver se consigo fazer dentro do mesmo padrão. Aproveitando a oportunidade para lhe perguntar: existe alguma documentação que indique quais são os padrões de codificação dos componentes para eu estudar? Obrigado.

Prezado Juliomar Marchetti, Eu fiz a migração do código do ACBrGNRE para o trunk2, e após alterar os fontes executei o "ACBrInstall_Trunk2.exe", marcando o componente e mais os dois componentes de Impressão (Fast e Fortes). O instalador concluiu tudo com sucesso. Em seguida ajustei o Projeto de Exemplo para que também funcionasse e consegui executar a opção "Consulta Configuração da UF". Solicito a gentileza de analisar minhas alterações e incorporá-las ao código do trunk2 caso sejam aprovadas. Obrigado. Seguem anexos os arquivos .ZIP com as pastas de Fontes e Exemplos: Fontes_ACBrDFe_ACBrGNRE.zip Exemplos_ACBrDFe_ACBrGNRE.zip

Amigo, está faltando a pasta "acbr\Fontes\ZLibExGZ" configurada no Delphi. No Delphi 7 vá no menu "Tools", opção "Environment Options", na aba "Library" clique em "Library Path" e adicione o caminho desta pasta. Caso utilize o ACBrInstall ele fará essa configuração automaticamente.

Prezados senhores, essa semana passei a usar o DanfeRaveCodeBase e tive exatamente o mesmo problema que vocês, a imagem da Logo não saía de jeito nenhum. Troquei a imagem JPEG várias vezes, fiz um debug nos fontes e vi que a imagem era carregada, mas não imprimia. A outra versão do DanfeRave funcionava perfeitamente, então fiz diversas pesquisas e descobri que o problema realmente é um BUG do Rave na versão que vem com o Delphi 7. A extinta Borland tinha um Patch de correção desta versão para o Delphi 7 no link: ftp://ftpd.borland.com/devsupport/delphi/d7/rave/rave_be_5_0_8.exe mas não tentem baixar pois o endereço não existe mais. Consegui pesquisar na Rede e achei a essa versão que era disponibilizada, baixei e instalei e FUNCIONOU perfeitamente no DanfeRaveCodeBase. Testei com várias logos e todas são impressas normalmente. Então segue o passo a passo pra quem precisa corrigir esta versão do Rave com problemas: OBS 1: esta versão do Rave é a mesma que vem com o Delphi 7, porém com correções de BUGs. Não é a versão vendida pelo fabricante que precisa de licença. Ela era disponibilizada gratuitamente pela Borland pra quem tinha o Delphi 7, isto significa que não é uma versão pirata ou que ofenda direitos autorais do fabricante. Existe outra opção que é comprar uma licença do Rave mais atualizada, mas fica a critério de cada um. OBS 2: siga a sequência corretamente caso contrário pode não funcionar. Passo 1) Baixar o patch do Rave versão 5.0.8 no link: http://www.4shared.com/get/z-w6vsEI/rave_be_5_0_8.html Caso não consiga baixar por este link pesquise no Google usando o termo: "rave_be_5_0_8.exe" Passo 2) Abrir o Delphi 7 e clicar em "Component" - Opção "Install Packages", clique uma vez no ACBrDanfeRV e clique no botão "Remove". Faça o mesmo com o componente "ACBrDanfeRVCodeBase"; Faça o mesmo com o componente "Rave Reports"; Feche o Delphi. Passo 3) Abrir o Painel de Controle -> Programas e Recursos (ou Adicionar e Remover Programas) -> procure o Borland Delphi 7, e clique em ALTERAR (cuidado para não remover). Escolha a opção "Modify", na próxima tela desmarque a opção Rave Reports para desinstalá-lo do Delphi, confirme e finalize. Passo 4) Execute o programa que você baixou "rave_be_5_0_8.exe" para instalar o Rave com as correções. Passo 5) Abrir o Delphi 7 e clicar em "Component" - Opção "Install Packages", clique no botão "Add" e escolha o arquivo "C:\Arquivos de Programas\Borland\Delphi7\Bin\dclRave70.bpl". Reinstale os componentes "ACBrDanfeRV" e "ACBrDanfeRVCodeBase"; Agora é só testar a impressão usando imagem JPEG na Logo do ACBrDanfeRVCodeBase, provavelmente vai funcionar, pois no meu projeto funcionou. Um grande abraço e boa sorte.