Інтеграція 1С-Бітрікс з Яндекс.Маркет: від фіду до API

Налаштування інтеграції 1С-Бітрікс з Яндекс.Маркет: від фіду до API

Каталог завантажено, але товари не проходять модерацію на Яндекс.Маркеті — 30% фідів містять помилки XML. Ціни та залишки не синхронізуються, замовлення губляться. Один із наших клієнтів, магазин електроніки з каталогом 3000 позицій, зіткнувся з відхиленням 50% товарів через неправильний мапінг категорій та відсутність штрихкодів. Після налаштування коректного YML-фіду та інтеграції Partner API модерація пройшла за 2 дні, а частота помилок знизилася до 0%.

Інтеграція 1С-Бітрікс з Яндекс.Маркет — стандартне завдання, але диявол у деталях: кривий YML-фід, невірний мапінг категорій, помилки в обробці callback-запитів. За 5 років ми налаштували понад 50 інтеграцій для каталогів від 100 до 50 000 товарів. Нижче — розбір типових проблем та рішень.

Замовте налаштування інтеграції — і ми закриємо всі проблеми з модерацією та синхронізацією.

Архітектура інтеграції

Яндекс.Маркет спілкується з магазином через два канали:

• YML-фід — XML-файл з товарами, який Маркет періодично забирає за URL. Основний канал для каталогу.
• Partner API (https://api.partner.market.yandex.ru/) — REST API для керування замовленнями, цінами, залишками, статусами.

У 1С-Бітрікс за генерацію фіду відповідає модуль catalog.export з профілем експорту «Яндекс.Маркет (YML)». За роботу з API — або модуль з Marketplace (RetailCRM, Kooplex, «МоєДіло»), або кастомний обробник, який ми пишемо під вашу архітектуру.

Генерація YML-фіду: глибоке налаштування

Стандартний профіль експорту створюється в Магазин → Налаштування → Експорт каталогу → Яндекс.Маркет. Базові параметри:

• Тип торгівлі: DBS (Delivery by Seller), FBS (Fulfillment by Seller), FBY (Fulfillment by Yandex).
• Інфоблок каталогу: прив'язка до конкретного інфоблоку товарів.
• Властивості для експорту: мапінг полів інфоблоку на теги YML.

Обов'язкові теги для кожного <offer>:

Критичний момент — <param>. Яндекс.Маркет вимагає характеристики товару через <param name="Розмір">42</param>. У Бітрікс характеристики — це властивості інфоблоку. Стандартний експортний профіль вивантажує тільки ті властивості, які явно позначені в налаштуваннях. Якщо властивість множинна, кожне значення генерує окремий <param>. Ми доопрацьовуємо обробник експорту в /bitrix/php_interface/include/catalog_export/, щоб гарантувати коректну структуру.

Проблема з торговими пропозиціями (SKU) — якщо товар має SKU (розмір, колір), кожна пропозиція — окремий <offer> у фіді, пов'язаний через <group_id>. Стандартний експорт Бітрікс не завжди коректно формує group_id — ми правимо код, щоб дублі не з'являлися. Докладніше про налаштування модуля експорту — в офіційній документації Бітрікс.

Які дані обов'язкові в YML-фіді?

Окрім базових тегів, для успішної модерації важливі атрибути <vendor>, <barcode> та <param>. Без штрихкоду товар не потрапить у категорії, де потрібна EAC-маркування. За статистикою, 20% відмов у модерації пов'язані з відсутністю barcode у товарів, де він обов'язковий. Ми завжди перевіряємо це на етапі аудиту.

Чому важливий правильний мапінг категорій?

Яндекс.Маркет використовує власне дерево категорій. Розділ «Електроніка → Смартфони» у вашому каталозі — це конкретний categoryId у дереві Маркету. Мапінг задається двома способами:

1. Через модуль інтеграції — завантажується дерево категорій Маркету, і для кожного розділу інфоблоку вибирається відповідність.
2. Через market_category у YML — тег <market_category>Електроніка/Смартфони</market_category> всередині <offer>. Яндекс намагається зіставити автоматично.

Перший спосіб надійніший. За нашими даними, близько 70% фідів відхиляються через невалідний XML, а некоректний мапінг категорій — причина 20% відмов у модерації.

Як керувати замовленнями через Partner API?

Коли покупець замовляє товар на Яндекс?

Маркет, замовлення потрібно прийняти і обробити. Схема:

1. Маркет відправляє POST на ваш endpoint (callback URL) з даними замовлення.
2. Обробник на стороні Бітрікс створює замовлення в модулі sale через Bitrix\Sale\Order::create().
3. При зміні статусу замовлення в Бітрікс — відправляється PUT-запит у Partner API для оновлення статусу на Маркеті.

Статуси Маркету: PROCESSING → DELIVERY → DELIVERED / CANCELLED. Мапінг на статуси Бітрікс (N, P, F, C) налаштовується в модулі інтеграції. Ми підключаємо автоматичне оновлення статусів та сповіщення для менеджерів.

Оновлення залишків. Маркет очікує актуальні залишки. Два підходи:

• Через фід — тег <count> у <offer>. Фід оновлюється по cron раз на 30–60 хвилин.
• Через API — метод PUT /campaigns/{campaignId}/offers/stocks. Оновлення в реальному часі, критично для товарів з швидким попитом. Вимоги до залишків описані в документації Partner API.

Часті помилки при інтеграції

• Фід не проходить валідацію. Яндекс перевіряє XSD-схему. Незакриті теги, спецсимволи (&, <, >) в описі без CDATA, кирилиця в URL картинок — все це причини відхилення. Ми використовуємо автоматичну перевірку фіду перед відправкою.
• Ціни не співпадають. Якщо на сайті діють знижки, а фід вивантажує ціну до знижки — Маркет може заблокувати магазин за розбіжність цін. Рішення: в експортному профілі вибрати тип ціни, що відповідає ціні на сайті, або формувати <oldprice> для закресленої ціни.
• Дублі товарів. При переіндексації каталогу змінюються ID елементів інфоблоку. Маркет вважає нові ID новими оферами, а старі — видаленими. Використовуйте <shop-sku> на основі артикула (властивість ARTICLE), а не ID елемента.

Якщо ви зіткнулися з однією з цих проблем — зв'яжіться з нами, ми допоможемо швидко їх усунути.