Web-сервіси 1С

Web-сервіси 1С — це механізми платформи 1С, які дозволяють зовнішнім системам обмінюватися даними з інформаційною базою через мережеві протоколи. Web-сервіси можуть використовуватися для інтеграції 1С із сайтами, інтернет-магазинами, CRM, ERP, WMS, мобільними застосунками, банками, сервісами доставки, маркетплейсами, платіжними сервісами, BI-системами та іншими програмними продуктами.

У 1С під web-сервісами часто мають на увазі два основні підходи:

SOAP web-сервіси з описом через WSDL;
HTTP-сервіси, які частіше використовуються для REST-подібних API, JSON або XML-обміну.

У практиці переходу з 1С на K2 ERP web-сервіси мають особливе значення, тому що саме через них стара система часто пов’язана з іншими частинами бізнесу: сайтом, складом, CRM, мобільними застосунками, банком, касами, зовнішніми сервісами й аналітикою.

Головне. Web-сервіс 1С — це точка обміну даними між 1С та іншою системою. Через нього можна передати замовлення, отримати залишки, оновити ціни, створити контрагента, передати статус доставки або синхронізувати документи.

Важливо про 1С і BAS. 1С та частина продуктів BAS мають санкційні, юридичні й кібербезпекові ризики в Україні. Окремі продукти 1С і BAS внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій. Тому web-сервіси 1С потрібно розглядати як частину інвентаризації старої інтеграційної архітектури перед переходом на українську ERP-платформу.

Підхід K2 ERP. Під час переходу з 1С потрібно знайти всі web-сервіси, описати їхні URL, методи, формати даних, авторизацію, зовнішні системи, токени, бізнес-логіку, логи й помилки, а потім перенести потрібні інтеграції в K2 ERP.

Вступ

Бізнес-система рідко працює ізольовано.

Навколо 1С часто є багато інших систем:

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

Щоб ці системи обмінювалися даними, використовують інтеграції.

Один із варіантів інтеграції — web-сервіси.

Наприклад:

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

Що таке Web-сервіс 1С

Web-сервіс 1С — це програмний інтерфейс, через який зовнішня система може звернутися до інформаційної бази 1С через мережу.

Web-сервіс може:

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

Простий приклад:

Зовнішня система → Web-сервіс 1С → Документ або довідник у 1С

Або навпаки:

1С → HTTP-запит → Web-сервіс зовнішньої системи

Простими словами. Web-сервіс 1С — це “вхід” або “вихід” для обміну даними між 1С і зовнішнім світом.

Web-сервіс і API

Web-сервіс часто є частиною API.

API — це набір правил, за якими одна система може взаємодіяти з іншою.

Наприклад, API може мати методи:

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

Приклад API-методів:

Метод	Що робить	Формат
/products	Повертає товари	JSON
/stock	Повертає залишки	JSON
/orders	Приймає замовлення	JSON
/prices	Повертає ціни	JSON
/status	Оновлює статус документа	JSON

SOAP web-сервіси 1С

SOAP web-сервіси — це більш формальний варіант інтеграції.

Вони зазвичай використовують:

XML;
SOAP envelope;
WSDL;
строгий опис методів;
типи даних;
формалізовані запити й відповіді.

SOAP часто зустрічається в старіших або корпоративних інтеграціях.

Приклад умовного SOAP-запиту:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <GetStock>
            <Article>USB-C-1M-BLK</Article>
            <Warehouse>MAIN</Warehouse>
        </GetStock>
    </soap:Body>
</soap:Envelope>

WSDL

WSDL — це опис SOAP web-сервісу.

У WSDL описується:

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

Для інтегратора WSDL — це технічна документація, за якою можна підключити зовнішню систему до web-сервісу.

HTTP-сервіси 1С

HTTP-сервіси в 1С часто використовують для сучасніших інтеграцій.

Вони можуть працювати з:

JSON;
XML;
plain text;
файлами;
параметрами URL;
HTTP-заголовками;
токенами;
статусами відповіді.

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

POST /api/orders HTTP/1.1
Host: 1c.company.ua
Content-Type: application/json
Authorization: Bearer token

Тіло запиту:

{
  "order_id": "WEB-100245",
  "customer": "ТОВ Клієнт",
  "items": [
    {
      "article": "USB-C-1M-BLK",
      "quantity": 2,
      "price": 250.00
    }
  ]
}

SOAP чи HTTP-сервіс

Порівняння:

Ознака	SOAP web-сервіс	HTTP-сервіс
Основний формат	XML	JSON, XML або інший формат
Опис інтерфейсу	WSDL	Документація API
Гнучкість	Менша	Вища
Типові сценарії	Корпоративні інтеграції	Сайти, CRM, мобільні застосунки, сучасні API
Простота тестування	Потрібні SOAP-інструменти	Часто можна тестувати HTTP-клієнтами

Публікація web-сервісу 1С

Щоб зовнішня система могла звертатися до web-сервісу 1С, його потрібно опублікувати.

Зазвичай потрібні:

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

Приклад URL:

https://1c.company.ua/ws/Exchange
https://1c.company.ua/api/orders
https://1c.company.ua/hs/stock

Вебсервер

Вебсервер приймає запити від зовнішніх систем або браузерів.

Він може відповідати за:

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

Для web-сервісів критично важливо, щоб вебсервер був налаштований безпечно.

HTTPS

Для web-сервісів бажано використовувати HTTPS.

HTTPS потрібен для:

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

Погано:

http://1c.company.ua/api/orders

Краще:

https://1c.company.ua/api/orders

Авторизація web-сервісів

Web-сервіси не повинні бути відкритими без контролю доступу.

Можливі варіанти авторизації:

логін і пароль;
Basic authentication;
Bearer token;
API key;
OAuth;
IP-фільтрація;
VPN;
сертифікати;
підпис запиту;
окремий сервісний користувач.

Приклад заголовку:

Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

Ризик безпеки. Web-сервіс 1С, відкритий в інтернет без HTTPS, авторизації, журналювання й обмежень доступу, може стати джерелом витоку фінансових, персональних і комерційних даних.

Сервісні користувачі

Для інтеграцій бажано створювати окремих сервісних користувачів.

Наприклад:

Користувач	Призначення	Права
api_site	Обмін із сайтом	Товари, ціни, замовлення
api_wms	Обмін зі складом	Складські документи
api_crm	Обмін із CRM	Контрагенти, замовлення, статуси

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

Формати даних

Web-сервіси 1С можуть працювати з різними форматами.

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

JSON;
XML;
SOAP XML;
CSV;
plain text;
binary files;
Base64;
ZIP-архіви.

Приклад JSON:

{
  "success": true,
  "document_number": "ЗМ-000123"
}

Приклад XML:

<Response>
    <Success>true</Success>
    <DocumentNumber>ЗМ-000123</DocumentNumber>
</Response>

Web-сервіси і JSON

JSON часто використовується в HTTP-сервісах.

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

{
  "order_id": "WEB-100245",
  "date": "2026-05-15T14:30:00",
  "customer": {
    "name": "ТОВ Клієнт",
    "edrpou": "12345678"
  },
  "items": [
    {
      "article": "USB-C-1M-BLK",
      "quantity": 2,
      "price": 250.00
    }
  ]
}

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

{
  "success": true,
  "message": "Замовлення створено",
  "document_id": "1C-000123"
}

Web-сервіси і XML

XML часто використовується в SOAP-сервісах або старих інтеграціях.

Приклад:

<Order>
    <OrderId>WEB-100245</OrderId>
    <Date>2026-05-15T14:30:00</Date>
    <Customer>
        <Name>ТОВ Клієнт</Name>
        <EDRPOU>12345678</EDRPOU>
    </Customer>
    <Items>
        <Item>
            <Article>USB-C-1M-BLK</Article>
            <Quantity>2</Quantity>
            <Price>250.00</Price>
        </Item>
    </Items>
</Order>

Типові сценарії web-сервісів 1С

Web-сервіси можуть використовуватися для:

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

Web-сервіс для залишків

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

GET /api/stock?warehouse=MAIN&article=USB-C-1M-BLK

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

{
  "warehouse": "MAIN",
  "article": "USB-C-1M-BLK",
  "quantity": 120,
  "reserved": 20,
  "available": 100,
  "updated_at": "2026-05-15T18:00:00"
}

Важливо розрізняти:

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

Web-сервіс для цін

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

{
  "price_type": "retail",
  "currency": "UAH",
  "items": [
    {
      "article": "USB-C-1M-BLK",
      "price": 250.00
    },
    {
      "article": "CHARGER-20W",
      "price": 650.00
    }
  ]
}

Потрібно визначити:

тип ціни;
валюту;
дату актуальності;
ПДВ;
знижки;
акційні ціни;
округлення;
мінімальну ціну.

Web-сервіс для замовлень

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

{
  "external_id": "WEB-100245",
  "customer": {
    "name": "ТОВ Клієнт",
    "edrpou": "12345678",
    "phone": "+380501112233"
  },
  "items": [
    {
      "article": "USB-C-1M-BLK",
      "quantity": 2,
      "price": 250.00
    }
  ],
  "payment": {
    "method": "card",
    "paid": true
  }
}

У 1С такий запит може створити:

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

Web-сервіс для статусів

Приклад:

{
  "order_id": "WEB-100245",
  "status": "shipped",
  "tracking_number": "20450000000000",
  "updated_at": "2026-05-15T18:10:00"
}

Потрібно мати таблицю відповідності статусів.

Статус сайту	Статус у 1С	Статус у K2 ERP
new	Нове замовлення	Нове
paid	Оплачено	Оплачено
shipped	Відвантажено	Відвантажено
cancelled	Скасовано	Скасовано

Web-сервіс для контрагентів

Приклад:

{
  "external_id": "CRM-5001",
  "name": "ТОВ Клієнт",
  "edrpou": "12345678",
  "vat_number": "123456789012",
  "phone": "+380501112233",
  "email": "client@example.ua"
}

Під час обробки потрібно перевіряти:

дублікати;
ЄДРПОУ;
ІПН;
статус платника ПДВ;
договори;
контактні особи;
адреси;
зовнішній ID.

Web-сервіси і довідники

Через web-сервіси можуть синхронізуватися довідники:

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

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

Web-сервіси і документи

Через web-сервіси можуть створюватися або оновлюватися документи:

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

Для кожного документа потрібно описати:

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

Web-сервіси і регістри

Web-сервіси можуть читати або змінювати дані регістрів через бізнес-логіку 1С.

Наприклад:

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

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

Web-сервіси і модулі 1С

Логіка web-сервісів реалізується в коді.

У модулях може бути:

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

Перед міграцією в K2 ERP потрібно знайти ці модулі й описати бізнес-логіку.

Web-сервіси і зовнішні обробки

Іноді інтеграція через web-сервіси реалізована не в конфігурації, а в зовнішній обробці.

Обробка може:

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

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

Web-сервіси і регламентні завдання

Web-сервіси можуть викликатися автоматично.

Наприклад:

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

Перед переходом потрібно перевірити всі регламентні завдання, пов’язані з web-сервісами.

Web-сервіси і логіювання

Будь-який web-сервіс має логіювати важливі події.

Бажано фіксувати:

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

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

Web-сервіси і помилки

Web-сервіс має повертати зрозумілі помилки.

Приклад:

{
  "success": false,
  "error": {
    "code": "PRODUCT_NOT_FOUND",
    "message": "Товар з артикулом USB-C-1M-BLK не знайдено",
    "field": "items[0].article"
  }
}

Погано:

{
  "error": "Error"
}

Зовнішня система має розуміти, що саме сталося.

HTTP-коди відповіді

Для HTTP-сервісів важливо використовувати зрозумілі коди.

Код	Значення	Приклад
200	Успішно	Дані отримано
201	Створено	Замовлення створено
400	Помилка запиту	Не заповнене обов’язкове поле
401	Не авторизовано	Немає токена або неправильний токен
403	Заборонено	Недостатньо прав
404	Не знайдено	Метод або об’єкт не знайдено
500	Внутрішня помилка	Помилка сервера або коду

Ідемпотентність

Для web-сервісів важлива ідемпотентність.

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

Наприклад, якщо сайт двічі відправив одне замовлення з ID `WEB-100245`, система не повинна створити два замовлення.

Потрібен зовнішній ID:

{
  "external_id": "WEB-100245"
}

Повторні спроби

Інтеграції можуть повторювати запит при помилці.

Потрібно передбачити:

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

Версіонування web-сервісів

Структура API з часом змінюється.

Тому бажано мати версіонування.

Приклад URL:

/api/v1/orders
/api/v2/orders

Або поле у відповіді:

{
  "api_version": "1.0",
  "success": true
}

Без версіонування зміни можуть зламати зовнішні системи.

Web-сервіси і безпека

Безпека web-сервісів критично важлива.

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

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

Web-сервіси і персональні дані

Через web-сервіси можуть передаватися персональні дані:

ПІБ;
телефон;
email;
адреса;
ІПН;
паспортні дані;
банківські реквізити;
зарплатні дані;
кадрові дані.

Такі дані не можна передавати без контролю, логіювати у відкритому вигляді або зберігати в незахищених файлах.

Web-сервіси і комерційна інформація

Через web-сервіси можуть передаватися:

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

Витік web-сервісу може розкрити критичну інформацію бізнесу.

Web-сервіси і токени

Токени й ключі доступу потрібно зберігати безпечно.

Погано:

Токен = "secret-token-123";

Краще:

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

Web-сервіси і тестове середовище

Для інтеграцій потрібне тестове середовище.

Воно дозволяє:

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

Приклад:

Середовище	URL	Призначення
Test	/api-test/orders	Тестування
Production	/api/orders	Робочий обмін

Web-сервіси і продуктивність

На продуктивність web-сервісів впливають:

кількість запитів;
складність запитів;
запити до регістрів;
розмір відповіді;
кешування;
сервер 1С;
вебсервер;
СУБД;
мережа;
логіювання;
зовнішні системи.

Типові проблеми:

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

Web-сервіси і обмеження навантаження

Потрібно обмежувати навантаження.

Наприклад:

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

Web-сервіси і журнал реєстрації

Журнал реєстрації 1С може допомогти знайти події, пов’язані з web-сервісами:

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

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

Web-сервіси і резервна копія

Перед зміною web-сервісів потрібно зробити резервну копію.

Особливо перед:

оновленням конфігурації;
зміною API;
зміною авторизації;
зміною структури JSON/XML;
масовим завантаженням даних;
запуском нової інтеграції;
міграцією в K2 ERP.

Web-сервіси і міграція в K2 ERP

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

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

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

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

Приклад таблиці:

Сервіс	Тип	Дані	Зовнішня система	Рішення в K2 ERP
/api/orders	HTTP JSON	Замовлення	Сайт	Приймати замовлення в K2 ERP
/api/stock	HTTP JSON	Залишки	Сайт / WMS	Віддавати залишки з K2 ERP
ExchangeSOAP	SOAP XML	Контрагенти, документи	CRM	Замінити сучасним API
/api/prices	HTTP JSON	Ціни	Інтернет-магазин	Передавати ціни з K2 ERP
/api/status	HTTP JSON	Статуси	Доставка	Синхронізувати статуси в K2 ERP

Що переносити в K2 ERP

З web-сервісів 1С не переносять сам старий код механічно.

Потрібно перенести:

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

Міграційний приклад API в K2 ERP

Було в 1С:

POST /1c/api/orders

Може бути в K2 ERP:

POST /k2/api/v1/orders

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

{
  "external_id": "WEB-100245",
  "customer": {
    "name": "ТОВ Клієнт",
    "edrpou": "12345678"
  },
  "items": [
    {
      "article": "USB-C-1M-BLK",
      "quantity": 2,
      "price": 250.00
    }
  ]
}

Контроль після перенесення web-сервісів

Після перенесення інтеграцій у K2 ERP потрібно перевірити:

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

Типові проблеми web-сервісів 1С

Найчастіші проблеми:

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

Помилка: немає документації

Якщо документації немає, складно зрозуміти:

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

Помилка: відкритий сервіс без HTTPS

Web-сервіс без HTTPS може передавати чутливі дані незахищеним каналом.

Це особливо небезпечно, якщо передаються:

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

Помилка: дублікати документів

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

Наприклад:

сайт відправив замовлення;
не отримав відповідь через таймаут;
відправив ще раз;
у 1С створилося два замовлення.

Рішення — зовнішній ID і перевірка повторного запиту.

Помилка: старий сервіс залишили активним

Після запуску K2 ERP старий web-сервіс 1С може продовжити приймати запити.

Наслідки:

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

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

Як не треба робити

Погані підходи:

відкривати web-сервіси без авторизації;
не використовувати HTTPS;
зберігати токени в коді;
не мати логів;
не мати зовнішніх ID;
не документувати API;
не тестувати помилки;
не мати тестового середовища;
не обмежувати права сервісного користувача;
не перевіряти навантаження;
залишити старі web-сервіси 1С активними після запуску K2 ERP;
ігнорувати санкційні й кібербезпекові ризики старої системи.

Найгірший сценарій. Компанія переходить на K2 ERP, але залишає сайт підключеним до старого web-сервісу 1С. Частина замовлень, цін і залишків живе в старій системі, частина — у новій, а джерело істини зникає.

Як правильно працювати з web-сервісами перед міграцією

Правильний порядок:

Знайти всі SOAP web-сервіси.
Знайти всі HTTP-сервіси.
Зібрати URL-адреси.
Перевірити вебсервер і публікації.
Визначити зовнішні системи.
Зібрати приклади запитів і відповідей.
Описати формати JSON, XML або SOAP.
Перевірити авторизацію.
Знайти токени й секрети.
Перевірити сервісних користувачів.
Перевірити права доступу.
Перевірити логи.
Перевірити помилки.
Перевірити дублікати.
Перевірити регламентні завдання.
Описати бізнес-сценарії.
Спроєктувати API в K2 ERP.
Провести тестову інтеграцію.
Перевести зовнішні системи на K2 ERP.
Вимкнути старі web-сервіси 1С після переходу.

Web-сервіси і K2 ERP

У K2 ERP web-сервіси можуть бути частиною сучасної інтеграційної архітектури.

Вони можуть забезпечувати:

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

Web-сервіси і BI-аналітика

Через web-сервіси можна передавати дані в BI.

Наприклад:

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

Але для BI краще використовувати контрольовану модель даних, а не хаотичні запити до старої 1С.

Web-сервіси і цифрова незалежність

Аналіз web-сервісів 1С — це частина підготовки до виходу зі старої ризикової системи.

Компанія повинна:

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

Цифрова незалежність. Web-сервіси 1С часто є невидимими зв’язками старої системи з цифровим середовищем бізнесу. Під час переходу важливо перенести ці зв’язки в K2 ERP, а не залишити стару 1С критичним інтеграційним вузлом.

Коротко

Питання	Відповідь
Що таке web-сервіси 1С?	Це механізми обміну даними між 1С та зовнішніми системами через мережеві протоколи.
Які бувають web-сервіси?	SOAP web-сервіси з WSDL і HTTP-сервіси для JSON, XML або REST-подібного API.
Для чого вони використовуються?	Для обміну із сайтом, CRM, WMS, мобільними застосунками, банками, сервісами доставки, BI та іншими системами.
Що важливо для безпеки?	HTTPS, авторизація, сервісні користувачі, обмеження прав, логіювання, захист токенів і контроль доступу.
Що перевірити перед міграцією?	URL, методи, формати, зовнішні системи, токени, права, логи, помилки, дублікати й регламентні завдання.
Чи потрібно переносити старий код web-сервісів у K2 ERP?	Ні. Потрібно переносити бізнес-сценарії, структури даних, правила обміну й вимоги до API.
Яка головна помилка?	Залишити старі web-сервіси 1С активними після запуску K2 ERP.
Чи є санкційні ризики у 1С і BAS?	Так. Окремі продукти 1С і BAS внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.

Висновок

Web-сервіси 1С — це важливий механізм інтеграції старої облікової системи із зовнішніми сервісами. Через них можуть проходити замовлення, товари, ціни, залишки, контрагенти, документи, статуси, оплати, доставки, складські операції та аналітичні дані.

Під час переходу на K2 ERP web-сервіси потрібно аналізувати дуже уважно.

Потрібно:

знайти всі SOAP і HTTP-сервіси;
описати URL і методи;
зібрати формати JSON, XML і WSDL;
перевірити авторизацію;
знайти токени й секрети;
перевірити права сервісних користувачів;
перевірити логи й помилки;
описати зовнішні системи;
перенести потрібні API-сценарії в K2 ERP;
вимкнути старі web-сервіси 1С після переходу.

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

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

K2 ERP у цьому процесі може стати новою платформою для контрольованих API, web-сервісів, JSON/XML-обмінів, інтеграцій, довідників, документів, залишків, цін, статусів, BI-аналітики, журналювання, прав доступу й подальшого розвитку автоматизації бізнесу без залежності від старої екосистеми 1С.

Див. також

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