Разработка сайта для ресторана быстрого питания. Сложности интеграции с iiko

Что такое iiko

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

С подобным справляются многие системы, но не все процессы в них автоматизированы. iiko же выстраивает работу целиком. Для примера:

Есть владелец ресторана, шеф-повар и бухгалтер. Они занимаются закупками и проверяют наличие продуктов на складе. Если там не хватает булок, ингредиент ставится в «стоп-лист», выручка теряется. Если булок, наоборот, больше, чем нужно, а гости заказывают бургеры редко — они начинают засыхать. Приходится списывать, из-за чего в цене растут другие блюда. Шеф-повар проверяет наличие по понедельникам, а бухгалтер проводит ревизию раз в пару недель, когда составляет отчеты. Поэтому иногда есть неточности в подсчетах.

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

Про клиента — сайт для службы доставки еды «Гриль №1»

«Гриль №1» — федеральная сеть ресторанов быстрого питания, всего по России 53 точки. И это ключевой фактор, почему заказчик выбрал iiko — в программе можно управлять отдельными ресторанами. Старый сайт был разработан на Битриксе, и iiko был подвязан к нему. Мы же разрабатывали новый сайт на Laravel, и iiko нужно было интегрировать уже с ним.

В iiko администратор может настраивать:

• информацию о пользователях и группах
• меню и ингредиенты
  
• акции, купоны и промокоды
  
• SEO и рассылки
  
• торговые точки и города
  

Кстати говоря, о точках. Их много — 53, и цифра собирается только расти. Эта особенность, которая тянется по всему проекту, и стала главным камнем преткновения.

Мы плавно подошли сути.

Проблемы интеграции с iiko

На сайте не отображались новые блюда

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

Чтобы на сайте отображалось новое блюдо, администратор должен добавить его через админпанель, правильно указав его категорию — воки, шаурма, пироги. Если категория указана неправильно, блюдо не синхронизируется, соответственно, на сайте ничего не меняется. Например, если администратор, когда добавлял новый вок, прописал категорию «‎wok‎» строчными буквами, то будет ошибка. Нужно именно заглавными.

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

Просим заказчика поменять «‎NAME‎», дальше удаляем связанные с этой группой блюда и заново синхронизируем

Заказы не доходили до кассы

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

Мы решили эту проблему, реализовав выгрузку в колл-центр. Заказчик развернул сервер, и на него улетают все заказы. Механизм такой: мы берем «‎потерявшийся» заказ и отгружаем его в колл-центр. Сотрудники переводят его на ту точку, на которую он и должен был уйти изначально.

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

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

В момент получения событий в Webhook, заказ уже создался на корректной точке — он выгрузился в колл-центр, и сотрудники перенесли его на нужную точку.

Непонятно, какие уже промокоды были активированы, а какие — еще нет

Под раздачу попала и система бонусов и акций. Купонов в сумме около 500-600 тысяч — это много. Чтобы выгрузить такое количество на сайт, мы прописали функцию их выгрузки через Excel. Чуть позже сделали ее автоматической, потому что делать что-то вручную — не самая хорошая идея, хотя на тот момент она была самой оптимальной. Сейчас объясним, почему.

Проблема того, что было непонятно, какие промокоды активированы, а какие — нет, вытекала из другой — в iiko нет метода, который автоматически возвращает список промокодов. Что это значит?

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

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

Когда пользователь вводит купон, мы идем в базу данных. Находим его и видим — он не активирован. Но может быть такое, что он активирован в оффлайне (знать это наверняка мы не можем). В базе данных видим купон и его серию, берем его и идем в инструментарий iiko.biz, отправляем запрос и смотрим — был он активирован ранее или нет. Если был — видим ошибку. В дальнейшем, если пользователь снова решит обмануть систему, мы уже не пойдем в iiko.biz. Если все нормально, просчитываем скидку дальше.

Какой вывод?

Вывода 2:

• Дотошное изучение системы, ее документации и требований — не всегда залог того, что все пойдет как по маслу
• Если в системе нет какого-то важного функционала, всегда можно что-нибудь придумать

Про процесс разработки сайта для «Гриль №1» целиком, можно почитать в разделе кейсы.