Інтеграція з маркетплейсом

Інтеграція з маркетплейсом — це автоматичний обмін даними між ERP, CRM, WMS, складом або K2 ERP і торговельним майданчиком, де компанія продає товари чи послуги. Така інтеграція дозволяє передавати на маркетплейс товари, ціни, залишки, характеристики, фото, статуси, а з маркетплейсу отримувати замовлення, оплати, доставки, повернення, рекламації, комісії та звіти.

Простіше кажучи, інтеграція з маркетплейсом потрібна, щоб продавець не переносив вручну сотні товарів, цін, залишків і замовлень між ERP та кабінетом продавця. Бо ручне оновлення залишків на маркетплейсі — це спорт для сильних духом і слабких систем.

Головне. ERP має бути джерелом правди для товарів, цін, залишків, собівартості, складів і обліку. Маркетплейс має бути каналом продажів. Інтеграція з’єднує ці два світи так, щоб продажі не перетворювалися на ручний хаос.

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

Що таке інтеграція з маркетплейсом

Інтеграція з маркетплейсом — це налаштований обмін даними між внутрішньою системою компанії та зовнішнім торговельним майданчиком.

Інтеграція відповідає на питання:

Які товари продавати на маркетплейсі?
Які ціни показувати?
Які залишки доступні?
Куди потрапляють замовлення?
Як резервується товар?
Як передається статус доставки?
Як обліковуються комісії маркетплейсу?
Як обробляються повернення?
Як фіксуються рекламації?
Як звірити виплати від маркетплейсу?

Типовий обмін:

ERP → Маркетплейс:
товари, ціни, залишки, фото, характеристики, статуси

Маркетплейс → ERP:
замовлення, клієнти, оплати, доставки, повернення, комісії, рекламації

Для чого потрібна інтеграція з маркетплейсом

Інтеграція потрібна для:

автоматичного вивантаження товарів;
оновлення цін;
оновлення залишків;
отримання замовлень;
резервування товарів;
передачі статусів замовлень;
створення ТТН або передачі номерів відправлень;
обробки оплат;
обліку комісій маркетплейсу;
контролю повернень;
обробки рекламацій;
звірки взаєморозрахунків із маркетплейсом;
аналізу прибутковості каналу;
зменшення ручної роботи;
зменшення помилок у цінах і залишках;
підключення Power BI-аналітики.

Без інтеграції продавець ризикує жити в режимі:

ERP каже: товару 0.
Маркетплейс каже: товар доступний.
Клієнт каже: я вже оплатив.
Менеджер каже: зараз щось придумаємо.
Бізнес каже: знову мінус репутація.

Що можна інтегрувати з маркетплейсом

Дані	Напрям	Приклад
Товари	ERP → Маркетплейс	Назва, артикул, опис, категорія
Характеристики	ERP → Маркетплейс	Розмір, колір, бренд, матеріал
Фото	ERP → Маркетплейс	Основне фото, галерея
Ціни	ERP → Маркетплейс	Роздрібна, акційна, промоціна
Залишки	ERP → Маркетплейс	Доступна кількість по складах
Замовлення	Маркетплейс → ERP	Нове замовлення клієнта
Оплати	Маркетплейс → ERP	Оплачено, очікує оплати, повернення коштів
Доставка	ERP ↔ Маркетплейс	ТТН, перевізник, статус відправлення
Статуси	ERP ↔ Маркетплейс	Прийнято, зібрано, відправлено, скасовано
Повернення	Маркетплейс → ERP	Повернення товару клієнтом
Рекламації	Маркетплейс → ERP	Претензія щодо якості або комплектації
Комісії	Маркетплейс → ERP	Комісія продажу, логістика, промо, штрафи
Звіти виплат	Маркетплейс → ERP	Суми до виплати продавцю

Основні сценарії інтеграції

Найчастіші сценарії:

ERP передає товари на маркетплейс;
ERP передає характеристики;
ERP передає фото;
ERP передає ціни;
ERP передає доступні залишки;
маркетплейс передає замовлення в ERP;
ERP резервує товар;
склад отримує задачу на відбір;
ERP передає статус збирання;
ERP або маркетплейс формує ТТН;
маркетплейс передає оплату;
маркетплейс передає комісію;
маркетплейс передає повернення;
ERP створює повернення товару;
ERP формує фінансову аналітику по каналу.

Інтеграція товарів

Товари можуть створюватися в ERP і передаватися на маркетплейс.

Передаються:

артикул;
SKU;
назва;
опис;
категорія;
бренд;
характеристики;
штрихкод;
одиниця виміру;
вага;
габарити;
країна виробництва;
гарантія;
фото;
сертифікати;
статус активності;
SEO-поля, якщо підтримуються;
правила публікації.

Приклад JSON товару:

{
  "sku": "ITEM-001",
  "barcode": "4820000000012",
  "name": "Фільтр повітряний F-20",
  "category": "Автотовари",
  "brand": "ExampleBrand",
  "unit": "шт",
  "weight": 0.35,
  "active": true
}

Мапінг категорій

Одна з найважливіших частин інтеграції — відповідність категорій ERP і маркетплейсу.

Приклад:

Категорія ERP	Категорія маркетплейсу	Коментар
Автотовари / Фільтри	Авто / Запчастини / Фільтри	Потрібно передавати бренд, модель, сумісність
Побутова хімія	Дім / Господарські товари	Потрібні об’єм і тип упаковки
Електроінструмент	Інструменти / Електроінструмент	Потрібні потужність, напруга, гарантія

Якщо товар потрапляє не в ту категорію, клієнт його не знаходить, маркетплейс може відхилити публікацію, а продавець потім дивується, чому “товар не продається”. Бо він, умовно кажучи, лежить у розділі шкарпеток замість запчастин.

Характеристики товарів

Маркетплейси часто вимагають заповнення характеристик.

Приклади:

бренд;
модель;
колір;
розмір;
матеріал;
вага;
габарити;
тип;
сумісність;
країна виробництва;
гарантійний строк;
технічні параметри;
склад;
сезонність;
комплектація.

Приклад:

{
  "sku": "ITEM-001",
  "attributes": {
    "brand": "ExampleBrand",
    "color": "black",
    "material": "plastic",
    "warranty_months": 12
  }
}

Характеристики краще вести структуровано в ERP, а не вільним текстом. Бо “чорний”, “чорн.”, “black” і “темний як ніч бухгалтера після інвентаризації” — для системи не одне й те саме.

Інтеграція фото

Маркетплейси часто мають вимоги до фото.

ERP або медіасховище може передавати:

головне фото;
додаткові фото;
фото упаковки;
фото сертифікатів;
інструкції;
відео, якщо підтримується;
порядок фото;
статус модерації.

Приклад:

{
  "sku": "ITEM-001",
  "images": [
    {
      "url": "https://example.com/images/item-001-main.jpg",
      "main": true
    },
    {
      "url": "https://example.com/images/item-001-2.jpg",
      "main": false
    }
  ]
}

Інтеграція цін

Ціни можуть передаватися з ERP на маркетплейс.

Типи цін:

базова;
акційна;
мінімальна;
рекомендована;
промоціна;
ціна для конкретного каналу;
ціна з урахуванням комісії;
ціна з урахуванням доставки;
ціна за регіоном;
ціна за валютою.

Приклад:

{
  "sku": "ITEM-001",
  "price": {
    "currency": "UAH",
    "regular": 1200.00,
    "promo": 1099.00,
    "promo_until": "2026-05-31"
  }
}

Ціноутворення для маркетплейсу

Ціна для маркетплейсу має враховувати не тільки собівартість і бажану маржу, а й додаткові витрати.

Враховуються:

собівартість;
комісія маркетплейсу;
логістика;
пакування;
еквайринг;
промо;
повернення;
рекламації;
штрафи;
податки;
бажана маржа.

Приклад:

Показник	Сума
Собівартість	700 грн
Комісія маркетплейсу	120 грн
Логістика	60 грн
Пакування	20 грн
Бажана маржа	200 грн
Мінімальна ціна	1 100 грн

Продати товар “з гарною знижкою” легко. Потім складніше пояснити, чому після комісії маркетплейсу й логістики прибуток схожий на декоративний елемент.

Інтеграція залишків

ERP або WMS має передавати на маркетплейс актуальні доступні залишки.

Важливо передавати:

фізичний залишок;
резерв;
доступний залишок;
склад;
очікуване надходження;
мінімальний запас;
статус “під замовлення”;
кількість, доступну для маркетплейсу;
буфер безпеки.

Формула:

Доступний залишок = Фізичний залишок - Резерв - Буфер

Приклад:

{
  "sku": "ITEM-001",
  "warehouse": "MAIN",
  "physical_stock": 20,
  "reserved": 5,
  "safety_buffer": 2,
  "available_for_marketplace": 13
}

Буфер залишків

Буфер потрібен, щоб не продати останню одиницю одночасно в кількох каналах.

Приклад:

Фізичний залишок: 10
Резерв: 3
Буфер: 2
На маркетплейс передаємо: 5

Буфер особливо важливий, якщо компанія продає одночасно:

у власному інтернет-магазині;
на кількох маркетплейсах;
через менеджерів;
у роздрібній точці;
через B2B-портал.

Без буфера останній товар може стати зіркою одразу п’яти замовлень. На жаль, товар про це не знає і фізично не розмножується.

Інтеграція замовлень

Замовлення з маркетплейсу має автоматично потрапляти в ERP.

Передаються:

номер замовлення маркетплейсу;
дата;
клієнт;
товари;
кількість;
ціни;
знижки;
комісії, якщо доступні;
спосіб доставки;
адреса;
статус оплати;
статус замовлення;
коментар;
промо;
склад відвантаження;
тип доставки.

Приклад:

{
  "marketplace_order_id": "MP-2026-000125",
  "created_at": "2026-05-16T12:30:00",
  "status": "new",
  "payment_status": "paid",
  "items": [
    {
      "sku": "ITEM-001",
      "quantity": 2,
      "price": 1099.00
    }
  ],
  "delivery": {
    "method": "marketplace_delivery",
    "city": "Київ"
  }
}

Обробка замовлення з маркетплейсу

Типовий процес:

Клієнт оформлює замовлення на маркетплейсі
  ↓
Маркетплейс передає замовлення в ERP
  ↓
ERP створює замовлення покупця
  ↓
ERP резервує товар
  ↓
Склад отримує задачу на відбір
  ↓
Товар комплектується і пакується
  ↓
Створюється доставка або ТТН
  ↓
ERP передає статус на маркетплейс
  ↓
Маркетплейс інформує клієнта

Статуси замовлення

Статуси потрібно синхронізувати між ERP і маркетплейсом.

Статус ERP	Статус маркетплейсу	Значення
Нове	New	Замовлення отримано
Підтверджено	Confirmed	Продавець прийняв замовлення
На відборі	Processing	Склад збирає товар
Запаковано	Packed	Товар готовий до відправки
Відвантажено	Shipped	Передано перевізнику
Доставлено	Delivered	Клієнт отримав товар
Скасовано	Cancelled	Замовлення скасовано
Повернення	Returned	Товар повернуто

Інтеграція доставки

Маркетплейс може мати власну доставку або передавати дані для доставки продавцю.

Передаються:

перевізник;
тип доставки;
адреса;
відділення;
отримувач;
телефон;
ТТН;
дата відправлення;
статус доставки;
вартість доставки;
хто оплачує доставку;
склад відвантаження.

Приклад:

{
  "marketplace_order_id": "MP-2026-000125",
  "carrier": "marketplace_logistics",
  "tracking_number": "TTN-20450000000000",
  "delivery_status": "shipped"
}

FBS, FBO і власна доставка

У маркетплейсах часто є різні моделі логістики.

Модель	Що означає	Особливість
FBS	Seller зберігає товар у себе і відправляє після замовлення	ERP має швидко резервувати і передавати статуси
FBO	Товар зберігається на складі маркетплейсу	Потрібен облік передачі товару на склад маркетплейсу
Власна доставка	Продавець сам організовує доставку	Потрібна інтеграція з перевізником
Dropshipping	Відправляє постачальник	Потрібна інтеграція з постачальником і контроль SLA

FBS

При FBS продавець сам зберігає товар і відвантажує замовлення після отримання з маркетплейсу.

Процес:

Маркетплейс → Замовлення → ERP → Резерв → Склад → Пакування → Відправка → Статус у маркетплейс

Ризики:

неактуальні залишки;
прострочення відвантаження;
помилки відбору;
неправильне пакування;
не переданий статус;
штрафи маркетплейсу.

FBO

При FBO товар передається на склад маркетплейсу, і маркетплейс сам виконує зберігання, відбір, пакування та доставку.

Потрібно обліковувати:

передачу товару на склад маркетплейсу;
залишки на складі маркетплейсу;
продажі;
повернення;
втрати;
комісії;
виплати;
звіти;
розбіжності.

Приклад:

ERP → Передача товару на склад маркетплейсу
Маркетплейс → Звіт про продажі
Маркетплейс → Звіт про залишки
Маркетплейс → Звіт про повернення
ERP → Фінансовий облік і аналітика

Інтеграція оплат

Маркетплейс може приймати оплату від клієнта і періодично виплачувати продавцю гроші за мінусом комісій.

Потрібно обліковувати:

суму продажу;
суму до виплати;
комісію маркетплейсу;
логістику;
промо;
штрафи;
повернення;
компенсації;
утримання;
дату виплати;
платіж;
акт або звіт маркетплейсу.

Приклад:

Показник	Сума
Сума продажу	10 000 грн
Комісія маркетплейсу	-1 200 грн
Логістика	-500 грн
Промо	-300 грн
До виплати	8 000 грн

Комісії маркетплейсу

Комісії потрібно враховувати у фінансовому результаті.

Типи комісій:

комісія за продаж;
комісія за категорію;
логістична комісія;
комісія за зберігання;
комісія за повернення;
комісія за просування;
еквайринг;
штраф;
абонплата;
плата за участь в акції.

Приклад:

{
  "marketplace_order_id": "MP-2026-000125",
  "gross_amount": 2198.00,
  "commission": 263.76,
  "logistics_fee": 80.00,
  "promo_fee": 50.00,
  "net_payout": 1804.24
}

Комісії — це не “десь там маркетплейс забрав”. Це реальна витрата, яка має потрапити в P&L. Інакше маржа виглядає гарно тільки до першої звірки.

Звірка з маркетплейсом

Звірка потрібна, щоб перевірити продажі, повернення, комісії та виплати.

Звіряються:

замовлення;
суми продажів;
повернення;
скасування;
комісії;
штрафи;
логістика;
промо;
виплати;
залишки;
компенсації;
акти або звіти маркетплейсу.

Приклад:

ERP: продажів за період — 500 000 грн
Маркетплейс: продажів — 498 000 грн
Різниця: 2 000 грн
Причина: одне повернення відображене в маркетплейсі, але не проведене в ERP

Повернення з маркетплейсу

Повернення потрібно автоматично або напівавтоматично передавати в ERP.

Передаються:

номер замовлення;
товар;
кількість;
причина повернення;
стан товару;
дата;
статус;
фото, якщо є;
сума повернення;
склад повернення;
рішення: в продаж, ремонт, брак, списання.

Приклад:

{
  "return_id": "RET-MP-00125",
  "marketplace_order_id": "MP-2026-000125",
  "sku": "ITEM-001",
  "quantity": 1,
  "reason": "customer_return",
  "condition": "opened_package",
  "status": "received"
}

Рекламації з маркетплейсу

Клієнт може створити претензію через маркетплейс.

Причини:

товар пошкоджений;
не той товар;
некомплект;
брак;
затримка доставки;
товар не відповідає опису;
гарантійна проблема;
помилка документів.

ERP має створити рекламацію і пов’язати її з:

замовленням;
товаром;
партією;
клієнтом;
складом;
відвантаженням;
доставкою;
відповідальним;
витратами;
рішенням.

Рейтинг продавця

Маркетплейси часто оцінюють продавців за якістю виконання.

Показники:

швидкість підтвердження замовлень;
швидкість відвантаження;
частка скасувань;
частка прострочень;
частка повернень;
кількість рекламацій;
рейтинг клієнтів;
відповіді на питання;
наявність товару;
якість контенту;
порушення правил маркетплейсу.

Інтеграція допомагає зменшити прострочення і помилки, а отже — захистити рейтинг. Бо рейтинг продавця падає швидше, ніж команда встигає сказати: “А хто мав оновити залишки?”

API маркетплейсу

API маркетплейсу — це інтерфейс, через який ERP і маркетплейс обмінюються даними.

API може підтримувати:

створення товарів;
оновлення товарів;
оновлення цін;
оновлення залишків;
отримання замовлень;
підтвердження замовлень;
передачу статусів;
передачу ТТН;
отримання повернень;
отримання звітів;
отримання комісій;
отримання виплат.

Приклад запиту:

GET /api/orders?status=new
Authorization: Bearer token

Приклад відповіді:

{
  "orders": [
    {
      "marketplace_order_id": "MP-2026-000125",
      "status": "new",
      "created_at": "2026-05-16T12:30:00"
    }
  ]
}

Webhooks маркетплейсу

Webhook дозволяє маркетплейсу надсилати події в ERP.

Приклади подій:

створено замовлення;
замовлення оплачено;
замовлення скасовано;
створено повернення;
змінено статус доставки;
створено рекламацію;
оновлено виплату;
товар відхилено модерацією.

Приклад webhook:

{
  "event": "order.created",
  "marketplace_order_id": "MP-2026-000125",
  "created_at": "2026-05-16T12:30:00"
}

Webhook зручний тим, що ERP не мусить кожну хвилину питати маркетплейс: “Ну що, є щось нове?”. Маркетплейс сам каже, коли щось сталося.

Файловий обмін із маркетплейсом

Деякі маркетплейси або проміжні сервіси підтримують файловий обмін.

Формати:

CSV;
XLSX;
XML;
JSON;
YML;
TXT.

Приклад CSV:

sku,name,price,stock
ITEM-001,Фільтр F-20,1099,13
ITEM-002,Насос NP-100,2500,5

Файловий обмін простіший, але має обмеження:

затримки;
помилки формату;
слабша обробка помилок;
складніше відстежувати статуси;
ризик застарілих залишків;
складніше працювати з поверненнями й комісіями.

Middleware для маркетплейсів

Якщо маркетплейсів багато, може використовуватися проміжний сервіс — middleware.

Схема:

K2 ERP → Middleware → Маркетплейс 1
                  → Маркетплейс 2
                  → Маркетплейс 3

Middleware може:

уніфікувати формати;
мапити категорії;
розподіляти залишки;
збирати замовлення;
передавати статуси;
нормалізувати помилки;
зменшити кількість окремих інтеграцій;
вести централізовані логи.

Ризик middleware: з’являється ще одна система, яка може все спростити або, при поганому налаштуванні, стати ще одним місцем, де “щось не дійшло”.

Джерело правди

Для кожного типу даних потрібно визначити джерело правди.

Дані	Джерело правди
Номенклатура	ERP
Собівартість	ERP
Ціни	ERP або pricing-модуль
Залишки	ERP / WMS
Замовлення	Маркетплейс створює, ERP обробляє
Статуси складу	ERP / WMS
Статуси доставки	ERP або маркетплейс
Комісії	Маркетплейс
Фінансовий результат	ERP / BI

Без джерела правди інтеграція швидко стає дипломатичним конфліктом між системами. І всі системи, звичайно, “не винні”.

Логування інтеграції

Логи мають фіксувати всі обміни.

Лог має містити:

дату і час;
маркетплейс;
напрям обміну;
тип об’єкта;
external ID;
ERP ID;
endpoint;
статус;
текст помилки;
повторні спроби;
payload або безпечну частину;
час відповіді;
відповідального.

Приклад:

Час	Подія	Статус	Коментар
16.05.2026 12:31	Отримання замовлення MP-125	OK	Створено SO-2026-00125
16.05.2026 12:35	Оновлення залишку ITEM-001	Error	Невірний токен API

Без логів інтеграція схожа на магію. А коли магія ламається, всі стають детективами без доказів.

Обробка помилок

Типові помилки:

товар не пройшов модерацію;
неправильна категорія;
відсутня обов’язкова характеристика;
неправильний формат ціни;
залишок не оновився;
замовлення вже існує;
API недоступний;
токен прострочений;
timeout;
неправильний статус;
немає відповідності SKU;
дубль клієнта;
повернення не знайдено;
звіт комісій не завантажився.

Система має:

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

Унікальні ідентифікатори

Для інтеграції потрібні стабільні ID.

Приклади:

marketplace_order_id;
erp_order_id;
sku;
external_product_id;
marketplace_product_id;
return_id;
payout_id;
transaction_id;
shipment_id;
claim_id.

Приклад:

{
  "marketplace_order_id": "MP-2026-000125",
  "erp_order_id": "SO-2026-00125"
}

Без ID замовлення починають дублюватися, товари — плутатися, а звірка стає жанром психологічної драми.

Безпека інтеграції

Потрібно контролювати:

HTTPS;
API-ключі;
токени;
IP whitelist;
ролі доступу;
обмеження методів API;
термін дії токенів;
підпис webhook;
rate limiting;
логування;
шифрування чутливих даних;
захист персональних даних;
розмежування доступу між маркетплейсами;
моніторинг підозрілих запитів.

API не повинен мати надмірні права. Якщо інтеграції для оновлення залишків дали право видаляти документи, це не довіра, а сценарій для дуже сумного інциденту.

Інтеграція з маркетплейсом у K2 ERP

У K2 ERP інтеграція з маркетплейсом може бути частиною контуру продажів, складу, фінансів, CRM, доставки, рекламацій і аналітики.

Можливості:

вивантаження товарів;
мапінг категорій;
передача характеристик;
передача фото;
передача цін;
передача залишків;
буфери залишків;
отримання замовлень;
резервування товару;
задачі складу на відбір;
передача статусів;
інтеграція з доставкою;
облік оплат;
облік комісій;
облік повернень;
облік рекламацій;
звірка виплат;
логування обміну;
audit log;
права доступу;
API;
Power BI-аналітика.

Приклад процесу:

K2 ERP передає товари, ціни і залишки на маркетплейс
  ↓
Клієнт оформлює замовлення
  ↓
Маркетплейс передає замовлення в K2 ERP
  ↓
K2 ERP створює замовлення покупця
  ↓
Товар резервується
  ↓
Склад збирає відправлення
  ↓
Статус і ТТН передаються на маркетплейс
  ↓
Маркетплейс передає звіт про комісії і виплату
  ↓
Power BI показує прибутковість каналу

Power BI для маркетплейсів

Power BI допомагає аналізувати продажі через маркетплейси.

Корисні дашборди:

продажі по маркетплейсах;
продажі по товарах;
маржа з урахуванням комісій;
топ товарів;
товари з низькою маржею;
залишки;
повернення;
рекламації;
комісії;
логістичні витрати;
штрафи;
виплати;
прострочені відвантаження;
рейтинг продавця;
помилки інтеграції;
динаміка замовлень;
прибутковість каналів.

Приклад:

Показник	Значення
Замовлень за місяць	4 820
Продажі	6 400 000 грн
Комісії маркетплейсів	720 000 грн
Логістика	310 000 грн
Повернення	186
Рекламації	42
Маржа після комісій	18,4%

Права доступу

Доступи потрібно обмежувати.

Роль	Доступ
Менеджер маркетплейсу	Товари, ціни, статуси, замовлення свого каналу
Склад	Замовлення на відбір, пакування, відвантаження
Фінанси	Комісії, виплати, звірка, фінансовий результат
Контроль якості	Повернення і рекламації
Адміністратор інтеграції	Логи, налаштування, повторний обмін
Керівник	Аналітика, KPI, проблемні товари і канали

Audit log інтеграції з маркетплейсом

Audit log має фіксувати:

хто змінив API-ключ;
хто змінив мапінг категорій;
хто змінив правило ціноутворення;
хто змінив буфер залишків;
хто повторив обмін;
хто змінив статус замовлення;
хто скасував замовлення;
хто змінив склад відвантаження;
хто змінив правила комісій;
хто змінив права інтеграції.

Audit log потрібен, щоб зміни в інтеграції не були “хтось щось перемкнув, і тепер маркетплейс продає старі ціни”.

KPI інтеграції з маркетплейсом

Корисні KPI:

кількість замовлень;
сума продажів;
маржа після комісій;
частка помилок інтеграції;
час передачі замовлення в ERP;
час підтвердження замовлення;
час відвантаження;
частка прострочених відвантажень;
частка скасувань;
частка повернень;
кількість рекламацій;
частка товарів із неактуальними залишками;
кількість товарів, відхилених модерацією;
точність звірки виплат;
рейтинг продавця;
SLA обробки замовлень.

Типові помилки інтеграції з маркетплейсом

Помилка	Причина	Наслідок
Продається товар без залишку	Передається фізичний залишок без резерву	Скасування і поганий рейтинг
Немає буфера	Один залишок продається в кількох каналах	Подвійні продажі
Немає мапінгу категорій	Категорії ERP і маркетплейсу не узгоджені	Товари не проходять модерацію
Немає характеристик	Дані ведуться в описі, а не структурно	Товари погано шукаються
Не враховуються комісії	Аналізують тільки ціну продажу	Маржа завищена
Немає логів	Обмін непрозорий	Помилки важко знайти
Замовлення дублюються	Немає external ID	Подвійна обробка
Немає звірки виплат	Не завантажуються звіти маркетплейсу	Фінансові розбіжності

Помилка: не врахували комісію

Погано:

Ціна продажу: 1 000 грн
Собівартість: 800 грн
“Прибуток”: 200 грн

Краще:

Ціна продажу: 1 000 грн
Собівартість: 800 грн
Комісія маркетплейсу: 120 грн
Логістика: 50 грн
Пакування: 20 грн
Фактичний прибуток: 10 грн

Так, це той момент, коли “гарні продажі” раптом перетворюються на дуже активне перенесення грошей із кишені в маркетплейс.

Помилка: залишки оновлюються раз на день

Якщо товар швидко продається, оновлення залишків раз на день може бути небезпечним.

Погано:

09:00 — на маркетплейс передали 20 шт.
11:00 — 20 шт. продали через інший канал.
15:00 — маркетплейс усе ще показує 20 шт.
16:00 — клієнти купують товар, якого вже немає.

Краще:

Оновлювати залишки часто або за подією:
резерв → продаж → повернення → списання → оновлення маркетплейсу.

Помилка: товари не проходять модерацію

Причини:

неправильна категорія;
відсутні обов’язкові характеристики;
погані фото;
заборонені слова в описі;
неправильний бренд;
некоректний штрихкод;
дубль товару;
невідповідність правилам маркетплейсу.

Рішення:

вести характеристики структуровано;
мати мапінг категорій;
перевіряти обов’язкові поля;
логувати помилки модерації;
створити відповідального за контент;
автоматично показувати товари з помилками.

Помилка: немає звірки виплат

Маркетплейс може утримувати комісії, штрафи, логістику, повернення і промо.

Погано:

Маркетплейс перерахував гроші.
Фінанси просто зарахували суму.
Ніхто не перевірив, з чого вона складається.

Краще:

Завантажити звіт маркетплейсу:
- продажі;
- комісії;
- повернення;
- логістика;
- штрафи;
- сума до виплати.
Звірити з ERP.

Автоматизація інтеграції з маркетплейсом

Автоматизація допомагає:

швидко публікувати товари;
оновлювати ціни;
оновлювати залишки;
отримувати замовлення;
резервувати товар;
контролювати SLA відвантаження;
передавати статуси;
обліковувати комісії;
обробляти повернення;
створювати рекламації;
звіряти виплати;
аналізувати маржу;
контролювати помилки;
захищати рейтинг продавця.

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

{
  "sku": "ITEM-001",
  "name": "Фільтр повітряний F-20",
  "category_id": "AUTO_FILTERS",
  "brand": "ExampleBrand",
  "barcode": "4820000000012",
  "description": "Фільтр повітряний для легкових автомобілів",
  "price": 1099.00,
  "currency": "UAH",
  "stock": 13,
  "attributes": {
    "material": "paper",
    "warranty_months": 12
  },
  "images": [
    "https://example.com/item-001-main.jpg"
  ]
}

Приклад JSON замовлення з маркетплейсу

{
  "marketplace": "example_marketplace",
  "marketplace_order_id": "MP-2026-000125",
  "created_at": "2026-05-16T12:30:00",
  "status": "new",
  "payment_status": "paid",
  "items": [
    {
      "sku": "ITEM-001",
      "quantity": 2,
      "price": 1099.00
    }
  ],
  "delivery": {
    "type": "fbs",
    "carrier": "marketplace_logistics",
    "city": "Київ"
  }
}

Приклад JSON звіту комісій

{
  "marketplace_order_id": "MP-2026-000125",
  "gross_amount": 2198.00,
  "fees": [
    {
      "type": "sales_commission",
      "amount": 263.76
    },
    {
      "type": "logistics",
      "amount": 80.00
    },
    {
      "type": "promotion",
      "amount": 50.00
    }
  ],
  "net_payout": 1804.24,
  "currency": "UAH"
}

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

Визначено маркетплейси.
Описано сценарії обміну.
Визначено джерело правди.
Налаштовано товари.
Налаштовано мапінг категорій.
Налаштовано характеристики.
Налаштовано фото.
Налаштовано ціни.
Налаштовано залишки.
Налаштовано буфери залишків.
Налаштовано отримання замовлень.
Налаштовано резервування.
Налаштовано статуси.
Налаштовано доставку.
Налаштовано повернення.
Налаштовано рекламації.
Налаштовано облік комісій.
Налаштовано звірку виплат.
Є унікальні ID.
Є логування.
Є повторна відправка.
Є моніторинг.
Є права доступу.
Є audit log.
Є Power BI-аналітика.

Типові питання

Що таке інтеграція з маркетплейсом?

Інтеграція з маркетплейсом — це автоматичний обмін даними між ERP або іншою внутрішньою системою компанії та торговельним майданчиком.

Які дані найчастіше інтегрують?

Найчастіше інтегрують товари, характеристики, фото, ціни, залишки, замовлення, статуси, доставку, повернення, рекламації, комісії та виплати.

Чому важливо передавати доступний залишок?

Бо фізичний залишок може бути частково зарезервований під інші замовлення. Якщо передавати фізичний залишок без резервів і буфера, можна продати товар, якого фактично вже немає.

Навіщо враховувати комісії маркетплейсу?

Щоб бачити реальну маржу. Продаж може виглядати прибутковим до того моменту, поки не врахувати комісію, логістику, промо, повернення і штрафи.

Що таке FBS і FBO?

FBS — товар зберігається у продавця, а після замовлення продавець його відвантажує. FBO — товар зберігається на складі маркетплейсу, і маркетплейс сам виконує логістику.

Чому потрібна звірка з маркетплейсом?

Щоб перевірити продажі, повернення, комісії, штрафи, логістику і фактичні виплати. Без звірки фінансовий результат по маркетплейсу може бути неточним.

Коротко

Питання	Відповідь
Що це?	Автоматичний обмін даними між ERP і маркетплейсом.
Основні дані	Товари, ціни, залишки, замовлення, доставка, повернення, комісії, виплати.
Головний принцип	ERP — джерело правди для обліку, маркетплейс — канал продажів.
Основні ризики	Продаж без залишку, неактуальні ціни, дублікати, невраховані комісії.
Найкраща практика	API, буфери залишків, логування, звірка виплат, Power BI, audit log і контроль SLA.

Висновок

Інтеграція з маркетплейсом — це важлива частина сучасної електронної комерції. Вона дозволяє автоматично керувати товарами, цінами, залишками, замовленнями, доставкою, поверненнями, рекламаціями, комісіями та виплатами.

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

Хороша інтеграція з маркетплейсом — це коли товар автоматично публікується, залишки актуальні, замовлення потрапляють в ERP, склад швидко відвантажує, комісії враховані, а фінансовий результат не виглядає як сюрприз після звіту маркетплейсу.

У сучасній ERP, зокрема в K2 ERP, інтеграція з маркетплейсом має бути пов’язана з товарами, категоріями, характеристиками, цінами, залишками, складами, замовленнями, доставкою, поверненнями, рекламаціями, комісіями, виплатами, API, webhooks, логами, audit log, правами доступу і Power BI. Тоді маркетплейс стає не окремим хаотичним каналом, а керованою частиною продажів.

Див. також

Зовнішні посилання