Интеграция УТ 11.5 с Яндекс.Еда: готовый шаблон для обмена

16 августа 2026 · infolimp.ru

Контекст и ситуация

Типовая интеграция УТ 11.5 с Яндекс.Еда через HTTP-сервисы — это, по сути, REST API с JSON-пакетами. На Infostart выложен готовый шаблон, который решает 80% задачи: приём заказов, выгрузка меню, обновление остатков. Но «дьявол в деталях» — оставшиеся 20% превращают интеграцию из «работает» в «работает надёжно». Главная ловушка, которую не замечают 9 из 10 внедренцев, — это гонка состояний (race condition) при обработке входящих заказов и некорректная обработка частичных отмен.

Технический разбор: почему «просто HTTP» не работает

Яндекс.Еда присылает заказ одним пакетом, но статусы могут меняться асинхронно: «Принят» → «Готовится» → «Передан курьеру» → «Доставлен». Если ваш обработчик не блокирует повторную обработку одного и того же заказа (по ИдентификаторЗаказаВЯндексе), вы рискуете создать в УТ 11.5 несколько документов «Заказ клиента» на один и тот же заказ. Типовой код из шаблона Infostart этого не предусматривает.

Ключевой тезис: Интеграция с агрегатором — это не про обмен данными, а про управление состояниями. Каждый входящий запрос должен быть идемпотентным: повторный вызов с тем же ID заказа не должен создавать новый документ.

// Пример блокировки повторной обработки заказа
Функция ОбработатьЗаказЯндекс(ИдентификаторЗаказа, ДанныеЗаказа) Экспорт

    // Проверяем, не обработан ли уже заказ
    НайденныеЗаказы = Документы.ЗаказКлиента.НайтиПоРеквизиту("ИдентификаторЗаказаВЯндексе", ИдентификаторЗаказа);
    Если НайденныеЗаказы.Количество() > 0 Тогда
        // Возвращаем ссылку на существующий заказ, не создавая новый
        Возврат НайденныеЗаказы[0].Ссылка;
    КонецЕсли;

    // Блокировка на уровне транзакции для исключения гонки
    НачатьТранзакцию();
    Попытка
        // Повторная проверка внутри транзакции
        НайденныеЗаказы = Документы.ЗаказКлиента.НайтиПоРеквизиту("ИдентификаторЗаказаВЯндексе", ИдентификаторЗаказа);
        Если НайденныеЗаказы.Количество() > 0 Тогда
            ЗафиксироватьТранзакцию();
            Возврат НайденныеЗаказы[0].Ссылка;
        КонецЕсли;

        НовыйЗаказ = Документы.ЗаказКлиента.СоздатьДокумент();
        // ... заполнение реквизитов из ДанныеЗаказа ...
        НовыйЗаказ.Записать(РежимЗаписиДокумента.Запись);
        ЗафиксироватьТранзакцию();
        Возврат НовыйЗаказ.Ссылка;
    Исключение
        ОтменитьТранзакцию();
        ЗаписьЖурналаРегистрации("ОшибкаИнтеграцииЯндекс", УровеньЖурналаРегистрации.Ошибка,,,
            КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
        Возврат Неопределено;
    КонецПопытки;

КонецФункции

Частичные отмены и возвраты: «слепое пятно» типового шаблона

Яндекс.Еда позволяет отменить не весь заказ, а отдельные позиции. Типовой шаблон на Infostart обрабатывает только полную отмену. Если клиент отменил одну пиццу из трёх, а две другие уже готовятся, ваш обработчик должен:

1. Скорректировать заказ клиента в УТ 11.5 (удалить строку или установить количество 0).
2. Пересчитать резервы на складе.
3. Отправить в Яндекс.Еда подтверждение частичной отмены.

Без этого остатки «поплывут»: товар, который фактически не ушёл клиенту, будет числиться зарезервированным под отменённый заказ.

Механика под капотом: как работает резерв в УТ 11.5

При создании заказа клиента УТ 11.5 автоматически резервирует товары на остатках. Если вы просто удалите строку заказа (или измените количество), резерв пересчитается. Но если вы создали заказ, а потом пришла частичная отмена — и вы её проигнорировали — резерв останется висеть. Через неделю складской учёт разойдётся с реальностью.

Предупреждение: Никогда не обрабатывайте частичную отмену через «Сторно заказа» или «Корректировку реализации». Это порождает цепочку документов, которую потом невозможно оттрассировать. Правильный путь — изменить существующий заказ клиента в режиме «Редактирование» с перепроведением.

// Обработка частичной отмены позиции заказа
Процедура ОбработатьЧастичнуюОтмену(СсылкаНаЗаказ, ИдентификаторПозицииЯндекс, НовоеКоличество)

    ЗаказОбъект = СсылкаНаЗаказ.ПолучитьОбъект();
    Если ЗаказОбъект = Неопределено Тогда
        Возврат;
    КонецЕсли;

    // Ищем строку ТЧ Товары по идентификатору из Яндекс.Еда
    Для Каждого Строка Из ЗаказОбъект.Товары Цикл
        Если Строка.ИдентификаторПозицииЯндекс = ИдентификаторПозицииЯндекс Тогда
            Если НовоеКоличество = 0 Тогда
                Строка.Удалить();
            Иначе
                Строка.Количество = НовоеКоличество;
            КонецЕсли;
            Прервать;
        КонецЕсли;
    КонецЦикла;

    Попытка
        ЗаказОбъект.Записать(РежимЗаписиДокумента.Запись);
    Исключение
        ЗаписьЖурналаРегистрации("ОшибкаЧастичнойОтменыЯндекс", УровеньЖурналаРегистрации.Ошибка,,,
            КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
    КонецПопытки;

КонецПроцедуры

Сравнение подходов: готовый шаблон vs кастомная доработка

Готовый шаблон с Infostart — это отличная стартовая точка. Но для production-использования его нужно доработать. Сравним ключевые аспекты:

Практическое руководство: что делать прямо сейчас

Если вы уже используете шаблон с Infostart или планируете внедрение, выполните чек-лист ниже. Это займёт 2-3 часа, но сэкономит дни на разборе последствий.

Чек-лист доработки интеграции

1. Добавьте реквизит «ИдентификаторЗаказаВЯндексе» в документ «Заказ клиента» (тип — Строка, длина 50). Заполняйте его при создании заказа.
2. Реализуйте идемпотентность — вставьте блокировку транзакции с повторной проверкой, как в примере выше.
3. Настройте обработку частичных отмен — добавьте в ТЧ «Товары» реквизит «ИдентификаторПозицииЯндекс» (тип — Строка).
4. Ограничьте выгрузку остатков — в запросе к регистру «ТоварыНаСкладах» добавьте отбор по товарам, которые есть в активных заказах Яндекс.Еда (иначе вы будете выгружать 10 000 позиций, когда нужно 50).
5. Добавьте мониторинг — создайте обработку, которая показывает «зависшие» заказы (созданы в УТ, но не подтверждены Яндексом более 30 минут).

Типичные ошибки

• Ошибка: Использование НайтиПоНаименованию для поиска номенклатуры по названию из Яндекс.Еда.
  Последствие: Дубли номенклатуры из-за опечаток или разных регистров.
  Решение: Используйте артикул или штрихкод. Если артикула нет — создайте соответствие через внешнюю обработку.
• Ошибка: Выгрузка остатков в реальном времени при каждом изменении заказа.
  Последствие: Блокировки на регистре остатков, падение производительности.
  Решение: Выгружайте остатки раз в 5-10 минут по расписанию регламентного задания.
• Ошибка: Игнорирование HTTP-статусов ответа от Яндекс.Еда.
  Последствие: Заказ создан в УТ, но не подтверждён агрегатором — клиент не получит уведомление.
  Решение: Проверяйте HTTPОтвет.КодСостояния и при ошибках (4xx, 5xx) ставьте заказ в очередь на повторную отправку.

Выводы

Готовый шаблон интеграции УТ 11.5 с Яндекс.Еда — это хороший фундамент, но не финальное решение. Критически важные аспекты (идемпотентность, частичные отмены, корректная работа с остатками) в нём либо отсутствуют, либо реализованы минимально. Потратив несколько часов на доработку по описанному чек-листу, вы получите интеграцию, которая не «посыпется» в первый же час пик.

Резюме для руководителя: Не принимайте интеграцию, если в коде нет блокировки повторной обработки заказов и обработки частичных отмен. Это не «пожелание», а обязательное требование для промышленной эксплуатации. Иначе готовьтесь к ручному пересчёту остатков каждую неделю.