Перегляд вихідного коду сторінки Клієнт-серверний режим BAS

{{DISPLAYTITLE:Клієнт-серверний режим BAS}}

{{SEO
|title=Клієнт-серверний режим BAS — сервер BAS, СУБД, тонкий клієнт, веб-клієнт, продуктивність і міграція в K2 ERP
|description=Клієнт-серверний режим BAS: що це таке, як працює сервер BAS/1С, СУБД, кластер серверів, тонкий клієнт, веб-клієнт, адміністрування, резервні копії, продуктивність, безпека, типові помилки і перехід з BAS у K2 ERP.
|keywords=клієнт-серверний режим BAS, BAS клієнт сервер, сервер BAS, сервер 1С, клієнт сервер 1С, СУБД BAS, SQL BAS, тонкий клієнт BAS, веб-клієнт BAS, кластер серверів 1С, інформаційна база BAS, адміністрування BAS, продуктивність BAS, резервна копія BAS, міграція з BAS, інтеграція з BAS, заміна BAS, K2 ERP, українська ERP, санкції BAS, санкції 1С, цифрова незалежність
|image=https://erp.kyiv.ua
}}

'''Клієнт-серверний режим BAS''' — це спосіб роботи інформаційної бази [[BAS]], при якому користувачі підключаються до системи через клієнтські застосунки, а основна обробка даних виконується на сервері [[BAS]] / [[1С]] і в системі керування базами даних. Такий режим використовується для більших баз, багатьох користувачів, складних облікових процесів, регламентних завдань, інтеграцій, web-доступу, підвищеної продуктивності й централізованого адміністрування.

На відміну від файлового режиму, де база зберігається у файлі, клієнт-серверний режим розділяє систему на кілька рівнів: клієнт, сервер застосунків і СУБД. Це дозволяє краще масштабувати роботу, контролювати доступ, виконувати фонові завдання, адмініструвати підключення користувачів і організовувати резервне копіювання на рівні бази даних.

<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Головне.''' Клієнт-серверний режим [[BAS]] — це архітектура, у якій користувач працює через клієнт, бізнес-логіка виконується на сервері BAS/1С, а дані зберігаються в СУБД. Такий режим потрібен для багатокористувацької роботи, великих баз, інтеграцій і стабільнішого адміністрування.
</div>

<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Важливо про BAS і 1С.''' [[BAS]] та [[1С]] мають санкційні, юридичні й кібербезпекові ризики в Україні. Окремі продукти [[1С]] і [[BAS]] внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій. Тому аналіз клієнт-серверної інфраструктури [[BAS]] варто розглядати як частину підготовки до контрольованого переходу на українську [[ERP]]-платформу.
</div>

<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Підхід K2 ERP.''' Під час переходу з [[BAS]] потрібно аналізувати не тільки довідники й документи, а й серверну архітектуру: де розміщена база, яка СУБД використовується, які є регламентні завдання, інтеграції, web-сервіси, користувачі, ролі, резервні копії, журнали й технічні обмеження.
</div>

__TOC__

== Вступ ==

Клієнт-серверний режим використовується тоді, коли звичайної файлової бази вже недостатньо.

Типові причини переходу на клієнт-сервер:

* багато одночасних користувачів;
* велика база даних;
* складні документи;
* багато регламентних завдань;
* активні інтеграції;
* обмін із сайтом;
* обмін із CRM;
* обмін із WMS;
* web-сервіси;
* потреба в централізованому адмініструванні;
* потреба в кращому контролі доступу;
* потреба в резервному копіюванні на рівні СУБД;
* потреба в стабільнішій роботі.

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

== Що таке клієнт-серверний режим BAS ==

'''Клієнт-серверний режим [[BAS]]''' — це архітектура, у якій система працює не як один файл на спільному диску, а як набір взаємопов’язаних компонентів.

Основні компоненти:

* клієнтський застосунок;
* сервер [[BAS]] / [[1С]];
* кластер серверів;
* СУБД;
* інформаційна база;
* регламентні завдання;
* web-сервер, якщо використовується web-доступ;
* інтеграційні сервіси;
* адміністрування;
* резервне копіювання.

Спрощена схема:

<syntaxhighlight lang="text">
Користувач → Клієнт BAS → Сервер BAS/1С → СУБД → Дані інформаційної бази
</syntaxhighlight>

<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Простими словами.''' У клієнт-серверному режимі користувач не працює напряму з файлом бази. Він підключається до сервера, а сервер уже звертається до бази даних.
</div>

== Файловий і клієнт-серверний режим ==

У [[BAS]] зазвичай розрізняють файловий і клієнт-серверний режим.

{| class="wikitable" style="width:100%;"
! Ознака
! Файловий режим
! Клієнт-серверний режим
|-
| Зберігання даних
| Файл бази
| СУБД
|-
| Підключення користувачів
| До файлової бази
| Через сервер BAS/1С
|-
| Масштабування
| Обмежене
| Краще для багатьох користувачів
|-
| Адміністрування
| Просте, але менш контрольоване
| Складніше, але гнучкіше
|-
| Резервне копіювання
| Копія файлу або вивантаження
| SQL-бекап, засоби СУБД, серверні процедури
|-
| Інтеграції
| Можливі, але обмежені
| Зручніше для web-сервісів і фонового обміну
|}

== Основні елементи архітектури ==

Клієнт-серверна архітектура BAS може включати:

* робочі місця користувачів;
* тонкий клієнт;
* товстий клієнт;
* веб-клієнт;
* сервер BAS/1С;
* кластер серверів;
* сервер СУБД;
* web-сервер;
* файлові каталоги обміну;
* сервер резервного копіювання;
* інтеграційні шлюзи;
* моніторинг;
* журнал реєстрації.

== Клієнт BAS ==

Клієнт — це програма або web-інтерфейс, через який користувач працює з базою.

Клієнт може бути:

* тонкий клієнт;
* товстий клієнт;
* веб-клієнт;
* мобільний або спеціальний клієнт, якщо він реалізований у конкретному рішенні.

Користувач через клієнт:

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

== Тонкий клієнт BAS ==

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

Тонкий клієнт часто використовують для:

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

Переваги:

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

== Веб-клієнт BAS ==

'''Веб-клієнт''' дозволяє працювати через браузер.

Для цього зазвичай потрібні:

* сервер BAS/1С;
* web-сервер;
* опублікована інформаційна база;
* налаштований доступ;
* HTTPS;
* права користувачів;
* контроль безпеки.

Веб-клієнт може бути корисним для:

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

<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Ризик безпеки.''' Публікація BAS у web без належного HTTPS, авторизації, обмеження доступу, журналювання й захисту може створити серйозні кібербезпекові ризики.
</div>

== Сервер BAS / 1С ==

Сервер BAS/1С — це проміжний рівень між клієнтами й СУБД.

Він відповідає за:

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

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

== Кластер серверів BAS ==

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

У кластері можуть бути:

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

Кластер допомагає централізовано керувати серверною роботою BAS.

== Робочі процеси ==

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

На них впливають:

* кількість користувачів;
* складність конфігурації;
* кількість звітів;
* кількість документів;
* запити до СУБД;
* обробки;
* інтеграції;
* регламентні завдання.

Якщо робочих процесів недостатньо або сервер слабкий, користувачі можуть відчувати повільну роботу.

== СУБД ==

СУБД — це система керування базами даних, у якій зберігаються дані інформаційної бази.

У СУБД зберігаються:

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

СУБД є критичною частиною клієнт-серверної архітектури.

== Інформаційна база ==

Інформаційна база в клієнт-серверному режимі — це не просто файл, а база в СУБД плюс конфігурація та дані.

Вона містить:

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

Для користувача база виглядає так само, як звичайна BAS, але технічно вона працює через сервер і СУБД.

== Підключення користувачів ==

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

Приклад:

<syntaxhighlight lang="text">
Користувач → Тонкий клієнт → Сервер BAS → Інформаційна база в СУБД
</syntaxhighlight>

Підключення може бути:

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

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

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

Сеанс може належати:

* звичайному користувачу;
* адміністратору;
* сервісному користувачу інтеграції;
* регламентному завданню;
* web-клієнту;
* фоновому процесу.

Адміністратор може контролювати:

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

== Регламентні завдання ==

Клієнт-серверний режим зручний для регламентних завдань.

Приклади:

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

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

== Фонові завдання ==

Фонові завдання — це процеси, які виконуються паралельно з роботою користувачів.

Наприклад:

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

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

== Продуктивність клієнт-серверного режиму ==

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

* потужність сервера BAS;
* потужність сервера СУБД;
* швидкість дисків;
* обсяг оперативної пам’яті;
* кількість користувачів;
* складність конфігурації;
* якість запитів;
* індекси в СУБД;
* регламентні завдання;
* інтеграції;
* мережа;
* резервне копіювання;
* антивірус;
* застаріле обладнання.

== Типові причини повільної роботи ==

Найчастіші причини:

* слабкий сервер;
* недостатньо оперативної пам’яті;
* повільні диски;
* перевантажена СУБД;
* багато фонових завдань;
* важкі звіти;
* неоптимальні запити;
* велика кількість старих документів;
* нетипова конфігурація з поганим кодом;
* інтеграції запускаються в робочий час;
* немає регламентного обслуговування СУБД.

== Приклад навантаження ==

{| class="wikitable" style="width:100%;"
! Сценарій
! Можливе навантаження
! Що перевірити
|-
| 10 користувачів
| Невелике
| Сервер, мережа, базові налаштування
|-
| 50 користувачів
| Середнє
| СУБД, пам’ять, фонові завдання
|-
| 100+ користувачів
| Високе
| Архітектуру, кластер, СУБД, індекси, інтеграції
|-
| Багато web-сервісів
| Нерівномірне
| API, черги, логи, таймаути
|}

== Резервне копіювання ==

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

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

* резервна копія засобами СУБД;
* вивантаження інформаційної бази;
* знімок сервера;
* копія віртуальної машини;
* копія файлових каталогів обміну;
* копія зовнішніх обробок;
* копія web-публікацій;
* копія налаштувань інтеграцій.

<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">
'''Важливо.''' Резервна копія клієнт-серверної BAS має включати не тільки дані в СУБД, а й пов’язані файли, обробки, інтеграційні каталоги, налаштування сервера і документацію відновлення.
</div>

== Відновлення з резервної копії ==

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

Потрібно перевіряти:

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

== Адміністрування клієнт-серверної BAS ==

Адміністрування включає:

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

== Користувачі і ролі ==

У клієнт-серверному режимі важливо правильно налаштувати користувачів.

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

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

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

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

Наприклад:

{| class="wikitable" style="width:100%;"
! Користувач
! Призначення
! Ризик
|-
| api_site
| Обмін із сайтом
| Може мати надмірні права
|-
| api_crm
| Обмін із CRM
| Може бачити персональні дані
|-
| exchange_wms
| Обмін зі складом
| Може змінювати складські документи
|-
| bi_export
| Вивантаження в BI
| Може читати фінансові дані
|}

Під час міграції в [[K2 ERP]] потрібно знайти всі сервісні облікові записи.

== Безпека клієнт-серверного режиму ==

Безпека має включати:

* контроль користувачів;
* складні паролі;
* обмеження адміністраторів;
* обмеження доступу до сервера;
* захист СУБД;
* захист резервних копій;
* HTTPS для web-доступу;
* VPN для віддаленої роботи;
* журналювання;
* антивірусний контроль;
* оновлення серверів;
* контроль інтеграцій;
* аудит сервісних користувачів.

== Доступ до СУБД ==

Прямий доступ до СУБД має бути обмежений.

Ризики прямого доступу:

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

Користувачі мають працювати через систему, а не напряму з таблицями СУБД.

== Журнал реєстрації ==

Журнал реєстрації допомагає аналізувати:

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

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

== Web-сервер і публікація бази ==

Якщо використовується web-клієнт або HTTP-сервіси, потрібна публікація бази на web-сервері.

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

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

== Інтеграції в клієнт-серверному режимі ==

Клієнт-серверна BAS часто є центром інтеграцій.

Інтеграції можуть бути з:

* сайтом;
* CRM;
* WMS;
* банком;
* касами;
* РРО / ПРРО;
* мобільними застосунками;
* BI;
* електронним документообігом;
* GPS;
* сервісами доставки;
* маркетплейсами;
* зовнішніми API.

Перед переходом у [[K2 ERP]] потрібно знайти всі інтеграції.

== Файлові каталоги обміну ==

Навіть у клієнт-серверному режимі можуть використовуватися файлові обміни.

Наприклад:

* XML;
* JSON;
* CSV;
* Excel;
* DBF;
* ZIP-архіви;
* банківські файли;
* файли сайту;
* файли складу;
* файли податкових документів.

Такі каталоги потрібно включити в інвентаризацію і резервне копіювання.

== Клієнт-серверний режим і оновлення BAS ==

Оновлення клієнт-серверної BAS потребує плану.

Перед оновленням потрібно:

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

== Тестова база ==

Тестова база в клієнт-серверному режимі потрібна для:

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

Тестова база має бути чітко відокремлена від робочої, щоб користувачі не ввели туди реальні документи.

== Клієнт-серверний режим і міграція в K2 ERP ==

Під час переходу з [[BAS]] у [[K2 ERP]] клієнт-серверну інфраструктуру потрібно аналізувати окремо.

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

* список інформаційних баз;
* сервери BAS/1С;
* сервери СУБД;
* web-публікації;
* регламентні завдання;
* фонові завдання;
* інтеграції;
* користувачів;
* ролі;
* сервісні облікові записи;
* резервні копії;
* зовнішні обробки;
* файлові каталоги;
* журнали;
* документацію.

== Інвентаризація серверної інфраструктури ==

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

{| class="wikitable" style="width:100%;"
! Об’єкт
! Приклад
! Що зробити при міграції
|-
| Сервер BAS
| srv-bas-01
| Зафіксувати роль і бази
|-
| СУБД
| sql-bas-01
| Зробити бекап і описати бази
|-
| Web-публікація
| /bas/erp
| Перевірити доступ і інтеграції
|-
| Регламентне завдання
| Обмін із сайтом
| Перенести сценарій у K2 ERP
|-
| Сервісний користувач
| api_site
| Замінити API-доступом K2 ERP
|}

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

З клієнт-серверної BAS не переносять сам сервер як є.

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

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

== Що залишити в архіві ==

Після запуску [[K2 ERP]] стара клієнт-серверна BAS може залишитися як архів.

В архіві можуть бути:

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

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

== Типові помилки клієнт-серверного режиму BAS ==

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

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

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

Наявність SQL-бекапу не гарантує, що база відновиться.

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

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

== Помилка: залишити старі інтеграції активними ==

Після переходу в [[K2 ERP]] стара BAS може продовжувати приймати або відправляти дані.

Ризики:

* сайт бере залишки зі старої BAS;
* CRM створює замовлення в старій BAS;
* BI читає старі дані;
* WMS синхронізується не з тією системою;
* користувачі бачать різні цифри;
* джерело істини зникає.

Після запуску [[K2 ERP]] старі інтеграції потрібно вимкнути або перевести в архівний режим.

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

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

Наприклад:

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

Якщо їх не перенести або не замінити, частина бізнес-процесів зупиниться.

== Помилка: не перевірити сервісних користувачів ==

Сервісні користувачі можуть мати доступ до великих обсягів даних.

Після міграції потрібно:

* знайти всі такі облікові записи;
* зрозуміти, для чого вони потрібні;
* вимкнути зайві;
* замінити доступ на API K2 ERP;
* змінити токени й паролі;
* перевірити журнали доступу.

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

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

* не робити резервну копію перед змінами;
* не перевіряти відновлення;
* не документувати сервери;
* не знати, де розміщена СУБД;
* не контролювати web-публікації;
* не знати всі інтеграції;
* не перевіряти регламентні завдання;
* не аналізувати сервісних користувачів;
* залишати BAS активною після запуску [[K2 ERP]];
* ігнорувати санкційні й кібербезпекові ризики.

<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Найгірший сценарій.''' Компанія переходить у [[K2 ERP]], але залишає клієнт-серверну BAS активною: web-сервіси працюють, регламентні завдання обмінюються даними, BI читає стару базу, а користувачі продовжують вводити документи у дві системи.
</div>

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

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

# Зробити резервну копію.
# Зафіксувати список інформаційних баз.
# Визначити сервер BAS/1С.
# Визначити сервер СУБД.
# Перевірити web-публікації.
# Перевірити користувачів.
# Перевірити сервісні облікові записи.
# Перевірити ролі й права.
# Перевірити регламентні завдання.
# Перевірити фонові завдання.
# Перевірити інтеграції.
# Перевірити файлові каталоги обміну.
# Перевірити зовнішні обробки.
# Перевірити журнал реєстрації.
# Перевірити резервне відновлення.
# Описати критичні процеси.
# Перенести потрібні сценарії в [[K2 ERP]].
# Вимкнути старі інтеграції після запуску.
# Перевести BAS в архівний режим.

== Клієнт-серверний режим і цифрова незалежність ==

Аналіз клієнт-серверної BAS — це частина виходу зі старої ризикової системи.

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

* знати, де розміщені її дані;
* контролювати сервери;
* контролювати доступи;
* контролювати резервні копії;
* знайти всі інтеграції;
* знайти всі web-публікації;
* перенести потрібні процеси в [[K2 ERP]];
* вимкнути старі канали обміну;
* не залишити BAS прихованим центром обліку;
* зменшити залежність від [[BAS]] і [[1С]].

<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Цифрова незалежність.''' Клієнт-серверна BAS часто є центральним вузлом старої ІТ-архітектури. Завдання міграції — не просто перенести дані, а забрати контроль над серверами, доступами, інтеграціями, резервними копіями й бізнес-процесами в [[K2 ERP]].
</div>

== Коротко ==

{| class="wikitable" style="width:100%;"
! Питання
! Відповідь
|-
| Що таке клієнт-серверний режим [[BAS]]?
| Це режим, у якому користувачі працюють через клієнт, бізнес-логіка виконується на сервері BAS/1С, а дані зберігаються в СУБД.
|-
| Чим він відрізняється від файлового режиму?
| У файловому режимі база зберігається у файлі, а в клієнт-серверному — у СУБД і обслуговується сервером.
|-
| Коли потрібен клієнт-сервер?
| Коли багато користувачів, велика база, складні звіти, інтеграції, web-доступ, регламентні завдання або високі вимоги до адміністрування.
|-
| Що важливо для безпеки?
| Контроль користувачів, HTTPS, VPN, обмеження доступу до СУБД, захист резервних копій, аудит сервісних облікових записів.
|-
| Що перевірити перед міграцією?
| Сервери, СУБД, бази, користувачів, ролі, регламентні завдання, інтеграції, web-публікації, резервні копії й журнали.
|-
| Чи потрібно переносити сервер BAS у [[K2 ERP]]?
| Ні. Потрібно перенести дані, процеси, інтеграції, права, API-сценарії, BI-показники й правила роботи.
|-
| Яка головна помилка?
| Залишити стару клієнт-серверну BAS активним центром інтеграцій після запуску [[K2 ERP]].
|-
| Чи є санкційні ризики у [[BAS]] і [[1С]]?
| Так. Окремі продукти [[1С]] і [[BAS]] внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.
|}

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

Клієнт-серверний режим [[BAS]] — це важлива архітектура для великих і середніх інформаційних баз. Він дозволяє працювати багатьом користувачам, виконувати регламентні завдання, обслуговувати інтеграції, використовувати СУБД, web-клієнт, фонові процеси й централізоване адміністрування.

Але під час переходу на [[K2 ERP]] клієнт-серверну BAS потрібно аналізувати дуже уважно.

Потрібно:

* зробити резервну копію;
* описати сервери;
* описати СУБД;
* описати інформаційні бази;
* перевірити користувачів і ролі;
* знайти всі інтеграції;
* перевірити web-публікації;
* перевірити регламентні завдання;
* перевірити резервне відновлення;
* перенести потрібні процеси в [[K2 ERP]];
* вимкнути старі інтеграції;
* залишити BAS тільки як архів, якщо це потрібно.

<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Правильний підхід.''' Клієнт-серверний режим [[BAS]] потрібно розглядати не лише як технічну інфраструктуру, а як карту старих бізнес-процесів, інтеграцій, доступів, регламентних завдань і ризиків, які потрібно контрольовано перенести або замінити в [[K2 ERP]].
</div>

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

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

== Див. також ==

* [[K2]]
* [[K2 ERP]]
* [[ERP]]
* [[BAS]]
* [[1С]]
* [[Конфігурація BAS]]
* [[Конфігурація 1С]]
* [[Файлова база 1С]]
* [[Тонкий клієнт 1С]]
* [[Веб-клієнт 1С]]
* [[Режим підприємства 1С]]
* [[Журнал реєстрації 1С]]
* [[Резервна копія 1С]]
* [[Оновлення 1С]]
* [[Web-сервіси 1С]]
* [[JSON 1С]]
* [[Інтеграція через файли]]
* [[Інтеграція через XML]]
* [[Інтеграція з BAS]]
* [[Інтеграція з 1С]]
* [[Міграція з BAS]]
* [[Міграція з 1С]]
* [[Заміна BAS]]
* [[Заміна 1С]]
* [[Довідники 1С]]
* [[Документи 1С]]
* [[Обробки 1С]]
* [[Модуль 1С]]
* [[Запити 1С]]
* [[API]]
* [[BI]]
* [[SQL]]
* [[JSON]]
* [[XML]]
* [[CSV]]
* [[Українське програмне забезпечення]]
* [[Автоматизація бізнесу]]
* [[Цифрова незалежність]]
* [[Деколонізація обліку]]

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

* [https://erp.kyiv.ua Сайт K2 ERP]
* [https://wiki.erp.kyiv.ua Wiki K2 ERP]
* [https://cloud.corp2.eu Хмара K2 ERP]
* [https://cip.gov.ua/ua/statics/perelik-zaboronenogo-do-vikoristannya-programnogo-zabezpechennya-ta-komunikaciinogo-merezhevogo-obladnannya Перелік забороненого до використання програмного забезпечення на сайті Держспецзв’язку]
* [https://cip.gov.ua/ua/news/vidpovidi-na-poshireni-zapitannya-shodo-pereliku-zaboronenogo-programnogo-zabezpechennya-ta-obladnannya Роз’яснення Держспецзв’язку щодо переліку забороненого ПЗ]
* [https://www.president.gov.ua/documents/6012024-52009 Указ Президента України №601/2024]
* [https://zakon.rada.gov.ua/go/601/2024 Указ Президента України №601/2024 на сайті Верховної Ради України]
* [https://t.me/+uIdWI1W6vndkMTAy Telegram-канал K2 ERP]
* [https://t.me/+6jFwAZM6TQliNTdi Група обговорення функціоналу та пропозицій]
* [https://www.linkedin.com/company/k2erp/ LinkedIn K2]

[[Категорія:K2]]
[[Категорія:K2 ERP]]
[[Категорія:ERP]]
[[Категорія:BAS]]
[[Категорія:1С]]
[[Категорія:Клієнт-серверний режим BAS]]
[[Категорія:Сервер BAS]]
[[Категорія:Сервер 1С]]
[[Категорія:Клієнт-серверний режим 1С]]
[[Категорія:СУБД]]
[[Категорія:SQL]]
[[Категорія:Тонкий клієнт 1С]]
[[Категорія:Веб-клієнт 1С]]
[[Категорія:Файлова база 1С]]
[[Категорія:Інформаційна база 1С]]
[[Категорія:Конфігурація BAS]]
[[Категорія:Конфігурація 1С]]
[[Категорія:Адміністрування BAS]]
[[Категорія:Резервна копія 1С]]
[[Категорія:Журнал реєстрації 1С]]
[[Категорія:Web-сервіси 1С]]
[[Категорія:JSON 1С]]
[[Категорія:API]]
[[Категорія:BI]]
[[Категорія:Інтеграція з BAS]]
[[Категорія:Інтеграція з 1С]]
[[Категорія:Міграція з BAS]]
[[Категорія:Міграція з 1С]]
[[Категорія:Заміна BAS]]
[[Категорія:Заміна 1С]]
[[Категорія:Права доступу]]
[[Категорія:Безпека]]
[[Категорія:Кібербезпека]]
[[Категорія:Українське програмне забезпечення]]
[[Категорія:Автоматизація бізнесу]]
[[Категорія:Цифрова незалежність України]]
[[Категорія:Деколонізація обліку]]