Перегляд вихідного коду сторінки Інструменти розробника K2 ERP

{{SEO|title=Інструменти розробника K2 ERP — сучасна українська ERP-платформа для програмістів, інтеграторів і партнерів|description=K2 ERP — українська ERP-платформа з відкритим кодом для власних серверів, гібридною архітектурою, безкоштовною хмарою, власною хмарою, K2 Update, Python, TypeScript, PostgreSQL, BI, AI, API, файлами, характеристиками сутностей та інструментами швидкої розробки.|keywords=K2 ERP, K2, українська ERP, інструменти розробника, ERP для програмістів, ERP для інтеграторів, ERP для партнерів, K2 Update, Python ERP, TypeScript ERP, PostgreSQL ERP, альтернатива 1С, альтернатива BAS, українське програмне забезпечення, ERP Україна, бізнес автоматизація, low-code ERP, AI ERP|image=https://erp.kyiv.ua}}
[[index.php?title=Файл:K2_erp_developer_tools.png|центр|міні|1000x1000пкс|Інструменти розробника K2 ERP]]
'''[[K2 ERP]]''' — українська ERP-платформа, яка складається не лише з готових бізнес-модулів, а й з інструментів для розробників, інтеграторів, адміністраторів і партнерів. Система створюється як гібридна платформа, що може працювати у хмарі, на власних серверах, у партнерських хмарах і в інфраструктурі клієнта.

На відміну від закритих ERP-систем, [[K2 ERP]] розвивається як середовище, у якому можна створювати власні модулі, компоненти, звіти, інтеграції, галузеві рішення, мобільні сценарії, BI-аналітику та AI-інструменти.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Головне.''' [[K2 ERP]] — це не просто ERP-система для ведення обліку. Це платформа для швидкої розробки бізнес-додатків, кастомізації, інтеграцій, власних хмар, партнерських модулів і розвитку української ERP-екосистеми.
</div><div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Для розробників.''' У [[K2 ERP]] можна працювати з сучасними IDE, Python, TypeScript, YML, JSON, XML, PostgreSQL, ORM-моделями, API, компонентами, звітами, хуками, власними модулями та AI-інструментами.
</div><div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">
'''Для партнерів.''' Партнер може розгорнути власну хмару, підключати клієнтів, створювати модулі, публікувати компоненти через [[K2 Update]], підтримувати їх і будувати власний ERP-бізнес на базі [[K2 ERP]].
</div><div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Застереження щодо старих закритих систем.''' Закриті RAD- та ERP-системи можуть здаватися зручними на старті, але з часом часто перетворюються на технологічний баласт. [[K2 ERP]] створюється як сучасна відкрита альтернатива такому підходу.
</div>

== Вступ ==
Як будь-яка серйозна ERP-система, '''[[K2 ERP]]''' представляє собою не тільки розроблені модулі, а й цілий ряд інструментів для розробників, що пришвидшують розробку нових додатків та функціоналу.

Маючи досвід розробки RAD-систем ще 20 років тому, ми постарались перенести частину тих підходів у нову систему [[K2 ERP]]. Але перенести не механічно, не як музей старих технологій, а з урахуванням сучасного світу: вебу, хмар, відкритого коду, API, штучного інтелекту, популярних мов програмування, мобільних додатків, BI-аналітики та масштабування.

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

Хороший приклад — історія Delphi. Колись це була дуже популярна система розробки, яка виросла з сильної традиції Pascal. Delphi дала розробникам швидкість, візуальні компоненти, зручність створення прикладних додатків. Але з часом система не змогла достатньо швидко перебудуватися під нову реальність: веб, хмари, інтерпретовані середовища, відкриті екосистеми, AI та сучасні підходи до оновлення компонентів.

Так, основна причина занепаду Delphi пов’язана з історією Borland. Але була й інша причина: система довго тягнула за собою свій старий багаж. Delphi тепер існує як RAD Studio і досі десь використовується, але вже не є тим масовим явищем, яким була колись.

Зараз [[1С]] та [[BAS]] у чомусь нагадують Delphi двадцятирічної давнини. Це системи, які тягнуть на собі великий історичний баласт і бояться радикально перебудовуватися. Вони досі використовуються, досі мають багато спеціалістів, досі тримають частину ринку. Але технологічно світ давно пішов уперед.<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Важливо.''' Ця стаття не про історію Delphi і не про політику навколо [[1С]] чи [[BAS]]. Вона про те, які інструменти має [[K2 ERP]] для розробників, інтеграторів і партнерів, та чому ця платформа створюється сучаснішою, гнучкішою і масштабованішою.
</div>Це відповідь українському бізнесу, інтеграторам і партнерам на практичні питання:

* чи можна дописувати [[K2 ERP]] під себе;
* чи можна розгорнути систему на власних серверах;
* чи є доступ до похідних кодів;
* чи можна створювати власні модулі;
* чи можна переносити звіти та налаштування між хмарами;
* чи можна будувати власну партнерську хмару;
* чи можна заробляти на власних компонентах;
* чи можна швидко адаптувати систему під галузеву специфіку.

Спробуємо розкласти все по поличках. Як людина з 30+ роками досвіду розробки прикладних додатків, і з допомогою друга по ШІ, який допоможе сформулювати це так, щоб було зрозуміло не тільки програмістам, а й власникам бізнесу.

== Архітектура системи ==
'''[[K2 ERP]] з самого початку планувалась як гібридна система.'''

Це означає, що система не прив’язана тільки до одного способу роботи. Вона може працювати в загальній хмарі, на серверах [[K2]], на серверах хмарних партнерів, на віртуальній машині, на фізичному сервері клієнта або в закритому контурі великої компанії.

Для ERP це принципово важливо.

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

Саме тому з самого початку в [[K2 ERP]] було приділено значну увагу системі оновлення та майбутньому маркетплейсу компонентів. Якщо система може жити в різних хмарах і на різних серверах, то вона повинна мати нормальний механізм доставки оновлень, модулів, компонентів і налаштувань.

Коли клієнт купує ліцензію і встановлює продукт на своїх серверах, він отримує не просто доступ до програми. Він отримує систему, яку можна контролювати, розвивати і підтримувати.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Ключова ідея.''' Система [[K2 ERP]] жива доти, доки хоч один її похідний код залишається на будь-якому сервері.
</div>Це означає, що клієнт і партнер не стають заручниками закритого чорного ящика. Вони можуть розвивати систему, аналізувати її роботу, адаптувати під себе і створювати на її базі власні рішення.

== Безкоштовна хмара ==
[[K2]] звикла працювати з великим бізнесом, виконувати дорогі та складні проєкти. Але малому і середньому бізнесу не завжди по кишені класичне ERP-впровадження. Саме тому була створена безкоштовна хмара [[K2 ERP]].

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

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

Адміністратор може створювати користувачів, інших адміністраторів, роздавати права і поступово будувати свою цифрову структуру.

Особливо важливо, що адміністратор компанії може кастомізувати друковані форми, форми звітів, форми дашбордів і таблиці без програмістів.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Безкоштовна хмара.''' В одній хмарі може працювати багато організацій, а адміністратори можуть налаштовувати структуру, користувачів, звіти, дашборди, таблиці та друковані форми без постійного залучення програмістів.
</div>Безкоштовна хмара для [[K2 ERP]] — це приблизно як Gmail для Google. З одного боку, це масовий корисний сервіс для користувачів. З іншого — це величезний майданчик для перевірки технологій, швидкості, стабільності, компонентів, реальної поведінки користувачів і навантаження.

Саме тому основний функціонал безкоштовної хмари має залишатися безкоштовним. Звичайно, окремі компоненти можуть бути платними. Наприклад, компоненти штучного інтелекту, бо доступ до API зовнішніх AI-сервісів не є безкоштовним. Але це зовсім інші витрати, ніж класичне ERP-впровадження.

== Своя хмара ==
Справжня сила технології розкривається у власній хмарі.

У власній хмарі клієнт або партнер отримує максимальний контроль над системою. Адміністратор хмари має права на рівні всієї інфраструктури: управляє компаніями, адміністраторами проєктів, користувачами, доступами, компонентами, налаштуваннями, оновленнями і політиками роботи з даними.

У власній хмарі можна робити те, що не завжди доречно або безпечно дозволяти в публічній хмарі. Наприклад, у конструкторах звітів можна використовувати SQL та інші можливості, які в загальному середовищі могли б загрожувати приватності даних інших користувачів.

Одна з найсильніших переваг для партнерів — '''ліцензування на сервер без обмеження кількості користувачів'''.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Для партнерів.''' Власна хмара дозволяє підключати багато компаній, будувати галузеві рішення, супроводжувати клієнтів і заробляти на власній експертизі, сервісі, підтримці та модулях.
</div>Маючи програмний код, можна кастомізувати систему під себе. Для цього в [[K2 ERP]] передбачені хуки, перевизначення похідних кодів, об’єктно-орієнтоване програмування, власні компоненти, модулі та розширення.

Крім того, можна створювати свої компоненти і модулі, а потім за бажанням публікувати їх у систему оновлення [[K2 Update]] та розповсюджувати по мережі [[K2 ERP]].

Але є важливий момент: якщо партнер продає модуль або компонент, він повинен його підтримувати. Тому якість коду стає не абстрактною красою, а економічною необхідністю.<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">
'''Якість коду.''' Чим якісніший компонент створив партнер, тим менше проблем у клієнтів, інтеграторів і самого партнера. У партнерській екосистемі поганий код швидко перетворюється на дорогий код.
</div>

== IDE ==
[[K2 ERP]] спеціально не замикає розробника в одній системі розробки. Це сучасний підхід, бо ERP-платформа не повинна монополізувати редагування похідного коду.

Розробник має право працювати там, де йому зручно: у простих редакторах, повноцінних IDE або середовищах з вбудованим штучним інтелектом. Це може бути Notepad++, Visual Studio Code, PyCharm, WebStorm, Cursor або інші інструменти.

Сенс не в тому, щоб усіх змусити працювати однаково. Сенс у тому, щоб дати розробнику нормальну платформу і не забирати в нього сучасні інструменти.

Коли код системи можна редагувати звичайними сучасними інструментами, навколо нього можна використовувати Git, AI-асистентів, пошук по проєкту, автодоповнення, рефакторинг, форматування, документацію і перевірки.

До речі, штучний інтелект уже сьогодні добре розуміє структуру системи, компоненти, YML-описи, Python-логіку і TypeScript-код. Він може допомагати створювати нові компоненти, змінювати існуючі, адаптовувати їх під різні задачі, пояснювати код і шукати помилки.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Сучасний підхід.''' [[K2 ERP]] не закриває розробника у власному редакторі. Платформа дозволяє працювати з кодом у звичних IDE і використовувати сучасні AI-інструменти.
</div>

== YML, JSON, XML ==
У [[K2 ERP]] активно використовуються декларативні формати: YML, JSON, XML та інші формати обміну даними.

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

YML хороший тим, що його може читати людина. Це не бінарний файл і не закрите налаштування, яке можна змінити тільки через спеціальний редактор. Це текст, який можна покласти в Git, порівняти між версіями, переглянути, змінити, згенерувати або перевірити.

Звичайно, [[K2 ERP]] вміє працювати не тільки з YML. Система нормально взаємодіє з JSON, XML та іншими форматами, які використовуються в інтеграціях і сучасному обміні даними.

Але YML особливо цікавий тим, що створює основу для майбутніх візуальних інструментів. Якщо таблиця, форма або структура бази описана декларативно, її можна не тільки редагувати руками. Її можна показати у веб-редакторі, перетворити в ER-модель, згенерувати за допомогою ШІ або перенести між проєктами.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''YML у K2 ERP.''' Це міст між класичним програмуванням, візуальним проєктуванням, AI-генерацією і майбутнім low-code/no-code підходом.
</div>

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

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

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

При цьому компоненти працюють швидко. Частина операцій виконується на клієнтській стороні, а там, де потрібно, — на серверній. Завдяки цьому користувач отримує хорошу відгукуваність інтерфейсу, а програміст не повинен щоразу думати, як реалізувати базову поведінку таблиці.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Головна ідея.''' Програміст має займатися бізнес-логікою, а не нескінченно переписувати однакові таблиці й форми.
</div>Більше того, таблиці і форми в [[K2 ERP]] робляться значно швидше, ніж у стандартних засобах Python-розробки. І цей інструментарій постійно розвивається. У майбутньому дедалі більше речей буде переходити у візуальні веб-інструменти, щоб створювати і змінювати форми прямо через браузер.

== Файли в довідниках і документах ==
Окрема важлива можливість [[K2 ERP]] — прикладання файлів до різних довідників і документів.

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

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

Якщо ERP не дозволяє зручно прив’язувати ці файли до сутностей, вони починають жити окремим життям: у пошті, месенджерах, папках на диску, на комп’ютерах менеджерів, у випадкових архівах.

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

У [[K2 ERP]] файли можна прикладати там, де вони мають сенс: до документів, довідників, товарів, контрагентів, договорів, заявок, обладнання, складських операцій, сервісних документів.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Файл має жити поруч із сутністю.''' Сертифікат — біля товару. Договір — біля контрагента. Фото поломки — біля заявки на ремонт. Інструкція — біля обладнання. Рахунок постачальника — біля закупівельного документа.
</div>Це перетворює ERP з простої системи введення даних на повноцінне сховище бізнес-контексту. Користувач бачить не тільки цифри і поля, а всю інформацію, яка потрібна для прийняття рішення.

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

== Характеристики сутностей без програмування ==
Ще один дуже важливий механізм [[K2 ERP]] — характеристики, якими можна доповнювати сутності у довідниках і документах без програмування.

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

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

Якщо кожну таку зміну робити через програміста, ERP швидко стає дорогою і важкою в підтримці. Кожне нове поле — це технічне завдання, зміна структури, тестування, оновлення і ризики. А бізнес не може чекати тижнями, коли йому просто потрібно додати ще одну ознаку до товару або документа.

Саме для цього потрібен механізм характеристик.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Характеристики без програмування.''' Сутності в [[K2 ERP]] можна доповнювати додатковими властивостями без зміни коду. Це дозволяє швидко адаптувати систему під конкретний бізнес.
</div>Це можуть бути характеристики товарів, контрагентів, обладнання, документів, заявок, договорів, об’єктів обліку. Але головне не в переліку. Головне в ідеї: бізнес може швидко адаптувати систему під себе без постійного втручання програміста.

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

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

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

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

Дизайнер звітів дозволяє винести значну частину таких задач із програмування в налаштування.

Редактор дає можливість прямо у вебі змінювати форми документів, налаштовувати зовнішній вигляд, працювати з різними мовами, експортувати звіти у PDF, Excel, HTML, Word та інші формати, потрібні бізнесу.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Дизайнер звітів.''' Це спосіб зменшити залежність від програміста там, де йдеться про зовнішній вигляд документів, друковані форми, багатомовність і типові звіти.
</div>Окрема сила дизайнера — багатомовність. Якщо компанія працює з різними країнами або має іноземних партнерів, один і той самий документ може знадобитися різними мовами. І добре, коли це не окремий “танець з бубном”, а нормальна можливість системи.

== Конструктор BI-звітів ==
Потужний інструмент для побудови звітів у [[K2 ERP]] — це конструктор BI-звітів.

У [[K2 ERP]] вдалося реалізувати у вебі те, що раніше традиційно існувало в системах класу “Корпорація”: можливість будувати велике дерево звітів, створювати різні види аналітики, працювати з деталізацією, таблицями, дашбордами і кубами.

BI-звіти потрібні не для краси. Вони потрібні для управління.

ERP без аналітики перетворюється на електронний архів документів. Документи введені, залишки пораховані, проводки є. Але керівнику потрібно інше: він хоче розуміти, що відбувається з бізнесом.

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

У [[K2 ERP]] передбачені різні види звітів: друковані звіти, дашборди, табличні звіти, PivotGrid або куби.

Друковані звіти можна роздрукувати, експортувати або відправити електронною поштою. Дашборди показують ключові показники і дозволяють провалюватися в деталі. Табличні звіти використовують стандартний функціонал таблиць: сортування, фільтрацію, копіювання через буфер, експорт, графіки. Куби дають можливість дивитися на інформацію з різних ракурсів.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''BI у K2 ERP.''' Конструктор BI-звітів перетворює дані на управлінські рішення, а не просто на красиві таблиці.
</div>

== Передача звітів та налаштувань між хмарами ==
Одна з важливих задач для партнерів і інтеграторів — не робити одну й ту саму роботу багато разів.

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

Саме тому важлива передача звітів і налаштувань між хмарами.

Це дає партнерам практичну перевагу: їхня робота накопичується. Вони створюють не просто разові налаштування, а бібліотеку рішень, яку можна переносити, адаптувати і продавати.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Повторне використання.''' Те, що одного разу добре зроблено, повинно жити далі й приносити користь іншим проєктам.
</div>Для клієнта це означає швидше впровадження. Для партнера — повторне використання досвіду. Для екосистеми [[K2 ERP]] — поступове накопичення якісних рішень.

== Конструктор структури бази даних ==
У багатьох бізнес-системах структура бази даних — це закрита територія програміста. Користувач її не бачить, адміністратор не розуміє, інтегратор боїться чіпати, а будь-яка зміна потребує ручного втручання в SQL.

У [[K2 ERP]] підхід інший.

Конструктор структури бази даних потрібен для того, щоб описувати і розвивати структуру системи керовано. Не хаотично, не випадковими таблицями, не ручними правками “десь у базі”, а через зрозумілі описи, моделі і міграції.

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

Конструктор структури бази даних дозволяє наблизити роботу з даними до архітектурного рівня. Розробник бачить не просто набір таблиць, а модель предметної області. Інтегратор краще розуміє, як пов’язані сутності. У майбутньому такі інструменти можуть давати можливість створювати частину структури через візуальні редактори.<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">
'''Фундамент ERP.''' Правильно описана структура даних — це половина успіху ERP-системи.
</div>

== Редактор ER-моделей ==
ER-модель — це спосіб подивитися на систему не через код, а через зв’язки між сутностями.

Для ERP це особливо важливо, бо тут усе пов’язано з усім: контрагенти, договори, документи, товари, склади, залишки, платежі, рахунки, підрозділи, користувачі, ролі.

Коли система маленька, можна тримати ці зв’язки в голові. Коли ERP росте, це вже неможливо.

Редактор ER-моделей потрібен, щоб бачити архітектуру даних візуально. Це корисно програмістам, бо допомагає швидше розуміти структуру модулів. Це корисно інтеграторам, бо вони краще бачать предметну область. Це корисно для навчання нових спеціалістів і аналізу перед доробками.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''ER-модель.''' Це карта системи. А без карти у великій ERP легко заблукати.
</div>У поєднанні з YML-описами, ORM-моделями і міграціями редактор ER-моделей може стати інструментом не тільки для перегляду, а й для проєктування системи.

== Редактор BP-моделей ==
Якщо ER-моделі описують дані, то BP-моделі описують бізнес-процеси.

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

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

Редактор BP-моделей дозволяє описувати бізнес-процеси зрозуміло і наочно.

Коли процес намальований, його легше обговорювати. Легше знайти зайві кроки. Легше побачити вузькі місця. Легше пояснити клієнту, що саме буде автоматизовано.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''BP-моделі.''' Це спосіб перетворити “у нас так історично склалося” на зрозумілу й керовану схему роботи.
</div>

== Компоненти: канбан, часові діаграми, графічні редактори та інше ==
ERP давно перестала бути набором сірих таблиць. У сучасному бізнесі потрібні різні способи роботи з даними.

Комусь зручно бачити задачі у вигляді канбан-дошки. Комусь потрібна часова діаграма. Комусь потрібен графічний редактор процесу. Комусь — календар. Комусь — дерево структури. Комусь — інтерактивний дашборд.

Саме тому в [[K2 ERP]] важливу роль відіграє розвиток компонентів.

Канбан зручний для задач, заявок, продажів, CRM, сервісу, документообігу. Часові діаграми потрібні для планування робіт, виробництва, графіків обслуговування, завантаження ресурсів. Графічні редактори потрібні для моделей, схем, процесів і структур.

Компонентний підхід дозволяє один раз зробити якісний інструмент і потім використовувати його в різних модулях.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Сила компонентів.''' У платформі важливо не тільки мати готові модулі, а й мати бібліотеку будівельних блоків для створення нових рішень.
</div>

== Переклад на різні мови ==
Багатомовність для ERP — це не косметика. Це необхідність.

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

[[K2 ERP]] має передбачати переклади не як окрему доробку, а як нормальну частину платформи.

Це стосується інтерфейсу, довідників, друкованих форм, звітів, повідомлень, шаблонів документів.

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

== Реплікатор ==
Для розподілених систем дуже важливим є механізм реплікації.

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

Реплікатор потрібен для синхронізації даних між різними вузлами системи.

Це може бути синхронізація між центральною базою і локальним сервером. Між хмарами. Між мобільним додатком і сервером. Між окремими інсталяціями. Між офлайн-режимом і основною системою.

У реальному житті інтернет не завжди ідеальний. Сервери можуть бути рознесені географічно. Частина роботи може виконуватися офлайн. Тому реплікація — це не функція “для галочки”, а важлива основа надійності.<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">
'''Реплікація.''' ERP має працювати там, де працює бізнес, а не тільки там, де є ідеальний інтернет.
</div>

== Використання ШІ для розробки, магія швидкої розробки компонентів ==
Штучний інтелект уже змінив програмування. І було б дивно створювати сучасну ERP-платформу, не враховуючи цього.

[[K2 ERP]] добре підходить для AI-асистованої розробки, бо використовує зрозумілі сучасному світу технології: Python, TypeScript, YML, JSON, SQL, ORM-моделі, компоненти, відкритий код.

ШІ може допомагати створювати нові компоненти, пояснювати існуючий код, генерувати YML-описи, писати SQL-запити, шукати помилки, адаптувати модулі під нові задачі, створювати заготовки форм і таблиць.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''ШІ для розробника.''' Штучний інтелект не замінює архітектора і досвідченого програміста, але різко прискорює рутинну частину роботи.
</div>Якщо раніше програміст годинами писав типову структуру компонента, тепер AI може підготувати заготовку. Якщо потрібно розібратися в незнайомому модулі, AI може допомогти пояснити логіку. Якщо треба швидко створити варіант інтеграції або звіту, AI стає корисним помічником.

Це і є магія швидкої розробки: не в тому, що система сама все зробить, а в тому, що правильна архітектура плюс AI дають розробнику значне прискорення.

== Використання ШІ для автоматизації рутинних дій користувачів ==
Штучний інтелект потрібен не тільки програмістам. У майбутньому він стане звичайним помічником користувача ERP.

Бухгалтер може попросити систему пояснити, чому змінилася дебіторка. Керівник може запитати, які товари зависли на складі. Менеджер може отримати допомогу в підготовці комерційної пропозиції. Сервісний інженер може отримати підказку, які роботи зазвичай виконуються для такого обладнання. Аналітик може просити побудувати звіт людською мовою.

ERP майбутнього — це не система, де користувач нескінченно натискає кнопки. Це система, де рутина поступово переходить до автоматичних помічників.

Звичайно, важливі питання безпеки, доступів, контролю і перевірки результатів. Але напрям очевидний: користувач повинен менше часу витрачати на механіку і більше — на рішення.

== Підключення Power BI, QlikView, Tableau та інших систем для аналізу даних ==
[[K2 ERP]] має власні інструменти аналітики, але в багатьох компаніях уже є своя BI-інфраструктура.

Хтось використовує Power BI. Хтось Tableau. Хтось QlikView або інші аналітичні системи. У великих компаніях BI часто живе окремим світом, де є свої аналітики, моделі даних, дашборди і правила.

ERP не повинна ревнувати дані до зовнішніх BI-систем.

[[K2 ERP]] має бути відкритою до підключення зовнішніх інструментів аналітики. Це дозволяє використовувати дані ERP у загальному аналітичному контурі компанії.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Аналітична відкритість.''' Дані з ERP можуть ставати частиною ширшої BI-системи компанії, а не залишатися замкненими всередині одного інтерфейсу.
</div>

== Підключення ШІ для аналізу даних ==
Окремий напрям — використання штучного інтелекту для аналізу даних.

Класична BI-система показує графік. ШІ може допомогти пояснити, що за ним стоїть.

Не просто “продажі впали на 12%”, а “продажі впали через зменшення повторних замовлень у трьох ключових клієнтів і зростання залишків по двох товарних групах”.

Не просто “дебіторка зросла”, а “основне зростання пов’язане з такими-то контрагентами і такими-то простроченими документами”.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''AI-аналітика.''' Це перехід від перегляду цифр до пояснення причин.
</div>Важливо правильно організувати доступи: ШІ не повинен бачити дані, до яких користувач не має прав. Але якщо цей рівень безпеки зроблений правильно, можливості відкриваються дуже цікаві.

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

== Інтеграція з іншими системами ==
Жодна сучасна ERP не може існувати ізольовано.

У бізнесу є банки, сайти, інтернет-магазини, маркетплейси, телефонія, пошта, служби доставки, CRM, державні сервіси, зовнішні бази, мобільні додатки, обладнання, каси, сканери, системи електронного документообігу.

ERP повинна бути центром цифрової екосистеми, а не островом.

Інтеграція може бути простою: передати замовлення з сайту в ERP. А може бути складною: синхронізувати залишки між складами, передати дані в BI, отримати оплату з банку, оновити статус доставки, створити документ, відправити повідомлення клієнту, завантажити вкладення, оновити довідники.

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

== API для роботи інших систем ==
API — це мова, якою ERP спілкується із зовнішнім світом.

Якщо система має нормальний API, її можна підключати до сайтів, мобільних додатків, зовнішніх сервісів, кабінетів клієнтів, партнерських порталів, аналітичних систем, AI-сервісів.

API робить [[K2 ERP]] не закритою програмою, а платформою.

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

== Логіювання на рівні бази даних ==
У серйозній ERP потрібно знати, що відбувалося з даними.

Хто змінив документ? Коли змінив? Яке поле було до цього? Що стало після зміни? Який процес спрацював? Яка помилка виникла? Чому зникла або змінилася інформація?

Для цього потрібне логіювання.

Логіювання на рівні бази даних дає системі пам’ять. Це важливо для аудиту, безпеки, розслідування помилок, підтримки, контролю змін і аналізу проблем.

У великих системах без логів підтримка перетворюється на ворожіння: “хтось щось зробив, але ніхто не знає що”.

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

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

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

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

Для малого бізнесу це може бути непомітно. Але для великої компанії, де документи створюються тисячами або мільйонами, такі речі стають критичними.<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">
'''Масштабування.''' ERP повинна бути готова не тільки до старту, а й до багаторічного росту.
</div>

== Робота додатків в режимі офлайн та синхронізація даних ==
Бізнес не завжди працює в умовах стабільного інтернету. Є склади, виробництва, торгові представники, сервісні інженери, віддалені об’єкти, експедиції, мобільні команди.

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

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

Це не найпростіша задача технічно. Потрібно думати про конфлікти, черги змін, пріоритети, права доступу, цілісність даних. Але для реального бізнесу це дуже важливо.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Офлайн-режим.''' ERP має працювати там, де працює людина, а не тільки там, де ідеальні умови для сервера.
</div>

== Мобільні додатки Android, iOS ==
Мобільні додатки для ERP — це вже не розкіш, а необхідність.

Керівник хоче бачити показники з телефона. Менеджер хоче працювати із заявками. Складський працівник хоче сканувати товар. Торговий представник хоче оформити замовлення в дорозі. Сервісний інженер хоче закрити заявку на об’єкті.

Мобільний доступ розширює ERP за межі офісу.

Android та iOS-додатки відкривають зовсім інші сценарії використання: складські операції, сервіс, CRM, погодження документів, повідомлення, фотофіксація, геолокація, мобільні дашборди, робота з файлами.

Особливо цікаво це в поєднанні з офлайн-режимом і синхронізацією. Тоді мобільний додаток стає не просто “вікном у веб”, а повноцінним інструментом роботи.

== Десктопні додатки Linux, Windows, macOS ==
Попри розвиток вебу, десктопні додатки теж залишаються важливими.

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

Тому підтримка десктопних додатків для Windows, Linux і macOS відкриває додаткові можливості.

[[K2 ERP]] не повинна бути обмежена тільки браузером.

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

Сильна платформа повинна давати вибір.

== Система оновлення K2 Update ==
[[K2 Update]] — одна з ключових частин архітектури [[K2 ERP]].

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

[[K2 Update]] — це не просто оновлення версій. Це основа екосистеми компонентів.

Через систему оновлень можна доставляти нові модулі, виправлення, компоненти, звіти, налаштування, галузеві рішення. У майбутньому це може працювати як маркетплейс, де партнери публікують свої рішення і розповсюджують їх по мережі [[K2 ERP]].<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''K2 Update.''' Це механізм, який дозволяє перетворювати досвід розробника або інтегратора на продукт.
</div>Інтегратор перестає бути людиною, яка просто “щось налаштувала одному клієнту”. Він може створити компонент, підтримувати його, оновлювати і продавати багатьом клієнтам.

== Python та TypeScript — популярні мови програмування у світі ==
Одна з принципових переваг [[K2 ERP]] — використання сучасних популярних мов програмування, зокрема Python та TypeScript.

Це важливо з дуже простої причини: навколо популярних мов є велика екосистема. Є бібліотеки, документація, розробники, AI-підтримка, інструменти, приклади, спільноти.

Закрита внутрішня мова ERP може здаватися зручною всередині однієї системи, але вона ізолює розробника від світу. Python і TypeScript, навпаки, підключають [[K2 ERP]] до світової екосистеми розробки.

Python добре підходить для бізнес-логіки, інтеграцій, обробки даних, автоматизації, API, AI-сценаріїв.

TypeScript добре підходить для сучасного веб-інтерфейсу, складних frontend-компонентів, клієнтської логіки.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Сучасні мови.''' [[K2 ERP]] не змушує розробника вивчати мову однієї закритої системи. Вона дозволяє працювати з технологіями, які потрібні на ринку.
</div>Це важливо і для партнерів: простіше знаходити людей, простіше навчати команду, простіше використовувати AI, простіше інтегрувати зовнішні бібліотеки й сервіси.

== PostgreSQL як основна база даних, можливість використовувати MySQL, SQLite та інші завдяки ORM-моделям і міграціям ==
Основною базою даних для [[K2 ERP]] є PostgreSQL.

Це потужна, надійна і сучасна СУБД, яка добре підходить для складних бізнес-систем. PostgreSQL дає серйозну основу для транзакцій, аналітики, великих обсягів даних, індексів, секціонування, складних запитів і надійної роботи.

При цьому архітектура через ORM-моделі та міграції дозволяє дивитися ширше. У певних сценаріях можна використовувати MySQL, SQLite та інші бази даних, якщо це виправдано конкретною задачею.

ORM-моделі і міграції потрібні для того, щоб розвиток структури бази був керованим.

Не ручні зміни “десь у базі”, не хаос SQL-скриптів, які ніхто не пам’ятає, а нормальна модель розвитку: описали структуру, створили міграцію, застосували, оновили.

Для ERP, яка повинна жити роками, це дуже важливо.

== Велика кількість компонентів та модулів, що росте з часом і все більше переноситься в K2 ERP ==
[[K2 ERP]] — це не застигла система. Вона постійно росте.

З часом у неї переноситься і розвивається дедалі більше компонентів та модулів: CRM, CMS, інтернет-магазин, ТОІР, WMS, документообіг, VDoc, система навчання, різні інтеграції та інші рішення.

Це важливо, бо ERP-платформа має накопичувати силу.

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

CRM дозволяє працювати з клієнтами і продажами.

CMS та інтернет-магазин — будувати зовнішні цифрові канали.

ТОІР — управляти технічним обслуговуванням і ремонтами.

WMS — працювати зі складською логістикою.

Документообіг і VDoc — керувати погодженнями, файлами, маршрутами, внутрішніми документами.

Система навчання — готувати користувачів і співробітників.

Інтеграції — з’єднувати ERP з навколишнім цифровим світом.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Ріст платформи.''' Чим більше якісних компонентів накопичує [[K2 ERP]], тим швидше можна створювати нові бізнес-рішення.
</div>

== Значення для програмістів ==
Для програміста [[K2 ERP]] цікава тим, що це не закрита клітка, а сучасна платформа.

Тут є код, який можна читати. Є популярні мови. Є сучасні IDE. Є декларативні описи. Є компоненти, які знімають рутину. Є API. Є база даних промислового рівня. Є можливість використовувати AI. Є механізми розширення, хуки, перевизначення, власні модулі.

Програміст у [[K2 ERP]] не просто “дописує облік”. Він створює бізнес-додатки на платформі.

У старих системах розробник часто стає спеціалістом вузького закритого світу. У [[K2 ERP]] він залишається частиною сучасної розробки: Python, TypeScript, Git, AI, API, PostgreSQL, веб-компоненти.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Для програміста.''' [[K2 ERP]] дає швидкість RAD, але без пастки старих закритих RAD-систем.
</div>

== Значення для інтеграторів ==
Для інтегратора [[K2 ERP]] цікава тим, що дозволяє робити не разові впровадження, а довгострокові рішення.

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

І найголовніше — багато напрацювань можна переносити між проєктами.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Для інтегратора.''' Інтегратор у [[K2 ERP]] накопичує не тільки досвід, а й готові рішення.
</div>Це зовсім інша економіка роботи. Не кожен проєкт з нуля, а поступове накопичення рішень, які можна адаптувати під різних клієнтів.

== Значення для партнерів ==
Для партнера [[K2 ERP]] відкриває можливість будувати власний бізнес.

Можна підняти свою хмару. Підключати клієнтів. Створювати галузеві рішення. Писати модулі. Публікувати компоненти через [[K2 Update]]. Продавати підтримку. Робити інтеграції. Навчати користувачів. Створювати власні продукти на базі [[K2 ERP]].

Партнер заробляє не тільки на годинах. Він може заробляти на інтелектуальній власності, яку створив.<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">
'''Для партнера.''' [[K2 ERP]] дозволяє бути не просто впроваджувачем чужої системи, а співтворцем ERP-екосистеми.
</div>

== Коротко ==
{| class="wikitable" style="width:100%;"
!Питання
!Відповідь
|-
|Що таке [[K2 ERP]]?
|Українська ERP-платформа для обліку, документів, звітів, бізнес-процесів, інтеграцій і розробки нових бізнес-додатків.
|-
|Чи можна розгорнути систему на власному сервері?
|Так. [[K2 ERP]] може працювати у хмарі, власній хмарі, на серверах партнерів або на серверах клієнта.
|-
|Чи є доступ до похідного коду?
|При розгортанні на власних серверах клієнт отримує похідні коди системи та компонентів, які використовуються.
|-
|Чи можна створювати власні модулі?
|Так. У [[K2 ERP]] можна створювати власні компоненти, модулі, звіти, інтеграції та галузеві рішення.
|-
|Що таке [[K2 Update]]?
|Система оновлення і розповсюдження компонентів, яка може стати основою маркетплейсу модулів [[K2 ERP]].
|-
|Чи можна прикладати файли до документів і довідників?
|Так. Файли можна прив’язувати до сутностей системи: документів, довідників, товарів, контрагентів, заявок, обладнання тощо.
|-
|Що таке характеристики сутностей?
|Механізм, який дозволяє доповнювати документи та довідники додатковими властивостями без програмування.
|-
|Які мови програмування використовуються?
|Python та TypeScript, а також декларативні формати YML, JSON, XML.
|-
|Яка основна база даних?
|PostgreSQL, з можливістю використання інших СУБД через ORM-моделі та міграції.
|-
|Чи можна використовувати AI?
|Так. ШІ може допомагати у розробці компонентів, аналізі коду, генерації описів, створенні звітів і автоматизації рутинних дій користувачів.
|-
|Для кого ця платформа?
|Для бізнесу, програмістів, інтеграторів, партнерів, адміністраторів, галузевих розробників і команд автоматизації.
|}

== Висновок ==
[[K2 ERP]] — це не просто ERP-система для ведення обліку.

Це сучасна українська ERP-платформа, яка поєднує гібридну архітектуру, відкритий код для власних серверів, безкоштовну і власну хмару, систему оновлень, компоненти, AI, API, BI, мобільність, офлайн-режим, сучасні мови програмування і можливість партнерського розвитку.

Її сила не тільки в готових модулях. Її сила в тому, що її можна розвивати.

Її можна встановити у себе. Її можна дописувати. Її можна інтегрувати. Її можна масштабувати. До неї можна додавати файли. Сутності можна доповнювати характеристиками без програмування. Звіти можна налаштовувати. Компоненти можна створювати. Модулі можна продавати. Хмару можна будувати власну.<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''K2 ERP — це не закрита коробка. Це платформа.'''
</div>Саме тому вона цікава програмістам, інтеграторам і партнерам.

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

'''[[K2 ERP]] — це спроба створити саме таку платформу. Українську, сучасну, відкриту до розвитку і готову до того, щоб навколо неї росла власна екосистема.'''

== Див. також ==

* [[K2]]
* [[K2 ERP]]
* [[K2 Update]]
* [[ERP]]
* [[CRM]]
* [[BI]]
* [[API]]
* [[PostgreSQL]]
* [[Python]]
* [[TypeScript]]
* [[YML]]
* [[JSON]]
* [[XML]]
* [[1С]]
* [[BAS]]
* [[Українське програмне забезпечення]]
* [[Автоматизація бізнесу]]
* [[Цифрова незалежність]]
* [[Деколонізація обліку]]

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

* [https://erp.kyiv.ua Сайт K2 ERP]
* [https://wiki.erp.kyiv.ua Wiki K2 ERP]
* [https://cloud.corp2.eu Хмара K2 ERP]
* [https://t.me/+uIdWI1W6vndkMTAy Telegram-канал K2 ERP]
* [https://t.me/+6jFwAZM6TQliNTdi Група обговорення функціоналу та пропозицій]
* [https://www.linkedin.com/company/k2erp/ LinkedIn K2]