Готовы ли касса и меню к связке: 12 вопросов до интеграции

Касса и онлайн-меню готовы к обсуждению интеграции, когда команда может доказательно ответить на двенадцать вопросов о данных, идентификаторах, владельцах изменений, статусах, сбоях и тестировании. Названия кассовой системы (POS) и подрядчика недостаточно.

Текущий проект не заявляет готовую интеграцию с конкретной кассовой системой. Эта анкета помогает найти блокирующие условия до оценки разработки и отделить подтверждённый контракт «Умного кафе» от требований внешней POS-системы.

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

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

Как работать с анкетой готовности

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

Оцените вопрос одним из трёх статусов:

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

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

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

1. Какая система хранит эталон меню?

Назовите одну главную систему хранения каталога: POS, «Умное кафе» или иной источник. Ответ «обе» требует отдельного правила разрешения конфликтов.

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

Блокирующее условие: сотрудники меняют названия и состав параллельно в двух системах без журнала и владельца.

2. Есть ли стабильный идентификатор каждой позиции?

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

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

Доказательство: выгрузка с ID и SKU, а также проверка уникальности в границах выбранного каталога.

3. Как сопоставляются разделы, модификаторы и варианты?

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

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

Доказательство: по одному полному примеру простого блюда и позиции с вариантами от обеих систем.

4. Где хранится цена и в какой единице?

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

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

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

5. Кто и как меняет доступность позиции?

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

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

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

6. Какой контракт создаёт заказ?

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

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

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

7. Как сопоставляются статусы двух систем?

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

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

Доказательство: сопоставление каждого состояния, допустимое направление и правило неизвестного статуса.

8. Как обрабатываются оплата, отмена и возврат?

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

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

Доказательство: диаграмма событий для успеха, отказа, тайм-аута и возврата с ответственными.

9. Что происходит при повторе или задержке сообщения?

Интеграция должна выдерживать повторную доставку без двойного заказа. Для этого нужен ключ защиты от повторов idempotency key или другой подтверждённый механизм удаления дублей.

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

Доказательство: тест повтора одного и того же события, задержанного ответа и восстановления после разрыва.

10. Как разделяются заведения и кассовые узлы?

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

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

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

11. Кто наблюдает обмен и разбирает исключения?

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

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

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

12. Где и как пройдёт тест до реальной смены?

Нужна отдельная тестовая среда или согласованный набор безопасных тестовых объектов. Проверка на живом гостевом заказе не заменяет приёмку.

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

Доказательство: протокол с входом, ожидаемым выходом, фактическим результатом и владельцем дефекта.

Итоговая таблица готовности

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

Группа	Вопросы	Решение для оценки
Источники и ключи	1–4	главный источник, сопоставление и единицы доказаны
Операционные изменения	5–8	владельцы доступности, заказа, статусов и денег согласованы
Надёжность и границы	9–11	повторы, точки и исключения имеют правила
Тестирование	12	тестовая среда и ожидаемые результаты готовы

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

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

Пакет доказательств перед технической оценкой

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

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

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

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

Что можно проверить сейчас

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

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

Сначала ответы, затем кабель

Готовность кассы и меню определяется не брендом системы, а двенадцатью доказанными ответами. Они показывают, какие данные связывать, кто ими владеет, как пережить повтор и где безопасно тестировать.

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