Версія K2 ERP

 

Якщо немає журналу змін, складно зрозуміти:

Правильне керування версіями дає можливість:

!; компонент

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

Службі підтримки потрібна відомості про версію.; Якщо [[K2 ERP]] застосовують, коли потрібно як хмарний сервіс, актуалізація має змогу виконуватися централізовано.; * що саме встановлено у клієнта;
* які функції доступні;
* чому в одній базі є собою документ, а в іншій немає;
* чому API функціонує по-різному;
* які зміни були внесені;
* чи можна оновлювати систему;
* чи сумісний компонент з поточним релізом;
* як відтворити помилку;
* яку інструкцію показувати користувачу.; K2 BAS Migration 0.9.2

'''Цифрова незалежність.''' реліз [[K2 ERP]] — це не без ускладнень номер.; При оновленні можуть змінюватися:

Під час переходу з [[BAS]] у [[K2 ERP]] версійність має стати частиною нової культури автоматизації: замість хаотичних доробок, невідомих обробок і непередбачуваних оновлень — контрольовані релізи, changelog, тестові бази, резервні копії, API-документація, BI-версії й прозора супровід.; Після актуалізація або міграції потрібно виконати звірки.; Вона надає можливість контролювати функціональність, релізи, модулі, API, BI, ролі, права, інтеграції, виправлення, міграції й підтримку.;<syntaxhighlight lang="text">
{| class="wikitable" style="width:100%;"
|-
| Development
| розробка програмного забезпечення нових функцій
|-
| Test
| Тестування змін
|-
| Staging
| Перевірка перед продуктивом
|-
| Production
| Робоча платформа користувачів
|-
| Archive
| Архівні інформаційні дані й історичні бази
|}

як ілюстрація:

<syntaxhighlight lang="text">

<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">

* змінилася форма документа;
* додано новий статус;
* додано нову кнопку;
* змінився звіт;
* з’явилася нова роль;
* змінилися права;
* змінився порядок проведення;
* з’явилися нові обов’язкові поля;
* змінилася друкована форма.; API має окреме значення, бо ним користуються зовнішні системи.; Ядро
MAJOR.MINOR.PATCH
Без версій складно зрозуміти:
|-
| організація А
| 3.2.5
| складський облік, продажі та реалізація, фінансовий блок
| API сайту
|-
| організація Б
| 3.2.5
| Агро, складський облік, автотранспорт
| GPS-інтеграція
|-
| організація В
| 3.1.9
| бухгалтерський обліковий облік, зарплата
| Старий BI-шар
|}

реліз має змогу включати зміни локалізації:

Вони дозволяють:

Потрібно версіонувати:

розробників забезпечується через У [[K2 ERP]] поняття версії важливе; додатково реалізовано адміністраторів, користувачів, впроваджувачів, служби підтримки, керівників проєктів, інтеграторів і компаній, які переходять з [[BAS]] або [[1С]] на українську ERP-платформу.; Відповідь

як ілюстрація:

* контрагентів;
* номенклатури;
* складів;
* договорів;
* залишків;
* документів;
* користувачів;
* ролей;
* цін;
* серій;
* характеристик;
* взаєморозрахунків;
* історії;
* інтеграційних ключів.;</div>

* версію API;
* список методів;
* приклади запитів;
* приклади відповідей;
* авторизацію;
* коди помилок;
* обмеження;
* зміни між версіями;
* deprecated-методи;
* дату вимкнення старих методів.; # Мати план відкату.; Змінено:

== реліз і аудит ==

* сайт;
* CRM;
* WMS;
* мобільний застосунок;
* BI;
* банк;
* маркетплейс;
* зовнішній інтегратор.; | реліз — це номер або стан продукту, а реліз — опублікований набір змін для використання.;<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
як ілюстрація:
== реліз і статуси документів ==

[[Категорія:Журналювання]]

== реліз модуля K2 ERP ==

Потрібно врахувати:

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

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

[[Категорія:JSON]]

* контролю змін;
* актуалізація системи;
* аналізу помилок;
* підтримки користувачів;
* сумісності модулів;
* міграції даних;
* тестування;
* інтеграцій;
* API;
* BI-аналітики;
* документування;
* аудиту;
* безпеки;
* планування розвитку ERP.; K2 ERP 3.2.4 → K2 ERP 3.2.5

Окремі модулі можуть мати власні версії.; !; Приклад

== реліз і журналювання ==

реліз системи потрібна для:

* перевірки нових функцій;
* перевірки старих сценаріїв;
* перевірки ролей;
* перевірки API;
* перевірки BI;
* перевірки друкованих форм;
* перевірки інтеграцій;
* перевірки міграцій;
* навчання користувачів.; Ділянка
Deprecated — це функція, яка ще функціонує, але буде замінена або видалена.;== реліз ядра K2 ERP ==
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">

[[Категорія:API]]
Погані підходи:
'''істотно про BAS і 1С.''' [[BAS]] та [[1С]] мають санкційні, юридичні й кібербезпекові ризики в Україні.;== Помилка: не перевірити права після актуалізація ==

!;</div>
== Вступ ==
|-
| реліз
| Позначення стану продукту або модуля
| 2.4.1
|-
| Реліз
| Опублікований набір змін для користувачів
| Реліз 2.4
|-
| Збірка
| Конкретний технічний результат складання коду
| build 240115
|-
| Патч
| Невелике виправлення
| 2.4.1-patch2
|-
| Hotfix
| Термінове виправлення критичної проблеми
| 2.4.1-hotfix1
|}

== Зовнішні посилання ==

Такі зміни мають бути погоджені з бізнесом.; !; * складський облік;
* продажі та реалізація;
* закупівельна діяльність;
* фінансовий блок;
* бухгалтерський обліковий облік;
* виробництво;
* зарплата;
* кадри;
* CRM;
* логістика;
* автотранспорт;
* агро;
* громадське харчування;
* акцизне паливо;
* BI;
* API;
* інтеграції.; Потрібно перевіряти:
має змогу зламатися:
Він має змогу містити правила перенесення:

За версію мають бути відповідальні.;== реліз і міграція з BAS ==

* у версії 3.2.4 звіт рахує неправильно;
* у версії 3.2.5 помилку виправлено;
* у версії 3.3.0 змінено API;
* у версії 3.3.1 виправлено сумісність із BI.; Якщо права не перевірити:

Він має визначати:

{| class="wikitable" style="width:100%;"

* інструкції користувачів;
* інструкції адміністраторів;
* API-документацію;
* BI-опис;
* міграційні інструкції;
* характеристика ролей;
* характеристика бізнес-процесів;
* release notes.;== Помилка: API змінено без попередження ==

== Помилка: актуалізація без тестової бази ==

[[Категорія:Реліз K2 ERP]]

[[Категорія:Версія K2 ERP]]

* модель користувачів;
* ролі;
* права доступу;
* журналювання;
* електронний документообіг;
* довідники;
* API;
* конфігурація;
* базові сервіси;
* механізм оновлень;
* інтеграційні механізми;
* системні таблиці;
* web-інтерфейс.; Вона постійно розвивається.; Для підтримки має змогу бути істотно, які версії підтримуються.;== реліз і друковані форми ==

Можливі ролі:

Після актуалізація потрібно перевіряти друк.; реліз
Потрібно перевірити:
!; * таблиці;
* поля;
* індекси;
* зв’язки;
* довідники;
* службові записи;
* типи даних;
* історичні таблиці;
* журнальні таблиці;
* міграційні таблиці.; Будь-яке актуалізація має мати план відновлення.; Він має містити:

[[Категорія:Версії API]]
!; |-
| Довідники
| Контрагенти, номенклатура, склади, договори
|-
| Залишки
| Товари, кошти, взаєморозрахунки
|-
| Документи
| Відкриті замовлення, надходження, реалізації
|-
| Права
| Ролі, користувачі, доступи
|-
| API
| Замовлення, залишки, статуси, авторизація
|-
| BI
| KPI, продажі та реалізація, залишки, фінансовий блок
|-
| Звіти
| продажі та реалізація, складський облік, фінансовий блок, бухгалтерський обліковий облік
|}

як ілюстрація:

Їх можна використовувати для:

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

* [[K2]]
* [[K2 ERP]]
* [[ERP]]
* [[Оновлення K2 ERP]]
* [[Користувач K2 ERP]]
* [[Ролі K2 ERP]]
* [[API]]
* [[BI]]
* [[Журналювання]]
* [[Резервна копія]]
* [[Міграція з BAS]]
* [[Міграція з 1С]]
* [[Заміна BAS]]
* [[Заміна 1С]]
* [[BAS]]
* [[1С]]
* [[Оновлення BAS]]
* [[Конфігурація BAS]]
* [[Користувач BAS]]
* [[Роль BAS]]
* [[Веб-клієнт BAS]]
* [[Клієнт-серверний режим BAS]]
* [[Файловий режим BAS]]
* [[Web-сервіси 1С]]
* [[JSON 1С]]
* [[Інтеграція з BAS]]
* [[Інтеграція з 1С]]
* [[Інтеграція через файли]]
* [[Інтеграція через XML]]
* [[SQL]]
* [[JSON]]
* [[XML]]
* [[CSV]]
* [[Українське програмне забезпечення]]
* [[Автоматизація бізнесу]]
* [[Цифрова незалежність]]
* [[Деколонізація обліку]]

'''Правило.''' актуалізація версії [[K2 ERP]] без резервної копії робочих даних — погана практика.; Перед оновленням версії потрібно зробити резервну копію.; # Розділяти ядро, модулі, API, BI і міграції.; # Публікувати release notes.; * сайтів;
* CRM;
* WMS;
* мобільних застосунків;
* BI;
* банків;
* маркетплейсів;
* електронного документообігу;
* сервісів доставки;
* зовнішніх інтеграторів.; |}

<syntaxhighlight lang="text">

== реліз і клієнтські доопрацювання ==

== реліз і часові пояси ==

* розуміти, що встановлено;
* знати, що змінилося;
* швидше підтримувати користувачів;
* безпечніше оновлювати систему;
* контролювати API;
* контролювати BI;
* не ламати інтеграції;
* документувати зміни;
* тестувати релізи;
* планувати еволюція;
* якісно мігрувати з [[BAS]] і [[1С]].; # Тестувати версію на тестовій базі.; Feature flags — це перемикачі функцій.;<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">

- Помилку відображення валюти в BI.; Такі зміни мають виконуватися контрольовано.;<syntaxhighlight lang="text">

!; Якщо статуси використовуються в API або BI, зміни потрібно документувати.; | Зробити резервну копію, оновити тестову базу, перевірити ролі, API, BI, інтеграції, звіти й бізнес-сценарії.; * повідомляти клієнтів;
* публікувати release notes;
* мати тестове середовище;
* мати план відкату;
* підтримувати сумісність API;
* не ламати інтеграції без попередження;
* документувати зміни;
* контролювати доступи;
* перевіряти продуктивність.; |-
| Чим реліз відрізняється від релізу?;== реліз бази даних ==
migration_2026_05_16_update_stock_balances

Вона потрібна для:

реліз і інтеграції

Добрі release notes містять: Перед оновленням версії потрібно перевірити її на тестовій базі.; Перехід із BAS або 1С у K2 ERP має включати:

Для контрольованої роботи бажано мати кілька середовищ.;== реліз і середовища ==

реліз міграційного пакета

як ілюстрація:

нові дашборди;
нові KPI;
нові фільтри;
нові розрізи;
нові джерела даних;
нові правила розрахунку;
виправлення показників;
оптимізацію запитів;
нові ролі доступу.; реліз ядра важлива, бо від неї можуть залежати всі модулі.; !; * виправлення вразливостей;
посилення авторизації;
зміни токенів;
обмеження API;
покращення журналювання;
нові права;
блокування старих методів;
контроль експорту;
захист персональних даних.;{{SEO

реліз і on-premise

як ілюстрація, реліз `3.2.5` має змогу означати: третя велика реліз, другий функціональний реліз, п’яте виправлення.; * Сайт K2 ERP

Потрібно документувати: Якщо змінюється API, потрібно попередити інтеграторів.; Це інструмент контролю розвитку української ERP-системи: які зміни внесено, які процеси підтримуються, які інтеграції працюють і як бізнес-середовище поступово відходить від старої екосистеми BAS / 1С.; Тестова база потрібна для:

реліз K2 ERP має змогу мати вимоги до СУБД.; Правильний підхід. реліз K2 ERP має бути завжди відома, задокументована й пов’язана з changelog, release notes, тестуванням, резервною копією, API, BI, ролями, інтеграціями й планом актуалізація.; Кого стосується

migration_2026_05_15_add_counterparty_status

Друковані форми можуть змінюватися між версіями.; # Тестова реліз.; # Патчі.; !; як ілюстрація: Вона потрібна для: |- | Підготовка | Перевірити release notes | Адміністратор |- | Бекап | Зробити резервну копію | Технічний спеціаліст |- | Тест | Оновити тестову базу | Впроваджувач |- | Перевірка | Перевірити бізнес-сценарії | Ключові користувачі |- | Інтеграції | Перевірити API, сайт, BI | Інтегратор |- | Production | Оновити робочу базу | Адміністратор |- | Контроль | Перевірити після запуску | Власники процесів |}

Потрібно документувати:

!; Приклад

контроль версії;
план актуалізація;
резервна копія;
вікно актуалізація;
тестування;
контрольні звірки;
журнал змін;
відповідальний за актуалізація;
план відкату;
повідомлення користувачам.; Найчастіші помилки:

!;

У різних клієнтів має змогу бути різна конфігурація K2 ERP.; Архівні версії потрібні для:

коротку інструкцію;
відео;
демонстрацію;
оновлену Wiki-статтю;
чек-лист;
тестовий сценарій;
FAQ;
повідомлення в системі;
характеристика нових кнопок;
характеристика нових правил.;

</syntaxhighlight> з цієї причини в заявках потрібно вказувати версію.;

реліз і API-документація

що змінилося;
чому з’явилася помилка;
кого зачіпає актуалізація;
чи потрібно навчання;
чи змінився API;
чи потрібно перевіряти BI;
чи змінилися права;
які документи перевіряти.; !; Ядро K2 ERP — це базова частина системи.; Після актуалізація потрібно перевірити матрицю доступу.; * новий документ;
новий звіт;
новий довідник;
новий API-метод;
нова BI-панель;
нова роль;
нова інтеграційні функціональні можливості;
покращення інтерфейсу;
розширення модуля.;

Release notes — це характеристика релізу для користувачів або адміністраторів.;

реліз і регламентні задачі

Патч-версія

зарплату;
собівартість;
банк;
касу;
персональні інформаційні дані;
API;
BI;
експорт;
адміністрування;
закриті періоди;
службові обробки.; | Без версії складно відтворити помилку, зрозуміти функціональні можливості і визначити, чи потрібне актуалізація.; Вони мають бути зрозумілі не тільки розробникам.; !; # Робити резервну копію перед оновленням.; реліз надає можливість зрозуміти, який саме функціональні можливості доступний користувачам, які зміни були внесені, які помилки виправлені, які модулі сумісні між собою і як планувати актуалізація.; # Перевіряти ролі й права.; компонент

як ілюстрація:

реліз і архів

реліз проходить життєвий цикл.;

Патч зазвичай виправляє помилки.; Такі зміни потрібно описувати в release notes.; реліз потрібна для контролю.; |- | Що таке changelog?; замовник

як ілюстрація:

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

K2 ERP 3.1 → K2 ERP 3.2

реліз і feature flags

K2 ERP 2.x → K2 ERP 3.x

рахунок;
видаткова накладна;
акт;
договір;
ТТН;
касовий документ;
податкова форма;
етикетка;
сертифікат;
комерційна пропозиція.; Якщо K2 ERP встановлена на серверах клієнта, актуалізація має змогу потребувати окремого плану.;== Приклад регламенту актуалізація ==

реліз API потрібна для:

реліз і план відкату

доступ до серверів;
резервні копії;
версії ОС;
версії СУБД;
мережеві конфігурація;
інтеграції;
робочий графік компанії;
вікно простою;
відповідального адміністратора;
безпекові політики клієнта.;== Висновок ==

!; |- | Як реліз пов’язана з міграцією з BAS?; Але їх не варто вмикати в критичних процесах без погодження.; !; Середовище

Приклад: Робоча база — це середовище, де користувачі реально працюють.; Приклад:

реліз і моніторинг

реліз має змогу описувати:

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

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

реліз K2 ERP — це важливий елемент керування ERP-системою.; реліз бази даних описує структуру таблиць, полів, індексів, зв’язків, міграцій і службових змін.; # Документувати клієнтські особливості.; !; |- | Чи є собою санкційні ризики у BAS і 1С?; Навчання має змогу включати:

відновлення;
перевірки міграції;
порівняння даних;
аудиту;
захисту від помилок;
повторного тесту;
аварійного повернення.; Особливо істотно перевірити:

Якщо користувачів не повідомити, вони можуть сприймати актуалізація як помилку.; # Повідомляти користувачів.;== реліз BI K2 ERP == реліз має змогу мати структуру:

реліз і права доступу

розробка програмного забезпечення.; Він має відповідати на питання:

як ілюстрація:

- Інтеграцію із сайтом.; BI-версія

Приклад:

форматі дат;
часовому поясі користувача;
журналі подій;
API-часі;
BI-звітах;
регламентних задачах;
датах документів;
архівах.; Для чого

Версійність — це частина зрілої ERP-архітектури.; Без номера версії супровід функціонує повільніше.; |-

Що робити перед оновленням версії?; реліз і ролі фінального тестування; перевірки клієнтських сценаріїв; перевірки інтеграцій; перевірки BI; перевірки продуктивності; пошуку критичних помилок; погодження з бізнесом.; # Перевіряти друковані форми.; /api/v1/orders Найгірший сценарій. організація оновлює K2 ERP або міграційний контур без номера версії, changelog, тестової бази, резервної копії й перевірки API.; Де: Hotfix Ці поняття схожі, але не однакові.; !; актуалізація версії має фіксуватися в журналі змін.; {\| class="wikitable" style="width:100%;" Типові помилки у керуванні версіями реліз має змогу містити зміни в: реліз і користувачі що додано; що змінено; що виправлено; що видалено; що застаріло; що потрібно перевірити; що впливає на користувачів; що впливає на інтеграції; що впливає на API; що впливає на BI; що впливає на міграцію.;== Сумісність API == /api/v3/orders Це потрібно враховувати при підтримці.; {\| class="wikitable" style="width:100%;" Зміни інтерфейсу можуть впливати на користувачів.; Особливості як ілюстрація: Потрібно зберігати: Як правильно керувати версіями K2 ERP реліз і тестова база сайт; CRM; складську систему; BI; мобільний застосунок; обмін із банком; інтеграцію з BAS; інтеграцію з зовнішнім сервісом.; * не вести номер версії; не вести changelog; не робити release notes; не тестувати; не робити резервну копію; не перевіряти API; не перевіряти BI; не перевіряти ролі; не повідомляти користувачів; не мати плану відкату; оновлювати хаотично; не документувати клієнтські доопрацювання; ігнорувати санкційні й кібербезпекові ризики старих BAS/1С-систем під час міграції.; Коментар Потрібно перевіряти: Велика реліз Мінорна реліз зазвичай додає функціональність без повної зміни архітектури.;== реліз і навчання користувачів ==
складський облік 1.8	K2 ERP 3.2+	Потрібні нові права доступу
API 3.0	K2 ERP 3.2+	Потрібна нова авторизація
BI 1.5	K2 ERP 3.1+	Потрібні нові аналітичні таблиці
Міграція BAS 0.9	K2 ERP 3.0+	Потрібна нова структура довідників

актуалізація версій має змогу включати безпекові зміни.;== Коротко == як ілюстрація:

реліз і SLA

як ілюстрація: |- | Що таке реліз K2 ERP?; |-

| Чому реліз важлива для API?;

<syntaxhighlight lang="text">

Потрібно знати:

!; Окремі продукти [[1С]] і [[BAS]] внесені до переліків забороненого програмного забезпечення для окремих категорій організацій в Україні.; Для міжнародних або розподілених команд істотно враховувати часові пояси.;== реліз і життєвий цикл ==

</div>

== Мінорна реліз ==

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

* поточну версію;
* статус сервісів;
* помилки;
* час відповіді API;
* стан черг;
* стан інтеграцій;
* стан BI-оновлення;
* стан резервних копій;
* активні користувачі;
* критичні події.; # Внутрішнє тестування.; актуалізація версії має змогу змінити бізнес-процес.; # Вести журнал оновлень.; /api/v2/orders

Бета-функції — це функції, які ще не вважаються в цілому стабільними.; Під час переходу з [[BAS]] у [[K2 ERP]] реліз має значення.; | Так.; * де резервна копія;
* хто відповідає за відновлення;
* скільки часу потрібно;
* які сервіси потрібно зупинити;
* як повідомити користувачів;
* як перевірити відновлення;
* які інтеграції потрібно вимкнути;
* як не втратити документи, введені після актуалізація.; Регламентні задачі можуть залежати від версії.;== реліз і release candidate ==

{| class="wikitable" style="width:100%;"

Міграція бази даних — це сценарій зміни структури або даних.; API-документація має містити:

!; - Новий звіт "продажі та реалізація по каналах".;[[Категорія:Резервна копія]]
Hotfix — це термінове виправлення критичної проблеми.; !; | Це журнал змін: що додано, змінено, виправлено, видалено або позначено як застаріле.; # Архів.; !; Приклад:
[[Категорія:K2 ERP]]
Якщо документація застаріла, користувачі бачать інший інтерфейс і не можуть виконати інструкцію.; # Перевіряти інтеграції.; '''Головне.''' реліз [[K2 ERP]] показує, у якому стані перебуває платформа: які модулі, функції, документи, API, звіти, ролі, виправлення й зміни доступні в конкретному релізі.; Етап
== реліз і бета-функції ==

|- | 1.4 | Додано продажі та реалізація по регіонах | Керівники продажів |- | 1.5 | Додано маржинальність | Фінансовий директор |- | 1.6 | Додано складські KPI | Керівник складу |}

Можливі зміни:

Додано:

реліз K2 ERP — це ідентифікатор конкретного стану ERP-системи.;== реліз, реліз і збірка ==

Приклад:

!;== Навіщо потрібна реліз ==

- Помилку округлення в друкованій формі рахунку.;== реліз і регламент актуалізація ==

Без відповідальності актуалізація стають хаотичними.; * версію СУБД;

розширення;
індекси;
права користувачів БД;
резервне копіювання;
продуктивність;
міграції;
сумісність запитів;
конфігурація кодування;
часові пояси.; Release candidate — це версія-кандидат на реліз.; * новий;
погоджено;
у роботі;
проведено;
закрито;
скасовано;
очікує оплати;
готово до відвантаження;
передано в доставку.;== реліз і deprecated-функції ==

Changelog K2 ERP

План відкату відповідає на питання: що робити, якщо актуалізація не вдалося.; Для неї потрібні:

реліз і робоча база

Приклад changelog

завдяки наявності Аудит версій користувачі можуть зрозуміти історію змін.; Модулі

як ілюстрація:

== реліз і сумісність модулів ==

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

== реліз і контрольні звірки ==

* швидше відкриваються списки;
* швидше формуються звіти;
* оптимізовано запити;
* зменшено навантаження на API;
* покращено кешування;
* додано індекси;
* зменшено час проведення документів;
* виправлено повільні BI-запити.; З урахуванням санкційних, юридичних і кібербезпекових ризиків [[BAS]] та [[1С]], перехід на [[K2 ERP]] має включати не лише перенесення даних, а й побудову зрілої моделі керування версіями, оновленнями, підтримкою та розвитком української ERP-платформи.; # супровід.; * документ;
* звіт;
* API;
* BI;
* інтеграційні функціональні можливості;
* роль;
* друкована форма;
* міграція;
* бізнес-процес.; Інтеграції особливо чутливі до змін версії.;

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

реліз і локалізація

власник продукту;
технічний адміністратор;
DevOps;
розробник;
впроваджувач;
аналітик;
керівник проєкту;
власник бізнес-процесу;
служба підтримки;
інтегратор.; Зміна

реліз має змогу змінити статуси документів.; Відповідальний У такому випадку істотно:

Після актуалізація можуть з’явитися нові об’єкти.; Частина K2 ERP 3.2.5 migration_2026_05_17_create_api_tokens |- | MAJOR | Велика реліз з істотними змінами | 3 |- | MINOR | Функціональне актуалізація | 2 |- | PATCH | Виправлення помилок або мале актуалізація | 5 |}

як ілюстрація:

Іноді замовник має індивідуальні конфігурація або доопрацювання.;</syntaxhighlight>

Зміна API має змогу вплинути на:

реліз і сумісність із СУБД

пілотів;
тестування;
демонстрацій;
збору зворотного зв’язку;
раннього впровадження.; | Зміна API має змогу вплинути на сайт, CRM, WMS, BI, мобільний застосунок або зовнішні інтеграції.; це конкретний стан системи K2 ERP на певний момент часу: набір функцій.;

- Новий API-метод для отримання статусів замовлень.; як ілюстрація:

Якщо актуалізація ставиться одразу в production, ризики високі.; - Нову роль "Керівник складу".; |- | Чому реліз важлива для підтримки?; Простий приклад:

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

|- | складський облік | 1.8.0 | Додано серії, покращено інвентаризацію |- | продажі та реалізація | 2.1.3 | Виправлено знижки й статуси замовлень |- | API | 3.0 | Додано нові методи для замовлень |- | BI | 1.5 | Додано панель маржинальності |}

Див.; додатково

Погана практика — встановлювати нову версію одразу в робочу базу без тесту.;== реліз і безпека ==

платформу;
ядро системи;
компонент;
функціональний блок;
API;
базу даних;
web-інтерфейс;
мобільний інтерфейс;
BI-шар;
інтеграційний шар;
міграційний пакет;
документацію;
конфігурація;
шаблони друкованих форм.; * з якої версії BAS мігрують;
у яку версію K2 ERP мігрують;
які модулі K2 ERP потрібні;
яка реліз міграційного пакета;
яка структура довідників;
які документи підтримуються;
які API доступні;
які звіти потрібно перенести;
які ролі потрібно створити.;

які методи додано;
які методи змінено;
які методи застаріли;
які поля змінилися;
які статуси додано;
які помилки виправлено;
які методи будуть вимкнені.; {| class="wikitable" style="width:100%;"

Коли користувач системи повідомляє про помилку, потрібно знати:

Модулі мають бути сумісні між собою.; Що означає

- Ролі менеджерів.; !;</syntaxhighlight>

організація має мати регламент актуалізація K2 ERP.; Changelog — це журнал змін версії.; як ілюстрація:

реліз і резервна копія

реліз системи	2.4.1	Загальний реліз K2 ERP
реліз модуля	складський облік 1.8.0	реліз складського функціоналу
реліз API	API v3	реліз інтеграційного інтерфейсу
реліз BI	BI 1.5	реліз аналітичних панелей
реліз міграції	BAS Migration 0.9	Пакет перенесення даних із BAS

!; Користувачам потрібно знати, що змінилося.; * українська мова;

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

Неоновлена платформа має змогу мати технічні й безпекові ризики.; * відмову від хаотичних доробок;

контроль змін;
документування релізів;
прозорий changelog;
контроль API;
контроль BI;
контроль ролей;
контроль інтеграцій;
резервне копіювання;
тестові середовища;
зрозумілу підтримку;
українську ERP-архітектуру.; # Перевіряти BI.; !; з цієї причини перехід на K2 ERP має включати не тільки міграцію даних, а й перехід до прозорої моделі версій, оновлень, підтримки й контролю змін.; Міграційний пакет має змогу мати власну версію.; !; як ілюстрація:

Нова реліз має змогу впливати на продуктивність.; # Застарівання.; | Це конкретний стан системи або модуля з певним набором функцій, виправлень, API, звітів, прав і змін.; - Помилку доступу для сервісного користувача API.; !; * сайт;

CRM;
WMS;
банки;
BI;
маркетплейси;
мобільні застосунки;
електронний електронний документообіг;
логістику;
каси;
зовнішні API;
імпорт файлів;
експорт файлів.; * версію системи;
версію модуля;
версію API;
роль користувача;
середовище;
дату актуалізація;
чи повторюється помилка;
які зміни були перед цим;
чи функціонує це в тестовій базі.; Потрібно попереджати користувачів і інтеграторів про такі зміни.; * кнопка переїхала;
поле стало обов’язковим;
змінився порядок вкладок;
додано новий фільтр;
змінено список статусів;
змінено форму документа;
додано новий розділ меню;
прибрано стару дію.;</syntaxhighlight>

Велика реліз зазвичай означає суттєві зміни.; # Архівувати старі версії.; * короткий характеристика релізу;

нові функціональні можливості;
важливі зміни;
інструкції для користувачів;
інструкції для адміністраторів;
відомі обмеження;
список перевірок після актуалізація;
вплив на інтеграції;
вплив на API;
вплив на BI.; # Release candidate.;== реліз і бізнес-процеси ==

Для української ERP істотно мати якісну українську локалізацію.; | Потрібно знати версію BAS, версію K2 ERP, версію міграційного пакета і сумісність модулів.; # Реліз.; Виправлено: BI-аналітика додатково має змогу мати власну версію.; Вона відповідає на питання:

нова технічна архітектура;
новий інтерфейс;
нова модель прав;
нова структура бази;
новий API;
новий BI-шар;
нові основні модулі;
зміна принципів інтеграції;
значні зміни у міграції з BAS;
зміни, які потребують навчання користувачів.; Приклад:

як ілюстрація: K2 ERP у цьому процесі має змогу стати платформою для контрольованих версій, модулів, релізів, API, BI-аналітики, журналювання, прав доступу, резервного копіювання, web-доступу, міграційних пакетів і подальшого розвитку автоматизації бізнесу без залежності від старої екосистеми BAS / 1С.; - Оновлено форму документа "Замовлення покупця".; # Завершення підтримки.; Підхід K2 ERP. Версії K2 ERP мають документуватися: що змінено, які модулі оновлено, які помилки виправлено, які API змінено, які міграції виконано, які звіти додано, які ролі змінено і які дії потрібні користувачам після актуалізація.; # Присвоювати кожному релізу номер версії.;== реліз і конфігурація клієнта ==

реліз і документація

Вона має змогу включати:

Потрібно знати:

Якщо реліз суттєво змінює роботу, потрібне навчання.; # Перевіряти API.;== реліз і UI ==

реліз API K2 ERP

немає номера версії;
немає changelog;
зміни не документуються;
актуалізація робиться без тесту;
немає резервної копії;
API змінюється без попередження;
BI-показники змінюються без пояснення;
користувачів не інформують;
ролі змінюються непомітно;
немає плану відкату;
різні клієнти мають різні неописані версії;
незрозуміло, що встановлено в production.; актуалізація версії має змогу змінювати ролі.; # Вести changelog.; У K2 ERP можуть додаватися:

Приклад структури номера версії

Документація має відповідати версії системи.; як ілюстрація: 3.2.5 Права доступу потрібно перевіряти після кожного суттєвого актуалізація.; як ілюстрація:

реліз і супровід

як ілюстрація: </syntaxhighlight>

; Поняття

Правильний підхід: Помилка має змогу існувати тільки в певній версії.; - Покращено фільтр по складах.; Воно має змогу включати:

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

Після актуалізація потрібно перевірити, що вони працюють.;== Як не треба робити == - Оптимізовано запит для звіту по залишках.;

додано нову роль;
змінено права ролі;
додано доступ до нового документа;
обмежено доступ до звіту;
додано роль для API;
додано роль для BI;
змінено права адміністратора;
з’явилася нова група доступу.; Що звірити

нічний обмін;
актуалізація валют;
розрахунок собівартості;
побудова BI-вітрин;
синхронізація з CRM;
обмін із сайтом;
очищення тимчасових даних;
архівація;
перевірка ліцензій;
формування повідомлень.;== Помилка: немає changelog ==

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

що стандартне;
що індивідуальне;
які модулі змінені;
які звіти дороблені;
які API-методи додані;
які ролі спеціальні;
які друковані форми клієнтські;
які інтеграції унікальні;
чи сумісні вони з новою версією.;== реліз і відповідальність ==

- Звіт по залишках.;== Release notes ==

Якщо API змінити без попередження, можуть перестати працювати: ERP-система не є собою статичним продуктом.; Що означає Але після актуалізація потрібно перевірити продуктивність на реальних даних.;== реліз і помилки ==

реліз і продуктивність

Щоб керувати цими змінами, потрібне поняття версії.; !; !;== реліз K2 ERP і цифрова незалежність == Архів має бути захищений і не використовуватися як робоча платформа.;

Окремо варто відзначити модулів, довідників, документів, API-методів, звітів, ролей, прав доступу, бізнес-процесів, інтеграцій, виправлень, змін у базі даних, інтерфейсі і технічній архітектурі виступає ключовою рисою реліз K2 ERP.; Окремі продукти 1С і BAS внесені до відкритих переліків програмного забезпечення, забороненого до використання для окремих категорій організацій.; Зміни

== Міграції бази даних ==

реліз і інтеграції

реліз міграційного пакета

реліз і on-premise

реліз і API-документація

реліз і регламентні задачі

Патч-версія

реліз і архів

реліз і feature flags

реліз і план відкату

реліз і моніторинг

реліз і права доступу

реліз і ролі

Hotfix

Типові помилки у керуванні версіями

реліз і користувачі

Як правильно керувати версіями K2 ERP

реліз і тестова база

Велика реліз

реліз і SLA

Changelog K2 ERP

реліз і робоча база

Приклад changelog

реліз і локалізація

реліз і сумісність із СУБД

Див.; додатково

реліз і резервна копія

реліз і документація

реліз API K2 ERP

Приклад структури номера версії

реліз і супровід

реліз і продуктивність