Конфігурація BAS

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

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

Головне. Конфігурація BAS — це не просто “програма”, а структура і логіка облікової системи: довідники, документи, регістри, звіти, ролі, модулі, форми, обробки, проводки, правила доступу й інтеграції.

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

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

Вступ

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

Але за всім цим стоїть конфігурація.

Вона визначає:

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

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

Що таке конфігурація BAS

Конфігурація BAS — це опис прикладної логіки інформаційної бази.

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

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

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

Частина конфігурації	Приклад
Довідник	Контрагенти, Номенклатура, Склади
Документ	Реалізація товарів, Надходження товарів, Касовий ордер
Регістр	Залишки товарів, Ціни номенклатури, Взаєморозрахунки
Звіт	Залишки на складах, Продажі, Оборотно-сальдова відомість
Обробка	Завантаження прайсу, Обмін із сайтом, Масова зміна цін

Простими словами. Конфігурація BAS — це “начинка” системи, яка визначає, які дані зберігаються, як вони обробляються і що бачить користувач.

Платформа і конфігурація

У BAS потрібно розрізняти платформу і конфігурацію.

Поняття	Що це таке	Приклад
Платформа	Технічна основа, на якій запускається прикладне рішення	Клієнт, сервер, мова, механізми бази
Конфігурація	Прикладна логіка для конкретної предметної області	Бухгалтерія, ERP, торгівля, зарплата, агро, громадське харчування
Інформаційна база	Конкретна база компанії з даними і конфігурацією	Робоча база підприємства

Одна і та сама платформа може запускати різні конфігурації.

Типова конфігурація BAS

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

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

BAS Бухгалтерія;
BAS ERP;
BAS Управління торгівлею;
BAS Комплексне управління підприємством;
BAS Зарплата та управління персоналом;
BAS Малий бізнес;
галузеві рішення BAS.

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

Нетипова конфігурація BAS

Нетипова конфігурація BAS — це конфігурація, яку змінювали під потреби конкретної компанії.

Зміни можуть бути різними:

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

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

Типова чи нетипова: чому це важливо

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

Ознака	Типова конфігурація	Нетипова конфігурація
Оновлення	Зазвичай простіше	Часто складніше
Міграція	Легше описати стандартні об’єкти	Потрібно аналізувати доробки
Документація	Частково є типова	Часто відсутня
Ризики	Нижчі	Вищі через невідомий код
Аналіз	Можна спиратися на стандартну структуру	Потрібен технічний аудит

Об’єкти метаданих BAS

Конфігурація складається з об’єктів метаданих.

Основні об’єкти:

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

Довідники в конфігурації BAS

Довідники зберігають відносно сталі об’єкти.

Наприклад:

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

У конфігурації визначається:

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

Приклад довідника

Приклад довідника “Номенклатура”:

Елемент	Приклад
Код	000001
Найменування	Кабель USB Type-C 1 м
Артикул	USB-C-1M-BLK
Одиниця виміру	шт
Група	Кабелі
Ставка ПДВ	20%

Якщо в компанії додали реквізити “Бренд”, “Серія”, “Країна походження”, “Код сайту”, це вже може бути доробкою конфігурації.

Документи в конфігурації BAS

Документи відображають господарські операції.

Наприклад:

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

У конфігурації документа визначається:

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

Приклад документа

Документ “Реалізація товарів” може мати:

Частина	Приклад
Організація	ТОВ “Компанія”
Контрагент	ТОВ “Клієнт”
Договір	Основний договір
Склад	Основний склад
Таблична частина	Товари, кількість, ціна, сума, ПДВ
Рухи	Зменшення залишків, дохід, взаєморозрахунки, ПДВ

Якщо проведення документа змінювалося програмістами, це потрібно обов’язково врахувати при міграції.

Регістри BAS

Регістри зберігають облікові рухи.

Основні типи:

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

Приклади:

Регістр	Для чого
Залишки товарів	Облік кількості на складах
Ціни номенклатури	Зберігання цін
Взаєморозрахунки	Борги покупців і постачальників
Регістр бухгалтерії	Бухгалтерські проводки
Зарплатні регістри	Нарахування й утримання

Рухи документів

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

Наприклад, реалізація може:

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

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

Плани рахунків

У бухгалтерських конфігураціях BAS є план рахунків.

Він визначає:

рахунки;
субрахунки;
аналітики;
валютний облік;
кількісний облік;
субконто;
типи рахунків;
правила проводок.

Приклад:

Рахунок	Призначення
281	Товари на складі
361	Розрахунки з покупцями
631	Розрахунки з постачальниками
301	Каса
311	Банк

Звіти в конфігурації BAS

Звіти показують дані користувачу.

Наприклад:

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

Звіт може бути типовим або доробленим.

Обробки в конфігурації BAS

Обробки виконують службові або бізнес-операції.

Наприклад:

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

Обробки можуть бути внутрішніми або зовнішніми.

Зовнішні обробки

Зовнішня обробка може зберігатися окремим файлом і не бути частиною основної конфігурації.

Це ризик для міграції, бо така обробка може бути критичною, але її можуть забути.

Приклади:

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

Перед переходом у K2 ERP потрібно зібрати всі зовнішні обробки.

Модулі BAS

Модулі містять програмний код.

У конфігурації можуть бути:

загальні модулі;
модулі об’єктів;
модулі форм;
модулі менеджерів;
модулі команд;
модулі сеансу;
модулі керованого застосунку;
модулі зовнішніх обробок.

У модулях може бути критична бізнес-логіка:

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

Форми BAS

Форми визначають, як користувач бачить об’єкт.

Наприклад:

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

У формах можуть бути доробки:

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

Ролі і права доступу

У конфігурації BAS визначаються ролі.

Приклади ролей:

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

Роль визначає:

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

Підсистеми

Підсистеми групують функціонал.

Наприклад:

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

Підсистема впливає на інтерфейс користувача і логічну структуру програми.

Константи

Константи зберігають загальні налаштування.

Наприклад:

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

При міграції потрібно перевірити, які константи реально впливають на бізнес-процеси.

Плани обміну

Плани обміну використовуються для синхронізації даних.

Наприклад:

обмін між філіями;
обмін між центральною базою і магазинами;
обмін із сайтом;
обмін із бухгалтерією;
обмін із зарплатною базою;
обмін із WMS;
обмін із CRM.

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

Бізнес-процеси і задачі

У деяких конфігураціях BAS можуть використовуватися бізнес-процеси.

Наприклад:

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

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

Типові доробки конфігурації BAS

Найчастіші доробки:

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

Приклад доробки довідника

Було типово:

Довідник	Реквізити
Номенклатура	Код, найменування, одиниця, група

Стало після доробки:

Довідник	Додані реквізити
Номенклатура	Артикул сайту, бренд, країна походження, вага, об’єм, код маркетплейсу

Такі поля можуть бути критичними для сайту, складу, логістики або BI.

Приклад доробки документа

Було типово:

Документ	Типова логіка
Замовлення покупця	Клієнт, товари, ціни, суми, статус

Стало після доробки:

Додано	Для чого
Канал продажу	Розділення сайт / менеджер / маркетплейс
Статус доставки	Контроль логістики
Зовнішній ID	Інтеграція з сайтом
Коментар складу	Передача інструкцій на відвантаження

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

Приклад доробки проведення

У типовій конфігурації документ може формувати одні рухи, а після доробки — інші.

Наприклад, реалізація додатково:

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

Таку логіку потрібно не копіювати механічно, а описати й реалізувати правильно в K2 ERP.

Оновлення конфігурації BAS

Оновлення конфігурації потрібне для:

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

Але якщо конфігурація нетипова, оновлення може бути складним.

Проблеми оновлення нетипової конфігурації

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

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

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

Розширення BAS

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

Переваги:

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

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

Конфігурація і резервна копія

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

Вона потрібна для:

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

Конфігурація і журнал реєстрації

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

Наприклад:

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

Конфігурація і інтеграції

Інтеграції часто приховані в конфігурації.

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

HTTP-сервіси;
web-сервіси;
JSON;
XML;
CSV;
Excel;
FTP;
файловий обмін;
регламентні завдання;
зовнішні обробки;
загальні модулі;
плани обміну.

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

Конфігурація і API

У сучасних системах важливо мати API.

У старій BAS API може бути реалізований нетипово:

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

Для K2 ERP краще проєктувати контрольовану API-архітектуру, а не механічно повторювати старі обміни.

Конфігурація і BI

Звіти BAS часто не покривають усі аналітичні потреби.

Компанії можуть мати:

зовнішні Excel-звіти;
SQL-запити;
Power BI;
окремі вивантаження;
ручні таблиці;
дороблені звіти;
обробки експорту.

При міграції потрібно визначити, які показники мають перейти в BI на базі K2 ERP.

Конфігурація і права доступу

Права доступу в BAS можуть бути складними.

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

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

При переході в K2 ERP права потрібно не просто копіювати, а переглянути.

Конфігурація і закриті періоди

Конфігурація може містити механізми заборони редагування.

Наприклад:

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

Ці правила потрібно врахувати в K2 ERP, щоб не втратити контроль обліку.

Конфігурація і регламентований облік

У регламентованому обліку конфігурація визначає:

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

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

Конфігурація і оперативний облік

В оперативному обліку конфігурація визначає:

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

Якщо ці правила змінені, їх потрібно описати перед переходом у K2 ERP.

Конфігурація і галузеві рішення

BAS може мати галузеві конфігурації або модулі.

Наприклад:

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

Галузеву специфіку потрібно аналізувати окремо, бо вона часто містить багато нетипових об’єктів.

Аналіз конфігурації перед міграцією

Перед переходом у K2 ERP потрібно провести аудит конфігурації.

Потрібно з’ясувати:

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

Таблиця інвентаризації конфігурації

Об’єкт	Тип	Статус	Рішення в K2 ERP
Номенклатура	Довідник	Дороблено	Перенести реквізити після очищення
Замовлення покупця	Документ	Дороблено	Описати статуси й зовнішні ID
Обмін із сайтом	Обробка	Нетипова	Замінити API K2 ERP
Звіт по маржі	Звіт	Нетиповий	Перенести в BI
Контроль боргу	Модуль	Дороблено	Реалізувати як бізнес-правило

Що переносити з конфігурації BAS

З конфігурації не переносять усе механічно.

Зазвичай потрібно перенести або переосмислити:

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

Що не варто переносити механічно

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

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

Міграція — це не копіювання конфігурації, а перенесення потрібної бізнес-логіки.

Конфігурація BAS і K2 ERP

У K2 ERP потрібно будувати цільову модель.

Вона має враховувати:

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

Типові проблеми конфігурації BAS

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

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

Помилка: не аналізувати конфігурацію перед міграцією

Якщо перенести тільки дані, але не проаналізувати конфігурацію, можна втратити:

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

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

Старий код BAS може містити:

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

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

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

Зовнішні обробки можуть бути критичними.

Якщо їх не зібрати, можна втратити:

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

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

Якщо права не перевірити, у новій системі можуть виникнути проблеми:

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

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

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

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

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

Як правильно аналізувати конфігурацію BAS

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

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

Конфігурація і цифрова незалежність

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

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

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

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

Коротко

Питання	Відповідь
Що таке конфігурація BAS?	Це прикладна структура і логіка системи: довідники, документи, регістри, звіти, обробки, модулі, ролі, форми, права й інтеграції.
Чим конфігурація відрізняється від платформи?	Платформа запускає систему, а конфігурація визначає бізнес-логіку і структуру обліку.
Що таке типова конфігурація?	Це стандартне рішення без суттєвих змін у коді.
Що таке нетипова конфігурація?	Це конфігурація з доробками, зміненими об’єктами, модулями, формами, звітами або інтеграціями.
Чому це важливо для міграції?	Бо доробки можуть містити критичні бізнес-правила, які потрібно врахувати в K2 ERP.
Що обов’язково перевірити?	Змінені об’єкти, зовнішні обробки, модулі, регламентні завдання, інтеграції, права, звіти й журнал реєстрації.
Чи потрібно переносити конфігурацію BAS у K2 ERP як є?	Ні. Потрібно переносити правильні дані, процеси, правила, інтеграції й аналітику, а не старий хаотичний код.
Чи є санкційні ризики у BAS і 1С?	Так. Окремі продукти 1С і BAS внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.

Висновок

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

Під час переходу на K2 ERP конфігурацію потрібно аналізувати дуже уважно.

Потрібно:

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

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

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

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

Див. також

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