Типове розширення ERP починається з невеликого прохання: додати поле, змінити форму або підготувати звіт. Далі з’ясовується, що поле має перевірятися, потрапляти до обміну, бути видимим лише певній ролі та зберегтися після оновлення. Саме тут важливі платформні інструменти: вони допомагають зробити зміну частиною системи, а не одноразовою латкою.
У огляді інструментів розробника K2 описує роботу з Python, TypeScript, YML, ORM, компонентами, звітами та K2 Update. Розглянемо цей набір через життєвий цикл доробки. K2 Platform тут є технологічною платформою розробки, а K2 ERP — прикладною корпоративною системою.
Спочатку перевірте, чи потрібен новий код
Автор описує характеристики сутностей, налаштування таблиць, друкованих форм і звітів. Тому запит на додаткову ознаку товару або інше оформлення документа доцільно спочатку перевірити як задачу налаштування. Новий код потрібен там, де змінюються правила, операції або спосіб взаємодії компонентів.
Для прикладу візьмемо заявку на ремонт із додатковою характеристикою обладнання та друкованою формою. Це навчальний сценарій проєктування, а не опис готового комплекту певного модуля. Спочатку визначають обов’язкові дані, користувачів і результат, який потрібно прийняти.
YML, модель даних та міграції
K2 використовує текстові YML-описи для форм, таблиць і структури системи. Їх можна зберігати у Git та порівнювати між версіями. Для доробки це дає змогу побачити не тільки кінцевий екран, а й конкретну зміну опису.
Основною СУБД у публікації названо PostgreSQL; розвиток структури пов’язано з ORM-моделями й міграціями. Підтримку інших СУБД потрібно перевіряти для конкретного компонента. Наявність ORM не означає, що будь-який SQL-запит або тип даних автоматично працюватиме однаково всюди.
Що перевіряти при зміні структури
З’ясуйте, як нове поле заповнюється для вже наявних записів, чи дозволене порожнє значення та як воно впливає на пошук і звіти. Міграцію спочатку перевіряють на тестовій копії. Зміна, яка працює лише на порожній базі, ще не готова для підприємства з історією операцій.
Компоненти звільняють час для бізнес-логіки
За описом K2, таблиці підтримують сортування, фільтрацію, роботу через буфер, налаштування полів та інші типові дії. Для розробника цінність у тому, щоб використовувати спільну поведінку, а не створювати її заново в кожному списку.
Python і TypeScript дозволяють працювати у звичних IDE. У джерелі також названо хуки, перевизначення та власні компоненти як механізми розширення. Перш ніж змінювати стандартний код, потрібно визначити підтримувану точку розширення й перевірити її сумісність із потрібною версією.
Форма, вкладення й аналітика — один сценарій
Джерело описує прив’язку файлів до документів і довідників, дизайнер друкованих форм та інструменти аналітики. У нашому прикладі фотографія несправності повинна залишатися пов’язаною із заявкою, а друкована форма — показувати погоджені дані, незалежно від того, хто її відкрив.
Перевірка має охопити права на запис і вкладення, відображення порожніх значень, потрібну мову документа та результат експорту. Для аналітики окремо перевіряють відбір, підсумки й деталізацію. Красивий дашборд не виправляє неправильний відбір — він лише показує його переконливішим шрифтом.
K2 Update та відповідальність за поставку
K2 Update описано як механізм доставки компонентів і оновлень. Маркетплейс у публікації розглядається як подальший розвиток. Перед поставкою модуля потрібно погодити склад пакета, версію, залежності, міграції, документацію та відповідального за підтримку.
Робочий порядок для команди: зафіксувати зміну в Git, перевірити на тестовому середовищі, звірити результат із вимогою й лише тоді переносити до робочої системи. Резервна копія та перевірений порядок відновлення потрібні до зміни структури, а не після першого несподіваного повідомлення.
Де допомагає AI і де потрібен інженер
AI може бути помічником у підготовці описів і коду, але його результат потрібно перевіряти на реальній моделі та правах доступу. Доступність AI-асистента в IDE не доводить наявності автоматичного виконання будь-якого бізнес-запиту в ERP. Так само офлайн-роботу та синхронізацію слід перевіряти для конкретного застосунку, а не виводити з назви платформи.
Головний результат роботи інструментів — підтримувана доробка з відомими правилами та способом оновлення. Про організаційну сторону цього підходу читайте матеріал про ERP-екосистему K2.
Leave a Reply