Problema resposta na UF Mato grosso (não suporta sincrono nfce)

[Bruno Freixo]

Prezados. no estado de mato grosso estamos tendo problema na emissão nfc-e. embora eu transmita sempre 1 xml e altere o modo de envio para sincrono. mas estamos com problema acredito que deveria receber pelo menos resposta cstat = 105 em processamento. mais vou colocar a o log do acbr abaixo

 

[Envio]
CStat=103
CUF=51
DhRecbto=10/05/2019 14:30:13
Msg=Lote recebido com sucesso
NRec=510003686060663
TMed=1
VerAplic=3.00
Versao=3.00
XMotivo=Lote recebido com sucesso
tpAmb=1

[Retorno]
CStat=0
CUF=0
DhRecbto=30/12/1899
Msg=
VerAplic=
Versao=
XMotivo=
nRec=510003686060663
tpAmb=1


Porem pelo log parece error no webservice. mas quando tento enviar nova nota a mesma deu em duplicidade.
vamos fazer uma tratativa para consultar a nota caso receba essa resposta do acbr. mas isso não pareceu normal pra min. é comun receber essa resposta do acbr? não deveria vim uma resposta em processamento? a sefaz de MT não suporta requisição sincrona?

 

[Envio]
CStat=103
CUF=51
DhRecbto=10/05/2019 14:30:19
Msg=Lote recebido com sucesso
NRec=510003686060869
TMed=1
VerAplic=3.00
Versao=3.00
XMotivo=Lote recebido com sucesso
tpAmb=1

Nota(s) não confirmadas:
1350->539-Duplicidade de NF-e com diferenca na Chave de Acesso

[Retorno]
CStat=539
CUF=51
DhRecbto=30/12/1899
Msg=Nota(s) não confirmadas:
1350->539-Duplicidade de NF-e com diferenca na Chave de Acesso
VerAplic=4.00
Versao=4.00
XMotivo=Duplicidade de NF-e com diferenca na Chave de Acesso
nRec=510003686060869
tpAmb=1
[NFe1350]
CStat=539
CUF=51
DhRecbto=10/05/2019 14:30:19
Msg=
VerAplic=4.00
Versao=4.00
XMotivo=Duplicidade de NF-e com diferenca na Chave de Acesso
arquivo=C:\LinkedGourmet\fc\CaminhoAssinada\51190532194658000178650010000013501214711566-NFCe.xml
chNFe=51190532194658000178650010000013501214711566
digVal=5QQKYvhKj/69PLenk7hyfGiAiiY=
nProt=
tpAmb=1

[Italo Giurizzato Junior]

Boa tarde Bruno,

Você esta usando a versão mais recente do ACBrMonitor?

Se você envia novamente a nota e a mesma é rejeitada por duplicidade, isso significa que a primeira vez que ela foi enviada em modo síncrono, ela foi recebida, processada e autorizada pela SEFAZ.

Logo conclui-se que a SEFAZ-MT suporta a recepção de NFC-e em modo síncrono.

Você tem um outro problema que é, Duplicidade com diferença na chave.

Isso significa que a nota enviada pela segunda vez, a chave estava diferente.

O que pode provocar essa diferença?

O erro mais comum é não atribuir um valor para o campo cNF (Código da Nota Fiscal) que faz parte da chave.

Se você não atribuir um valor para o campo cNF o Monitor se encarrega de gerar um código aleatório, isso explica que o segundo envio da mesma nota ter a chave diferente.

A minha sugestão é que a sua aplicação gere um código aleatório para cNF, armazene esse código no banco de dados com os demais dados da nota e no momento de gerar o arquivo TXT com os dados da venda, atribua o código ao campo cNF.

Como isso você garante que a chave sempre será gerada exatamente igual.

Por fim, acredito o seu problema de não receber informações corretas logo após o primeiro envio deve ser devido ao uso de alguma versão antiga do monitor.

[Bruno Freixo]

Em 13/05/2019 at 13:25, Italo Jurisato Junior disse:

Boa tarde Bruno,

Você esta usando a versão mais recente do ACBrMonitor?

Se você envia novamente a nota e a mesma é rejeitada por duplicidade, isso significa que a primeira vez que ela foi enviada em modo síncrono, ela foi recebida, processada e autorizada pela SEFAZ.

Logo conclui-se que a SEFAZ-MT suporta a recepção de NFC-e em modo síncrono.

Você tem um outro problema que é, Duplicidade com diferença na chave.

Isso significa que a nota enviada pela segunda vez, a chave estava diferente.

O que pode provocar essa diferença?

O erro mais comum é não atribuir um valor para o campo cNF (Código da Nota Fiscal) que faz parte da chave.

Se você não atribuir um valor para o campo cNF o Monitor se encarrega de gerar um código aleatório, isso explica que o segundo envio da mesma nota ter a chave diferente.

A minha sugestão é que a sua aplicação gere um código aleatório para cNF, armazene esse código no banco de dados com os demais dados da nota e no momento de gerar o arquivo TXT com os dados da venda, atribua o código ao campo cNF.

Como isso você garante que a chave sempre será gerada exatamente igual.

Por fim, acredito o seu problema de não receber informações corretas logo após o primeiro envio deve ser devido ao uso de alguma versão antiga do monitor.

Obrigado. pela resposta. percebi que houve o error no merge automatico do TFCV acabou removendo o valor booleano do sicrono. deixando rotina assicrona.

[Italo Giurizzato Junior]

Obrigado por reportar.

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