XML de Evento invalido

[Luciano César Gimenez]

Ola pessoal, quando envio um evento de carta de correção, o XML que é gravado na pasta de envio, quando tento abrir o XML ele não carrega corretamente no IE, ele carrega como se fosse texto, mas o evento foi enviado para receita tudo certinho, gostaria que alguem por favor desse uma olhada nesse xml e ver se estou fazendo algo errado.

Desde ja agradeço a atenção de todos...

Luciano

 1101103515080912034700014255001000000258134823157607-procEventoNFe.xml

[Régys Silveira]

Abrindo o arquivo, veja na tag <xEvento>Carta de Correção registrada</xEvento>, o çã está com caracteres inválidos, isso inválida a abertura do XML no Internet Explorer.

[Luciano César Gimenez]

Ola Regys boa tarde, obrigado pela dica, era isso mesmo, mas porque agora esta ocorrendo isso, sendo que na versão anterior(Trunk) não acontecia isso, sera que tenho que ajustar alguma propriedade nessa nova versão do Trunk2?

Desde ja agradeço a atenção...

Luciano

[Italo Giurizzato Junior]

Boa tarde Luciano,

Nos fontes do Trunk o componente trocava o cedilha por "C" e vogais acentuas por não acentuadas antes de salvar em disco.

Nos fontes do Trunk2 não foi incluída a função que faz esse serviço nas rotinas que obtêm o retorno da SEFAZ.

[Luciano César Gimenez]

Ola Italo boa tarde, obrigado pela reposta, mas você teria alguma sugestão para solucionar isso? ou  ainda vai ser inclusa essa função?

Desde ja obrigado...

Luciano

[Italo Giurizzato Junior]

Bom dia Luciano,

Não vejo problemas em incluir ela novamente.

[Daniel Simoes]

Boa tarde Luciano,

Nos fontes do Trunk o componente trocava o cedilha por "C" e vogais acentuas por não acentuadas antes de salvar em disco.

Nos fontes do Trunk2 não foi incluída a função que faz esse serviço nas rotinas que obtêm o retorno da SEFAZ.

Ítalo,

Isso não é feito em "TGerador.wCampo" ? 

Lá no final ele chama "FiltrarTextoXML", que por sua vez, chama ParseText...

[Italo Giurizzato Junior]

Boa tarde Daniel,

Isso se pegarmos os dados do XML mais a assinatura e protocolo e gerar novamente o XML, caso contrario não.

Temos também outras situações, por exemplo a inutilização de numeração, onde temos 3 XMLs, o de envio, de retorno e de compartilhamento.

O de envio não temos problemas, pois é executado o "TGerador.wCampo", mas o de retorno e o de compartilhamento que é apenas uma montagem dos dois anteriores não temos essa filtragem e consequentemente vai aparecer esses caracteres "inválidos".

[Daniel Simoes]

Nessa caso, basta modificar essas rotinas, que não usam TGerador.wCampo, para submeter todas as Strings a "ParseText"

[Cantu]

Esse problema passou a existir tanto no trunk1 como no trunk2, já faz alguns meses, e pelo que estou vendo, ainda não foi corrigido.

[Cantu]

Complementando o post anterior, eu percebi o problema porque ao gravar em arquivo, o xml previamente armazenado num blob, ele nao abre corretamente nos browsers. Verifiquei que se adicionar os caracteres que identificam UTF8 nos primeiros dois bytes do arquivo ($EF $BB), ele passa a abrir corretamente. Ele também não visualiza corretamente no IBExpert.

Eu gravo o conteudo do blob assim:

tqCCeXML.asString := UTF8Encode(NFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML);

Delphi XE6.

Honestamente, não sei se o correto seria tratar o retorno do webservice e trocar os caracteres acentuados, pois estaríamos alterando o retorno original.

[]s
Cantu

[Daniel Simoes]

Mas todo o retorno dos WebServices já devem estar em UTF8... (UTF8 é o padrão exigido em todos os Documentos Fiscais Eletrônicos)...

Então não seria necessária nenhuma conversão o XML retornado...

[Cantu]

Daniel, a propriedade NFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML ainda está como AnsiString

E, aparentemente, o método SaveToFile do TBlobfield gera um arquivo sem o identificador de UTF8.

[]s
Cantu

[Daniel Simoes]

Ao invés de incluir o "BOM" no inicio do arquivo... experimente a adicionado no inicio do XML: <?xml version="1.0" encoding="UTF-8"?>

[Cantu]

Daniel, o conteúdo já tem a tag do xml... mas ao gravar o arquivo, se não tiver o BOM e tiver algum caractere acentuado em alguma tag, dá erro ao carregar no browser (ou renderiza sem formatação). Adicionando o BOM resolve.

[Daniel Simoes]

Estranho... isso não deveria ser necessário, já que existe o conceito de arquivos UTF8 sem o BOM... e a TAG do tipo do XML deveria ser tudo o que o Browser precisa...

[Cantu]

Também acho que os browsers deveriam ser mais espertos e pela tag do xml já identificar que o conteúdo está em UTF8. No momento, estou resolvendo da seguinte forma:

Criei uma procedure para gerar o arquivo do XML (que no meu caso, vem de um blob) já com o BOM:

 

procedure WriteToUnicodeFile(arquivo:TFileName; s:string);
var
 Writer: TStreamWriter;
begin
 Writer := TStreamWriter.Create(arquivo, false, TEncoding.UTF8);
 try
   Writer.Write(s);
 finally
   Writer.Free;
 end;
end;

Agora, ao invés de usar o TBlobField.SavetoFile, chamo essa procedure passando o Tblobfield.asString no parametro s.

[Daniel Simoes]

Oi Cantu,

Em nossa conversa por Skype, notamos que o Delphi XE (e todos Delphis com suporte a Unicode) não estavam gravando os XMLs corretamente com o encoding em UTF8... Por isso o problema ocorria...

Apliquei modificações na ACBrUtil, baseado na sugestão que você me enviou.... para permitir que a conversão da String nativa do XE (Unicode) seja convertida para UTF8 antes da gravação do XML em disco...

Testei no  D7, XE7 e Lazarus... todos gravaram com sucesso os arquivos de Envio, Retorno e Envelopes, usando o encoding UTF8... e todos os arquivos foram abertos sem problemas no MS Edge

 

[Cantu]

Ótimo Daniel!

Vou atualizar o trunk aqui

[]s
Cantu

[Luciano César Gimenez]

Ola Daniel boa tarde, essa alteração que você fez acima, também afeta a questão de tirar a acentuação das Respostas da SEFAZ? que está ficando com acentuação e ai não consigo abrir o XML no I.E.?

Desde já obrigado...

Luciano

[Daniel Simoes]

Não devemos modificar a resposta do SEFAZ... se ela tem acentos, então temos que considerá-los...

O problema de não abrir, ocorre pelo fato do arquivo estar usando um Encoding diferente do informado na TAG inicial

A modificação que fiz, é para garantir que o arquivo seja sempre gravado com o Encoding de UTF8 (o mesmo informado na Tag inicial)

[Daniel Simoes]

Apliquei mais algumas modificações no Demo do ACBrNFe, e nos fontes do ACBr, referente a essa questão do UTF8, por favor atualizem, e leia o conteúdo dos arquivos de "Change-Log.txt"

[Cantu]

Daniel, como ficou a questão da propriedade XML dos componentes? Continua sem estar codificado em UTF8? Existe agora alguma forma de eu pegar o XML de NFe, CCe, etc. direto do componente e já em UTF8?

[Gildenor]

 

Atualizei ACBr, porem quando a nota é denegada 302 (Uso Denegado : Irregularidade fiscal do destinatário), salvo do procnfe, porem ele nao abre no navegador, nem pelo acbr - o acento bloqueia. Sei que ha mudancas neste sentido porem, nao consegui resolver este problema. Qual propriedade ou metodo devo acionar pra resolver este problema?

Att,

[Daniel Simoes]

Em qual revisão do SVN você está ?

correcoes para esse problema foram enviadas ontem