Привет, Хабр! На связи Пиробайт. В этом году мы разработали новую версию сайта для федеральной службы доставки «Гриль №1». У себя рассказали, как круто справились с задачей, но не упомянули о том, что приключилось на бэкенде. Считаем, что и такие стороны лучше освещать, мы за прозрачность. В статье расскажем, в чем была загвоздка с iiko (айко) и какие решения мы нашли.

Что такое iiko и с чем там могут быть сложности

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

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

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

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

Теперь о самом проекте

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

Старый сайт был разработан на Битриксе, и iiko был подвязан к нему. Мы же разрабатывали новый сайт на Laravel, и iiko нужно было интегрировать уже с ним. 

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

  • информацию о пользователях и группах;

  • меню и ингредиенты;

  • акции, купоны и промокоды;

  • SEO и рассылки;

  • торговые точки и города.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Под раздачу попала и система бонусов и акций.

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

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

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

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

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

***

Вывода 2:

  1. Дотошное изучение системы, ее документации и требований — не всегда залог того, что все пойдет как по маслу, у всего есть риски;

  2. Если в системе нет какого-то важного функционала, всегда можно что-нибудь придумать. 

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

Если остались вопросы или есть гипотезы, что таких ситуациях делали бы вы (а может уже делали), оставляйте комменты! Интересно послушать и про ваш опыт в том числе.

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

В телеграм-канале

Во ВКонтакте

На нашем сайте

Комментарии (1)


  1. yavoloh
    28.12.2023 14:50

    Спасибо за статью!

    Что было бы еще интересно узнать:

    • разделение на города на основе локалей next.js - опыт, какие плюсы\минусы (например, удобно ли изменять список, ведь он должен быть статичен)

    • сращивание данных DaData и Яндекс Карты - с какими проблемами столкнулись и как решали (базы все же разные и не всегда бьются адреса; тоже на проекте имеем города и подсказки из DaData, а карты от Яндекса)