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

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

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

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

ERP: продажів за період — 500 000 грн 

{

- штрафи;

Пакування: 20 грн Приклади:

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

Приклад:
 "stock": 13,

Якщо товар оперативно продається, актуалізація залишків раз на день має змогу бути небезпечним.; Модель
=== Чому істотно передавати доступний залишок? ===
Потрібно контролювати:
!; Вона надає можливість автономно керувати товарами, цінами, залишками, замовленнями, доставкою, поверненнями, рекламаціями, комісіями та виплатами.;== Помилка: немає звірки виплат ==
Webhook надає можливість маркетплейсу надсилати події в ERP.; '''Хороша інтеграційні функціональні можливості з маркетплейсом — це коли товар автономно публікується, залишки актуальні, замовлення потрапляють в ERP, складський облік оперативно відвантажує, комісії враховані, а фінансовий результат не виглядає як сюрприз після звіту маркетплейсу.'''
Замовлення з маркетплейсу має автономно потрапляти в ERP.; "quantity": 2,

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

[[Категорія:Українське програмне забезпечення]]

 "name": "Фільтр повітряний F-20",
Middleware має змогу:
 "unit": "шт",
ERP → Маркетплейс:
<syntaxhighlight lang="json">
Які залишки доступні?; А коли магія ламається, всі стають детективами без доказів.; Інакше маржа виглядає гарно тільки до першої звірки.; ERP резервує товар
<syntaxhighlight lang="json">
Буфер потрібен, щоб не продати останню одиницю одночасно в кількох каналах.; Причина

== Для чого потрібна інтеграційні функціональні можливості з маркетплейсом ==

 "marketplace": "example_marketplace",

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

* номер замовлення;
* товар;
* кількість;
* причина повернення;
* стан товару;
* дата;
* статус;
* фото, якщо є собою;
* сума повернення;
* складський облік повернення;
* рішення для бізнесу: в продаж, ремонт, брак, списання.; Показник
 "logistics_fee": 80.00,
[[Категорія:FBO]]
 "marketplace_order_id": "MP-2026-000125",
 "payment_status": "paid",

<syntaxhighlight lang="json">

 "sku": "ITEM-001",

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

* товар пошкоджений;
* не той товар;
* некомплект;
* брак;
* затримка доставки;
* товар не відповідає опису;
* гарантійна проблема;
* помилка документів.;[[Категорія:Складський облік]]
Маркетплейс → Звіт про продажі та реалізація
!; ITEM-002,Насос NP-100,2500,5

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

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

 "sku": "ITEM-001",

* неправильна категорія;
* відсутні обов’язкові характеристики;
* погані фото;
* заборонені слова в описі;
* неправильний бренд;
* некоректний штрихкод;
* дубль товару;
* невідповідність правилам маркетплейсу.; # Налаштовано доставку.; * [https://erp.kyiv.ua Сайт K2 ERP]
* [https://wiki.erp.kyiv.ua Wiki K2 ERP]
* [https://cloud.corp2.eu K2 Cloud ERP]

== Помилка: товари не проходять модерацію ==
{
 "type": "logistics",
 "images": [
інтеграційні функціональні можливості відповідає на питання:
 "currency": "UAH"
Комісія маркетплейсу: 120 грн
== інтеграційні функціональні можливості з маркетплейсом у K2 ERP ==
Приклад:
Різниця: 2 000 грн
 "created_at": "2026-05-16T12:30:00",
ERP або медіасховище має змогу передавати:
== FBS ==
[[Категорія:API]]
 "return_id": "RET-MP-00125",
<syntaxhighlight lang="json">
<syntaxhighlight lang="json">
Маркетплейси часто мають вимоги до фото.;<syntaxhighlight lang="json">

 ↓

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

* артикул;
* SKU;
* назва;
* характеристика;
* категорія;
* бренд;
* характеристики;
* штрихкод;
* одиниця виміру;
* вага;
* габарити;
* країна виробництва;
* гарантія;
* фото;
* сертифікати;
* статус активності;
* SEO-поля, якщо підтримуються;
* правила публікації.; "color": "black",
</div>
Маркетплейс інформує клієнта
 "tracking_number": "TTN-20450000000000",
 "delivery": {

Як резервується товар?; !; Приклад
<syntaxhighlight lang="json">
16:00 — клієнти купують товар, якого вже немає.; # Налаштовано обліковий облік комісій.; Категорія ERP

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

 "active": true

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

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

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

"carrier": "marketplace_logistics",

Ризики: 

"available_for_marketplace": 13

"created_at": "2026-05-16T12:30:00"
  • продажі та реалізація по маркетплейсах;
  • продажі та реалізація по товарах;
  • маржа з урахуванням комісій;
  • топ товарів;
  • товари з низькою маржею;
  • залишки;
  • повернення;
  • рекламації;
  • комісії;
  • логістичні витрати;
  • штрафи;
  • виплати;
  • прострочені відвантаження;
  • рейтинг продавця;
  • помилки інтеграції;
  • динаміка замовлень;
  • прибутковість каналів.; # Налаштовано товари.; Така інтеграційні функціональні можливості надає можливість передавати на маркетплейс товари, ціни, залишки, характеристики, фото, статуси, а з маркетплейсу отримувати замовлення, оплати, доставки, повернення, рекламації, комісії та звіти.;== Приклад JSON звіту комісій ==
"sku": "ITEM-001",
  • базова;
  • акційна;
  • мінімальна;
  • рекомендована;
  • промоціна;
  • ціна для конкретного каналу;
  • ціна з урахуванням комісії;
  • ціна з урахуванням доставки;
  • ціна за регіоном;
  • ціна за валютою.; Маркетплейс має бути каналом продажів.; # Налаштовано буфери залишків.; # Визначено джерело правди.;</syntaxhighlight>

!; продали через інший канал.; Показник </syntaxhighlight> Товар комплектується і пакується ERP передає статус на маркетплейс 

"brand": "ExampleBrand",

FBO

!;</syntaxhighlight> Приклад: 

]
"regular": 1200.00,

!; Сума 

<syntaxhighlight lang="text">

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

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

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

]
↓

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

"type": "promotion",

ERP або WMS має передавати на маркетплейс актуальні доступні залишки.; "type": "sales_commission", замовник оформлює замовлення на маркетплейсі інтеграційні функціональні можливості з маркетплейсом — це автоматичний обмін даними між ERP або іншою внутрішньою системою компанії та торговельним майданчиком.; !; !;== Що можна інтегрувати з маркетплейсом == 

"method": "marketplace_delivery",

],

- комісії; 

"barcode": "4820000000012",
"safety_buffer": 2,

Приклад: 

→ Маркетплейс 3
],

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

Звірка потрібна, щоб перевірити продажі та реалізація, повернення, комісії та виплати.; "category_id": "AUTO_FILTERS", 

== автоматизація процесів інтеграції з маркетплейсом ==
== інтеграційні функціональні можливості залишків ==
 "type": "fbs",
Без буфера останній товар має змогу стати зіркою одразу п’яти замовлень.; |-
| Найкраща практика
| API, буфери залишків, логування, звірка виплат, Power BI, audit log і контроль SLA.; Типи комісій:

</syntaxhighlight> 

"promo": 1099.00,

Доступи потрібно обмежувати.; Маркетплейс передає замовлення в K2 ERP

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

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

Комісії потрібно враховувати у фінансовому результаті.; "status": "new",

!; "status": "new",

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

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

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

↓

Краще: 

"price": 1099.00

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

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

!;</syntaxhighlight> 

Маркетплейс → Замовлення → ERP → Резерв → складський облік → Пакування → Відправка → Статус у маркетплейс
== Типові помилки інтеграції з маркетплейсом ==
!;[[Категорія:Залишки]]
Маркетплейс має змогу утримувати комісії, штрафи, логістику, повернення і промо.; інтеграційні функціональні можливості з’єднує ці два світи так, щоб продажі та реалізація не перетворювалися на ручний хаос.; Значення

== інтеграційні функціональні можливості оплат ==
'''API маркетплейсу''' — це інтерфейс, через який ERP і маркетплейс обмінюються даними.; # Налаштовано ціни.; Створюється доставка або ТТН

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

 "material": "plastic",

{| class="wikitable" style="width:100%;"
 "sku": "ITEM-001",
{| class="wikitable" style="width:100%;"
|-
| Номенклатура
| ERP
|-
| Собівартість
| ERP
|-
| Ціни
| ERP або pricing-модуль
|-
| Залишки
| ERP / WMS
|-
| Замовлення
| Маркетплейс створює, ERP обробляє
|-
| Статуси складу
| ERP / WMS
|-
| Статуси доставки
| ERP або маркетплейс
|-
| Комісії
| Маркетплейс
|-
| Фінансовий результат
| ERP / BI
|}

<syntaxhighlight lang="text">

У маркетплейсах часто є собою різні моделі логістики.; Коментар
[[Категорія:Замовлення покупця]]

складський облік отримує задачу на відбір

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

Показники:

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

}

}

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

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

Authorization: Bearer token </syntaxhighlight> "items": [ Без ID замовлення починають дублюватися, товари — плутатися, а звірка стає жанром психологічної драми.; "gross_amount": 2198.00, Корисні KPI: резерв → продаж → повернення → списання → актуалізація маркетплейсу.; ITEM-001,Фільтр F-20,1099,13 
"marketplace_order_id": "MP-2026-000125",

Приклад: На маркетплейс передаємо: 5 Приклад: 

 "sku": "ITEM-001",

!; Одна з найважливіших частин інтеграції — відповідність категорій ERP і маркетплейсу.;<syntaxhighlight lang="json">

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

* не втрачати інформаційні дані;
* показувати зрозумілу помилку;
* повідомляти відповідального;
* дозволяти повторити обмін;
* не створювати дублікати;
* мати чергу повторних спроб;
* зберігати історію.; ↓
Без джерела правди інтеграційні функціональні можливості оперативно стає дипломатичним конфліктом між системами.;[[Категорія:Доставка]]
== Комісії маркетплейсу ==
== Зовнішні посилання ==

"marketplace_order_id": "MP-2026-000125",
"sku": "ITEM-001",
Маркетплейси часто вимагають заповнення характеристик.;
[[Категорія:Права доступу в ERP]]

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

}

== Висновок ==

 ↓

Найчастіші сценарії:
{
складський облік збирає відправлення

 "main": false

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

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

Щоб бачити реальну маржу.; Напрям

 "promo_fee": 50.00,
<syntaxhighlight lang="text">
<syntaxhighlight lang="http">
Статуси потрібно синхронізувати між ERP і маркетплейсом.; "warranty_months": 12

бізнес-середовище каже: знову мінус репутація.; # є собою унікальні ID.; FBO — товар зберігається на складі маркетплейсу, і маркетплейс сам виконує логістику.; Питання

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

* собівартість;
* комісія маркетплейсу;
* логістика;
* пакування;
* еквайринг;
* промо;
* повернення;
* рекламації;
* штрафи;
* податки;
* бажана маржа.; {
 ↓
!; Ціни можуть передаватися з ERP на маркетплейс.; # Налаштовано отримання замовлень.; "quantity": 2,

</syntaxhighlight> 

Як обробляються повернення?; # Налаштовано повернення.; ↓
 ↓
 "amount": 80.00
[[Power BI]] сприяє аналізувати продажі та реалізація через маркетплейси.; # є собою audit log.; Коментар
 "event": "order.created",
}

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

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

Для кожного типу даних потрібно визначити джерело правди.; !; "weight": 0.35,

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

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

інтеграційні функціональні можливості доставки

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

 "marketplace_order_id": "MP-2026-000125",
{
{
Приклад процесу:
Приклад:
 }
Звірити з ERP.; # є собою моніторинг.; Категорія маркетплейсу

[[Категорія:Інтеграція]]

Бо фізичний залишок має змогу бути частково зарезервований під інші замовлення.; "physical_stock": 20,

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

Маркетплейс має змогу приймати оплату від клієнта і періодично виплачувати продавцю гроші за мінусом комісій.; автоматизація процесів сприяє: FBS — товар зберігається у продавця, а після замовлення продавець його відвантажує.; "brand": "ExampleBrand", 

"sku": "ITEM-001",
↓

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

!; # є собою Power BI-аналітика.; це автоматичний обмін даними між ERP, CRM, WMS, складом або K2 ERP і торговельним майданчиком, де організація продає товари чи послуги виступає ключовою рисою інтеграційні функціональні можливості з маркетплейсом.; Статус 

 }
 "amount": 50.00
<syntaxhighlight lang="text">
|-
| FBS
| Seller зберігає товар у себе і відправляє після замовлення
| ERP має оперативно резервувати і передавати статуси
|-
| FBO
| Товар зберігається на складі маркетплейсу
| Потрібен обліковий облік передачі товару на складський облік маркетплейсу
|-
| Власна доставка
| Продавець сам організовує доставку
| Потрібна інтеграційні функціональні можливості з перевізником
|-
| Dropshipping
| Відправляє постачальник
| Потрібна інтеграційні функціональні можливості з постачальником і контроль SLA
|}

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

Які товари продавати на маркетплейсі?; }
Audit log потрібен, щоб зміни в інтеграції не були “хтось щось перемкнув, і тепер маркетплейс продає старі ціни”.; Буфер особливо важливий, якщо організація продає одночасно:

 {

Якщо товар потрапляє не в ту категорію, замовник його не знаходить, маркетплейс має змогу відхилити публікацію, а продавець потім дивується, чому “товар не продається”.; # є собою логування.; "commission": 263.76, Маркетплейс → ERP: Webhook зручний тим, що ERP не мусить кожну хвилину питати маркетплейс: “Ну що, є собою щось нове?”.;

  • замовленням;
  • товаром;
  • партією;
  • клієнтом;
  • складом;
  • відвантаженням;
  • доставкою;
  • відповідальним;
  • витратами;
  • рішенням.; Як передається статус доставки?; Подія
== Файловий обмін із маркетплейсом ==
<syntaxhighlight lang="json">
|-
| Сума продажу
| 10 000 грн
|-
| Комісія маркетплейсу
| -1 200 грн
|-
| Логістика
| -500 грн
|-
| Промо
| -300 грн
|-
| До виплати
| 8 000 грн
|}

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

API не повинен мати надмірні права.; Буфер: 2

Продати товар “з гарною знижкою” без зайвих зусиль.;== KPI інтеграції з маркетплейсом ==
15:00 — маркетплейс усе ще показує 20 шт.; |-
| центральний принцип
| ERP — джерело правди для обліку, маркетплейс — канал продажів.; Собівартість: 800 грн
 "gross_amount": 2198.00,
 },
Маркетплейс каже: товар доступний.; Тоді маркетплейс стає не окремим хаотичним каналом, а керованою частиною продажів.;[[Категорія:Рекламації]]

</div>
== Основні сценарії інтеграції ==
фінансовий блок без ускладнень зарахували суму.; # Налаштовано мапінг категорій.; ↓

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

* дату і час;
* маркетплейс;
* напрям обміну;
* тип об’єкта;
* external ID;
* ERP ID;
* endpoint;
* статус;
* текст помилки;
* повторні спроби;
* payload або безпечну частину;
* час відповіді;
* відповідального.; Без звірки фінансовий результат по маркетплейсу має змогу бути неточним.; Без нього хтось бігає з папірцем і дуже старається не продати те, чого вже немає.; Бо рейтинг продавця падає швидше, ніж команда встигає сказати: “А хто мав оновити залишки?”

"reason": "customer_return",
  • створення товарів;
  • актуалізація товарів;
  • актуалізація цін;
  • актуалізація залишків;
  • отримання замовлень;
  • підтвердження замовлень;
  • передачу статусів;
  • передачу ТТН;
  • отримання повернень;
  • отримання звітів;
  • отримання комісій;
  • отримання виплат.; # Визначено маркетплейси.; ↓

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

"status": "received"

"erp_order_id": "SO-2026-00125"

Логи мають фіксувати всі обміни.; Які ціни показувати?; Приклад: 

}
↓

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

"warehouse": "MAIN",

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

Причини:
Доступний залишок = Фізичний залишок - Резерв - Буфер
 "sku": "ITEM-001",
Повернення потрібно автономно або напівавтоматично передавати в ERP.; Товар резервується

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

Приклад: Лог має містити: При FBO товар передається на складський облік маркетплейсу, і маркетплейс сам виконує зберігання, відбір, пакування та доставку.; !; # Налаштовано характеристики.; Потім складніше пояснити, чому після комісії маркетплейсу й логістики прибуток схожий на декоративний елемент.; {| class="wikitable" style="width:100%;"

}

Ціна продажу: 1 000 грн

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

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

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

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

замовник оформлює замовлення 

},

ERP каже: товару 0.; Статус ERP

  • ERP передає товари на маркетплейс;
  • ERP передає характеристики;
  • ERP передає фото;
  • ERP передає ціни;
  • ERP передає доступні залишки;
  • маркетплейс передає замовлення в ERP;
  • ERP резервує товар;
  • складський облік отримує задачу на відбір;
  • ERP передає статус збирання;
  • ERP або маркетплейс формує ТТН;
  • маркетплейс передає оплату;
  • маркетплейс передає комісію;
  • маркетплейс передає повернення;
  • ERP створює повернення товару;
  • ERP формує фінансову аналітику по каналу.; # є собою права доступу.; * товар не пройшов модерацію;
  • неправильна категорія;
  • відсутня обов’язкова характеристика;
  • неправильний формат ціни;
  • залишок не оновився;
  • замовлення вже існує;
  • API недоступний;
  • токен прострочений;
  • timeout;
  • неправильний статус;
  • немає відповідності SKU;
  • дубль клієнта;
  • повернення не знайдено;
  • звіт комісій не завантажився.; "sku": "ITEM-001",
"description": "Фільтр повітряний для легкових автомобілів",
; Приклади: ; } 
Типи цін:
Маркетплейс → Звіт про повернення
== Буфер залишків ==
 "https://example.com/item-001-main.jpg"

Характеристики краще вести структуровано в ERP, а не вільним текстом.; Наслідок

* вести характеристики структуровано;
* мати мапінг категорій;
* перевіряти обов’язкові поля;
* логувати помилки модерації;
* створити відповідального за контент;
* автономно показувати товари з помилками.; Це реальна витрата, яка має потрапити в P&L.; !; |-
| Основні інформаційні дані
| Товари, ціни, залишки, замовлення, доставка, повернення, комісії, виплати.; }

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

 },

Приклад:

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

Приклад: Ціна продажу: 1 000 грн

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

Приклад:

{

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

Погано:

  • CSV;
  • XLSX;
  • XML;
  • JSON;
  • YML;
  • TXT.; ERP створює замовлення покупця

Комісії — це не “десь там маркетплейс забрав”.; Показник 

}
; # Налаштовано звірку виплат.;

Собівартість: 800 грн

“Прибуток”: 200 грн

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

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

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

; Сума

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

бізнес-процес:

</syntaxhighlight>

</syntaxhighlight> 

== інтеграційні функціональні можливості фото ==

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

 "main": true

Як обліковуються комісії маркетплейсу?; 11:00 — 20 шт.; }
 "delivery": {
{
== Статуси замовлення ==
 "created_at": "2026-05-16T12:30:00"
}
платформа має:
"net_payout": 1804.24, Потрібно обліковувати:
"net_payout": 1804.24
  • створено замовлення;
  • замовлення оплачено;
  • замовлення скасовано;
  • створено повернення;
  • змінено статус доставки;
  • створено рекламацію;
  • оновлено виплату;
  • товар відхилено модерацією.;</syntaxhighlight>
== Звірка з маркетплейсом ==

Маркетплейси часто оцінюють продавців за якістю виконання.; Бо “чорний”, “чорн.”, “black” і “темний як ніч бухгалтера після інвентаризації” — для системи не одне й те саме.; Типовий бізнес-процес:

істотно передавати: Резерв: 3 {{SEO

Приклад webhook:

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

"items": [

- сума до виплати.;== Обробка помилок == 

}

↓

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

; 
}

 "city": "Київ"

}

Краще:

 "currency": "UAH",
!; І всі системи, звичайно, “не винні”.; # є собою повторна відправка.; Схема:
 "price": 1099.00,
 {

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

 ],

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

* бренд;
* модель;
* колір;
* розмір;
* матеріал;
* вага;
* габарити;
* тип;
* сумісність;
* країна виробництва;
* гарантійний строк;
* технічні параметри;
* складський облік;
* сезонність;
* комплектація.;[[Категорія:HTTP-сервіси]]
функціональні можливості:
}
 "warranty_months": 12
Приклад:
}
Як фіксуються рекламації?; Якщо передавати фізичний залишок без резервів і буфера, можна продати товар, якого фактично вже немає.; Як звірити виплати від маркетплейсу?;== Мапінг категорій ==
 "orders": [
{

{

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

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

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

Маркетплейс перерахував гроші.; "delivery_status": "shipped"

; 
"fees": [

K2 ERP створює замовлення покупця інтеграційні функціональні можливості з маркетплейсом — це важлива частина сучасної електронної комерції.; "attributes": {

Якісна інтеграційні функціональні можливості сприяє продавати швидше, зменшувати ручну роботу, уникати продажу відсутнього товару, контролювати рейтинг продавця, бачити реальну маржу й будувати нормальну аналітику по каналах продажів.; Джерело правди Приклад CSV: У K2 ERP інтеграційні функціональні можливості з маркетплейсом має змогу бути частиною контуру продажів, складу, фінансів, CRM, доставки, рекламацій і аналітики.; # Налаштовано резервування.; - повернення;

інтеграційні функціональні можливості цін

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

  • швидкість підтвердження замовлень;
  • швидкість відвантаження;
  • частка скасувань;
  • частка прострочень;
  • частка повернень;
  • кількість рекламацій;
  • рейтинг клієнтів;
  • відповіді на питання;
  • наявність товару;
  • якість контенту;
  • порушення правил маркетплейсу.; Що означає
товарів забезпечується через Головне. ERP має бути джерелом правди; додатково реалізовано цін, залишків, собівартості, складів і обліку.; Завантажити звіт маркетплейсу:
Нове New Замовлення отримано
Підтверджено Confirmed Продавець прийняв замовлення
На відборі Processing складський облік збирає товар
Запаковано Packed Товар готовий до відправки
Відвантажено Shipped Передано перевізнику
Доставлено Delivered замовник отримав товар
Скасовано Cancelled Замовлення скасовано
Повернення Returned Товар повернуто 
"barcode": "4820000000012",

"images": [

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

  • перевізник;
  • тип доставки;
  • адреса;
  • відділення;
  • отримувач;
  • телефон;
  • ТТН;
  • дата відправлення;
  • статус доставки;
  • вартість доставки;
  • хто оплачує доставку;
  • складський облік відвантаження.; Бо він, умовно кажучи, лежить у розділі шкарпеток замість запчастин.; інтеграційні функціональні можливості — це службовий коридор між вітриною і реальним бізнесом.; "promo_until": "2026-05-31"

sku,name,price,stock

  • передачу товару на складський облік маркетплейсу;
  • залишки на складі маркетплейсу;
  • продажі та реалізація;
  • повернення;
  • втрати;
  • комісії;
  • виплати;
  • звіти;
  • розбіжності.; "price": {

{ Формула: Враховуються: Маркетплейс → Звіт про залишки Приклад відповіді:

Проста аналогія. Маркетплейс — це великий торговий центр.; інформаційні дані Приклад JSON товару:

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

{ 

"payment_status": "paid",

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

; # Налаштовано фото.; Формати:

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

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

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

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

Щоб перевірити продажі та реалізація, повернення, комісії, штрафи, логістику і фактичні виплати.; Маркетплейс сам каже, коли щось сталося.; !;</syntaxhighlight> 

↓

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

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

"city": "Київ"

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

Що це?; ERP — це ваш складський облік, бухгалтерський обліковий облік, ціни, закупівельна діяльність, фінансовий блок й залишки.;</syntaxhighlight>

Що таке FBS і FBO?

Куди потрапляють замовлення?; 

{

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

 "url": "https://example.com/images/item-001-main.jpg",
Причина: одне повернення відображене в маркетплейсі, але не проведене в ERP
Маркетплейс передає звіт про комісії і виплату
{
GET /api/orders?status=new
Типові помилки:

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

Логістика: 50 грн
== інтеграційні функціональні можливості замовлень ==
 "marketplace_order_id": "MP-2026-000125",
!; Особливість

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

== Логування інтеграції ==
Товари можуть створюватися в ERP і передаватися на маркетплейс.; Помилка

API має змогу підтримувати:

* marketplace_order_id;
* erp_order_id;
* sku;
* external_product_id;
* marketplace_product_id;
* return_id;
* payout_id;
* transaction_id;
* shipment_id;
* claim_id.; # Налаштовано рекламації.;== Коротко ==

 {
 "reserved": 5,
У сучасній ERP, зокрема в [[K2 ERP]], інтеграційні функціональні можливості з маркетплейсом має бути пов’язана з товарами, категоріями, характеристиками, цінами, залишками, складами, замовленнями, доставкою, поверненнями, рекламаціями, комісіями, виплатами, API, webhooks, логами, audit log, правами доступу і Power BI.; Краще:

 ]
 → Маркетплейс 2

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

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

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

Якщо маркетплейсів багато, має змогу використовуватися проміжний сервіс — middleware.; "carrier": "marketplace_logistics", "quantity": 1, Погано: "material": "paper",
  • уніфікувати формати;
  • мапити категорії;
  • розподіляти залишки;
  • збирати замовлення;
  • передавати статуси;
  • нормалізувати помилки;
  • зменшити кількість окремих інтеграцій;
  • вести централізовані логи.; | Автоматичний обмін даними між ERP і маркетплейсом.; {| class="wikitable" style="width:100%;"
</syntaxhighlight> 
замовник каже: я вже оплатив.;== Див.; додатково ==

Приклад:
== Типові питання ==
Менеджер каже: зараз щось придумаємо.;
;

Маркетплейс передає замовлення в ERP Приклад запиту:

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

 class="wikitable" style="width:100%;" 
"status": "new",
== Middleware для маркетплейсів ==
Отримано з https://wiki.corp2.eu/index.php?title=Інтеграція_з_маркетплейсом&oldid=2103