Послуги з інтеграції 1С-Бітрікс з маркетплейсами

Інтеграція 1С-Бітрікс з маркетплейсами

Типова ситуація: менеджер руками оновлює залишки на Ozon, паралельно Wildberries продає товар, якого вже немає на складі. Покупець оформлює замовлення — отримує скасування. Рейтинг продавця падає, майданчик ріже покази. Знайомо? Вирішується це одним способом — програмною інтеграцією Бітрікса з маркетплейсами через API, коли залишки, ціни та замовлення синхронізуються автоматично з єдиної адмінки.

Навіщо підключати маркетплейси

Маркетплейси — готовий трафік. Мільйони покупців із карткою в руці.

• Канали продажів — трафік, який один інтернет-магазин не збере. Більше половини онлайн-покупок проходять через майданчики.
• Економія на залученні — майданчик бере трафік на себе. Вам залишається асортимент і ціни.
• Єдине управління — товари, залишки, замовлення з усіх каналів у Бітріксі. Жодного ручного введення.
• Наскрізна аналітика — маржинальність по кожному каналу. Рішення на цифрах, не на інтуїції.

Які маркетплейси підключаємо

Ozon — Seller API v3. Створення карток (/v3/product/import), оновлення цін (/v1/product/import/prices), залишки (/v2/products/stocks), замовлення FBO/FBS (/v3/posting/fbs/list), повернення. Налаштовуємо автогенерацію штрихкодів та етикеток через label/task.

Wildberries — API постачальника. Вивантаження номенклатури з характеристиками за категоріями (/content/v2/cards/upload), баркоди, синхронізація залишків на складах WB (/api/v3/stocks), обробка замовлень і постачань, медіаконтент. Часта проблема — залишки розходяться між сайтом і WB, покупець оформлює замовлення на неіснуючий товар. Вирішуємо синхронізацією кожні 15 хвилин через агент Бітрікс.

Яндекс.Маркет — Partner API. Каталог через фід або push-модель, ціни, залишки, замовлення DBS/FBS/FBY (/campaigns/{campaignId}/orders), інтеграція з Яндекс.Доставкою.

СберМегаМаркет — Merchant API. Товари, офери, замовлення, синхронізація статусів.

Інші — AliExpress Росія, Avito, галузеві майданчики (Lamoda, Leroy Merlin).

Механізми інтеграції

Пряма інтеграція через API — найнадійніший шлях. Розробляємо кастомний модуль Бітрікс, який напряму звертається до ендпоінтів майданчика. Повний контроль: якщо маркетплейс ламає зворотну сумісність (а WB робить це регулярно) — оновлюємо модуль самі, не чекаємо третю сторону. Кожен запит логується в b_event_log, ретраї на 429/500 — автоматичні.

Агрегатори — RetailCRM, МійСклад, ApiShip. Уніфікують обмін із кількома майданчиками. Швидкий старт, але чорна скринька: коли щось ламається, дебажити через чужий шар — задоволення сумнівне. Підходить при обмеженому бюджеті.

Фіди (YML/XML) — вивантаження каталогу у форматі Яндекс.Маркет (YML), Google Merchant (XML). Генерація налаштовується через модуль catalog.export або кастомний обробник на CIBlockXMLFile. Класика, працює для початкового рівня інтеграції.

Вивантаження товарів і синхронізація

Вивантаження — не «натиснув кнопку». За ним серйозна підготовча робота.

• Мапінг категорій — зіставлення розділів інфоблоку Бітрікс із деревом категорій майданчика. У Ozon своя таксономія (/v1/description-category/tree), у WB — своя. Обов'язкові атрибути відрізняються.
• Мапінг властивостей — властивості інфоблоку (PROPERTY_*) → характеристики маркетплейсу. Конвертація одиниць, форматів — автоматично через таблицю відповідностей у highload-інфоблоці.
• Збагачення карток — rich-контент для Ozon, відеоогляди для WB, 360-фото. Майданчики ранжують за заповненістю: між «голою» та пропрацьованою карткою різниця в продажах дворазова.
• Зображення — автоматична генерація в потрібних роздільностях через CFile::ResizeImageGet().

Синхронізація — за розкладом через агенти CAgent::AddAgent():

Обробка замовлень

Замовлення з майданчиків потрапляють у b_sale_order автоматично й обробляються в єдиному потоці.

• Створення — замовлення приходить з усіма реквізитами. Модуль парсить відповідь API, створює замовлення через \Bitrix\Sale\Order::create(), прив'язує до типу платника та платіжної системи маркетплейсу.
• Єдиний потік — менеджери працюють із замовленнями з усіх каналів в одному інтерфейсі. Джерело замовлення видно у властивості ORDER_PROP.
• Синхронізація статусів — зібрали, відвантажили, доставили — статус оновлюється на маркетплейсі через callback. Обробник OnSaleStatusOrder.
• Повернення — скасування на маркетплейсі створює повернення в Бітрікс. Залишки повертаються на склад автоматично.
• Передача в 1С — замовлення йдуть у 1С:Підприємство через штатний обмін CommerceML. Єдине джерело правди.

Моніторинг

Мультиканальна торгівля без моніторингу — хаос із наростаючою ентропією.

• Контроль залишків — сповіщення при розбіжностях між Бітрікс, маркетплейсом і 1С. Товар із нульовим залишком блокується автоматично — не можна продати те, чого немає. Перевірка через cron кожні 10 хвилин.
• Логування та ретраї — кожен запит до API логується в b_event_log з тілом запиту й відповіді. Збій? Автоповтор з експоненційним backoff. Критична помилка? Сповіщення в Telegram-бот адміна.
• Ціноутворення — автоматичний розрахунок з урахуванням комісій майданчика, логістики та цільової маржі. Формула в налаштуваннях модуля: price = base_price / (1 - commission) + logistics.
• Аналітика — дашборд: виручка, замовлення, середній чек, повернення, маржинальність по кожному маркетплейсу окремо.

Підхід до інтеграції

1. Аудит — дивимось каталог Бітрікс, структуру інфоблоків, наявні обміни з 1С. Визначаємо готовність даних. Буває, 80% роботи — привести картки до ладу: заповнити обов'язкові властивості, уніфікувати одиниці вимірювання.
2. Стратегія — пріоритетні майданчики, модель (FBO/FBS/DBS), глибина інтеграції.
3. Розробка модулів — мапінг, валідація, обробка помилок. Покриваємо unit-тестами критичні сценарії: розбиття замовлення, перерахунок залишків при частковому скасуванні.
4. Тестування — вивантаження тестових товарів, емуляція замовлень через sandbox API майданчиків, граничні випадки (нульовий залишок, товар без фото, ціна нижче мінімальної).
5. Запуск — послідовно запускаємо інтеграції, моніторимо перші обміни в реалтаймі.
6. Супровід — майданчики регулярно оновлюють API (WB — без попередження). Адаптуємося оперативно.

Терміни

Конкретні терміни залежать від обсягу каталогу, кількості майданчиків, складності мапінгу та стану обміну з 1С. Детальну оцінку даємо після аудиту.