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

Інтеграція з банком

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

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

Звідки сайт бере залишки? інтеграційні функції ERP здатна бути односторонньою або двосторонньою. Поле ERP

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

ERP перевіряє site_order_id. Виглядає сучасно, а функціонує як факс у новому корпусі. * передача товарів;

  • передача категорій;
  • передача характеристик;
  • передача фото;
  • передача цін;
  • передача залишків;
  • приймання замовлень;
  • створення клієнтів;
  • обробка оплат;
  • передача статусів;
  • передача ТТН;
  • особистий кабінет клієнта;
  • B2B-портал;
  • заявки з сайту;
  • рекламації;
  • сервісні звернення;
  • API;
  • webhooks;
  • логування обміну;
  • audit log;
  • права доступу;
  • Power BI-аналітика. Поле сайту
↓

Webhooks

  • отримати список товарів;
  • отримати ціни;
  • отримати залишки;
  • створити замовлення;
  • створити клієнта;
  • оновити статус;
  • передати оплату;
  • створити рекламацію;
  • отримати документи;
  • перевірити доступність доставки. інтеграційні функції ERP без моніторингу — це як холодильник без лампочки й термометра. "customer": {

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

критично передавати саме доступний залишок, а не без зусиль фізичний.
"name": "Іван",

3. # Налаштувати моніторинг. Без external_id інтеграційні функції ERP оперативно перетворюється на гру “це те саме замовлення чи дуже схоже?”. інформаційні дані

</syntaxhighlight>

"warehouse": "MAIN",
  • хто змінив конфігурація інтеграції;
  • хто змінив API-ключ;
  • хто повторив обмін;
  • хто змінив мапінг полів;
  • хто змінив правила цін;
  • хто змінив складський облік для залишків;
  • хто змінив доступи сайту;
  • хто скасував замовлення;
  • хто змінив статус;
  • хто видалив лог або запис. Якщо менеджер змінює ціну в ERP, а маркетолог — на сайті, через тиждень вони обидва впевнені, що праві. Що означає

}

це автоматичний обмін даними між сайтом, інтернет-магазином, порталом клієнта або корпоративним вебресурсом і внутрішньою системою компанії: ERP, CRM, WMS, HRM, фінансовою системою, складом, сервісом або K2 ERP виступає ключовою рисою інтеграційні функції ERP з сайтом. Звідки сайт бере товари? Вона дає можливість автоматизовано передавати товари, ціни, залишки, замовлення, клієнтів, оплати, статуси доставки, документи, заявки й рекламації між сайтом і ERP. # Описано замовлення. # Визначити джерело правди для даних.</syntaxhighlight> </syntaxhighlight> 1. ↓

* зрозумілий формат;
* зручний для вебсервісів;
* підтримується більшістю мов програмування;
* добре підходить для структурованих даних;
* швидко передавати вкладені об’єкти. "warehouse": "KYIV",
Причини:
- бачить акт звірки;
ERP → Сайт → Маркетплейс
== JSON в інтеграції з сайтом ==

! інформаційні дані Сайт → ERP: замовлення, клієнти, оплати, заявки Audit log потрібен, щоб інтеграційні функції ERP не була “чорним ящиком із кнопкою, яку ніхто не натискав, але все зламалось”. Щоб бачити, які інформаційні дані передавались, коли, з яким результатом і з якою помилкою. "email": "client@example.com" Як ERP дізнається про заявки з сайту?Power BI здатна аналізувати інформаційні дані сайту й ERP. Приклад CSV:

"sku": "ITEM-001",

}

</syntaxhighlight>

"reserved": 3
↓

{

  • автоматичного оновлення версій каталогу товарів;
  • показу актуальних цін;
  • показу актуальних залишків;
  • приймання замовлень із сайту в ERP;
  • створення клієнтів і контактів;
  • передачі оплат;
  • передачі статусів замовлення;
  • синхронізації доставки;
  • формування рахунків;
  • роботи з особистим кабінетом клієнта;
  • обміну документами;
  • контролю повернень;
  • контролю рекламацій;
  • автоматизації B2B-порталу;
  • зменшення ручних помилок;
  • пришвидшення обробки замовлень;
  • підключення аналітики в Power BI. Якщо сайт приймає онлайн-оплати, статус платежу потрібно передавати в ERP.== інтеграційні функції ERP оплат ==
  • роздрібна;
  • оптова;
  • дилерська;
  • акційна;
  • персональна;
  • за договором;
  • за сегментом клієнта;
  • за валютою;
  • за регіоном;
  • за кількістю. # виступає як мапінг полів. Створити замовлення на сайті. Доступ

Приклади: <product> Товар резервується Webhook зручний тим, що платформа не питає кожні 5 хвилин “ну що там?”, а надсилає повідомлення, коли щось справді сталося. # Визначено джерело правди. # Описати бізнес-процеси. # виступає як Power BI або інша аналітичні інструменти. ! # виступає як повторна відправка.== Впровадження інтеграції з сайтом ==

Через 5 хвилин повторює запит. # Підготувати API або файловий формат. }

Приклад:

клієнт ERP: не дуже щасливий. "success": true, ERP → Сайт API здатна дозволяти:

"claim_id": "WEB-CLAIM-00125",
"sku": "ITEM-001",

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

Сайт передає замовлення в K2 ERP

"price": 1200.00,
{ Сценарій: створення замовлення з оплатою. |-
Товари ERP
Ціни ERP
Залишки ERP / WMS
Замовлення Сайт створює, ERP обробляє
Оплати Платіжна платформа + ERP
Клієнти CRM / ERP
Статуси доставки ERP / служба доставки
"edrpou": "12345678",

4. Відповідь }

"phone": "+380000000000",

Що краще: API чи файловий обмін?

клієнт ERP має скріншот найнижчої. Усі обміни потрібно логувати. Частота

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

  • заявка на консультацію;
  • запит ціни;
  • заявка на сервіс;
  • заявка на ремонт;
  • рекламація;
  • запит на демо;
  • підписка;
  • анкета клієнта;
  • запит документів;
  • заявка на партнерство;
  • форма зворотного зв’язку. Перевірив ціну. * свої замовлення;
  • статуси;
  • рахунки;
  • акти;
  • накладні;
  • акти звірки;
  • баланс;
  • дебіторську заборгованість;
  • історію оплат;
  • персональні ціни;
  • договори;
  • рекламації;
  • сервісні заявки;
  • бонуси;
  • ліміти;
  • документи для завантаження. ! {
"category": "Категорія 1",

Помилка: сайт продає те, чого немає

! Етапи: B2B-портал без інтеграції з ERP — це дуже красива форма ручного введення даних. # Описати напрям обміну. Формати:

"name": "ТОВ клієнт ERP",
"email": "client@example.com",
"active": true

Для цього потрібні унікальні ідентифікатори. інформаційні дані {

клієнт ERP здатна створити рекламацію через сайт. Помилка
Дізналися від клієнта. Провести онлайн-оплату. {| class="wikitable" style="width:100%;"
!=== Які інформаційні дані найчастіше інтегрують із сайтом? ===

 "price": 1200.00
4. Товари, ціни, залишки

=== Що має бути джерелом правди для цін і залишків? ===
Синхронізація здатна бути:
Приклад:
[[Категорія:B2B-портал]]
 "type": "company",
Клієнти можуть створюватися на сайті й передаватися в ERP. Приклад двосторонньої інтеграції:
== Синхронізація даних ==

 "quantity": 2,
== Основні сценарії інтеграції ==
 },

5. Файловий обмін простий, але має ризики:

 "delivery_status": "shipped",
Одна з типових проблем інтеграції — дублювання клієнтів. # Навчити відповідальних. {| class="wikitable" style="width:100%;"

[[Категорія:Оплати]]

Ціни мають мати джерело правди. Сервіс
 "available": 7,
 ↓
== інтеграційні функції ERP замовлень ==
<syntaxhighlight lang="text">
}

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

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

{

Authorization: Bearer token

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

Сайт не повинен мати повний доступ до ERP. # виступає як захист від дублів. * сайт повторно відправив замовлення;

  • ERP не перевірила site_order_id;
  • timeout сприйняли як помилку і створили друге замовлення. "transaction_id": "TX123456789"
"currency": "UAH",

Краще: </syntaxhighlight> </syntaxhighlight> </syntaxhighlight>

"available": 15,

Конфлікти даних

Висновок

</syntaxhighlight>

"currency": "UAH",

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

Приклад: Сайт і ERP можуть обмінюватися даними доставки. # виступає як авторизація. Подія

Краще:

Приклад статусів: Проста аналогія. Сайт — це вітрина магазину.== Тестування інтеграції ==

Способи інтеграції з сайтом

Audit log інтеграції

  • персональні ціни;
  • договори;
  • кредитні ліміти;
  • відстрочка платежу;
  • замовлення за шаблонами;
  • повторення попереднього замовлення;
  • погодження замовлення всередині клієнта;
  • залишки по складах;
  • акти звірки;
  • документи;
  • обмеження асортименту;
  • історія продукту закупівель. # Описано статуси.== інтеграційні функції ERP цін ==
Статус повертається на сайт
== Помилка: немає моніторингу інтеграції ==
== Коротко ==
== Особистий кабінет клієнта ==
Приклад:
[[Категорія:Замовлення]]
 "reserved": 1
{

Звідки сайт бере ціни? Перевірив залишок. | Автоматичний обмін даними між сайтом і ERP/CRM/WMS/іншими системами. # Визначити частоту синхронізації. Без логів дуже важко зрозуміти, де саме зламався обмін. |-
| Немає джерела правди
| інформаційні дані редагують і в ERP, і на сайті
| Різні ціни, залишки, описи
|-
| Не передають доступний залишок
| Передають фізичний залишок
| Продаж зарезервованого товару
|-
| Немає унікального ID
| Поганий мапінг
| Дублі замовлень і клієнтів
|-
| Немає логів
| Обмін не контролюється
| Неможливо знайти причину помилки
|-
| Немає повторної відправки
| Помилка губить інформаційні дані
| Замовлення не потрапляє в ERP
|-
| API має надмірні права
| Слабка безпека
| Ризик зміни або витоку даних
|-
| Не обробляють помилки
| Сайт показує “успіх”, ERP не створила замовлення
| клієнт ERP чекає, а бізнес-середовище не бачить замовлення
|-
| Немає тестового середовища
| Перевіряють на бойових даних
| Поломки в реальному продажі та реалізація
|}

Див. так само

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

! "site_order_id": "WEB-2026-000125",

Лог інтеграції — це чорний ящик.
- бачить замовлення;

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

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

товарів забезпечується через '''Головне.''' інтеграційні функції ERP з сайтом дає можливість сайту продавати, приймати заявки або показувати інформаційні дані клієнту, а ERP — бути джерелом правди; так само реалізовано цін, залишків, замовлень, оплат, клієнтів і документів. |-
| Основні інформаційні дані
| Товари, ціни, залишки, замовлення, клієнти, оплати, статуси, доставка, документи. 6.

Приклад:

* CSV;
* XML;
* JSON;
* XLSX;
* TXT.<syntaxhighlight lang="text">

Якісна інтеграційні функції ERP з сайтом зменшує ручну роботу, прискорює обробку замовлень, знижує кількість помилок, покращує клієнтський досвід і дає керівництву прозору аналітику. Час |- | 16.05.2026 11:25 | Створення замовлення WEB-125 | OK | Створено SO-2026-00125 |- | 16.05.2026 11:26 | Передача оплати | Error | Невідома валюта |}

Найпоширеніші сценарії:

"email": "ivan@example.com",

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

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

  • товар не знайдено;
  • клієнт ERP уже існує;
  • неправильний формат JSON;
  • відсутнє обов’язкове поле;
  • неправильна валюта;
  • немає залишку;
  • ціна неактуальна;
  • API недоступний;
  • timeout;
  • дубль замовлення;
  • неправильний токен;
  • помилка доставки;
  • помилка платіжної системи. * site_order_id;
  • erp_order_id;
  • sku;
  • customer_id;
  • payment_id;
  • transaction_id;
  • claim_id;
  • delivery_id;
  • product_guid;
  • external_id. здатна все добре. клієнт ERP, звісно, вибирає нижчу ціну. CMS здатна мати:

Маркетплейс → Сайт → ERP

"site_order_id": "WEB-2026-000125",

Зазвичай ERP або WMS. * інтернет-магазин;

  • корпоративний сайт;
  • B2B-портал;
  • маркетплейс;
  • клієнтський кабінет;
  • сервісний портал;
  • навчальний портал;
  • портал партнерів. Сайт передає замовлення в ERP

K2 ERP передає статус і ТТН на сайт

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

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

* артикул;
* назва;
* SEO-опис;
* категорія;
* бренд;
* характеристики;
* одиниця виміру;
* фото;
* штрихкод;
* вага;
* габарити;
* статус активності;
* SEO-поля;
* аналоги;
* супутні товари;
* серії;
* модифікації. {
 "phone": "+380000000000",
<syntaxhighlight lang="text">
{{DISPLAYTITLE:Інтеграція з сайтом}}
Приклад:

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

Якщо обмін не проходить 10 хвилин або виступає як 5 помилок підряд — платформа надсилає повідомлення відповідальному. sku,name,price,stock Можна передавати: |- | Товари | ERP → Сайт | Назва, артикул, SEO-опис, характеристики |- | Категорії | ERP → Сайт | Групи товарів, структура каталогу |- | Ціни | ERP → Сайт | Роздрібна, оптова, акційна, персональна |- | Залишки | ERP → Сайт | Доступна кількість по складах |- | Замовлення | Сайт → ERP | Замовлення покупця |- | Клієнти | Сайт → ERP / ERP → Сайт | Профіль клієнта, контакти, реквізити |- | Оплати | Сайт → ERP | Онлайн-оплата, статус платежу |- | Статуси | ERP → Сайт | Прийнято, зібрано, відправлено, доставлено |- | Доставка | ERP ↔ Сайт | Перевізник, ТТН, адреса, вартість |- | Документи | ERP → Сайт | Рахунок, акт, накладна, акт звірки |- | Рекламації | Сайт → ERP | Звернення клієнта щодо якості |- | Заявки | Сайт → ERP | Форма зворотного зв’язку, сервісна заявка |}

Як передаються клієнти? Приклад:

"unit": "шт",

Як оновлюються статуси замовлень? "site_order_id": "WEB-2026-000125", { Сайт: показує “в наявності”.

"type": "retail",

API без авторизації, бо “там же тільки залишки”. 6. |- | Найкраща практика | API, унікальні ID, логування, обробка помилок, моніторинг, безпека і Power BI-аналітика. # виступає як логування. |- | API | Сайт і ERP обмінюються запитами | Замовлення, товари, клієнти, статуси |- | Webhook | Сайт або ERP надсилає подію при зміні | Нове замовлення, оплата, зміна статусу |- | Файловий обмін | інформаційні дані передаються файлами | CSV, XML, JSON |- | Пряма інтеграційні функції ERP з базою | Системи читають або пишуть у базу | Рідко, з великими ризиками |- | Middleware | Проміжний сервіс обміну | Складні інтеграції між багатьма системами |- | Плагін CMS | компонент для конкретної CMS | WooCommerce, OpenCart, Shopify, інші CMS |}

! Відкрив сайт. Статус в ERP

</syntaxhighlight>

"sku": "ITEM-001",

Сайт має іншу. "sku": "ITEM-001", Приклад: ! "event": "order.paid",

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

</syntaxhighlight>

  • різні написання назви;
  • різні телефони;
  • різні email;
  • клієнт ERP оформив замовлення кілька разів;
  • компанія-користувач вже виступає як в ERP;
  • сайт не передає ЄДРПОУ;
  • немає правил пошуку дубля. Погано:

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

Навіщо потрібні логи інтеграції?

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

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

Як передаються оплати? критично не заплутатись, де джерело правди. ! B2B-портал — це сайт або особистий кабінет для корпоративних клієнтів.</syntaxhighlight>

== Обробка помилок ==
! ! ERP → Сайт: товари, ціни, залишки, статуси

Приклад тест-кейсу:

- завантажує рахунок;

 "carrier": "nova_poshta",

[[Категорія:Доставка]]
{| class="wikitable" style="width:100%;"
== інтеграційні функції ERP статусів замовлення ==
 "status": "created"

Якщо замовлення вже створено — повертає існуючий erp_order_id. ERP створює рекламацію, призначає відповідального, контролює SLA і запускає бізнес-процес розгляду. Значення

<syntaxhighlight lang="json">

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

Погано:

 "amount": 2400.00

}

* номер замовлення на сайті;
* дата;
* клієнт ERP;
* контактні інформаційні дані;
* товари;
* кількість;
* ціни;
* знижки;
* доставка;
* спосіб оплати;
* статус оплати;
* коментар клієнта;
* промокод;
* адреса доставки;
* перевізник;
* джерело замовлення. "barcode": "4820000000012",
клієнт ERP заходить у кабінет:
{
[[Категорія:Українське програмне забезпечення]]
Приклад:
'''Хороша інтеграційні функції ERP з сайтом — це коли клієнт ERP бачить актуальну ціну, купує доступний товар, замовлення автоматизовано потрапляє в ERP, складський облік оперативно збирає відвантаження, а менеджер не копіює інформаційні дані вручну як герой минулого століття.'''
[[Категорія:Особистий кабінет]]
! І зазвичай голосніше за всіх сперечається клієнт ERP. ERP — це складський облік, каса, бухгалтерський обліковий облік, закупівельна діяльність, ціни, клієнти й документи. Ромашка ТОВ

! Перевірити резерв товару.== Що можна інтегрувати з сайтом ==

K2 ERP створює замовлення покупця і резервує товар JSON часто застосовують, коли потрібно для API. # Описано доставку. Audit log має фіксувати:

  • дату і час;
  • напрям обміну;
  • endpoint;
  • тип об’єкта;
  • ID на сайті;
  • ID в ERP;
  • статус;
  • помилку;
  • payload або його безпечну частину;
  • повторну спробу;
  • користувача або сервіс;
  • час відповіді. У K2 ERP інтеграційні функції ERP з сайтом здатна забезпечувати обмін між ERP і вебресурсом компанії. Якщо сайт здатна “все”, то перша ж помилка або атака здатна зробити “все” дуже буквально. |}

API краще для оперативного обміну, замовлень, статусів, оплат і кабінету клієнта. Конфлікт виникає, коли сайт і ERP мають різні інформаційні дані.=== Чому критично передавати доступний залишок, а не фізичний? ===

інтеграційні функції ERP з сайтом у K2 ERP

Що таке інтеграційні функції ERP з сайтом?

"site_order_id": "WEB-2026-000125",

конкурентні переваги:

Куди потрапляють замовлення з сайту? Для інтеграції критично мати ID об’єктів.
{

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

У ERP така форма здатна створити ліда, задачу менеджеру, сервісну заявку або звернення підтримки. ],
== Типові питання ==
"amount": 2400.00,
"name": "Товар А",
- створює рекламацію.

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

"prices": [

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

</syntaxhighlight> Передаються:

Сайт здатна передавати в ERP не тільки замовлення, а й форми. ↓

Передаються: Приклад: Помилки інтеграції неминучі. Скопіював замовлення. }

"stock": [
складський облік збирає замовлення
Іноді сайт функціонує разом із маркетплейсами. ТОВ “Ромашка”
  • номер платежу;
  • платіжна платформа;
  • сума;
  • валюта;
  • статус;
  • дата;
  • комісія;
  • замовлення;
  • клієнт ERP;
  • transaction id;
  • підтвердження платежу.
    [[Категорія:Audit log]]
    
    == Файловий обмін ==
    інтеграційні функції ERP з сайтом потрібна для:
    ! 2. Бо товар, який уже зарезервований під іншого клієнта, — це не товар “можна купити”, а майбутній конфлікт.<syntaxhighlight lang="text">
    
    == Що таке інтеграційні функції ERP з сайтом ==
    == Обробка замовлення з сайту в ERP ==

</syntaxhighlight>

клієнт ERP оформлює замовлення

Якщо ERP бачить site_order_id, вона не створює друге замовлення. # виступає як API або формат файлів. ↓

{

  • ПІБ або назва компанії;
  • телефон;
  • email;
  • ЄДРПОУ або ІПН;
  • адреса;
  • контактна особа;
  • тип клієнта;
  • сегмент;
  • джерело;
  • згода на обробку даних;
  • особистий кабінет;
  • реквізити;
  • договори. XML теж застосовується для, особливо в старіших або формалізованих інтеграціях. {
інтеграційні функції ERP з сайтом — це автоматичний обмін даними між сайтом або інтернет-магазином і внутрішньою системою компанії: ERP, CRM, складом, фінансами або сервісом.
 "currency": "UAH",

ERP перевіряє клієнта, ціни, залишки

* спосіб доставки;
* перевізник;
* адреса;
* складський облік відвантаження;
* номер ТТН;
* статус доставки;
* вартість доставки;
* дата відправлення;
* дата доставки;
* контакт отримувача;
* коментар. ! # Запустити пілот. Бо якщо ERP, сайт і маркетплейс одночасно вирішують, яка ціна правильна, клієнт ERP купить там, де помилка найвигідніша. інтеграційні функції ERP — це двері між вітриною і реальним бізнесом. Файловий обмін застосовується для, коли API немає або інтеграційні функції ERP проста. ! ↓

* REST API;
* GraphQL API;
* webhooks;
* плагіни;
* модулі обміну;
* експорт-імпорт файлів;
* власну базу даних;
* обмеження інтеграції. # Налаштувати повторну відправку. "description": "Пошкоджено корпус товару",

Приклад:
<syntaxhighlight lang="xml">
 <stock>15</stock>
Краще:
 "erp_order_id": "SO-2026-00125",
інтеграційні функції ERP з сайтом має бути захищена. інтеграційні функції ERP саме для того, щоб таких сцен було менше. {| class="wikitable" style="width:100%;"

* кількість замовлень із сайту;
* конверсія замовлень;
* сума продажів;
* середній чек;
* популярні товари;
* товари без залишку;
* замовлення з помилками інтеграції;
* дублікати клієнтів;
* час обробки замовлення;
* частка оплат онлайн;
* рекламації з сайту;
* повернення;
* SLA обробки замовлень;
* джерела трафіку;
* ефективність акцій;
* маржа по онлайн-продажах. Напрям
Типи цін:
== інтеграційні функції ERP залишків ==
 },

 "payment_id": "PAY-WEB-00125",

== Приклад мапінгу полів ==
K2 ERP передає товари, ціни й залишки на сайт
Потрібно контролювати:
Передаються:

Замовлення з сайту має автоматизовано потрапляти в ERP. ТОВ Ромашка

 "site_order_id": "WEB-2026-000125",
{
Приклад:

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

! # Налаштувати безпеку. # виступає як тестове середовище. ! Питання

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

</syntaxhighlight>

- провідний принцип Визначити джерело правди для кожного типу даних. }

Краще:

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

інтеграційні функції ERP з CMS

"erp_order_id": "SO-2026-00125"
]
  • різна ціна;
  • різний залишок;
  • різний статус;
  • різний клієнт ERP;
  • дубль замовлення;
  • замовлення скасоване на сайті, але активне в ERP;
  • товар видалений на сайті, але активний в ERP;
  • оплата виступає як на сайті, але немає в ERP. Приклад:
"name": "ТОВ клієнт ERP",
"type": "demo_request",
<sku>ITEM-001</sku>

інтеграційні функції ERP з сайтом — це налаштований обмін даними між сайтом і внутрішніми системами компанії. {| class="wikitable" style="width:100%;"

"stock": 15,
 "items": [

Приклад:

* очікує оплати;
* оплачено;
* частково оплачено;
* помилка оплати;
* повернення коштів;
* скасовано;
* chargeback;
* потребує перевірки. Значення
Хто виступає як джерелом правди для даних? }
== Дублі клієнтів ==
XML зручний для суворих схем, але зазвичай більш громіздкий, ніж JSON. ERP: товар зарезервований під іншого клієнта. Показник
|-
| product.sku
| Номенклатура.Артикул
| Унікальний артикул товару
|-
| product.name
| Номенклатура.Назва
| Назва товару
|-
| order.id
| ЗамовленняПокупця.ExternalID
| ID замовлення на сайті
|-
| customer.email
| Контрагент.Email
| Для пошуку клієнта
|-
| payment.status
| Оплата.Статус
| paid, pending, failed
|}

1. # виступає як обробка помилок. ! Перевірити створення замовлення в ERP. Перевірив товар. Якщо сайт продає фізичний залишок без урахування резервів, клієнт ERP здатна купити товар, якого фактично вже немає для продажу. Коментар

{

<syntaxhighlight lang="json">
}
 "sku": "ITEM-001",
|-
| Сайт
| Створення замовлень, читання товарів, цін і залишків
|-
| Особистий кабінет
| Читання документів тільки свого клієнта
|-
| Платіжний компонент
| Передача статусів оплат
|-
| Сервіс рекламацій
| Створення рекламацій і вкладень
|-
| Адміністратор інтеграції
| Перегляд логів і повтор обміну
|}

! Замовлення не передаються 6 годин.
{
Перевірити відповідь сайту клієнту.</syntaxhighlight>

ERP передає на сайт доступний залишок:

8. клієнт ERP бачить оновлення версій в кабінеті

</syntaxhighlight> Погано:

"site_order_id": "WEB-2026-000125",
"reason": "damaged_goods",
ITEM-001,Насос NP-100,1200,15
Сьогодні “тільки залишки”, завтра хтось створює фальшиве замовлення, післязавтра фінансовий відділ вивчає нові слова. * в реальному часі;
* кожні кілька хвилин;
* раз на годину;
* раз на день;
* за подією;
* вручну за кнопкою;
* пакетно вночі. Коли щось падає, без нього всі без зусиль дивляться одне на одного й кажуть: “У нас усе відправилось”. # Запустити в промислову експлуатацію. Приклад:
Ціни ведуться в ERP. # Описати, які інформаційні дані передаються. # Налаштувати обробку помилок. "type": "wholesale",

клієнт ERP бачить статус у кабінеті

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

* загальний залишок;
* залишок по складах;
* доступний залишок;
* зарезервований залишок;
* очікуване надходження;
* дату поставки;
* мінімальну кількість для продажу;
* статус “під замовлення”;
* статус “немає в наявності”. "payment_status": "paid",
</div>
Приклади форм:

Приклади:

== Помилка: ціни змінюються вручну на сайті ==

 ↓
  • клієнт ERP;
  • замовлення;
  • товар;
  • партія або серійний номер;
  • причина;
  • SEO-опис проблеми;
  • фото;
  • відео;
  • бажане рішення для бізнесу;
  • контакт;
  • дата. Вставив у ERP. |-
Основні технології API, JSON, XML, webhooks, файловий обмін, middleware.== Права доступу ==

ITEM-002,Фільтр F-20,350,40

XML в інтеграції з сайтом

API інтеграційні функції ERP

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

↓

</syntaxhighlight>

"brand": "ExampleBrand",

5. Менеджер має третю в Excel. Де застосовується для

  • створення товару;
  • оновлення версій ціни;
  • оновлення версій залишку;
  • створення замовлення;
  • оплату;
  • скасування;
  • часткову оплату;
  • доставку;
  • повернення;
  • рекламацію;
  • дубль замовлення;
  • помилковий JSON;
  • timeout;
  • недоступність API;
  • неправильний токен;
  • відсутнє поле;
  • великі обсяги даних. # Описано оплати. # Провести тестування. Перевірити статус оплати. клієнт ERP: оплачує. Помилився в одному символі. Типовий бізнес-процес:
"price": 1200.00

</syntaxhighlight>

↓
Що це? # виступає як HTTPS.
↓

клієнт ERP здатна бачити: Сайт здатна бути побудований на CMS або e-commerce платформі. "category": "Промислове обладнання",

інтеграційні функції ERP відповідає на питання: Менеджер: вибачається. Приклад:

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

Як сайт отримує документи? * Сайт K2 ERP

інтеграційні функції ERP здатна впасти непомітно. Передаються: Приклад: { Формується доставка

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

{

 "shipped_at": "2026-05-16T16:45:00"
 "phone": "+380000000000"

 },

* товари;
* ціни;
* залишки;
* замовлення;
* статуси;
* доставки;
* повернення;
* рекламації;
* комісії. Бо ручне копіювання замовлень — це не цифровізація, а Excel-фітнес для терплячих людей.<syntaxhighlight lang="json">

Ціни можуть змінюватися в ERP і автоматизовано передаватися на сайт. Для системи без правил — чотири різні клієнти і майбутнє свято в актах звірки. Приклад односторонньої інтеграції:
Проблема виникає, коли сайт показує “в наявності”, менеджер каже “немає”, а ERP мовчить, бо її ніхто не питав. Сайт має отримувати ціни й доступні залишки з внутрішньої системи, а не жити окремим життям. # Описано клієнтів.<syntaxhighlight lang="text">
POST /api/orders

 {

== Джерело правди ==
Найчастіше інтегрують товари, ціни, залишки, замовлення, клієнтів, оплати, статуси доставки, документи, заявки й рекламації. Тоді сайт стає не окремою вітриною, а повноцінною частиною керованого бізнес-процесу. # Описано товари, ціни, залишки. |-
| базовий ризик
| Різні інформаційні дані на сайті й в ERP: ціни, залишки, клієнти, статуси. Якщо дверей немає, хтось бігає туди-сюди з блокнотом і героїчно помиляється. Статуси дозволяють клієнту бачити, що відбувається із замовленням. Він не дурний. Отримав маленький бізнес-квест. Коментар
'''Webhook''' — це повідомлення про подію. ! - бачить статус доставки;
[[Категорія:Ціни]]
<syntaxhighlight lang="json">
 <price currency="UAH">1200.00</price>

Замовлення з сайту не створилося в ERP через timeout. інтеграційні функції ERP з сайтом часто потрібна для особистого кабінету клієнта. Наслідок

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

 "currency": "UAH"
Статуси оплати:
7. "sku": "ITEM-001",
</product>
! # виступає як унікальні ідентифікатори. ]
 ↓
2.<syntaxhighlight lang="text">
== Power BI для інтеграції з сайтом ==
{| class="wikitable" style="width:100%;"
== B2B-портал ==
ERP має:
}

'''API''' — це інтерфейс, через який сайт і ERP обмінюються даними. Ручне редагування цін на сайті обмежене або заборонене. Файловий обмін простіший, але часто повільніший і менш зручний для обробки помилок.[[Категорія:BI]]

3. # виступає як моніторинг. Статус
! Корисні дашборди:

Приклад:
функції ERP:
 "customer_id": "WEB-CUST-00125",
|-
| Замовлень із сайту за місяць
| 2 450
|-
| Успішно передано в ERP
| 98,7%
|-
| Помилок інтеграції
| 32
|-
| Середній час створення замовлення в ERP
| 12 секунд
|-
| Онлайн-оплат
| 64%
|-
| Рекламацій із сайту
| 18
|}

Якщо обмін не пройшов, потрібен механізм повторної відправки. "attachments": ["photo1.jpg", "photo2.jpg"]
 "status": "paid",
Сайт отримує ціни автоматизовано. Перед запуском потрібно протестувати:

клієнт ERP оформлює замовлення на сайті

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

Приклад: ТОВ "Ромашка"

↓

Приклад:

"provider": "payment_gateway",

Залишки потрібні, щоб сайт показував реальну доступність товару. Джерело правди }

ERP створює замовлення покупця
Особливості:
<syntaxhighlight lang="text">
<syntaxhighlight lang="http">
}
Причина:

 "price": 1050.00

Фізичний залишок - резерв = доступно для продажу.
<name>Товар А</name>

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

Поганий сценарій:

↓
"delivery_method": "nova_poshta"

Content-Type: application/json

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

"paid_at": "2026-05-16T12:05:00",

}

"tracking_number": "20450000000000",

<syntaxhighlight lang="csv">

}

<syntaxhighlight lang="text">

Прийнято Нове замовлення Замовлення отримано
Підтверджено Погоджено Менеджер перевірив замовлення
Комплектується На відборі складський облік збирає товар
Відправлено Відвантажено Товар передано перевізнику
Доставлено Закрито Замовлення виконано
Скасовано Скасовано Замовлення не виконується

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

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

Якщо джерело правди не визначене, інформаційні дані оперативно починають сперечатися між собою.
# Описати мапінг полів. "name": "Насос промисловий NP-100",

<syntaxhighlight lang="json"> <syntaxhighlight lang="text">

"comment": "Хочу демо K2 ERP для виробництва"

<syntaxhighlight lang="json">

"form_id": "FORM-2026-00045",
"created_at": "2026-05-16T11:25:00",

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

== Повторна відправка ==