Диагностическая инструкция для администратора и поставщика интеграции. Проверки выполняйте последовательно, меняя один параметр за раз. Названия экранов и доступные функции зависят от версии iiko и внешнего приложения; перед изменениями сверяйте их с официальной документацией. Здесь изложен авторский порядок поиска причины, а не гарантированное исправление любого похожего сообщения.
Как проявляется проблема
- Сайт сообщает об успехе, а сотрудник не находит заказ.
- В уведомлениях виден заказ, но его состояние не меняется.
Что проверить сначала
- Приложение считает HTTP-ответ окончательным подтверждением.
- Не реализовано получение последующего результата.
- События приходят, но не сопоставляются с нужным заказом.
Три точки наблюдения
Полная формулировка из статьи
Уточните, какой сценарий используется: заказ доставки, заказ в зале или иной поддерживаемый тип. У разных сценариев могут отличаться методы и статусы. Не применяйте инструкцию по доставке к столовому заказу только из-за похожего названия. Сверьте схему с официальным справочником своей версии API. Разделите три поля результата: HTTP-статус запроса, state проверки команды и creationStatus создаваемого заказа. Они относятся к разным уровням. В справочнике commands/status использует state со значениями InProgress, Success и Error. Не подставляйте сюда статус кухни или доставки. После успешной команды всё равно сопоставьте конкретный заказ и его текущие данные. Для командного сценария используйте предусмотренный поставщиком запрос состояния с organizationId и correlationId. В текущей схеме commands/status ответ 410 означает, что такой correlationId больше не поддерживается: бесконечно опрашивать его нельзя. Перейдите к доступному поиску самого заказа и сохранённому журналу интеграции, а не объявляйте исходную попытку автоматически несуществующей.

Маршрут диагностики
Маршрут проверок
Полная формулировка из статьи
Шаг 1. Запишите местный номер сайта, UUID заказа, время отправки и correlationId. Эти значения выполняют разные роли, поэтому не заменяйте одно другим. Сохраните первый ответ целиком после удаления персональных данных. Именно он поможет понять, была ли операция отклонена сразу или ожидала дальнейшего выполнения. Шаг 2. Уточните, какой сценарий используется: заказ доставки, заказ в зале или иной поддерживаемый тип. У разных сценариев могут отличаться методы и статусы. Не применяйте инструкцию по доставке к столовому заказу только из-за похожего названия. Сверьте схему с официальным справочником своей версии API. Шаг 4. Для командного сценария используйте предусмотренный поставщиком запрос состояния с organizationId и correlationId. В текущей схеме commands/status ответ 410 означает, что такой correlationId больше не поддерживается: бесконечно опрашивать его нельзя. Перейдите к доступному поиску самого заказа и сохранённому журналу интеграции, а не объявляйте исходную попытку автоматически несуществующей. Шаг 6. Перед повторной отправкой согласуйте судьбу исходной попытки. Проверьте, не был ли заказ уже приготовлен вручную или создан с задержкой. После восстановления обработайте неопределённые обращения по одному. Автоматический массовый повтор очереди без сверки способен создать дубли, даже когда связь уже работает нормально.
Скриншоты и фрагменты документации

Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.

Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.

Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.
Пошаговое решение
Отмечайте выполненные проверки. Отметки действуют до перезагрузки страницы.

Иллюстрация рабочего процесса; сгенерированное фото, не интерфейс iiko. 
Иллюстрация рабочего процесса; сгенерированное фото, не интерфейс iiko.
Развилка результата
Полная формулировка из статьи
Критерий результата: Приложение показывает различие между ожиданием, ошибкой и подтверждённым созданием, а оператор может открыть результат одной операции по её идентификатору. Контрольный заказ найден на нужной кассе ровно один раз и сопоставлен с исходной корзиной. Передача специалисту: Подключайте обслуживающего специалиста, если требуется изменение регистрации терминала, прав организации или логики отправки. Подготовьте один воспроизводимый пример вместо большого архива без пояснений. Укажите исходное и ожидаемое состояние, точку назначения и последовательность действий. Для повторной отправки сначала установите судьбу первоначального обращения.
Как понять, что проблема решена
Приложение показывает различие между ожиданием, ошибкой и подтверждённым созданием, а оператор может открыть результат одной операции по её идентификатору. Контрольный заказ найден на нужной кассе ровно один раз и сопоставлен с исходной корзиной.
Как снизить риск повторения
Не показывайте гостю безусловное подтверждение до установленного результата. Добавьте журнал переходов состояния и очередь обращений, требующих внимания. Согласуйте с персоналом резервный процесс, если подтверждение задерживается.
Если проблема осталась
Подключайте обслуживающего специалиста, если требуется изменение регистрации терминала, прав организации или логики отправки. Подготовьте один воспроизводимый пример вместо большого архива без пояснений. Укажите исходное и ожидаемое состояние, точку назначения и последовательность действий. Для повторной отправки сначала установите судьбу первоначального обращения.
Что передать в поддержку
Скопируйте шаблон и заполните его без паролей, API-ключей, данных карт и сведений о гостях.
Проблема: Заказ принят API, но не виден на кассе: как проверить статус создания Версия и компонент iiko: Ресторан / рабочее место: Время сбоя и часовой пояс: Точный текст сообщения: Что ожидалось / что произошло: Какие проверки выполнены: Результат каждой проверки: Идентификатор операции (если допустимо):
Где помогает Menu 360
Menu 360 интегрируется с iiko и может дополнять заказ автоматическими продажами и допродажами. Успех такой рекомендации оценивайте по принятому составу заказа, а не по одному нажатию «добавить». Проверьте, что предложенный десерт дошёл вместе с основными блюдами, и лишь после подтверждения результата показывайте гостю завершение оформления.
Вопросы и ответы
HTTP 200 означает, что заказ уже на кассе?
Нет. Для команды это может быть успешное принятие запроса с последующей обработкой. Проверьте результат команды, затем создание самого заказа и нужную точку. Не смешивайте HTTP-статус, state команды и статус готовности заказа: это разные сведения.
Почему commands/status перестал отвечать на старый correlationId?
Спецификация предусматривает HTTP 410 для больше не поддерживаемого correlationId. Остановите повторный опрос этой операции и восстановите результат по данным заказа и собственным журналам. Такой ответ сам по себе не доказывает, что заказ никогда не создавался.
Источники и применимость
Официальная документация служит основой проверки возможностей iiko. Последовательность диагностики и контрольные примеры разработаны редакцией Menu 360; это не подтверждение ошибки именно в вашей конфигурации.
Обсуждения похожих ситуаций
Вопросы пользователей подтверждают наличие похожих ситуаций. Советы в обсуждениях могут относиться к старым версиям или другому модулю.
- Обсуждение: Заказ принят API, но не виден на кассе: как проверить статус создания
В обсуждении 2024 года выясняется, что обмен статусами зависит от реализации конкретного модуля.