Диагностическая инструкция для администратора и поставщика интеграции. Проверки выполняйте последовательно, меняя один параметр за раз. Названия экранов и доступные функции зависят от версии iiko и внешнего приложения; перед изменениями сверяйте их с официальной документацией. Здесь изложен авторский порядок поиска причины, а не гарантированное исправление любого похожего сообщения.
Как проявляется проблема
- Возвращается DuplicatedOrderId или сообщение о существующем заказе.
- После повторного нажатия появляются две корзины либо два приготовления.
Что проверить сначала
- Одна операция отправлена повторно без проверки результата.
- Генератор ID использует пересекающиеся значения разных сред.
- После восстановления базы повторно используются старые локальные номера.
Три точки наблюдения
Полная формулировка из статьи
Найдите исходный заказ в iiko поддерживаемым способом и уточните результат у сотрудника. Сравните состав, сумму и источник. Если первая попытка была создана, а ответ потерян, корректным продолжением будет восстановить связь с ней. Создавать новую запись как замену в таком случае опасно для кухни и оплаты. Проверьте журнал сайта на повторные отправки: двойное нажатие, повтор HTTP-клиента, обработчик оплаты, фоновая очередь. Один гостевой заказ не должен независимо отправляться несколькими механизмами. Обозначьте единственного владельца отправки, а остальным компонентам передавайте результат уже выполняемой операции. Если конфликт возникает у разных новых заказов, изучите генерацию ID. Проверьте тестовую и рабочую среду, несколько сайтов и восстановление резервной копии. Локальный порядковый номер без области уникальности может пересечься. Исправление генератора поручите разработчику, сохранив карту уже отправленных обращений.
Маршрут диагностики
Маршрут проверок
Полная формулировка из статьи
Шаг 1. Остановите автоматические повторы только для проблемного обращения, если это предусмотрено вашей системой. Сохраните его UUID, время и первоначальный ответ. Не останавливайте всё приложение без необходимости. Первое действие — восстановить историю одной операции, а не изменить идентификатор в надежде, что ошибка исчезнет. Шаг 2. Найдите исходный заказ в iiko поддерживаемым способом и уточните результат у сотрудника. Сравните состав, сумму и источник. Если первая попытка была создана, а ответ потерян, корректным продолжением будет восстановить связь с ней. Создавать новую запись как замену в таком случае опасно для кухни и оплаты. Шаг 4. Если конфликт возникает у разных новых заказов, изучите генерацию ID. Проверьте тестовую и рабочую среду, несколько сайтов и восстановление резервной копии. Локальный порядковый номер без области уникальности может пересечься. Исправление генератора поручите разработчику, сохранив карту уже отправленных обращений. Шаг 6. Проверьте один новый заказ и контролируемое повторное обращение по нему на тестовом сценарии. Убедитесь, что результат не размножается. Затем отдельно обработайте конфликтные заказы из очереди: для каждого зафиксируйте найденный экземпляр, ручное приготовление, оплату и решение оператора. Массовая смена ID не заменяет сверку.
Скриншоты и фрагменты документации
Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.
Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.
Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.
Пошаговое решение
Отмечайте выполненные проверки. Отметки действуют до перезагрузки страницы.
Иллюстрация рабочего процесса; сгенерированное фото, не интерфейс iiko. 
Иллюстрация рабочего процесса; сгенерированное фото, не интерфейс iiko.
Развилка результата
Полная формулировка из статьи
Критерий результата: Новый заказ получает уникальное сопоставление, повтор того же действия не создаёт второе приготовление, а восстановленная связь указывает на существующий экземпляр. В журнале видна причина повтора и результат проверки, а не только новая успешная попытка. Передача специалисту: Если минимальный контрольный запрос остаётся неуспешным, передайте поставщику интеграции версию приложения, время, адрес метода и обезличенный ответ. Укажите, что уже проверено и какой результат ожидался. Секреты передавайте только предусмотренным защищённым способом; в обычное обращение достаточно идентификатора корреляции и описания сценария.
Как понять, что проблема решена
Новый заказ получает уникальное сопоставление, повтор того же действия не создаёт второе приготовление, а восстановленная связь указывает на существующий экземпляр. В журнале видна причина повтора и результат проверки, а не только новая успешная попытка.
Как снизить риск повторения
Храните внешний UUID вместе с локальным номером и журналом попыток. После восстановления базы или клонирования сайта проверяйте область уникальности. Обработчик оплаты не должен независимо дублировать отправку заказа из корзины.
Если проблема осталась
Если минимальный контрольный запрос остаётся неуспешным, передайте поставщику интеграции версию приложения, время, адрес метода и обезличенный ответ. Укажите, что уже проверено и какой результат ожидался. Секреты передавайте только предусмотренным защищённым способом; в обычное обращение достаточно идентификатора корреляции и описания сценария.
Что передать в поддержку
Скопируйте шаблон и заполните его без паролей, API-ключей, данных карт и сведений о гостях.
Проблема: iiko: заказ с указанным идентификатором уже существует — без повторных заказов Версия и компонент iiko: Ресторан / рабочее место: Время сбоя и часовой пояс: Точный текст сообщения: Что ожидалось / что произошло: Какие проверки выполнены: Результат каждой проверки: Идентификатор операции (если допустимо):
Где помогает Menu 360
При использовании Menu 360 вместе с iiko одинаково важно доставить весь состав и сохранить единственный экземпляр заказа. Автоматические продажи и допродажи могут добавить соус или напиток, но эти позиции должны остаться частью того же подтверждённого заказа. В контрольном тесте проверьте повторное нажатие оформления и отсутствие второго приготовления.
Вопросы и ответы
Можно поменять ID и отправить заказ ещё раз?
Только после установления судьбы исходной попытки. Если заказ уже создан, новый UUID может создать второй экземпляр с тем же составом. Сначала найдите первую операцию и свяжите её с записью сайта; исправление генератора для будущих заказов не заменяет сверку старого.
UUID заказа и номер на чеке — одно и то же?
Нет. Технический UUID, внешний номер сайта и отображаемый номер iiko выполняют разные роли. В журнале храните их раздельно. Совпадение короткого номера не доказывает, что найдена та же запись, а отсутствие знакомого номера не доказывает, что первой попытки нет.
Источники и применимость
Официальная документация служит основой проверки возможностей iiko. Последовательность диагностики и контрольные примеры разработаны редакцией Menu 360; это не подтверждение ошибки именно в вашей конфигурации.
Обсуждения похожих ситуаций
Вопросы пользователей подтверждают наличие похожих ситуаций. Советы в обсуждениях могут относиться к старым версиям или другому модулю.
- Обсуждение: iiko: заказ с указанным идентификатором уже существует — без повторных заказов
В теме приведён реальный ответ DuplicatedOrderId; предлагаемые изменения идентификатора зависят от модуля и не годятся как безусловный рецепт.