- v3 · actual
- v2 · deprecado
- v1 · deprecado
Estás viendo el contrato actual (v3) de
order.reversed. v3 es un cambio que rompe solo en el bloque fiscal: pasa de cancellation.metadata.fiscal a cancellation.fiscal, se vuelve estructurado (authority, history, compensates) y sefazCancellation ya no se emite. Los campos de auditoría de cancellation agregados en v2 (cancellationType, cancellationGroup, cancellationNote) no cambian. Ver Rutas que cambian respecto del contrato anterior.order.reversed dispara cuando la autoridad fiscal confirma la cancelación de un documento que había autorizado previamente. Es el resultado fiscal de order.cancelled: la orden se cancela primero dentro de Fire (order.cancelled), la cancelación se pide ante la autoridad vía tu proveedor fiscal, y order.reversed dispara solo cuando la autoridad la aprueba.
Condición de disparo
Fire emiteorder.reversed cuando un documento fiscal de la orden llega a cancelled — por su integración nativa con el proveedor o por el callback fiscal con eventType: "cancelled" — y la orden tiene un registro operativo de cancelación en Fire. Sin ese registro el evento no se emite: el bloque cancellation es lo que le dice a los consumidores que esto es una anulación y no una venta.
Qué hay en trigger.data
El mismo snapshot V4 de orden que order.completed, con status: "CANCELLED", más el bloque cancellation: los mismos campos de auditoría que order.cancelled y, dentro, el bloque fiscal con el documento cancelado.
Campos de efectivo en
payments.paymentMethods[]. customerCashAmount y changeAmount son números. Las órdenes inyectadas antes del 24 de septiembre de 2026 traen customerCashAmount como el texto "0" y sin changeAmount: si reenviás o reprocesás eventos viejos, leé el campo como número. Ver la referencia de campos de order.completed.Ejemplo — Brasil (NFC-e, sanitizado)
Fíjate que en Brasil
authority.documentNumber y compensates.documentNumber son iguales (12388): SEFAZ anula el documento en vez de emitir uno nuevo. En regímenes donde una cancelación es una nota de crédito separada, difieren.Referencia de data.cancellation
Los campos de auditoría son los mismos que en order.cancelled — incluido cancellationId, que ambos eventos comparten para la misma cancelación y puedes usar como llave de unión. El bloque fiscal se documenta abajo.
El bloque fiscal
Para ver cómo llega acá cada campo del callback fiscal, consulta Del callback a los eventos. El bloque fiscal deorder.invoiced, order.cancelled y order.reversed es lo que Fire guardó en la orden, con la misma forma. No se rearma por emisor: ya sea que el documento haya entrado por la integración nativa de tu proveedor fiscal o por el callback fiscal, lees los mismos campos a la misma profundidad.
Dónde vive en cada evento
Campos del bloque
string | null
El estado fiscal de la orden, no de un documento:
awaiting_payment, not_issued, pending, processing, fiscal_graphic, authorized, cancelling, cancelled, rejected, denied, error. En la práctica order.invoiced lleva authorized, order.reversed lleva cancelled y order.cancelled lleva authorized o cancelling.string | null
Código ISO 3166-1 alfa-2 del régimen que emitió el documento (
BR, CO, EC, CL, AR, VE). El país ya no vive en el nombre del evento: filtra por este campo.string | null
Identificador de Fire para el adaptador que procesó el documento (
plugnotas, generic). Es nuestro, no el nombre del proveedor.string | null
Timestamp ISO 8601 UTC del hecho fiscal que disparó el evento, tal como lo reportó el proveedor.
object | null
El veredicto del ente sobre el documento vigente. Los campos que significan lo mismo en todo país van arriba; los identificadores propios del ente van en
countryData, con el vocabulario de ese país.object[]
Cada parada del recorrido fiscal de la orden que describe un documento, de la más vieja a la más nueva — incluida la vigente. En
order.invoiced suele tener una entrada, igual a authority; en order.reversed tiene la factura y después la cancelación. Las paradas sin bloque de documento no aparecen — por ejemplo el cancelling que Fire asienta antes de consultar al ente; un processing que ya trae la numeración de la caja sí aparece.No es
fiscalRepresentation.history. Ese lista solo los documentos anteriores de la numeración; este es el recorrido completo y termina con el documento vigente.object | null
Un puntero al documento que el vigente reemplaza. Presente cuando el estado fiscal de la orden es
cancelled; null en otro caso. Apunta a la última parada de history que no es a su vez una cancelación — busca su documentNumber ahí para tener el documento entero.No lleva
reason, a diferencia de fiscalRepresentation.compensates. El motivo ya viaja en el mismo evento, con más detalle: cancellation.cancellationType, cancellationGroup, cancellationReason, cancellationNote y cancellationSource. Fire no emite order.reversed sin un registro operativo de cancelación, así que ese bloque siempre está cuando está compensates. Un código fijo ORDER_CANCELLATION acá diría lo mismo con menos información. El bloque de numeración sí lleva reason: es donde el código canónico se resuelve al texto que se imprime en la nota de crédito, que necesita la redacción propia de la empresa.En Brasil el puntero se refiere al mismo número. SEFAZ no numera un documento nuevo para cancelar uno, así que
compensates.documentNumber es igual a authority.documentNumber. Es correcto, no un bug.countryData y el callback fiscal
countryData es un bloque con tres nombres, según de qué lado de Fire lo mires:
Lo que tu proveedor manda en el
document del callback es lo que recibes en authority.countryData, con los mismos nombres de clave. La regla que separa a los dos es la exclusión: toda clave del callback que no sea un campo canónico cae intacta en countryData. Por eso un identificador nuevo de un país viaja sin ningún cambio del lado de Fire.
Los campos raíz del callback pasan a ser los campos de primer nivel de authority con los mismos nombres, salvo los tres importes, que se agrupan en amounts. provider y metadata pasan a ser providerIdentity y providerMetadata (null si están ausentes o vacíos). La tabla campo por campo está en Del callback a los eventos.
El
protocolo de Brasil vive en countryData, no arriba. Solo SEFAZ lo tiene — Chile tiene trackId, Argentina el cae — así que es vocabulario del ente, no un campo canónico. Las órdenes guardadas antes de este contrato lo tenían arriba como authorizationProtocol; Fire también lo emite como countryData.protocolo para esas.Rutas que cambian respecto del contrato anterior
Cada ruta anterior tiene exactamente una ruta actual. El payload no lleva número de versión: la versión pertenece a este contrato documentado.
Lifecycle
Una orden cancelada antes de que su documento fuera autorizado dispara soloorder.cancelled: no hay nada que revertir ante la autoridad.
Handler de ejemplo
Errores comunes
- Lee
cancellation.fiscal, nocancellation.metadata.fiscal. La ruta anterior viene vacía en v3. sefazCancellationya no está. La fecha de cancelación esauthority.cancelledAt; los identificadores del ente están enauthority.countryData.- Es posible la entrega fuera de orden. Si llega
order.reversedde una orden para la que no tienes cancelación, créala a partir del bloquecancellationde este evento en vez de descartar el evento. - No hay evento para una cancelación fallida. Si la autoridad rechaza la cancelación, no dispara ningún evento.
Eventos relacionados
order.cancelled
Dispara antes que este evento — la cancelación de la orden en sí.
order.invoiced
El evento que reportó el documento que acá se cancela.
Callback fiscal
Cómo un proveedor reporta la cancelación que dispara este evento.
data.fiscalRepresentation
Sin cambios en v3. Tiene los números del comprobante impreso en la caja — el que se está anulando — y es un bloque distinto de cancellation.fiscal: fiscalRepresentation es lo que se numeró, authority es lo que decidió el ente. La referencia de campos está en la página v2.