Visão geral e conceitos

Esta seção explica como configurar e administrar uma cozinha digital (KDS) a partir do backoffice da Fire, sem entrar em código. É voltada para operações, implantação em loja e suporte de produto. Onde você trabalha: o menu KDS, em /kds/admin. Para as ações diárias do operador na tela de cozinha, consulte Ações na tela e Painel de senhas. Para cadastrar TVs de cozinha sem e-mail, consulte Emparelhar um dispositivo. Supervisores que monitoram a loja inteira usam o Board do operador.

Antes de começar

O que você precisa

Requisito	Detalhe
Acesso ao módulo KDS	Um papel com permissões KDS na conta.
Uma loja KDS criada	KDS → All Stores → Create store. Ao criar uma loja nova, o sistema pode levar você ao assistente de configuração inicial.
Uma tela física (fire-kds)	Cada TV/tablet de cozinha executa o fire-kds. Prefira o emparelhamento de dispositivo (código de 6 dígitos) para que o dispositivo entre na loja sem convite por e-mail.

Para a maioria das lojas a configuração padrão é suficiente: estações genéricas, roteamento com fallback para todas as estações ativas e regras de estação em “aceitar tudo”. Os ajustes finos por item_type, canal ou serviço são opcionais e explicados mais adiante.

Como as peças se relacionam

Loja
 ├── Estações       → "filas" lógicas de cozinha (Grelha, Fritadeira, Montagem, Despacho…)
 ├── Telas          → dispositivos físicos que exibem tickets
 │    └── Atribuição  → quais estações cada tela mostra (tela ↔ estação)
 ├── Estratégia de roteamento → para qual estação vai cada linha (padrão: fallback para todas)
 ├── Dispositivo de teclado → teclado USB/BT associado a uma tela
 │    └── Layout de teclado → qual tecla executa qual ação (bump, recall, etc.)
 └── Impressão pronto-retirada → opcional; uma única tela por loja

Regra mental: o roteamento decide para qual estação de produção vai cada item; a tela decide quais estações o operador vê naquele monitor.

Dois tipos de estações

Nem toda estação é configurada da mesma forma:

Tipo	Workflow stage	Escolhida por item_type no roteamento?	O que recebe
Produção	`PRODUCTION`, `PRE_ASSEMBLY`	Sim — mappings + fallback	Cada linha do pedido (item a item).
Convergência	`ASSEMBLY`, `DISPATCH`	Não — não aparecem nas linhas de mapping	O ticket inteiro quando a produção avançou (fluxo de convergência).

Em Routing → Mappings, o backoffice só permite escolher estações de produção / pre-assembly. Montagem e despacho não são roteáveis por item: você não pode definir “BURGER → ASSEMBLY” em uma linha de mapping. Em vez disso:

ASSEMBLY / DISPATCH recebem o ticket inteiro, não linha por linha. Com Produção obrigatória = Sim, isso acontece quando as linhas de produção são concluídas (gates de convergência). Com Produção obrigatória = Não (cozinha assembly-only), o ticket aparece assim que o pedido entra.
Na estratégia você configura a convergence distribution (qual estação de montagem ou despacho recebe o ticket quando há várias).
Na estação de montagem/despacho você pode filtrar por canal de venda (POS, KIOSK, UBER_EATS…) ou tipo de serviço (DINE_IN, DELIVERY, TAKEOUT…) — não por item_type.

Padrões de cozinha

Cozinha simples (uma única fila)

Há dois padrões válidos para uma cozinha pequena. O que usamos em produção hoje é o B (assembly-only).

Padrão B — uma única estação ASSEMBLY (produção) ⭐
Padrão A — estação de produção KITCHEN

Cozinha mínima real: 1 estação ASSEMBLY + 1 tela + Produção obrigatória = Não.

Passo	O que fazer
1	Store settings: Produção obrigatória = Não.
2	Criar uma estação `ASSEMBLY` (convergence ativada).
3	Criar uma tela; atribuir só `ASSEMBLY`.
4	Roteamento ativo (mappings vazios bastam).
5	(Opcional) Impressão pronto-retirada nessa tela.
6	Painel de senhas em `/waitlist/{storeId}`.

Pedido → ASSEMBLY (imediato) → cozinhar → bump ticket → painel "Pronto" + impressão opcional

Modelar a cozinha como “produção” pura (sem stage ASSEMBLY):

Passo	O que fazer
1	Criar uma estação com stage `PRODUCTION` (ex. code `KITCHEN`).
2	Criar uma tela e atribuir só essa estação.
3	Criar roteamento sem mappings e fallback apontando para essa única estação.
4	Regras de estação em Accept all item types.
5	Produção obrigatória = Sim (padrão).

Pedido → (sem mapping) → fallback → estação KITCHEN → tela única → bump por linha

Se a cozinha crescer depois, você adiciona estações de produção, ativa Produção obrigatória = Sim e mapeia por item_type. ASSEMBLY passa a ser o expo onde o ticket converge quando a produção termina.

Fluxo operacional (assembly-only)

Este é o setup usado em lojas pequenas hoje em produção: uma estação de montagem, uma tela, sem grelha/fritadeira/despacho separados.

O pedido entra — o POS/kiosk envia o pedido ao KDS. Um ticket é criado com suas linhas.
Painel: “Em preparo” — enquanto o pedido está SENT_TO_KITCHEN, seu código aparece na área de preparo.
Ticket na tela — com Produção obrigatória = Não, o ticket entra direto na coluna ASSEMBLY.
Operador cozinha — vê o ticket inteiro: código, canal, serviço, itens e modificadores. Pode usar HOLD se necessário.
Bump — em ASSEMBLY é um bump por pedido (ticket inteiro).
O ciclo de cozinha fecha — sem estação DISPATCH, o bump na montagem é o passo final: pedido → pronto para retirada, ticket KDS → DONE.
Snackbar “Enviado” — aparece por alguns segundos com a opção Desfazer (janela configurável, ~3 min).
Painel: “Pronto” — o mesmo código salta para a área de pronto para retirada.
Impressão (se configurada) — cupom fiscal e/ou ticket de entrega.
O cliente retira — usando o código na tela ou o ticket impresso.

Para a experiência completa do operador nesses passos, consulte Ações na tela.

Cozinha multi-estação (referência)

Para cozinhas com grelha + montagem + despacho, o fluxo é mais longo:

Pedido
  └─► Roteamento por item_type → estações PRODUCTION (GRILL, FRY, KITCHEN…)
        └─► Regras opcionais (canal / serviço / item)
              └─► Tela de produção → bump POR LINHA
                    └─► O gate de convergência abre quando a produção termina
                          └─► ASSEMBLY (ticket inteiro) → bump
                                └─► DISPATCH (opcional) → bump
                                      └─► READY_FOR_PICKUP + painel de senhas + impressão

Opções KDS no nível da loja (fire-kds)

Quando o layout do backoffice já existe, os managers podem ajustar o comportamento da cozinha em fire-kds → Configurações → KDS (e sobrescritas por tela na tela de produção):

Opção	O que controla
Defaults de display	Escala de fonte, tamanho do cartão, alerta de pedido novo (visual ± som). As telas podem seguir a loja ou manter valores locais.
Riscar linhas	Exigir tocar cada linha pai antes do bump, opcionalmente limitado a certas estações.
Nome do cliente nos tickets	Mostrar ou ocultar o nome, opcionalmente só para canais / tipos de entrega selecionados.
Filtros do painel de senhas	Ocultar tipos de entrega (ex. delivery) do painel voltado ao cliente.
Motivos de cancelamento	Quais motivos do catálogo Fire os operadores podem escolher ao cancelar no KDS / board do operador.

Próximo: Configurar uma loja · Emparelhar um dispositivo · Board do operador.

Quiosque

POS

KDS

BOH

Agente Fire

Backoffice

PayBridge

Visão geral e conceitos

Antes de começar

O que você precisa

Como as peças se relacionam

Dois tipos de estações

Padrões de cozinha

Cozinha simples (uma única fila)

Fluxo operacional (assembly-only)

Cozinha multi-estação (referência)

Opções KDS no nível da loja (fire-kds)

​Antes de começar

​O que você precisa

​Como as peças se relacionam

​Dois tipos de estações

​Padrões de cozinha

​Cozinha simples (uma única fila)

​Fluxo operacional (assembly-only)

​Cozinha multi-estação (referência)

​Opções KDS no nível da loja (fire-kds)

Antes de começar

O que você precisa

Como as peças se relacionam

Dois tipos de estações

Padrões de cozinha

Cozinha simples (uma única fila)

Fluxo operacional (assembly-only)

Cozinha multi-estação (referência)

Opções KDS no nível da loja (fire-kds)