YML
YML — декларативний текстовий формат опису структур, моделей, налаштувань, компонентів, форм, меню, довідників, документів та інших елементів системи K2 ERP.
У K2 ERP YML використовується як міст між архітектурною ідеєю, ER-моделлю, ORM-моделлю, структурою бази даних, програмним кодом модуля, інтерфейсом користувача та автоматично створеним бізнес-додатком.
Головне. У K2 ERP YML — це не просто конфігураційний файл. Це формалізований опис бізнес-моделі, з якого система може автоматично створювати структури, ORM-моделі, міграції, код модуля, меню, довідники, журнали документів і форми документів.
Для розробників. YML дозволяє описувати структуру компонента зрозуміло, читабельно, контрольовано і придатно для генерації коду, версіонування через Git та роботи з штучним інтелектом.
Для AI-розробки. ШІ може генерувати YML-структури за описом людини, фактично створюючи ER-модель майбутнього компонента. Людина перевіряє цю модель, уточнює промптами й акцептує автоматичне створення компонента.
Важливо. YML у K2 ERP не замінює програміста. Він прибирає рутину. Програміст більше не переписує одну й ту саму структуру в різних місцях, а працює як архітектор, який описує модель і контролює результат.
Вступ
У сучасній ERP-системі важливо не тільки написати код. Важливо правильно описати структуру бізнесу.
У бізнесі є товари, контрагенти, договори, документи, склади, рахунки, заявки, платежі, маршрути погодження, бізнес-процеси, файли, характеристики, звіти й ролі користувачів.
Якщо кожну таку сутність створювати вручну в коді, потім окремо описувати її в базі даних, потім окремо створювати форми, меню, довідники, журнали документів, права доступу та інтерфейси, розробка швидко перетворюється на нескінченне дублювання.
Саме для цього в K2 ERP використовується YML.
YML дозволяє описати модель один раз, а далі використати цей опис для автоматичного створення багатьох частин системи.
Це принципово інший підхід до розробки. Не “написати все руками”, а “описати модель так, щоб система сама могла створити потрібну структуру”.
Що таке YML
YML — це текстовий декларативний формат опису даних і налаштувань.
У контексті K2 ERP YML використовується для того, щоб описувати не просто параметри, а цілі бізнес-структури:
- сутності;
- таблиці;
- поля;
- типи даних;
- зв’язки;
- документи;
- довідники;
- журнали документів;
- форми документів;
- меню;
- компоненти;
- права;
- службові налаштування;
- елементи інтерфейсу;
- правила генерації.
Але головна цінність YML не в самому синтаксисі.
Головна цінність у тому, що YML є зрозумілим і для людини, і для машини.
Людина може прочитати файл і зрозуміти, що в ньому описано. Система може прочитати файл і автоматично створити на його основі структуру, код, форми та інші елементи.
Ключова ідея. YML — це мова опису структури, а не мова ручного програмування. Він дозволяє сказати системі: “Ось як має виглядати компонент”, а далі система сама створює необхідні частини.
Чому саме YML
У бізнес-системах давно використовуються різні формати опису даних: XML, JSON, YML та інші.
XML достатньо формальний і потужний, але часто виглядає занадто важким для людини. Він має багато службових тегів, які ускладнюють читання.
JSON зручний для обміну даними між системами й дуже популярний у веб-розробці, але для великих конфігурацій і багаторівневих описів не завжди такий зручний для ручного редагування.
YML добре підходить саме для опису структур, бо він лаконічний, читабельний і зручний для людини.
Приклад простого опису товару в YML:
product:
code: "000001"
name: "Ноутбук Lenovo"
unit: "шт"
price: 32000
active: true
Такий опис легко прочитати навіть людині, яка не є програмістом. Видно, що описується товар, у якого є код, назва, одиниця виміру, ціна та ознака активності.
У K2 ERP ця читабельність особливо важлива, бо YML може використовуватися не тільки програмістами, а й архітекторами системи, інтеграторами, технічними консультантами та штучним інтелектом.
YML як міст між людиною і системою
У класичному програмуванні людина часто формулює ідею, потім програміст вручну перекладає її в таблиці, класи, форми, меню, інтерфейси, документи й логіку.
У K2 ERP YML дозволяє скоротити цей шлях.
Людина описує структуру в декларативному вигляді. Система читає цей опис і розуміє, що потрібно створити.
Наприклад, якщо в YML описано довідник “Контрагенти”, система може створити:
- структуру таблиці;
- ORM-модель;
- міграцію бази даних;
- пункт меню;
- форму списку;
- форму картки;
- базові операції створення, редагування, перегляду та видалення;
- службові описи для компонента.
Тобто YML стає проміжною мовою між бізнес-задумом і технічною реалізацією.
YML у K2 ERP. Це не просто “налаштування”. Це опис, з якого може народжуватися готовий компонент.
Місце YML в архітектурі K2 ERP
У K2 ERP YML є частиною загального ланцюжка автоматичного створення компонентів.
| Етап | Опис |
|---|---|
| ER-модель | Архітектурний опис сутностей, зв’язків і структури майбутнього компонента. |
| YML-структура | Декларативний текстовий опис моделі, який може бути створений людиною, редактором або ШІ. |
| ORM-модель | Автоматично згенерована модель для роботи з базою даних у коді. |
| Міграції | Автоматичне створення або зміна структури бази даних. |
| Код модуля | Автоматично створений програмний каркас компонента. |
| Меню | Автоматично сформовані пункти меню. |
| Довідники | Автоматично створені довідники. |
| Журнали документів | Автоматично створені журнали для роботи з документами. |
| Форми документів | Автоматично створені форми введення й перегляду документів. |
| Базовий функціонал | Початкові операції, які випливають з моделі. |
Таким чином, YML є центральним текстовим описом, через який модель перетворюється на працюючий компонент.
Простий приклад YML-опису довідника
Нижче наведено спрощений приклад YML-опису довідника “Контрагенти”.
entity: contractor
title: "Контрагенти"
type: directory
fields:
id:
type: integer
primary_key: true
code:
type: string
title: "Код"
required: true
name:
type: string
title: "Назва"
required: true
edrpou:
type: string
title: "ЄДРПОУ"
phone:
type: string
title: "Телефон"
email:
type: string
title: "E-mail"
active:
type: boolean
title: "Активний"
default: true
У цьому прикладі описано сутність `contractor`, яка є довідником. Вона має поля: ідентифікатор, код, назву, ЄДРПОУ, телефон, e-mail та ознаку активності.
На основі такого опису система може автоматично створити довідник контрагентів.
Що система може створити з такого YML
З наведеного YML-опису K2 ERP може автоматично сформувати:
- таблицю в базі даних;
- ORM-модель;
- міграцію;
- пункт меню “Контрагенти”;
- список контрагентів;
- форму картки контрагента;
- базові операції додавання, редагування, перегляду та видалення;
- службові налаштування компонента;
- основу для API-доступу;
- основу для використання у звітах;
- основу для інтеграції з іншими документами.
Тобто один YML-опис може породити цілий набір технічних і функціональних елементів.
Саме це і робить YML важливим для швидкої розробки.
Приклад опису документа
Довідники важливі, але справжня сила ERP розкривається в документах.
Документ — це не просто форма. Це бізнес-подія.
Наприклад: продаж, закупівля, переміщення товару, заявка, рахунок, акт, платіж, замовлення, виробнича операція.
Нижче наведено спрощений приклад YML-опису документа “Замовлення покупця”.
entity: customer_order
title: "Замовлення покупця"
type: document
fields:
id:
type: integer
primary_key: true
number:
type: string
title: "Номер"
auto: true
date:
type: datetime
title: "Дата"
required: true
contractor_id:
type: reference
title: "Контрагент"
entity: contractor
required: true
warehouse_id:
type: reference
title: "Склад"
entity: warehouse
comment:
type: text
title: "Коментар"
table_parts:
items:
title: "Товари"
fields:
product_id:
type: reference
title: "Товар"
entity: product
required: true
quantity:
type: decimal
title: "Кількість"
required: true
price:
type: decimal
title: "Ціна"
required: true
amount:
type: decimal
title: "Сума"
calculated: true
У цьому прикладі описано документ із шапкою та табличною частиною.
Шапка документа містить номер, дату, контрагента, склад і коментар.
Таблична частина містить товари, кількість, ціну й суму.
На основі цього YML система може автоматично створити не тільки таблиці, а й журнал документів, форму документа та табличну частину.
Автоматичне створення журналу документів
Якщо в YML сутність має тип `document`, система може автоматично створити журнал документів.
Журнал документів — це список документів певного типу, наприклад “Замовлення покупців”.
У журналі можуть відображатися:
- номер документа;
- дата;
- контрагент;
- склад;
- сума;
- статус;
- автор;
- дата створення;
- дата зміни.
Приклад YML-опису журналу:
journal:
title: "Замовлення покупців"
entity: customer_order
columns:
- field: number
title: "Номер"
- field: date
title: "Дата"
- field: contractor_id
title: "Контрагент"
- field: warehouse_id
title: "Склад"
- field: total_amount
title: "Сума"
- field: status
title: "Статус"
Система може використати цей опис для автоматичного створення списку документів з потрібними колонками.
Автоматичне створення форми документа
Форма документа — це те, з чим працює користувач.
Якщо структура документа вже описана в YML, форма може бути створена автоматично.
Приклад опису форми:
form:
entity: customer_order
title: "Замовлення покупця"
layout:
- row:
- field: number
- field: date
- row:
- field: contractor_id
- field: warehouse_id
- row:
- field: comment
- table_part: items
title: "Товари"
Цей опис говорить системі, як розмістити поля на формі.
У першому рядку — номер і дата.
У другому — контрагент і склад.
Далі — коментар.
Потім — таблична частина “Товари”.
Перевага. Програміст не малює форму вручну з нуля. Він описує структуру, а система створює форму автоматично.
Автоматичне створення меню
Меню — ще одна частина, яку не потрібно кожного разу створювати вручну.
Приклад YML-опису меню:
menu:
section: "Продажі"
items:
- title: "Замовлення покупців"
entity: customer_order
type: journal
- title: "Контрагенти"
entity: contractor
type: directory
- title: "Товари"
entity: product
type: directory
З такого опису K2 ERP може автоматично створити розділ меню “Продажі” та додати до нього потрібні пункти.
YML і ER-модель
ER-модель описує сутності та зв’язки між ними.
YML є текстовим представленням такої моделі.
Наприклад, якщо в ER-моделі є сутність “Замовлення покупця”, яка пов’язана з “Контрагентом”, “Складом” і “Товаром”, то в YML це може бути описано через поля типу `reference`.
Приклад:
contractor_id:
type: reference
title: "Контрагент"
entity: contractor
required: true
Цей фрагмент означає, що поле `contractor_id` є посиланням на сутність `contractor`.
Для людини це зрозуміло як “у документі є контрагент”.
Для системи це зрозуміло як зв’язок між таблицями, який можна використати для генерації ORM-моделі, форми, довідника, API та звітів.
YML і ORM
ORM-модель потрібна для того, щоб програмний код міг працювати з базою даних не напряму через таблиці, а через об’єкти.
Якщо в YML описана сутність, система може автоматично створити відповідну ORM-модель.
Наприклад, з такого YML:
entity: product
title: "Номенклатура"
type: directory
fields:
id:
type: integer
primary_key: true
name:
type: string
title: "Назва"
price:
type: decimal
title: "Ціна"
може бути автоматично створена умовна Python-модель:
class Product(BaseModel):
id: int
name: str
price: Decimal
Або TypeScript-інтерфейс:
export interface Product {
id: number;
name: string;
price: number;
}
Це спрощені приклади, але вони показують суть: YML стає джерелом для генерації моделей у різних мовах програмування.
YML і міграції бази даних
Міграції потрібні для керованої зміни структури бази даних.
У старому підході програміст часто вручну пише SQL-скрипти, які створюють або змінюють таблиці.
У підході K2 ERP структура описується через YML, а міграції можуть створюватися автоматично.
Наприклад, якщо в YML додано нове поле:
tax_number:
type: string
title: "Податковий номер"
система може зрозуміти, що в таблицю потрібно додати нову колонку.
Це дозволяє уникнути хаотичних ручних змін у базі даних.
Фундамент ERP. Структура бази даних повинна змінюватися керовано. YML дозволяє описувати ці зміни на рівні моделі, а не випадкових ручних правок.
YML і PostgreSQL
Основною базою даних для K2 ERP є PostgreSQL.
YML-опис може бути використаний для створення структур у PostgreSQL: таблиць, колонок, індексів, зв’язків, обмежень і міграцій.
Наприклад:
indexes:
- name: idx_product_name
fields:
- name
- name: idx_product_code
fields:
- code
unique: true
Такий опис може бути використаний для створення індексів у базі даних.
Це важливо для продуктивності. У великих ERP-системах правильні індекси можуть значно прискорювати пошук, фільтрацію, побудову звітів і роботу журналів документів.
YML і TypeScript
TypeScript використовується для frontend-частини, компонентів інтерфейсу, типізації даних і взаємодії з API.
Якщо YML описує структуру сутності, то з нього можна автоматично створювати типи для frontend.
Наприклад, з опису довідника “Контрагенти” можна сформувати:
export interface Contractor {
id: number;
code: string;
name: string;
edrpou?: string;
phone?: string;
email?: string;
active: boolean;
}
Це дозволяє frontend-розробнику працювати з типізованими даними й зменшує кількість помилок.
YML і Python
Python використовується для backend-логіки, бізнес-правил, API, інтеграцій, обробки даних і AI-сценаріїв.
З YML можна генерувати Python-моделі, схеми валідації, структури API та каркаси сервісів.
Приклад умовної моделі:
class Contractor(BaseModel):
id: int
code: str
name: str
edrpou: str | None = None
phone: str | None = None
email: str | None = None
active: bool = True
Замість того щоб вручну дублювати структуру в різних частинах системи, її можна один раз описати в YML.
YML і API
Якщо структура сутності описана в YML, система може використати цю інформацію для створення API.
Наприклад, для сутності `contractor` можуть бути автоматично створені маршрути:
GET /api/contractors
GET /api/contractors/{id}
POST /api/contractors
PUT /api/contractors/{id}
DELETE /api/contractors/{id}
Звичайно, реальна система може мати складніші правила доступу, фільтрації, валідації й бізнес-логіки.
Але базова ідея проста: якщо система знає структуру сутності, вона може створити типові API-операції автоматично.
YML і права доступу
У ERP важливо не тільки створити дані, а й правильно обмежити доступ до них.
YML може містити опис ролей і прав.
Приклад:
permissions:
roles:
sales_manager:
title: "Менеджер з продажу"
access:
read: true
create: true
update: true
delete: false
sales_director:
title: "Керівник продажів"
access:
read: true
create: true
update: true
delete: true
approve: true
Такий опис дозволяє централізовано визначати, хто може переглядати, створювати, редагувати, видаляти або погоджувати документи.
YML і валідація даних
У бізнес-системі важливо, щоб користувач не міг зберегти некоректні дані.
YML може описувати правила валідації.
Приклад:
fields:
email:
type: string
title: "E-mail"
validation:
format: email
quantity:
type: decimal
title: "Кількість"
validation:
min: 0.001
date:
type: datetime
title: "Дата"
required: true
Цей опис говорить системі, що e-mail має бути у правильному форматі, кількість не може бути меншою за 0.001, а дата є обов’язковою.
YML і бізнес-правила
Не вся бізнес-логіка може бути описана просто через поля й типи.
Але частину правил можна декларативно описати в YML.
Наприклад:
rules:
calculate_amount:
when: "items.quantity or items.price changed"
set:
items.amount: "items.quantity * items.price"
calculate_total:
when: "items.amount changed"
set:
total_amount: "sum(items.amount)"
Це умовний приклад, але він показує напрям: типові правила можуть бути описані декларативно, а складна логіка — дописана програмістом.
Правильний баланс. YML описує те, що можна формалізувати. Програміст дописує те, що потребує складної експертної логіки.
YML і AI
Штучний інтелект особливо добре працює там, де є зрозуміла структура.
YML якраз дає таку структуру.
Людина може написати промпт:
Створи YML-модель для документа "Заявка на ремонт обладнання".
Потрібні поля: номер, дата, клієнт, обладнання, опис проблеми,
пріоритет, відповідальний інженер, статус.
Додай табличну частину для виконаних робіт:
робота, кількість годин, ставка, сума.
entity: repair_request
title: "Заявка на ремонт обладнання"
type: document
fields:
id:
type: integer
primary_key: true
number:
type: string
title: "Номер"
auto: true
date:
type: datetime
title: "Дата"
required: true
customer_id:
type: reference
title: "Клієнт"
entity: contractor
required: true
equipment_id:
type: reference
title: "Обладнання"
entity: equipment
required: true
problem_description:
type: text
title: "Опис проблеми"
required: true
priority:
type: enum
title: "Пріоритет"
values:
- low
- normal
- high
- critical
default: normal
engineer_id:
type: reference
title: "Відповідальний інженер"
entity: employee
status:
type: enum
title: "Статус"
values:
- draft
- in_work
- completed
- closed
default: draft
table_parts:
works:
title: "Виконані роботи"
fields:
work_id:
type: reference
title: "Робота"
entity: service_work
hours:
type: decimal
title: "Кількість годин"
rate:
type: decimal
title: "Ставка"
amount:
type: decimal
title: "Сума"
calculated: true
Після цього людина перевіряє модель, уточнює промптами, додає або змінює поля, коригує зв’язки й акцептує автоматичне створення компонента.
Як AI і YML змінюють роль програміста
У старому підході програміст вручну створював:
- таблиці;
- моделі;
- форми;
- меню;
- журнали;
- довідники;
- API;
- базові операції;
- службові структури.
У підході K2 ERP значна частина цього може створюватися автоматично з YML.
Коли підключається ШІ, він може допомогти створити сам YML.
Тоді роль людини змінюється.
Програміст більше не є людиною, яка вручну переносить одну й ту саму структуру з одного місця в інше.
Він стає архітектором, який:
- формулює задачу;
- перевіряє модель;
- уточнює структуру;
- контролює якість;
- акцептує створення компонента;
- дописує складну логіку, яка не була описана в промпті.
AI + YML. Людина описує задум. ШІ формує YML-модель. K2 ERP автоматично створює компонент. Програміст дошліфовує складну логіку. Це і є програмування зі швидкістю думки.
YML і Git
Оскільки YML — це текстовий формат, його зручно зберігати в Git.
Це дає багато переваг:
- можна бачити історію змін;
- можна порівнювати версії;
- можна робити гілки розробки;
- можна проводити code review;
- можна відкотити помилкові зміни;
- можна бачити, хто і коли змінив модель;
- можна переносити моделі між проєктами.
Наприклад, якщо хтось додав нове поле до документа, це видно в diff:
+ delivery_date:
+ type: date
+ title: "Дата доставки"
Це значно краще, ніж коли зміни зроблені десь у закритому конфігураторі й незрозуміло, хто, коли і що саме змінив.
YML і повторне використання компонентів
Якщо компонент описаний через YML, його легше переносити, копіювати, адаптувати й розповсюджувати.
Це особливо важливо для партнерів K2 ERP.
Наприклад, партнер створив модуль “Сервісне обслуговування обладнання”. У ньому є:
- довідник обладнання;
- довідник видів робіт;
- документ “Заявка на ремонт”;
- документ “Акт виконаних робіт”;
- журнали документів;
- форми;
- звіти;
- ролі доступу.
Якщо структура цього модуля описана в YML, її можна переносити між інсталяціями, використовувати як шаблон, розвивати й публікувати через K2 Update.
YML і K2 Update
K2 Update може використовувати YML як частину механізму доставки компонентів.
Компонент може містити:
- YML-опис структур;
- ORM-моделі;
- міграції;
- frontend-компоненти;
- backend-логіку;
- звіти;
- шаблони;
- налаштування меню;
- права доступу.
YML у такому пакеті виконує роль зрозумілого опису структури компонента.
Це дозволяє не просто передати “набір файлів”, а передати керовану модель, яку система може встановити, оновити або перевірити.
YML і low-code/no-code
Low-code і No-code часто обіцяють, що бізнес зможе створювати додатки без програмістів.
Але в реальності складні ERP-системи не можуть повністю обійтися без архітекторів і програмістів.
Правильний підхід інший.
Не треба обіцяти, що програмісти зникнуть. Треба зробити так, щоб програмісти не займалися рутиною.
YML у K2 ERP — це основа для такого підходу.
Частину структури можна створювати візуально.
Частину — описувати вручну.
Частину — генерувати за допомогою ШІ.
Частину — дописувати програмно.
Реалістичний low-code. YML не робить складну ERP магічно простою. Він робить її керованою, структурованою і придатною для автоматичної генерації.
Переваги YML у K2 ERP
| Перевага | Пояснення |
|---|---|
| Читабельність | YML легко читати людині. |
| Декларативність | Описується не “як програмувати”, а “що має бути створено”. |
| Автоматична генерація | З YML можна створювати ORM, міграції, код, меню, форми й довідники. |
| Версіонування | YML зручно зберігати в Git. |
| AI-сумісність | ШІ добре працює з текстовими структурованими описами. |
| Повторне використання | Моделі можна переносити між проєктами. |
| Масштабованість | Система може рости без хаотичного дублювання структур. |
| Прозорість | Архітектуру компонента можна зрозуміти з текстового опису. |
Типові помилки при роботі з YML
Попри простоту, з YML потрібно працювати уважно.
Типові помилки:
- неправильні відступи;
- неузгоджені назви полів;
- дублювання сутностей;
- відсутність типів даних;
- занадто складні структури в одному файлі;
- спроба описати в YML те, що краще реалізувати в коді;
- відсутність коментарів;
- некоректні посилання на інші сутності;
- невраховані права доступу;
- неописані правила валідації.
Приклад помилки з відступами:
fields:
name:
type: string
title: "Назва"
Правильно:
fields:
name:
type: string
title: "Назва"
У YML відступи мають значення. Через це важливо використовувати нормальні редактори, підсвічування синтаксису й перевірки.
Рекомендації щодо структури YML-файлів
Щоб YML-моделі залишалися зручними, варто дотримуватися кількох принципів.
Не потрібно створювати один гігантський файл на всю систему. Краще розділяти описи за модулями, компонентами або сутностями.
Наприклад:
sales/
contractors.yml
products.yml
customer_order.yml
invoice.yml
menu.yml
permissions.yml
Такий підхід спрощує підтримку.
Якщо змінюється документ “Замовлення покупця”, не потрібно відкривати файл на десять тисяч рядків. Достатньо працювати з конкретним описом.
Коментарі в YML
Коментарі допомагають пояснити, навіщо потрібне поле або правило.
Приклад:
fields:
edrpou:
type: string
title: "ЄДРПОУ"
# Використовується для перевірки контрагента та інтеграцій із зовнішніми сервісами
Коментарі особливо корисні в складних галузевих модулях, де бізнес-логіка не завжди очевидна.
YML і документація
Оскільки YML описує структуру компонента, з нього можна генерувати документацію.
Наприклад, система може автоматично створити опис сутності:
| Поле | Тип | Назва | Обов’язкове |
|---|---|---|---|
| code | string | Код | Так |
| name | string | Назва | Так |
| edrpou | string | ЄДРПОУ | Ні |
| active | boolean | Активний | Ні |
Це зручно для розробників, інтеграторів, тестувальників і користувачів.
YML і тестування
Якщо структура описана в YML, можна автоматично генерувати частину тестів.
Наприклад, якщо поле обов’язкове, можна перевірити, що система не дозволяє зберегти документ без цього поля.
Якщо поле має тип `decimal`, можна перевірити числові значення.
Якщо поле є посиланням на іншу сутність, можна перевірити коректність зв’язку.
Таким чином, YML може бути джерелом не тільки для генерації коду, а й для перевірки якості.
YML і рефакторинг
У великих системах рефакторинг неминучий.
Бізнес змінюється. Поля додаються. Документи уточнюються. Зв’язки перебудовуються. Частина логіки застаріває.
Якщо структура системи розкидана по коду, базі, формах і меню, рефакторинг стає болючим.
Якщо ж основа описана через YML, зміни можна робити більш керовано.
Наприклад, якщо потрібно перейменувати поле, система може бачити, де воно використовується: у формі, журналі, API, звіті, правилах, правах доступу.
Це не означає, що всі зміни стають автоматично простими. Але вони стають більш прозорими.
YML і модульність
K2 ERP розвивається як модульна система.
Модуль повинен бути достатньо незалежним, щоб його можна було встановити, оновити, видалити або замінити без руйнування всієї системи.
YML допомагає описати межі модуля.
Наприклад, модуль “Продажі” може містити свої сутності, документи, меню, права та форми.
Модуль “Сервіс” може використовувати частину довідників із модуля “Продажі”, але мати власні документи й процеси.
Такі зв’язки можна описувати явно.
module: service
title: "Сервісне обслуговування"
depends_on:
- sales
- warehouse
- crm
Це дозволяє системі розуміти залежності між модулями.
YML і незалежні компоненти
Одна з важливих переваг K2 ERP — можливість створювати незалежні легкі компоненти, які легко підтримувати й інтегрувати між собою.
YML дозволяє описати компонент так, щоб він не був випадковим шматком коду.
Компонент має зрозумілу структуру:
- назву;
- версію;
- залежності;
- сутності;
- форми;
- меню;
- права;
- міграції;
- точки інтеграції.
Приклад:
component:
name: service_requests
title: "Сервісні заявки"
version: "1.0.0"
depends_on:
- contractors
- equipment
entities:
- repair_request
- service_work
menu:
section: "Сервіс"
Такий опис робить компонент зрозумілим для системи, розробника, партнера й ШІ.
Повний приклад міні-компонента
Нижче наведено умовний спрощений приклад YML-опису міні-компонента “Сервісні заявки”.
component:
name: service_requests
title: "Сервісні заявки"
version: "1.0.0"
entities:
equipment:
title: "Обладнання"
type: directory
fields:
id:
type: integer
primary_key: true
code:
type: string
title: "Код"
required: true
name:
type: string
title: "Назва"
required: true
serial_number:
type: string
title: "Серійний номер"
contractor_id:
type: reference
title: "Власник"
entity: contractor
repair_request:
title: "Заявка на ремонт"
type: document
fields:
id:
type: integer
primary_key: true
number:
type: string
title: "Номер"
auto: true
date:
type: datetime
title: "Дата"
required: true
equipment_id:
type: reference
title: "Обладнання"
entity: equipment
required: true
problem_description:
type: text
title: "Опис проблеми"
status:
type: enum
title: "Статус"
values:
- draft
- in_work
- completed
- closed
default: draft
table_parts:
works:
title: "Роботи"
fields:
work_name:
type: string
title: "Робота"
hours:
type: decimal
title: "Години"
amount:
type: decimal
title: "Сума"
menu:
section: "Сервіс"
items:
- title: "Обладнання"
entity: equipment
type: directory
- title: "Заявки на ремонт"
entity: repair_request
type: journal
З такого опису система може автоматично створити довідник обладнання, документ заявки на ремонт, журнал заявок, форми, меню, ORM-моделі, міграції та базовий функціонал.
Порівняння старого і нового підходу
| Старий підхід | Підхід K2 ERP з YML |
|---|---|
| Таблиці створюються вручну | Структура описується в YML, таблиці створюються автоматично |
| Форми створюються окремо | Форми можуть генеруватися з моделі |
| Меню налаштовується окремо | Меню описується в YML |
| ORM пишеться вручну | ORM-модель генерується автоматично |
| API дублює структуру вручну | API може використовувати опис моделі |
| Зміни важко контролювати | Зміни видно в Git |
| AI не має структурованого контексту | ШІ працює з чітким YML-описом |
| Розробник витрачає час на рутину | Розробник працює з архітектурою і складною логікою |
Чим YML кращий за ручну розробку однакових структур
Ручна розробка має сенс там, де потрібна складна логіка, нестандартні алгоритми, інтеграції або спеціальні сценарії.
Але немає сенсу вручну створювати те, що повторюється в кожному модулі:
- поле назви;
- поле дати;
- посилання на контрагента;
- табличну частину;
- форму списку;
- форму документа;
- журнал;
- меню;
- базові CRUD-операції.
YML дозволяє прибрати цю рутину.
Програмісту залишається важливіша робота: подумати, чи правильно побудована модель, чи не буде проблем зі зв’язками, чи відповідає структура реальному бізнесу, яку складну логіку треба дописати окремо.
YML як основа програмування зі швидкістю думки
Коли людина описує ідею, ШІ формує YML, а K2 ERP автоматично створює компонент — розробка наближається до швидкості думки.
Це не означає, що складні системи з’являються магічно без контролю.
Це означає, що людина перестає витрачати час на механічне дублювання.
Процес виглядає так:
| Крок | Що відбувається |
|---|---|
| 1 | Людина формулює ідею компонента. |
| 2 | ШІ створює YML-структуру. |
| 3 | Людина перевіряє модель. |
| 4 | Людина уточнює промптами потрібні деталі. |
| 5 | Модель акцептується. |
| 6 | K2 ERP автоматично створює компонент. |
| 7 | Програміст дописує складну логіку, яка не була описана в моделі. |
Формула. Ідея → ШІ → YML → ER-модель → ORM → міграції → код модуля → меню → довідники → журнали → форми → готовий компонент.
Коротко
| Питання | Відповідь |
|---|---|
| Що таке YML у K2 ERP? | Декларативний текстовий опис структур, моделей, форм, меню, документів, довідників і компонентів. |
| Для чого використовується YML? | Для автоматичного створення ORM-моделей, міграцій, програмного коду, меню, довідників, журналів документів і форм. |
| Чи може ШІ створювати YML? | Так. ШІ може генерувати YML за описом людини, фактично створюючи ER-модель майбутнього компонента. |
| Яка роль людини? | Перевірити структуру, уточнити промпти, акцептувати модель і дописати складну логіку, яку не було описано в промпті. |
| Чому YML зручний? | Він читабельний, текстовий, придатний для Git, автоматичної генерації та роботи з ШІ. |
| Чи замінює YML програміста? | Ні. Він прибирає рутину й дозволяє програмісту працювати на рівні архітектури. |
| Чим YML корисний для партнерів? | Дозволяє створювати переносимі компоненти, модулі, шаблони та галузеві рішення. |
| Чим YML корисний для бізнесу? | Дозволяє швидше створювати новий функціонал і адаптувати ERP під реальні процеси. |
Висновок
YML у K2 ERP — це не просто формат файлу.
Це один із ключових елементів сучасної архітектури, яка дозволяє переходити від ручного програмування до моделювання, автоматичної генерації та AI-асистованої розробки.
Завдяки YML система може розуміти структуру компонента, створювати ORM-моделі, міграції, код, меню, довідники, журнали документів, форми документів і базовий функціонал.
Коли до цього підключається штучний інтелект, людина може описати задум людською мовою, отримати YML-модель, перевірити її, уточнити промптами й акцептувати автоматичне створення компонента.
Саме тому YML є одним із фундаментів програмування зі швидкістю думки.
Він не замінює архітектора.
Він не замінює досвід.
Він не замінює складну бізнес-логіку.
Але він прибирає величезний пласт рутини, який у старих системах забирав час, гроші, нерви й змушував програмістів вручну робити те, що давно має створюватися автоматично.
YML у K2 ERP — це мова, якою бізнес-ідея починає перетворюватися на працюючий компонент.
Саме через YML, ER-моделі, ORM, генерацію, модульність і ШІ K2 ERP будує новий підхід до створення ERP-систем — швидший, легший, зрозуміліший і значно сучасніший за старі закриті технології.
Див. також
- K2
- K2 ERP
- K2 Update
- ERP
- YML
- YAML
- JSON
- XML
- ER-модель
- BP-модель
- ORM
- API
- Python
- TypeScript
- PostgreSQL
- SQLite
- MySQL
- SQL
- Git
- AI
- Штучний інтелект
- Low-code
- No-code
- RAD
- IDE
- Автоматична генерація коду
- Автоматизація бізнесу
- Українське програмне забезпечення
- Альтернатива 1С
- Альтернатива BAS
Зовнішні посилання
- Сайт K2 ERP
- Wiki K2 ERP
- Хмара K2 ERP
- Telegram-канал K2 ERP
- Група обговорення функціоналу та пропозицій
- LinkedIn K2
index.php?title=Категорія:K2 index.php?title=Категорія:K2 ERP index.php?title=Категорія:YML index.php?title=Категорія:YAML index.php?title=Категорія:ERP index.php?title=Категорія:AI index.php?title=Категорія:Штучний інтелект index.php?title=Категорія:Програмування index.php?title=Категорія:Інструменти розробника index.php?title=Категорія:ERP для розробників index.php?title=Категорія:ERP для інтеграторів index.php?title=Категорія:ERP для партнерів index.php?title=Категорія:ORM index.php?title=Категорія:API index.php?title=Категорія:Python index.php?title=Категорія:TypeScript index.php?title=Категорія:PostgreSQL index.php?title=Категорія:Low-code index.php?title=Категорія:No-code index.php?title=Категорія:Автоматична генерація коду index.php?title=Категорія:Автоматизація бізнесу index.php?title=Категорія:Українське програмне забезпечення index.php?title=Категорія:Альтернатива 1С index.php?title=Категорія:Альтернатива BAS index.php?title=Категорія:Цифрова незалежність України