- v2 · actual
- v1.2 · deprecado
- v0 · deprecado
Estás viendo el contrato actual (v2) de
order.invoiced. v2 es un cambio que rompe solo en data.fiscal: la bolsa plana se reemplaza por un bloque estructurado — campos canónicos dentro de authority, los identificadores del ente dentro de authority.countryData, los montos dentro de authority.amounts — más history y compensates. docType y dataAutorizacao ya no se emiten; cStat viaja dentro de authority.countryData. El resto del snapshot de la orden no cambia. Ver Rutas que cambian respecto del contrato anterior.order.invoiced dispara cuando la autoridad fiscal del país autoriza el documento fiscal asociado a una orden — SEFAZ en Brasil, SRI en Ecuador, DIAN en Colombia, AFIP en Argentina, SII en Chile, SENIAT en Venezuela.
Este evento es separado de order.completed: la orden se paga primero (order.completed), después el documento se emite vía tu proveedor fiscal, y order.invoiced dispara solo cuando la autoridad devuelve la autorización.
Condición de disparo
Fire emiteorder.invoiced cuando un documento fiscal de la orden llega a authorized, ya sea que Fire se entere por su integración nativa con el proveedor o por el callback fiscal con eventType: "authorized".
Qué hay en trigger.data
El mismo snapshot V4 de orden que order.completed, más el bloque fiscal descrito abajo. El status de la orden queda en "COMPLETED": una autorización fiscal no cambia el status de la orden.
Ejemplo — Brasil (NFC-e, sanitizado)
Los bloques elididos como igual que
order.completed son exactamente el snapshot que lleva order.completed. Ver la referencia de campos de order.completed.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.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.
Dónde viven los totales fiscales
authority.amounts son los montos del documento tal como los reportó el ente. Los agregados propios de la orden (vBC, vNF, vICMS…) siguen en data.payments.metadata.fiscal, y la clasificación por línea (NCM, CFOP) en data.orderLines[n].metadata.fiscal — igual que en order.completed.
Handler de ejemplo
Errores comunes
- Lee
fiscal.authority.*, nofiscal.*. Los campos planos de v1.2 ya no están. La tabla de Rutas que cambian mapea cada uno. - No alinees por hora con
authorizedAten Brasil. Lleva una medianoche convencional; usaissuedAtpara la hora. historyincluye el documento vigente. No cuentes sus entradas como “documentos anteriores”.- No hay evento para
rejected/denied/error. Esos resultados se guardan pero no disparanorder.invoiced.
Eventos relacionados
order.completed
Dispara antes que este evento — la orden en sí.
order.reversed
Dispara después si el documento se cancela ante la autoridad.
Callback fiscal
Cómo un proveedor reporta la autorización que dispara este evento.
data.fiscalRepresentation
Sin cambios en v2. Es la numeración fiscal que el punto de venta obtuvo antes de inyectar la orden — lo que se imprimió en la caja — y es un bloque distinto de fiscal: fiscalRepresentation es lo que se numeró, fiscal.authority es lo que decidió el ente. La referencia de campos está en order.completed y en la página v1.2.