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

[Roberto Rocha_11114]

Desde que uso o ACBR tenho um incômodo puramente estético que é de poder gerar NFSe (Rio de Janeiro) com quebras de linha na descrição dos serviços. 
O problema ocorre porque para o RIo de Janeiro, a quebra de linha deve ser enviada mesmo com #13#10 e não com qualquer outra sequencia de caracteres que simule a quebra de linha

Dei uma olhada nos fontes do ACBR, e estou sugerindo uma mudança para que a quebra de linha possa ser implementada no ACBR. Comigo aqui testou e deu certo.
1º) Em pnfsNFSeW_ABRASFv2

    onde tem Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace( NFSe.Servico.ItemServico.Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR);
    substituir por 
         if FProvedor=proRJ Then
            Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace( NFSe.Servico.ItemServico.Discriminacao, ';', #13#10, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR)
        Else
            Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace( NFSe.Servico.ItemServico.Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR)
 

2º) Em ACBrDFeSSL
Tirar as linhas 
  // Removendo quebras de linha //
  XmlAss := StringReplace(XmlAss, #10, '', [rfReplaceAll]);
  XmlAss := StringReplace(XmlAss, #13, '', [rfReplaceAll]);
 

3º) Em ACBrDFeSSL
Logo depois de 
  if PosSig > 0 then
  begin
Acrescentar 
      XmlAss := copy(XmlAss, 1, PosSig - 1) + StringReplace(copy(XmlAss, PosSig, length(XmlAss)),#13, '', [rfReplaceAll]);  
      XmlAss := copy(XmlAss, 1, PosSig - 1) + StringReplace(copy(XmlAss, PosSig, length(XmlAss)),#10, '', [rfReplaceAll]);  

 

Assim, o comando de tirar #13 #10 fica restrito somente a tirar estes caracteres da assinatura e não de todo o XML gerado.

Abs

     

 

[Italo Giurizzato Junior]

Boa noite Roberto,

Favor anexar os fontes que você alterou para que possamos avaliar e caso esteja tudo OK, vamos disponibilizar no repositório.

[Roberto Rocha_11114]

Olá Italo 
Bom dia. 
Estou respondendo com atraso de dois anos. Me desculpe. Mas naquele momento eu estava com o Trunk desatualizado e não queria atualizar e me ver forçado a refazer as alterações que eram necessárias todas de novo. Daí que não lhe respondi. 
Agora atualizei o Trunk , refiz os ajustes que preciso fazer para que a NF do Rio de Janeiro fique com quebras de linha (mais estético, simplesmente isso) e vou indicar o que tenho tido que fazer para ter esse recurso. 

 

Em pnfsNFSeW_ABRASFv1;

// Inclui essas 4 linha abaixo em procedure TNFSeW_ABRASFv1.GerarServicoValores;  (para que os #13#10 não sejam excluídos em WCAmpoNFSe
  if FProvedor in [proRJ] Then Begin
     Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1, StringReplace( FNFSe.Servico.Discriminacao, #13#10,'||', [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR);
     Gerador.ArquivoFormatoXML := StringReplace(Gerador.ArquivoFormatoXML,'||',#13#10,[rfReplaceAll, rfIgnoreCase] );
  End Else
/////////////////////////////////////////////////////////////////////
  Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1,StringReplace(FNFSe.Servico.Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR);  // Essa linha é a original
Depois
// Inclui essas 4 linha abaixo em procedure TNFSeW_ABRASFv1.GerarListaServicos;  (para que os #13#10 não sejam excluídos em WCAmpoNFSe
  if FProvedor in [proRJ] Then Begin
    Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1,
                    StringReplace( NFSe.Servico.ItemServico.Discriminacao,  #13#10,'||', [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR);
     Gerador.ArquivoFormatoXML := StringReplace(Gerador.ArquivoFormatoXML,'||',#13#10,[rfReplaceAll, rfIgnoreCase] );
  End Else
/////////////////////////////////////////////////////////////////////
    Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1,
                    StringReplace( NFSe.Servico.ItemServico.Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR);

 

Em ACBrDFeSSL;

function TDFeSSLXmlSignClass.AjustarXMLAssinado(const ConteudoXML: String;  X509DER: String): String;
var
  XmlAss: String;
  PosSig, PosIni, PosFim: Integer;

  function RemoveEspacos( const AXML, TagIni, TagFim : String): String;
  begin
    Result := '';
    PosIni := PosLast(TagIni, AXML);
    if PosIni > 0 then
    begin
      PosFim := PosEx(TagFim, AXML, PosIni + 1);
      if PosFim > 0 then
        Result := copy(AXML, 1, PosIni - 1) +
                  StringReplace(copy(AXML, PosIni, PosFim-PosIni), ' ', '', [rfReplaceAll])+
                  copy(AXML, PosFim, Length(AXML));
// Inclui essas duas linhas para excluir as quebras de linha da assinatura /////////////////////
        Result := copy(AXML, 1, PosIni - 1) +StringReplace(copy(AXML, PosIni, PosFim-PosIni), #13, '', [rfReplaceAll])+copy(AXML, PosFim, Length(AXML));
        Result := copy(AXML, 1, PosIni - 1) +StringReplace(copy(AXML, PosIni, PosFim-PosIni), #10, '', [rfReplaceAll])+copy(AXML, PosFim, Length(AXML));
//////////////////////////////////////////////////////////////////
    end;

 

E tive que cancelar a remoção de quebras de linha que vinha por padrão, (no original elas não estão como comentário)

  // Removendo quebras de linha //
//  XmlAss := StringReplace(XmlAss, #10, '', [rfReplaceAll]);
//  XmlAss := StringReplace(XmlAss, #13, '', [rfReplaceAll]);

Não sei que efeitos colaterais essa alteração acima gera, mas para mim, que só gero NF no Rio de Janeiro, não vi nenhum efeito colateral indesejado. 

 

Depois disso, quando preencho os dados da NF para emissão, coloco #13#10 dentro do campo Servico.Discriminacao e no campo Servico.ItemServico.Descricao e eles saem na nota fiscal com quebras de linha como eu queria. 

 

ACBrDFeSSL.pas

pnfsNFSeW_ABRASFv1.pas

[Italo Giurizzato Junior]

Bom dia Roberto,

A intensão de ter no XML os caracteres #13#10 é para que ao abrir o XML através de um navegador o conteúdo das tags: Discriminacao e Descricao sejam apresentados com quebra de linha?

Ou se não fizer isso na impressão do DANFSE não sai com a quebra de linha?

Se é na impressão então devemos fazer as devidas correções neste e não na geração do XML.

[Roberto Rocha_11114]

OI Ítalo. 
A Nota fiscal de serviços da prefeitura do RJ , obtida no site após ter sido gerada, mostra a discriminação do serviços com quebras de linha se elas forem incluidas no campo Descrição. 
A intensão de ter no XML os caracteres #13#10 é para que ao abrir o XML através de um navegador o conteúdo das tags: Discriminacao e Descricao sejam apresentados com quebra de linha? NAO! 
A intenção é para que ao enviar o XML para a prefeitura do RJ, ela emita a NF com estas quebras de linha na descrição e então, na impressão da NF , a descrição fique mais bem formatada.

Ou se não fizer isso na impressão do DANFSE não sai com a quebra de linha? Eu não uso a impressão do sistema, eu uso a impressão do site da prefeitura.

 

Imagine que eu queira colocar na NF um texto descritivo do serviço com mais de uma linha para descreve-lo, Por exemplo:

"Reparo do micro computador

Ajustes no acesso a internet

Reconfiguração da impressora"

Mas é tudo um único serviço com um único valor (Logo, não é o caso de usar o Servico.ItemServico.Add três vezes)

Do jeito que o Projeto acbr está vai ficar uma única linha:   "Reparo do micro computador Ajustes no acesso a internet Reconfiguração da impressora"

 

Em resumo:

Se na descrição do serviços eu mandar (e o ACBR não retirar esses caracteres)  "SERVICO TAL"#13#10"OUTRO SERVICO TAL"     na NF da prefeitura sairá em duas linhas. Se retirar , sai tudo junto. Repito, apenas questão estética 

Veja uma nota fiscal que ficou sem o #13#10 ( ANTES DEU ADAPTAR O FONTE) : https://notacarioca.rio.gov.br/contribuinte/notaprint.aspx?ccm=10194954&nf=000000338&cod=IFSGBI9L

e outra com  ( DEPOIS DEU ADAPTAR O FONTE) : https://notacarioca.rio.gov.br/contribuinte/notaprint.aspx?ccm=10194954&nf=000000342&cod=D26L4EGK

nas duas eu mando na discriminação o conteudo com #13#10#13#10   logo antes do texto "Valor Aproximado dos serviços"

Abs

[Italo Giurizzato Junior]

Bom dia Roberto,

Se no arquivo RJ.ini tivermos:

QuebradeLinha=#13#10

E ao alimentar o componente mais precisamente o campo Discriminação informarmos: Serviço 1;Serviço 2;;Serviço 3 (por exemplo).

Ao gerar o XML teremos:

Serviço 1#13#10Serviço 2#13#10#13#10Serviço 3

Mantendo a linha:

  Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1,
                     StringReplace(FNFSe.Servico.Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR);

Pois esta realiza a troca do ";" ponto e virgula pelo conteúdo do campo QuebradeLinha definido no arquivo INI.

O problema agora é com a remoção dos caracteres #13#10 realizado pela rotina que faz a assinatura.

[Roberto Rocha_11114]

OI Italo. Boa tarde.
Se não me engano, sua primeira aproximação não funcionará. O texto (depois do StringReplace) conterá #13#10 (6 caracteres) e não os 2 caracteres ascii nº 13 e nº 10. 
#13#10 só viram quebra de linha se constarem no código fonte do Delphi. A rotina que lê os caracteres do INI e salva na variável FQuebradeLinha vai salvar nela uma String com 6 caracteres
Essa parte no entanto é fácil de resolver: basta criar a regra que no ini, se QuebradeLinha=ENTER  então no final da rotina que le o Ini , acrescenta-se o código: If QuebradeLinha='ENTER' Then QuebradeLinha=#13#10 (sem aspas, pois aí o Delphi converte)

 

O problema começa na rotina wCampoNFSe que chama uma outra dentro dela wcampo, que chama FiltrarTextoXML  que vai retirar as quebras de linha 

Ou seja, mesmo que a sua aproximação funcionasse, quando o texto passa por wCampoNFSe a quebra de linha já é retirada.

 

 

[Italo Giurizzato Junior]

Bom dia Roberto,

Assim que eu gosto, pessoas que estudam os fontes dos componentes.

Então precisamos procurar a melhor solução para esse problema.

[Italo Giurizzato Junior]

Roberto,

Tente da seguinte forma:

Em ACBrNFSeConfiguracoes, faça a seguinte alteração (incluir a linha em negrito):

  FConfigGeral.QuebradeLinha := trim(FPIniParams.ReadString('Geral', 'QuebradeLinha', ''));

  if FConfigGeral.QuebradeLinha = 'ENTER' then
    FConfigGeral.QuebradeLinha := #13#10;

Em pnfsNFSeW_ABRASFv1, faça a seguinte alteração (incluir o valor False que esta em negrito):

  Gerador.wCampoNFSe(tcStr, '#32', 'Discriminacao', 01, 2000, 1,
                     StringReplace(FNFSe.Servico.Discriminacao, ';', FQuebradeLinha, [rfReplaceAll, rfIgnoreCase] ), DSC_DISCR, False);

Esse parâmetro acrescentado no final faz com que o ParseTextoXML seja false e com isso o FltrarTextoXML não seja executado, desta forma os caracteres #13#10 não serão removidos da tag <Discriminacao>.

Bom, acredito que agora vai resolver o problema da quebra de linha no campo desejado.

Se funcionar o XML do RPS tem que ficar com a quebra de linha como você deseja.

Ai o próximo passo é encontrar uma solução no que diz respeito a assinatura, que acaba removendo a quebra de linha.
 

 

[Roberto Rocha_11114]

OK. Até aí foi. O problema mesmo vai ser na parte da assinatura. Pois é uma rotina que não se conecta diretamente com a geração do XML. 
Eu fiz uma variável booleana EMITINDONFSRIODEJANEIRO e se for true, não exclui os #13#10 do XML. Mas ficou feio do ponto de vista de qualidade de fonte. 
Tem que setar TRUE nela ANTES DE EMITIR a NF e false Depois. Fica ruim.

[Mauro Gomes]

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.

[Italo Giurizzato Junior]

Bom dia Mauro,

Concordo com você, precisamos unir forças para encontrar a melhor solução possível para a NFS-e sem gerar efeito colateral para os demais componentes.

Me parece que o problema agora se localiza ao assinar o XML, pois após a assinatura o componente remove as quebras de linha (#13#10), o motivo disso é que o conteúdo de uma das tags do grupo <Signature> é gerado com quebras de linha.

[Daniel Simoes]

O componente remove as quebras de linha, pois isso é uma exigência das regras de Transformação, antes de assinar o XML... ou seja se isso não for feito, o outro lado irá detectar a assinatura como inválida... As transformações são normatizadas pelo W3C e se modificarmos a maneira como ela ocorre, estaremos quebrando o padrão...

Observe ainda o fato de que são Libs de terceiros que geralmente manipulam o XML para fazer a transformação de forma correta como: MSXML, LibXml2 e LibXmlSec 

Não devemos confundir o XML assinado  ( que tem validade jurídica) com a representação gráfica dele...

Quais são as regras de Transformação para Sign Digest, adotadas por essa prefeitura?

O problema pode estar na verdade no lado da Prefeitura... talvez ela indique algum carácter que possa ser exibido como quebra de linha na exibição da descrição do seu site.

[Daniel Simoes]

Tente o seguinte:

https://www.w3.org/TR/xml/#sec-line-ends

Ou seja... onde desejar uma quebra de linha insira #xA

[Roberto Rocha_11114]

OI . 

"O problema pode estar na verdade no lado da Prefeitura... talvez ela indique algum carácter que possa ser exibido como quebra de linha na exibição da descrição do seu site." O site da prefeitura do RJ diz que para quebrar linha tem que enviar o #13#10, nenhum outro caracter faz isso.

O problema é que a rotina de remover as quebras de linha da assinatura (que tem que ser feito) também as remove de todo o XML que é gerado.
A mudança que fiz no fonte (que mandei em anexo no início) faz exatamente o serviço de apenas tirar as quebras de linha da assinatura, deixando as que estejam no conteúdo intactas.

Não entendi porque - pois estou bem ocupado implementando a NF4.0 e sem tempo para pesquisar (prometo ajudar mais tarde) - mas com essa alteração Danfes não foram aceitas (De outra forma, ao mudar a rotina resolveu para a prefeitura do RJ, mas estragou para a SEFAZ) porque na geração do  xml da Sefaz em algum lugar tem #13#10.

Minha conclusão: Se acertarmos a rotina para tirar o #13#10 somente da assinatura resolve a NFCarioca, mas estraga a Danfe.

Precisaríamos entender qual processo na geração da Danfe está incluindo quebras de linha no XML gerado.

Se resolvermos esse último problema e acertarmos para a retirada de quebras de linha afetar apenas a assinatura, ficamos bem.

 

 

[Daniel Simoes]

Temos que seguir um padrão... a única maneira correta de informar quebras de linha em conteúdos de XML é conforme definido pelo W3C

https://www.w3.org/TR/xml/#sec-line-ends

a exigência da Prefeitura não faz sentido e quebra os padrões estabelecidos 

Repare que a norma do W3C é semelhante para caracteres especiais como  < > e &

[Roberto Rocha_11114]

Oi. Pois é. Fui dar uma olhada então no site da prefeitura com mais detalhes e olha o que achei no manual em https://notacarioca.rio.gov.br/files/manuais/NFSe_layout_rps.pdf:

Descritivo dos serviços. Texto contínuo. O conjunto de caracteres correspondentes ao código ASC 13 e ASC 10 (Chr(13) + Chr(10)) deverá ser substituído pelo caracter | (pipe ou barra vertical. ASC 124).

Ou seja: Basta mandar ||  no lugar do #13#10 que a prefeitura troca. Já testei inclusive. 

Por mim, tópico resolvido (e vou voltar os fontes como estavam)

Em tempo: Obrigado pelo esforço de me ajudarem. 

Editado 4 Julho, 2018 por Roberto Rocha_11114
Faltou agradecer

[Italo Giurizzato Junior]

Boa tarde Roberto,

Acredito que teremos que alterar o arquivo INI do provedor.

[Mauro Gomes]

8 horas atrás, Daniel Simoes disse:

O componente remove as quebras de linha, pois isso é uma exigência das regras de Transformação, antes de assinar o XML... ou seja se isso não for feito, o outro lado irá detectar a assinatura como inválida... As transformações são normatizadas pelo W3C e se modificarmos a maneira como ela ocorre, estaremos quebrando o padrão...

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.

[Mauro Gomes]

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?

[Roberto Rocha_11114]

OI Mauro

 

Bom dia. 

Eu descobri que precisa colocar 2x o |.      Ou seja, | não funciona. || funciona. Não sei pq.

[Roberto Rocha_11114]

Não. Não funciona. 
Depois que eu coloquei a mensagem anterior (agora cedo) eu fui gerar uma NFse RJ (para exemplificar para o Mauro) eu percebi que eu havia me atrapalhado no teste. 

Enviar | ou || não funciona. 

Voltei com os fontes como estavam. 
Precisa enviar #13#10 no XML , na parte descriminação e precisa tirar os #13#10 da assinatura. 

 

É  uma quebra de padrão do XML, mas é assim que a prefeitura do RJ funciona! 

[Daniel Simoes]

Desculpe mas não podemos implementar dessa maneira no ACBr 

[Mauro Gomes]

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.

[Roberto Rocha_11114]

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). 
Daí que abandonei essa solução. 

O Ideal era que a prefeitura do RJ aceitasse um caracter para simular o #13#10 no XML.  Mas parece não haver.