Диагностическая инструкция для администратора и поставщика интеграции. Проверки выполняйте последовательно, меняя один параметр за раз. Названия экранов и доступные функции зависят от версии iiko и внешнего приложения; перед изменениями сверяйте их с официальной документацией. Здесь изложен авторский порядок поиска причины, а не гарантированное исправление любого похожего сообщения.
Как проявляется проблема
- Запрос зависает или заканчивается ожиданием.
- Утром сайт принимает заказ, но касса получает его с задержкой.
Что проверить сначала
- Сетевое ожидание на сервере сайта.
- Недоступен нужный кассовый терминал или транспорт.
- Приложение слишком рано считает незавершённую операцию ошибкой.
Три точки наблюдения
Полная формулировка из статьи
Найдите идентификаторы первой операции и проверьте её состояние до повторной отправки. Если ответа совсем нет, сохраните время и собственный ID обращения. Затем уточните у кассира, не появился ли заказ. Нельзя считать отсутствие ответа доказательством отсутствия результата, особенно после сетевого разрыва. Проверьте, доступна ли нужная точка в момент инцидента. Сравните обычную работу сотрудников и облачную передачу. Зафиксируйте запуск кассы утром, восстановление интернета и время первого успешного обращения. Такая временная шкала помогает отличить регулярно недоступный терминал от случайного ожидания отдельного HTTP-запроса. Уточните у поставщика поддерживаемую настройку ожидания передачи и её смысл для вашей версии. Не подставляйте значение из старого форумного примера в рабочую конфигурацию без проверки. Слишком длинное ожидание может лишь отложить сообщение об ошибке, пока гость уже ждёт подтверждения или звонит в ресторан.
Маршрут диагностики
Маршрут проверок
Полная формулировка из статьи
Шаг 1. Сначала определите, какой именно таймаут сработал: браузера, сервера приложения, HTTP-клиента или передачи на кассу. Запишите измеренную продолжительность и текст ответа. Эти ожидания нельзя исправлять одной настройкой: увеличение времени браузера не восстанавливает связь терминала с облаком. Шаг 2. Найдите идентификаторы первой операции и проверьте её состояние до повторной отправки. Если ответа совсем нет, сохраните время и собственный ID обращения. Затем уточните у кассира, не появился ли заказ. Нельзя считать отсутствие ответа доказательством отсутствия результата, особенно после сетевого разрыва. Шаг 4. Уточните у поставщика поддерживаемую настройку ожидания передачи и её смысл для вашей версии. Не подставляйте значение из старого форумного примера в рабочую конфигурацию без проверки. Слишком длинное ожидание может лишь отложить сообщение об ошибке, пока гость уже ждёт подтверждения или звонит в ресторан. Шаг 6. После восстановления связи сверяйте зависшие операции по одной. Если заказ уже выполнен вручную, зафиксируйте это до разрешения повторов. Проверьте один сценарий временной потери связи на согласованном тесте: приложение должно восстановить результат, а не размножить обращения. Отдельно проверьте уведомления гостю и сотрудникам.
Скриншоты и фрагменты документации
Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.
Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.
Редакционная визуализация фрагмента OpenAPI, не скриншот интерфейса iikoCloud API — официальный справочник OpenAPI. Нажмите на изображение, чтобы открыть отдельно. Сверяйте источник с версией и настройками своей системы.
Пошаговое решение
Отмечайте выполненные проверки. Отметки действуют до перезагрузки страницы.
Иллюстрация рабочего процесса; сгенерированное фото, не интерфейс iiko. 
Иллюстрация рабочего процесса; сгенерированное фото, не интерфейс iiko.
Развилка результата
Полная формулировка из статьи
Критерий результата: При краткой потере связи система сохраняет неопределённое обращение, затем показывает установленный результат. Контрольный заказ появляется на кассе один раз. Очередь после восстановления сверена, а гостю не отправлены противоречащие друг другу подтверждения. Передача специалисту: Подключайте обслуживающего специалиста, если требуется изменение регистрации терминала, прав организации или логики отправки. Подготовьте один воспроизводимый пример вместо большого архива без пояснений. Укажите исходное и ожидаемое состояние, точку назначения и последовательность действий. Для повторной отправки сначала установите судьбу первоначального обращения.
Как понять, что проблема решена
При краткой потере связи система сохраняет неопределённое обращение, затем показывает установленный результат. Контрольный заказ появляется на кассе один раз. Очередь после восстановления сверена, а гостю не отправлены противоречащие друг другу подтверждения.
Как снизить риск повторения
Контролируйте доступность кассы до начала приёма онлайн-заказов. Ведите отдельные метрики сетевого ожидания и завершения создания. Согласуйте предельное время ожидания с операторами и резервный способ связи с гостем.
Если проблема осталась
Подключайте обслуживающего специалиста, если требуется изменение регистрации терминала, прав организации или логики отправки. Подготовьте один воспроизводимый пример вместо большого архива без пояснений. Укажите исходное и ожидаемое состояние, точку назначения и последовательность действий. Для повторной отправки сначала установите судьбу первоначального обращения.
Что передать в поддержку
Скопируйте шаблон и заполните его без паролей, API-ключей, данных карт и сведений о гостях.
Проблема: Таймаут передачи заказа в iikoFront: как не потерять заказ и не создать дубль Версия и компонент iiko: Ресторан / рабочее место: Время сбоя и часовой пояс: Точный текст сообщения: Что ожидалось / что произошло: Какие проверки выполнены: Результат каждой проверки: Идентификатор операции (если допустимо):
Где помогает Menu 360
Menu 360 интегрируется с iiko и предлагает сценарии автоматических продаж и допродаж в цифровом меню. После сетевого сбоя проверяйте сохранность полного состава: основного блюда и принятого гостем дополнения. Рекомендации полезно настраивать после устойчивой передачи заказов, чтобы персонал видел их один раз и мог вовремя выполнить.
Вопросы и ответы
Увеличить HTTP Timeout — достаточно для передачи на кассу?
Нет. HTTP-ожидание ответа и время передачи заказа в iikoFront — разные параметры. Если касса недоступна или выбрана другая группа, длинное ожидание только задержит ответ. Сначала проверьте этап сбоя и исходный результат, затем согласуйте настройку ожидания с поставщиком.
Есть ли подтверждённое универсальное исправление из GitHub #567?
Нет. Issue содержит пример таймаута и уточняющий вопрос участника проекта о применяемом API. Это первичное свидетельство проблемы, а не готовый патч. В статье поэтому предлагается проверять связь, адресат и результат операции, а не копировать несуществующее решение.
Источники и применимость
Официальная документация служит основой проверки возможностей iiko. Последовательность диагностики и контрольные примеры разработаны редакцией Menu 360; это не подтверждение ошибки именно в вашей конфигурации.
Обсуждения похожих ситуаций
Вопросы пользователей подтверждают наличие похожих ситуаций. Советы в обсуждениях могут относиться к старым версиям или другому модулю.
- Обсуждение: Таймаут передачи заказа в iikoFront: как не потерять заказ и не создать дубль
Пользователь описывает утренние заказы, которые API принимал, но касса не получала; обсуждались последующий статус и ожидание передачи.
- Обсуждение: Таймаут передачи заказа в iikoFront: как не потерять заказ и не создать дубль
24.07.2025 описан ответ 200 с ожиданием, затем Error. 06.08.2025 contributor уточнил, каким API пользуется автор; официального решения в issue нет.