Как сменить меню, когда сайт, касса и предзаказы живут в разных версиях

Какой переход нужен ресторану

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

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

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

Четыре подтверждения вместо одной отметки

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

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

Учебное переключение в 15:00

Ниже вымышленный ресторан и один местный день; часы иллюстрируют порядок работы, а не срок обновления какого-либо продукта. В версии M17 суп стоит 420. Версия M18 меняет цену на 450 и убирает один дополнительный гарнир. Ресторан решил применять новые условия к новым подтверждениям после переключения, а принятые заказы исполнять по сохранённой спецификации, когда это возможно.

1. В 14:55 команда проверяет M18 на кассе и сайте в разрешённой тестовой среде: новая цена, недоступный гарнир, правильная кухонная строка.
2. В 14:58 подтверждается заказ A на два супа по 420, выдача в 15:30. Сохранённый товарный итог A — 840.
3. В 14:59 посетитель открывает корзину B с одним супом и ещё не завершает оформление.
4. В 15:00 источник публикует M18. Касса уже применяет новую версию; сайт пока работает с M17.
5. В 15:02 сайт подтверждает применение M18. Только после контрольной проверки ответственный разрешает новые заказы этого канала по утверждённому плану.

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

Корзина, принятый заказ и будущая выдача

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

Заказ A не пересчитывают простой подстановкой текущего прайса: два супа остаются связаны с принятыми 840 и версией M17. Если исполнить старый состав невозможно, ответственному нужен отдельный процесс согласования изменения. Переписывание справочника не подтверждает согласие гостя.

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

Порядок выпуска и задержка канала

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

Уведомление об изменении полезно как сигнал перечитать источник. Toast описывает menus webhook с рестораном и временем последней публикации; в качестве страховки от пропуска сообщения рекомендует проверять metadata каждые 30 минут. Время publishedDate передаётся в UTC. Это конкретные рекомендации Toast; они не гарантируют, что ваш канал применит меню за тридцать минут. Toast: событие публикации меню.

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

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

Что возвращает откат

Возврат M17 меняет предложение для последующих продаж в рамках принятого решения. Он не отменяет заказ C, уже подтверждённый по M18 за 450, и не превращает его в покупку за 420. Сохраните список заказов, принятых в период новой версии, и разберите ошибки отдельно от восстановления каталога.

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

Набор приёмочных проверок

• Новая цена появляется в каждой контрольной корзине только по согласованной границе действия.
• Старая вкладка и повтор прежнего заказа не возвращают снятый гарнир без проверки.
• Заказ A сохраняет состав и 840; новый единичный заказ получает 450.
• При задержке одного канала видны его версия, ответственный и ограничение новых продаж.
• Повтор уведомления не запускает новый выпуск и не заменяет актуальное меню старым.
• Откат сохраняет историю заказов обеих версий и не стирает независимые исправления.

В SABSUS и подключённых каналах нужно отдельно подтвердить доступность истории меню, проверки корзины, приостановки приёма и управления предзаказами. Этот материал задаёт критерии рабочего процесса, а не обещает готовую автоматизацию. Источники проверены 9 октября 2026 года; M17, M18, время и суммы — редакционный учебный пример.