fiscal.authority, con la forma que se describe acá.
Si todavía no la leíste, Cómo funciona lo fiscal en Fire explica los dos actos y los dos bloques que esta página da por conocidos.
Qué pasa, paso a paso
- Tu proveedor hace POST del callback fiscal. Fire lo valida y responde
202 Accepted. Un202significa encolado, no procesado, y nunca significa que se envió un evento. - Un worker en segundo plano guarda el veredicto en la orden, normalmente en un par de segundos.
- Según el
eventType, Fire emite un evento a tus Integration Flows — o no.
Qué evento sale
Solo se emite un evento cuando el callback realmente cambió el documento. Un reenvío de un estado ya aplicado (
idempotent), un callback que haría retroceder el documento (regression) o uno que no coincide con ningún documento (notFound) igual se responde con 202, y no emite nada.
Dónde cae cada campo del callback
Todo lo de abajo cae enorders.fiscal.authority, y de ahí en los eventos.
Tres reglas explican la tabla:
documentpasa a sercountryData. Fire no guarda una lista de las claves de cada país: todo lo que viene endocumentllega intacto acountryData. Un identificador nuevo que tu ente empiece a exigir viaja sin ningún cambio del lado de Fire.providerymetadataconservan los nombres de la numeración. Del lado de la numeración el proveedor también envíaproviderymetadata, y Fire los expone comoproviderIdentityyproviderMetadata. El callback hace lo mismo, así que los dos bloques de la orden se leen igual.providerIdentity.referencees lo que le citas al proveedor para encontrar la operación en sus registros.- Vacío significa
null, no ausente. Un callback sinproviderometadata(o con{}) guardaproviderIdentity: nullyproviderMetadata: null.
Dónde aparece en cada evento
La referencia campo por campo de ese bloque está en el bloque fiscal.
El camino sin callback: Brasil (PlugNotas)
En Brasil no hay callback fiscal: Fire conoce el veredicto de SEFAZ directamente por PlugNotas. El bloque que recibe tu consumidor tiene la misma forma, con estas diferencias:Una orden, de punta a punta
La misma orden brasileña por el callback fiscal, recortada a las partes fiscales.1
Callback: authorized
2
Fire responde 202 y después guarda el veredicto
3
order.invoiced lo lleva
4
La orden se cancela en Fire
order.cancelled sale de inmediato con data.cancellation.fiscal = { "status": "authorized", "authority": { … } } — la factura tal como estaba. Todavía no se le consultó nada al ente.5
Callback: cancelled, y después order.reversed
El proveedor envía
eventType: "cancelled" con su propio eventId (reusar el de la autorización devuelve 409). Fire emite order.reversed con authority.documentType: "CREDIT_NOTE", cancelledAt completado, los dos documentos en history y compensates apuntando a la factura.Lo que no pasa
- No hay evento para
rejected,deniednierror. Se guardan; tu consumidor solo los ve enlastKnown.fiscal.statusde un evento posterior. - Un
202no es un evento. Consulta el endpoint de resultado si necesitas saber que el callback se procesó. - El callback no cambia
fiscalRepresentation. Lo que se imprimió en la caja queda como estaba. - No hay guard por proveedor. Una orden tiene un solo documento. Cuando la orden ya tiene un documento, un
authorizedcuyoeventIdno coincide termina ennotFoundy no cambia nada; si la orden no tiene documento, elauthorizedlo crea. UneventIdque Fire no emitió para esa orden se rechaza con400antes del202. Uncancelledresuelve el documento más reciente de la orden y lo actualiza, sin importar qué proveedor lo emitió — PlugNotas incluido.

