Техническая сторона истории успеха всегда намного больше интересует руководителей проектов и интеграторов, чем, например, то, как оно было раньше и как работает сейчас. Поэтому о реализации мобильного учёта в Бургер Кинге мы решили рассказать именно с точки зрения технарей. Разбираем архитектуру решения, работу с API Microsoft Dynamics AX (Axapta), организацию офлайн‑режима и интеграцию с Честным ЗНАКом.

Сеть быстрого питания Бургер Кинг в России объединяет более 800 ресторанов. Ежедневный оборот включает тысячи поставок, инвентаризации и межскладские перемещения. Часть продукции подлежит строгой прослеживаемости в государственных системах «Меркурий», ЕГАИС и Честный ЗНАК.

Основной технической задачей этого проекта стала миграция бизнес‑процессов со стационарных рабочих мест на терминалы сбора данных (ТСД) с обеспечением бесперебойной работы даже при отсутствии стабильного Wi‑Fi. В качестве программного ядра заказчик выбрал решение «Магазин 15» от Клеверенса, интегрированное с учётной системой Axapta.

Архитектурные требования и ограничения

Проект стартовал в условиях действующей инфраструктуры крупной федеральной сети. Первостепенно нужно было настроить бесшовную интеграцию мобильного контура с legacy‑системой Microsoft Dynamics AX (Axapta) при сохранении высокой отказоустойчивости на 800+ распределённых узлах. 

При проектировании системы мы выделили ключевые технические ограничения:

  1. Нестабильная сеть
    В зонах приготовления пищи и складских помещениях часто отсутствуют точки доступа Wi‑Fi или наблюдается низкое качество сигнала. Система должна была обязательно поддерживать полноценный офлайн‑режим.

  2. Интеграция с legacy‑системой
    Бургер Кинг ведёт учёт в Microsoft Dynamics AX (Axapta). А значит, прямая запись в основные таблицы ERP запрещена политиками безопасности и архитектурными стандартами.

  3. Государственная маркировка

ГИС МТ требовала поэкземплярно принимать DataMatrix‑коды. Заказчик сразу озвучил, что нужно настроить оперативную проверку валидности КМ в системе Честный ЗНАК без задержек для пользователя.

  1. Масштабируемость
    Решение должно работать идентично на 800+ узлах сети с минимальными затратами на поддержку.

Реализация интеграции

Для обмена данными между мобильным приложением и Axapta был использован подход через промежуточные таблицы и Клеверенс API. Это позволило изолировать мобильный контур от ядра ERP и обеспечить асинхронную обработку данных.

Структура хранения данных в Axapta была расширена тремя специализированными таблицами:

  1. Хранит общую информацию о документе (ID операции, дата, статус, ID сотрудника).

  2. Содержит строковые позиции товара (SKU, количество, единицы измерения).

  3. Отдельная таблица для хранения кодов маркировки, связанных с конкретными строками.

Мы связали наше решение с Axapta через Клеверенс API. В системе учёта все данные о приёмке, инвентаризации или кегах сохраняются в специальных таблицах. Также был настроен коннектор, чтобы проверять, что кега настоящая, зарегистрирована в Честном ЗНАКе в правильном статусе

Евгений Яицкий, руководитель проектного отдела Клеверенс

Такая нормализация данных позволила избежать блокировок основных таблиц ERP во время массовой загрузки результатов инвентаризации или приёмки.

Алгоритм работы в офлайн‑режиме

Поскольку зоны складского хранения и приготовления пищи в ресторанах часто экранированы или находятся вне зоны покрытия корпоративного Wi‑Fi, система была спроектирована по принципу Offline‑first. Это позволило исключить простои персонала при потере соединения с центральным сервером. 

А ключевым техническим решением стал механизм локального кэширования и отложенной синхронизации:

  1. Локальное хранение
    Все действия сотрудника (сканирование ШК, ввод количества, проверка сроков годности) записываются в локальную базу данных ТСД. Обработка происходит мгновенно, без ожидания ответа от сервера. 

  2. Очереди задач
    Приложение формирует очереди на отправку данных. Если Wi‑Fi “отвалился”, данные не теряются, а накапливаются во внутренней памяти терминала.

  3. Авто‑синхронизация
    Как только соединение восстанавливается, система автоматически отправляет накопленные пакеты на сервер.

  4. Конфликт‑менеджмент
    На стороне сервера реализована логика проверки остатков и валидации данных перед финальной проводкой документа в Axapta. Синхронизация занимает несколько минут после восстановления связи.

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

Работа с Честным ЗНАКом

Одной из самых сложных задач стала интеграция с системой маркировки разливного пива. Процесс постановки кег на кран требовал мгновенной обратной связи.

Технический флоу операции:

  1. Сотрудник сканирует DataMatrix на кеге.

  2. Приложение отправляет запрос через специализированный коннектор к сервису проверки валидности.

  3. Параллельно выполняется локальная проверка срока годности товара в базе.

  4. При успешной валидации данные фиксируются локально и помечаются для отправки в Честный ЗНАК через ERP.

  5. При ошибке (неверный статус, просрочка) интерфейс блокирует дальнейшие действия и выводит предупреждение.

Это исключило возможность проведения операций с нелегальной или некондиционной продукцией на уровне UI/UX, сняв нагрузку с бэк‑офиса по ручному контролю.

Оптимизация UX для снижения нагрузки на поддержку

Учитывая, что конечными пользователями являются линейные сотрудники ресторанов, а не IT‑специалисты, особое внимание было уделено защите от ошибок ввода (Input Validation):

  • Контекстные подсказки
    Интерфейс динамически меняется в зависимости от типа товара. Для маркированной продукции система принудительно требует сканирования DataMatrix, игнорируя обычные штрихкоды.

  • Автоматизация учёта тары
    Логика выбора типа тары завязана на профиль поставщика. Сотруднику не нужно выбирать тип вручную — система определяет его автоматически на основе справочников.

  • Проверка целостности
    Реализованы скрипты, предотвращающие закрытие документа при неполном вводе данных или наличии незакрытых позиций.

Результаты внедрения и планы развития

Внедрение мобильной инфраструктуры в ресторанах Бургер Кинг ускорило рутинные операции и изменило баланс нагрузки. Перенос первичной обработки данных на edge‑устройства позволил разгрузить ядро ERP и повысить отказоустойчивость всей системы.

По данным постмониторинга за первые 6 месяцев эксплуатации:

  • Скорость приёмки выросла на 60% — за счёт исключения ручного ввода и автоматического сравнения факта с планом.

  • Скорость инвентаризации увеличилась на 33% — благодаря сканированию запечатанных коробов и работе в офлайн‑режиме.

  • Нагрузка на ERP снизилась — количество прямых операций пользователей в учётной системе сократилось до минимума, так как вся первичная регистрация происходит на ТСД.

На 2026 год запланировано расширение функционала мобильного клиента. Основная цель — дальнейшая децентрализация вычислений и перенос логики формирования документов с сервера на клиентские устройства там, где это безопасно с точки зрения консистентности данных.

Выводы

Проект автоматизации процессов в Бургер Кинг демонстрирует, что успешная цифровизация распределённой розничной сети зависит не только от выбора стека технологий, но и от грамотной архитектуры взаимодействия между edge‑устройствами и центральной ERP‑системой. Опыт интеграции мобильного контура с Axapta в условиях жёстких требований государственной маркировки позволяет выделить несколько основных принципов, которые могут быть полезны при проектировании аналогичных высоконагруженных решений. 

  1. Изоляция через API
    Использование промежуточных таблиц и API для интеграции с тяжелыми ERP‑системами (как Axapta) позволяет сохранить производительность ядра и упростить масштабирование мобильного контура.

  2. Offline‑first подход
    Для розничных сетей с большой площадью покрытие Wi‑Fi редко бывает идеальным. Архитектура должна изначально проектироваться с учётом локального хранения данных и механизмов разрешения конфликтов при синхронизации.

  3. Валидация на клиенте
    Перенос проверок (сроки годности, статусы маркировки) на сторону ТСД снижает количество ошибочных операций и разгружает центральные серверы обработки данных маркировки.

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

Ирина Роготнева, руководитель проектов по маркировке Бургер Кинг

Этот подход доказал, что даже в условиях жестких требований государственного регулирования и устаревших ERP‑систем можно построить гибкую, отказоустойчивую и быструю мобильную инфраструктуру.