🍽️ Для ресторана · кафе · бара

Как контролировать потери на кухне?

Система требует обязательную причину на каждой позиции потери, выбираемую из справочника, настроенного на POS. Свыше порогов по причине (настраиваемых) потеря требует одобрения менеджера смены. При закрытии смены вы видите топ-10 потерь по продукту, а детектор аномалий со скользящим окном (3–30 дней, по умолчанию 7) отмечает жёлтым то, что превышает среднее + 1σ, и красным то, что превышает 2σ.

📋 Обязательная причина · выбирается из справочника POS 🛑 Пороги по причине · одобрение менеджера свыше порога 🏆 Топ-10 потерь · в снимке закрытия смены 🚨 Детектор аномалий · настраиваемые пороги warn / alert

Как это работает, шаг за шагом

Три уровня: позиция (обязательная причина), накладная (порог + одобрение), отчёт (топ-10 + аномалии). Настройки выполняем мы на этапе внедрения на основе обсуждения на consultation-звонке.

1. Обязательная причина на позиции

Когда повар нажимает + Добавить потерю на планшете, он выбирает продукт, вводит количество (отрицательное = списание со склада — положительное зарезервировано для инвентарных корректировок) и выбирает причину из списка, настроенного на POS: cazut_spart, expirat, ars_preparat, anulare_client, autoconsum_personal, degustare_client, furt_frauda и т. д.

Система проверяет, что причина принадлежит настроенному списку. Если список пуст, принимается свободный текст — но мы рекомендуем строгий справочник, чтобы можно было фильтровать позднее.

2. Живой предпросмотр влияния на склад

Перед сохранением система показывает рядом с полем ввода: «Спишет 0.060 кг со склада Моцареллы на POS X». Если списание оставит склад в минусе, появляется заметное предупреждение — повар проверяет, что не ошибся при вводе.

Чекбокс «Применить списание со склада сразу» по умолчанию не отмечен — защищает склад от ошибок в моменты загрузки. Менеджер смены подтверждает (двухшаговый legacy-поток).

3. Порог → одобрение менеджера

Свыше порога, настроенного по типу причины, накладная переходит в статус «ожидает одобрения». Менеджер смены получает уведомление, одобряет одним кликом (при желании с комментарием) или отклоняет с указанием причины → оператор корректирует и отправляет повторно.

Пример по умолчанию: свыше 100 MDL — одобрение; причина furt_frauda — всегда одобрение; комплименты клиентам свыше 50 MDL — одобрение.

4. Топ-10 потерь при закрытии

Когда менеджер нажимает «Закрыть смену», формируется ретроспективный снимок по паре календарная-дата × POS. Он включает подытоги по семи типам движения (производство, продажа, списания, перемещения, приёмка, преобразования, e-commerce) и топ-10 потерь по продукту (продукт, количество событий, количество).

Снимок неизменяем после записи — повторное закрытие той же пары дата+POS создаёт параллельную папку, а не перезаписывает.

Три реальных примера потока потерь

Конкретные ситуации, которые вы видите на кухне каждый день, и как их обрабатывает система.

Моцарелла упала при упаковке

Повар роняет 60 г моцареллы на пол во время приготовления пиццы. На его планшете: + Добавить потерю → Моцарелла → −0.060 кг → причина cazut_spart → заметка «Упало при упаковке» → сохранено.

Ниже порога (60 г моцареллы ≈ 15 MDL < 100 MDL) → без одобрения. Строка появляется в существующей накладной расхода пиццы, склад уменьшается, причина остаётся для аудита.

Пицца сгорела в духовке

Повар забывает пиццу в духовке. Причина ars_preparat → требует одобрения менеджера свыше порога. Пиццу нужно переделать через повторный заказ (ручной поток на кассе), а потеря остаётся в аудите с причиной и указанием того, кто одобрил.

Комплимент VIP-клиентам

Владелец решает подарить бутылку вина и тарелку тапас VIP-клиентам. Официант отмечает позиции «gift» с причиной degustare_client → сумма > 50 MDL порога комплиментов → одобрение менеджера смены → позиции с ценой 0 MDL в фискальном чеке, причина остаётся сохранённой для месячного отчёта.

Питание персонала в конце смены

В 23:30 менеджер открывает «Зарегистрировать расход персонала»: список поваров + потреблённые блюда, причина autoconsum_personal, заметка «Питание смены». Система формирует самостоятельную накладную списания, уменьшает склад ингредиентов (разложенный BOM), причина остаётся на каждой позиции.

Справочник причин — частые примеры

У каждого кода собственный порог одобрения, настраиваемый на уровне POS:

Код причины            Описание                             Одобрение
─────────────────────  ─────────────────────────────────    ────────────
productive             Обычный расход (BOM ингредиент)      нет
anulare_client         Отмена после начала приготовления    нет
ars_preparat           Блюдо сгорело / испорчено            да
cazut_spart            Упало / разбилось                    да (>100 MDL)
expirat                Просрочено                           нет
autoconsum_personal    Питание персонала                    нет
degustare_client       Комплимент клиенту                   да (>50 MDL)
furt_frauda            Хищение / мошенничество              да (всегда)

Пороги и список причин настраиваем мы на этапе внедрения — затем вы можете корректировать их из раздела администрирования в любое время.

Детектор аномалий — как он решает «жёлтый» vs «красный»

Запускается on-demand со вкладки 📊 Reports → Обнаружение аномалий потерь. Менеджер выбирает историческое окно, система делает остальное.

Скользящее окно 3–30 дней

Историческое окно настраивается в диапазоне от 3 до 30 дней (по умолчанию 7). Система рассчитывает среднее + стандартное отклонение потерь по каждому продукту в этом интервале, на текущем POS.

Порог warn (жёлтый) — 1σ по умолчанию

Продукты с потерями выше среднего + 1× stddev отмечаются жёлтым. Порог настраивается — его можно понизить до 0.5σ для небольших точек с малым объёмом, чтобы детекция не пропускала аномалии на малых данных.

Порог alert (красный) — 2σ по умолчанию

Продукты сверх среднего + 2× stddev отмечаются красным. Чёткий сигнал: «У моцареллы в 4 раза больше потерь, чем среднее за неделю — проверьте холодильник, проверьте партию».

Продукты с короткой историей — пропускаются

Система пропускает продукты с историей менее 3 дней. Стандартное отклонение на таких малых данных ненадёжно и привело бы к ложноположительным срабатываниям.

Что детектор не делает (прозрачность)

Детектор работает по продукту, агрегированно по POS. Следующее остаётся ⚙️ доступным по запросу (усилие поддержки за отдельную плату, оценивается в часах после анализа):

  • Дополнительная сегментация по дню / часу / причине (cross-motive или временнóй паттерн)
  • Сравнение между физическими станциями (горячий цех vs холодный цех) — агрегируется на уровне POS

Результаты кликабельны — из списка аномалий вы переходите напрямую к карточке продукта на складе для расследования.

Часто задаваемые вопросы

Что делать, если потеря была применена ошибочно?

Каждая накладная потери отображается как внутренняя накладная в панели накладных, с точным отчётом об изменениях на складе (какой продукт, какое количество, на каком складе). На уровне накладной есть инструмент корректировки склада, которым администратор (или пользователь со специальными разрешениями) пользуется, чтобы отменить эффект. Накладная остаётся видимой в архивах для аудита, с автором + причиной + временной меткой.

Положительное количество = пополнение склада?

Да, но только для редких инвентарных корректировок (пересчёт находит 3 дополнительные единицы). Требует отдельного admin-разрешения, жёлтое предупреждение на форме и дополнительный чекбокс подтверждения перед сохранением. Обычные операторы не могут случайно выполнить такой тип корректировки.

Можно ли добавить контекст к потере (например, стол, где разбился бокал)?

Да. При регистрации потери оператор может добавить свободный комментарий — полезно для потерь, привязанных к конкретному столу («бокал разбился за столом 5») или другому контексту, важному для аудита. Комментарий остаётся в позиции накладной и виден впоследствии.

Кто видит отчёт о закрытии с топ-10 потерь?

Менеджер смены нажимает кнопку «Закрыть смену» на вкладке Reports и получает полный снимок — подытоги по подтипам, топ-10 продуктов с потерями, сводку счетов. Повара и официанты не имеют доступа к финансовым отчётам по умолчанию.

Учёт по счетам SNC автоматический?

Нет. Причина сохраняется в позиции накладной, а соответствие причина → счёт SNC (611 / 711 / 712 / 713 / 714) остаётся ответственностью бухгалтера. Автоматический сплит по счетам SNC в отчёте смены — ⚙️ доступно по запросу — усилие поддержки за отдельную плату, оценивается в часах после анализа.

Существует ли полная история по каждой потере для аудита?

Да. Каждая накладная потери появляется в списке внутренних накладных, с автором, временной меткой до секунды, причиной и комментарием. Из списка вы открываете любую накладную и видите все детали — полезно для ретроспективной проверки или обсуждения с бухгалтером.

Тарифы ниже ориентировочные — точную настройку (пороги причин, окно детектора аномалий, справочник по станциям) выполняем на этапе внедрения на основе consultation-звонка.

Хотите реальный контроль над потерями в вашем ресторане?

Контроль потерь (обязательные причины, пороги по причине, одобрение менеджера, топ-10 и детектор аномалий) входит в тариф Extra HoReCa. Справочник причин + пороги настраиваем мы на этапе внедрения на основе вашей политики (кто одобряет что, при каком пороге). Сравнение тарифов + текущая цена → смотрите страницу тарифов.

Запланируйте разговор

Для кастомных настроек (пороги причин, окно детектора, автоматический SNC-сплит, сравнение между физическими станциями) оцениваем после consultation-звонка — усилие поддержки за отдельную плату, оценивается в часах после анализа. Для остального — стандартный справочник причин, пороги по умолчанию, топ-10 и детектор аномалий с 1σ/2σ — тариф Extra HoReCa готов на этапе внедрения.

Эл. почта
Телефон / WhatsApp
Записаться на звонок

SGAPPS LABS SRL · Кишинёв, Молдова · В непрерывной эксплуатации с 2018 · POS · ERP · Фискальный регистратор MEV · Android fleet