Nota Fiscal de Serviços no Rio de Janeiro com quebra de linhas

[Mauro Gomes]

5 horas atrás, Roberto Rocha_11114 disse:

OI Mauro. 

Eu  implementei essa solução e vi que se completar com espaços não funciona. E eu achei que completando com pontos fica feio também (e o problema todo é justamente a estética da NF). 

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".

[Mauro Gomes]

Em 05/07/2018 at 09:58, Daniel Simoes disse:

Desculpe mas não podemos implementar dessa maneira no ACBr 

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.

[Daniel Simoes]

Não sou o mantenedor do ACBrNFSe, talvez o @Italo Jurisato Junior possa responder...

A minha opinião é que não devemos modificar em nada um XML retornado de uma consulta, pois isso pode invalidar a assinatura do mesmo 

[Italo Giurizzato Junior]

Bom dia a todos,

Se tratando de NFS-e onde existem provedores que não requer que o RPS seja assinado (35 para ser mais preciso) com certeza ao retornar o XML da NFS-e não vai estar assinado.

Quanto a remoção das quebras não me recordo o motivo pelo qual elas foram inseridas.

[Mauro Gomes]

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

[Daniel Simoes]

Não acho que seja válido, inserir a propriedade TGeralConf.RetirarRetornoCRLF em ACBrDFeConfiguracoes.pas ... logo surgirão outros casos, quendo retirar apenas o CR, ou LF, ou outro caractere... quando o correto é retirar tudo,para assinar o XML, e é a prefeitura do RJ que não está interpretando XMLs com #xD#xA

No entanto, como eu já havia afirmado em tópicos anteriores, não acho correto modificarmos o XML retornado pelo WebService...

[Mauro Gomes]

3 horas atrás, Daniel Simoes disse:

Não acho que seja válido, inserir a propriedade TGeralConf.RetirarRetornoCRLF em ACBrDFeConfiguracoes.pas ... logo surgirão outros casos, quendo retirar apenas o CR, ou LF, ou outro caractere... quando o correto é retirar tudo, para assinar o XML, e é a prefeitura do RJ que não está interpretando XMLs com #xD#xA

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:

4 horas atrás, Daniel Simoes disse:

No entanto, como eu já havia afirmado em tópicos anteriores, não acho correto modificarmos o XML retornado pelo WebService...

Agradeço sua atenção ao assunto.

[Italo Giurizzato Junior]

Bom dia Mauro,

Fiz uma alteração no fonte do ACBrNFSe que acredito que vai resolver o problema de remover as quebras de linhas no XML de retorno.

Ainda hoje estarei enviando para o repositório.

[Daniel Simoes]

15 horas atrás, Mauro Gomes disse:

A propriedade criada TGeralConf.RetirarRetornoCRLF em ACBrDFeConfiguracoes.pas

O problema de modificar ACBrDFeConfiguracoes.pas, é que ela afeta TODOS os DFe's emitidos pelo ACBr... então, caso realmente seja necessária a propriedade, ela deveria ser criada em ACBrNFSeConfiguracoes.pas

[Mauro Gomes]

5 horas atrás, Italo Jurisato Junior disse:

Bom dia Mauro,

Fiz uma alteração no fonte do ACBrNFSe que acredito que vai resolver o problema de remover as quebras de linhas no XML de retorno.

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.

[Italo Giurizzato Junior]

Boa noite Mauro,

O grande X da questão é o seguinte.

Existe o projeto da NFS-e Padrão Nacional que estou torcendo muito que vire realidade.

Se o que penso se tornar realidade vamos ter uma propriedade de configuração inútil e o componente ACBrNFSe com a migração das cidades para o Padrão Nacional a cada dia será menos utilizado até ser extinto.

No momento eu prefiro incluir IFs e CASEs no código do ACBrNFSe para contornar a falta de padronização entre os provedores.

Uma outra solução é criar um campo de configuração no arquivo INI do provedor, por exemplo:

RemoverQuebradeLinha=S

Se esse campo não existir ou o seu valor for N a quebra de linha não será removida.

Uma nova propriedade de configuração seria incluída no ACBrNFSeConfiguracoes e utilizada pelo ACBrNFSeWebServices.

O que você acha?

 

[Mauro Gomes]

15 horas atrás, Italo Jurisato Junior disse:

Uma outra solução é criar um campo de configuração no arquivo INI do provedor, por exemplo:

RemoverQuebradeLinha=S

Se esse campo não existir ou o seu valor for N a quebra de linha não será removida.

Uma nova propriedade de configuração seria incluída no ACBrNFSeConfiguracoes e utilizada pelo ACBrNFSeWebServices.

O que você acha?

 

Bom dia Italo.

Acho que é uma ótima ideia, já baixei as alterações e testei, funcionaram perfeitamente.

Obrigado e um grande abraço.