Несколько точек: как не смешивать меню, заказы и доступы

Несколько заведений нельзя вести как одну большую точку. Меню, столы, заказы и сотрудники должны принадлежать конкретному заведению, а сеть должна управлять общими правилами: кто отвечает за объект, кто может его менять и как сравнивать результат.

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

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

• Каждый объект должен однозначно принадлежать одному заведению.
• Центр сети задаёт определения и правила доступа; филиал отвечает за актуальность своей смены.
• Общий отчёт строится только из сопоставимых данных, но не даёт права редактировать всё всем.
• Проверяйте изоляцию негативными сценариями: сотрудник одной точки не должен изменить объект другой.
• Публичное демо показывает гостевой путь одной демо-точки, а не управление сетью.

Что именно нельзя смешивать

Смешивание начинается, когда объект теряет однозначную принадлежность. Одинаковое название блюда или стола не делает записи общими: «Капучино» в двух филиалах может иметь разную цену, доступность и состав, а «Стол 5» должен вести к своему залу.

Для сети полезно держать четыре границы:

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

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

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

Модель владения «сеть / точка»

Удобнее всего разделить четыре вида участия: задаёт правило, выполняет, проверяет и получает информацию. Такая матрица ответственности не требует специального программного модуля; это управленческий договор.

Объект	Центр сети	Управляющий точки	Смена	Проверка
Структура категорий	задаёт обязательное ядро	добавляет допустимую локальную часть	сообщает о проблемах	сравнение структуры по графику
Цена и состав позиции	утверждает политику изменений	вносит подтверждённую правку	не меняет без полномочий	журнал изменения и выборочная сверка
Доступность блюда	задаёт срок реакции	назначает ответственного	меняет по факту остатка, если роль разрешает	контроль устаревшего стоп-листа
Заказ	задаёт значения статусов	следит за соблюдением процесса	переводит по фактическому событию	незавершённые и ошибочные переходы
Стол и QR-вход	задаёт формат маркировки	создаёт и принимает комплект	сообщает о повреждении	контрольный заказ с каждого входа
Сотрудник и роль	задаёт модель полномочий	запрашивает и отзывает доступ	использует личный доступ	регулярная сверка активных пользователей

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

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

Как разделить меню без копирования хаоса

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

Разделите элементы на три слоя:

1. Сетевое ядро. Позиции, название и базовые требования к которым задаёт центр.
2. Локальная конфигурация. Цена, доступность, расписание или ассортимент, если политика сети это допускает.
3. Точка публикации. Конкретное заведение и меню, в котором гость видит позицию.

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

Контрольный вопрос после массовой правки звучит так: «Какие точки должны были измениться и где подтверждение?» Ответ «изменили шаблон» недостаточен. Выберите две позиции и откройте гостевое меню каждой затронутой точки.

Как сохранить заказ внутри правильной точки

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

Техническая проверка включает три условия:

• запрос списка заказов ограничен выбранным заведением;
• изменение статуса не применяется к заказу чужой точки;
• заказ нельзя собрать из стола одной точки и позиций другой.

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

Организационная часть не менее важна. Все филиалы должны одинаково понимать статусы. Например, «готов» означает, что заказ физически готов к выдаче, а не что кухня только увидела карточку. Иначе общая недельная сводка сравнит разные события под одним названием.

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

Как выдавать и отзывать доступы

Доступ следует за рабочей ролью и заведением. Аккаунт «на всякий случай» опасен не потому, что сотрудник обязательно ошибётся, а потому, что никто не заметит устаревшее полномочие.

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

Введите короткий жизненный цикл доступа:

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

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

Негативная приёмка изоляции

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

Составьте отдельную таблицу тестов:

Попытка	Ожидаемый результат
Пользователь точки А открывает список заказов	видит только заказы точки А
Пользователь точки А меняет заказ точки Б по прямому идентификатору	действие отклонено
Администратор точки А редактирует позицию точки Б	действие отклонено
Заказ точки А содержит стол точки Б	создание отклонено
Владелец отзывает доступ бывшего сотрудника	следующая авторизация недоступна
Переключение выбранной точки системной ролью	интерфейс и данные явно показывают новый контекст

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

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

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

Что централизовать, не создавая общей свалки

Централизуйте определения и решения, а не каждое действие. Сети полезно иметь единый словарь статусов, шаблон брифа, правила артикулов SKU, формат QR-носителей и календарь проверки доступов.

Локальными остаются факты смены: доступность позиции, физическое состояние QR-таблички, назначение сотрудника на очередь, причина задержки заказа. Центр получает эти данные в оговорённом виде, но не подменяет управляющего точки.

Для каждого общего показателя запишите паспорт:

• название и единицу;
• событие начала и конца;
• источник;
• владелец качества;
• правило нулевого знаменателя;
• что нельзя сравнивать.

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

Где проходит граница продукта

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

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

Сеть контролирует правила, точки владеют фактами

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

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