Mauro Gomes

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