Ir para conteúdo
  • Cadastre-se

dev botao

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

Recommended Posts

  • Membros Pro
Postado

Bom dia.

Num teste de timeout ia tentar inutilizar o número da nota para detectar se ela foi enviada ou não para a SEFAZ, e acabei descobrindo que consigo número de notas com cstat 100. 

Alguém sabe algo sobre isso? Acontece só em homologação será?

Seguem NF-e e solicitação de inutilização em anexo.

33180604756933000164550010000033931745998536-nfe.xml

35180475693300016455001000003393000003393-inu.xml

  • Moderadores
Postado

Estranho é a NFe ter sido emitida pelo RJ e a inutilização por SP...

Afinal o emitente é de qual UF?

  • Curtir 1
Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

  • Membros Pro
Postado
20 minutos atrás, BigWings disse:

Estranho é a NFe ter sido emitida pelo RJ e a inutilização por SP...

Afinal o emitente é de qual UF?

Então, agora que vi que estava emitente RJ mas configurado SP, isso explica a questão da inutilização. Não entendi porque deixou enviar desse jeito, antes dava erro e tinha que deixar ambos mesmo estado, mas tudo bem, problelma resolvido.

Obrigado.

  • Moderadores
Postado

Bom dia! 
E o comando dado não alterou em nada a nota fiscal. Ela continua autorizada até o momento  tanto na SEFAZ local como no portal nacional. 
Uma vez emitida não é aceito a inutilização do número.  Você teria que testar estes retornos se estão vindo corretos. 
 

tela.png


logoacbr.pngConheça o Portal do Projeto ACBr

Ajude o Projeto ACBr crescer - Assine o SAC ACBr
Assine um dos planos de longa duração do SAC ACBr, obtenha Descontos Especiais, Parcele no Cartão e ainda ganhe Brindes Exclusivos. Saiba mais aqui

Conheça o ACBrLib, o ACBr de forma nativa para qualquer linguagem de programação. Saiba mais aqui

 

 

 

 

  • Consultores
  • Solution
Postado

Bom dia Felipe,

Me tira uma duvida, você tenta inutilizar um numero após o envio e ter ocorrido erro de timeout?

Você considera esse procedimento correto?

Vamos analisar duas situações.

1. A nota é enviada e recepcionada pela SEFAZ, mas por algum problema não obtemos o retorno.

Ao tentar inutilizar o numero dessa nota, o pedido de inutilização deve ser rejeitado uma vez que a nota já consta na base de dados da SEFAZ.

Neste caso sabemos que a nota foi enviada, sendo assim basta agora conseguir o protocolo de autorização.

2. A nota é enviada mas por algum problema não chega até a SEFAZ.

Ao tentar inutilizar o numero dessa nota, o pedido de inutilização é aceito uma vez que a nota não existe na base de dados da SEFAZ.

Neste caso não vamos poder enviar a nota novamente com esse numero uma vez que agora esse numero na SEFAZ consta com inutilizado.

Como você resolve esse problema agora?

Altera o numero da nota e envia novamente?

 

Não seria mais pratico se após o envio realizar uma consulta caso tenha ocorrendo algum erro de timeout?

Se o erro ocorreu no envio, a consulta vai acusar que a nota não consta na base de dados, sendo assim podemos enviar novamente.

Por outro lado se o erro ocorreu após o envio, ou seja, no retorno, a consulta vai retornar o protocolo de autorização ou a rejeição caso a nota tenha alguma informação errada.

Estando o componente carregado com a nota ao realizar a consulta, se o retorno desta retornar que a nota foi autorizada, o componente vai se encarregar de atualizar o XML acrescentando o protocolo de autorização.

Por outro lado se a nota foi rejeitada, devemos efetuar as devidas correções e enviar novamente.

Esse sim é o procedimento correto a ser feito.

 

Repense.

 

Consultor SAC ACBr

Italo Giurizzato Junior
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

Analista de Sistemas / Araraquara-SP

Araraquara - A era dos Trólebus

  • Membros Pro
Postado
3 horas atrás, Italo Jurisato Junior disse:

Bom dia Felipe,

Me tira uma duvida, você tenta inutilizar um numero após o envio e ter ocorrido erro de timeout?

Você considera esse procedimento correto?

Vamos analisar duas situações.

1. A nota é enviada e recepcionada pela SEFAZ, mas por algum problema não obtemos o retorno.

Ao tentar inutilizar o numero dessa nota, o pedido de inutilização deve ser rejeitado uma vez que a nota já consta na base de dados da SEFAZ.

Neste caso sabemos que a nota foi enviada, sendo assim basta agora conseguir o protocolo de autorização.

2. A nota é enviada mas por algum problema não chega até a SEFAZ.

Ao tentar inutilizar o numero dessa nota, o pedido de inutilização é aceito uma vez que a nota não existe na base de dados da SEFAZ.

Neste caso não vamos poder enviar a nota novamente com esse numero uma vez que agora esse numero na SEFAZ consta com inutilizado.

Como você resolve esse problema agora?

Altera o numero da nota e envia novamente?

 

Não seria mais pratico se após o envio realizar uma consulta caso tenha ocorrendo algum erro de timeout?

Se o erro ocorreu no envio, a consulta vai acusar que a nota não consta na base de dados, sendo assim podemos enviar novamente.

Por outro lado se o erro ocorreu após o envio, ou seja, no retorno, a consulta vai retornar o protocolo de autorização ou a rejeição caso a nota tenha alguma informação errada.

Estando o componente carregado com a nota ao realizar a consulta, se o retorno desta retornar que a nota foi autorizada, o componente vai se encarregar de atualizar o XML acrescentando o protocolo de autorização.

Por outro lado se a nota foi rejeitada, devemos efetuar as devidas correções e enviar novamente.

Esse sim é o procedimento correto a ser feito.

 

Repense.

 

Obrigado, vou rever o processo. 

  • Este tópico foi criado há 2350 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.
Visitante
Este tópico está agora fechado para novas respostas
×
×
  • 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.