Skip to main content
Descontinuada (v1). Contrato anterior, mantido apenas como referência histórica. A versão atual é order-reversed — v2.
order.reversed dispara quando a SEFAZ confirma o cancelamento de um documento fiscal (NFC-e ou NF-e) que tinha sido previamente autorizado. É a contraparte SEFAZ-confirmada de order.cancelled: o pedido é cancelado primeiro dentro do Fire (disparando order.cancelled), o Fire então pede o cancelamento na SEFAZ via seu provedor fiscal, e order.reversed dispara apenas quando a SEFAZ carimba o protocolo de cancelamento.

Condição de disparo

O Fire emite order.reversed uma vez por cancelamento fiscal, na primeira vez em que tudo o seguinte é verdade:
  • O pedido está em uma loja com faturamento fiscal habilitado (storeFiscalConfig.enabled === true)
  • Um documento fiscal tinha sido previamente autorizado (ou seja, order.invoiced foi emitido antes)
  • Uma solicitação de cancelamento foi enviada ao seu provedor fiscal
  • O seu provedor fiscal reporta que a autoridade fiscal confirmou o cancelamento

O que tem em trigger.data

Mesmo snapshot V4 que order.cancelled — incluindo o mesmo bloco cancellation de auditoria — com um sub-objeto extra sefazCancellation dentro de cancellation.metadata.fiscal. Essa é a única diferença estrutural. status é "CANCELLED". O pedido é o mesmo referenciado pelo evento order.cancelled anterior do mesmo orderId.

Exemplo — payload real de produção (BR, sanitizado)

Referência de data.cancellation.metadata.fiscal.sefazCancellation

Este é o único bloco que é único de order.reversed. Cada outro campo é compartilhado com order.cancelled — veja essa página para os campos de auditoria de cancelamento.
object
Confirmação SEFAZ do cancelamento. Presente apenas após a SEFAZ ter carimbado o protocolo de cancelamento.

Lifecycle

Para um pedido brasileiro fiscal-enabled, espere os quatro eventos acima. Para pedidos brasileiros sem autorização fiscal (porque o pedido foi cancelado antes da emissão fiscal, ou o fiscal estava desabilitado), apenas order.cancelled dispara — não order.reversed.

Handler de exemplo

Erros comuns

  • Não processe order.reversed sem order.cancelled primeiro. Eles disparam em ordem em fluxo normal, mas entrega fora de ordem é possível. Se você receber order.reversed para um orderId que não tem como cancelado registrado, logue e crie o registro a partir do bloco cancellation deste evento — não jogue o evento fora.
  • sefazCancellation.date e cStat podem ser null em sandbox. Não faça com que a production-readiness dependa de eles estarem presentes em ambientes dev.
  • A URL do XML de cancelamento é distinta do XML do documento original. Garanta que sua lógica de arquivamento salve ambos — você precisará deles para auditoria.
  • Mesmo cancellation.cancellationId que order.cancelled. Ambos os eventos para o mesmo cancelamento compartilham o cancellation ID — útil como chave de join ao correlacionar os dois eventos no seu sistema.
  • Não há evento para cancelamento SEFAZ falho. Se a SEFAZ rejeita a solicitação de cancelamento, nenhum evento dispara. Monitore o log de execuções do dashboard para esses casos.

Eventos relacionados

order.cancelled

Dispara antes deste evento — o cancelamento em si.

order.invoiced

O evento anterior que estabeleceu o documento fiscal sendo cancelado aqui.