Ir para conteúdo
  • Cadastre-se

dev botao

Problema na consulta de nota cancelada


  • Este tópico foi criado há 2473 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

Estou com um problema na consulta de notas que estão canceladas, está gravando o XML com o protocolo de cancelamento substituindo o protocolo de autorização no XML original na pasta.

Exemplo: tenho uma nfce que está autorizada, faço o cancelamento dela e tenho um problema de comunicação, não sei se o cancelamento foi aprovado ou não.

Faço uma consulta da situação pelo WS de consulta, utilizando o arquivo XML (uso o loadFromFile, não uso a consulta pela chave de acesso).

Ao executar o nfe.Consultar ele atualiza o XML na pasta original e substitui o protocolo de autorização pelo protocolo de cancelamento. Isso ocorre quando o parâmetro "Geral"."Atualizar XML Cancelado" está como true. No meu entendimento ele deveria atualizar incluindo o protocolo de cancelamento, e não substituindo o de autorização. Nesse caso ele também está gerando o arquivo *-NFeDFe.xml que tem a nota, o protocolo de autorização e os eventos, mas nesse arquivo o protocolo de autorização também está incorreto, exibindo o protocolo de cancelamento no seu lugar.

Até onde sei o XML para ter valor jurídico precisa do protocolo de autorização correto? Ou somente com o protocolo de cancelamento ela é considerada válida?

Esse era o conteúdo da tag protNFe antes da consulta:

<protNFe versao="3.10">
<infProt>
<tpAmb>2</tpAmb>
<verAplic>RSnfce201702131316</verAplic>
<chNFe>43170626393120000190650010000002451850966532</chNFe>
<dhRecbto>2017-06-16T17:11:10-03:00</dhRecbto>
<nProt>143170000867421</nProt>
<digVal>O2UfnpNHlvxlGkH6/FDgXqj+DTE=</digVal>
<cStat>100</cStat>
<xMotivo>Autorizado o uso da NF-e</xMotivo>
</infProt>
</protNFe>
 

Depois da consulta, o prodNFe ficou assim:

<protNFe versao="3.10">
<infProt>
<tpAmb>2</tpAmb>
<verAplic>RSnfce201610061504</verAplic>
<chNFe>43170626393120000190650010000002451850966532</chNFe>
<dhRecbto>2017-06-16T17:18:22-03:00</dhRecbto>
<nProt>143170000867454</nProt>
<digVal>O2UfnpNHlvxlGkH6/FDgXqj+DTE=</digVal>
<cStat>101</cStat>
<xMotivo>Cancelamento de NF-e homologado</xMotivo>
</infProt>
</protNFe>
 

 

Link para o comentário
Compartilhar em outros sites

  • Moderadores
9 horas atrás, jhoerlle disse:

Até onde sei o XML para ter valor jurídico precisa do protocolo de autorização correto? Ou somente com o protocolo de cancelamento ela é considerada válida?

Bom dia,

Na minha interpretação o XML válido é o com o protocolo de autorização ou denegação.

Cancelamento é um evento vinculado à nota e tem seu XML próprio.

A atualização do XML no cancelamento é uma prática que vem do tempo da NFe 1.0, e por comodidade para importação do XML foi mantido no ACBr.

Para desativar esse comportamento, configure a opção:

ACBrNFe1.Configuracoes.Geral.AtualizarXMLCancelado := False;

 

Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

Link para o comentário
Compartilhar em outros sites

Em 2017-6-17 at 08:16, BigWings disse:

Bom dia,

Na minha interpretação o XML válido é o com o protocolo de autorização ou denegação.

Cancelamento é um evento vinculado à nota e tem seu XML próprio.

A atualização do XML no cancelamento é uma prática que vem do tempo da NFe 1.0, e por comodidade para importação do XML foi mantido no ACBr.

Para desativar esse comportamento, configure a opção:


ACBrNFe1.Configuracoes.Geral.AtualizarXMLCancelado := False;

 

Eu concordo com você, o xml só é válido com protocolo de autorização ou denegação.

Na verdade o meu objetivo não é "embutir" o xml de cancelamento no xml da nota, essa realmente é uma prática antiga e acredito que não mais utilizada.

Qual é o meu problema exatamente: quando tento fazer o cancelamento de uma NFCe e por algum motivo não obtenho o retorno desse cancelamento (problema de internet normalmente) e aí não sei se ele chegou a ser efetivado na Sefaz ou não (a mesma questão que ocorre com a contingência offline no envio das notas, onde a sugestão da própria Sefaz é emitir nova nota com um novo número pois não tem como saber se a nota originalmente enviada foi autorizada ou não quando ocorre falha de comunicação). Nesse caso quando tenho erro de comunicação  na chamada do WS de evento (cancelamento) eu deixo a minha nota com uma flag sinalizando essa situação e posteriormente eu faço uma consulta da situação dessa nota para saber se o cancelamento foi efetivado ou não. Caso não tenha sido, faço novo cancelamento e tudo certo, mas caso ela esteja como cancelada na Sefaz eu preciso obter o XML com o protocolo de cancelamento, de registro do evento. E essa é a minha dificuldade. Atualmente quando faço a consulta da situação da nota, se deixo a opção "Atualizar XML Cancelado" como false ele não faz nenhum tipo de atualização no XML, nem da nota fiscal e nem no XML do evento. Se eu marco esta opção como true, aí quando faço a consulta da situação da nota (utilizando o loadFromFile com o XML) ele atualiza o XML e substitui o protocolo de autorização pelo de cancelamento, ele não inclui na nota o de cancelamento, ele simplesmente remove o de autorização e incluir o de cancelamento, invalidando assim "juridicamente" aquele XML. Ele também cria o novo arquivo *-NFeDFe.xml com a concatenação da nota, do procNFe e do registro do evento, isso serviria, mas o problema é que nesse novo arquivo criado o procNFe também está errado, com o protocolo de cancelamento no lugar do protocolo de autorização. Assim tem dois protocolos de cancelamento e nenhum de autorização nesse novo arquivo criado.

Não sei se consegui esclarecer qual a minha dificuldade....

Link para o comentário
Compartilhar em outros sites

  • Moderadores
50 minutos atrás, jhoerlle disse:

Não sei se consegui esclarecer qual a minha dificuldade....

Pelo que entendi você tem um XML já cancelado na SEFAZ mas sem o protocolo de autorização no arquivo, e na consulta quer obter o protocolo de autorização. Entendi?

Seria um caso a se analisar, qual o protocolo retornado na consulta. Sendo apenas o de cancelamento, ficaria difícil...

Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

Link para o comentário
Compartilhar em outros sites

2 minutos atrás, BigWings disse:

Pelo que entendi você tem um XML já cancelado na SEFAZ mas sem o protocolo de autorização no arquivo, e na consulta quer obter o protocolo de autorização. Entendi?

Seria um caso a se analisar, qual o protocolo retornado na consulta. Sendo apenas o de cancelamento, ficaria difícil...

Correto, eu tenho o XML sem o protocolo de cancelamento.

Na consulta da situação da nota me retorna o número do protocolo de cancelamento, mas somente em nfe.WebServices.Consulta.procEventoNFe.Items[0].RetEventoNFe.retEvento.Items[0].RetInfEvento.nProt,

Eu tenho o número do protocolo de cancelamento e consigo gravar ele no meu banco de dados, mas não consigo ter o XML do evento com o protocolo. O correto seria conseguir o XML do evento com o protocolo de autorização, sem mexer em nada no XML da nota, que continua com o protocolo de autorização.

Link para o comentário
Compartilhar em outros sites

3 horas atrás, fabricio.syncode disse:

Olá @jhoerlle,

Até onde entendi, você está com um problema parecido com o que eu tive a um tempo atrás... dá uma olhada nesse tópico e vê se te ajuda:

 

Cara, me ajudou muito.

Eu precisava justamente o que você implementou gerar o XML do procEventoNFe com o protocolo de cancelamento quando eu não tinha ele por algum erro de comunicação no cancelamento.

Implementei da maneira que você sugeriu e funcionou perfeitamente.

Muito obrigado pela ajuda.

Link para o comentário
Compartilhar em outros sites

  • Este tópico foi criado há 2473 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar Agora
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.