Компонент 03. Кухня и производство (KDS / Kitchen Operations)¶

Статус: ревизия №2 по итогам аудита корпуса · 10.10.2026. Числовые факты сопровождаются ссылками; канонические перечисления — в «Модели данных», §0.

Домен D3. Место, где заказ превращается в еду и где теряются или зарабатываются 5–10 п.п. фудкоста (ориентир сети — 25–30% выручки, см. ../glossary.md). Задача модуля — скорость без ошибок и полное списание по техкартам.

1. Функциональные требования¶

1.1. Маршрутизация заказов¶

flowchart LR
    O["Заказ из любого канала"] --> R["Разложение позиций по станциям: правила точки"]
    R --> S1["Горячий цех"]
    R --> S2["Холодный цех"]
    R --> S3["Гриль и фритюр"]
    R --> S4["Бар"]
    R --> S5["Кондитерка"]
    S1 --> E["Экран экспо/шефа: курсы, синхронизация подач"]
    S2 --> E
    S3 --> E
    S4 --> E
    S5 --> E
    E --> X{"Зал или доставка?"}
    X -->|"зал"| V["Выдача гостю"]
    X -->|"доставка"| P["Упаковка и курьер"]
    R -.->|"резервный канал"| PR["Цеховые принтеры"]

Позиции заказа автоматически раскладываются по станциям/цехам: горячий, холодный, гриль, фритюр, бар, кондитерка, упаковка.
Правила маршрутизации настраиваются на точку; печать на цеховые принтеры как резервный канал и/или экраны.
Разбиение на подачи (курсы) и «вместе с…», приоритеты, пометки «аллергия», «без лука» — до повара, а не до кассира.

1.2. Кухонный экран (KDS)¶

Цветовые статусы с таймерами: новый → в работе → готов → выдан/упакован; просрочка подсвечивается.
Объединение позиций по блюдам (группировка одинаковых позиций из разных заказов в пиковые часы).
Фото подачи и состав блюда прямо на экране (ТТК на экране) — повар не уходит за бумажной картой.
Объявление «стоп-листа» с кухни — мгновенно во все каналы продаж.
Экраны шефа/экспо: контроль всех заказов, перераспределение между станциями, «запаздывающие» позиции.

1.3. Тайминги и дисциплина¶

Норматив приготовления на блюдо/категорию (по ТТК); факт — от статусов на экране.
Отчёты: среднее время приготовления по станции/повару/смене, доля просроченных заказов, узкие места по часам загрузки.
Контроль времени выдачи для доставки (обещание «45 минут» начинается на кухне).

1.4. Производство и полуфабрикаты¶

Многоуровневые ТТК: блюдо состоит из полуфабрикатов, полуфабрикат — из сырья; списание корректно на любом уровне.
Акты производства и разбора: цех выпустил партию заготовок из сырья — склад переместился «сырьё → заготовка» с фиксацией выхода и потерь.
Планирование заготовок по прогнозу продаж (с учётом сезонности и дней недели) и сроков годности.
Бракераж и списание готового: просрочка на витрине — актом, а не «пропало».

1.5. Статусы: два уровня, один канонический словарь¶

Канонические перечисления платформы зафиксированы в 12-data-model.md, §0; KDS работает с двумя уровнями и не смешивает их:

Уровень заказа (Order.status):

stateDiagram-v2
    [*] --> accepted
    accepted --> kitchen : маршрутизация по станциям
    kitchen --> ready : все тикеты готовы
    ready --> served : зал — подан гостю
    ready --> packed : доставка — упакован
    packed --> delivered : назначение курьера вручено

Уровень станции (KitchenTicket.status):

stateDiagram-v2
    [*] --> queued
    queued --> cooking : повар взял
    cooking --> ready : готово, списание по ТТК
    ready --> served : выдан на экспо/в зал

Экраны повара показывают тикеты (queued | cooking | ready | served); экраны шефа/экспо и кассы — заказы.
«Передан курьеру» — не статус заказа или тикета, а DeliveryAssignment.status = picked_up (заказ остаётся packed до delivered).
Просрочка по нормативу подсвечивается на каждом шаге обоих уровней.

2. Как это сделано у аналогов¶

iiko: выбор схемы — цеховые принтеры или терминал шефа с контролем времени приготовления, просмотром ТТК и оформлением актов списания/разбора/перемещения 1; контроль свежести блюд на витрине — только в Enterprise-тарифе 2.
r_keeper КДС Про: визуализация заказов и статусов, тайминги, ЭДО при выпуске продукции, печать этикеток с весом/составом/сроком годности; заявлено снижение ФОТ кухни на 10–30% 3.
Saby Presto «Монитор производства»: на планшете повара — рецептура, фото подачи, комментарии гостей, остатки, списания, подписание документов 4.
Toast KDS: цветные статусы, маршрутизация по станциям, флаги аллергенов, coordination expo; тестировщики отмечают устойчивость линии в пиковые часы 5.
Lightspeed KDS: маршрутизация по станциям, курсы и приоритеты, дашборды производительности кухни 6.
Revel KDS: кастомные кухонные процессы, мультисцены, разделение потоков доставки и зала 6.

3. Метрики домена¶

Время «заказ принят → готов» (медиана/перцентили) по станциям.
Доля заказов с просрочкой по нормативу; доля позиций, возвращённых гостем из-за ошибок.
Загрузка станции по часам (для планирования смен и заготовок).
Точность списаний: план по ТТК против факта инвентаризации (см. компонент 04).

4. Требования к реализации для lovii¶

KDS — web-приложение на любом планшете/экране, офлайн-устойчивое (локальная очередь тикетов).
Связка «тикеты ↔ склад»: статус «готов» триггерит списание по ТТК, а не момент пробития (так честнее для многоуровневых полуфабрикатов) — но с возможностью обратной корректировки.
«Фабрика-кухня» как отдельный тип объекта: производство заготовок и отгрузка на точки с приёмкой на месте (модель есть у r_keeper — приложение официанта + кассы + интерфейс фабрики-кухни + доставка + склад 7).
Видеонаблюдение поверх тикетов: инцидент «заказ готовился 25 минут» → клип из видео (антифрод и обучение).
Для франшизы: эталонные нормативы времени из ТТК УК, отчёт «какая точка отстаёт от эталона скорости».