База даних K2 ERP

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

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

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

Важливо. База даних ERP — це не місце для хаотичного копіювання старих довідників. Під час переходу з 1С або BAS потрібно очищати дублікати, розділяти активні й архівні дані, переглядати доступи та будувати нову інформаційну модель.

Що таке база даних K2 ERP

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

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

Наприклад, CRM-модуль може використовувати того самого контрагента, що й фінансовий модуль. Документообіг може працювати з тим самим договором, що й заявка на оплату. Складський модуль може використовувати ту саму номенклатуру, що й продажі, закупівлі або виробництво.

Архітектурний сенс. База даних K2 ERP поєднує модулі не через ручні обміни, а через спільну інформаційну основу. Це зменшує дублювання, помилки та залежність від Excel-файлів.

Єдина база даних як архітектурний принцип

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

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

K2 ERP має іншу логіку. Єдина база даних дозволяє:

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

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

PostgreSQL у K2 ERP

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

PostgreSQL може використовуватися для роботи з:

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

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

Технічний акцент. PostgreSQL у K2 ERP — це не просто СУБД, а основа для транзакційності, структурованих довідників, аналітики, журналювання та масштабування.

Роль K2.db

У K2 Cloud ERP Python база даних доступна через глобальний об’єкт:

K2.db

Цей об’єкт використовується як точка доступу до підключення бази даних у системних класах і модулях. Наприклад, у технічному описі класів K2 зазначається, що `db` є властивістю класу K2, яка відповідає за підключення до бази даних.

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

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

ORM-структури та models.py

У K2 Cloud ERP компоненти мають містити ORM-структури, необхідні для роботи відповідної компоненти. Зазвичай вони зберігаються у файлі:

models.py

Файл `models.py` описує структури даних, з якими працює компонент. Це можуть бути таблиці, поля, зв’язки, типи даних і правила, потрібні для збереження об’єктів у базі.

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

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

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

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

Структура бази даних у компонентах

Компоненти K2 ERP повинні мати опис структури бази даних. У технічних вимогах до компонент зазначено, що структура бази даних зберігається в каталозі:

doc/schema

На момент опису інструкції структура бази даних може зберігатися у форматі SQL Power Architect.

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

Основні типи даних у K2 ERP

База даних K2 ERP може містити різні групи даних. Їх можна умовно поділити на бізнесові, системні, технічні та аналітичні.

Тип даних	Приклади	Навіщо потрібні
Довідники	контрагенти, номенклатура, склади, підрозділи, валюти, статті бюджету	Єдина база для всіх модулів
Документи	договори, рахунки, акти, заявки, накладні, накази	Фіксація бізнес-подій і юридичних підстав
Фінансові дані	платежі, заявки на оплату, бюджети, план-факт, взаєморозрахунки	Контроль грошей і зобов’язань
Складські дані	залишки, рухи, партії, резерви, інвентаризації	Контроль товарів і матеріальних цінностей
CRM-дані	ліди, контакти, угоди, клієнти, історія комунікацій	Управління продажами та взаємодією з клієнтами
Користувачі й доступи	користувачі, ролі, права, дозволи, сесії	Безпека та контроль дій
Системні налаштування	параметри проєкту, домени, мови, компоненти, шаблони	Керування платформою
Журнали	події, помилки, повідомлення, історія змін	Аудит і діагностика
Аналітичні дані	звіти, агрегати, BI-показники	Управлінська аналітика

Спільні довідники

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

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

У старих системах або в кількох окремих базах часто виникають дублікати:

ТОВ “Приклад”;
ТОВ Приклад;
Приклад ТОВ;
Example LLC;
контрагент із помилкою в назві;
контрагент без коду;
контрагент, створений повторно в іншій конфігурації.

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

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

Таблиці модулів

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

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

Приклад: номенклатура

У технічному описі K2 Cloud ERP згадується логіка додавання нової номенклатури через таблицю:

k2nomenclature

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

Типова логіка такого процесу:

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

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

Приклад: залишки

У матеріалах K2 також згадується обробка залишків із використанням статусів:

`new`;
`stable`;
`old`.

Типова логіка оновлення залишків може виглядати так:

нові записи вставляються зі статусом `new`;
попередні стабільні записи переводяться в `old`;
нові записи після перевірки переводяться в `stable`;
застарілі записи видаляються або виключаються з активної вибірки;
зміни фіксуються через `commit`;
у разі помилки виконується `rollback`.

Така модель допомагає не просто перезаписувати залишки, а керовано оновлювати стан даних.

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

Транзакції: commit і rollback

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

Для цього використовуються транзакції.

commit

означає фіксацію змін у базі.

rollback

означає відкат змін у разі помилки.

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

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

Підключення до бази даних

У класі K2 є методи, пов’язані з ініціалізацією підключення до бази даних:

init_db()
init_db_uri()
init_db_custom()
init_db_uri_custom()
init_db_user()
init_db_uri_user()

Ці методи відображають кілька сценаріїв роботи з базою:

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

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

Файл підключення до БД

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

create_db_file_config_user()
init_db_uri_user()

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

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

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

Ролі на рівні бази даних

У K2 Cloud ERP передбачені методи роботи з користувачами на рівні бази даних:

create_db_role(user_name, password)
drop_db_role(user_name)
kill_user_sessions(target_username)

Це означає, що система може створювати, видаляти або завершувати сесії користувачів не лише на рівні інтерфейсу, а й на рівні БД.

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

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

Права доступу

У K2 ERP доступи мають бути частиною архітектури бази даних. У технічному описі методу `get_user_permissions()` згадуються дозволи:

`r` — читання;
`w` — запис;
`i` — вставка;
`d` — видалення;
`c` — створення;
`exp` — експорт;
`imp` — імпорт;
`del_` — відновлення або робота з видаленими записами;
`settable` — налаштування таблиці;
`cutpast` — операції вирізання і вставлення;
`enable` — увімкнення;
`active` — активність.

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

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

Експорт та імпорт

Права `exp` та `imp` особливо важливі для безпеки бази даних.

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

Імпорт даних — це також ризик, бо некоректний файл може створити дублікати, зіпсувати довідники або змінити залишки.

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

Ризик. Неконтрольований експорт може винести з ERP фінансові, клієнтські або персональні дані. Неконтрольований імпорт може зіпсувати довідники, залишки або документи.

Журналювання та логування

База даних ERP має підтримувати аудит дій. У K2 Cloud ERP існує клас `k2logging` і методи для збереження та завантаження повідомлень логування.

Для бази даних важливо фіксувати:

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

Журналювання потрібне не лише для розробників. Воно допомагає бізнесу зрозуміти, що сталося з даними, хто виконав дію і коли виникла помилка.

Перевага. Журналювання перетворює ERP з “чорної скриньки” на контрольовану систему, де можна відстежити події, помилки та важливі зміни.

База даних і документообіг

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

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

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

База даних і фінансовий контур

Фінансові дані — одна з найчутливіших зон ERP. У базі даних K2 ERP можуть зберігатися:

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

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

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

База даних і CRM

CRM-модуль K2 ERP працює з клієнтами, лідами, контактами, угодами, задачами, файлами, рахунками, звітами й налаштуваннями. У технічному описі згадується клас `K2CRM`, а також клас `K2DocsCRM`, у якому база даних доступна через глобальний об’єкт `K2.db`.

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

База даних і склад

Складський контур у ERP залежить від якості даних. У базі можуть зберігатися:

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

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

База даних і BI-аналітика

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

База даних є джерелом для:

управлінських звітів;
фінансових показників;
складських звітів;
CRM-аналітики;
план-факт аналізу;
звітів за підрозділами;
контролю оплат;
аналізу продажів;
продуктивності складу;
ефективності бізнес-процесів.

Перевага. Якщо дані народжуються в процесах K2 ERP, аналітика формується природно, а не вручну через Excel-зведення.

База даних і інтеграції

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

Інтеграції можуть передавати:

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

Кожна інтеграція має мати власника, опис, журнал помилок, правила доступу та сценарій відновлення.

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

Міграція даних з 1С/BAS

Під час міграції з 1С або BAS база даних K2 ERP стає цільовим середовищем для нової структури даних.

Не варто просто переносити стару базу “як є”. Перед міграцією потрібно визначити:

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

Міграція має не забруднювати K2 ERP старим хаосом, а створювати чисту й керовану структуру даних.

Помилка. Найгірший сценарій — перенести всю стару базу 1С/BAS без очищення. У такому випадку K2 ERP отримає дублікати, застарілі записи, помилкові права й непотрібний архівний шум.

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

Активні та архівні дані

Важливо розділяти активні й архівні дані.

Активні дані — це те, що потрібно для щоденної роботи:

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

Архівні дані — це історія, яка потрібна для перевірок, аудиту, юридичного зберігання або довідки.

Архівні дані не завжди треба переносити в активні таблиці K2 ERP. Часто краще створити контрольований архів із обмеженим доступом.

Резервне копіювання бази даних

Резервне копіювання — обов’язкова частина роботи з базою даних K2 ERP.

Backup має відповідати моделі розгортання:

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

Важливо не лише створювати резервні копії, а й перевіряти відновлення. Backup, який ніколи не тестували, не можна вважати надійним.

Важливо. Резервна копія без перевірки відновлення — це лише припущення, а не гарантія.

Відновлення після збою

Для бази даних K2 ERP потрібно мати сценарій відновлення після збою. Він має відповідати на питання:

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

ERP без плану відновлення — це ризик для бізнесу.

Індекси та продуктивність

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

Для продуктивності важливі:

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

Аналітичний звіт не повинен блокувати роботу операційного модуля. Імпорт не повинен зупиняти користувачів. Інтеграція не повинна створювати надмірне навантаження на базу.

Dev, Test, Prod бази

Для якісної розробки й впровадження бажано розділяти бази або середовища.

Середовище	Призначення	Особливість
Dev	Розробка модулів і компонентів	Можна експериментувати без ризику для бізнесу
Test	Перевірка оновлень, міграцій, ролей, інтеграцій	Має бути схоже на бойове середовище
Demo	Демонстрації та навчання	Дані мають бути навчальними або знеособленими
Prod	Робоча база підприємства	Максимальна стабільність і контроль
Archive	Історичні дані	Обмежений доступ і правила зберігання

Не можна тестувати небезпечні зміни безпосередньо на бойовій базі.

Заборона. Не можна тестувати імпорти, оновлення, нові модулі або масові зміни прямо на бойовій базі без перевірки в Test-середовищі.

Безпека бази даних

Безпека бази даних K2 ERP включає кілька рівнів:

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

Особливо чутливими є фінансові, кадрові, зарплатні, договірні та персональні дані.

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

Чого не можна робити з базою K2 ERP

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

Небажані практики:

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

Документація бази даних

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

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

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

Без документації модуль стає ризиком для майбутньої підтримки.

База даних і магазин доповнень

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

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

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

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

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

Типові помилки під час роботи з базою даних

Перша помилка — переносити всі дані зі старої 1С/BAS без очищення. У результаті K2 ERP отримує дублікати, помилки й архівний шум.

Друга помилка — створювати окремі таблиці там, де можна використовувати спільні довідники.

Третя помилка — давати користувачам надмірні права на експорт і редагування.

Четверта помилка — працювати напряму з бойовою базою без backup і тесту.

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

Шоста помилка — не розділяти dev, test і prod.

Сьома помилка — не перевіряти відновлення з резервної копії.

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

Як зрозуміти, що база даних K2 ERP побудована правильно

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

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

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

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

Що таке база даних K2 ERP?

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

Яку СУБД використовує K2 ERP?

У технологічній основі K2 ERP використовується PostgreSQL.

Що таке K2.db?

`K2.db` — це глобальний об’єкт доступу до бази даних у K2 Cloud ERP Python. Через нього системні класи й модулі можуть працювати з БД.

Де описується структура бази даних компоненти?

ORM-структури компоненти описуються у файлі `models.py`, а документація структури бази даних має зберігатися в каталозі `doc/schema`.

Чому єдина база даних важлива для ERP?

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

Чи можна переносити всю стару базу 1С/BAS у K2 ERP?

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

Чи потрібне резервне копіювання бази K2 ERP?

Так. Резервне копіювання є обов’язковою частиною роботи з базою ERP. Також потрібно регулярно перевіряти відновлення з backup.

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

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

Сторінка База даних K2 ERP має допомагати користувачам і пошуковим системам зрозуміти, як у K2 ERP організовано зберігання даних: єдина база, PostgreSQL, спільні довідники, ORM-структури, `models.py`, `K2.db`, ролі, права, транзакції, резервне копіювання, міграція з 1С/BAS і безпека.

Вона покриває запити: “база даних K2 ERP”, “K2 ERP база даних”, “K2 Cloud ERP PostgreSQL”, “K2.db”, “ORM K2 ERP”, “models.py K2”, “єдина база даних ERP”, “база даних української ERP”, “міграція даних з 1С”, “міграція даних з BAS”, “безпека бази даних ERP”, “резервне копіювання ERP”.

Коротко

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

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

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

Див. також