Falha de envio eConf - MT

[Hetosoft Sistemas]

Olá. Estou com dificuldade em implementar o envio do eConf.

Estou fazendo os testes em ambiente de homologação, tanto de NF-e quanto de NFC-e emitidas em MT.

Quando envio eConf para NF, o retorno do evento é: 

<cStat>494</cStat>
<xMotivo>Rejeicao: Chave de Acesso inexistente</xMotivo>

Quando o envio é de NFC-e o retorno é:
 

<cStat>410</cStat>
<xMotivo>Rejeicao: UF informada no campo cUF nao e atendida pelo Web Service</xMotivo>

Vou anexar o XML do Envio e Retorno dos eventos.
Se alguém puder identificar o que estou fazendo de errado ficarei grato.

Evento Envio NFCe 65.xml Evento Envio NFe 55.xml Retorno Evento NFCe 65.xml Retorno Evento NFe 55.xml

[Italo Giurizzato Junior]

Bom dia @Hetosoft Sistemas,

Notei que o envio do evento tanto para NFe quanto para a NFC-e esta sendo feito para o ambiente de homologação.

As notas foram emitidas em ambiente de homologação ou de produção?

Se foi emitidas em produção o envio do evento também tem que ser em ambiente produção.

[Hetosoft Sistemas]

Isso mesmo @Italo Giurizzato Junior todo o processo foi feito em homologação. Desde a emissão do documento.
Os documentos foram protocolados dia 14 (2 dias atrás)

[Diego Foliene]

Boa tarde!

No que diz respeito ao retorno para NF-e, é possível que o ambiente de homologação da UF esteja passando por instabilidade.

Realizando testes de consulta pela chave de acesso em meu ambiente estou recebendo o seguinte retorno:

<?xml version="1.0" encoding="utf-8" ?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
  <soapenv:Body>
    <nfeResultMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NFeConsultaProtocolo4">
      <retConsSitNFe xmlns="http://www.portalfiscal.inf.br/nfe"
                     versao="4.00">
        <tpAmb>2</tpAmb>
        <verAplic>MT_A2RL-4.00</verAplic>
        <cStat>999</cStat>
        <xMotivo>Rejeicao: Erro nao catalogado</xMotivo>
        <cUF>51</cUF>
        <dhRecbto>2025-01-17T13:43:37-04:00</dhRecbto>
        <chNFe>$entidade.chNFe</chNFe>
      </retConsSitNFe>
    </nfeResultMsg>
  </soapenv:Body>
</soapenv:Envelope>

Depois de insistir recebi o retorno de nota autorizada.

Quanto ao retorno do envio para NFC-e, a mensagem me parece "desatualizada", visto que não existe o cUF na estrutura do arquivo e sim o cOrgao.

Na NT também consta a seguinte orientação para o cOrgao:

Quote

Código do órgão de recepção do Evento, conforme Tabela do IBGE.

Para a NF-e (modelo 55): Informar o código 92-SVRS, utilizando a URL do WS de Eventos da SVRS para este modelo de Documento Fiscal.

Para a NFC-e (modelo 65): Se UF participante da SVRS, informar o código 92-SVRS, utilizando a URL do WS de Eventos da SVRS; se não participante, informar o Código da UF do Emitente, para as SEFAZ com ambiente de autorização próprio.

O caso de MT entraria na parte "informar o Código da UF do Emitente, para as SEFAZ com ambiente de autorização próprio.", no entanto, como você recebeu esta rejeição, se possível, faça um teste enviando com o valor 92.

[Hetosoft Sistemas]

Exato @Diego Foliene. Por isso achei estranho a questão do cUF. Eu já tentei com 51 e 92 no cOrgao.
Fiz novamente pra poder anexar os xmls dos eventos.

 

Evento Envio NFCe 65 - cOrgao 92.xml Retorno Evento NFCe 65 - cOrgao 92.xml

[Diego Foliene]

Por favor, consegue realizar um teste no ambiente de produção com uma nota no valor baixo?

A estrutura do arquivo está correta.

Apesar de informações como o tópico abaixo indicarem que o estado do MT adota o e-Conf, tudo indica que eles não o fizerem de fato, que é um problema interno.

Isso ou este pode ser um comportamento do ambiente de homologação.

Vale abrir um Fale Conosco junto a Sefaz para questionamento.

[Hetosoft Sistemas]

Deu certo em produção. Apenas a NF-e. A NFC-e continou com o erro:
 

<cStat>410</cStat>
<xMotivo>Rejeicao: UF informada no campo cUF nao e atendida pelo Web Service</xMotivo>

[Italo Giurizzato Junior]

Bom dia @Hetosoft Sistemas,

Você poderia anexar o XML de envio do evento feito para a NF-e e para a NFC-e?

[Hetosoft Sistemas]

Olá, desculpe pela demora, estamos retomando o projeto agora.
Segue anexo da NFe e NFCe. 
A NF-e tudo certo, consegui até registrar o cancelamento de um eConf.

NFCe_1-eve.xml NFCe_1-ped-eve.xml NFe_1-eve.xml NFe_1-ped-eve.xml

[Italo Giurizzato Junior]

Boa tarde @Hetosoft Sistemas,

Notei que a tag nSeqEvento do envio do evento (NF-e) esta com o valor 3, já o da NFC-e esta com o valor 4.

Você esta incrementando esse numero a cada envio desse evento?

[Hetosoft Sistemas]

Exato. Foram feitas outras tentativas anteriormente. Vou pedir pro analista de testes fazer do zero com outra nota pra ficar com nSeqEvento, mas tenho certeza que não vai mudar nada. Pois anteriormente já foi feito.

[Italo Giurizzato Junior]

Bom dia @Hetosoft Sistemas,

Existem eventos que devemos sempre usar o nSeqEvento igual a 1, outros podemos até incrementar esse valor, como é o caso da carta de correção que pode chegar até 20.

No caso da carta de correção podemos enviar até 20 cartas sequenciadas de 1 até 20 para a mesma nota, lembrando que a carta de numero 2 anula a de numero 1, a de numero 3 anula a de numero 2 e assim por diante.

O evento eConf permite que o nSeqEvento varie de 1 até 99, eu acredito que sempre devemos usar o nSeqEvento igual a 1 e só usar o nSeqEvento igual a 2 caso a nota tenha 2 formas de pagamento.

Como é possível ter até 100 formas de pagamento, isso explica o motivo do nSeqEvento para esse tipo de evento variar de 1 a 99.

[Hetosoft Sistemas]

Entendi. Pode até fazer sentido. Porém em outros cenários enviando apenas 1 forma de pagamento e nSeq = 1, a NFC-e sempre retorna o mesmo erro.
Já tentei usar o cOrgao 51 e 92

[Italo Giurizzato Junior]

Boa tarde @Hetosoft Sistemas,

Não vejo outra alternativa entrar em contato com a SEFAZ e expor o problema.