Cancelamento com erro: "nao encontrei final elemento: </eventoMDFe>"

[ThiagoDornelas]

boa tarde,

hj atualizei os fontes para implementação do Mdfe 3.0 e comecei a ter o erro em anexo sempre q tento fazer o cancelamento de um MDF.

debuguei os fontes pra tentar identificar o problema e descobri q aparentemente o problema esta na unit ACBrDFeXsMsXmlCapicom.

Na procedue Assinar, existe este trecho

    {$IfDef FPC2}
     AXml := ACBrUTF8ToAnsi(ConteudoXML);
    {$Else}
     AXml := UTF8ToNativeString(ConteudoXML);
    {$EndIf}

Neste ponto a variável ConteudoXML possui os dados do evento e apos passar pela linha UTF8ToNativeString(ConteudoXML) ela retorna nada, ou seja, a variável AXml fica vazia.

Apos este ponto, é chamada a função AdicionarSignatureElement(AXml, False, docElement, IdSignature) e como  AXml está limpa, a função me retorna erro.

 

Se alguem puder me dar uma força neste problema, ficarei agradecido.

 

obrigado

 

Thiago Dornelas

[Italo Giurizzato Junior]

Boa noite Thiago,

O problema ocorre também com o componente configurado para a versão 1.00?

[ThiagoDornelas]

Em 11/04/2017 at 20:35, Italo Jurisato Junior disse:

Boa noite Thiago,

O problema ocorre também com o componente configurado para a versão 1.00?

boa tarde Italo.

Configurado pra 1.00 nao ocorre o problema.

[Italo Giurizzato Junior]

Boa noite Thiago,

Se a variável AXML fica vazia significa que a variável ConteudoXML contem algum carácter estranho e consequentemente a conversão foi abortada.

No caso de cancelamento temos que justificar o mesmo, na justificativa não tem cedilha ou vogal acentuada ou outro carácter especial?

[ThiagoDornelas]

bom dia Italo, 

após esse seu comentário sobre carácter especial, fiz um outro teste mais apurado.

- na versão 1.00, o cancelamento  é homologado mesmo contendo carácter especial na justificativa. Fiz um teste escrevendo "teste de homologação" e passou sem problemas.

- na versão 3.00, o cancelamento não é homologado quando tem carácter especial mas se não tiver, ele é homologado. Com a justificativa "teste de homologação", nao foi aceito, mas quando alterei pra "teste de homologacao ", ele foi aceito.

 

Nesse novo layout não sera mais aceito carácter especial ?

Editado 17 Abril, 2017 por ThiagoDornelas

[Italo Giurizzato Junior]

Boa noite Thiago,

A SEFAZ sempre recomendou que não devemos utilizar caracteres especiais, tais como cedilha e vogais acentuadas entre outros.

[ThiagoDornelas]

blz Italo,

vou providenciar esta alteração pra retirar os caracteres especias.

muito obrigado pela atenção.

 

abraço.

Editado 19 Abril, 2017 por ThiagoDornelas

[bsoft]

Boa tarde,

Identificamos uma situação não muito parecida com esta (nosso caso é a importação de um XML de NF-e emitido por outro sistema), mas onde o problema em si é que a função UTF8ToNativeString está retornando o XML vazio, e gostaríamos de compartilhar a solução: uma simples verificação em cima do resultado, que pelo menos retorna o próprio XML ao invés de não ter nenhum conteúdo caso não sobreviva aos métodos de conversão Utf8ToAnsi / UTF8Decode / UTF8ToString.

function UTF8ToNativeString(AUTF8String: AnsiString): String;
begin
  {$IfDef FPC}
   Result := AUTF8String;  // FPC usa UTF8 de forma nativa
  {$Else}
   {$IfDef UNICODE}
    {$IfDef DELPHI12_UP}  // delphi 2009 em diante
     Result := UTF8ToString(AUTF8String);
    {$Else}
     Result := UTF8Decode(AUTF8String);
    {$EndIf}
   {$Else}
    Result := Utf8ToAnsi(AUTF8String) ;
   {$EndIf}

   if Result = '' then Result := AUTF8String;
  {$EndIf}
end;

Como o @Italo Jurisato Junior falou, de fato a SEFAZ sempre recomendou que não sejam utilizados caracteres especiais, mas ela não proíbe, então entendemos que esta alteração, além de não afetar o funcionamento, pode ser que ajude em determinados casos.

Segue em anexo o arquivo ACBrUtil.pas modificado, e também o XML de NF-e que motivou esta alteração (notem que apesar do encoding="UTF-8", o arquivo é ANSI e consegue ser lido normalmente pelo Delphi).

ACBrUtil.pas

NFe41170577595395000490550050014156431090627603.xml

[Daniel Simoes]

O problema está ocorrendo... porque o XML está acentuado da maneira errada... ele possui a declaração, de que usa UTF8, mas os acentos estão em ANSI... Veja no NotePad++

Repare que com isso, o XML é completamente inválido... e não pode ser validado pelo site do SEFAZ

https://www.receita.fazenda.gov.br/Aplicacoes/SSL/ATBHE/Assinadoc/ValidadorAssinaturas.app/valida.aspx

Citar

A assinatura digital do documento fornecido não é válida.
Motivo: O arquivo fornecido não é um PKCS #7 válido.

 

Apliquei a conversão do XML de ANSI para UTF8, e a validação da assinatura no site do SEFAZ ocorreu com sucesso... Ou seja, esse XML era originalmente UTF8 (a assinatura válida comprova isso)... Provavelmente alguma rotina interna sua, está salvando o XML como ANSI

[bsoft]

@Daniel Simoes, esta NF-e não foi emitida pelo nosso sistema, foi um cliente nosso (transportador) que recebeu esta NF-e da Frimesa.

Sabemos que é esta a falha, porém você também deve saber o quanto é difícil para um cliente pequeno argumentar com uma grande empresa que eles estão emitindo errado as NF-e's e que eles devem corrigir o problema. Eles preferem trocar o transportador!  

Agradecemos o retorno, mas pedimos que reavalie a sugestão, afinal, ela não será prejudicial à função UTF8ToNativeString.

[Daniel Simoes]

A modificação não resolve o problema... pois como voce pode ver... dessa maneira o XML não é válido... 

[bsoft]

Humildemente discordamos de sua opinião.

Na sequência do código do ACBr, no resultado desta função é aplicada a função RemoverDeclaracaoXML, que simplesmente removerá o cabeçalho incorreto "<?xml version="1.0" encoding="UTF-8"?>" deste exemplo, e o conteúdo será lido sem nenhum problema.

Podemos até ir mais a fundo no problema e analisar modificações na função XmlEhUTF8 - que tem como defeito simplesmente "acreditar" no que está sendo informado no encoding, mas não verifica se o conteúdo é realmente codificado em UTF8 - mas nossa sugestão envolve apenas a adição de uma linha para evitar um retorno vazio (que não possui vantagem nenhuma em ser desta forma).

Pedimos pela última vez que reavalie a sugestão, ela pode ser útil para muita gente, inclusive para você e seus clientes.

Se não aceitar, sem problemas, temos diversas alterações específicas para nossa empresa, e continuaremos amigos

[Daniel Simoes]

Não me oponho a modificação sugerida, afinal ela parece inócua... mas veja que você está manipulando um XML sem validade jurídica (assinatura inválida)

O problema não afeta usuários de Lazarus (meu caso), pois o Lazarus usa UTF8 de forma nativa.