Durante o processo de homologação das rotas de inutilização de numeração de NF-e e NFC-e percebemos que alguns campos documentados não estavam sendo retornados.
Quando rejeitado, não é retornado o número de protocolo (não sei se esse é o comportamento esperado, se sim, talvez fosse interessante colocar isso na documentação).
Em todos os casos (rejeitado ou registrado), os campos: codigo_mensagem, mensagem e chave_acesso não aparecem no JSON de retorno (talvez não existam de fato e tenham sido documentados indevidamente).
Outro problema parece ser com as datas, a data de recebimento, quando a inutilização é rejeitada parece estar vindo com um offset de horas errado (a conversão do timezone para UTC parece estar sendo executada duas vezes), exemplo:
No caso a requisição foi feita no dia 02/10 às 21h10, horário de Brasilia, então a data do evento está correta em UTC (dia 03/10 00h10), porém a data de recebimento teve o offset aplicado novamente (dia 03/10 03h10).
De acordo com a documentação da SEFAZ, o número do protocolo só é retornado quando o pedido de inutilização é homologado (código de status 102). Nos demais casos, não existe número de protocolo. Iremos adicionar essa informação na documentação da API em breve.
Esse é um comportamento esperado. Para o caso de pedido de inutilização, os referidos campos não serão incluídos no JSON. Iremos adicionar essa informação na documentação da API em breve
Com relação a esse caso, não conseguimos reproduzir o erro. Em todos os nossos testes, as duas datas aparecem corretamente. Você poderia nos fornecer o id da inutilização onde a propriedade data_recebimento aparece com o offset incorreto?
Boa tarde, Arimateia, quanto aos dois primeiros itens, eu suspeitei que talvez fosse o caso mesmo, mas obrigado pelas confirmações, farei o devido tratamento aqui com relação ao protocolo em pedidos não homologados.
Quanto ao último item, a inutilização com ID 3a06b281-9ba1-4d77-b14c-bdc6b24d5c2a é a que utilizei para o meu exemplo acima (de onde retirei as datas citadas).
Identificamos que é a SEFAZ-RS que está retornando o offset incorreto. Para comprovar isso, baixe o XML da inutilização (endpoint GET /nfe/inutilizacoes/{id}/xml) e verifique o conteúdo da tag retInutNFe/infInut/dhRecbto.
Não encontramos esse problema em testes realizados com outras autorizadoras.
Entendi, tentei fazer a chamada no endpoint informado, mas ele retorna erro 404 de que o evento não foi encontrado quando tento fazer para esse ID que informei (que foi rejeitado), como a inutilização que foi homologada estava com a data correta, o XML dela também estava correto.
Não sei se o XML está disponível também apenas para inutilizações que tenham sido homologadas, nesse caso não consigo verificar por aqui o XML para validar, mas obrigado pelo retorno!
O XML também fica disponível para inutilizações que foram rejeitadas pela respectiva SEFAZ autorizadora.
No seu caso específico, a URL para acessar o XML da inutilização mencionada anteriormente deve ser: GET https://api.sandbox.nuvemfiscal.com.br/nfe/inutilizacoes/3a06b281-9ba1-4d77-b14c-bdc6b24d5c2a/xml.
Sim, se faço a requisição para o ID 3a06b291-a3e3-4e1c-8120-d5f8b0a62022, que foi autorizado, na URL: https://api.sandbox.nuvemfiscal.com.br/nfe/inutilizacoes/3a06b291-a3e3-4e1c-8120-d5f8b0a62022/xml
Tenho o retorno correto do XML, mas se faço para o ID 3a06b281-9ba1-4d77-b14c-bdc6b24d5c2a, que foi rejeitado, na URL: https://api.sandbox.nuvemfiscal.com.br/nfe/inutilizacoes/3a06b281-9ba1-4d77-b14c-bdc6b24d5c2a/xml
Ele retorna erro 404:
{
"error": {
"code": "EventoDfeXmlNotFound",
"message": "Xml do evento 3a06b281-9ba1-4d77-b14c-bdc6b24d5c2a não disponível."
}
}
Entendi, eu estava apenas tentando visualizar o XML como você tinha informado para ver a data de recebimento, a rota de detalhes eu já havia utilizado e foi onde vi o offset incorreto.
Acho que como os pontos que mencionei no post inicial já foram respondidos, podem fechar esse ticket então.