9806->Rejeicao: NFC-e com Data-Hora de emissao atrasada

[joaolenosi]

Boa tarde!

Alguns clientes estão relatando o seguinte erro:

9806->Rejeicao: NFC-e com Data-Hora de emissao atrasada.

A nota técnica diz o seguinte:
 

Citar

B09-40 65 NFC-e com Tipo de Emissão=1-Normal (ou 3-SCAN, ou 6-SVCAN, 7-SVC-RS) e Data-Hora de Emissão com atraso superior a 5 minutos em relação ao horário de recepção na SEFAZ. Nota: A emissão da NFC-e deve ocorrer de forma on-line, realtime. Aceita uma tolerância de até 5 minutos, devido ao sincronismo de horário do servidor da Empresa e o servidor da SEFAZ. Obrig. 704 Rej. Rejeição: NFC-e com Data-Hora de emissão atrasada

Qual procedimento deve ser feito para uma nota que foi gerada offline e passou de 10 minutos do limite envio?

Por que ao tentar reenviar a nota sempre dá o erro citado acima. Já tentei manipular o XML adicionando as tags de forma manual: 

Citar

<dhCont>2019-04-15T10:36:29-03:00</dhCont>
<xJust>TESTE DE ENVIO SEM CONEX.</xJust>

E modificando as tag <tpEmis>9</tpEmis>, porém não obtive êxito!

Segue os arquivos em anexo.
Desde já obrigado

 

 

24190406369445000120650010000098061000098067-nfe.xml

[BigWings]

12 minutos atrás, joaolenosi disse:

Qual procedimento deve ser feito para uma nota que foi gerada offline e passou de 10 minutos do limite envio?

Como já diz o trecho da NT que você citou, a rejeição não afeta as NFCe emitidas em contingência off-line.

Apenas no modo normal há tolerância máxima de 5 minutos entre a data e hora de emissão e a data e hora de recebimento no webservice.

12 minutos atrás, joaolenosi disse:

Por que ao tentar reenviar a nota sempre dá o erro citado acima. Já tentei manipular o XML adicionando as tags de forma manual: 

Não deve ser feito nenhum tipo de alteração no XML emitido em contingência. Apenas carregar o arquivo e enviar. Se houver rejeição neste envio, sim, é permitida a correção do campo que causou a rejeição.

[joaolenosi]

9 minutos atrás, BigWings disse:

Como já diz o trecho da NT que você citou, a rejeição não afeta as NFCe emitidas em contingência off-line.

Apenas no modo normal há tolerância máxima de 5 minutos entre a data e hora de emissão e a data e hora de recebimento no webservice.

Não deve ser feito nenhum tipo de alteração no XML emitido em contingência. Apenas carregar o arquivo e enviar. Se houver rejeição neste envio, sim, é permitida a correção do campo que causou a rejeição.

Mas é justamente no reenvio da nota que ocorre esse erro!

E manipulando a tag <dhEmi> ele gera um erro de assinatura!

Editado 15 Abril, 2019 por joaolenosi

[BigWings]

2 minutos atrás, joaolenosi disse:

Mas é justamente no reenvio da nota que ocorre esse erro!

O XML que você anexou está com tpEmis = 1 (normal). Dessa forma é feita a crítica da data e hora de emissão.

Se a NFCe foi emitida em contingência o correto era estar tpEmis = 9.

[joaolenosi]

A seguir irei demonstrar como consegui simulei esse erro:

1. Citar

    

   1. Painel de Controle\Todos os Itens do Painel de Controle\Central de Rede e Compartilhamento > Conexão local> Protocolo TCP/IP versáo IPV4> usar os seguintes endereços: DNS primário: 233 99 0 255
      DNS secundário:  154 255 255 0
      Eu inventei esses DNS´S para que no momento que seja gerada uma NFC-e seu envio seja realizado ela entre no modo offline.
   2. Tentei enviar a nota e a mesma entrou no modo offline.
   3. Depois de mais ou menos uns 15 minutos eu coloquei para obter o DNS  automáticamente, e tentei realizar o reenvio carregando o XML gerado anteriormente. E é nesse momento que o erro ocorre, foi desta maneira que consegui simular o erro!

    

    

12 minutos atrás, BigWings disse:

O XML que você anexou está com tpEmis = 1 (normal). Dessa forma é feita a crítica da data e hora de emissão.

Se a NFCe foi emitida em contingência o correto era estar tpEmis = 9.

Ela foi emitida em contingência, eu expliquei os passos que realizei no penúltima post.
Realizando os passos, eu consegui enviar uma nota offline em contigência, e por algum motivo a tag <tpEmis> foi alimentada com 1.

E mesmo alterando para <pEmis>9</tpEmis>, o erro persiste.

Editado 15 Abril, 2019 por joaolenosi

[BigWings]

41 minutos atrás, joaolenosi disse:

Realizando os passos, eu consegui enviar uma nota offline em contigência, e por algum motivo a tag <tpEmis> foi alimentada com 1.

Quer dizer que tem algo errado com a tua rotina.

42 minutos atrás, joaolenosi disse:

E mesmo alterando para <pEmis>9</tpEmis>, o erro persiste. 

Configure o componente para gravar os arquivos de envio e retorno e anexe eles aqui.

[joaolenosi]

14 horas atrás, BigWings disse:

Quer dizer que tem algo errado com a tua rotina.

Configure o componente para gravar os arquivos de envio e retorno e anexe eles aqui.

Certo, vou fazer isso agora mesmo!

Poderia me informar onde que está essa opção? Dei uma olhada no componente ACBrNFe1 e não achei nenhuma propriedade para salvar o log.

[joaolenosi]

15 horas atrás, BigWings disse:

Quer dizer que tem algo errado com a tua rotina.

Configure o componente para gravar os arquivos de envio e retorno e anexe eles aqui.

Seria esses XML´s de envio e retorno que você precisa para analisar?
Lembrando que esses XML´S foram gerados após eu tentar reenviar a referida nota!
segue em anexo.

0-env-lot.xml 0-rec.xml 243065070139333-ped-rec.xml 243065070139333-pro-rec.xml

[BigWings]

5 minutos atrás, joaolenosi disse:

Seria esses XML´s de envio e retorno que você precisa para analisar?
Lembrando que esses XML´S foram gerados após eu tentar reenviar a referida nota!
segue em anexo.

0-env-lot.xml 6 kB · 0 downloads  0-rec.xml 357 B · 0 downloads 243065070139333-ped-rec.xml 166 B · 0 downloads 243065070139333-pro-rec.xml 669 B · 0 downloads

No arquivo 0-env-lot.xml continua o tpEmis = 1, por isso a rejeição.

[joaolenosi]

20 minutos atrás, BigWings disse:

No arquivo 0-env-lot.xml continua o tpEmis = 1, por isso a rejeição.

Então o que fazer para resolver esse problema?
Por que a nota não consta na SEFAZ.

 

 

[joaolenosi]

Se eu alterar a tag: tpEmis para <tpEmis>9</tpEmis> e tentar reenviar a nota, recebo o seguinte erro:

 

Citar

-<infProt>
<tpAmb>2</tpAmb>
<verAplic>SVRSnfce201904120803</verAplic>
<chNFe>24190406369445000120650010000098069000098067</chNFe>
<dhRecbto>2019-04-16T10:22:29-03:00</dhRecbto>
<digVal>N2aRpT1uDrvEHHaSeehbkVnzaZo=</digVal>
<cStat>297</cStat>
<xMotivo>Rejeicao: Assinatura difere do calculado</xMotivo>
</infProt>

Eu não sei o que fazer para as notas fiscais que foram geradas em contingência, mas por algum motivo a tag tpEmis não foi alimentada com 9 e nem foi gerado as demais tags:

Citar

<dhCont>2019-04-16T09:53:00-03:00</dhCont>
<xJust>TESTE DE ENVIO 2019</xJust>

Qual o procedimento correto a fazer com as notas que apresentam esse cenário?

[BigWings]

1 hora atrás, joaolenosi disse:

Eu não sei o que fazer para as notas fiscais que foram geradas em contingência, mas por algum motivo a tag tpEmis não foi alimentada com 9 e nem foi gerado as demais tags: 

O que vale é o XML então o que você está dizendo é que as notas deveriam ter sido geradas em contingência mas foram geradas no modo normal, e não foram autorizadas pela SEFAZ.

Foi impresso o DANFE NFCe desses XML? Se foi impresso o DANFE de um XML gerado em modo normal sem o protocolo de autorização, ele é inválido e a empresa estaria sujeita a multa pelo fisco.

Sendo essa a situação o que precisa ser feito é:

 - Entrar em contato com o assessor contábil da empresa pra que ele oriente a melhor forma de se resolver.

Pode ser preciso:

a) Inutilizar as numerações de NFCe que foram emitidas em modo normal mas não tiveram o protocolo de autorização gerado pela SEFAZ e;

  - Gerar uma NFe para acobertar essas NFCe inutilizadas ou;

  - Gerar novas NFCe com o mesmo propósito.

1 hora atrás, joaolenosi disse:

Se eu alterar a tag: tpEmis para <tpEmis>9</tpEmis> e tentar reenviar a nota, recebo o seguinte erro:

Qualquer alteração no XML vai causar erro de assinatura, você precisaria gerar e assinar novamente o XML.

[joaolenosi]

5 horas atrás, BigWings disse:

O que vale é o XML então o que você está dizendo é que as notas deveriam ter sido geradas em contingência mas foram geradas no modo normal, e não foram autorizadas pela SEFAZ.

Foi impresso o DANFE NFCe desses XML? Se foi impresso o DANFE de um XML gerado em modo normal sem o protocolo de autorização, ele é inválido e a empresa estaria sujeita a multa pelo fisco.

Sendo essa a situação o que precisa ser feito é:

 - Entrar em contato com o assessor contábil da empresa pra que ele oriente a melhor forma de se resolver.

Pode ser preciso:

a) Inutilizar as numerações de NFCe que foram emitidas em modo normal mas não tiveram o protocolo de autorização gerado pela SEFAZ e;

  - Gerar uma NFe para acobertar essas NFCe inutilizadas ou;

  - Gerar novas NFCe com o mesmo propósito.

Qualquer alteração no XML vai causar erro de assinatura, você precisaria gerar e assinar novamente o XML.

Sim, o DANFE foi impresso e gerado em ambiente normal sem o protocolo de autorização, devido a divergência que houve!

Certo, vou providenciar essas medidas que você me falou. 
Vou tentar simular esse erro no meu sistema para não ocorrer futuramente!
 

Citar

Qualquer alteração no XML vai causar erro de assinatura, você precisaria gerar e assinar novamente o XML.

E quanto a esse procedimento que você mencionou, eu realizei, porém não obtive êxito para enviar a nota.

Mas de qualquer forma muito obrigado, considero esse tópico como resolvido.

[joaolenosi]

Podem fechar esse tópico!

Muito obrigado.

[Juliana Tamizou]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.