XML NF-e "DigestValue" <> "DigVal"

[former_member1153961]

Boa tarde,

Estamos com problemas em alguns arquivos XML(s) armazenados no KPRO do GRC.

Vários arquivos XML(s) estão com os campos u201CDigestValueu201D diferente co campo "DigVal".

Todos estes casos ocorreram quando a SEFAZ retornou as seguintes Rejeições:

214 - Rejeição: Tamanho da mensagem excedeu o limite estabelecido

225 - Rejeição: Falha no Schema XML da NFe

243 - Rejeição: XML Mal Formado

296 - Rejeição: Certificado Assinatura erro no acesso a LCR

999 - Rejeição: Erro não catalogado (informar a mensagem de erro capturado no tratamento da exceção)

Obs.: Estas rejeições só ocorreram quando existia problemas internos na SEFAZ(es).

Por procedimento, nestes casos, os processos foram reiniciados na J1BNFE e após isso enviado para o GRC novamente.

No GRC estes processos foram assinados novamente e enviados para a SEFAZ.

A SEFAZ recebeu estes processos e nos retornou a rejeição 204 (Rejeição u2013 Duplicidade NF-e).

Foi efetuado a u201CConsulta de Statusu201D para estes processos e os mesmos foram atualizados no KPRO do GRC.

Resumindo, a SEFAZ retornou uma Rejeição onde na verdade era para retornar a NF-e Autorizada e quando o enviamos novamente para a SEFAZ, a mesma foi assinada novamente assim justificando a diferença entre os campos "DigestValue" e "DigVal".

O que pode ser feito para evitar que estes problemas continuem a ocorrer? Existe algo (configuração, desenvolvimento, procedimento ou aplicação de SAP Note) que possa ser feito para evitar este tipo de problema?

Qual o procedimento correto a se fazer quando uma NF-e é rejeitada com estes códigos (214, 225, 243, 296, 999)? É enviar novamente o processos para o GRC? Existe uma forma de enviar novamente sem que o mesmo seja assinado digitalmente novamente?

Já abri um chamado na service.sap.com, porém acredito que eu não consegui me expressar bem.

Att.

Márcio Marusco

SD SAP Consultant

[former_member1153961]

Olá Aaron.

Identificamos um erro em nosso sistema, porem o erro era no ERP
e não no GRC/NF-e.

Quando reenviávamos o processo pela J1BNFE, ele atribuía uma
nova data/hora no XML, e quando este XML era enviado para o GRC/NF-e, como a
estrutura dele era diferente da estrutura do primeiro arquivo enviado (campo
data/hora diferentes), o GRC/NF-e efetuava uma nova assinatura digital,
deixando os campos em questão diferentes do da SEFAZ que já havia autorizado o
XML, com a estrutura do arquivo enviado pela primeira vez.

Ajustamos a nossa BADI NF-e do ERP e este problema nunca mais
ocorreu.

Espero ter ajudado em algo.

Abraços.

Márcio Marusco

[Former Member]

Oi, qual era a sua resolução, neste caso?