Рекомендації для розробників K2

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

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

Головна ідея. Розробник K2 має створювати не одноразову доробку, а підтримуваний елемент ERP-платформи. Код має бути зрозумілим, компонент — документованим, інтерфейс — зручним, база даних — чистою, а оновлення — перевіреним.

Важливо. ERP-розробка відрізняється від звичайної веб-розробки. Тут помилка в полі, праві доступу, SQL-запиті, імпорті або оновленні може вплинути на реальні бізнес-процеси клієнта.

Критично. Не можна робити зміни “на живій базі”, без Git, без тестування, без опису версії та без розуміння бізнес-наслідків.

Що означає бути розробником K2

Розробник K2 — це спеціаліст, який створює або підтримує функціональність у межах ERP-платформи. Це може бути backend-розробник, frontend-розробник, full-stack-розробник, Python-розробник, PHP-розробник, TypeScript/JavaScript-розробник, спеціаліст із PostgreSQL, інтегратор, розробник звітів, автор доповнень або технічний партнер.

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

Технічний акцент. Розробник K2 працює на перетині коду, бази даних, бізнес-логіки, інтерфейсу, прав доступу та процесів підприємства.

Основні принципи розробки K2

Розробка в K2 має спиратися на кілька базових принципів.

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

Другий принцип — повторне використання. Якщо в K2 уже є грид, форма, довідник, фільтр, механізм імпорту, експорту або доступів, потрібно використовувати стандартну логіку, а не писати власну копію.

Третій принцип — контроль даних. Будь-яка зміна в базі має бути зрозумілою, контрольованою й безпечною.

Четвертий принцип — Git-дисципліна. Зміни мають фіксуватися, комітитися, пушитися, перевірятися й описуватися.

П’ятий принцип — тестування до публікації. Компонент не можна вважати готовим, якщо він не перевірений на тестовому середовищі.

Шостий принцип — документація. Якщо модуль не описаний, його важко підтримувати, передавати й продавати через екосистему K2.

Правильний підхід. Кожна розробка в K2 має відповідати трьом питанням: що вона робить, як її підтримувати, і що станеться після оновлення.

Локальне середовище розробника

Перед роботою з кодом розробник має підготувати локальне середовище. Для K2 Cloud ERP Python типовий сценарій передбачає копіювання робочого проєкту, перший запуск, налаштування віртуального середовища, запуск додатку, відкриття проєкту в PyCharm і підключення Git.

Базовий порядок:

скопіювати проєкт із віддаленого сервера;
перейти в каталог проєкту;
виконати `first_run.sh` або `first_run.bat`;
змінити `domain_protocol` з `https` на `http` для локального запуску;
запустити додаток через `run.sh` або `run.bat`;
відкрити проєкт у PyCharm;
налаштувати Python Interpreter на локальний `venv`;
встановити й налаштувати Git;
підключити потрібні компоненти;
перевірити роботу локального середовища.

cd /K2CloudERP
bash first_run.sh
bash run.sh

Для Windows:

./first_run.bat
./run.bat

Важливо. Локальне середовище не повинно бути копією хаосу з бойового сервера. Воно має бути робочим dev-контуром, де можна безпечно розробляти, перевіряти й готувати зміни.

PyCharm і Python Interpreter

Для Python-розробки в K2 зручно використовувати PyCharm. Після відкриття проєкту потрібно налаштувати інтерпретатор саме на локальне віртуальне середовище поточного проєкту.

Приклад шляху для Linux:

../K2CloudERP/venv/bin/python3.12

Приклад шляху для Windows:

..\K2CloudERP\venv\Scripts\python.exe

Якщо PyCharm використовує неправильний Python Interpreter, залежності можуть не відповідати проєкту. Це призводить до помилок запуску, некоректної роботи модулів або різної поведінки в IDE та консолі.

Типова помилка. Розробник відкрив проєкт у PyCharm, але не підключив правильний `venv`. У результаті код може запускатися не в тому середовищі, де встановлені потрібні залежності.

Git-дисципліна

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

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

git config --global user.name "Ваше Ім'я"
git config --global user.email "ваша_електронна_пошта@example.com"

Для авторизації через SSH:

ssh-keygen -t rsa -b 4096 -C "ваша_електронна_пошта@example.com"
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa
cat ~/.ssh/id_rsa.pub

Отриманий публічний ключ потрібно додати у віддалений репозиторій.

Правильна звичка. Перед змінами — `git pull`. Після змін — `git status`. Перед передачею — осмислений commit. Після перевірки — push.

Коміти

Коміт має пояснювати, що саме змінено. Назва коміту не повинна бути випадковою.

Погані приклади:

fix
update
123
new
test

Кращі приклади:

Додано поле ПДВ у форму заявки на оплату
Виправлено фільтр за статусом у журналі документів
Оновлено SQL для довідника постачальників
Додано перевірку прав на експорт у K2Grid

Стандартні команди:

git status
git add .
git commit -m "Опис зміни"
git pull
git push

Важливо. Коміт має бути зрозумілим іншому розробнику через місяць або рік. Якщо з назви неясно, що змінилося, підтримка стає складнішою.

Робота з auto_update

Для списку компонент може використовуватися скрипт `auto_update`. Його копіюють у корінь проєкту на рівні з `app.py`, після чого в `settings.py` додають потрібні компоненти.

Типова робота:

cd auto_update
python git_cmd.py clone
python git_cmd.py status
python git_cmd.py commit
python git_cmd.py pull
python git_cmd.py push

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

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

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

Якщо потрібно підключити одну компоненту вручну, розробник переходить у каталог компоненти, ініціалізує Git, додає remote і отримує код із репозиторію.

Приклад:

cd components/k2site
git init
git checkout -b main
git remote add origin http://git.corp2.eu/k2erp/python/k2/base/site/k2site.git
git remote -v
git fetch origin
git pull origin main
git status

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

Компонентна архітектура

Компонент у K2 має бути не хаотичним набором файлів, а структурованою частиною системи.

Типова структура компоненти може містити:

components/
└── example_module/
    ├── example_module/
    │   ├── models.py
    │   ├── views.py
    │   ├── forms.py
    │   ├── hooks.py
    │   ├── objects/
    │   └── templates/
    ├── doc/
    │   ├── schema/
    │   ├── business_processes/
    │   └── user_manual/
    ├── requirements.txt
    └── setup.py

`models.py` відповідає за структури даних. `views.py` — за логіку представлень. `forms.py` — за форми. `hooks.py` — за розширення поведінки. `doc/schema` — за документацію структури бази даних. `setup.py` — за параметри компоненти, включно з версією.

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

Версії компонентів

Кожна компонента, яка публікується або оновлюється, має мати версію. Версія вказується у `setup.py`.

Приклад:

version = "2.0.4.43"
version_type = "stable"

Для testing/beta-версії:

version = "2.0.4.43"
version_type = "testing"

Після зміни версії потрібно додати опис змін у `history.txt`.

Приклад:

2.0.4.43 - додано перевірку прав на експорт у журналі документів

Помилка. Оновити код компоненти, але не змінити версію й не додати запис у `history.txt` — це погана практика. Пізніше буде складно зрозуміти, що саме було змінено.

Сервер оновлень

Для завантаження компонентів у систему оновлення використовуються налаштування в каталозі:

builder/config

У файл `component-list.txt` додається список компонентів:

components/k2update
components/k2adm
components/k2site

У каталозі `builder/config/ignore` створюються файли з переліком того, що не потрібно завантажувати.

Приклад:

__pycache__
.gitignore
.git
ej2.min.js

У файл `token.txt` додається токен доступу до сервера оновлень.

Публікація:

python k2update_push.py

Важливо. Перед `k2update_push.py` потрібно перевірити список компонентів, ignore-файли, токен, версію, history.txt і готовність до тестування.

Тестові домени deb1-deb3

Після завантаження нової версії компоненти потрібно оновити її на тестових доменах:

`deb1`;
`deb2`;
`deb3`.

Після оновлення потрібно перевірити функціональність. Мета цього етапу — переконатися, що нова версія:

коректно встановлюється;
не ламає наявний функціонал;
сумісна з поточним середовищем;
не створює помилок у залежних модулях;
працює відповідно до опису в `history.txt`.

Критично. Не можна вважати компонент готовим після push або завантаження на сервер оновлень. Готовність підтверджується тільки після перевірки на тестових середовищах.

База даних і models.py

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

Файл:

models.py

відповідає за структури даних компоненти.

У документації компоненти потрібно описувати:

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

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

SQL і довідники

У K2 багато інтерфейсів спираються на довідники: товари, контрагенти, працівники, склади, проєкти, статуси, види документів, валюти, статті бюджету.

Для довідників важливо:

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

Для DropDown-полів SQL часто має повертати ключ і значення:

select id as k, name as v
from table_name
order by name

Важливо. Для довідників у K2Grid SQL має повертати зрозумілі `k` та `v`. Якщо цього не зробити, поле вибору може працювати некоректно.

K2Grid і YML

K2Grid може описувати таблиці через YML-файли. Такий підхід дозволяє створювати гриди, поля, сортування, фільтри, кнопки, довідники, master-detail-зв’язки та інші елементи інтерфейсу без хаотичного ручного кодування.

YML-опис таблиці зазвичай містить:

`select` — SQL-джерело;
`table` — логічна назва сутності;
`typeid` — тип опису;
`caption` — заголовок грида;
`sortname` — поле сортування;
`sortorder` — порядок сортування;
`height` — висоту;
`fields` — опис полів;
`detile` — зв’язок із детальною таблицею;
`getmaster` — режим деталі;
`masterid` — поле зв’язку з майстром;
`where` — фільтр для деталі.

Перевага K2Grid. YML-опис дозволяє стандартизувати таблиці, зменшити дублювання коду й швидше створювати бізнес-інтерфейси.

Master-detail

Зв’язок master-detail використовується, коли є головний запис і пов’язані рядки. Наприклад, документ і таблична частина, замовлення і позиції, завдання і рядки, накладна і товари.

У майстрі вказується детальна таблиця:

detile: document_rows

У деталі:

getmaster: true
masterid: documentid
where: " where (documentid='{masterid}') and (documentid<>'') "

Схема роботи:

користувач вибирає рядок у майстрі;
K2Grid читає ID майстра;
значення підставляється в `{masterid}`;
детальна таблиця показує тільки пов’язані рядки.

Архітектурний акцент. Master-detail — це базовий шаблон ERP: документ і рядки, замовлення і позиції, заявка і деталі.

Поля у K2Grid

У `fields` описуються колонки та поля форми.

Типові атрибути:

Атрибут	Призначення
`field`	фактичне поле з SQL select
`alias`	явне посилання на поле з урахуванням alias таблиці
`caption`	назва колонки або підпис поля
`width`	ширина колонки в гріді
`width_form`	ширина поля у формі
`align`	вирівнювання
`readonly`	заборона редагування
`hidden`	приховування колонки
`type_field`	тип редактора
`def_value`	значення за замовчуванням
`search`	участь у пошуку
`sql`	SQL для довідникового поля
`show_for`	обмеження видимості за користувачами

Важливо. Кожне поле, зазначене у `fields`, має бути в `select`, якщо воно використовується для відображення або логіки.

Типи полів

У K2Grid можуть використовуватися різні типи полів:

`date`;
`datetime`;
`checkbox`;
`DropDown`;
`condition`;
текстові поля;
числові поля;
службові поля;
приховані ID;
кнопки-дії.

Для DropDown потрібно вказувати SQL, який повертає `k` і `v`.

Приклад:

supplierid:
  field: supplierid
  caption: Постачальник
  type_field: DropDown
  sql: |
    select supplierid as k, name as v
    from suppliers
    order by name

Для кнопки через `condition`:

print:
  field: ' '
  caption: Д
  width: 30
  type_field: condition
  cond:
    exp: (false)
    url2: '/?adm=document&mode=admin&id={documentid}&op=print'
    caption2: <i class="fa-solid fa-print" title="Друк"></i>

Порада. Службові кнопки краще робити вузькими — 30–40 px, а пошук для них вимикати через `search: false`.

Права доступу в інтерфейсі

Розробник має враховувати права доступу на кількох рівнях:

меню;
грид;
поле;
кнопка;
форма;
серверна дія;
API;
база даних.

Приклад `show_for`:

show_for: "-1, 1"

Це означає, що поле або кнопка показується тільки користувачам із відповідними ID.

Але приховати кнопку в інтерфейсі недостатньо. Серверна дія також має перевіряти права.

Критично. Не можна покладатися лише на приховування кнопки в UI. Якщо дія важлива, права мають перевірятися і на backend-рівні.

Меню компонентів

Меню до класів може формуватися за допомогою масиву або автоматично через YML-файл. Прийнято зберігати меню в каталозі:

/папка_компоненти/res/menu/назва_меню.yml

Типові параметри меню:

`name` — ідентифікатор меню;
`caption` — заголовок;
`addcaption` — додатковий текст або бейдж;
`addcaption_style` — стиль бейджа;
`iconclass` — клас іконки;
`url` — адреса переходу;
`command` — команда або зарезервований функціонал.

Приклад:

- name: "k2test_phpgrid"
  caption: "PHPGrid Demo"
  addcaption: "+"
  iconclass: "bi bi-grid-3x3"
  url: "?adm=k2test_phpgrid"
  command:

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

UX для розробника K2

ERP-інтерфейс має бути не просто красивим. Він має бути зручним для щоденної роботи.

Розробник має думати про:

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

UX-принцип. Добрий ERP-інтерфейс економить час користувача щодня, а не просто добре виглядає на демо.

AJAX і збереження без перезавантаження

Для сучасних веб-модулів K2 важливо підтримувати роботу без зайвого перезавантаження сторінки. AJAX може використовуватися для:

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

Важливо. AJAX не скасовує серверну перевірку. Навіть якщо інтерфейс перевірив дані на frontend, backend має повторно перевірити права, валідацію й бізнес-правила.

Імпорт та експорт

Імпорт і експорт мають бути контрольованими функціями.

Розробник має врахувати:

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

Ризик. Експорт може винести з ERP критичні дані, а імпорт може зіпсувати довідники або залишки. Ці функції не можна робити без прав і перевірок.

Інтеграції

Інтеграція — це не просто “передали дані”. Це контрольований процес обміну між K2 і зовнішньою системою.

Для інтеграції потрібно описати:

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

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

Безпека розробки

Розробник K2 має думати про безпеку на кожному етапі.

Не можна:

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

Критично. Безпека в ERP — це не додаткова опція. Це частина кожної форми, кожного API, кожного SQL-запиту й кожної кнопки.

Продуктивність

ERP працює з великими обсягами даних. Тому розробник має враховувати продуктивність ще під час проєктування.

Потрібно:

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

Важливо. Те, що працює на тестових десяти записах, може не працювати на реальних ста тисячах документів.

Тестування

Тестування в K2 має перевіряти не тільки запуск сторінки, а повний бізнес-сценарій.

Для модуля потрібно перевірити:

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

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

Документація

Кожен модуль або компонент має мати документацію.

Документація має описувати:

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

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

Що не можна робити розробнику K2

Не можна:

змінювати бойову базу без процедури;
пушити код без перевірки;
робити оновлення без версії;
забувати `history.txt`;
комітити токени й паролі;
писати SQL без урахування продуктивності;
створювати дублікати довідників;
обходити стандартні права доступу;
робити інтерфейс без валідації;
залишати debug-режим у prod;
публікувати компонент без тесту;
копіювати стару логіку 1С/BAS без переосмислення;
створювати модуль без документації.

Заборона. Не виправляйте проблему “швидко в базі”, якщо це має бути зміна компоненти, міграції, моделі або бізнес-логіки.

Типові помилки розробників K2

Перша помилка — починати з коду, не зрозумівши бізнес-процес.

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

Третя помилка — створювати новий довідник замість використання спільного.

Четверта помилка — писати власний грид, коли є стандартний K2Grid.

П’ята помилка — забувати права доступу.

Шоста помилка — не перевіряти SQL на реальних обсягах даних.

Сьома помилка — комітити зміни без опису.

Восьма помилка — не оновлювати `setup.py` і `history.txt`.

Дев’ята помилка — не тестувати компонент на `deb1`–`deb3`.

Десята помилка — не писати документацію.

Висновок. Більшість проблем у ERP-розробці виникає не через складний код, а через відсутність дисципліни: прав, тестів, версій, документації та розуміння процесу.

Чек-лист перед передачею компоненти

Перед передачею компоненти потрібно перевірити:

код закомічено;
виконано `git status`;
виконано `git pull`;
конфлікти відсутні;
версію оновлено в `setup.py`;
опис змін додано в `history.txt`;
компоненту додано в `component-list.txt`;
ignore-файл налаштовано;
токен не потрапив у репозиторій;
компоненту завантажено через `k2update_push.py`;
оновлення перевірено на тестових доменах;
гриди відкриваються;
форми зберігаються;
права працюють;
імпорт і експорт перевірені;
документація оновлена;
помилки в логах перевірені.

Чек-лист якості коду

Код має бути:

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

Ознака якісного коду. Інший розробник може відкрити компоненту, зрозуміти її структуру, запустити, протестувати й продовжити роботу без дзвінка автору.

Розробка для магазину доповнень K2

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

Потрібно підготувати:

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

Важливо для marketplace. Доповнення для магазину K2 має бути продуктом, а не архівом файлів. Його мають розуміти, встановлювати, оновлювати й підтримувати інші люди.

Атестаційні завдання для розробників

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

Таке завдання перевіряє:

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

Практичний сенс. Атестаційне завдання має перевіряти не знання синтаксису, а здатність створити реальний ERP-модуль.

Як зрозуміти, що розробник готовий до K2

Розробник готовий до роботи з K2, якщо він:

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

Ознака готовності. Розробник K2 має мислити не “як зробити кнопку”, а “який бізнес-процес ця кнопка змінює”.

Поширені запитання

Що таке рекомендації для розробників K2?

Рекомендації для розробників K2 — це правила й практики створення модулів, компонентів, гридів, форм, документів, інтеграцій і оновлень у K2 ERP та K2 Cloud ERP.

Чому Git обов’язковий для розробки K2?

Git потрібен для контролю змін, командної роботи, історії версій, комітів, оновлень компонентів і безпечної підтримки ERP-коду.

Що таке auto_update?

`auto_update` — це скрипт для роботи зі списком компонентів: клонування, перевірки статусу, комітів, pull і push.

Чому потрібно оновлювати setup.py і history.txt?

`setup.py` містить версію компоненти, а `history.txt` пояснює, що саме змінилося. Без цього важко підтримувати оновлення й розуміти історію змін.

Навіщо тестувати на deb1-deb3?

Тестові домени потрібні, щоб перевірити нову версію компоненти до використання в ширшому середовищі.

Що найважливіше для розробника K2Grid?

Потрібно правильно описати `select`, `fields`, DropDown-поля, master-detail-зв’язки, кнопки `condition`, права доступу, ширини колонок, пошук і сортування.

Чи можна робити зміни напряму в базі?

Небажано. Прямі зміни в бойовій базі без процедури, backup, тестування й документації є ризиком для ERP.

Пов’язані сторінки

SEO-призначення сторінки

Сторінка Рекомендації для розробників K2 має допомагати розробникам, партнерам і технічним командам знаходити правила створення якісних модулів для K2 ERP та K2 Cloud ERP: компоненти, Git, auto_update, K2Grid, YML, гриди, форми, база даних, права доступу, тестування, оновлення, документація та безпека.

Вона покриває запити: “рекомендації для розробників K2”, “K2 ERP для розробників”, “розробка модулів K2”, “K2 Cloud ERP Python”, “K2Grid YML”, “компоненти K2 ERP”, “Git K2 ERP”, “auto_update K2”, “k2update_push.py”, “розробка ERP модулів”, “K2 ERP backend”, “K2 ERP frontend”, “українська ERP розробка”.

Коротко

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

Розробник K2 має працювати через Git, дотримуватися компонентної архітектури, описувати структуру даних, перевіряти права доступу, тестувати зміни на окремих середовищах, оновлювати версії, вести `history.txt` і думати про реальний бізнес-процес, а не лише про код.

Головний висновок. Якісна розробка K2 — це дисципліна: компонентність, Git, база даних, права, UX, тестування, документація й відповідальність за бізнес-дані клієнта.

Див. також

Що означає бути розробником K2

Основні принципи розробки K2

Локальне середовище розробника

PyCharm і Python Interpreter

Git-дисципліна

Коміти

Робота з auto_update

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

Компонентна архітектура

Версії компонентів

Сервер оновлень

Тестові домени deb1-deb3

База даних і models.py

SQL і довідники

K2Grid і YML

Master-detail

Поля у K2Grid

Типи полів

Права доступу в інтерфейсі

Меню компонентів

UX для розробника K2

Рекомендації для гридів

Рекомендації для форм

Рекомендації для документів

AJAX і збереження без перезавантаження

Імпорт та експорт

Інтеграції

Безпека розробки

Продуктивність

Тестування

Документація

Рекомендації щодо назв

Що не можна робити розробнику K2

Типові помилки розробників K2

Чек-лист перед передачею компоненти

Чек-лист якості коду

Рекомендації для junior-розробника K2

Рекомендації для middle-розробника K2

Рекомендації для senior-розробника K2

Розробка для магазину доповнень K2

Атестаційні завдання для розробників

Як зрозуміти, що розробник готовий до K2

Поширені запитання

Що таке рекомендації для розробників K2?

Чому Git обов’язковий для розробки K2?

Що таке auto_update?

Чому потрібно оновлювати setup.py і history.txt?

Навіщо тестувати на deb1-deb3?

Що найважливіше для розробника K2Grid?

Чи можна робити зміни напряму в базі?

Пов’язані сторінки

SEO-призначення сторінки

Коротко

Див. також