Під час переходу на K2 ERP важливо розділити два завдання: отримати дані зі старої системи та спроєктувати модель, у якій вони працюватимуть надалі. Липневий технічний матеріал K2 присвячений саме цій різниці.
Ключова пропозиція джерела — розглядати стару базу як джерело інформації для перенесення. Новий інтерфейс, підключений до колишньої структури, сам по собі ще не означає завершеної міграції бізнес-логіки та залежностей.
Логічний об’єкт і фізичне зберігання
Користувач працює з контрагентом, накладною або складом. На рівні бази ці сутності можуть бути розкладені між кількома таблицями, службовими ідентифікаторами та зв’язками. Для перенесення потрібне зіставлення зрозумілих бізнес-понять із фактичним зберіганням.
У матеріалі K2 розглянуто довідники, документи, табличні частини, перелічення та регістри. Конкретна структура залежить від версії, конфігурації й доробок, тому її не можна надійно визначити лише за назвою програми.
Що містить карта відповідностей
Для кожної сутності варто зафіксувати джерело, поле або зв’язок, його значення для бізнесу, правило перетворення та поле цільової моделі. Окремо визначають ключ, за яким запис зберігатиме ідентичність після повторного завантаження.
Наприклад, перенесення накладної охоплює не тільки номер і дату. Потрібно пов’язати її з організацією, контрагентом, рядками товарів і одиницями виміру. Якщо втратити зв’язок між шапкою та рядками, зовнішньо схожий документ ще не буде коректним результатом.
Перетворення значень і винятки
Коди статусів та інших перелічень потрібно зіставляти з їхнім змістом. Порожнє значення, службовий ідентифікатор і звичайний текст можуть потребувати різної обробки. Для неоднозначних записів має бути погоджене рішення відповідального фахівця.
Так само слід врахувати дороблені поля й нестандартні аналітики. Якщо вони впливають на звіти, облік або маршрути погодження, їхнє призначення потрібно з’ясувати до завантаження. Мовчазне відкидання незрозумілого поля може спотворити бізнес-сенс даних.
Повне завантаження та зміни після нього
У джерелі K2 згадує порційне перенесення й роботу з дельтою змін для великих баз. У проєкті це потребує чіткої межі: які дані перенесено, що змінилося після початкового завантаження та як обробляються виправлення і повтори.
Перевірка має включати кількість об’єктів, повноту зв’язків і контрольні підсумки за погодженими зрізами. Для критичних документів корисне предметне зіставлення: чи однаково команда розуміє операцію в старій і новій системі.
Який результат вважати завершеним
Результат міграції — це доступні та зрозумілі дані, на яких можна виконувати узгоджені операції. До приймання потрібні описані правила, журнал винятків і підтвердження відповідальних за бізнес-процес. Формат вивантаження обирають під конкретний обсяг і джерело, а не як універсальний рецепт.
Додатково: підготовка довідників і правил міграції та доступ до історичного архіву.
Джерело: матеріал K2 про структуру джерела та перенесення даних від 09.07.2026.
Leave a Reply