ERP Platform Docs

3.1 Интеграция с Яндекс.Едой

время чтения ~4 мин.

BR 3.1: Интеграция с Яндекс.Едой

Зависит от:

Контекст

Франшиза хочет принимать заказы с маркетплейса Яндекс.Еда (и Маркет Деливери — бывший Delivery Club, технически та же платформа Яндекса) напрямую в свою ERP-админку и на POS ресторана. Сейчас заказы Яндекса обрабатываются вручную через отдельный планшет «Я.Еда Вендор» — без связи с каталогом, без учёта в отчётах франшизы, без единого UX кассира.

Цель — сделать Яндекс.Еда одним из нескольких каналов заказа в нашей ERP (наравне с внутренним POS и будущим собственным сайтом/мобильным приложением). Архитектурно интеграция закладывается абстрактной — через выделенный Aggregator Service, чтобы позже добавить Chibbis / Broniboy / других без переделки Order Service.

Требования

1. Меню публикуется из нашего Catalog Service в Яндекс

  • Каждый товар в Catalog имеет флаг available_in_aggregator (bool).
  • Для товара можно задать отдельную цену для Яндекса (price_override) — чтобы учесть их комиссию 12-35%.
  • Маппинг нашего product_id ↔ их external_sku — после первой синхронизации Яндекс присваивает свой ID, мы сохраняем.
  • Синхронизация batch — раз в сутки. Яндекс пуллит наш JSON-снапшот. Real-time обновления — только через стоп-лист.
  • Модификаторы, категории, фото — всё из нашего каталога.

2. Стоп-лист синхронизируется раз в 10 минут

  • Когда товар уходит в стоп (по остаткам Warehouse или вручную франчайзи) — через ≤15 минут он исчезает из приложения Яндекс.Еды.
  • Яндекс пуллит эндпоинт /stoplist каждые ~10 минут.
  • Обратное: товар возвращается в продажу — так же через следующий pull.

3. Приём заказа из Яндекса

Когда гость оформил заказ в приложении Яндекс.Еды:

  • Яндекс дёргает наш эндпоинт POST /orders/new.
  • Aggregator Service валидирует: есть ли ресторан с таким external_restaurant_id, есть ли все товары, нет ли стоп-листа.
  • Заказ создаётся в Order Service с channel=YANDEX_EDA, external_order_id, payment_type=EXTERNAL_PREPAID.
  • В админке заказ виден в OrderHistory с бейджем «Я.Еда».
  • На POS ресторана — звуковая нотификация + карточка нового заказа в секции «Заказы агрегаторов».
  • По умолчанию заказ в статусе NEW, ждёт подтверждения кассира.

4. Управление статусом заказа на POS

Кассир в секции «Заказы агрегаторов» видит карточку и управляет статусами:

КнопкаСтатус у насЧто уходит в Яндекс
ПринятьIN_PROGRESSaccepted → гость видит «Готовится»
ОтклонитьCANCELLEDrejected + причина → автоотмена + возврат гостю
ГотовREADYready → курьер вызывается
Передан курьеруHANDED_OVERhanded_over → гость видит «В доставке»

Обновления уходят в Яндекс push-запросом через Aggregator Service.

5. PayKeeper для этих заказов не используется

  • Заказы Яндекса уже фискализированы Яндексом при онлайн-оплате.
  • В ресторане PayKeeper терминал для такого заказа не вызывается (нет повторного чека).
  • В админке в отчёте «Выручка по ТТ» агрегаторные заказы идут отдельной строкой (комиссия Яндекса учитывается отдельно).

6. Отмена заказа гостем

  • Гость отменил в приложении → Яндекс push нам (или мы видим при следующем pull).
  • Order Service переводит заказ в CANCELLED.
  • Кассир видит отмену на POS (если заказ ещё не выдан). Если уже в IN_PROGRESS — отмена идёт с фиксацией (возможна частичная компенсация через refund_records).

7. Маркированные товары при доставке

Для доставляемых маркированных позиций (молочные напитки, бутилированная вода, пиво, некоторые соусы):

  • На POS перед «Передан курьеру» — экран сканирования DataMatrix.
  • Каждый код проверяется через ФЯ PayKeeper (labelcheck) или облачный ТС ПИоТ.
  • Коды передаются в нашу БД (marked_items_handover) для последующего отчёта в ЦРПТ.
  • Открытый юридический вопрос: кто именно обязан выводить коды из оборота при онлайн-доставке — Яндекс или ресторан. Требуется консультация юриста. До решения — собираем коды «на всякий случай».

8. Подключение ресторана (onboarding)

  • В админке на странице ТТ — вкладка «Интеграции».
  • Владелец франчайзи жмёт «Подключить Яндекс.Еду» → ввод client_id/client_secret (выдаются Яндексом после договора).
  • Тест-режим — проверка OAuth + тестовый заказ.
  • После активации — галочка «Активно», логи pull/push-запросов доступны там же.

Роли и доступ

РольЧто может
ФраншизаВидит все заказы агрегаторов по всей сети, может делать отчёты, настраивать маркетинг
ФранчайзиПодключает Яндекс.Еду к своим ТТ, управляет price_override, смотрит свои заказы
Менеджер ТТВидит заказы своей ТТ, управляет стоп-листом
КассирПринимает/отклоняет/закрывает заказы на POS

Out of scope (для этого BR)

  • Собственный сайт/мобилка для заказов — отдельный BR позже (тот же Aggregator Service будет принимать и их, просто с другим channel).
  • Маркет Деливери — добавляется после Яндекс.Еды как новый конфиг того же коннектора (одна неделя работы).
  • Chibbis / Broniboy / другие локальные — Phase 2.
  • Wolt — в РФ не работает, не рассматриваем.
  • Автоматический расчёт зон доставки — пока настраивается вручную на стороне Яндекса.

Критические блокеры

  1. Договор с Яндексом — до подписания нет sandbox, полных JSON-схем, OAuth credentials. Спеки делаем по публичной документации (yandex.ru/dev/eda-vendor/doc/ru/ref/). Код начинаем только после получения тестового доступа.
  2. Бизнес-одобрение — Яндекс проверяет рейтинг/категорию/размер меню ресторана перед подключением. Без одобрения интеграцию не активировать.
  3. Честный Знак в доставке — юридическая консультация.
  4. Нет готовых SDK — клиент пишем сами.

Ссылки

Вид графа

Обратные ссылки