Программы iiko и r_keeper: мобильное приложение поверх вашей учётной системы

Зачем приложение поверх iiko или r_keeper

iiko и r_keeper — системы автоматизации общепита: в них ведут номенклатуру, цены, склад, кассовые смены и отчётность. Они закрывают учёт внутри заведения, но не дают гостю собственного канала заказа — приложения с меню, историей покупок и бонусным счётом. Мобильное приложение DELICIO работает поверх учётной системы, а не вместо неё: касса, склад и отчётность остаются там, где они уже настроены, а приложение становится ещё одним каналом приёма заказов. Для персонала это выглядит привычно: заказ из приложения приходит в ту же систему, что и заказ официанта или оператора, и проходит по тем же правилам обслуживания. Для владельца это значит, что не нужно менять учётный контур, переучивать бухгалтерию и заново заводить номенклатуру. Само приложение при этом остаётся отдельным продуктом со своей витриной и логикой заказа — подробнее о нём на странице мобильное приложение для ресторана.

Что синхронизируется между приложением и учётной системой

Смысл интеграции — единый источник данных. Из учётной системы в приложение обычно передаются номенклатура и структура меню, категории и модификаторы, цены и прайс-листы по точкам, стоп-листы и признак доступности блюда. Обратно в систему уходят заказы, оформленные гостем: состав, выбранные модификаторы, тип обслуживания (в зале, самовывоз, доставка), комментарий и способ оплаты. После того как заказ закрыт на кассе, в приложении появляется чек и начисленные бонусы, а данные о продаже остаются в отчётности заведения. Конкретный набор полей зависит от версии системы и купленных модулей, поэтому состав обмена фиксируется на старте: что именно тянем, с какой периодичностью и какие данные считаем обязательными. Обмен строится через API и штатные механизмы интеграции самой системы. Со стороны заведения для этого заводят отдельного технического пользователя с ограниченными правами, а не выдают общий администраторский доступ: приложению не нужны права на изменение справочников, склада или закрытие смен, ему достаточно читать меню и создавать заказы. Такое разделение полезно и с точки зрения безопасности, и при разборе спорных ситуаций — всегда видно, какие операции пришли из приложения.

Что нужно от заведения и какие сложности встречаются

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

Чем отличается iiko от r_keeper и что делать с другими системами

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

Перед стартом интеграции нужен короткий технический чек-лист. Какая система используется и какой у неё версия; где она развёрнута — на локальном сервере заведения или в облаке; какие лицензии и модули куплены, поскольку доступ к API у части систем лицензируется отдельно; есть ли внешний доступ к серверу и постоянный адрес или потребуется защищённый канал. Дальше — учётная запись для интеграции с правами на чтение номенклатуры и создание заказов, список подразделений и складов, актуальные прайс-листы, типы обслуживания и настроенные способы оплаты. Отдельно уточняем, кто со стороны заведения отвечает за учётную систему: часто это внешний подрядчик или партнёр, который её внедрял, и все изменения на сервере идут через него. Чем раньше этот человек подключён к проекту, тем меньше пауз в работе и согласований в переписке. Практика показывает, что сбор этих данных занимает больше времени, чем сама техническая часть, поэтому чек-лист лучше пройти до начала работ, а не по ходу.

Сложности почти всегда однотипные. Первая — «грязная» номенклатура: дубли позиций, технические карточки, блюда без цены или с ценой только в одном прайс-листе. В приложение это попадает как есть, поэтому меню чистят на стороне учётной системы до запуска продаж. Вторая — модификаторы: у них своя логика обязательности, минимума и максимума, и переносить их нужно с проверкой, иначе гость соберёт заказ, который кухня не сможет приготовить. Третья — доступность сервера: если система стоит на локальном компьютере в заведении, отключение питания или интернета обрывает обмен, поэтому предусматривают повтор запросов и очередь заказов, чтобы ничего не потерялось. Четвёртая — обновления: после апдейта учётной системы формат ответа может измениться, и интеграцию нужно перепроверять. На это закладывают тестовый контур, где обмен прогоняют на реальном меню до открытия приёма заказов. Пятая, нетехническая: персонал должен понимать, откуда берётся заказ из приложения и что с ним делать, — короткая инструкция для смены снимает большую часть вопросов первой недели.

На практике разница между iiko и r_keeper заметна не столько в перечне данных, сколько в организации работ. У iiko интеграции чаще делают через документированный HTTP-API, в том числе облачный, и подключение обычно требует меньше согласований. r_keeper исторически сильнее завязан на серверную установку и работу через партнёрскую сеть: доступ, нужную лицензию на обмен и настройку на стороне сервера согласовывают с той компанией, которая обслуживает конкретный ресторан, — это добавляет шагов и времени. Набор данных при этом сопоставим: меню, цены, стоп-листы, заказы, чеки. Если у вас другая система, например Poster или иная касса с открытым API, схема не меняется: смотрим документацию, определяем доступные сущности и собираем обмен по тому же принципу. Когда API нет вовсе, приложение запускают на собственном меню, а интеграцию добавляют позже. Как это устроено в доставке — на странице мобильное приложение для доставки еды.