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

Інтеграція з WMS — це обмін даними між ERP-системою та Warehouse Management System, тобто системою управління складом. Така інтеграція дозволяє поєднати фінансовий, управлінський і товарний облік в K2 ERP з операційною складською логікою: прийманням товарів, розміщенням по комірках, відбором, пакуванням, відвантаженням, переміщенням, інвентаризацією, контролем партій, серій, термінів придатності та роботою зі штрихкодами.

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

Головне. ERP знає, що бізнес хоче зробити: купити, продати, перемістити, списати або інвентаризувати товар. WMS знає, як саме це виконати на складі: з якої комірки взяти, куди покласти, яким маршрутом відібрати, що просканувати і як підтвердити операцію.

Для K2 ERP. Інтеграція з WMS може реалізовуватися через API, JSON, події, черги повідомлень, webhooks, імпорт/експорт, окремі інтеграційні модулі, YML-описи структур, ORM-моделі та механізми синхронізації довідників, документів і залишків.

Практична ідея. Хороша інтеграція з WMS — це коли менеджер у K2 ERP бачить замовлення, склад реально відбирає товар у WMS, комірник сканує штрихкод, а залишки, статуси й документи автоматично синхронізуються без дзвінків “а ви вже відвантажили?”.

Важливо про 1С/BAS. 1С і BAS пов’язані з російською технологічною екосистемою та перебувають у санкційному полі України. Указ Президента України №133/2017 ввів у дію рішення РНБО від 28 квітня 2017 року щодо санкцій, а Указ №601/2024 — рішення РНБО від 2 вересня 2024 року щодо застосування, скасування та внесення змін до санкцій. Держспецзв’язку також оприлюднила перелік забороненого до використання програмного забезпечення та комунікаційного обладнання, де серед іншого згадуються продукти 1С, BAS та UA-Бюджет. ^[1] ^[2] ^[3]

Вступ

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

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

Саме для цього існують WMS-системи.

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

ERP і WMS мають різні ролі, але повинні працювати разом.

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

Що таке WMS

WMS або Warehouse Management System — це система управління складом, яка автоматизує фізичні складські операції.

WMS зазвичай відповідає за:

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

WMS працює ближче до фізичного складу, ніж ERP.

Якщо K2 ERP відповідає на питання “що потрібно продати, купити або перемістити”, то WMS відповідає на питання “де саме це лежить і як це взяти”.

Для чого потрібна інтеграція ERP і WMS

Інтеграція потрібна, щоб K2 ERP і WMS не жили окремими життями.

Без інтеграції виникають проблеми:

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

Інтеграція створює єдиний контур:

K2 ERP → завдання для складу → WMS → фактичне виконання → K2 ERP

Ролі K2 ERP і WMS

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

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

Інтеграція з WMS зазвичай охоплює кілька ключових сценаріїв:

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

Синхронізація довідників

Перед тим як обмінюватися документами, потрібно синхронізувати довідники.

Зазвичай з K2 ERP у WMS передаються:

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

Приклад довідника товару у форматі JSON:

{
  "product_id": 1001,
  "sku": "NB-001",
  "name": "Ноутбук Lenovo ThinkPad",
  "unit": "шт",
  "barcodes": [
    "4820000000011",
    "4820000000012"
  ],
  "weight": 1.8,
  "volume": 0.012,
  "active": true
}

Якщо довідники не синхронізовані, WMS не знатиме, що саме приймати, відбирати або сканувати.

Інтеграція номенклатури

Номенклатура — найважливіший довідник для WMS.

У K2 ERP товар може мати управлінські, облікові й комерційні властивості.

У WMS товар має ще й складські властивості:

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

Приклад YML-опису складських властивостей товару:

entity: product
title: "Номенклатура"
type: directory

fields:
  sku:
    type: string
    title: "Артикул"
    required: true

  name:
    type: string
    title: "Назва"
    required: true

  unit:
    type: string
    title: "Одиниця виміру"

  barcode:
    type: string
    title: "Основний штрихкод"

  weight:
    type: decimal
    title: "Вага"

  volume:
    type: decimal
    title: "Об'єм"

  batch_tracking:
    type: boolean
    title: "Партійний облік"
    default: false

  serial_tracking:
    type: boolean
    title: "Серійний облік"
    default: false

  expiry_tracking:
    type: boolean
    title: "Контроль терміну придатності"
    default: false

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

У простому складському обліку достатньо знати склад.

Наприклад:

Основний склад
Склад браку
Склад сервісу

У WMS цього мало.

WMS працює з адресним зберіганням:

Склад → Зона → Ряд → Стелаж → Полиця → Комірка

Приклад структури комірки:

{
  "warehouse": "MAIN",
  "zone": "A",
  "aisle": "03",
  "rack": "05",
  "level": "02",
  "cell": "A-03-05-02",
  "cell_type": "picking",
  "active": true
}

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

Приймання товару

Приймання — один із базових сценаріїв інтеграції.

Процес може виглядати так:

K2 ERP створює замовлення постачальнику
→ товар прибуває на склад
→ K2 ERP передає очікуване приймання в WMS
→ WMS виконує фактичне приймання
→ комірник сканує товари
→ WMS повертає фактичні кількості в K2 ERP
→ K2 ERP створює або оновлює документ надходження

Приклад очікуваного приймання:

{
  "receipt_id": "RC-000125",
  "supplier_id": 45,
  "warehouse": "MAIN",
  "expected_date": "2026-06-01",
  "items": [
    {
      "sku": "NB-001",
      "expected_quantity": 20
    },
    {
      "sku": "MN-001",
      "expected_quantity": 50
    }
  ]
}

Фактичне приймання

WMS може повернути фактичний результат приймання.

Наприклад:

{
  "receipt_id": "RC-000125",
  "status": "completed",
  "accepted_at": "2026-06-01T11:40:00",
  "items": [
    {
      "sku": "NB-001",
      "expected_quantity": 20,
      "accepted_quantity": 20,
      "cell": "A-01-01-01"
    },
    {
      "sku": "MN-001",
      "expected_quantity": 50,
      "accepted_quantity": 48,
      "cell": "A-01-02-01",
      "comment": "2 одиниці пошкоджено"
    }
  ]
}

Після цього K2 ERP може:

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

Відвантаження товару

Відвантаження — ще один ключовий сценарій.

Процес:

K2 ERP створює замовлення покупця
→ замовлення резервується
→ K2 ERP передає завдання на відбір у WMS
→ WMS формує маршрут відбору
→ комірник відбирає товар
→ товар пакується
→ WMS підтверджує відвантаження
→ K2 ERP створює видатковий документ

Приклад завдання на відвантаження:

{
  "shipment_id": "SH-000501",
  "customer_id": 125,
  "warehouse": "MAIN",
  "delivery_service": "Нова пошта",
  "items": [
    {
      "sku": "NB-001",
      "quantity": 2
    },
    {
      "sku": "KB-001",
      "quantity": 5
    }
  ]
}

Фактичне відвантаження

WMS може повернути фактично відвантажені товари:

{
  "shipment_id": "SH-000501",
  "status": "shipped",
  "shipped_at": "2026-06-01T16:20:00",
  "packages": [
    {
      "package_id": "PK-10001",
      "weight": 4.2,
      "tracking_number": "20400012345678"
    }
  ],
  "items": [
    {
      "sku": "NB-001",
      "requested_quantity": 2,
      "shipped_quantity": 2
    },
    {
      "sku": "KB-001",
      "requested_quantity": 5,
      "shipped_quantity": 5
    }
  ]
}

Після цього K2 ERP може оновити статус замовлення, створити реалізацію, передати номер ТТН клієнту або запустити інтеграцію зі службою доставки.

Резервування товару

Резервування — важливий момент між ERP і WMS.

У K2 ERP менеджер може створити замовлення клієнта й зарезервувати товар.

Але WMS має знати, що цей товар не можна віддати іншому замовленню.

Приклад резерву:

{
  "reservation_id": "RS-00077",
  "order_id": "SO-00215",
  "warehouse": "MAIN",
  "items": [
    {
      "sku": "NB-001",
      "quantity": 2
    }
  ]
}

Резерв може бути:

обліковим;
фізичним;
по складу;
по комірці;
по партії;
по серії;
з терміном дії.

Переміщення товарів

Переміщення може відбуватися між складами або всередині складу.

Між складами:

Основний склад → Склад сервісу

Всередині складу:

Комірка A-01-01-01 → Комірка B-03-02-04

У K2 ERP міжскладське переміщення може бути документом управлінського обліку.

У WMS внутрішньоскладське переміщення може бути операційним завданням.

Приклад:

{
  "movement_id": "MV-000301",
  "type": "internal",
  "warehouse": "MAIN",
  "items": [
    {
      "sku": "NB-001",
      "quantity": 10,
      "from_cell": "A-01-01-01",
      "to_cell": "B-02-01-03"
    }
  ]
}

Інвентаризація

Інвентаризація — це перевірка фактичних залишків.

У K2 ERP може створюватися документ інвентаризації.

WMS виконує фактичний підрахунок через сканування.

Процес:

K2 ERP створює документ інвентаризації
→ WMS отримує завдання на перерахунок
→ комірники сканують товари
→ WMS повертає фактичні залишки
→ K2 ERP формує розбіжності
→ відповідальні приймають рішення
→ створюються документи оприбуткування або списання

Приклад результату інвентаризації:

{
  "inventory_id": "INV-000045",
  "warehouse": "MAIN",
  "completed_at": "2026-06-02T18:10:00",
  "items": [
    {
      "sku": "NB-001",
      "system_quantity": 12,
      "actual_quantity": 12
    },
    {
      "sku": "MN-001",
      "system_quantity": 25,
      "actual_quantity": 24,
      "difference": -1
    }
  ]
}

Партії, серії та терміни придатності

Для багатьох складів важливо контролювати партії, серії та терміни придатності.

Це актуально для:

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

Приклад партійного обліку:

{
  "sku": "MED-001",
  "batch": "B-2026-05",
  "expiry_date": "2027-05-31",
  "quantity": 100
}

Приклад серійного обліку:

{
  "sku": "PHONE-001",
  "serial_numbers": [
    "SN000001",
    "SN000002",
    "SN000003"
  ]
}

K2 ERP має отримувати від WMS фактичні партії та серії, які були прийняті або відвантажені.

Штрихкоди і ТЗД

WMS часто працює з терміналами збору даних.

Комірник сканує:

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

Це зменшує кількість ручних помилок.

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

Приклад довідника штрихкодів:

{
  "sku": "NB-001",
  "barcodes": [
    {
      "barcode": "4820000000011",
      "unit": "шт"
    },
    {
      "barcode": "4820000000012",
      "unit": "коробка",
      "quantity": 10
    }
  ]
}

Статуси документів

Інтеграція має передавати не тільки дані, а й статуси.

Приклад статусів замовлення:

Статус у K2 ERP	Статус у WMS	Значення
Створено	Не отримано	Замовлення ще не передано в WMS
Передано на склад	New	WMS отримала завдання
Відбирається	Picking	Комірник виконує відбір
Упаковано	Packed	Товар підготовлено
Відвантажено	Shipped	Товар покинув склад
Помилка	Error	Потрібна ручна перевірка

Статуси дозволяють менеджерам бачити реальну картину.

Помилки інтеграції

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

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

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

Приклад помилки:

{
  "success": false,
  "error": {
    "code": "PRODUCT_NOT_FOUND",
    "message": "Товар з артикулом NB-001 не знайдено в WMS",
    "field": "items[0].sku"
  }
}

Помилки потрібно не ховати, а показувати відповідальним користувачам.

Журнал інтеграції

Для якісної інтеграції потрібен журнал обміну.

Він має фіксувати:

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

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

{
  "timestamp": "2026-06-01T16:25:00",
  "direction": "WMS_TO_K2",
  "document_type": "shipment",
  "document_id": "SH-000501",
  "status": "success",
  "duration_ms": 245
}

Журнал інтеграції — це чорна скринька літака. Коли щось пішло не так, без нього всі починають казати: “А в мене працювало”.

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

Існує кілька способів інтеграції з WMS.

Спосіб	Опис	Коли використовувати
API	Онлайн-обмін через HTTP/REST або інший API	Сучасний основний сценарій
Webhooks	WMS або K2 ERP повідомляє іншу систему про подію	Для статусів і подій
Черги повідомлень	Обмін через брокер повідомлень	Для надійного асинхронного обміну
Файловий обмін	CSV, XML, JSON-файли	Для старих або простих систем
Прямий доступ до БД	Читання/запис у таблиці	Небажано, тільки у виняткових випадках
Гібридний підхід	Комбінація API, файлів і черг	Для складних проєктів

API-інтеграція

API — найкращий варіант для сучасної інтеграції.

Переваги API:

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

Приклад endpoint-ів:

POST /api/wms/products
POST /api/wms/receipts
POST /api/wms/shipments
POST /api/wms/inventory
GET  /api/wms/shipments/{id}/status
POST /api/wms/events

Webhooks

Webhook дозволяє одній системі повідомити іншу про подію.

Наприклад, WMS може надіслати в K2 ERP подію про відвантаження:

{
  "event": "shipment.shipped",
  "shipment_id": "SH-000501",
  "timestamp": "2026-06-01T16:20:00"
}

Після цього K2 ERP може автоматично змінити статус замовлення.

Черги повідомлень

Черги повідомлень корисні, коли потрібно забезпечити надійність.

Наприклад, якщо WMS тимчасово недоступна, повідомлення не губиться, а чекає повторної обробки.

Черги корисні для:

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

Файловий обмін

Файловий обмін — старіший, але іноді практичний спосіб.

Формати:

CSV;
XML;
JSON;
XLSX.

Приклад:

K2 ERP формує файл shipments_20260601.json
WMS забирає файл
WMS обробляє відвантаження
WMS повертає файл shipment_result_20260601.json
K2 ERP імпортує результат

Цей спосіб простіший, але має недоліки: затримки, складність контролю помилок, ризик дублів і слабша онлайн-видимість.

Чому прямий доступ до бази небажаний

Іноді інтеграцію хочуть зробити через прямий доступ до бази даних.

Це небезпечний підхід.

Проблеми:

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

Краще використовувати API або інтеграційний модуль.

Архітектура інтеграції K2 ERP і WMS

Типова архітектура:

K2 ERP
  ↓ довідники, документи, завдання
Інтеграційний модуль
  ↓ API / черга / webhook
WMS
  ↓ фактичне виконання
Інтеграційний модуль
  ↓ статуси, залишки, результати
K2 ERP

Інтеграційний модуль потрібен, щоб:

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

YML-опис інтеграційного компонента

У K2 ERP інтеграційний компонент може бути описаний через YML.

Приклад:

component:
  name: wms_integration
  title: "Інтеграція з WMS"
  version: "1.0.0"

entities:
  wms_exchange_log:
    title: "Журнал обміну з WMS"
    type: register

    fields:
      direction:
        type: enum
        title: "Напрям"
        values:
          - k2_to_wms
          - wms_to_k2

      document_type:
        type: string
        title: "Тип документа"

      document_id:
        type: string
        title: "Ідентифікатор документа"

      status:
        type: enum
        title: "Статус"
        values:
          - success
          - error
          - pending

      request_payload:
        type: json
        title: "Запит"

      response_payload:
        type: json
        title: "Відповідь"

      created_at:
        type: datetime
        title: "Дата створення"

З такого опису можна автоматично створити частину структури інтеграційного модуля.

ORM для інтеграції

На основі YML можуть створюватися ORM-моделі.

Приклад умовної Python-моделі:

class WmsExchangeLog(BaseModel):
    id: int
    direction: str
    document_type: str
    document_id: str
    status: str
    request_payload: dict | None = None
    response_payload: dict | None = None
    created_at: datetime

Це дозволяє працювати з журналом інтеграції як із нормальним об’єктом системи.

Синхронізація залишків

Залишки — найчутливіша частина інтеграції.

Є кілька підходів:

Підхід	Опис	Ризик
ERP головна по залишках	K2 ERP вважає облікові залишки головними	Можливі розбіжності з фізичним складом
WMS головна по фізичних залишках	WMS відповідає за фактичні залишки по комірках	Потрібна якісна синхронізація з ERP
Гібридний підхід	ERP веде облік, WMS веде фізику	Потрібні правила звірки

Найчастіше правильний підхід такий:

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

Звірка залишків

Звірка залишків потрібна регулярно.

Приклад звірки:

Товар	Залишок K2 ERP	Залишок WMS	Різниця	Статус
NB-001	12	12	0	Добре
MN-001	25	24	-1	Потрібна перевірка
KB-001	80	80	0	Добре

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

Ідемпотентність операцій

В інтеграції важливо уникати дублювання.

Наприклад, якщо WMS двічі надіслала підтвердження відвантаження, K2 ERP не повинна двічі списати товар.

Для цього використовується ідемпотентність.

Кожна операція має унікальний ідентифікатор:

{
  "operation_id": "WMS-EVENT-000000123",
  "event": "shipment.shipped",
  "shipment_id": "SH-000501"
}

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

Версіонування API

API інтеграції має версіонуватися.

Наприклад:

/api/v1/wms/shipments
/api/v2/wms/shipments

Це дозволяє оновлювати інтеграцію без аварійного ламання старих клієнтів.

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

Інтеграція з WMS має бути захищеною.

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

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

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

Продуктивність інтеграції

На великому складі може бути багато подій.

Наприклад:

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

Тому інтеграція має бути продуктивною.

Важливо:

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

Моніторинг інтеграції

Інтеграція має контролюватися.

Потрібні показники:

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

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

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

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

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

Приклад правильної карти відповідальності

Дані або процес	Головна система	Коментар
Контрагенти	K2 ERP	WMS може отримувати тільки потрібні дані
Номенклатура	K2 ERP	WMS отримує складські властивості
Комірки	WMS	ERP може отримувати агреговану інформацію
Замовлення покупців	K2 ERP	WMS отримує завдання на відбір
Фактичний відбір	WMS	ERP отримує підтвердження
Фінансові документи	K2 ERP	WMS не повинна вести фінанси
Фізичні залишки по комірках	WMS	ERP отримує підсумки й розбіжності
Управлінські залишки	K2 ERP	Формуються на основі документів і підтверджень

Інтеграція з WMS при переході з 1С/BAS

Під час переходу з 1С/BAS на K2 ERP інтеграцію з WMS потрібно переглянути.

У старих системах обмін часто міг працювати через:

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

При переході на K2 ERP варто не копіювати старий механізм, а створити сучасну інтеграційну архітектуру через API, JSON, журнали обміну, черги та нормальні модулі.

Міграційне правило. Якщо стара інтеграція з WMS у 1С працювала тільки тому, що всі боялися її вимкнути, це не інтеграція. Це складський оберіг. У K2 ERP краще зробити нормально.

Санкційний аспект при заміні 1С/BAS

Якщо WMS була інтегрована з 1С або BAS, перехід на K2 ERP має враховувати не тільки технічний, а й санкційний аспект.

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

Використання 1С/BAS пов’язане з санкційним полем України: відповідні обмеження вводилися рішеннями РНБО через укази Президента України №133/2017 та №601/2024, а офіційний перелік забороненого до використання ПЗ ведеться Держспецзв’язку. ^[4] ^[5] ^[6]

Тому заміна інтеграції з 1С/BAS на інтеграцію з K2 ERP — це не просто технічний апгрейд, а частина цифрової незалежності компанії.

Приклад процесу інтеграції від замовлення до відвантаження

Крок	Система	Дія
1	K2 ERP	Створюється замовлення покупця
2	K2 ERP	Перевіряється доступність товару
3	K2 ERP	Формується завдання на відвантаження
4	Інтеграційний модуль	Передає завдання в WMS
5	WMS	Створює завдання на відбір
6	WMS	Комірник сканує товар і комірку
7	WMS	Підтверджує фактичний відбір
8	WMS	Пакує і відвантажує товар
9	Інтеграційний модуль	Передає результат у K2 ERP
10	K2 ERP	Оновлює статус замовлення і створює документи

Приклад процесу приймання

Крок	Система	Дія
1	K2 ERP	Створюється замовлення постачальнику
2	K2 ERP	Передається очікуване приймання в WMS
3	WMS	Комірник приймає товар
4	WMS	Скануються штрихкоди, партії, серії
5	WMS	Товар розміщується в комірки
6	WMS	Повертає фактичний результат
7	K2 ERP	Створює документ надходження
8	K2 ERP	Фіксує розбіжності, якщо вони є

Тестування інтеграції

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

Тестові сценарії:

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

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

Перед запуском потрібно перевірити:

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

Переваги інтеграції K2 ERP з WMS

Перевага	Пояснення
Точніші залишки	Фактичні складські операції швидше потрапляють в ERP
Менше ручної роботи	Документи й статуси синхронізуються автоматично
Швидше відвантаження	WMS оптимізує відбір і пакування
Кращий контроль складу	Видно комірки, партії, серії, розбіжності
Менше помилок	Сканування зменшує ручне введення
Краща аналітика	K2 ERP отримує фактичні дані для звітів
Масштабованість	Склад може рости без хаосу в обліку
Цифрова незалежність	Перехід від 1С/BAS до K2 ERP зменшує залежність від російської екосистеми

Ризики інтеграції

Ризик	Як зменшити
Розбіжності залишків	Регулярна звірка, чітка карта відповідальності
Дублі документів	Ідемпотентність і унікальні ідентифікатори
Помилки довідників	Єдині коди товарів, контроль штрихкодів
Відмова однієї системи	Черги, повторні спроби, журнал обміну
Неправильні статуси	Узгоджена статусна модель
Складність підтримки	Документація, API, моніторинг
Небезпечна інтеграція напряму в БД	Використовувати API або інтеграційний модуль

Коротко

Питання	Відповідь
Що таке інтеграція з WMS?	Це обмін даними між K2 ERP і системою управління складом для синхронізації документів, довідників, залишків, статусів і фактичних складських операцій.
За що відповідає K2 ERP?	За бізнес-документи, облік, продажі, закупівлі, фінанси, аналітику, довідники, інтеграції та управлінські процеси.
За що відповідає WMS?	За фізичне виконання складських операцій: приймання, розміщення, відбір, пакування, відвантаження, комірки, штрихкоди, партії й серії.
Який найкращий спосіб інтеграції?	Для сучасної архітектури — API, JSON, webhooks, черги повідомлень і інтеграційний модуль.
Чи можна інтегрувати через файли?	Так, але це менш гнучкий і менш оперативний спосіб, доречний для простих або старих систем.
Чи варто робити прямий обмін через базу даних?	Зазвичай ні. Це ризиковано для цілісності, безпеки й підтримки.
Що найважливіше в інтеграції?	Єдині довідники, статуси, журнал обміну, ідемпотентність, звірка залишків і чітке розділення відповідальності між ERP та WMS.
Чому це важливо при переході з 1С/BAS?	Бо старі інтеграції часто побудовані на застарілих механізмах, а 1С/BAS мають санкційні та технологічні ризики для українського бізнесу.

Висновок

Інтеграція з WMS — це один із ключових елементів сучасної складської автоматизації.

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

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

Для компаній, які переходять з 1С/BAS, інтеграція з WMS — це можливість не просто перенести старий обмін у нову систему, а побудувати сучасну API-first архітектуру без російської технологічної залежності, з нормальним журналом, моніторингом, статусами, повторними спробами й прозорою логікою.

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

Саме тому інтеграцію з WMS потрібно будувати не як тимчасовий обмін, а як повноцінний модуль K2 ERP: з API, JSON, YML, ORM, журналом обміну, моніторингом, безпекою, звіркою залишків і готовністю до масштабування.

Див. також

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

[1] ttps://zakon.rada.gov.ua/laws/show/133/2017

[2] ttps://zakon.rada.gov.ua/laws/show/601/2024

[3] ttps://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya

[4] ttps://zakon.rada.gov.ua/laws/show/133/2017

[5] ttps://zakon.rada.gov.ua/laws/show/601/2024

[6] ttps://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya

[1]

[2]

[3]

[4]

[5]

[6]