Заказ не попал с сайта в iiko: что проверить и кто отвечает за сбой

Гость оформил заказ, увидел сообщение «Заказ принят», а на кассе и кухне — тишина. Иногда деньги уже списаны. Для ресторана это выглядит как одна проблема, но на самом деле заказ проходит через несколько самостоятельных систем. Каждая из них может успешно выполнить свою часть, пока следующая уже дала сбой.

Поэтому отметка об успешном оформлении на сайте ещё не доказывает, что заказ создан в iiko и появился на терминале. Сайт мог сохранить заявку в собственной базе, платёжный сервис — подтвердить оплату, а передача в iiko при этом могла завершиться ошибкой или остаться в обработке. Сайт также может получить подтверждение отправки раньше, чем заказ появится на кассе. Поэтому важно различать два события: сайт передал заказ и ресторан его получил.

Точная последовательность оплаты и отправки в iiko зависит от конкретного сайта и интеграции. В одних решениях заказ передают после оплаты, в других этапы организованы иначе. Поэтому по одному факту списания денег нельзя определить, где находится заказ.

Путь заказа: где именно он может остановиться

Упрощённо цепочка выглядит так:

Гость → сайт → оплата → интеграция/API → iikoCloud → iikoFront на главной кассе → касса и кухня

На практике это семь отдельных участков.

1. Гость и сайт. Сайт принимает состав корзины, контакты, адрес, способ оплаты и желаемое время доставки. На этом этапе он может показать собственное сообщение об успешном оформлении.

2. Оплата. Банк или платёжный сервис подтверждает либо отклоняет платёж. Это отдельная операция: успешная оплата не является подтверждением создания заказа в iiko.

3. Сервер сайта. Он сохраняет заказ и готовит данные для передачи: товары, модификаторы, адрес, время, тип оплаты, организацию и источник заказа.

4. Интеграция и iikoCloud API. Интеграция отправляет заказ в iiko и фиксирует полученный результат, чтобы при сбое можно было восстановить ход событий.

5. iikoCloud. Система проверяет данные заказа и направляет его в нужную терминальную группу. Подтверждение отправки и появление заказа на кассе — разные этапы.

6. iikoFront и главная касса. Заказ передаётся на главный кассовый терминал группы. Для этого терминал, связь � транспортный компонент iiko должны работать.

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

Такое разделение помогает не искать «виноватого вообще», а установить последнюю систему, которая точно видела заказ.

Основные точки сбоя и их признаки

Сайт не создал или не сохранил заказ

Признаки: у ресторана нет номера заказа сайта; заявка отсутствует в административной панели; уведомление гостю могло не прийти; в журнале сайта нет записи о попытке передачи в iiko.

Кто проверяет: разработчик сайта или поддержка платформы. Если заказ не появился даже во внутренней базе сайта, до iiko он, скорее всего, не дошёл вовсе.

Оплата прошла, но дальнейший сценарий не запустился

Признаки: есть подтверждение платежа и идентификатор операции, но в сайте нет подтверждённого заказа либо нет попытки отправки в iiko.

Здесь нужно сопоставить журналы сайта и платёжного сервиса. Эквайринг отвечает за результат платежа, но не за передачу заказа в iiko. Связать успешную оплату с созданием и отправкой заказа должен сайт или интеграционный модуль.

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

iiko отклонила данные заказа

Признаки: в журнале интеграции есть ответ с ошибкой; заказ не появляется в iiko; проблема может повторяться только с определённым блюдом, модификатором, адресом, временем или способом оплаты.

К таким ошибкам, в частности, приводят:

• товар или модификатор на сайте не совпадает с внешним меню iiko;

• количество модификаторов нарушает ограничения, заданные в iiko;

• тип оплаты удалён или недоступен для нужной терминальной группы;

• телефон передан в неподходящем формате;

• время доставки передано в прошлом или не соответствует действующим настройкам;

• адрес не проходит правила зоны доставки;

• неверно указан источник заказа или не выбрана подходящая терминальная группа.

Кто проверяет: администратор iiko вместе с разработчиком интег�ации. Ресторан отвечает за актуальные настройки меню, оплат, зон и терминальных групп в iiko. Разработчик интеграции — за то, чтобы сайт получил эти данные, правильно их использовал и корректно обработал отказ.

Сайт не смог передать заказ в iikoCloud

Признаки: заказ сохранился на сайте, но в iiko его нет; одновременно могут перестать проходить все заказы, а не только заказы с определённым блюдом или адресом.

Так бывает, когда сайт теряет доступ к iikoCloud: например, из-за настроек подключения, прав доступа или лицензии. Самостоятельно определять техническую причину управляющему не нужно. Его задача — зафиксировать время первого сбоя, номера непринятых заказов и уточнить, проходят ли заказы во всех точках или проблема возникла только в одной.

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

iikoCloud получила заказ, но касса его не приняла

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

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

Кто проверяет: разработчик интеграции подтверждает, что заказ действительно был передан в iikoCloud. После этого специалист по iiko или обслуживающий партнёр проверяет маршрут заказа до нужной кассы и состояние оборудования точки.

Касса или локальная инфраструктура недоступна

Признаки: терминал выключен, спит или не виден в iikoWeb; iikoFront потерял связь с сервером; проблема возникает рывками вместе с перебоями интернета; заказы не доходят до конкретной точки.

Кто проверяет: первую проверку выполняет администратор ресторана — включено ли оборудование, есть ли интернет, работает ли iikoFront. Настройку главной кассы, терминальной группы, локальной сети и транспортного компонента проверяет специалист по iiko или системный администратор.

Заказ есть на кассе, но не дошёл до кухни

Если заказ уже виден в iikoFront, участок «сайт — интеграция — iikoCloud» свою задачу выполнил. Дальше проверяют ресторанный процесс, настройки печати или кухонного оборудования. Это уже не сбой передачи заказа с сайта в iiko.

Кто проверяет: управляющий точки или руководитель доставки сначала проверяет действия сотрудников. Настройки печати и работу кухонного оборудования проверяет специалист по iiko или подрядчик, обслуживающий оборудование.

На сайте неверный статус, хотя заказ есть в iiko

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

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

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

Что проверить до обращения к специалисту

Задача управляющего — не искать техническую причину, а собрать основные факты:

1. Запишите данные заказа: номер, время, точку, сумму, способ оплаты и телефон гостя.

2. Найдите заказ на сайте: есть ли он в панели управления и какой статус там указан.

3. Уточните статус оплаты: платёж подтверждён или сумма только заблокирована.

4. Проверьте кассу нужной точки: работает ли терминал, есть ли интернет и появился ли заказ в iikoFront.

5. Определите масштаб: не прошёл один заказ, заказы одной точки или заказы перестали поступать во все рестораны.

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

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

Симптом — вероятная причина — кто проверяет

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

Что должно быть предусмотрено заранее

Чтобы о потерянном заказе ресторан узнавал не от гостя, на сайте и в интеграции должны быть предусмотрены:

• фиксация доступных этапов: заказ создан на сайте, оплачен, отправлен в iiko и получен результат отправки;

• уведомление ответственному, если отправка завершилась ошибкой или подтверждение не пришло за установленное время;

• защита от создания дубля при повторной отправке заказа;

• согласованный ручной порядок действий на случай недоступности кассы или iiko.

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