Два одинаковых напитка, разный состав: как проверять модификаторы

Сначала определите единицу выбора

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

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

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

Три независимых ограничения

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

Разделение действительно встречается в моделях поставщиков: Square документирует отдельные параметры минимального и максимального выбора и разрешения нескольких количеств одного модификатора. Эти поля отмечены Beta, а ограничения могут переопределяться для конкретного товара. Это повод проверять итоговое правило на товаре, а не только родительскую группу. Справочник Square: CatalogModifierList.

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

Учебный заказ из трёх напитков

Все суммы условные, в одной денежной единице; налоги и скидки из примера исключены. Базовый напиток стоит 250. Овсяная основа добавляет 40 на стакан, одна дополнительная порция эспрессо — 30, сироп — 20. Гость заказывает два напитка на овсяной основе с двумя дополнительными порциями эспрессо каждый и третий обычный напиток с сиропом.

Это две конфигурации, хотя базовое название одно. Лимит «не больше двух дополнительных порций» проверяется для каждого напитка и не нарушается четырьмя порциями на всю строку A. Если гость убирает дополнительный эспрессо из одного стакана, исходную строку нужно разделить: 350 + 290 + 270 = 910. Итоговое количество дополнительных порций становится два.

Приёмка должна обнаружить обе ошибки: 970 при неверном количестве добавок на кухне и правильный состав при неправильном счёте. Отдельно проверьте маркировку стаканов: агрегированное «эспрессо × 4» не объясняет распределение между тремя напитками.

Что меняется при передаче в API

Не переносите значение из поля интерфейса в одноимённое поле интеграции без проверки его смысла. Например, Toast Orders API требует равенства quantity у позиции и каждого её модификатора. Разные наборы изменений у одинаковых блюд передаются отдельными Selection. Повтор одной добавки описывается повторными записями модификатора, каждая с количеством родительской позиции. Это конкретный контракт Toast, а не инструкция для любой кассы. Toast: модификаторы и количества.

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

Поддержка повторов тоже имеет границы. Toast отдельно описывает настройку повторного выбора и ограничения при вложенных модификаторах. Проверка обычной добавки не подтверждает, что повторяемый составной гарнир будет работать так же. Toast: multiple modifier selection.

Значение по умолчанию и замена

Явно различайте «гость оставил стандартный состав», «гость удалил компонент» и «поле не было передано». В Toast значения по умолчанию добавляются на POS, но при создании заказа через API их требуется включать явно; пропуск означает удаление соответствующего модификатора. Правило default modifiers в документации Toast. Для другого поставщика установите собственное подтверждённое поведение.

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

Приёмка на кассе, сайте и кухне

1. Оставьте обязательную группу пустой, затем выберите два взаимоисключающих варианта. В обоих случаях должно появиться понятное объяснение до принятия заказа.
2. Выберите одну добавку дважды и третью сверх лимита. Проверьте повторы, сумму и запрещённый третий выбор отдельно.
3. Воспроизведите заказ на 970 и изменение до 910. Сверьте каждый стакан, а не только общий итог.
4. Откройте прежнюю корзину после отключения добавки. Неразрешённый состав должен попасть на повторную проверку, без скрытой замены.
5. Передайте тот же состав через каждый рабочий канал. Кухонный экран, печать и маркировка должны сохранять распределение добавок.

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

Когда упрощать меню

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

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