Skip to main content
Esta página é para quem configura print e cancel contra a Fire. Os operadores da cozinha usam o formulário de Credenciais Fire no backoffice; não escolhem variáveis de ambiente.

​
Cascata de resolução

Em runtime o fire-kds sempre percorre a mesma lista:
  1. Linha ativa de vendor para o vendor do pedido (Vendor ID do backoffice).
  2. Padrão da conta (vendor vazio).
  3. Variáveis de ambiente no servidor fire-kds.
Print e cancel não compartilham o mesmo fallback de env: A API key guardada é a mesma linha para os dois trabalhos. Print envia Authorization: Bearer. Cancel envia x-api-key.
base_url é só o host da Fire (https://br.app.fire.rest). O fire-kds acrescenta o path. Uma URL com /v1/print é recusada no backoffice.

​
Chamada de impressão fiscal

Quando as credenciais resolvem, o fire-kds pede:
  • v1 — Brasil.
  • v2 — Equador e países seguintes (layout RIDE em fiscalRepresentation).
O contrato para partners está em Dados de impressão fiscal. O timeout padrão é 4 segundos. 400 / 401 / 403 são permanentes; o resto enfileira uma nova tentativa.

​
Cancelamento quando a Fire diz não

O cancel usa a mesma cascata e depois POST no adaptador de cancelamento do XMART com x-api-key. Se a Fire (ou o adaptador) responder 4xx:
  • O operador vê O Fire rejeitou o cancelamento mais o detalhe de policy (reasonDetail e, quando vier, limiar / tempo decorrido).
  • O trabalho de cancel fica falho. O ticket não é marcado como cancelado.
  • O mesmo input não é tentado de novo sozinho.
Um cancelamento posterior bem-sucedido, ou um bump, é o que tira o ticket da cozinha. Veja Ações na tela para o texto do operador.

​
O que isto não é

  • Não é o Agente Fire (WebSocket da impressora local). Isso é Periféricos, impressão e validação.
  • Não é o catálogo de motivos de cancelamento. Isso vive nas configurações KDS da loja.