Перейти до вмісту

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

Матеріал з K2 ERP Wiki

"regular": 1200.00,

}

Фактичний прибуток: 10 грн

Ризики:

</syntaxhighlight> 

}
"status": "new",

"active": true

Простіше кажучи, інтеграційні функції ERP з маркетплейсом потрібна, щоб продавець не переносив вручну сотні товарів, цін, залишків і замовлень між ERP та кабінетом продавця. Маркетплейс має бути каналом продажів. "currency": "UAH",
Найчастіші сценарії:
{
У [[K2 ERP]] інтеграційні функції ERP з маркетплейсом здатна бути частиною контуру продажів, складу, фінансів, CRM, доставки, рекламацій і аналітики. |-
| Найкраща практика
| API, буфери залишків, логування, звірка виплат, Power BI, audit log і контроль SLA. |-
| провідний принцип
| ERP — джерело правди для обліку, маркетплейс — канал продажів. Буфер: 2

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

16:00 — клієнти купують товар, якого вже немає. "weight": 0.35,
__TOC__
{{DISPLAYTITLE:Інтеграція з маркетплейсом}}

[[Категорія:Webhooks]]

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

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

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

- продажі та реалізація; ! }, 

{

"marketplace_order_id": "MP-2026-000125",

Звірка потрібна, щоб перевірити продажі та реалізація, повернення, комісії та виплати. І всі системи, звичайно, “не винні”. Причина

</syntaxhighlight>

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

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

</syntaxhighlight>

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

через інтеграційні функції ERP користувачі можуть зменшити прострочення і помилки, а отже — захистити рейтинг. Без інтеграції продавець ризикує жити в режимі: Погано: { ! ! Одна з найважливіших частин інтеграції — відповідність категорій ERP і маркетплейсу. Коментар 

"sku": "ITEM-001",

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

Статуси потрібно синхронізувати між ERP і маркетплейсом. {| class="wikitable" style="width:100%;"

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

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

Доступи потрібно обмежувати.== Приклад JSON замовлення з маркетплейсу ==

 "marketplace_order_id": "MP-2026-000125",

 {

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

"currency": "UAH",

ERP створює замовлення покупця Маркетплейс каже: товар доступний.</syntaxhighlight> ! # Налаштовано залишки. K2 ERP передає товари, ціни і залишки на маркетплейс } } 

"physical_stock": 20,
↓
"items": [ Приклад: { sku,name,price,stock
}

Без логів інтеграційні функції ERP схожа на магію. } 

{

Маркетплейс інформує клієнта Приклад: 

 "marketplace_order_id": "MP-2026-000125",
 "sku": "ITEM-001",

- логістика; Маркетплейси часто вимагають заповнення характеристик.=== Що таке інтеграційні функції ERP з маркетплейсом? ===

функції ERP:

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

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

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

"barcode": "4820000000012",

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

</syntaxhighlight> 
]

} </syntaxhighlight>

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

Краще: 

[[Категорія:Замовлення покупця]]

{| class="wikitable" style="width:100%;"

{

* базова;
* акційна;
* мінімальна;
* рекомендована;
* промоціна;
* ціна для конкретного каналу;
* ціна з урахуванням комісії;
* ціна з урахуванням доставки;
* ціна за регіоном;
* ціна за валютою. Без нього хтось бігає з папірцем і дуже старається не продати те, чого вже немає.== Безпека інтеграції ==
Логістика: 50 грн
Приклади:
Товар резервується
клієнт ERP здатна створити претензію через маркетплейс. # виступає як моніторинг. {

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

складський облік отримує задачу на відбір
! Особливість
<syntaxhighlight lang="text">
<syntaxhighlight lang="text">
[[Категорія:ТТН]]

 "amount": 263.76

Які ціни показувати?== інтеграційні функції ERP з маркетплейсом у K2 ERP ==

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

Пакування: 20 грн

ERP → Фінансовий обліковий облік і аналітичні інструменти

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

Статус і ТТН передаються на маркетплейс

Приклад:

[[Категорія:HTTP-сервіси]]

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

"status": "received"

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

інтеграційні функції ERP оплат

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

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

{

інтеграційні функції ERP залишків

Як резервується товар? Деякі маркетплейси або проміжні сервіси підтримують файловий обмін.</syntaxhighlight>

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

"quantity": 2,

ERP або WMS має передавати на маркетплейс актуальні доступні залишки. Куди потрапляють замовлення? # виступає як повторна відправка. * у власному інтернет-магазині;

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

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

"material": "plastic",

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

Authorization: Bearer token 

"brand": "ExampleBrand",

</syntaxhighlight> 

}
|-
| Менеджер маркетплейсу
| Товари, ціни, статуси, замовлення свого каналу
|-
| складський облік
| Замовлення на відбір, пакування, відвантаження
|-
| фінансовий блок
| Комісії, виплати, звірка, фінансовий результат
|-
| Контроль якості
| Повернення і рекламації
|-
| Адміністратор інтеграції
| Логи, конфігурація, повторний обмін
|-
| Керівник
| аналітичні інструменти, KPI, проблемні товари і канали
|}

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

 ]

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

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

* кількість замовлень;
* сума продажів;
* маржа після комісій;
* частка помилок інтеграції;
* час передачі замовлення в ERP;
* час підтвердження замовлення;
* час відвантаження;
* частка прострочених відвантажень;
* частка скасувань;
* частка повернень;
* кількість рекламацій;
* частка товарів із неактуальними залишками;
* кількість товарів, відхилених модерацією;
* точність звірки виплат;
* рейтинг продавця;
* SLA обробки замовлень. Така інтеграційні функції ERP дає можливість передавати на маркетплейс товари, ціни, залишки, характеристики, фото, статуси, а з маркетплейсу отримувати замовлення, оплати, доставки, повернення, рекламації, комісії і звіти. Приклад
Файловий обмін простіший, але має обмеження:
<syntaxhighlight lang="json">
ITEM-001,Фільтр F-20,1099,13
{| class="wikitable" style="width:100%;"
<syntaxhighlight lang="text">

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

"sku": "ITEM-001",

"type": "fbs",

"gross_amount": 2198.00,

- сума до виплати. Це реальна витрата, яка має потрапити в P&L. Час

ERP резервує товар </syntaxhighlight> 

Audit log потрібен, щоб зміни в інтеграції не були “хтось щось перемкнув, і тепер маркетплейс продає старі ціни”. Категорія маркетплейсу
Які залишки доступні?<syntaxhighlight lang="json">

* вести характеристики структуровано;
* мати мапінг категорій;
* перевіряти обов’язкові поля;
* логувати помилки модерації;
* створити відповідального за контент;
* автоматизовано показувати товари з помилками.</div>
== Що можна інтегрувати з маркетплейсом ==
Маркетплейс → Замовлення → ERP → Резерв → складський облік → Пакування → Відправка → Статус у маркетплейс
=== Навіщо враховувати комісії маркетплейсу? ===

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

}

{

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

Коротко

↓

Приклад: 

"attributes": {
"price": 1099.00,

Причина: одне повернення відображене в маркетплейсі, але не проведене в ERP

  • затримки;
  • помилки формату;
  • слабша обробка помилок;
  • складніше відстежувати статуси;
  • ризик застарілих залишків;
  • складніше працювати з поверненнями й комісіями.
    - штрафи;
Формати:
інтеграційні функції ERP відповідає на питання:
  1. Визначено маркетплейси.
"promo_fee": 50.00,

Ціна для маркетплейсу має враховувати не тільки собівартість і бажану маржу, а й додаткові витрати.== Помилка: не врахували комісію == Так, це той момент, коли “гарні продажі та реалізація” раптом перетворюються на дуже активне перенесення грошей із кишені в маркетплейс. Для кожного типу даних потрібно визначити джерело правди. # Налаштовано обліковий облік комісій. Завантажити звіт маркетплейсу: 

"gross_amount": 2198.00,
  • створення товарів;
  • оновлення версій товарів;
  • оновлення версій цін;
  • оновлення версій залишків;
  • отримання замовлень;
  • підтвердження замовлень;
  • передачу статусів;
  • передачу ТТН;
  • отримання повернень;
  • отримання звітів;
  • отримання комісій;
  • отримання виплат. |-

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

"brand": "ExampleBrand",

[[Категорія:Буфер залишків]]

товари, ціни, залишки, фото, характеристики, статуси

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

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

K2 ERP створює замовлення покупця

* бренд;
* модель;
* колір;
* розмір;
* матеріал;
* вага;
* габарити;
* тип;
* сумісність;
* країна виробництва;
* гарантійний строк;
* технічні параметри;
* складський облік;
* сезонність;
* комплектація.[[Категорія:Інтеграція з маркетплейсом]]
 "main": false
 → Маркетплейс 2

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

 "reason": "customer_return",

== інтеграційні функції ERP товарів ==

* суму продажу;
* суму до виплати;
* комісію маркетплейсу;
* логістику;
* промо;
* штрафи;
* повернення;
* компенсації;
* утримання;
* дату виплати;
* платіж;
* акт або звіт маркетплейсу. * товар не пройшов модерацію;
* неправильна категорія;
* відсутня обов’язкова характеристика;
* неправильний формат ціни;
* залишок не оновився;
* замовлення вже існує;
* API недоступний;
* токен прострочений;
* timeout;
* неправильний статус;
* немає відповідності SKU;
* дубль клієнта;
* повернення не знайдено;
* звіт комісій не завантажився. ↓
[[Категорія:K2 ERP]]
 "marketplace_order_id": "MP-2026-000125",
[[Категорія:E-commerce]]
== Помилка: товари не проходять модерацію ==
 "status": "new",
== інтеграційні функції ERP цін ==

 "marketplace_order_id": "MP-2026-000125",

Як фіксуються рекламації? → Маркетплейс 3
 "fees": [
Приклад:
{| class="wikitable" style="width:100%;"
== Помилка: немає звірки виплат ==
 },
Типи цін:
[[Категорія:XML]]
 ↓
Собівартість: 800 грн
ERP або медіасховище здатна передавати:
Фізичний залишок: 10
Передаються:

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

Приклад CSV: </syntaxhighlight> “Прибуток”: 200 грн Корисні KPI: фінансовий блок без зусиль зарахували суму. Сума Приклад webhook: 

"url": "https://example.com/images/item-001-main.jpg",

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

== Див. так само ==

<syntaxhighlight lang="json">

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

 "sku": "ITEM-001",

! |- | Що це? Що означає

</syntaxhighlight> 

09:00 — на маркетплейс передали 20 шт.

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

Маркетплейс здатна утримувати комісії, штрафи, логістику, повернення і промо. # Налаштовано ціни.
 "price": 1099.00
 "available_for_marketplace": 13
Як обробляються повернення? # виступає як логування. Роль
Приклад:
Схема:
<syntaxhighlight lang="text">

[[Категорія:Інтернет-магазин]]

 "name": "Фільтр повітряний F-20",

! Подія
Маркетплейс: продажів — 498 000 грн

Комісія маркетплейсу: 120 грн

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

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

 "price": {
 "tracking_number": "TTN-20450000000000",
 ↓

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

Оновлювати залишки часто або за подією: 

"marketplace_order_id": "MP-2026-000125",

{ 

"marketplace_order_id": "MP-2026-000125",
"marketplace_order_id": "MP-2026-000125",

</syntaxhighlight> - комісії; 

{

Причини: Ціна продажу: 1 000 грн Краще: 

"net_payout": 1804.24

Для інтеграції потрібні стабільні ID. # Налаштовано фото.== FBS ==

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

 "color": "black",

ERP передає статус на маркетплейс

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

 "created_at": "2026-05-16T12:30:00"
Audit log має фіксувати:
 "items": [
<syntaxhighlight lang="text">
 "currency": "UAH"
Комісії — це не “десь там маркетплейс забрав”. {

'''інтеграційні функції ERP з маркетплейсом''' — це важлива частина сучасної електронної комерції. Бо ручне оновлення версій залишків на маркетплейсі — це спорт для сильних духом і слабких систем. Показник
 {
 "carrier": "marketplace_logistics",

Якщо товар оперативно продається, оновлення версій залишків раз на день здатна бути небезпечним. "net_payout": 1804.24,
Собівартість: 800 грн
Приклад:
== Звірка з маркетплейсом ==
Логи мають фіксувати всі обміни. # Описано сценарії обміну. інформаційні дані
 "city": "Київ"
Менеджер каже: зараз щось придумаємо. Наслідок

* ERP передає товари на маркетплейс;
* ERP передає характеристики;
* ERP передає фото;
* ERP передає ціни;
* ERP передає доступні залишки;
* маркетплейс передає замовлення в ERP;
* ERP резервує товар;
* складський облік отримує задачу на відбір;
* ERP передає статус збирання;
* ERP або маркетплейс формує ТТН;
* маркетплейс передає оплату;
* маркетплейс передає комісію;
* маркетплейс передає повернення;
* ERP створює повернення товару;
* ERP формує фінансову аналітику по каналу. А коли магія ламається, всі стають детективами без доказів. Показник
Продати товар “з гарною знижкою” швидко. Напрям
Як передається статус доставки? "condition": "opened_package",

</syntaxhighlight>

  • головне фото;
  • додаткові фото;
  • фото упаковки;
  • фото сертифікатів;
  • інструкції;
  • відео, якщо підтримується;
  • порядок фото;
  • статус модерації. Джерело правди
↓
"url": "https://example.com/images/item-001-2.jpg",

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

"price": 1099.00
"orders": [

Webhook зручний тим, що ERP не мусить кожну хвилину питати маркетплейс: “Ну що, виступає як щось нове?”. # Налаштовано рекламації. ERP — це ваш складський облік, бухгалтерський обліковий облік, ціни, закупівельна діяльність, фінансовий блок й залишки. ↓ 

↓

Маркетплейс → Звіт про залишки

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

],
"carrier": "marketplace_logistics",

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

 "stock": 13,

 "payment_status": "paid",

!<syntaxhighlight lang="json">

 "warranty_months": 12
товарів забезпечується через '''Головне.''' ERP має бути джерелом правди; так само реалізовано цін, залишків, собівартості, складів і обліку. Якщо інтеграції для оновлення версій залишків дали право видаляти документи, це не довіра, а сценарій для дуже сумного інциденту. "delivery": {

Приклад:
[[Категорія:FBS]]
Повернення потрібно автоматизовано або напівавтоматично передавати в ERP. Продаж здатна виглядати прибутковим до того моменту, поки не врахувати комісію, логістику, промо, повернення і штрафи. {| class="wikitable" style="width:100%;"

Окремо варто відзначити CRM, WMS, складом або [[K2 ERP]] і торговельним майданчиком, де компанія-користувач продає товари чи послуги виступає ключовою рисою '''інтеграційні функції ERP з маркетплейсом'''. !== FBO ==

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

11:00 — 20 шт. ↓
Як звірити виплати від маркетплейсу? * marketplace_order_id;
* erp_order_id;
* sku;
* external_product_id;
* marketplace_product_id;
* return_id;
* payout_id;
* transaction_id;
* shipment_id;
* claim_id. ! }

[[Категорія:K2 Cloud ERP]]
Потрібно обліковувати:
 "delivery_status": "shipped"
критично передавати:
K2 ERP → Middleware → Маркетплейс 1
Ніхто не перевірив, з чого вона складається.[[Категорія:Повернення товарів]]

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

 "logistics_fee": 80.00,

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

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

!== Webhooks маркетплейсу ==
Різниця: 2 000 грн
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
<syntaxhighlight lang="json">
{
 "sku": "ITEM-001",
 "reserved": 5,
 "marketplace_order_id": "MP-2026-000125",

{{SEO
|title=Інтеграція з маркетплейсом — ERP, API, товари, ціни, залишки, замовлення, доставка і K2 ERP
|description=Інтеграція з маркетплейсом: що це таке, як обмінювати товари, ціни, залишки, замовлення, статуси, доставки, повернення, рекламації, комісії та документи між ERP і маркетплейсом. API, JSON, webhooks, логування, ERP, K2 ERP, Power BI, типові помилки і приклади.
|keywords=інтеграція з маркетплейсом, інтеграція ERP з маркетплейсом, маркетплейс, API маркетплейсу, товари, ціни, залишки, замовлення, доставка, повернення, комісії, K2 ERP, Power BI
}}

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

! Щоб перевірити продажі та реалізація, повернення, комісії, штрафи, логістику і фактичні виплати. FBO — товар зберігається на складі маркетплейсу, і маркетплейс сам виконує логістику. # Налаштовано доставку. # Налаштовано товари.=== Чому критично передавати доступний залишок? ===
Створюється доставка або ТТН
}
 "commission": 263.76,
Замовлення з маркетплейсу має автоматизовано потрапляти в ERP. Лог має містити:

Ціна продажу: 1 000 грн
 "images": [
[[Категорія:Товари]]
!<syntaxhighlight lang="text">

{

 "warranty_months": 12

платформа має:

Погано:
 "quantity": 1,
API не повинен мати надмірні права. }

 },

Маркетплейс передає звіт про комісії і виплату

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

 "event": "order.created",

 "delivery": {

Приклад:

* номер замовлення маркетплейсу;
* дата;
* клієнт ERP;
* товари;
* кількість;
* ціни;
* знижки;
* комісії, якщо доступні;
* спосіб доставки;
* адреса;
* статус оплати;
* статус замовлення;
* коментар;
* промо;
* складський облік відвантаження;
* тип доставки. Показник
Ціни можуть передаватися з ERP на маркетплейс. "main": true

 "created_at": "2026-05-16T12:30:00",

Маркетплейс здатна мати власну доставку або передавати інформаційні дані для доставки продавцю. "promo": 1099.00,

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

Звірити з ERP. автоматизація процесів оптимізує:
 ↓
інтеграційні функції ERP з маркетплейсом — це автоматичний обмін даними між ERP або іншою внутрішньою системою компанії та торговельним майданчиком. Тоді маркетплейс стає не окремим хаотичним каналом, а керованою частиною продажів. # Налаштовано статуси. # виступає як Power BI-аналітика. ! Вона дає можливість автоматизовано керувати товарами, цінами, залишками, замовленнями, доставкою, поверненнями, рекламаціями, комісіями та виплатами. # Визначено джерело правди. інтеграційні функції ERP з’єднує ці два світи так, щоб продажі та реалізація не перетворювалися на ручний хаос. ! "status": "new",

клієнт ERP оформлює замовлення
Причини:
бізнес-середовище каже: знову мінус репутація. Статус маркетплейсу
! "type": "sales_commission",

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

Які товари продавати на маркетплейсі? 15:00 — маркетплейс усе ще показує 20 шт. "payment_status": "paid",

== Буфер залишків ==
Формула:
API здатна підтримувати:
Маркетплейс здатна приймати оплату від клієнта і періодично виплачувати продавцю гроші за мінусом комісій.

"https://example.com/item-001-main.jpg"

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

"category_id": "AUTO_FILTERS",

Без джерела правди інтеграційні функції ERP оперативно стає дипломатичним конфліктом між системами. Категорія ERP 

"type": "promotion",

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

Приклад: 

}

Типи комісій: Буфер потрібен, щоб не продати останню одиницю одночасно в кількох каналах. Без ID замовлення починають дублюватися, товари — плутатися, а звірка стає жанром психологічної драми. # Налаштовано резервування. На жаль, товар про це не знає і фізично не розмножується. ], 

]
"type": "logistics",
"sku": "ITEM-001",

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

  • не втрачати інформаційні дані;
  • показувати зрозумілу помилку;
  • повідомляти відповідального;
  • дозволяти повторити обмін;
  • не створювати дублікати;
  • мати чергу повторних спроб;
  • зберігати історію. | Автоматичний обмін даними між ERP і маркетплейсом. Потрібно контролювати:
Товари можуть створюватися в ERP і передаватися на маркетплейс.
 "erp_order_id": "SO-2026-00125"

 "method": "marketplace_delivery",

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

* [[Інтеграція з сайтом]]
* [[API]]
* [[Інтеграція через JSON]]
* [[HTTP-сервіси]]
* [[Webhooks]]
* [[CRM]]
* [[ERP]]
* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[Складський облік]]
* [[Штрихкодування]]
* [[Адресне зберігання]]
* [[Замовлення покупця]]
* [[Контрагент]]
* [[Типи цін]]
* [[Партії]]
* [[Управління доставкою]]
* [[ТТН]]
* [[Рекламації]]
* [[Повернення товарів]]
* [[Фінансовий результат]]
* [[Power BI]]
* [[BI система]]
* [[Audit log]]
* [[Права доступу в ERP]]
* [[Українське програмне забезпечення]]

 "created_at": "2026-05-16T12:30:00"

* [https://erp.kyiv.ua Сайт K2 ERP]
* [https://wiki.erp.kyiv.ua Wiki K2 ERP]
* [https://cloud.corp2.eu K2 Cloud ERP]

клієнт ERP оформлює замовлення на маркетплейсі
 "return_id": "RET-MP-00125",
 ↓
== Логування інтеграції ==
== Обробка помилок ==
}
! # виступає як audit log. продали через інший канал. Якісна інтеграційні функції ERP оптимізує продавати швидше, зменшувати ручну роботу, уникати продажу відсутнього товару, контролювати рейтинг продавця, бачити реальну маржу й будувати нормальну аналітику по каналах продажів. ERP: продажів за період — 500 000 грн

! '''API маркетплейсу''' — це інтерфейс, через який ERP і маркетплейс обмінюються даними. ! Без звірки фінансовий результат по маркетплейсу здатна бути неточним.== Що таке інтеграційні функції ERP з маркетплейсом ==

 "sku": "ITEM-001",

GET /api/orders?status=new

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

{

ITEM-002,Насос NP-100,2500,5 

}

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

  • CSV;
  • XLSX;
  • XML;
  • JSON;
  • YML;
  • TXT. складський облік збирає відправлення

} } 

== Middleware для маркетплейсів ==
<syntaxhighlight lang="text">
 "safety_buffer": 2,
[[Категорія:Українське програмне забезпечення]]
! Відповідь

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

{
</div>
{| class="wikitable" style="width:100%;"
Приклад:
|-
| Продається товар без залишку
| Передається фізичний залишок без резерву
| Скасування і поганий рейтинг
|-
| Немає буфера
| Один залишок продається в кількох каналах
| Подвійні продажі та реалізація
|-
| Немає мапінгу категорій
| Категорії ERP і маркетплейсу не узгоджені
| Товари не проходять модерацію
|-
| Немає характеристик
| інформаційні дані ведуться в описі, а не структурно
| Товари погано шукаються
|-
| Не враховуються комісії
| Аналізують тільки ціну продажу
| Маржа завищена
|-
| Немає логів
| Обмін непрозорий
| Помилки важко знайти
|-
| Замовлення дублюються
| Немає external ID
| Подвійна обробка
|-
| Немає звірки виплат
| Не завантажуються звіти маркетплейсу
| Фінансові розбіжності
|}

{| class="wikitable" style="width:100%;"

<syntaxhighlight lang="json">

бізнес-процес:
 "marketplace": "example_marketplace",
 "unit": "шт",
[[Категорія:JSON]]
<syntaxhighlight lang="text">

! Модель

}

Power BI показує прибутковість каналу

 ↓

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

інтеграційні функції ERP замовлень

Значення

ERP → Маркетплейс: Резерв: 3 FBS — товар зберігається у продавця, а після замовлення продавець його відвантажує. # виступає як унікальні ID. ↓ Погано: Маркетплейс передає замовлення в ERP

ERP → Передача товару на складський облік маркетплейсу

</syntaxhighlight> Маркетплейс → Звіт про повернення Передаються:

Приклад: 

↓
"barcode": "4820000000012",

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

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

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

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

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

Характеристики краще вести структуровано в ERP, а не вільним текстом. "amount": 50.00 

"name": "Фільтр повітряний F-20",
"attributes": {

Що таке FBS і FBO?

Приклад: Маркетплейс → ERP: </syntaxhighlight>

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

 "sku": "ITEM-001",
== Помилка: залишки оновлюються раз на день ==
! Бо він, умовно кажучи, лежить у розділі шкарпеток замість запчастин. * замовленням;
* товаром;
* партією;
* клієнтом;
* складом;
* відвантаженням;
* доставкою;
* відповідальним;
* витратами;
* рішенням. "city": "Київ"
{
 "description": "Фільтр повітряний для легкових автомобілів",

рішення для бізнесу:

== інтеграційні функції ERP фото ==
Маркетплейс передає замовлення в K2 ERP
 "images": [
Маркетплейс перерахував гроші. # Налаштовано характеристики.[[Категорія:Права доступу в ERP]]
Middleware здатна:
Приклад процесу:
[[Категорія:Маркетплейс]]
 "promo_until": "2026-05-31"
 "created_at": "2026-05-16T12:30:00",
Приклад:

<syntaxhighlight lang="text">

- повернення;
 },
 ↓
 {
Корисні дашборди:
 "material": "paper",
 "brand": "ExampleBrand",
Щоб бачити реальну маржу. "category": "Автотовари",
Комісії потрібно враховувати у фінансовому результаті. Потім складніше пояснити, чому після комісії маркетплейсу й логістики прибуток схожий на декоративний елемент. Доступ
[[Категорія:ERP]]

}

! }
 ],
Приклад:
Маркетплейс → Звіт про продажі та реалізація

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

{| class="wikitable" style="width:100%;"

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

Показники:

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

}

  • комісія за продаж;
  • комісія за категорію;
  • логістична комісія;
  • комісія за зберігання;
  • комісія за повернення;
  • комісія за просування;
  • еквайринг;
  • штраф;
  • абонплата;
  • плата за участь в акції.
{| class="wikitable" style="width:100%;"
[[Категорія:Рекламації]]
[[Категорія:Замовлення]]
!<syntaxhighlight lang="http">

 "warehouse": "MAIN",
[[Категорія:Доставка]]
При FBS продавець сам зберігає товар і відвантажує замовлення після отримання з маркетплейсу. резерв → продаж → повернення → списання → оновлення версій маркетплейсу.== Характеристики товарів ==

Товар комплектується і пакується

Отримано з https://wiki.kyiv.ua/index.php?title=Інтеграція_з_маркетплейсом&oldid=2103