Об’єднання баз починається з питання: які записи справді описують один і той самий об’єкт? Якщо у двох підрозділів є товар «Насос», це ще не означає, що можна скласти його залишки в один рядок. Можуть відрізнятися модель, одиниця виміру або спосіб обліку.
У матеріалі від 2 червня 2026 року K2 пояснює свою ставку на моделі, конструктори та спільну логіку даних. Один із ключових орієнтирів — переносити в нову ERP впорядковану інформацію. Для міграційного проєкту цей принцип варто перетворити на конкретні правила відповідності.
Спільний довідник потребує спільного значення
У різних джерелах один контрагент може мати кілька написань, а одна назва — належати різним юридичним особам. Товарні картки можуть відрізнятися артикулом, виробником, упаковкою чи одиницею виміру. Автоматичне зіставлення лише за назвою створює ризик неправильного об’єднання.
Для кожного типу даних потрібно погодити ознаки відповідності. У контрагента це можуть бути ідентифікаційні дані разом із перевіркою реквізитів; у товару — узгоджена комбінація артикулу, виробника та інших важливих характеристик. Остаточні правила визначає власник даних із предметним фахівцем.
Таблиця відповідностей зберігає шлях назад
Корисний результат підготовки — відповідність між ідентифікатором джерела та цільовим записом. Коли кілька карток об’єднують в одну, потрібно зберегти, звідки вони походили й хто погодив рішення.
Наприклад, «Сервіс-Плюс» у двох базах може виявитися однією компанією після перевірки реквізитів. Але дві однойменні картки «Підшипник» без уточнення характеристик поки залишаються невизначеними. Це умовні приклади, а не опис виконаного перенесення.
Невизначені записи краще винести в окремий список для перевірки. Інакше система впевнено перенесе помилку, а розбирати її доведеться бухгалтеру, який не підписувався на роль детектива.
Модель даних і модель процесу вирішують різні задачі
ER-модель описує сутності та зв’язки: товар, склад, документ, рядок документа. Модель процесу визначає, як люди працюють із цими об’єктами: хто створює, перевіряє, погоджує й виправляє записи.
У підході K2 ці інструменти пов’язані з розвитком рішення на K2 Platform — технологічній платформі для розробки програмного забезпечення. K2 ERP є корпоративною інформаційною системою. Готовність конкретного процесу потрібно перевіряти окремо від можливості його змоделювати.
Порядок роботи з даними до запуску
- Описати джерела. Зафіксувати бази, файли, версії, потрібні періоди й відповідальних.
- Перевірити якість. Знайти дублікати, порожні обов’язкові реквізити, різні одиниці та суперечливі значення.
- Погодити цільову структуру. Визначити спільні довідники, потрібну історію та правила розмежування доступу.
- Підготувати відповідності. Описати зіставлення полів і записів, окремо залишити невизначені випадки.
- Виконати пробне перенесення. Перевірити погоджений набір у тестовому середовищі.
- Звірити результат. Порівняти контрольні документи, залишки й підсумки за потрібними розрізами.
- Погодити запуск. Визначити момент припинення змін у джерелі, фінальне перенесення й дії у разі невдалого запуску.
Це методика організації робіт. Вона не означає, що будь-яку стару конфігурацію можна автоматично перенести без аналізу або що K2 вже реалізує всі перелічені перевірки одним натисканням.
Повторне використання починається з документації
Першоджерело також описує розвиток конструкторів, перенесення налаштувань між середовищами та делегування частини змін ближче до клієнта. Для проєкту корисно окремо зафіксувати, які механізми доступні в обраній версії, а які потребують розробки.
Навіть якщо налаштування можна перенести, потрібно перевірити їхні залежності: структуру даних, права, звіти та інтеграції. Галузевий шаблон стає повторно використовуваним рішенням тоді, коли інший фахівець може зрозуміти його умови й перевірити результат.
Як оцінювати успішність об’єднання
Кількість завантажених рядків — лише один показник. Бізнесу потрібні правильні зв’язки, пояснювані підсумки, доступна історія та визначені відповідальні за довідники після запуску.
Тому приймання міграції варто будувати на контрольних сценаріях і погоджених правилах. Нова ERP має отримати зрозумілу інформацію, з якою підприємство зможе працювати й надалі підтримувати порядок.
Архітектурний підхід описано в статті K2 про моделі, конструктори та об’єднання даних. Можливості редактора розглянуто окремо в матеріалі про ER-моделі K2.
Leave a Reply