Автоматизація обміну даними: 1С-Бітрікс та Ozon Білорусь

Оператор щодня витрачає 2–3 години на перенесення замовлень з Ozon Білорусь в 1С-Бітрікс. Ціни застарівають, Ozon блокує картки. Залишки розходяться, клієнти скаржаться на скасування. Знайома картина? Ми автоматизуємо обмін товарами, замовленнями та залишками між вашим магазином на 1С-Бітрікс і Ozon Білорусь. Ми маємо 5+ років досвіду інтеграції 1С-Бітрікс з маркетплейсами та виконали 40+ проєктів для українських та білоруських продавців. Наприклад, у проєкті для мережі електроніки ми налаштували синхронізацію залишків кожні 5 хвилин, що зменшило кількість скасованих замовлень на 30%. Ozon активно зростає в Білорусі: окремий розділ для продавців, склади в Мінську, схеми FBS і FBO. Технічно інтеграція будується на Ozon Seller API — тому ж, що й у Росії, але з білоруською специфікою документообігу та логістики. Проаналізуємо ваш каталог і запропонуємо рішення за 1–2 дні. Вартість розраховується індивідуально. Отримайте консультацію — зв'яжіться з нами.

Як влаштований Ozon Seller API?

Ozon надає REST API за адресою https://api-seller.ozon.ru/. Аутентифікація — через заголовки Client-Id: {id} та Api-Key: {key}. Обидва значення беруться з особистого кабінету продавця. Основні методи:

• POST /v2/product/import — завантаження товарів (асинхронне, через чергу)
• POST /v1/product/import/prices — оновлення цін
• POST /v2/products/stocks — оновлення залишків (FBS)
• POST /v3/posting/fbs/list — список замовлень FBS
• POST /v4/posting/fbs/ship — підтвердження відвантаження

Завантаження товарів асинхронне: відправляємо масив товарів, отримуємо task_id, потім опитуємо GET /v1/product/import/info?task_id={id} до завершення. Типовий час обробки — 5–15 хвилин. Ми гарантуємо коректне оброблення помилок і повторні спроби при збоях.

Ozon Seller API дозволяє повністю автоматизувати управління асортиментом і замовленнями — з документації Ozon.

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

Ozon має власне дерево категорій і обов'язкові атрибути для кожної. Отримуємо атрибути через POST /v3/category/attribute. Для категорії «Смартфони» це 30+ атрибутів: бренд, колір, об'єм пам'яті, ОС — частина обов'язкових. Значення беруться з довідників Ozon: не можна написати «red» — потрібен ID значення. Отримуємо ID через POST /v2/category/attribute/values. Маппінг: властивість інфоблоку Бітрікс (наприклад, PROP_COLOR = "Червоний") → ID атрибута Ozon (attribute_id: 10096) → ID значення (value_id: 61587). Цю таблицю ведемо як окрему сутність в Бітрікс — вона змінюється при додаванні нових категорій. Без правильного маппінгу товар може бути заблокований.

FBS: управління залишками та замовленнями

При схемі FBS (fulfillment by seller) ключовий цикл:

1. Оновлення залишків в Ozon з Бітрікс — кожні 5–15 хвилин.
2. Отримання нових замовлень з Ozon — опитування POST /v3/posting/fbs/list з фільтром status: awaiting_packaging.
3. Створення замовлення в Бітрікс, резервування товару.
4. Збірка, формування етикетки (метод POST /v2/posting/fbs/package-label).
5. Передача в Ozon акту про відвантаження.

Етикетки Ozon — PDF з 2D-баркодом. Друкуємо на принтері етикеток (Zebra, TSC) або звичайному принтері A4. Ми автоматизуємо цей процес, щоб ви не витрачали час на ручний друк.

Як уникнути oversell та розходження залишків?

Якщо інтеграція оновлює залишки рідше, ніж надходять замовлення, можливий oversell — продаж відсутнього товару. Для високооборотних товарів ми зменшуємо виставлений на Ozon залишок на 10–20% як буфер або збільшуємо частоту синхронізації до 5 хвилин. Також налаштовуємо автоматичне резервування в Бітрікс при отриманні замовлення з Ozon. Це знижує ризик розходжень до 1%.

Особливості для білоруських продавців

Білоруські продавці відвантажують на склади Ozon в Білорусі (Мінськ) або безпосередньо в пункти видачі. Логістика простіша та швидша, ніж відвантаження в Москву. Документообіг: при відвантаженні Ozon вимагає акт передачі в електронному вигляді. Для білоруських юросіб це накладна ТН-2. Дані для формування беремо із замовлення Ozon, генеруємо документ в Бітрікс або інтегрованій обліковій системі.

Повернення обробляються автоматично: Ozon створює повернення (refund або cancelled postings). Інтеграція відстежує події через POST /v3/returns/company/fbs, створює повернений документ в Бітрікс і повертає товар на залишки. Ми гарантуємо, що жодне повернення не буде втрачено.

Що входить в роботу з інтеграції?

Додатково надаємо:

• Доступи до налаштованих систем.
• Навчання ваших співробітників роботі з інтеграцією.
• Гарантійну підтримку 30 днів після запуску.
• Можливість розширення (додавання нових категорій, схем).

Типові проблеми та їх вирішення

Товар заблоковано Ozon. Часта причина — невідповідність атрибутів вимогам категорії. Статус перевіряємо через POST /v2/product/info (поле status.state_failed), читаємо status.validation_errors і коригуємо атрибути. Ми включаємо автоматичні сповіщення про блокування.

Розходження залишків. Вирішується буфером (10–20%) або частішою синхронізацією. Для точності використовуємо теговане кешування в Бітрікс — дані про замовлення оновлюються швидше.

Інтеграція через API Ozon у 5 разів швидша за ручне введення даних, а автоматизація зменшує кількість помилок на 80%.

Орієнтири за термінами

Вартість розраховується індивідуально після аудиту каталогу та схеми роботи (FBS/FBO). Отримайте консультацію — зв'яжіться з нами для оцінки вашого проєкту.

Як відбувається інтеграція 1С-Бітрікс з маркетплейсами

Менеджер вручну оновлює залишки на Ozon, а Wildberries продає товар, якого на складі немає. Клієнт отримує скасування, рейтинг падає, майданчик ріже покази. Втрати від оверстейтів на каталозі в 5 000 SKU сягають 15% замовлень щомісяця. Ми вирішуємо це автоматичною синхронізацією через API: замовлення потрапляють в Бітрікс, залишки та ціни оновлюються з єдиної адмінки. Наш досвід — 60+ проєктів з інтеграції, 5+ років на ринку. Гарантуємо, що після налаштування жоден товар не піде в мінус.

За даними Вікіпедії, 1С-Бітрікс використовується на понад 100 000 сайтів, що робить його найпоширенішою CMS для e-commerce в Україні. 70% онлайн-покупок проходять через маркетплейси. Товари з коректними залишками отримують вдвічі більше показів. Без автоматизації ви або втрачаєте продажі, або витрачаєте години на ручне оновлення. Ми пропонуємо інтеграцію під ключ — від аудиту каталогу до моніторингу. Оцінимо ваш проєкт за один день: замовте консультацію.

Стабільність підтверджуємо SLA: час реакції на збій — 2 години в робочий час. Використовуємо теговане кешування та агенти Бітрікса, щоб навантаження на сервер не зростало. Економія на ручній праці після інтеграції — до 40 годин на місяць, що еквівалентно 25% робочого часу менеджера. Окупність проєкту — 3-4 тижні.

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

Маркетплейси — готовий трафік, який один інтернет-магазин не збере. Більше половини онлайн-покупок — через майданчики. Вам залишається асортимент і ціни.

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

Як працює синхронізація залишків з Wildberries?

API постачальника WB вимагає оновлювати стоки на складах кожні 15-30 хвилин. Інакше залишки розходяться з сайтом, покупець оформлює замовлення на неіснуючий товар. Ми налаштовуємо агент Бітрікса: CAgent::AddAgent() з інтервалом 15 хвилин, який викликає /api/v3/stocks. Дані беруться з торговельного каталогу з урахуванням резервів.

Типова помилка: в Бітріксі залишок 10 одиниць, на WB стоїть 10, але 3 вже зарезервовані в замовленнях WB. Наш модуль віднімає резерв перед відправкою. Після інтеграції розбіжностей немає, рейтинг продавця зростає. 95% помилок синхронізації виявляються автоматично завдяки вбудованому контролю.

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

• 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), обробка замовлень та поставок, медіаконтент.
• Яндекс.Маркет — Partner API. Каталог через фід або push-модель, ціни, залишки, замовлення DBS/FBS/FBY (/campaigns/{campaignId}/orders), інтеграція з Яндекс.Доставкою.
• СберМегаМаркет — Merchant API. Товари, офери, замовлення, синхронізація статусів.
• Інші — AliExpress Росія, Авіто, галузеві майданчики (Lamoda, Leroy Merlin).

Чому пряма інтеграція вигідніша за агрегатори?

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

Агрегатори — RetailCRM, МойСклад, ApiShip — швидкий старт, але чорна скриня. Час реакції на збій через агрегатор — від 24 годин, у нас — 2 години. На highload-каталогах (10 000+ SKU) пряма робота через API втричі дешевша в довгостроковій підтримці, ніж щомісячна плата за агрегатор плюс втрата виручки від простоїв. Фіди (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С — документація з рекомендаціями.
• Розробка модуля інтеграції (на кожен маркетплейс) з вихідним кодом.
• Налаштування мапінгу категорій та властивостей.
• Конфігурація агентів та webhook’ів.
• Тестування в sandbox та на реальних даних.
• Навчання менеджерів роботі з єдиним потоком замовлень.
• Моніторинг протягом перших двох тижнів після запуску.
• Технічна підтримка та оновлення при змінах API майданчиків.

Які терміни інтеграції?

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