Кто поставил стоп в iiko: находим за секунды

Коротко: чтобы найти, кто поставил стоп на блюдо в iiko по всей сети, откройте журнал событий (Event Log) в iikoOffice или iikoWeb и отфильтруйте по действию «Стоп-лист» — отчёт покажет точку, сотрудника, время и причину за один запрос. Но проблема часто не в самом стопе, а в рассинхроне между кассой, стоп-листом и меню в приложении доставки. А это уже вопрос интеграции.

Что понадобится

Чтобы найти, кто поставил стоп, нужны три вещи: административный доступ к iikoOffice или iikoWeb (роль с правами на отчёты), точное название блюда и филиал, если у вас сеть, и окно поиска по времени — обычно хватает суток.

• Доступ к разделу Отчёты → Журнал событий (Event Log)
• Права роли «Менеджер» или выше — рядовой кассир такой отчёт не увидит
• Название номенклатуры точно как в меню (регистр иногда важен для фильтра)
• Список филиалов, если проверяете сеть, а не одну точку

Шаг 1: Открыть журнал событий

Журнал событий в iikoOffice фиксирует все действия персонала с номенклатурой — в том числе постановку и снятие стоп-листа. Зайдите в Администрирование → Журнал событий (в веб-версии — раздел «Отчёты» или «Аудит»).

Выберите тип события «Изменение стоп-листа» или «StopListItem» — формулировка зависит от версии. Нет такого пункта в фильтрах? Значит роль пользователя не даёт доступа к этому логу, права нужно расширить.

Шаг 2: Отфильтровать по блюду и дате

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

Работаете с сетью из нескольких точек на одной базе iikoChain? Отчёт можно вывести сразу по всем ресторанам, без переключения между базами. Вот и та самая экономия часов на звонках поварам и администраторам.

Шаг 3: Проверить причину и снять стоп при необходимости

В карточке события обычно указана причина: «нет ингредиента», «вручную» или системная отметка от кассы. Причина устарела, продукт уже привезли? Снимите стоп прямо из отчёта или через раздел «Стоп-лист» в меню точки.

Отсюда и знакомая жалоба рестораторов: цена активна, категория активна, стопа нет — а блюда в меню приложения всё равно нет. По опыту интеграторов, сопровождающих подключение iiko к сторонним каналам продаж, корень проблемы почти всегда в разрыве между кассовой системой и витриной доставки, а не в самом стоп-листе. На практике такие кейсы разбирают команды техподдержки, которые ежедневно сталкиваются с рассинхроном между iiko и внешними приложениями, — и подтверждают: это системная проблема, а не разовый сбой.

Частые ошибки

• Ищут стоп только в текущей смене — событие может быть поставлено накануне и не снято при пересменке.
• Проверяют не ту базу — в сети с несколькими юрлицами каждая точка может сидеть на отдельной базе iiko, и общего журнала физически нет.
• Путают стоп-лист с деактивацией номенклатуры — это разные механизмы, и стоп-лист не всегда объясняет пропажу блюда из меню.
• Не проверяют синхронизацию с внешним приложением или агрегатором — блюдо активно в iiko, но канал продаж не подтянул изменение из-за сбоя интеграции.

Итог

Журнал событий в iikoOffice — быстрый способ найти, кто и когда поставил стоп. Но он не решает более широкую проблему: разрыв между кассой, стоп-листом и витриной доставки. Если блюдо технически активно, но не отображается у гостя, вопрос уже не к отчёту, а к тому, как настроена синхронизация между iiko и приложением, через которое вы принимаете заказы.

Особенно чувствительно это для доставки через агрегатор: по данным отраслевых оценок 2026 года, средняя комиссия агрегаторов доставки в России составляет 25–35% от суммы заказа. Любой сбой синхронизации в такой модели означает не просто потерянную продажу, а ещё и комиссию, которую вы платите площадке с неработающим меню. Для сравнения: себестоимость собственной доставки ресторана, по экспертным оценкам, держится в районе 25–27% от суммы заказа — заметно ниже верхней границы агрегаторской комиссии. Собственное приложение с прямой интеграцией в iiko снимает часть этих рисков: синхронизация здесь встроена в настройку платформы, а не висит отдельным слоем поверх кассы.

Ключевые выводы

• Журнал событий в iikoOffice показывает, кто поставил стоп-лист, филиал и время — поиск занимает секунды, если есть права доступа к отчёту.
• В сети с несколькими юрлицами единого журнала по всем точкам может не быть — это ограничение архитектуры iiko, а не самого отчёта.
• Пропажа блюда из меню при активной цене и категории часто связана не со стоп-листом, а с разрывом синхронизации между кассой и приложением доставки.
• По данным отраслевых оценок 2026 года, комиссия агрегаторов составляет 25–35% от заказа, тогда как тариф платформы Foodonaut за своё приложение — 4% от выручки, подтверждено владельцем платформы.
• Собственное приложение с прямой интеграцией в iiko снижает риск рассинхрона меню, который на агрегаторе оборачивается потерей продаж и комиссией одновременно.

Источники

• IT для HoReCa 2026: iiko, r_keeper, доставка, программа
• Тренды и рейтинг foodtech-индустрии России 2026 — обзор Surf
• Как запустить доставку еды в 2026 году: полное руководство от анализа рынка до первых заказов — iiko Service — официальный партнёр iiko
• Почему в России подорожала доставка еды: мнение ресторатора - 9 мая 2026 | МГОРСК.ру
• Комиссия 35% против 4%: во сколько обходится отказ от своего приложения навынос — Teletype

Читайте также

• Единое меню сети в приложении без сбоя стоп-листов
• Разработка приложения для сети кафе: цена и окупаемость