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

База даних K2 ERP

Матеріал з K2 ERP Wiki
Такі файли мають бути захищені.;

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

  • схему бази даних;
  • інструкцію встановлення;
  • історію змін;
  • залежності;
  • правила актуалізація;
  • характеристика впливу на інформаційні дані;
  • вимоги до прав доступу.; Складський компонент має змогу використовувати ту саму номенклатуру, що й продажі та реалізація, закупівельна діяльність або виробництво.; У такому випадку K2 ERP отримає дублікати, застарілі записи, помилкові права й непотрібний архівний шум.; |}
│ └── user_manual/

База даних і складський облік

Файл `models.py` описує структури даних, з якими функціонує компонент.; |}

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

Спільні довідники — одна з головних переваг єдиної бази даних.; Він має відповідати на питання:

  • `r` — читання;
  • `w` — запис;
  • `i` — вставка;
  • `d` — видалення;
  • `c` — створення;
  • `exp` — експорт;
  • `imp` — імпорт;
  • `del_` — відновлення або робота з видаленими записами;
  • `settable` — конфігурація таблиці;
  • `cutpast` — операції вирізання і вставлення;
  • `enable` — увімкнення;
  • `active` — активність.; kill_user_sessions(target_username)
├── doc/

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

У технологічному стеку K2 ERP застосовують, коли потрібно PostgreSQL.; Перед міграцією потрібно очистити дублікати, відокремити активні інформаційні дані від архівних і не копіювати старі помилки.; Через нього системні класи й модулі можуть працювати з БД.; │ ├── business_processes/ Приклад логіки компоненти:
  • отримати інформаційні дані номенклатури;
  • перевірити, чи є собою запис у базі;
  • якщо запис уже є собою — не дублювати;
  • якщо запису немає — створити новий;
  • за потреби нормалізувати одиницю виміру;
  • зафіксувати зміни;
  • у разі помилки записати її в лог.; Воно сприяє бізнесу зрозуміти, що сталося з даними, хто виконав дію і коли виникла помилка.; CRM-модуль K2 ERP функціонує з клієнтами, лідами, контактами, угодами, задачами, файлами, рахунками, звітами й налаштуваннями.; Резервне копіювання — обов’язкова частина роботи з базою даних K2 ERP.;
У старих системах або в кількох окремих базах часто виникають дублікати:
Для продуктивності важливі: У технологічній основі K2 ERP застосовується PostgreSQL.; |-
Ризик. Дублікати в довідниках руйнують аналітику, ускладнюють звірки, створюють помилки в документах і заважають міграції.; База даних K2 ERP має змогу містити різні групи даних.; * стандартне підключення;
  • підключення за URI;
  • кастомне підключення;
  • підключення для конкретного користувача;
  • підключення до custom-баз;
  • зчитування параметрів підключення з конфігураційних файлів.; Середовище

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

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

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

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

означає відкат змін у разі помилки.; Для безпеки краще, щоб зовнішні сервіси не мали неконтрольованого прямого доступу до таблиць.; як ілюстрація, у технічному описі класів K2 зазначається, що `db` є собою властивістю класу K2, яка відповідає за підключення до бази даних.; {| class="wikitable" style="width:100%; background:#e8f5e9;"

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

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

Для бази даних істотно фіксувати: </syntaxhighlight>

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

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

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

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

init_db_uri_user() У великій ERP-системі продуктивність бази даних має велике значення.; Це можуть бути таблиці, поля, зв’язки, типи даних і правила, потрібні для збереження об’єктів у базі.; Не можна створювати зайві ролі, використовувати спільні логіни або залишати активними користувачів, які вже не мають працювати з системою.; |}

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

Архітектурний сенс.

База даних K2 ERP поєднує модулі не через ручні обміни, а через спільну інформаційну основу.; Зазвичай вони зберігаються у файлі:

</syntaxhighlight>

  • правильні індекси;
  • оптимізовані запити;
  • контроль великих таблиць;
  • архівація старих даних;
  • обмеження непотрібних вибірок;
  • оптимізація звітів;
  • контроль важких інтеграцій;
  • моніторинг повільних запитів.; Їхня цінність саме в з цієї причини, що вони можуть посилатися на спільні сутності: користувачів, контрагентів, номенклатуру, склади, проєкти, договори, документи та ролі.; П’ята помилка — не документувати структуру бази компоненти.; Backup, який ніколи не тестували, не можна вважати надійним.; init_db_uri_custom()
Для розробника. Якщо компонента створює нові таблиці або сутності, це має бути описано в ORM і задокументовано.; Резервне копіювання є собою обов’язковою частиною роботи з базою ERP.; ORM-структури компоненти описуються у файлі `models.py`, а документація структури бази даних має зберігатися в каталозі `doc/schema`.; K2.db

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

Для бази даних K2 ERP потрібно мати сценарій відновлення після збою.; * пряме редагування бойових таблиць без процедури;
* створення дубльованих довідників;
* використання спільних логінів;
* неконтрольований експорт;
* імпорт без перевірки;
* зміна структури таблиць без версії компоненти;
* відсутність резервної копії перед масовими змінами;
* тестування на бойовій базі;
* зберігання паролів у відкритому вигляді;
* інтеграції без журналу помилок;
* відсутність документації структури даних.; як ілюстрація, CRM-модуль має змогу використовувати того самого контрагента, що й фінансовий компонент.;== Як зрозуміти, що база даних K2 ERP побудована правильно ==
|-
== Експорт та імпорт ==
|}

{{DISPLAYTITLE:База даних K2 ERP}}

== Коротко ==

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

* довідниками;
* документами;
* фінансовими операціями;
* складськими залишками;
* CRM-даними;
* правами доступу;
* журналами подій;
* налаштуваннями системи;
* аналітичними запитами;
* модулями та компонентами.;[[Категорія:ORM]]
|-
| '''Перевага.''' <span style="color:#2e7d32;">Журналювання перетворює ERP з “чорної скриньки” на контрольовану систему, де можна відстежити події, помилки та важливі зміни.;</span> Централізований доступ спрощує контроль, підтримку й безпеку.; {| class="wikitable" style="width:100%; background:#ffebee;"

Для ERP-системи істотно, щоб операції з базою даних були цілісними.; Але для архітектури K2 ERP вона має принципове значення, з цієї причини що саме через спільну базу даних модулі можуть працювати як частини однієї системи.; {| class="wikitable" style="width:100%; background:#e3f2fd;" Без документації компонент стає ризиком для майбутньої підтримки.;=== Чи потрібне резервне копіювання бази K2 ERP? ===

{{SEO 


│ ├── views.py

Кожна інтеграційні функціональні можливості має мати власника, характеристика, журнал помилок, правила доступу та сценарій відновлення.; Третя помилка — давати користувачам надмірні права на експорт і редагування.; База даних є собою джерелом для: завдяки наявності | Перевага. Єдина база даних користувачі можуть підприємству бачити цілісну картину бізнесу: фінансовий блок, документи, продажі та реалізація, складський облік, CRM, користувачі й аналітичні інструменти працюють не окремо, а в єдиній ERP-логіці.; Якщо компонент створює таблиці, зв’язки або нові сутності, їх потрібно документувати.; Це потрібно, щоб доповнення не ламали систему після оновлень і не створювали приховані ризики.; Якщо платформа створює документ, змінює залишок, додає фінансову заявку або переносить інформаційні дані з іншої системи, операційна дія має або завершитися в цілому, або бути скасована.; │ ├── models.py

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

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

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

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

== Див.; додатково ==
Кожен компонент K2 ERP має змогу мати власні таблиці.;</span> Це основа керованості підприємства: чисті довідники, актуальні документи, контроль доступів, безпечні інтеграції, транзакційність, резервне копіювання, журналювання, міграція зі старих систем і можливість розвивати нові модулі без дублювання вже створеної логіки.; У них не можна зберігати паролі або токени без контролю доступу.; Часто краще створити контрольований архів із обмеженим доступом.; Якщо таблиці ростуть, кількість документів збільшується, користувачів стає більше, а інтеграції працюють постійно, запити можуть сповільнюватися.; Шоста помилка — не розділяти dev, test і prod.; Для цього використовуються транзакції.; |-
| '''істотно.''' <span style="color:#ef6c00;">Залишки не можна оновлювати хаотично.; У результаті K2 ERP отримує дублікати, помилки й архівний шум.;</span> Це зменшує дублювання, помилки та залежність від Excel-файлів.;<syntaxhighlight lang="text">
[[Категорія:Міграція з 1С]]
Для таких даних особливо важливі права доступу, журналювання, резервне копіювання, контроль експорту та розділення ролей.; ERP без плану відновлення — це ризик для бізнесу.; Це означає, що платформа має змогу створювати, видаляти або завершувати сесії користувачів не лише на рівні інтерфейсу, а й на рівні БД.;</span> Якщо контрагент забезпечується через | '''Головна ідея.''' <span style="color:#2e7d32;">База даних K2 ERP має бути єдиним джерелом правди; додатково реалізовано товар, документ, заявка, складський облік, користувач системи або платіж існує в системі, він має бути частиною спільної структури даних, а не копією в окремій таблиці, Excel-файлі чи зовнішній базі без контролю.;== Єдина база даних як архітектурний принцип ==
[[Категорія:K2 ERP]]
істотно розділяти активні й архівні інформаційні дані.; Документ — це не без ускладнень файл, завантажений у систему.;</span>
|}

Міграція має не забруднювати K2 ERP старим хаосом, а створювати чисту й керовану структуру даних.; інтеграційні функціональні можливості не повинна створювати надмірне навантаження на базу.; {| class="wikitable" style="width:100%; background:#fff3e0;"
|-
| '''Ризик.''' <span style="color:#b71c1c;">Неконтрольований експорт має змогу винести з ERP фінансові, клієнтські або персональні інформаційні дані.;</span>
|}

 ├── requirements.txt

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

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

components/

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

як ілюстрація, один і той самий контрагент має змогу використовуватися в CRM, договорах, рахунках, заявках на оплату, документах і аналітиці.;[[Категорія:Архітектура K2 ERP]]
{| class="wikitable" style="width:100%; background:#e8f5e9;"
{| class="wikitable" style="width:100%; background:#fff3e0;"
У традиційній ERP база даних часто залишається невидимою для бізнес-користувача.; роботу модулів.; База даних ERP має підтримувати аудит дій.; {| class="wikitable" style="width:100%; background:#e8f5e9;"

=== Що таке K2.db? ===

{| class="wikitable" style="width:100%; background:#e8f5e9;"
|-
| '''істотно для розробника.''' <span style="color:#ef6c00;">Не варто створювати хаотичні прямі підключення до бази там, де має використовуватися стандартний механізм K2.;<syntaxhighlight lang="text">
|-
| '''істотно.''' <span style="color:#ef6c00;">Резервна копія без перевірки відновлення — це лише припущення, а не гарантія.; Не можна працювати з базою даних як із “зручною таблицею”, яку можна редагувати вручну без правил.; |}

== Відновлення після збою ==
|-
| '''Правильний сценарій.''' <span style="color:#2e7d32;">Перед перенесенням даних потрібно провести аудит, очистити довідники, визначити активні записи, відокремити архів і не копіювати старі доступи автономно.;== Роль K2.db ==

* нові записи вставляються зі статусом `new`;
* попередні стабільні записи переводяться в `old`;
* нові записи після перевірки переводяться в `stable`;
* застарілі записи видаляються або виключаються з активної вибірки;
* зміни фіксуються через `commit`;
* у разі помилки виконується `rollback`.; як ілюстрація, CRM-модуль має змогу працювати з лідами, контактами, угодами, рахунками та комунікаціями.; Для бойового середовища потрібно використовувати окремі правила безпеки: обмеження прав, захист файлової системи, контроль доступу до конфігурацій і резервне копіювання.; |-
| '''істотно.''' <span style="color:#ef6c00;">Ролі на рівні БД мають відповідати реальній моделі доступів.; Приклади
|-
| '''Архітектурний принцип.''' <span style="color:#1565c0;">Доступи в K2 ERP мають бути не “все або нічого”, а деталізованими за діями: читання, запис, створення, видалення, імпорт, експорт і адміністрування.; завдяки наявності цьому K2 ERP має змогу працювати не як набір розрізнених систем, а як цілісна платформа, де модулі використовують спільну інформаційну основу, а бізнес-середовище отримує єдине джерело правди.;</span> Під час переходу з [[1С]] або [[BAS]] потрібно очищати дублікати, розділяти активні й архівні інформаційні дані, переглядати доступи та будувати нову інформаційну модель.;</span>
|}

[[Категорія:Українське програмне забезпечення]]

init_db_custom()

 │ ├── forms.py

Цей об’єкт застосовується як точка доступу до підключення бази даних у системних класах і модулях.; Особливість

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

  • у публічній хмарі — за резервування відповідає оператор хмари;
  • у партнерській хмарі — відповідальність несе хмарний партнерська сторона;
  • у приватній хмарі — правила визначаються договором;
  • у локальному розгортанні — відповідальність часто лежить на клієнті або партнері;
  • у dev-середовищі — резервування потрібне для збереження розробок і тестових даних.; |}
Особливо чутливими є собою фінансові, кадрові, зарплатні, договірні та персональні інформаційні дані.; Аналітичний звіт не повинен блокувати роботу операційного модуля.;
Восьма помилка — дозволяти інтеграціям записувати інформаційні дані без журналювання й контролю помилок.; У технічному описі згадуються методи:
|}

!; !; з цієї причини база даних має забезпечувати цілісність, статуси, перевірки й контроль змін.;</span>
|}

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

models.py

; має змогу працювати з документами, але не мати права експортувати інформаційні дані.; │ ├── hooks.py Четверта помилка — працювати напряму з бойовою базою без backup і тесту.; ├── requirements-components.txt

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

База даних K2 ERP — це фундамент української ERP-платформи K2.; │ ├── objects/

; Він має атрибути:

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

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

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

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

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

} 
Кожен компонент або компонента, що створює власні таблиці, має мати документацію структури бази даних.; Для якісної розробки й впровадження бажано розділяти бази або середовища.; |}

[[Категорія:Доступи K2 ERP]]

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

== Активні та архівні інформаційні дані ==

* помилки під час збереження;
* помилки під час імпорту;
* відхилені транзакції;
* критичні зміни;
* дії користувачів;
* зміни ролей;
* зміни налаштувань;
* проблеми інтеграцій;
* актуалізація компонентів.; {| class="wikitable" style="width:100%; background:#e3f2fd;"

Одним із ключових принципів K2 ERP є собою ідея '''єдиної бази даних'''.; Складський компонент має змогу мати таблиці для залишків, рухів, партій і розміщення.;</span>
|}

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

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

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

Сторінка '''База даних K2 ERP''' має допомагати користувачам і пошуковим системам зрозуміти, як у K2 ERP організовано зберігання даних: єдина база, PostgreSQL, спільні довідники, ORM-структури, `models.py`, `K2.db`, ролі, права, транзакції, резервне копіювання, міграція з 1С/BAS і безпека.; Імпорт не повинен зупиняти користувачів.; * тип документа;
* номер;
* дата;
* контрагент;
* договір;
* статус;
* автор;
* відповідальний;
* маршрут погодження;
* файл або набір файлів;
* історичний розвиток змін;
* права доступу;
* зв’язок із фінансовими, складськими або CRM-процесами.;[[Магазин доповнень K2]] має враховувати структуру бази даних кожного доповнення.; Журналювання потрібне не лише для розробників.;

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

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

├── k2adm/
  • номенклатура;
  • одиниці виміру;
  • склади;
  • комірки;
  • залишки;
  • рухи;
  • партії;
  • резерви;
  • інвентаризації;
  • документи надходження;
  • документи відвантаження;
  • зв’язок зі закупівлями та продажами.; |-
Ознака здорової бази. Користувачі не сперечаються, де “справжні інформаційні дані”, бо всі ключові модулі працюють із єдиною інформаційною основою K2 ERP.; Використання PostgreSQL додатково важливе для Linux-серверів, хмарної інфраструктури, локального розгортання та сценаріїв, де бізнес-середовище хоче уникати дорогих або закритих серверних ліцензій.; Якщо під час імпорту залишків частина записів збережеться, а частина ні, бізнес-середовище має змогу отримати неправильні інформаційні дані.; init_db()

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

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

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

</syntaxhighlight> 

* які довідники актуальні;
* які контрагенти дублюються;
* які товари не використовуються;
* які договори діючі;
* які залишки потрібно перенести;
* які документи мають залишитися в архіві;
* які користувачі більше не працюють;
* які доступи не можна копіювати;
* які таблиці старої системи потрібні лише для історії.; create_db_file_config_user()
`K2.db` — це глобальний об’єкт доступу до бази даних у K2 Cloud ERP Python.; Компоненти K2 ERP повинні мати характеристика структури бази даних.; |-
| '''Фінансовий ризик.''' <span style="color:#b71c1c;">Фінансовий контур не можна відкривати всім користувачам.;== Підключення до бази даних ==
== База даних і фінансовий контур ==

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

init_db_uri()

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

[[Категорія:Міграція з BAS]]

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

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

Це означає, що CRM не має бути окремим островом.;=== Яку СУБД використовує K2 ERP? ===

;

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

Не варто без ускладнень переносити стару базу “як є собою”.; Це істотно для хмарної, партнерської, приватної та локальної архітектури, де середовища можуть мати різні параметри БД.;== Транзакції: commit і rollback ==

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

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

Але ці таблиці не повинні перетворюватися на ізольовані “острови”.;
* де зберігаються резервні копії;
* як часто вони створюються;
* хто має до них доступ;
* як оперативно можна відновити систему;
* чи тестувалося відновлення;
* що робити після пошкодження даних;
* хто ухвалює рішення для бізнесу про відкат;
* як повідомляються користувачі.;<syntaxhighlight lang="text">

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

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

Права `exp` та `imp` особливо важливі для безпеки бази даних.; Навіщо потрібні
|-
| '''істотно.''' <span style="color:#ef6c00;">База даних ERP — це не місце для хаотичного копіювання старих довідників.; * контрагентів;
* замовлення;
* залишки;
* платежі;
* документи;
* статуси;
* файли;
* інформаційні дані маркетплейсів;
* банківські виписки;
* повідомлення;
* логістичні статуси.; Це означає, що модулі не повинні існувати як ізольовані системи з власними копіями довідників і власною логікою зберігання.; Архівні інформаційні дані не завжди треба переносити в активні таблиці K2 ERP.;</span> Інакше компонент буде важко підтримувати, оновлювати й перевіряти.; |}

rollback

* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[Архітектура K2 ERP]]
* [[Розгортання K2 ERP]]
* [[Розгортання системи K2 Cloud ERP Python для розробників]]
* [[Магазин доповнень K2]]
* [[Сертифікація K2]]
* [[Доступи K2 ERP]]
* [[Ролі K2 ERP]]
* [[Безпека K2 ERP]]
* [[Міграція з 1С]]
* [[Міграція з BAS]]
* [[PostgreSQL]]
* [[Python]]
* [[ORM]]

Типова логіка такого процесу:
{| class="wikitable" style="width:100%; background:#fff3e0;"
Друга помилка — створювати окремі таблиці там, де можна використовувати спільні довідники.; '''База даних K2 ERP''' — це структуроване сховище, у якому зберігаються інформаційні дані всіх ключових модулів платформи.;</span>
|}

Складський контур у ERP залежить від якості даних.;</span>
|}

Технічно частину даних можна переносити, але не варто переносити все без аналізу.;</span> Старі користувачі, тимчасові облікові записи й зайві адміністратори повинні регулярно переглядатися.;== Індекси та продуктивність ==

Фінансові інформаційні дані — одна з найчутливіших зон ERP.; Єдина база даних надає можливість:

drop_db_role(user_name)

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

з цієї причини імпорт і експорт у K2 ERP мають бути окремими контрольованими правами, а не автоматичною можливістю для всіх користувачів.; k2nomenclature
Інтеграції можуть передавати:
{| class="wikitable" style="width:100%;"
__TOC__
=== Де описується структура бази даних компоненти? ===
{| class="wikitable" style="width:100%; background:#fff3e0;"
Метод перевіряє, чи існує номенклатура в таблиці `k2nomenclature`.;</span> Доступ до заявок, оплат, бюджетів і банківських даних має бути обмеженим і контрольованим.; електронний документообіг має змогу працювати з тим самим договором, що й заявка на оплату.; У такій моделі бізнес-середовище постійно стикається з питанням: де справжні інформаційні дані?; {| class="wikitable" style="width:100%; background:#fff3e0;"
|-
| '''Помилка.''' <span style="color:#b71c1c;">Найгірший сценарій — перенести всю стару базу 1С/BAS без очищення.;</span> У них можуть бути параметри доступу, які потрібно захищати правами файлової системи, політиками безпеки й резервним копіюванням.; K2 ERP має іншу логіку.; {| class="wikitable" style="width:100%; background:#e3f2fd;"
=== Чи можна переносити всю стару базу 1С/BAS у K2 ERP? ===

Ще одна ознака правильної архітектури — новий компонент має змогу використовувати вже наявні інформаційні дані.; '''База даних K2 ERP''' — це центральне сховище даних платформи K2 ERP, у якому зберігаються довідники, документи, користувачі, ролі, фінансові інформаційні дані, складські інформаційні дані, CRM-дані, конфігурація, журнали та інформаційні дані модулів.;</span> Це контрольований канал обміну, який має права, журнал, правила помилок і відповідального.; Якщо заявки, документи, склади, продажі та реалізація, закупівельна діяльність та фінансовий блок ведуться в одній системі, аналітичні інструменти має змогу формуватися без ручного зведення в Excel.; commit

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

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

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

Типова логіка актуалізація залишків має змогу виглядати так:

* ТОВ “Приклад”;
* ТОВ Приклад;
* Приклад ТОВ;
* Example LLC;
* контрагент із помилкою в назві;
* контрагент без коду;
* контрагент, створений повторно в іншій конфігурації.; create_db_role(user_name, password)
|-
| '''Безпека.''' <span style="color:#b71c1c;">Файли підключення до БД не можна залишати відкритими.;
  • `new`;
  • `stable`;
  • `old`.;
    * управлінських звітів;
* фінансових показників;
* складських звітів;
* CRM-аналітики;
* план-факт аналізу;
* звітів за підрозділами;
* контролю оплат;
* аналізу продажів;
* продуктивності складу;
* ефективності бізнес-процесів.; інформаційні дані CRM можуть бути пов’язані з фінансами, документами, договорами, продажами, рахунками та аналітикою.; '''Імпорт даних''' — це додатково ризик, бо некоректний файл має змогу створити дублікати, зіпсувати довідники або змінити залишки.; У технічному описі методу `get_user_permissions()` згадуються дозволи:

{| class="wikitable" style="width:100%;"
|-
| '''Ризик.''' <span style="color:#b71c1c;">операційна дія з базою даних без транзакцій має змогу залишити систему в напівзміненому стані.; Перша помилка — переносити всі інформаційні дані зі старої 1С/BAS без очищення.;== База даних і CRM ==

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

!;== Таблиці модулів ==
|-
| '''<span style="color:#1565c0;">Dev</span>'''
| розробка програмного забезпечення модулів і компонентів
| Можна експериментувати без ризику для бізнесу
|-
| '''<span style="color:#1565c0;">Test</span>'''
| Перевірка оновлень, міграцій, ролей, інтеграцій
| Має бути схоже на бойове середовище
|-
| '''Demo'''
| Демонстрації та навчання
| інформаційні дані мають бути навчальними або знеособленими
|-
| '''<span style="color:#2e7d32;">Prod</span>'''
| Робоча база підприємства
| Максимальна стабільність і контроль
|-
| '''Archive'''
| Історичні інформаційні дані
| Обмежений доступ і правила зберігання
|}

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

doc/schema
|-
| '''Заборона.''' <span style="color:#b71c1c;">Не можна тестувати імпорти, актуалізація, нові модулі або масові зміни прямо на бойовій базі без перевірки в Test-середовищі.; Безпека бази даних K2 ERP охоплює кілька рівнів:

[[Категорія:Компоненти K2 ERP]]

У K2 Cloud ERP компоненти мають містити ORM-структури, необхідні для роботи відповідної компоненти.; {| class="wikitable" style="width:100%; background:#fff3e0;"
|-
| '''<span style="color:#1565c0;">Довідники</span>'''
| контрагенти, номенклатура, склади, підрозділи, валюти, статті бюджету
| Єдина база для всіх модулів
|-
| '''<span style="color:#1565c0;">Документи</span>'''
| договори, рахунки, акти, заявки, накладні, накази
| Фіксація бізнес-подій і юридичних підстав
|-
| '''<span style="color:#2e7d32;">Фінансові інформаційні дані</span>'''
| платежі, заявки на оплату, бюджети, план-факт, взаєморозрахунки
| Контроль грошей і зобов’язань
|-
| '''<span style="color:#2e7d32;">Складські інформаційні дані</span>'''
| залишки, рухи, партії, резерви, інвентаризації
| Контроль товарів і матеріальних цінностей
|-
| '''<span style="color:#1565c0;">CRM-дані</span>'''
| ліди, контакти, угоди, клієнти, історичний розвиток комунікацій
| керування продажами та взаємодією з клієнтами
|-
| '''<span style="color:#ef6c00;">Користувачі й доступи</span>'''
| користувачі, ролі, права, дозволи, сесії
| Безпека та контроль дій
|-
| '''Системні конфігурація'''
| параметри проєкту, домени, мови, компоненти, шаблони
| Керування платформою
|-
| '''<span style="color:#b71c1c;">Журнали</span>'''
| події, помилки, повідомлення, історичний розвиток змін
| Аудит і діагностика
|-
| '''Аналітичні інформаційні дані'''
| звіти, агрегати, BI-показники
| Управлінська аналітичні інструменти
|}

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

У K2 ERP база даних розглядається не як приховане технічне сховище, а як <span style="color:#1565c0;">основа всієї ERP-архітектури</span>.; Вона.; init_db_user()
|-
| '''Перевага.''' <span style="color:#2e7d32;">Якщо інформаційні дані народжуються в процесах K2 ERP, аналітичні інструменти формується природно, а не вручну через Excel-зведення.; Якщо компонент створює таблиці або змінює структуру даних, це має бути описано.;== Dev, Test, Prod бази ==

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

* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[Архітектура K2 ERP]]
* [[Розгортання K2 ERP]]
* [[Розгортання системи K2 Cloud ERP Python для розробників]]
* [[Магазин доповнень K2]]
* [[Сертифікація K2]]
* [[Партнерська програма K2]]
* [[Доступи K2 ERP]]
* [[Ролі K2 ERP]]
* [[Безпека K2 ERP]]
* [[K2 ERP Документообіг]]
* [[Фінансовий облік]]
* [[Управлінський облік]]
* [[Міграція з 1С]]
* [[Міграція з BAS]]
* [[PostgreSQL]]
* [[ORM]]
* [[Python]]

[[Категорія:Магазин доповнень K2]]

init_db_uri_user()

== PostgreSQL у K2 ERP ==

 │ └── ...; '''Експорт даних''' — це ризик, з цієї причини що користувач системи має змогу вивантажити клієнтів, фінансові інформаційні дані, документи, залишки, персональні інформаційні дані або управлінську аналітику.; |}

'''Архівні інформаційні дані''' — це історичний розвиток, яка потрібна для перевірок, аудиту, юридичного зберігання або довідки.; Ці методи відображають кілька сценаріїв роботи з базою:

 │ ├── schema/
== Основні типи даних у K2 ERP ==
== База даних і магазин доповнень ==
== Права доступу ==
У K2 ERP електронний документообіг спирається на базу даних.; Документація має відповідати на питання:

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

 └── setup.py
[[Категорія:База даних K2 ERP]]
Для ERP це критично.;[[Категорія:Безпека K2 ERP]]

== Структура бази даних у компонентах ==
|-
| '''істотно для магазину доповнень.''' <span style="color:#ef6c00;">компонент без описаної структури даних, правил актуалізація й вимог до доступів не повинен вважатися зрілим корпоративним доповненням.; У технічному описі згадується клас `K2CRM`, а додатково клас `K2DocsCRM`, у якому база даних доступна через глобальний об’єкт `K2.db`.; {| class="wikitable" style="width:100%; background:#ffebee;"

== Ролі на рівні бази даних ==
|-
У K2 можуть використовуватися файли з параметрами підключення до бази даних.; як ілюстрація, виробничий компонент не має заново створювати номенклатуру, CRM не має заново створювати контрагентів, а електронний документообіг не має дублювати договори.; з цієї причини транзакційність є собою базовою вимогою до роботи з БД.; додатково потрібно регулярно перевіряти відновлення з backup.; Інтеграції K2 ERP можуть працювати з базою даних напряму або через API, залежно від архітектури.; Тип даних
Отримано з https://wiki.corp2.eu/index.php?title=База_даних_K2_ERP&oldid=800