Перейти до вмісту

Встановлення K2 ERP: відмінності між версіями

Матеріал з K2 ERP Wiki
Створена сторінка: {{DISPLAYTITLE:Встановлення K2 ERP}} {{SEO |title=Встановлення K2 ERP — розгортання української ERP, K2 Cloud ERP, сервер, хмара, міграція з 1С/BAS |description=Встановлення K2 ERP — це процес підготовки, розгортання, налаштування та запуску української ERP-системи K2 ERP або K2 Cloud ERP. Стаття...
 
Немає опису редагування
 
Рядок 1: Рядок 1:
{{DISPLAYTITLE:Встановлення K2 ERP}}
{{DISPLAYTITLE:Розгортання K2 Cloud ERP Python для розробників}}


{{SEO
{{SEO
|title=Встановлення K2 ERP — розгортання української ERP, K2 Cloud ERP, сервер, хмара, міграція з 1С/BAS
|title=Розгортання K2 Cloud ERP Python для розробників локальний запуск, PyCharm, Git, компоненти, оновлення
|description=Встановлення K2 ERP — це процес підготовки, розгортання, налаштування та запуску української ERP-системи K2 ERP або K2 Cloud ERP. Стаття пояснює сценарії встановлення: хмара, окрема хмара, локальний сервер, гібридна модель, партнерська хмара, тестове середовище, права доступу, безпека, резервні копії, документообіг, ЕДО, КЕП, інтеграції, Реплікатор K2 ERP і міграція з 1С/BAS.
|description=Інструкція з локального розгортання робочого проєкту K2 Cloud ERP Python для розробників: копіювання проєкту по FTP, перший запуск, налаштування віртуального середовища, запуск K2 Cloud ERP, встановлення PyCharm, налаштування Python Interpreter, встановлення Git, підключення віддалених репозиторіїв компонент, коміт змін, завантаження компонент на сервер оновлення та тестування на deb1-deb3.
|keywords=встановлення K2 ERP, розгортання K2 ERP, інсталяція K2 ERP, K2 ERP установка, K2 Cloud ERP, встановлення K2 Cloud ERP, K2 ERP сервер, K2 ERP хмара, K2 ERP локально, K2 ERP гібридне розгортання, Партнерська хмара K2, українська ERP, українське програмне забезпечення, ERP встановлення, ERP розгортання, міграція з 1С, міграція з BAS, Реплікатор K2 ERP, перехід з 1С та BAS на K2 ERP, K2 ERP Документообіг, K2 VDoc, VDoc, Модуль Вчасно, Вчасно.ЕДО, ЕДО, КЕП, безпека ERP, резервне копіювання ERP, права доступу K2 ERP, тестове середовище ERP, продуктивне середовище ERP
|keywords=K2 Cloud ERP Python, розгортання K2 Cloud ERP, встановлення K2 ERP Linux, K2 ERP Python, PyCharm K2 ERP, Git K2 ERP, auto_update K2 ERP, k2update_push.py, компоненти K2 ERP, локальний запуск K2 Cloud ERP, first_run.sh, run.sh, k2cfg.py, Реплікатор K2 ERP, K2 ERP для розробників
|alternativeTo=локальні сервери 1С; BAS; застарілі ERP; Excel-облік; ручне адміністрування; неконтрольовані бази; старі бухгалтерські системи; розрізнені CRM; розрізнені складські системи
}}
}}


{{SoftwareAlternative
'''Розгортання K2 Cloud ERP Python для розробників''' — це інструкція з локального запуску робочого проєкту [[K2 Cloud ERP]], підключення середовища розробника, налаштування [[PyCharm]], роботи з [[Git]], підключення репозиторіїв компонент і завантаження нових версій компонент у систему оновлення.
|name=K2 ERP
 
|type=українська ERP-платформа, яку можна встановлювати або розгортати в хмарній, локальній, гібридній чи партнерській моделі; підтримує фінансовий облік, управлінський облік, бухгалтерію, CRM, продажі, закупівлі, склад, виробництво, документообіг, ЕДО, КЕП, архіви, інтеграції, аналітику, міграцію з /BAS/UA-Бюджет, резервні копії та контроль доступів
Ця інструкція призначена для розробників, які отримують існуючий проєкт K2 Cloud ERP, запускають його локально, підключають віртуальне середовище, працюють із компонентами та передають зміни через Git і систему оновлення.
|alternative_to=1С; BAS; UA-Бюджет; Парус-Підприємство; старі ERP; старі бухгалтерські системи; локальні сервери без підтримки; Excel-облік; ручні файли; розрізнені CRM; старі складські системи; неконтрольовані документообіги
 
|category=встановлення K2 ERP, розгортання K2 ERP, K2 Cloud ERP, K2 ERP, українська ERP, хмарна ERP, локальна ERP, гібридна ERP, Партнерська хмара K2, міграція з 1С, міграція з BAS, Реплікатор K2 ERP, документообіг, ЕДО, КЕП, безпека ERP
__TOC__
}}
 
== 1. Копіювання існуючого проєкту по FTP і перший запуск ==
 
Спочатку потрібно скопіювати з віддаленого сервера існуючий проєкт по FTP.
 
Після копіювання потрібно перейти в каталог:
 
<pre>
/K2CloudERP
</pre>
 
У цьому каталозі запускається файл першого запуску '''first_run''' для налаштування параметрів віртуального середовища в поточному локальному розташуванні.
 
Для Linux використовується команда:
 
<pre>
bash first_run.sh
</pre>
 
Для Windows використовується команда:
 
<pre>
./first_run.bat
</pre>
 
Після цього потрібно перейти у файл налаштувань:
 
<pre>
/K2CloudERP/cfg/k2/k2/k2cfg.py
</pre>
 
У цьому файлі потрібно змінити параметр:
 
<pre>
domain_protocol
</pre>
 
Значення потрібно змінити з:
 
<pre>
https
</pre>
 
на:
 
<pre>
http
</pre>
 
Після зміни налаштувань можна запускати додаток.
 
Для Linux:
 
<pre>
bash run.sh
</pre>
 
Для Windows:
 
<pre>
./run.bat
</pre>
 
== 2. Встановлення середовища розробки PyCharm та відкриття проєкту ==
 
Для розробки використовується середовище [[PyCharm]].
 
=== Встановлення PyCharm у Linux через snap ===
 
Для Linux можна встановити PyCharm через snap.
 
Спочатку потрібно виконати команди:
 
<pre>
sudo rm /etc/apt/preferences.d/nosnap.pref
sudo apt update
sudo apt install snapd
sudo snap install pycharm-community --classic
</pre>
 
Після встановлення PyCharm запускається командою:
 
<pre>
pycharm-community
</pre>
 
=== Встановлення PyCharm у Linux через архів із сайту JetBrains ===
 
Також PyCharm можна встановити через завантаження архіву з офіційного сайту JetBrains:
 
<pre>
https://www.jetbrains.com/pycharm/download/?section=linux
</pre>
 
Після завантаження архів потрібно розпакувати, перейти в папку:
 
<pre>
bin
</pre>
 
і запустити файл:
 
<pre>
./pycharm.sh
</pre>
 
Якщо під час запуску виникає помилка, потрібно встановити JRE/JDK командами:
 
<pre>
sudo apt update
sudo apt install default-jdk
</pre>
 
=== Встановлення PyCharm у Windows ===
 
Для Windows потрібно завантажити архів із сайту JetBrains:
 
<pre>
https://www.jetbrains.com/pycharm/download/?section=windows
</pre>
 
Після цього потрібно розпакувати архів, запустити файл встановлення та встановити PyCharm згідно з інструкціями інсталятора.
 
=== Відкриття проєкту в PyCharm ===
 
Після встановлення потрібно відкрити середовище розробки PyCharm.
 
Далі потрібно відкрити поточний завантажений проєкт K2 Cloud ERP і налаштувати змінне середовище для цього проєкту.
 
У правому нижньому куті PyCharm потрібно вибрати:
 
<pre>
Python Interpreter
</pre>


'''Встановлення K2 ERP''' — це процес підготовки, розгортання, налаштування та запуску '''[[K2 ERP]]''' або '''[[K2 Cloud ERP]]''' у роботу. Залежно від потреб компанії система може використовуватися в хмарі, на окремому сервері, у локальній інфраструктурі, у гібридній моделі або через '''[[Партнерська хмара K2|Партнерську хмару K2]]'''.
Потім:


'''[[K2 ERP]]''' позиціонується як українська система управління підприємством, що поєднує фінанси, бухгалтерію, продажі, склад, закупівлі, документообіг, CRM, аналітику та галузеві модулі в єдиному цифровому середовищі. Офіційні матеріали K2 також описують K2 ERP як гібридну ERP, що може поєднувати переваги хмари та локального розміщення.
<pre>
Add new Interpreter
</pre>


Встановлення K2 ERP не варто зводити лише до технічної інсталяції. Для бізнесу це ширший процес: вибір моделі розгортання, підготовка користувачів, налаштування ролей, перенесення даних, підключення документообігу, ЕДО, КЕП, інтеграцій, резервного копіювання, тестового середовища й запуску в продуктивну роботу.
У полі '''Location''' потрібно додати шлях до поточної папки:


'''[[K2 ERP]]''', '''[[K2 Cloud ERP]]''', '''[[Реплікатор K2 ERP]]''', '''[[K2 ERP Документообіг]]''', '''[[K2 VDoc]]''', '''[[Модуль Вчасно]]''', '''[[Вчасно.ЕДО]]''' і '''[[VDoc]]''' можуть бути основою впровадження: ERP, CRM, фінанси, склад, виробництво, документообіг, ЕДО, КЕП, архіви, інтеграції, аналітика, міграція зі старих систем, резервні копії та контроль доступів.
<pre>
venv
</pre>


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


<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
Приклад:
'''Безпековий контекст.''' Перед встановленням ERP потрібно визначити модель доступів, адміністраторів, резервні копії, тестове середовище, правила оновлень, інтеграції, ЕДО, КЕП, архіви, персональні дані, фінансові документи, технічних користувачів і порядок закриття старих систем після міграції.
</div>


__TOC__
<pre>
../K2CloudERP/venv/bin.python3.12.exe
</pre>


== Що таке встановлення K2 ERP ==
Після налаштування інтерпретатора можна запускати проєкт у debug-режимі через кнопку у правому верхньому куті PyCharm.


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


У простому випадку встановлення може означати доступ до [[K2 Cloud ERP]] у хмарі. У складнішому випадку це може бути окрема хмара, локальний сервер, гібридна архітектура, тестове середовище, міграція зі старих систем, інтеграції з банками, ЕДО, складами, інтернет-магазинами, CRM, ПРРО або іншими сервісами.
Для Linux:


Правильне встановлення K2 ERP має завершуватися не просто відкритою системою, а робочим бізнес-контуром: користувачі заходять у систему, ролі налаштовані, дані перенесені або підготовлені, документи створюються, інтеграції працюють, резервні копії організовані, а стара система поступово виводиться з використання.
<pre>
bash run.sh
</pre>


== Основні сценарії встановлення ==
Для Windows:


K2 ERP може встановлюватися або розгортатися в кількох сценаріях.
<pre>
./run.bat
</pre>


Найпростіший шлях — '''[[K2 Cloud ERP]]''', коли компанія отримує ERP у хмарі без власного серверного господарства. Це зручно для швидкого старту, тестування, малого й середнього бізнесу, віддалених команд і компаній, які не хочуть утримувати власну інфраструктуру.
=== Ручна активація віртуального середовища ===


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


Третій сценарій — локальне встановлення або приватна інфраструктура. Такий підхід може бути потрібний компаніям із суворими внутрішніми ІТ-політиками, власними дата-центрами або специфічними вимогами до зберігання даних.
<pre>
source venv/bin/activate
</pre>


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


== Хмарне встановлення K2 ERP ==
<pre>
.\venv\Scripts\activate
</pre>


Хмарне встановлення K2 ERP підходить компаніям, які хочуть швидко почати роботу без власного сервера.
== 3. Встановлення та налаштування Git ==


У цьому сценарії основні технічні задачі — розміщення, доступність, базова інфраструктура, резервні копії та адміністрування — можуть бути централізовані. Клієнт зосереджується на бізнес-процесах: фінансах, продажах, складі, документах, CRM, виробництві, аналітиці й користувачах.
Для роботи з компонентами потрібно встановити й налаштувати [[Git]].


Хмарний старт особливо корисний під час переходу з 1С/BAS: можна створити тестове середовище, перенести частину даних, перевірити процеси, навчити користувачів і тільки після цього запускати продуктивну роботу.
=== Встановлення Git у Linux ===


== Окрема хмара K2 ERP ==
Для Linux використовується команда:


Окрема хмара K2 ERP — це сценарій для компаній, яким потрібен вищий рівень контролю.
<pre>
sudo apt update
sudo apt install git
</pre>


У такій моделі компанія може отримати ізольовану інфраструктуру, окремий сервер, окремі правила доступів і більший контроль над даними. Це може бути важливо для підприємств із чутливими фінансовими, виробничими, кадровими або комерційними даними.
=== Встановлення Git у Windows ===


Окрема хмара може бути компромісом між швидкістю хмарного розгортання та контролем приватної інфраструктури.
Для Windows потрібно завантажити Git за посиланням:


== Локальне встановлення K2 ERP ==
<pre>
https://git-scm.com/downloads/win
</pre>


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


Цей сценарій може бути доречним, якщо компанія має власний ІТ-відділ, сервери, політики безпеки, вимоги до локального зберігання даних або складні інтеграції з внутрішніми системами.
=== Налаштування користувача Git ===


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


== Гібридне розгортання K2 ERP ==
<pre>
git config --global user.name "Ваше Ім'я"
</pre>


Гібридне розгортання поєднує хмарну й локальну модель.
Також потрібно налаштувати email:


Наприклад, основна ERP може працювати в хмарі, а окремі інтеграції, архіви, локальні сервіси або виробничі системи можуть залишатися на стороні клієнта. Або навпаки: критичні дані зберігаються локально, а частина користувацьких сервісів працює через хмарний доступ.
<pre>
git config --global user.email "ваша_електронна_пошта@example.com"
</pre>


Гібридна модель корисна тоді, коли компанія не може або не хоче переносити все одразу. Вона дозволяє рухатися поступово: спочатку CRM і документи, потім склад, фінанси, виробництво, інтеграції та архіви.
=== Авторизація в Git ===


== Партнерська хмара K2 ==
Можливі два варіанти авторизації:


'''[[Партнерська хмара K2]]''' — це модель, у якій партнер, інтегратор або сервісна компанія надає клієнтам хмарне середовище на базі K2 ERP.
авторизація за допомогою логіна й пароля;


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


Партнерська хмара включає не лише технічне розміщення. Вона може охоплювати впровадження, підтримку, міграцію, навчання, документообіг, ЕДО, КЕП, інтеграції, галузеві шаблони й супровід клієнтів.
=== Налаштування SSH-ключа ===


== Мобільне встановлення K2 Cloud ERP ==
Для створення SSH-ключа потрібно виконати команду:


Окремий сценарій — встановлення або підключення K2 Cloud ERP на мобільних пристроях.
<pre>
ssh-keygen -t rsa -b 4096 -C "ваша_електронна_пошта@example.com"
</pre>


Офіційні матеріали K2 зазначають, що додатки K2 Cloud ERP доступні через App Store та Google Play, а встановлення для користувача є звичним і швидким. Це важливо для керівників, менеджерів, складських працівників, польових команд, сервісних спеціалістів і працівників, яким потрібен доступ до ERP не лише з комп’ютера.
Після цього потрібно запустити ssh-agent:


Мобільний доступ не замінює повноцінне впровадження ERP, але робить систему ближчою до щоденної роботи.
<pre>
eval "$(ssh-agent -s)"
</pre>


== Підготовка до встановлення ==
Далі потрібно додати ключ:


Перед встановленням K2 ERP потрібно підготувати бізнес і технічну частину.
<pre>
ssh-add ~/.ssh/id_rsa
</pre>


З боку бізнесу потрібно визначити, які процеси запускаються першими: CRM, продажі, склад, фінанси, документообіг, виробництво, бухгалтерія, ЕДО, КЕП, аналітика або міграція з 1С/BAS.
Щоб переглянути публічний ключ, використовується команда:


З технічного боку потрібно визначити модель розгортання, користувачів, адміністраторів, ролі, резервні копії, інтеграції, домени, доступи, тестове середовище, вимоги до безпеки й порядок запуску.
<pre>
cat ~/.ssh/id_rsa.pub
</pre>


Найгірший сценарій — спочатку встановити систему, а потім з’ясовувати, хто має доступ, які дані переносити, які процеси запускати і хто відповідає за підтримку.
Отриманий ключ потрібно скопіювати й вставити у віддалений репозиторій.


== Обстеження перед встановленням ==
== 4. Підключення віддаленого репозиторію Git для компоненти або списку компонент ==


Перед встановленням бажано провести коротке обстеження.
Підключення репозиторію можна виконувати для списку компонент або для однієї компоненти вручну.


Потрібно зрозуміти, які системи вже використовуються: 1С, BAS, Excel, CRM, складські системи, сайти, інтернет-магазини, документообіг, Вчасно.ЕДО, банки, ПРРО, виробничі системи, Power BI або інші інструменти.
=== Підключення списку компонент через auto_update ===


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


== Вибір моделі розгортання ==
<pre>
auto_update
</pre>


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


Для швидкого старту часто підходить K2 Cloud ERP. Для підвищеного контролю — окрема хмара або виділений сервер. Для компаній із власною інфраструктурою — локальне або гібридне розгортання. Для партнерів — Партнерська хмара K2.
<pre>
app.py
</pre>


Важливо не обирати модель лише за звичкою. Якщо компанія раніше тримала 1С на локальному сервері, це не означає, що нову ERP обов’язково потрібно встановлювати так само.
Посилання на каталог:


== Тестове середовище ==
<pre>
https://git.corp2.eu/k2erp/python/k2/base/client/auto_update
</pre>


Тестове середовище — важлива частина встановлення K2 ERP.
Після цього потрібно відкрити проєкт у консолі й перейти в каталог:


У ньому можна перевірити структуру довідників, ролі, права, документи, звіти, інтеграції, ЕДО, КЕП, перенесені дані й типові сценарії користувачів.
<pre>
cd auto_update
</pre>


Тестове середовище особливо важливе під час міграції з 1С/BAS. Воно дозволяє зробити пробне перенесення, побачити помилки, очистити довідники, звірити залишки й навчити користувачів без ризику для реальної роботи.
Далі потрібно відкрити файл:


== Продуктивне середовище ==
<pre>
settings.py
</pre>


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


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


Не варто запускати продуктивне середовище як експеримент. Коли ERP починає працювати в реальному бізнесі, помилки впливають на продажі, склад, документи, фінанси, виробництво й управління.
<pre>
settings_example.py
</pre>


== Користувачі та ролі ==
Після налаштування потрібно виконати команду для клонування актуальних версій компонент і перейменування каталогів поточних версій компонент:


Після встановлення K2 ERP потрібно налаштувати користувачів і ролі.
<pre>
python git_cmd.py clone
</pre>


Ролі мають відповідати реальній відповідальності працівників: менеджер продажів, бухгалтер, керівник, склад, закупівлі, виробництво, HR, адміністратор, погоджувач документів, користувач ЕДО, технічний користувач інтеграції.
=== Підключення однієї компоненти вручну ===


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


== Права доступу ==
Наприклад, для компоненти '''k2site''':


Права доступу K2 ERP потрібно налаштовувати до запуску, а не після першого інциденту.
<pre>
cd components/k2site
</pre>


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


Окремо потрібно обмежити права технічних користувачів. Інтеграції не повинні працювати через особисті облікові записи працівників або адміністраторів.
<pre>
git init
</pre>


== Адміністратори системи ==
Створити локальну гілку main і перемкнутися на неї:


Адміністратори K2 ERP мають бути визначені заздалегідь.
<pre>
git checkout -b main
</pre>


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


Якщо адміністратор один і всі знання зосереджені тільки в нього, компанія створює новий ризик. Краще мати описані правила, документацію, резервного відповідального й зрозумілий порядок підтримки.
<pre>
git checkout master
</pre>


== Резервне копіювання ==
Далі потрібно додати віддалений репозиторій:


Резервне копіювання має бути частиною встановлення K2 ERP з першого дня.
<pre>
git remote add origin http://git.corp2.eu/k2erp/python/k2/base/site/k2site.git
</pre>


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


Резервна копія ERP містить ті самі критичні дані, що й робоча система: фінанси, контрагентів, документи, зарплату, кадри, склад, аналітику й архіви. Тому доступ до копій має бути контрольованим.
<pre>
git remote -v
</pre>


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


Після встановлення ERP потрібно мати не лише резервні копії, а й план відновлення.
<pre>
git fetch origin
</pre>


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


ERP впливає на багато процесів одночасно. Тому план відновлення має бути не формальним, а практично перевіреним.
<pre>
git pull origin main
</pre>


== Безпека встановлення ==
Для перевірки змін локально скопійованої копії проєкту порівняно з віддаленим репозиторієм використовується команда:


Безпека встановлення K2 ERP охоплює інфраструктуру, користувачів, ролі, резервні копії, інтеграції, ЕДО, КЕП, журнали дій, адміністраторів і правила підтримки.
<pre>
git status
</pre>


Перед запуском потрібно прибрати зайві доступи, визначити технічних користувачів, не використовувати спільні паролі, описати інтеграції, розділити тестове й продуктивне середовище, обмежити доступ до персональних і фінансових даних.
== 5. Коміт змін на віддалений репозиторій Git ==


ERP — це не сайт-візитка. Це ядро управління компанією, тому безпека має бути частиною встановлення, а не окремою задачею «на потім».
Коміт змін можна виконувати автоматично через скрипт auto_update або вручну.


== Встановлення модулів K2 ERP ==
=== Автоматичний коміт через auto_update ===


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


Це можуть бути CRM, продажі, закупівлі, склад, фінанси, управлінський облік, виробництво, документообіг, ЕДО, КЕП, аналітика, інтернет-магазин, інтеграції або міграційні модулі.
<pre>
cd auto_update
</pre>


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


== K2 Cloud Ядро ==
<pre>
python git_cmd.py clone
</pre>


'''[[K2 Cloud Ядро]]''' може розглядатися як базова частина платформи K2 Cloud ERP.
Перевірити статус:


Офіційні матеріали K2 описують K2 Cloud Ядро як основу для запуску та підтримки інших модулів K2 ERP. Воно дозволяє централізовано керувати системними процесами, логікою документів, довідниками, правами доступу та інтеграційною взаємодією між компонентами платформи.
<pre>
python git_cmd.py status
</pre>


Це важливо для встановлення, тому що ERP має бути не набором розрізнених модулів, а єдиною платформою з керованою логікою.
Виконати коміт змін:


== Документообіг після встановлення ==
<pre>
python git_cmd.py commit
</pre>


Після встановлення K2 ERP варто одразу продумати документообіг.
Отримати зміни з віддаленого сервера:


Документи мають мати маршрути погодження, статуси, права доступу, архіви, зв’язок із контрагентами, договорами, рахунками, оплатами, складськими операціями або виробничими процесами.
<pre>
python git_cmd.py pull
</pre>


'''[[K2 ERP Документообіг]]''', '''[[K2 VDoc]]''' і '''[[VDoc]]''' можуть допомогти побудувати документний контур у межах ERP, а не окремо від неї.
Запушити зміни на віддалений репозиторій:


== ЕДО і КЕП після встановлення ==
<pre>
python git_cmd.py push
</pre>


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


'''[[Модуль Вчасно]]''' і '''[[Вчасно.ЕДО]]''' можуть використовуватися для інтеграції електронного документообігу з K2 ERP.
Після внесення змін у коді потрібно перевірити їх командою:


Це дозволяє підписувати документи, передавати їх контрагентам, бачити статуси, зберігати архів і пов’язувати електронні документи з ERP-операціями.
<pre>
git status
</pre>


== Інтеграції після встановлення ==
Далі потрібно додати зміни:


ERP рідко працює повністю ізольовано.
<pre>
git add .
</pre>


Після встановлення K2 ERP можуть знадобитися інтеграції з банками, сайтами, інтернет-магазинами, CRM, складами, службами доставки, ЕДО, ПРРО, BI-системами, телефонією, маркетплейсами, старими базами або зовнішніми API.
Потім виконати коміт:


Кожну інтеграцію потрібно описати: які дані передаються, хто власник, який технічний користувач використовується, які права він має, що відбувається при помилці й як інтеграцію вимкнути.
<pre>
git commit -m "Назва комміту"
</pre>


== Міграція з 1С/BAS під час встановлення ==
Після цього потрібно запушити зміни на віддалений репозиторій:


Якщо K2 ERP встановлюється замість 1С або BAS, встановлення потрібно поєднати з міграційним проєктом.
<pre>
git push
</pre>


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


'''[[Реплікатор K2 ERP]]''' може використовуватися для контрольованого перенесення даних у K2 ERP: витягування, очищення, зіставлення, перенесення, перевірка й звірка.
<pre>
git pull
</pre>


== Початкове налаштування довідників ==
== 6. Налаштування завантаження компонент на сервер оновлення ==


Після встановлення потрібно налаштувати довідники.
Для налаштування завантаження компонент на сервер оновлення потрібно відкрити папку:


До базових довідників можуть належати контрагенти, номенклатура, склади, підрозділи, користувачі, ролі, договори, статті витрат, валюти, одиниці виміру, категорії документів, маршрути погодження й інші сутності.
<pre>
builder/config
</pre>


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


== Навчання користувачів ==
<pre>
component-list.txt
</pre>


Навчання користувачів — частина встановлення K2 ERP.
потрібно додати список компонент, які будуть завантажуватися на сервер оновлення.


Навіть найкраще налаштована ERP не працюватиме, якщо користувачі не розуміють, що робити, де створювати документи, як погоджувати, як шукати інформацію, як працювати зі складом, фінансами, CRM, ЕДО або звітами.
Кожна компонента додається з нового рядка.


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


== Пілотний запуск ==
<pre>
components/k2update
components/k2adm
components/k2site
</pre>


Пілотний запуск дозволяє перевірити систему на обмеженій ділянці.
У папці:


Наприклад, можна запустити один склад, одну групу менеджерів, один вид документів, один підрозділ або один процес. Це дозволяє швидко знайти помилки, уточнити ролі, скоригувати форми, перевірити інтеграції й навчити ключових користувачів.
<pre>
ignore
</pre>


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


== Промисловий запуск ==
Приклад файлу:


Промисловий запуск означає, що K2 ERP стає основною системою для визначених процесів.
<pre>
k2site.txt
</pre>


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


Після запуску важливо не повертатися хаотично до старих баз, Excel-файлів і ручних обмінів. Інакше компанія отримає не нову ERP, а ще одну систему поруч зі старим хаосом.
<pre>
__pycache__
.gitignore
.git
ej2.min.js
</pre>


== Закриття старих систем після встановлення ==
У файлі:


Після встановлення K2 ERP старі системи потрібно виводити з активного використання.
<pre>
token.txt
</pre>


Це стосується 1С, BAS, UA-Бюджет, Парус, старих CRM, Excel-таблиць, складських програм, локальних баз і файлових архівів.
потрібно додати токен доступу до сервера оновлення.


Закриття означає не обов’язково фізичне видалення. Спочатку потрібно архівувати потрібні дані, обмежити доступ, вимкнути інтеграції, описати резервні копії, заблокувати технічних користувачів і визначити правила доступу до історії.
== 7. Завантаження нової версії компоненти в систему оновлення ==


== Типові помилки під час встановлення K2 ERP ==
Для створення нової версії компоненти, stable або beta/testing, потрібно змінити версію у файлі:


Найчастіша помилка — сприймати встановлення ERP як технічну інсталяцію без бізнес-підготовки.
<pre>
setup.py
</pre>


Друга помилка — запускати систему без ролей, резервних копій, тестового середовища й відповідальних адміністраторів.
Файл розташований у корені каталогу компоненти.


Третя помилка — переносити всі старі дані без очищення.
Потрібно змінити рядок 5, поле:


Четверта помилка — залишати стару 1С/BAS-систему відкритою після запуску K2 ERP.
<pre>
version
</pre>


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


== Етапи встановлення K2 ERP ==
<pre>
version=2.0.4.43
</pre>


{| class="wikitable" style="width:100%;"
Також потрібно вказати тип версії:
! Етап
! Зміст
|-
| Обстеження
| Визначаються поточні системи, процеси, користувачі, дані, інтеграції, архіви й вимоги до безпеки.
|-
| Вибір моделі
| Обирається хмара, окрема хмара, локальне встановлення, гібридна модель або партнерська хмара.
|-
| Підготовка середовища
| Створюється тестове або продуктивне середовище, налаштовуються базові параметри, доступи й адміністрування.
|-
| Налаштування ролей
| Визначаються користувачі, ролі, права доступу, адміністратори й технічні користувачі.
|-
| Підготовка даних
| Очищуються довідники, готуються контрагенти, номенклатура, склади, залишки, документи й архіви.
|-
| Міграція
| Дані переносяться через [[Реплікатор K2 ERP]] або інші погоджені інструменти, потім перевіряються й звіряються.
|-
| Інтеграції
| Підключаються банки, ЕДО, сайти, склади, CRM, ПРРО, BI або інші зовнішні системи.
|-
| Навчання
| Користувачі проходять навчання за своїми ролями й реальними сценаріями роботи.
|-
| Пілотний запуск
| Система запускається на обмеженому процесі або підрозділі для перевірки.
|-
| Промисловий запуск
| K2 ERP стає робочою системою для визначених процесів.
|-
| Закриття старого контуру
| Старі доступи, інтеграції, резервні копії й системи переводяться в контрольований архів або виводяться з використання.
|}


== Порівняння сценаріїв встановлення ==
<pre>
version_type='stable'
</pre>


{| class="wikitable" style="width:100%;"
або testing-версію:
! Сценарій
! Коли підходить
! Особливості
|-
| [[K2 Cloud ERP]]
| Для швидкого старту без власного сервера.
| Менше технічної складності, зручний тестовий і продуктивний запуск.
|-
| Окрема хмара
| Для компаній із підвищеним контролем даних.
| Ізольована інфраструктура, окремий сервер, більше контролю.
|-
| Локальне встановлення
| Для компаній із власною ІТ-інфраструктурою.
| Більше контролю, але більше відповідальності за адміністрування.
|-
| Гібридна модель
| Для поступового переходу або складних інтеграцій.
| Частина процесів у хмарі, частина локально або на виділеній інфраструктурі.
|-
| [[Партнерська хмара K2]]
| Для партнерів, інтеграторів, бухгалтерських компаній і сервісних провайдерів.
| Партнер надає не лише хмару, а й впровадження, підтримку, міграцію та супровід.
|}


== Встановлення K2 ERP як alternativeTo ==
<pre>
version_type='testing'
</pre>


{| class="wikitable" style="width:100%;"
Після цього потрібно додати опис змін у файл:
! Старий або ризиковий підхід
! Альтернатива через встановлення K2 ERP
|-
| Локальні сервери 1С/BAS без підтримки
| [[K2 Cloud ERP]], окрема хмара, локальне або гібридне розгортання
|-
| Excel-облік і ручні файли
| [[K2 ERP]], CRM, склад, фінанси, документи й аналітика в єдиній системі
|-
| Розрізнені документи
| [[K2 ERP Документообіг]], [[K2 VDoc]], [[VDoc]]
|-
| Ручний ЕДО
| [[Модуль Вчасно]], [[Вчасно.ЕДО]], інтеграція ЕДО з ERP
|-
| Складна міграція з 1С/BAS
| [[Реплікатор K2 ERP]], тестове перенесення, очищення, звірка, запуск
|-
| Неконтрольовані архіви
| Контрольований електронний архів у межах ERP-контуру
|-
| Відсутність ІТ-команди
| Хмарна або партнерська модель супроводу, адміністрування й підтримки
|}


== SEO-запити, пов’язані зі статтею ==
<pre>
history.txt
</pre>


Ця стаття орієнтована на користувачів, які шукають встановлення K2 ERP, розгортання K2 ERP, інсталяція K2 ERP, K2 ERP установка, K2 Cloud ERP встановлення, K2 ERP у хмарі, K2 ERP локально, K2 ERP сервер, K2 ERP гібридна модель, K2 ERP окрема хмара, Партнерська хмара K2, українська ERP встановлення, ERP розгортання, міграція з 1С у K2 ERP, міграція з BAS у K2 ERP, Реплікатор K2 ERP, K2 ERP Документообіг, Вчасно.ЕДО, VDoc, K2 VDoc, ERP без локального сервера.
Файл розташований у корені каталогу компоненти.


Типові запити: «встановлення K2 ERP», «як встановити K2 ERP», «розгортання K2 ERP», «K2 Cloud ERP встановлення», «K2 ERP локально чи в хмарі», «K2 ERP сервер», «K2 ERP міграція з 1С», «K2 ERP міграція з BAS», «K2 ERP тестове середовище», «K2 ERP права доступу», «K2 ERP резервне копіювання».
Опис змін додається в один рядок.


== Поширені запитання ==
Приклад:


=== Що таке встановлення K2 ERP? ===
<pre>
2.0.4.43 - додавання додаткового поля в форму реєстрації
</pre>


[[Встановлення K2 ERP]] — це підготовка, розгортання, налаштування й запуск [[K2 ERP]] або [[K2 Cloud ERP]] у роботу: користувачі, ролі, дані, модулі, інтеграції, документообіг, ЕДО, КЕП, резервні копії та підтримка.
Далі потрібно перейти в корінь додатку, на рівні з виконуваним файлом:


=== Чи можна встановити K2 ERP у хмарі? ===
<pre>
app.py
</pre>


Так. Для цього може використовуватися [[K2 Cloud ERP]], окрема хмара або [[Партнерська хмара K2]].
Команда:


=== Чи можна встановити K2 ERP локально? ===
<pre>
cd k2
</pre>


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


=== Що потрібно підготувати перед встановленням? ===
<pre>
builder/config/component-list.txt
</pre>


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


=== Чи можна під час встановлення перейти з 1С/BAS? ===
<pre>
python k2update_push.py
</pre>


Так. Для цього може використовуватися [[Реплікатор K2 ERP]], тестове перенесення, очищення довідників, звірка залишків, перенесення документів і запуск нової ERP.
== 8. Оновлення змінених версій компонент на тестових доменах ==


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


Так, особливо якщо є міграція з 1С/BAS, інтеграції, склад, документообіг, ЕДО або виробництво. Тестове середовище дозволяє перевірити процеси до промислового запуску.
<pre>
deb1
deb2
deb3
</pre>


=== Що робити зі старою системою після встановлення K2 ERP? ===
Після оновлення потрібно протестувати функціонал.


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


== Коротко ==
== Коротко ==


{| class="wikitable" style="width:100%;"
{| class="wikitable" style="width:100%;"
! Питання
! Етап
! Відповідь
! Що робиться
|-
|-
| Що це?
| 1
| Підготовка, розгортання, налаштування й запуск [[K2 ERP]] або [[K2 Cloud ERP]]
| Копіюється існуючий проєкт по FTP, запускається first_run і змінюється domain_protocol з https на http.
|-
|-
| Основні сценарії
| 2
| Хмара, окрема хмара, локальне встановлення, гібридна модель, [[Партнерська хмара K2]]
| Встановлюється PyCharm, відкривається проєкт і налаштовується Python Interpreter.
|-
|-
| З чого почати?
| 3
| З обстеження процесів, даних, користувачів, інтеграцій і вимог до безпеки
| Встановлюється Git, налаштовується користувач і SSH-ключ.
|-
|-
| Для міграції
| 4
| [[Реплікатор K2 ERP]]
| Підключаються віддалені репозиторії компонент через auto_update або вручну.
|-
|-
| Для документообігу
| 5
| [[K2 ERP Документообіг]], [[K2 VDoc]], [[VDoc]]
| Комітяться та пушаться зміни через auto_update або вручну.
|-
|-
| Для ЕДО
| 6
| [[Модуль Вчасно]], [[Вчасно.ЕДО]]
| Налаштовується список компонент для завантаження на сервер оновлення.
|-
|-
| Важливий етап
| 7
| Тестове середовище, звірка даних і навчання користувачів
| Створюється нова версія компоненти й завантажується через k2update_push.py.
|-
|-
| Головний ризик
| 8
| Встановити систему технічно, але не підготувати бізнес-процеси, ролі, дані, резервні копії та закриття старої системи
| Компоненти оновлюються на тестових доменах deb1-deb3 і тестуються.
|}
|}
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Головний висновок.''' [[Встановлення K2 ERP]] — це не просто інсталяція програми. Це запуск української ERP-архітектури: [[K2 ERP]], [[K2 Cloud ERP]], [[Реплікатор K2 ERP]], документообіг, ЕДО, КЕП, архіви, інтеграції, користувачі, ролі, резервні копії, тестове середовище, міграція з 1С/BAS і контрольований перехід у продуктивну роботу.
</div>
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Перевіряйте актуальність.''' Технічні вимоги, умови K2 Cloud ERP, можливості локального або гібридного розгортання, ціни, інтеграції, мобільні застосунки, ЕДО, КЕП, правила підтримки, вимоги до безпеки й резервного копіювання можуть змінюватися. Перед встановленням потрібно перевіряти чинну документацію та погоджувати архітектуру з відповідальними фахівцями.
</div>
== Джерела ==
* [https://erp.kyiv.ua/ K2 ERP: офіційний сайт]
* [https://wiki.erp.kyiv.ua/ K2 ERP Wiki]
* [https://corp2.eu/ K2 Cloud ERP]
* [https://erp.kyiv.ua/erp/ K2 ERP: гібридна ERP]
* [https://erp.kyiv.ua/product/k2-cloud-yadro/ K2 Cloud Ядро]
* [https://erp.kyiv.ua/z-1-travnya-bezkoshtovnyj-upravlinskyj-oblik-u-k2-cloud-erp/ K2 Cloud ERP: окрема хмара та виділений сервер]
* [https://erp.kyiv.ua/k2-erp-biznes-zavzhdy-pid-rukoyu/ K2 Cloud ERP на мобільних пристроях]
* [https://erp.kyiv.ua/product/replikator/ K2 ERP: Реплікатор]
* [https://erp.kyiv.ua/category/perehid-z-1s-ta-bas/ K2 ERP: Перехід з 1С та BAS]
* [https://erp.kyiv.ua/k2-cloud-erp-prozoryj-perehid-z-1s-ta-bas-bez-vtraty-danyh-i-zupynky-pidpryyemstv/ K2 Cloud ERP: прозорий перехід з 1С та BAS]
* [https://erp.kyiv.ua/product/dokumentoobig-na-1-server-bez-obmezhennya-korystuvachiv/ K2 ERP: Документообіг]
* [https://erp.kyiv.ua/product/modul-vchasno/ K2 ERP: Модуль Вчасно]
* [https://erp.kyiv.ua/product/vdoc/ K2 ERP: VDoc]


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


* [[K2 Cloud ERP]]
* [[K2 ERP]]
* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[K2 Cloud Ядро]]
* [[K2 Cloud Ядро]]
* [[Партнерська хмара K2]]
* [[Партнерська програма K2]]
* [[Розгортання K2 ERP]]
* [[Розгортання K2 ERP]]
* [[Архітектура K2 ERP]]
* [[Встановлення K2 ERP]]
* [[База даних K2 ERP]]
* [[K2 ERP для Linux]]
* [[API K2 ERP]]
* [[PyCharm]]
* [[Інтеграції K2 ERP]]
* [[Git]]
* [[GitLab]]
* [[Розробка K2 ERP]]
* [[Компоненти K2 ERP]]
* [[Оновлення K2 ERP]]
* [[Права доступу K2 ERP]]
* [[Права доступу K2 ERP]]
* [[Безпека ERP]]
* [[Безпека ERP]]
* [[Реплікатор K2 ERP]]
* [[K2 ERP Документообіг]]
* [[K2 VDoc]]
* [[VDoc]]
* [[Модуль Вчасно]]
* [[Вчасно.ЕДО]]
* [[Хмарна ERP]]
* [[SaaS ERP]]
* [[ERP-системи]]
* [[Міграція з 1С]]
* [[Міграція з BAS]]
* [[Міграція з UA-Бюджет]]
* [[Міграція з Парус]]
* [[Перехід з 1С та BAS на K2 ERP]]
* [[Українська ERP]]
* [[Українське програмне забезпечення]]
* [[Документообіг]]
* [[Електронний документообіг]]
* [[КЕП]]
* [[Бухгалтерський облік]]
* [[Фінансовий облік]]
* [[Управлінський облік]]
* [[Складський облік]]
* [[Виробництво]]
* [[CRM]]


[[Категорія:Встановлення K2 ERP]]
[[Категорія:K2 Cloud ERP]]
[[Категорія:K2 ERP]]
[[Категорія:K2 ERP]]
[[Категорія:K2 Cloud ERP]]
[[Категорія:K2 Cloud Ядро]]
[[Категорія:Партнерська хмара K2]]
[[Категорія:Партнерська програма K2]]
[[Категорія:Розгортання K2 ERP]]
[[Категорія:Розгортання K2 ERP]]
[[Категорія:Архітектура K2 ERP]]
[[Категорія:Встановлення K2 ERP]]
[[Категорія:База даних K2 ERP]]
[[Категорія:Розробка K2 ERP]]
[[Категорія:API K2 ERP]]
[[Категорія:K2 ERP для розробників]]
[[Категорія:Інтеграції K2 ERP]]
[[Категорія:K2 ERP Python]]
[[Категорія:Права доступу K2 ERP]]
[[Категорія:PyCharm]]
[[Категорія:Реплікатор K2 ERP]]
[[Категорія:Git]]
[[Категорія:Компоненти K2 ERP]]
[[Категорія:Оновлення K2 ERP]]
[[Категорія:Хмарна ERP]]
[[Категорія:Хмарна ERP]]
[[Категорія:SaaS ERP]]
[[Категорія:ERP-системи]]
[[Категорія:ERP-системи]]
[[Категорія:Українська ERP]]
[[Категорія:Українська ERP]]
[[Категорія:Українське програмне забезпечення]]
[[Категорія:Міграція з 1С]]
[[Категорія:Міграція з BAS]]
[[Категорія:Міграція з UA-Бюджет]]
[[Категорія:Міграція з Парус]]
[[Категорія:Перехід з 1С та BAS на K2 ERP]]
[[Категорія:Безпека ERP]]
[[Категорія:Документообіг]]
[[Категорія:Електронний документообіг]]
[[Категорія:КЕП]]
[[Категорія:K2 ERP Документообіг]]
[[Категорія:K2 VDoc]]
[[Категорія:Модуль Вчасно]]
[[Категорія:Вчасно.ЕДО]]
[[Категорія:VDoc]]
[[Категорія:Бухгалтерський облік]]
[[Категорія:Фінансовий облік]]
[[Категорія:Управлінський облік]]
[[Категорія:Складський облік]]
[[Категорія:Виробництво]]
[[Категорія:CRM]]
[[Категорія:Корпоративна Wiki]]
[[Категорія:Корпоративна Wiki]]

Поточна версія на 19:08, 2 травня 2026


SEO title: Розгортання K2 Cloud ERP Python для розробників — локальний запуск, PyCharm, Git, компоненти, оновлення SEO description: Інструкція з локального розгортання робочого проєкту K2 Cloud ERP Python для розробників: копіювання проєкту по FTP, перший запуск, налаштування віртуального середовища, запуск K2 Cloud ERP, встановлення PyCharm, налаштування Python Interpreter, встановлення Git, підключення віддалених репозиторіїв компонент, коміт змін, завантаження компонент на сервер оновлення та тестування на deb1-deb3. SEO keywords: K2 Cloud ERP Python, розгортання K2 Cloud ERP, встановлення K2 ERP Linux, K2 ERP Python, PyCharm K2 ERP, Git K2 ERP, auto_update K2 ERP, k2update_push.py, компоненти K2 ERP, локальний запуск K2 Cloud ERP, first_run.sh, run.sh, k2cfg.py, Реплікатор K2 ERP, K2 ERP для розробників Alternative to:


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

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

1. Копіювання існуючого проєкту по FTP і перший запуск

Спочатку потрібно скопіювати з віддаленого сервера існуючий проєкт по FTP.

Після копіювання потрібно перейти в каталог:

/K2CloudERP

У цьому каталозі запускається файл першого запуску first_run для налаштування параметрів віртуального середовища в поточному локальному розташуванні.

Для Linux використовується команда:

bash first_run.sh

Для Windows використовується команда:

./first_run.bat

Після цього потрібно перейти у файл налаштувань:

/K2CloudERP/cfg/k2/k2/k2cfg.py

У цьому файлі потрібно змінити параметр:

domain_protocol

Значення потрібно змінити з:

https

на:

http

Після зміни налаштувань можна запускати додаток.

Для Linux:

bash run.sh

Для Windows:

./run.bat

2. Встановлення середовища розробки PyCharm та відкриття проєкту

Для розробки використовується середовище PyCharm.

Встановлення PyCharm у Linux через snap

Для Linux можна встановити PyCharm через snap.

Спочатку потрібно виконати команди:

sudo rm /etc/apt/preferences.d/nosnap.pref
sudo apt update
sudo apt install snapd
sudo snap install pycharm-community --classic

Після встановлення PyCharm запускається командою:

pycharm-community

Встановлення PyCharm у Linux через архів із сайту JetBrains

Також PyCharm можна встановити через завантаження архіву з офіційного сайту JetBrains:

https://www.jetbrains.com/pycharm/download/?section=linux

Після завантаження архів потрібно розпакувати, перейти в папку:

bin

і запустити файл:

./pycharm.sh

Якщо під час запуску виникає помилка, потрібно встановити JRE/JDK командами:

sudo apt update
sudo apt install default-jdk

Встановлення PyCharm у Windows

Для Windows потрібно завантажити архів із сайту JetBrains:

https://www.jetbrains.com/pycharm/download/?section=windows

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

Відкриття проєкту в PyCharm

Після встановлення потрібно відкрити середовище розробки PyCharm.

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

У правому нижньому куті PyCharm потрібно вибрати:

Python Interpreter

Потім:

Add new Interpreter

У полі Location потрібно додати шлях до поточної папки:

venv

У полі Base Interpreter потрібно додати шлях до поточного виконуваного Python-файлу.

Приклад:

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

Після налаштування інтерпретатора можна запускати проєкт у debug-режимі через кнопку у правому верхньому куті PyCharm.

Також проєкт можна запускати з консолі PyCharm.

Для Linux:

bash run.sh

Для Windows:

./run.bat

Ручна активація віртуального середовища

Для Linux:

source venv/bin/activate

Для Windows:

.\venv\Scripts\activate

3. Встановлення та налаштування Git

Для роботи з компонентами потрібно встановити й налаштувати Git.

Встановлення Git у Linux

Для Linux використовується команда:

sudo apt update
sudo apt install git

Встановлення Git у Windows

Для Windows потрібно завантажити Git за посиланням:

https://git-scm.com/downloads/win

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

Налаштування користувача Git

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

git config --global user.name "Ваше Ім'я"

Також потрібно налаштувати email:

git config --global user.email "ваша_електронна_пошта@example.com"

Авторизація в Git

Можливі два варіанти авторизації:

авторизація за допомогою логіна й пароля;

авторизація через SSH.

Налаштування SSH-ключа

Для створення SSH-ключа потрібно виконати команду:

ssh-keygen -t rsa -b 4096 -C "ваша_електронна_пошта@example.com"

Після цього потрібно запустити ssh-agent:

eval "$(ssh-agent -s)"

Далі потрібно додати ключ:

ssh-add ~/.ssh/id_rsa

Щоб переглянути публічний ключ, використовується команда:

cat ~/.ssh/id_rsa.pub

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

4. Підключення віддаленого репозиторію Git для компоненти або списку компонент

Підключення репозиторію можна виконувати для списку компонент або для однієї компоненти вручну.

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

Для роботи зі списком компонент використовується скрипт:

auto_update

Потрібно скопіювати каталог зі скриптом і вставити його в корінь проєкту на рівні з виконуваним файлом:

app.py

Посилання на каталог:

https://git.corp2.eu/k2erp/python/k2/base/client/auto_update

Після цього потрібно відкрити проєкт у консолі й перейти в каталог:

cd auto_update

Далі потрібно відкрити файл:

settings.py

У словник потрібно додати ключі з потрібними компонентами.

Повний список компонент міститься у файлі:

settings_example.py

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

python git_cmd.py clone

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

Для підключення однієї компоненти потрібно перейти в папку потрібної компоненти.

Наприклад, для компоненти k2site:

cd components/k2site

Далі потрібно ініціалізувати Git у поточній директорії:

git init

Створити локальну гілку main і перемкнутися на неї:

git checkout -b main

За потреби можна перемкнутися на іншу локальну гілку:

git checkout master

Далі потрібно додати віддалений репозиторій:

git remote add origin http://git.corp2.eu/k2erp/python/k2/base/site/k2site.git

Перевірити підключений репозиторій:

git remote -v

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

git fetch origin

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

git pull origin main

Для перевірки змін локально скопійованої копії проєкту порівняно з віддаленим репозиторієм використовується команда:

git status

5. Коміт змін на віддалений репозиторій Git

Коміт змін можна виконувати автоматично через скрипт auto_update або вручну.

Автоматичний коміт через auto_update

Потрібно відкрити проєкт у консолі й перейти в каталог:

cd auto_update

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

python git_cmd.py clone

Перевірити статус:

python git_cmd.py status

Виконати коміт змін:

python git_cmd.py commit

Отримати зміни з віддаленого сервера:

python git_cmd.py pull

Запушити зміни на віддалений репозиторій:

python git_cmd.py push

Ручний коміт змін

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

git status

Далі потрібно додати зміни:

git add .

Потім виконати коміт:

git commit -m "Назва комміту"

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

git push

Під час подальшої роботи зміни з віддаленого репозиторію отримуються командою:

git pull

6. Налаштування завантаження компонент на сервер оновлення

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

builder/config

У файлі:

component-list.txt

потрібно додати список компонент, які будуть завантажуватися на сервер оновлення.

Кожна компонента додається з нового рядка.

Приклад:

components/k2update
components/k2adm
components/k2site

У папці:

ignore

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

Приклад файлу:

k2site.txt

Приклад вмісту:

__pycache__
.gitignore
.git
ej2.min.js

У файлі:

token.txt

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

7. Завантаження нової версії компоненти в систему оновлення

Для створення нової версії компоненти, stable або beta/testing, потрібно змінити версію у файлі:

setup.py

Файл розташований у корені каталогу компоненти.

Потрібно змінити рядок 5, поле:

version

Приклад:

version=2.0.4.43

Також потрібно вказати тип версії:

version_type='stable'

або testing-версію:

version_type='testing'

Після цього потрібно додати опис змін у файл:

history.txt

Файл розташований у корені каталогу компоненти.

Опис змін додається в один рядок.

Приклад:

2.0.4.43 - додавання додаткового поля в форму реєстрації

Далі потрібно перейти в корінь додатку, на рівні з виконуваним файлом:

app.py

Команда:

cd k2

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

builder/config/component-list.txt

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

python k2update_push.py

8. Оновлення змінених версій компонент на тестових доменах

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

deb1
deb2
deb3

Після оновлення потрібно протестувати функціонал.

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

Коротко

Етап Що робиться
1 Копіюється існуючий проєкт по FTP, запускається first_run і змінюється domain_protocol з https на http.
2 Встановлюється PyCharm, відкривається проєкт і налаштовується Python Interpreter.
3 Встановлюється Git, налаштовується користувач і SSH-ключ.
4 Підключаються віддалені репозиторії компонент через auto_update або вручну.
5 Комітяться та пушаться зміни через auto_update або вручну.
6 Налаштовується список компонент для завантаження на сервер оновлення.
7 Створюється нова версія компоненти й завантажується через k2update_push.py.
8 Компоненти оновлюються на тестових доменах deb1-deb3 і тестуються.

Див. також