Рабочий экран владельца: заказы, меню, столы и сотрудники

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

Ниже — пошаговый разбор текущей административной панели «Умного кафе» по коду и проектной документации. Публичное демо не открывает эти экраны, поэтому маршрут владельца проверяется отдельно при подключении.

Если читать 30 секунд

• Заказы: увидеть активную очередь, детали и перевести заказ только на допустимый следующий статус.
• Меню: изменить позицию или доступность и проверить результат в гостевом каталоге.
• Столы: создать метку, открыть нужную точку входа и принять физический носитель.
• Сотрудники: выдать персональный доступ, сверить роль и вовремя отозвать его.
• Аналитику, интеграцию с кассовой системой (POS) и управление сетью эти четыре задачи сами по себе не подтверждают.

Как устроен маршрут владельца

Административная панель разделяет операционные области по маршрутам. В приложении есть страницы рабочей очереди сотрудников, заказов, меню, столов, заведений и пользователей. Для ежедневного обхода владельцу не нужно открывать всё подряд.

Используйте один цикл:

1. Найдите исключение в заказах.
2. Проверьте, не связано ли оно с меню.
3. Убедитесь, что вход со стола ведёт в правильный контекст.
4. Проверьте, у кого есть право исправлять соответствующий участок.

Так четыре экрана превращаются в причинный маршрут. Если открыть их как отдельные списки, владелец увидит записи, но не обязательно найдёт источник проблемы.

Важно сохранять контекст заведения. Для обычных пользователей операции должны относиться к их точке; широкая системная роль выбирает заведение явно. При работе с несколькими филиалами ориентируйтесь на правила изоляции меню, заказов и доступов, а не на ожидание общей сетевой сводки.

Задача 1. Проверить заказ и следующее действие

Первый экран должен отвечать не «сколько всего было», а «что требует действия сейчас». В рабочем процессе сотрудников активные заказы группируются по статусам, отдельно загружаются завершённые заказы текущего дня, а список периодически обновляется.

Карточка заказа может показывать номер, стол или доставку, позиции, время и текущее состояние. Следующее действие вычисляется из статуса. Например, новый заказ принимают, подтверждённый передают в приготовление, готовящийся отмечают готовым. Для заказа с обязательной оплатой переход из ожидания оплаты блокируется, пока платёж не подтверждён.

Маршрут проверки владельца:

1. Выберите активный заказ, который дольше других остаётся на одном этапе.
2. Откройте детали: позиции, количества, комментарий и место выдачи.
3. Спросите ответственного, какое физическое событие ещё не произошло.
4. Меняйте статус только после этого события, а не ради «чистого экрана».
5. Если карточка неполная, зафиксируйте, на каком этапе потерялась информация.

Очередь не доказывает причину задержки. Она показывает состояние, а разбор требует разговора со сменой. Для ежедневной карты показателей владельца используйте отдельные семь утренних метрик; текущий пошаговый разбор не обещает, что административная панель сама рассчитывает их.

Задача 2. Исправить меню и подтвердить результат

Правка меню заканчивается не нажатием «сохранить», а проверкой гостевого представления. В административной панели можно работать с меню, разделами и позициями: названием, внутренним артикулом SKU, кратким и полным описанием, ценой, весом, изображением, переводами, порядком и доступностью.

Для срочного исключения используйте изменение доступности позиции. Оно подходит для закончившегося блюда, сезонной паузы или временного снятия. Но интерфейс не знает физический остаток сам по себе: сотрудник должен получить факт и выполнить действие.

Короткий маршрут владельца:

1. Найдите позицию по разделу, названию или артикулу SKU.
2. Проверьте, относится ли правка к выбранному меню и заведению.
3. Измените только нужное поле.
4. Обновите гостевой каталог и убедитесь, что результат виден там, где ожидался.
5. Назначьте время обратной проверки, если изменение временное.

Для цены важно помнить проектный контракт: серверная часть хранит суммы в копейках, а интерфейс может показывать рубли. Не переносите число между программным интерфейсом API и формой без понимания единицы.

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

Задача 3. Принять стол и его точки входа

Стол в системе — не только подпись «Стол 7». Он связан с точкой входа гостя, поэтому владелец принимает одновременно запись и физический носитель.

На странице столов пользователь с достаточной ролью может создать или изменить метку, удалить стол, открыть QR-коды для Telegram, браузера или MAX, сформировать табличку и регенерировать ключ. Регенерация делает старые QR-коды недействительными, поэтому её нельзя считать обычным косметическим действием.

Маршрут приёмки:

1. Сверьте метку в админке с планом зала и печатным носителем.
2. Откройте каждый используемый канал именно с этой карточки стола.
3. Убедитесь, что гость попадает в правильное заведение и контекст стола.
4. Проведите тестовый заказ по согласованному сценарию.
5. После регенерации ключа замените все старые экземпляры и повторите проверку.

Не выводите все доступные каналы на табличку только потому, что они существуют. Филиал выбирает те входы, которые обслуживает и объясняет смена. Физический комплект подробнее разобран в руководстве по настольным QR-носителям.

Задача 4. Сверить сотрудника и его полномочия

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

В форме сотрудника есть привязка к заведению, роль, язык, активность и идентификаторы поддерживаемых способов входа. Роль описывает разрешённые действия: сотрудник работает с заказами, расширенные роли получают административные возможности, владелец управляет пользователями своей точки. Фактические проверки остаются в серверной части, поэтому интерфейсная подпись не заменяет авторизацию.

Маршрут сверки:

1. Сопоставьте активных пользователей с текущим расписанием и обязанностями.
2. Уберите общий доступ, если им пользуются несколько людей.
3. Проверьте привязку сотрудника к нужному заведению.
4. Выдайте минимальную роль для реальной задачи.
5. Отзовите доступ при переводе, увольнении или окончании временной обязанности.

Не создавайте роль «на будущее». Чем шире полномочия, тем сложнее понять, кто изменил меню или стол. При этом статья не обещает полноценный аудит действий пользователя, если такой журнал не подтверждён кодом и документацией.

Контрольная карточка четырёх задач

Заполните одну строку на каждом обходе. Карточка нужна не для отчётности, а чтобы довести изменение до подтверждения.

Задача	Проверяемое действие	Готовое состояние	Ограничение
Заказ	открыть детали и сверить следующее физическое событие	статус соответствует реальной работе	причина задержки выясняется со сменой
Меню	изменить одно поле или доступность	гостевой каталог показывает ожидаемый результат	остатки не обновляются сами без источника
Стол	сверить метку и используемые входы	носитель ведёт в правильный контекст	регенерация требует перепечатки
Сотрудник	сверить точку, роль и активность	доступ принадлежит действующему ответственному	роль не равна полному аудиту действий

Если одна строка не закрывается, не переходите сразу к другой странице. Назначьте владельца исключения и время повторной проверки.

Что проверять за пределами каждой страницы

Админ-действие показывает запись системы, но готовое состояние часто находится в физической смене. Поэтому к четырём задачам добавьте внешнее подтверждение, не приписывая его панели.

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

Такой двойной контроль помогает отличить ошибку данных от ошибки исполнения. Если в панели всё верно, а гость получает неправильное блюдо, ищите передачу на кухню. Если кухня готова, но позиция скрыта, проверяйте административное состояние. Не добавляйте для этого пятый «универсальный экран»: сначала свяжите системную запись с одним наблюдаемым фактом.

Владелец также должен определить, что не проверяется этим обходом. Кассовая сверка, фискальные операции, остатки склада, платёжные расчёты и финансовая отчётность требуют своих источников. Наличие суммы заказа на странице не превращает её в подтверждённую выручку.

Если исключение затрагивает несколько страниц, начните с события гостя и двигайтесь назад. Неверный стол проверяют от носителя к записи стола и заказу. Недоступное блюдо — от гостевого каталога к позиции и владельцу изменения. Такой маршрут уменьшает риск исправить удобную запись, не устранив причину.

Чего не следует ждать от этого экрана

Четыре операционные задачи не складываются автоматически в аналитическую сводную панель. Текущая документация описывает показатели текущего дня и страницы управления, но это не подтверждает пользовательские утренние или недельные отчёты с произвольными формулами.

Также пошаговый разбор не обещает:

• готовую интеграцию с кассовой системой;
• единую сводную панель нескольких точек;
• автоматический расчёт экономики пилота;
• полную замену кассы, кухни или учётной системы;
• отсутствие ручного владельца стоп-листа и доступа.

Эти границы полезны. Владелец оценивает продукт по реальным действиям, а не по воображаемому экрану со всеми показателями бизнеса.

Как проверить гостевую сторону и запросить доступ к административной панели

В публичном демо доступны выбор демо-заведения, меню, корзина, оформление заказа и отслеживание статуса гостем. Оно не открывает рабочую очередь сотрудников, страницы меню, столов и пользователей, не показывает роли и не подтверждает управленческую аналитику.

После самостоятельной проверки гостевого маршрута запросите проверку четырёх административных задач через форму подключения. Возьмите контрольную карточку и попросите пройти конкретный сценарий: заказ, правка меню, стол и сотрудник.

Рабочий экран заканчивается подтверждённым состоянием

Ценность админ-панели не в количестве разделов. Владелец должен провести четыре действия и увидеть их результат: заказ соответствует смене, меню — гостевому каталогу, стол — физическому входу, сотрудник — своей роли и точке.

Такой обход даёт операционный контроль без обещания несуществующей панели бизнес-аналитики. Аналитику и сетевое управление оценивайте как отдельные задачи с отдельными источниками данных.