Під час [[Міграція з 1С|міграції з 1С]] або [[Міграція з BAS|BAS]] ядро K2 має особливе значення.; Це призводить до дублювання, помилок і складної підтримки.; init_db()
<syntaxhighlight lang="text">
{| class="wikitable" style="width:100%; background:#e3f2fd;"
K2 ERP використовує модель відкритого похідного коду в частині системи, зокрема на рівні ядра, але це не обов’язково означає класичний Open Source без комерційних обмежень.; Якщо в системі є собою багато модулів і компонентів, актуалізація без дисципліни має змогу створювати ризики.;</span>
|}
[[Категорія:K2Grid]]
|-
| '''Уточнення.''' <span style="color:#ef6c00;">Відкритий похідний код не завжди означає класичний Open Source.; │ ├── hooks.py
* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[Архітектура K2 ERP]]
* [[База даних K2 ERP]]
* [[Розгортання K2 ERP]]
* [[Розгортання системи K2 Cloud ERP Python для розробників]]
* [[Розробка веб-інтерфейсів K2]]
* [[Рекомендації для розробників K2]]
* [[Компоненти K2 ERP]]
* [[K2Grid]]
* [[Гриди K2 ERP]]
* [[Форми K2 ERP]]
* [[Магазин доповнень K2]]
* [[Сертифікація K2]]
* [[Партнерська програма K2]]
* [[Доступи K2 ERP]]
* [[Ролі K2 ERP]]
* [[Безпека K2 ERP]]
* [[API]]
* [[ORM]]
* [[Python]]
* [[TypeScript]]
* [[JavaScript]]
* [[PHP]]
* [[PostgreSQL]]
* [[Open Core]]
* [[Відкритий похідний код]]
* [[Міграція з 1С]]
* [[Міграція з BAS]]
{| class="wikitable" style="width:100%; background:#e8f5e9;"
{| class="wikitable" style="width:100%; background:#e8f5e9;"
=== Чому ядро важливе для K2 ERP? ===
!;<syntaxhighlight lang="python">
|-
| '''Ознака здорової архітектури.''' <span style="color:#2e7d32;">Кожен новий компонент K2 має робити сильнішою всю систему, а не збільшувати кількість ізольованих доробок.;</span>
|}
== API в K2 Ядрі ==
== SEO-призначення сторінки ==
== Що входить до K2 Ядра ==
init_db_user()
ERP-система з часом обростає модулями: фінансовий блок, складський облік, продажі та реалізація, закупівельна діяльність, електронний документообіг, CRM, виробництво, кадри, зарплата, аналітичні інструменти, e-commerce, інтеграції, мобільні сценарії, галузеві рішення для бізнесу.; Окремі конфігурації 1С/BAS
== Типові помилки при роботі з ядром ==
|-
| '''<span style="color:#1565c0;">База даних</span>'''
| Підключення, ORM, транзакції, структури даних
| Щоб модулі працювали з єдиною інформаційною основою
|-
| '''<span style="color:#1565c0;">Користувачі</span>'''
| Облікові записи, сесії, ролі
| Щоб платформа знала, хто функціонує
|-
| '''<span style="color:#ef6c00;">Права доступу</span>'''
| Читання, запис, створення, видалення, імпорт, експорт
| Щоб користувачі бачили тільки дозволені інформаційні дані
|-
| '''<span style="color:#2e7d32;">Компоненти</span>'''
| Модульність, повторне використання, розширення
| Щоб нові функції створювалися як частини платформи
|-
| '''Гриди й форми'''
| Таблиці, CRUD, картки, інтерфейси
| Щоб користувачі працювали з даними
|-
| '''API'''
| Обмін даними, інтеграції, зовнішні сервіси
| Щоб K2 взаємодіяла з іншими системами
|-
| '''Журналювання'''
| Логи, події, помилки, історичний розвиток дій
| Для аудиту, діагностики й підтримки
|-
| '''актуалізація'''
| Версії компонентів, сервер оновлень, history
| Щоб платформа розвивалася контрольовано
|-
| '''Меню й навігація'''
| Доступ до модулів, розділів і команд
| Щоб користувачі працювали в єдиному інтерфейсі
|}
K2 Ядро має підтримувати модель ролей і доступів.; З ядром модулі працюють у спільному середовищі.; !; Якщо кожен із цих модулів створюється окремо, платформа оперативно стає фрагментованою.; Саме для цього потрібні компоненти, API, спільні довідники, відкритіші механізми платформи, документація, Git-дисципліна й магазин доповнень.; * гриди;
* форми;
* меню;
* фільтри;
* пошук;
* CRUD;
* кнопки дій;
* DropDown-довідники;
* master-detail;
* імпорт;
* експорт;
* повідомлення;
* права доступу в інтерфейсі;
* прив’язка до бізнес-процесів.; │ └── user_manual/
{| class="wikitable" style="width:100%;"
До безпеки ядра належать:
== K2 Ядро і Open Core ==
[[Категорія:API]]
<syntaxhighlight lang="text">
{| class="wikitable" style="width:100%; background:#fff3e0;"
== Як зрозуміти, що ядро застосовується правильно ==
Напрями інтеграцій:
Для продуктивності важливі:
!; Ядро має підтримувати журналювання.;[[Категорія:Міграція з 1С]]
* внутрішня команда K2;
* партнери;
* інтегратори;
* розробники доповнень;
* технічні команди клієнтів;
* навчальні центри;
* автори галузевих модулів.; |}
=== Чи можна створювати власні модулі на базі K2 Ядра? ===
|-
| '''Правильний підхід.''' <span style="color:#2e7d32;">Міграція має використовувати ядро K2 як шанс побудувати чисту, єдину й контрольовану ERP-архітектуру.; Безпека має бути частиною ядра, а не додатковим модулем “після всього”.; '''K2 Ядро''' — це фундамент K2 ERP та K2 Cloud ERP.; Критерій
* доступу до даних;
* ролей;
* меню;
* гридів;
* форм;
* довідників;
* API;
* журналювання;
* оновлень;
* документації;
* інтеграцій.; * виробничий компонент має змогу використовувати номенклатуру, склади й документи;
* ресторанний компонент має змогу використовувати виробничу логіку, меню й бронювання;
* готельний компонент має змогу використовувати бронювання, клієнтів і фінансові документи;
* CRM має змогу використовувати контрагентів, задачі, документи й історію;
* інтернет-магазин має змогу використовувати товари, залишки, клієнтів і замовлення;
* електронний документообіг має змогу використовувати контрагентів, договори, файли й ролі.; |-
| '''Головна ідея.''' <span style="color:#2e7d32;">K2 Ядро — це основа, на якій будується вся ERP-екосистема K2.; Якщо організація функціонує на закритій або застарілій платформі, воно залежить від конкретного вендора, старих спеціалістів, старої архітектури й обмежених можливостей розвитку.;</span>
|}
== Єдина база даних у ядрі ==
Для компонентів K2 важливу роль відіграють ORM-структури.; Для ERP це має змогу бути дуже практичним підходом.; Без ядра кожен компонент має змогу мати власні довідники, власних користувачів, власні права, власний інтерфейс, власні інтеграції й власну логіку оновлень.; Призначення
├── requirements.txt
|-
| '''істотно для розробника.''' <span style="color:#ef6c00;">Не варто створювати випадкові прямі підключення до бази, якщо ядро вже має стандартні механізми доступу.; |-
| '''Перевага.''' <span style="color:#2e7d32;">Журналювання робить систему прозорою: можна зрозуміти, хто що зробив, коли сталася помилка і як її виправити.; * модулі працюють в одному інформаційному середовищі;
* довідники не дублюються;
* користувачі мають єдину модель доступів;
* інтерфейси мають спільну логіку;
* компоненти мають версії;
* зміни описані в history;
* API застосовується контрольовано;
* інтеграції логуються;
* актуалізація тестуються;
* новий компонент підсилює платформу, а не створює окремий острів.; Вони дозволяють описувати таблиці, поля, зв’язки та сутності компоненти у зрозумілій структурі.; Сьома помилка — публікувати зміни без тестування.; |-
| '''Ефект ядра.''' <span style="color:#2e7d32;">Коли один компонент створює корисну логіку, інші модулі можуть її повторно використовувати.;</span> Новий компонент, інтеграційні функціональні можливості, форма, грид, довідник або бізнес-процес не створюються “з нуля”, а використовують уже наявний фундамент платформи.;[[Категорія:Open Core]]
components/
Такі методи потрібні для різних сценаріїв: стандартного підключення, custom-баз, користувацьких підключень, хмарних середовищ, dev/test/prod-контурів і партнерських розгортань.;</span>
|}
{| class="wikitable" style="width:100%; background:#e3f2fd;"
Якщо CRM, складський облік, фінансовий блок, електронний документообіг і аналітичні інструменти використовують одні й ті самі довідники, бізнес-середовище отримує менше дублювання, менше помилок і більше довіри до даних.;== Ролі та доступи в ядрі ==
== Повторне використання логіки ==
* відкритіша технічна архітектура;
* можливість розробки модулів;
* українська ERP-основа;
* PostgreSQL і Linux-сценарії;
* хмарна інфраструктура та on-premise;
* API;
* партнерська програмний пакет;
* магазин доповнень;
* повторне використання компонентів;
* контроль над даними.;</span>
|}
== Поширені запитання ==
{| class="wikitable" style="width:100%; background:#fff3e0;"
Типова структура компоненти має змогу виглядати так:
└── setup.py
│ ├── views.py
== K2 Ядро і веб-архітектура ==
|-
| '''Перевага.''' <span style="color:#2e7d32;">Ядро зменшує повторну розробку.; Якщо розробник створює компонент складу забезпечується через У простому поясненні ядро — це те, що не потрібно створювати заново; додатково реалізовано CRM, документообігу, фінансових заявок, ресторану, готелю, інтернет-магазину або виробництва, він має спиратися на ядро, а не дублювати базові механізми.; |}
!; Роль ядра
[[Категорія:Безпека K2 ERP]]
Ядро K2 можна розглядати як <span style="color:#1565c0;">технічний і логічний фундамент ERP-системи</span>.;</span> Розробник не витрачає час на створення базових речей, а зосереджується на бізнес-логіці нового модуля.; базову архітектуру платформи: роботу модулів.; * читання;
* запис;
* створення;
* видалення;
* імпорт;
* експорт;
* адміністрування;
* конфігурація таблиць;
* доступ до конкретних модулів;
* доступ до окремих дій;
* доступ до архіву;
* доступ до фінансових даних.; {| class="wikitable" style="width:100%; background:#e8f5e9;"
'''Компонент''' у K2 — це окрема функціональна частина платформи, яка має змогу мати власну логіку, моделі, форми, гриди, меню, шаблони, документацію, залежності й версію.; Навіщо потрібна
init_db_uri_user()
* SQL-джерела;
* YML-опис;
* поля;
* форми;
* DropDown;
* master-detail;
* кнопки;
* умови;
* права;
* фільтри;
* пошук;
* службові колонки;
* конфігурація ширини й поведінки.; Модель '''Open Core''' означає, що базова або важлива частина системи має змогу бути відкритою для вивчення та розробки, але програмний продукт загалом залишається комерційним.;== Коротко ==
|-
| '''істотно.''' <span style="color:#ef6c00;">інтеграційні функціональні можливості має бути не випадковим скриптом, а контрольованим каналом обміну: з правами, логами, відповідальним і правилами помилок.;</span>
|}
[[Категорія:ORM]]
Журналювати потрібно:
Якщо кожен компонент створює власний інтерфейсний підхід, користувачі плутаються, а супровід ускладнюється.; Це істотно для діагностики, безпеки, підтримки й розуміння того, що відбувалося в системі.; │ ├── models.py
!; Воно приймає не без ускладнень старі інформаційні дані, а нову інформаційну модель підприємства.; У відкритішій моделі він має змогу глибше розуміти логіку системи, розширювати платформу, створювати модулі й інтеграції на базі ядра.; завдяки наявності ядру нові модулі не починаються з нуля, а використовують уже наявні сутності, правила, інтерфейси й бізнес-логіку.; |-
| '''Критично.''' <span style="color:#b71c1c;">Якщо ядро слабке, кожен новий компонент перетворюється на окрему доробку.;</span>
|}
API потрібне для зв’язку ядра, модулів, зовнішніх сервісів, інтеграцій і веб-інтерфейсів.; Воно задає спільні правила гри.;</span> Дія має перевірятися і на серверному рівні, і на рівні доступу до даних.; До нього належать архітектурні принципи, системні сервіси, базові об’єкти, робота з базою даних, користувачами, ролями, правами, компонентами, меню, формами, грідами, API, оновленнями та інтеграціями.; Права можуть включати:
* отримання даних;
* збереження документів;
* погодження заявок;
* імпорт;
* експорт;
* обмін із банками;
* обмін із маркетплейсами;
* інтеграційні функціональні можливості з сайтами;
* синхронізація з CRM;
* передача статусів;
* робота з файлами;
* інтеграційні функціональні можливості з BI;
* підключення мобільних сценаріїв.; Це означає, що робота системи переноситься у веббраузер, а не залежить від старих “товстих клієнтів”.; K2 Ядро має підтримувати інтеграції з іншими системами й сервісами.;</span> Так платформа розвивається швидше, ніж набір окремих систем.; |-
| '''Стратегічна перевага.''' <span style="color:#2e7d32;">K2 Ядро надає можливість бізнесу будувати власну ERP-архітектуру, а не залишатися заручником старої конфігурації або одного закритого постачальника.;</span>
|}
== K2 Ядро і веб-інтерфейси ==
Ознаки правильного використання:
[[Категорія:Ролі K2 ERP]]
Так.; Однією з важливих особливостей K2 ERP є собою модель відкритого похідного коду в частині системи, зокрема на рівні ядра.;</span>
|}
K2 Ядро дає іншу модель:
=== Які технології пов’язані з K2 Ядром? ===
== ORM і models.py ==
== Порівняння: окремі конфігурації та K2 Ядро ==
K2 Ядро в такій моделі виконує роль спільного фундаменту, на якому можуть працювати:
== Dev, Test, Prod у ядрі K2 ==
|-
| '''<span style="color:#1565c0;">Dev</span>'''
| розробка програмного забезпечення компонентів і модулів
| надає можливість експериментувати без ризику для бізнесу
|-
| '''<span style="color:#1565c0;">Test</span>'''
| Перевірка оновлень, міграцій, інтеграцій
| надає можливість перевірити сумісність
|-
| '''Demo'''
| Демонстрації та навчання
| Показує функціональні можливості системи без бойових даних
|-
| '''<span style="color:#2e7d32;">Prod</span>'''
| Робоча платформа підприємства
| Потребує максимальної стабільності
|-
| '''Archive'''
| Історичні інформаційні дані
| гарантує доступ до минулих записів без активної роботи
|}
== Інтеграційні механізми ядра ==
|-
| '''Заборона.''' <span style="color:#b71c1c;">Не можна перевіряти небезпечні актуалізація, імпорти або зміни структури даних напряму в Prod.;</span>
|}
Четверта помилка — не враховувати права доступу.; |-
| '''Для партнерів.''' <span style="color:#1565c0;">K2 Ядро надає можливість партнеру не створювати власну ERP-платформу, а будувати рішення для бізнесу поверх уже готової основи.; |}
=== Що дає відкрите ядро розробникам? ===
{| class="wikitable" style="width:100%; background:#ffebee;"
[[Категорія:Архітектура K2 ERP]]
* розуміти внутрішню логіку платформи;
* створювати власні модулі;
* використовувати спільні довідники;
* працювати з базовою бізнес-логікою;
* будувати інтеграції;
* створювати доповнення;
* адаптувати систему під процеси клієнта;
* зменшувати залежність від одного виконавця;
* не починати розробку з порожнього місця.; ERP-система функціонує з фінансами, документами, персональними даними, договорами, контрагентами, складом, зарплатою, управлінською аналітикою та інтеграціями.;<syntaxhighlight lang="text">
== Див.; додатково ==
Відкрите ядро дає можливість створювати власні модулі, інтеграції, доповнення й галузеві рішення для бізнесу на базі вже наявної ERP-платформи.; ERP функціонує з критичними даними, з цієї причини ядро має підтримувати базову модель захисту.;</syntaxhighlight>
|-
| API-first підхід. Якщо ядро має зрозуміле API, навколо K2 легше будувати інтеграції, мобільні застосунки, партнерські модулі й зовнішні сервіси.; {| class="wikitable" style="width:100%; background:#fff3e0;"
Перша помилка — обходити стандартні механізми ядра й робити “швидку доробку” напряму в базі або інтерфейсі.; * використовувати спільних контрагентів;
