Skip to main content
Esta página es para quien configura print y cancel contra Fire. Los operadores de cocina usan el formulario de Credenciales Fire en el backoffice; no eligen variables de entorno.

​
Cascada de resolución

En runtime fire-kds siempre recorre la misma lista:
  1. Fila activa de vendor para el vendor de la orden (Vendor ID del backoffice).
  2. Default de cuenta (vendor vacío).
  3. Variables de entorno en el servidor fire-kds.
Print y cancel no comparten el mismo fallback de env: La API key guardada es la misma fila para ambos trabajos. Print envía Authorization: Bearer. Cancel envía x-api-key.
base_url es solo el host de Fire (https://br.app.fire.rest). fire-kds agrega el path. Una URL con /v1/print se rechaza en el backoffice.

​
Llamada de impresión fiscal

Cuando las credenciales se resuelven, fire-kds pide:
  • v1 — Brasil.
  • v2 — Ecuador y países posteriores (layout RIDE en fiscalRepresentation).
El contrato para partners está en Datos de impresión fiscal. El timeout por defecto es 4 segundos. 400 / 401 / 403 son permanentes; el resto encola un reintento.

​
Cancelación cuando Fire dice que no

Cancel usa la misma cascada y luego POST al adaptador de cancelación de XMART con x-api-key. Si Fire (o el adaptador) responde 4xx:
  • El operador ve Fire rechazó la cancelación más el detalle de policy (reasonDetail y, si viene, umbral / tiempo transcurrido).
  • El trabajo de cancel queda fallido. El ticket no se marca cancelado.
  • El mismo input no se reintenta solo.
Una cancelación posterior exitosa, o un bump, es lo que saca el ticket de la cocina. Ver Acciones en pantalla para el copy del operador.

​
Lo que esto no es

  • No es el Agente Fire (WebSocket de impresora local). Eso es Periféricos, impresión y validación.
  • No es el catálogo de motivos de cancelación. Eso vive en los ajustes KDS de la tienda.