K2 ERP Wiki Ukraine — База знань з автоматизації та санкцій в Україні - Внесок користувача [uk]

Головна сторінка

2026-04-28T21:58:35Z

R: Поправив жирність

== Про систему K2 ERP ==

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

== Сайти K2 ERP ==
[[Ресурси K2 ERP]]

== Для користувачів ==

[[Початок роботи з K2 ERP]]

[[Хмара K2]]

[[Бухгалтерія K2 ERP]]

[[Управлінський облік K2 ERP]]

[[CRM K2 ERP]]

[[Складський облік K2 ERP]]

[[Інтернет-магазин K2 ERP]]

[[K2 VDoc]]

[[Галузеві рішення K2 ERP]]

[[Звіти та аналітика K2 ERP]]

[[Поширені питання K2 ERP]]

== Для програмістів ==

[[Розгортання системи K2 ERP Python для розробників]]

[[Архітектура K2 ERP]]

[[Встановлення K2 ERP]]

[[Розгортання K2 ERP]]

[[Створення модулів K2 ERP]]

[[База даних K2 ERP]]

[[API K2 ERP]]

[[Інтеграції K2 ERP]]

[[K2 CMS]]

[[Розробка веб-інтерфейсів K2]]

[[Бізнес-процеси K2 ERP]]

[[Права доступу K2 ERP]]

[[Рекомендації для розробників K2]]

[[Класи та команди K2 ERP Python]]

[[Стандарти UI K2 2025]]

== Атестаційні завдання по K2 ERP ==

[[Атестаційні завдання по K2 ERP]]

[[Регламент K2]]

== K2 ERP PHP ==

[[Практична робота в K2 ERP PHP]]

[[Інструкція по розгортанню K2 ERP PHP]]

[[Класи та команди K2 Cloud ERP PHP]]

== Робота в K2 ==
[[Налаштування WireGuard]]

== Довідник та модулі ==

* [[K2 CMS]]
* [[K2 VDoc (Електронний документообіг)]]
* [[Ліцензійна політика K2]]

== Навігація за категоріями ==
Усі статті бази знань автоматично групуються за категоріями:

* [[:Категорія:ERP-системи|ERP-системи]]
* [[:Категорія:Програмне забезпечення, розроблене в Україні|Українське ПЗ]]
* [[:Категорія:Програмне забезпечення для бізнесу|ПЗ для бізнесу]]

== Порівняння систем ==

[[K2 ERP vs BAS ERP]]

[[K2 ERP vs BAS Управління торгівлею (UT)]]

[[K2 ERP vs Парус-Підприємство]]

[[K2 ERP vs SAP]]

[[K2 ERP vs Microsoft Dynamics 365]]

[[K2 ERP vs Oracle NetSuite]]

[[K2 ERP vs Odoo]]

[[K2 ERP vs Scoro]]

== Статті по IT ==

[[Цифрова деокупація та санкції в Україні]]

Головна сторінка

2026-04-28T21:57:55Z

R: Додав порівняння

== Про систему K2 ERP ==

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

== Сайти K2 ERP ==
[[Ресурси K2 ERP]]

== Для користувачів ==

[[Початок роботи з K2 ERP]]

[[Хмара K2]]

[[Бухгалтерія K2 ERP]]

[[Управлінський облік K2 ERP]]

[[CRM K2 ERP]]

[[Складський облік K2 ERP]]

[[Інтернет-магазин K2 ERP]]

[[K2 VDoc]]

[[Галузеві рішення K2 ERP]]

[[Звіти та аналітика K2 ERP]]

[[Поширені питання K2 ERP]]

== Для програмістів ==

[[Розгортання системи K2 ERP Python для розробників]]

[[Архітектура K2 ERP]]

[[Встановлення K2 ERP]]

[[Розгортання K2 ERP]]

[[Створення модулів K2 ERP]]

[[База даних K2 ERP]]

[[API K2 ERP]]

[[Інтеграції K2 ERP]]

[[K2 CMS]]

[[Розробка веб-інтерфейсів K2]]

[[Бізнес-процеси K2 ERP]]

[[Права доступу K2 ERP]]

[[Рекомендації для розробників K2]]

[[Класи та команди K2 ERP Python]]

[[Стандарти UI K2 2025]]

== Атестаційні завдання по K2 ERP ==

[[Атестаційні завдання по K2 ERP]]

[[Регламент K2]]

== K2 ERP PHP ==

[[Практична робота в K2 ERP PHP]]

[[Інструкція по розгортанню K2 ERP PHP]]

[[Класи та команди K2 Cloud ERP PHP]]

== Робота в K2 ==
[[Налаштування WireGuard]]

== Довідник та модулі ==

* [[K2 CMS]]
* [[K2 VDoc (Електронний документообіг)]]
* [[Ліцензійна політика K2]]

== Навігація за категоріями ==
Усі статті бази знань автоматично групуються за категоріями:

* [[:Категорія:ERP-системи|ERP-системи]]
* [[:Категорія:Програмне забезпечення, розроблене в Україні|Українське ПЗ]]
* [[:Категорія:Програмне забезпечення для бізнесу|ПЗ для бізнесу]]

== Порівняння систем ==

[[K2 ERP vs BAS ERP]]

[[K2 ERP vs BAS Управління торгівлею (UT)]]

[[K2 ERP vs Парус-Підприємство:|'''K2 ERP vs Парус-Підприємство''':]]

[[K2 ERP vs SAP]]

[[K2 ERP vs Microsoft Dynamics 365]]

[[K2 ERP vs Oracle NetSuite]]

[[K2 ERP vs Odoo]]

[[K2 ERP vs Scoro]]

== Статті по IT ==

[[Цифрова деокупація та санкції в Україні]]

Заміщення 1С

2026-04-28T21:52:03Z

R: Заміщення 1С

== Заміщення 1С та BAS: Стратегія переходу для українського бізнесу ==
'''Заміщення 1С''' — це стратегічний комплекс заходів із виведення підсанкційних програмних продуктів (1С:Підприємство, BAS, Парус) з ІТ-контуру підприємства та впровадження альтернативних систем автоматизації.

З огляду на посилення санкційної політики у 2024–2026 роках, повна відмова від російського софту стала необхідною умовою для безпечного функціонування будь-якого українського суб'єкта господарювання.

=== Чому заміщення є критичним у 2026 році? ===

* '''Юридична токсичність''': Використання підсанкційного ПЗ може бути підставою для перевірок з боку контролюючих органів та блокування електронного документообігу.
* '''Відсутність легітимних оновлень''': Після січня 2026 року офіційна підтримка та оновлення форм звітності для систем 1С/BAS в Україні технічно та юридично заблоковані.
* '''Кіберризики''': Продукти, код яких розроблявся в РФ, містять потенційні вразливості для цільових атак на інфраструктуру України.

=== Етапи заміщення 1С ===
Процес переходу зазвичай триває від 3 до 9 місяців, залежно від масштабу компанії, і включає наступні кроки:

==== 1. Аналіз поточної конфігурації ====
Проведення інвентаризації всіх модулів (Бухгалтерія, Зарплата і Кадри, Склад, Виробництво). Визначення обсягу кастомізації (допрацювань), які були зроблені в 1С.

==== 2. Підготовка даних (Data Cleaning) ====
Перед переходом необхідно провести ревізію довідників контрагентів, номенклатури та залишків. Важливо вивантажити дані у форматі CSV або Excel для подальшого імпорту в нову систему.

==== 3. Вибір цільової системи ====
На ринку України представлено три основні вектори заміщення:

* '''Українські ERP''': Системы, як-от [[K2 ERP]] або IT-Enterprise, що спочатку розроблялися під українське законодавство.
* '''Міжнародні ERP''': [[Odoo]], SAP Business One, Microsoft Dynamics 365 (потребують локалізації бухгалтерії).
* '''Хмарні сервіси''': Спеціалізовані рішення для малого бізнесу (Dilovod, Master:Бухгалтерія).

==== 4. Паралельна експлуатація ====
Протягом 1-2 звітних періодів (місяців) рекомендується вести облік одночасно у старій та новій системах для звірки сальдо та коректності нарахувань.

=== Порівняння архітектури 1С та сучасних ERP ===
{| class="wikitable"
!Характеристика
!1С / BAS (Застаріле)
!Сучасні системи (напр. K2 ERP)
|-
|'''Архітектура'''
|Монолітна, закрита
|Модульна, веб-орієнтована
|-
|'''Доступ'''
|Переважно локальний сервер
|Хмарний доступ (SaaS), мобільні додатки
|-
|'''Безпека'''
|Ризик витоку даних до РФ
|Відповідність стандартам ДСТУ/ISO
|-
|'''Оновлення'''
|Ручне, складне
|Автоматичне, "безшовне"
|}

=== Рекомендації щодо міграції ===
Для мінімізації ризиків під час заміщення рекомендується:

* Не намагатися повністю скопіювати інтерфейс 1С у новій системі.
* Використовувати перехід як можливість для оптимізації застарілих бізнес-процесів.
* Забезпечити повне видалення підсанкційного ПЗ з серверів після завершення міграції для уникнення претензій з боку кіберполіції.

Цифрова деокупація та санкції в Україні

2026-04-28T21:51:12Z

R: Цифрова деокупація

'''Цифрова деокупація''' — це процес повного заміщення програмного забезпечення, цифрових сервісів та ІТ-інфраструктури, що мають походження з країни-агресора (РФ) або контролюються її резидентами, на українські або міжнародні аналоги. Метою цифрової деокупації є забезпечення національної кібербезпеки, захист персональних даних та запобігання фінансуванню агресії через ліцензійні платежі.

=== Законодавче підґрунтя ===
Процес цифрової деокупації в Україні регулюється наступними нормативно-правовими актами:

* '''Указ Президента України №487/2024''': Про запровадження санкцій проти технологічних компаній РФ.
* '''Закон України про санкції''': Визначає правові основи обмеження використання програмних продуктів.
* '''Рішення РНБО від 2025 року''': Встановлює граничні терміни використання підсанкційного ПЗ для приватного сектору (до 1 січня 2026 року).

=== Реєстр підсанкційного програмного забезпечення (основні групи) ===
У межах цифрової деокупації обов'язковому заміщенню підлягають наступні системи:
{| class="wikitable"
!Група ПЗ
!Найпопулярніші продукти
!Статус (на 2026 рік)
|-
|ERP та бухгалтерський облік
|1С:Підприємство, BAS ERP, Парус
|Повна заборона для держсектору; критичні ризики для бізнесу.
|-
|CRM-системи
|Бітрікс24, AmoCRM
|Блокування на рівні провайдерів; витік даних до РФ.
|-
|Антивірусне ПЗ
|Kaspersky, Dr.Web
|Заборонено до використання на території України.
|}

=== Ризики використання підсанкційного ПЗ ===
1. '''Кібершпигунство''': Наявність «бекдорів» (backdoors) у коді російського ПЗ дозволяє спецслужбам РФ отримувати доступ до фінансової та стратегічної інформації українських компаній. 2. '''Фінансування тероризму''': Сплата за оновлення та підтримку російських продуктів фактично є наповненням бюджету країни-агресора. 3. '''Технічне блокування''': Згідно з планом цифрової деокупації, з 2026 року буде посилено контроль за електронною звітністю. Звіти, сформовані у підсанкційних програмах, можуть не прийматися державними органами.

=== Дорожня карта цифрової деокупації підприємства ===

# '''Аудит''': Виявлення всіх встановлених програм російського походження.
# '''Вибір альтернативи''': Перехід на українські системи (наприклад, [[K2 ERP]]) або світові рішення ([[Odoo]], [[SAP]]).
# '''Міграція даних''': Вивантаження залишків та довідників зі старих систем.
# '''Навчання персоналу''': Адаптація команди до нового інтерфейсу та бізнес-процесів.

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

* [[K2 ERP]] — українська альтернатива для цифрової деокупації.
* [[Заміщення 1С]] — покроковий гайд міграції.

Головна сторінка

2026-04-28T21:49:56Z

R: Додав розділ цифрової деокупації

== Про систему K2 ERP ==

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

== Сайти K2 ERP ==
[[Ресурси K2 ERP]]

== Для користувачів ==

[[Початок роботи з K2 ERP]]

[[Хмара K2]]

[[Бухгалтерія K2 ERP]]

[[Управлінський облік K2 ERP]]

[[CRM K2 ERP]]

[[Складський облік K2 ERP]]

[[Інтернет-магазин K2 ERP]]

[[K2 VDoc]]

[[Галузеві рішення K2 ERP]]

[[Звіти та аналітика K2 ERP]]

[[Поширені питання K2 ERP]]

== Для програмістів ==

[[Розгортання системи K2 ERP Python для розробників]]

[[Архітектура K2 ERP]]

[[Встановлення K2 ERP]]

[[Розгортання K2 ERP]]

[[Створення модулів K2 ERP]]

[[База даних K2 ERP]]

[[API K2 ERP]]

[[Інтеграції K2 ERP]]

[[K2 CMS]]

[[Розробка веб-інтерфейсів K2]]

[[Бізнес-процеси K2 ERP]]

[[Права доступу K2 ERP]]

[[Рекомендації для розробників K2]]

[[Класи та команди K2 ERP Python]]

[[Стандарти UI K2 2025]]

== Атестаційні завдання по K2 ERP ==

[[Атестаційні завдання по K2 ERP]]

[[Регламент K2]]

== K2 ERP PHP ==

[[Практична робота в K2 ERP PHP]]

[[Інструкція по розгортанню K2 ERP PHP]]

[[Класи та команди K2 Cloud ERP PHP]]

== Робота в K2 ==
[[Налаштування WireGuard]]

== Довідник та модулі ==

* [[K2 CMS]]
* [[K2 VDoc (Електронний документообіг)]]
* [[Ліцензійна політика K2]]

== Навігація за категоріями ==
Усі статті бази знань автоматично групуються за категоріями:

* [[:Категорія:ERP-системи|ERP-системи]]
* [[:Категорія:Програмне забезпечення, розроблене в Україні|Українське ПЗ]]
* [[:Категорія:Програмне забезпечення для бізнесу|ПЗ для бізнесу]]

== Статті по IT ==

[[Цифрова деокупація та санкції в Україні]]

Атестаційні завдання K2 ERP/Інтернет-магазин

2026-04-28T21:43:53Z

R: Пененос з Гугл док.

'''Атестаційне завдання K2 ERP — Інтернет-магазин''' — практична задача для розробника K2 ERP, що передбачає створення модуля інтернет-магазину з управлінням товарами, категоріями, кошиком, замовленнями, оплатою, залишками, медіафайлами та адміністративним інтерфейсом.

== Назва ==
'''Модуль Інтернет-магазин: управління товарами, кошиком, замовленнями та оплатою'''.

== Реальний бізнес-контекст ==
Компанія хоче створити власний інтернет-магазин на базі K2 ERP, інтегрований із загальною ERP-структурою.

Модуль повинен забезпечувати:

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

== Основні завдання ==

=== 1. Структура довідників ===

==== Довідник «Категорії товарів» ====
Довідник категорій товарів повинен містити:

* назву категорії;
* батьківську категорію для побудови ієрархії;
* сортування;
* SEO-поля:
** URL;
** Title;
** Description.

==== Довідник «Товари» ====
Довідник товарів повинен містити:

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

=== 2. Фронтенд магазину для покупців ===

==== Каталог товарів ====
Каталог товарів повинен підтримувати:

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

==== Сторінка товару ====
Сторінка товару повинна містити:

* фото з можливістю збільшення;
* назву товару;
* опис;
* ціну;
* кнопку '''«Додати у кошик»'''.

==== Кошик ====
Кошик повинен підтримувати:

* перелік товарів у кошику;
* можливість змінити кількість товару;
* автоматичний перерахунок загальної суми;
* кнопку '''«Оформити замовлення»'''.

=== 3. Оформлення замовлення ===
Форма оформлення замовлення повинна містити:

* ім’я та прізвище покупця;
* телефон;
* email;
* адресу доставки;
* коментар до замовлення;
* вибір способу оплати:
** оплата при отриманні;
** оплата онлайн.

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

* WayForPay;
* LiqPay;
* Stripe;
* або іншої платіжної системи.

Після успішної оплати статус замовлення повинен змінюватися автоматично.

=== 5. Журнал замовлень в адмінці ===
Журнал замовлень повинен бути доступний в адміністративній частині.

==== Колонки журналу ====
У журналі мають бути такі колонки:

* номер замовлення;
* дата замовлення;
* покупець;
* сума;
* статус:
** нове;
** в обробці;
** відправлено;
** завершено;
** скасовано;
* тип оплати.

==== Функціональність журналу ====
Журнал замовлень має підтримувати:

* фільтрацію за статусом;
* фільтрацію за періодом;
* перегляд деталей замовлення;
* зміну статусу замовлення.

=== 6. Додаткові функції ===
Потрібно реалізувати:

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

=== 7. Бекенд-функціонал для адміністраторів ===
Адміністративний інтерфейс повинен підтримувати:

* додавання товарів через AJAX-інтерфейс;
* редагування товарів через AJAX-інтерфейс;
* видалення товарів через AJAX-інтерфейс;
* завантаження великої кількості товарів через імпорт CSV або Excel;
* управління категоріями без перезавантаження сторінки.

== Технічні вимоги ==
{| class="wikitable"
!Параметр
!Опис
|-
|Бекенд
|K2 ERP на Python або PHP
|-
|БД
|PostgreSQL або MySQL
|-
|Фронтенд
|HTML5, JavaScript, AJAX через Fetch або Axios
|-
|UI-компоненти
|DataTables, Select2, WYSIWYG-редактор для опису товару
|-
|Платіжні шлюзи
|WayForPay, LiqPay або Stripe
|-
|Медіа
|Завантаження зображень через FilePond або аналог
|}

== Критерії оцінки ==
{| class="wikitable"
!Критерій
!Бали
|-
|Реалізація довідника товарів і категорій
|20
|-
|Робота кошика і оформлення замовлення
|20
|-
|Інтеграція з платіжною системою
|20
|-
|Журнал замовлень і управління статусами
|20
|-
|Інтерактивність через AJAX
|10
|-
|Збереження структури і логіки бізнес-процесів
|10
|-
!Разом
!100
|}

== Примітка ==
Інтернет-магазин є обов’язковим модулем для багатьох бізнесів у 2025 році незалежно від розміру компанії.

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

== Очікуваний результат ==
У результаті виконання атестаційного завдання має бути створений модуль інтернет-магазину K2 ERP, який підтримує каталог товарів і категорій, сторінки товарів, кошик, оформлення замовлення, онлайн-оплату, журнал замовлень, управління статусами, email-сповіщення, облік залишків, акційні товари, імпорт CSV/Excel та AJAX-адміністрування.

== Рекомендовані сутності бази даних ==

* категорії товарів;
* товари;
* фото товарів;
* залишки товарів;
* склади;
* кошики;
* рядки кошика;
* замовлення;
* рядки замовлення;
* покупці;
* способи оплати;
* платежі;
* статуси замовлень;
* історія зміни статусів;
* email-сповіщення;
* імпорт товарів;
* SEO-налаштування.

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

* [[K2 Cloud ERP|K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Інтернет-магазин]]
* [[Каталог товарів]]
* [[Кошик]]
* [[Онлайн-оплата]]
* [[WayForPay]]
* [[LiqPay]]
* [[Stripe]]
* [[Складський облік]]

Атестаційні завдання K2 ERP/CMS

2026-04-28T21:41:38Z

R: Перенос з Гугл док.

'''Атестаційне завдання K2 ERP — CMS''' — практична задача для розробника K2 ERP, що передбачає створення модуля управління контентом сайту або корпоративного порталу: сторінками, новинами, статтями, оголошеннями, медіафайлами, багатомовністю, публікацією та історією змін.

== Назва ==
'''Модуль CMS: Управління контентом сайту і корпоративного порталу'''.

== Реальний бізнес-контекст ==
Компанія має публічний сайт або внутрішній корпоративний портал. Потрібно надати менеджерам можливість самостійно керувати контентом без залучення розробників.

Користувачі повинні мати можливість:

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

== Основні завдання ==

=== 1. Структура довідників ===

==== Довідник «Категорії контенту» ====
Довідник категорій контенту повинен містити:

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

==== Довідник «Мови» ====
Довідник мов повинен містити:

* назву мови, наприклад українська, англійська, польська;
* код мови, наприклад <code>uk</code>, <code>en</code>, <code>pl</code>.

=== 2. Журнал «Матеріали» ===
Журнал матеріалів повинен відображати всі одиниці контенту сайту або корпоративного порталу.

==== Колонки журналу ====
У журналі мають бути такі колонки:

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

==== Функціональність журналу ====
Журнал має підтримувати:

* пошук по заголовку;
* пошук по автору;
* пошук по категорії;
* фільтрацію за статусом;
* фільтрацію за мовою.

=== 3. Форма створення матеріалу ===

==== Основна інформація ====
Форма створення або редагування матеріалу повинна містити:

* заголовок;
* короткий опис або анонс;
* повний текст матеріалу через WYSIWYG-редактор;
* категорію з вибором із довідника через AJAX;
* мову;
* зображення-прев’ю із завантаженням через медіабібліотеку;
* статус:
** чернетка;
** опубліковано.

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

* теги для SEO;
* URL-адресу, яка генерується автоматично або вказується вручну.

=== 4. Управління медіафайлами ===
Модуль має містити медіабібліотеку з каталогами.

Потрібно реалізувати:

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

=== 5. Мультимовність ===
Кожен матеріал може мати окремі версії різними мовами.

Потрібно реалізувати механізм прив’язки матеріалів між мовами.

Приклад:

* '''Про нас''' українською мовою → '''About us''' англійською мовою.

=== 6. Публікація на сайті ===
Після публікації матеріал автоматично відображається на сайті за налаштованим шаблоном.

URL повинен формуватися за правилом:<pre>
/<код мови>/<категорія>/<url матеріалу>/
</pre>Приклад URL:<pre>
/en/news/open-new-office/
</pre>

=== 7. Специфіка функціоналу ===
Модуль повинен підтримувати:

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

=== 8. Модульні блоки контенту, опціонально ===
Рівень Advanced передбачає можливість створення окремих блоків контенту для розміщення в різних частинах сайту.

Приклади блоків:

* банер;
* акційний блок;
* слайдер.

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

== Технічні вимоги ==
{| class="wikitable"
!Параметр
!Опис
|-
|Бекенд
|K2 ERP на Python або PHP
|-
|БД
|PostgreSQL або MySQL
|-
|Фронтенд
|HTML5, JavaScript, AJAX через Axios або Fetch API
|-
|UI-компоненти
|DataTables, Select2, WYSIWYG-редактор TinyMCE або CKEditor
|-
|Медіауправління
|Завантаження файлів через FilePond або Dropzone.js
|-
|Друк
|Немає необхідності
|}

== Критерії оцінки ==
{| class="wikitable"
!Критерій
!Бали
|-
|Реалізація журналу матеріалів
|20
|-
|Форма створення та редагування матеріалу
|20
|-
|Робота медіабібліотеки
|20
|-
|Підтримка багатомовності
|20
|-
|Інтерактивність через AJAX
|10
|-
|Управління статусами публікації
|10
|-
!Разом
!100
|}

== Примітка ==
Цей модуль потрібен практично кожній компанії, що має сайт або внутрішній портал: IT-компаніям, маркетинг-агентствам, торговим мережам, освітнім установам і банкам.

== Очікуваний результат ==
У результаті виконання атестаційного завдання має бути створений CMS-модуль K2 ERP, який підтримує довідники категорій і мов, журнал матеріалів, форму створення та редагування контенту, WYSIWYG-редактор, медіабібліотеку, багатомовність, автоматичну публікацію, SEO-поля, історію змін, AJAX-інтерактив і, за потреби, модульні блоки контенту.

== Рекомендовані сутності бази даних ==

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

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

* [[K2 Cloud ERP|K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[CMS]]
* [[Контент]]
* [[Медіабібліотека]]
* [[Багатомовність]]
* [[WYSIWYG]]
* [[TinyMCE]]
* [[CKEditor]]

Атестаційні завдання K2 ERP/CRM

2026-04-28T21:39:15Z

R: Перенос з Гугл док.

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

== Назва ==
'''Модуль CRM: Управління лідами, клієнтами, угодами і комунікаціями'''.

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

Потрібно автоматизувати процес:

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

== Основні завдання ==

=== 1. Структура довідників ===

==== Довідник «Статуси лідів» ====
Довідник статусів лідів описує етапи проходження потенційного клієнта через воронку продажів.

Приклад послідовності статусів:

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

==== Довідник «Джерела лідів» ====
Довідник джерел лідів описує, звідки прийшов потенційний клієнт.

Приклади джерел:

* вебсайт;
* рекомендації;
* реклама;
* холодний дзвінок;
* захід.

=== 2. Журнал «Ліди» ===
Журнал лідів повинен відображати потенційних клієнтів і поточний стан роботи з ними.

==== Колонки журналу ====
У журналі мають бути такі колонки:

* ПІБ або назва компанії;
* джерело ліда;
* дата створення;
* відповідальний менеджер;
* поточний статус;
* ймовірність успіху, %;
* очікувана сума угоди.

==== Функціональність журналу ====
Журнал лідів має підтримувати:

* пошук по імені;
* пошук по телефону;
* пошук по email;
* фільтрацію за статусами;
* фільтрацію за менеджерами;
* фільтрацію за джерелами.

=== 3. Форма створення ліда ===

==== Основна інформація ====
Форма створення ліда повинна містити:

* ПІБ або назву компанії;
* телефон;
* email;
* джерело ліда з вибором через AJAX;
* примітки;
* відповідального менеджера з вибором зі списку користувачів.

==== Важливий функціонал ====
Потрібно передбачити:

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

=== 4. Журнал «Клієнти» ===
Журнал клієнтів повинен містити всі компанії або фізичних осіб, які стали клієнтами.

==== Колонки журналу ====

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

=== 5. Журнал «Угоди» ===
Журнал угод повинен відображати комерційні можливості та замовлення.

==== Колонки журналу ====

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

==== Функціональність журналу угод ====
Журнал угод має підтримувати:

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

=== 6. Журнал «Комунікації» ===
Журнал комунікацій зберігає історію контактів із лідами та клієнтами.

==== Типи подій ====

* дзвінок:
** вхідний;
** вихідний;
* email;
* зустріч;
* коментар.

==== Колонки журналу ====

* клієнт або лід;
* тип події;
* дата;
* опис;
* відповідальний.

==== Функціональність журналу комунікацій ====
Потрібно реалізувати:

* додавання події вручну;
* прив’язку події до ліда;
* прив’язку події до клієнта.

=== 7. Воронка продажів ===
Воронка продажів повинна візуально показувати проходження лідів та угод по етапах.

==== Графік воронки ====
На графіку потрібно показати:

* кількість лідів на кожній стадії;
* конверсії між стадіями;
* втрати на кожному етапі.

Воронку можна реалізувати через просту діаграму, наприклад з використанням бібліотеки Chart.js.

=== 8. Звітність ===

==== Звіт «Ліди за період» ====
Звіт має показувати:

* кількість нових лідів;
* конверсії в клієнтів;
* джерела лідів.

==== Звіт «Ефективність менеджерів» ====
Звіт має показувати:

* кількість лідів на менеджера;
* кількість успішних угод;
* середню суму угоди.

=== 9. Додаткові умови ===
Модуль повинен підтримувати:

* виконання всіх операцій через AJAX:
** створення ліда;
** оновлення статусу;
** додавання комунікацій;
* миттєве оновлення статусу ліда без перезавантаження сторінки;
* автоматичні нагадування менеджерам про заплановані події:
** зустрічі;
** дзвінки;
* нотифікації при переході ліда у стадію '''«Угода»'''.

== Технічні вимоги ==
{| class="wikitable"
!Параметр
!Опис
|-
|Бекенд
|K2 ERP на Python або PHP
|-
|БД
|PostgreSQL або MySQL
|-
|Фронтенд
|HTML5, JavaScript, AJAX через Axios або Fetch API
|-
|UI-компоненти
|DataTables, Select2, Chart.js
|-
|Нотифікації
|Email або внутрішні сповіщення через WebSocket, опціонально
|-
|Друк
|Можливість експорту списків в Excel або PDF
|}

== Критерії оцінки ==
{| class="wikitable"
!Критерій
!Бали
|-
|Реалізація журналів лідів, угод і клієнтів
|20
|-
|Конверсія ліда у клієнта та угоду
|20
|-
|Управління комунікаціями
|20
|-
|Воронка продажів і аналітика
|20
|-
|Інтерактивність через AJAX
|10
|-
|Загальна якість структури коду і БД
|10
|-
!Разом
!100
|}

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

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

== Рекомендовані сутності бази даних ==

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

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

* [[K2 Cloud ERP|K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[CRM]]
* [[Ліди]]
* [[Клієнти]]
* [[Угоди]]
* [[Воронка продажів]]
* [[Chart.js]]

Атестаційні завдання K2 ERP/TMS

2026-04-28T21:36:38Z

R: Перенос з Гугл док.

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

== Назва ==
'''Модуль управління транспортними перевезеннями (TMS)'''.

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

У системі потрібно вести облік:

* замовлень на доставку;
* автомобілів та водіїв;
* планування маршрутів;
* витрат на перевезення;
* статусу виконання доставки.

Менеджери повинні:

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

== Основні завдання ==

=== 1. Структура довідників ===

==== Довідник «Транспортні засоби» ====
Довідник транспортних засобів повинен містити:

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

==== Довідник «Водії» ====
Довідник водіїв повинен містити:

* ПІБ;
* телефон;
* водійське посвідчення;
* прив’язку до транспортного засобу.

=== 2. Журнал «Замовлення на перевезення» ===
Журнал замовлень на перевезення повинен відображати всі доставки та їхній поточний стан.

==== Колонки журналу ====
У журналі мають бути такі колонки:

* номер замовлення;
* дата створення;
* замовник, контрагент;
* пункт відправлення;
* пункт призначення;
* дата та час завантаження;
* дата та час доставки;
* статус замовлення:
** нове;
** в дорозі;
** доставлено;
** скасовано.

==== Функціональність журналу ====
Журнал має підтримувати:

* пошук за номером замовлення;
* пошук за замовником;
* пошук за датами;
* фільтрацію за статусами.

=== 3. Форма створення замовлення на перевезення ===

==== Заголовок замовлення ====
Форма замовлення повинна містити:

* замовника, контрагента через AJAX-пошук;
* контактну особу;
* пункт відправлення — пошук адреси або ручне введення;
* пункт призначення;
* планову дату завантаження;
* планову дату доставки;
* примітки.

==== Вибір транспортного засобу ====
Потрібно реалізувати:

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

==== Вибір водія ====
Система повинна пропонувати водія, який закріплений за машиною, або дозволяти вибрати іншого водія.

=== 4. Операції зі статусами ===
Потрібно реалізувати такі статуси замовлення:

* '''Нове''' — замовлення створене;
* '''Призначено''' — обрано машину та водія;
* '''В дорозі''' — машина вирушила, статус встановлюється кнопкою '''«Почати доставку»''';
* '''Доставлено''' — машина прибула, статус встановлюється кнопкою '''«Завершити доставку»''';
* '''Скасовано''' — замовлення скасоване.

=== 5. Додаткові розрахунки ===
Вартість доставки розраховується за тарифами.

Можливі варіанти тарифікації:

* фіксована ціна за доставку;
* ціна за кілометр з автоматичним розрахунком відстані через Google Maps API;
* ціна за кілометр із ручним введенням відстані.

==== Формула розрахунку вартості ====
<pre>
Вартість = Відстань × Тариф за 1 км + Додаткові витрати
</pre>До додаткових витрат можуть належати:

* очікування;
* навантаження;
* інші витрати, пов’язані з перевезенням.

=== 6. Шаблони документів ===

==== Транспортна накладна ====
У транспортній накладній потрібно виводити:

* номер замовлення;
* машину;
* водія;
* замовника;
* пункт відправлення;
* пункт призначення;
* список товарів, якщо потрібен;
* підписи водія і представника замовника.

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

=== 7. Звітність ===

==== Звіт «Перевезення за період» ====
Звіт має показувати:

* кількість замовлень;
* суми за перевезення;
* витрати по транспорту;
* коефіцієнт використання транспорту.

==== Звіт «Рентабельність транспорту» ====
Звіт має показувати:

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

=== 8. Специфіка функціоналу ===
Модуль повинен підтримувати:

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

== Технічні вимоги ==
{| class="wikitable"
!Параметр
!Опис
|-
|Бекенд
|K2 ERP на Python або PHP
|-
|БД
|PostgreSQL або MySQL
|-
|Фронтенд
|HTML5, JavaScript, AJAX через Fetch API або Axios
|-
|UI-компоненти
|DataTables, Select2 для автопошуку
|-
|Карти, опціонально
|Google Maps API або OpenStreetMap для розрахунку відстаней
|-
|Друк
|Stimulsoft Reports або внутрішній PDF-генератор
|}

== Критерії оцінки ==
{| class="wikitable"
!Критерій
!Бали
|-
|Реалізація журналу замовлень
|20
|-
|Форма замовлення з вибором машини і водія
|20
|-
|Логіка статусів доставки
|20
|-
|Розрахунок вартості перевезення
|15
|-
|Формування друкованих документів
|15
|-
|Звітність і аналітика
|10
|-
!Разом
!100
|}

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

Правильна реалізація TMS-модуля дозволяє контролювати весь ланцюжок доставки та оптимізувати витрати на транспорт.

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

== Рекомендовані сутності бази даних ==

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

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

* [[K2 Cloud ERP|K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[TMS]]
* [[Логістика]]
* [[Транспортна накладна]]
* [[Акт виконаних робіт]]
* [[OpenStreetMap]]
* [[Google Maps API]]

Атестаційні завдання K2 ERP/Управління договорами

2026-04-28T21:34:30Z

R: Перенос з Гугл док

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

== Назва ==
'''Модуль управління договорами компанії'''.

== Реалістичний опис бізнес-процесу ==
Компанія має велику кількість договорів із клієнтами та підрядниками. Для нормальної роботи потрібно:

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

== Основні завдання ==

=== 1. Структура довідників ===

==== Довідник «Контрагенти» ====
Довідник контрагентів повинен містити:

* назву компанії;
* тип контрагента:
** клієнт;
** постачальник;
* ЄДРПОУ або ІПН;
* контактну особу;
* email для повідомлень.

==== Довідник «Типи договорів» ====
Довідник типів договорів повинен містити:

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

=== 2. Журнал «Договори» ===
Журнал договорів повинен відображати всі договори компанії.

==== Колонки журналу ====
У журналі мають бути такі колонки:

* номер договору;
* контрагент;
* тип договору;
* дата укладання;
* дата початку;
* дата закінчення;
* статус договору:
** діючий;
** закінчений;
** пролонгований;
** розірваний;
* сума договору;
* періодичність оплат:
** одноразово;
** щомісяця;
** щокварталу.

==== Функціональність журналу ====
Журнал договорів має підтримувати:

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

=== 3. Форма створення договору ===

==== Заголовок договору ====
Форма створення договору повинна містити:

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

==== Додаткові дані договору ====
У формі договору потрібно передбачити:

* прикріплення файлу скану підписаного договору у форматі PDF;
* поле приміток у форматі textarea.

=== 4. Автоматичне нарахування рахунків по договорах ===
На початку кожного місяця система має перевіряти всі діючі договори з періодичністю '''«Щомісяця»'''.

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

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

=== 5. Сповіщення про закінчення договору ===
За 30 днів до закінчення договору система має створити нагадування.

Нагадування повинно:

* відображатися у списку '''«Договори, що закінчуються»''' у панелі керівника;
* надсилатися email відповідальному менеджеру.

=== 6. Шаблони друку ===

==== Шаблон договору ====
Шаблон договору повинен формуватися у форматі DOCX або PDF.

У шаблоні потрібно підтримати підстановку змінних:

* <code>{{CONTRACT_NUMBER}}</code> — номер договору;
* <code>{{CLIENT_NAME}}</code> — назва клієнта;
* <code>{{START_DATE}}</code> — дата початку;
* <code>{{END_DATE}}</code> — дата закінчення;
* <code>{{AMOUNT}}</code> — сума.

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

==== Шаблон рахунку ====
Шаблон рахунку повинен містити:

* контрагента;
* суму;
* дату виставлення;
* підпис директора та бухгалтера.

=== 7. Звітність ===

==== Звіт «Договори за період» ====
Звіт повинен показувати договори за вибраний період:

* укладені;
* закінчені;
* пролонговані.

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

==== Звіт «Очікувані платежі» ====
Звіт повинен показувати суми платежів по діючих договорах на майбутні місяці.

=== 8. Функціональні вимоги ===
Модуль повинен підтримувати:

* роботу без перезавантаження сторінок через AJAX;
* збереження чернеток договорів;
* автоматичний підрахунок сум платежів;
* лог змін із зазначенням, хто і коли редагував договір.

== Технічні вимоги ==
{| class="wikitable"
!Параметр
!Опис
|-
|Бекенд
|K2 ERP на Python або PHP
|-
|БД
|PostgreSQL або MySQL
|-
|Фронтенд
|HTML5, JavaScript, AJAX
|-
|UI-компоненти
|DataTables, Select2 для вибору контрагентів
|-
|Друк
|Stimulsoft або внутрішній генератор PDF
|}

== Критерії оцінки ==
{| class="wikitable"
!Критерій
!Бали
|-
|Реалізація журналу договорів
|15
|-
|Форма створення договору та розрахунки
|20
|-
|Автоматичне створення рахунків
|20
|-
|Нотифікації про закінчення договорів
|15
|-
|Формування друкованих шаблонів
|10
|-
|Якість структури БД і коду
|20
|-
!Разом
!100
|}

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

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

== Рекомендовані сутності бази даних ==

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

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

* [[K2 Cloud ERP|K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Управління договорами]]
* [[Контрагенти]]
* [[Рахунок на оплату]]
* [[Акт виконаних робіт]]
* [[Автоматичне нарахування]]
* [[Пролонгація договору]]

Атестаційні завдання K2 ERP/Оренда

2026-04-28T21:32:03Z

R: Перенос з Гугл док

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

== Назва ==
'''Модуль обліку виставлення рахунків орендарям за орендовані площі та комунальні послуги в ТРЦ'''.

== Опис ситуації ==
Власник ТРЦ має десятки орендарів: магазини, кафе, сервісні компанії. Кожного місяця потрібно автоматизовано виконувати нарахування та виставлення рахунків.

Щомісячно необхідно:

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

Система повинна:

* автоматично розраховувати суми;
* дозволяти вручну коригувати дані;
* виставляти рахунки;
* формувати акти виконаних робіт;
* друкувати документи та надсилати їх орендарям;
* вести аналітику по оплатах і заборгованості.

== Завдання ==

=== 1. Структура довідників ===

==== Довідник «Орендарі» ====
Довідник орендарів повинен містити:

* назву компанії;
* договір оренди:
** номер договору;
** дату початку;
** дату закінчення;
* контактних осіб;
* email для виставлення рахунків.

==== Довідник «Орендовані площі» ====
Довідник орендованих площ повинен містити:

* прив’язку до орендаря;
* номер приміщення;
* метраж, м²;
* ставку оренди за м², грн/м²;
* додаткові примітки.

==== Довідник «Послуги» ====
Довідник послуг повинен містити типи послуг:

* електроенергія;
* вода;
* опалення;
* кондиціонування;
* прибиральні послуги.

Для кожної послуги потрібно передбачити тип розрахунку:

* за показниками лічильника;
* за нормативом на 1 м²;
* фіксована сума.

=== 2. Журнал документів «Рахунки на оплату» ===
Журнал документів має відображати всі рахунки, виставлені орендарям.

==== Колонки журналу ====
У журналі повинні бути такі колонки:

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

==== Функціональність журналу ====
Журнал має підтримувати:

* створення рахунку;
* редагування рахунку;
* проведення рахунку;
* друк рахунку;
* фільтрацію по орендарю;
* фільтрацію по статусу;
* фільтрацію по періоду.

=== 3. Форма створення рахунку ===

==== Заголовок документа ====
Заголовок рахунку повинен містити:

* орендаря з пошуком у довіднику через AJAX;
* період нарахування;
* дату виставлення.

==== Таблична частина ====
Таблична частина повинна містити орендовані площі та послуги.
{| class="wikitable"
!№
!Назва послуги
!Одиниця виміру
!Кількість
!Ціна за одиницю
!Сума
|-
|1
|Оренда приміщення
|м²
|120
|300
|36 000
|-
|2
|Електроенергія
|кВт·год
|450
|5
|2 250
|-
|3
|Водопостачання
|м³
|30
|20
|600
|-
|4
|Опалення
|м²
|120
|30
|3 600
|-
! colspan="5" |Підсумкова сума
!42 450 грн
|}

=== 4. Розрахунки в системі ===

==== Оренда ====
Сума оренди розраховується за формулою:<pre>
Сума оренди = Метраж × Ставка за м²
</pre>

==== Електроенергія ====
Якщо є лічильник:<pre>
Сума = Спожиті кВт·год × Тариф
</pre>Якщо лічильника немає:<pre>
Сума = Норма споживання × Метраж × Тариф
</pre>

==== Водопостачання ====
Водопостачання розраховується за лічильником або за нормативом.

==== Опалення і кондиціонування ====
Опалення та кондиціонування зазвичай розраховуються пропорційно площі.

=== 5. Інтерфейс користувача ===
Інтерфейс користувача повинен підтримувати:

* додавання рядків послуг у таблиці через AJAX без перезавантаження сторінки;
* редагування кількості або тарифу прямо в таблиці через inline edit;
* автоматичний перерахунок підсумкової суми при зміні кількості або тарифу;
* кнопку '''«Зберегти чернетку»''';
* кнопку '''«Виставити рахунок»'''.

=== 6. Друк рахунку ===
Шаблон рахунку повинен містити:

* назву орендаря;
* реквізити ТРЦ;
* таблицю послуг;
* підсумкову суму;
* підпис відповідальної особи ТРЦ.

Формат друку:

* PDF;
* або HTML-друк для подальшої відправки.

=== 7. Звітність ===

==== Звіт «Реєстр виставлених рахунків» ====
Звіт має містити:

* список рахунків із підсумками за періодами;
* суми виставлені;
* суми сплачені;
* борги.

==== Звіт «Баланс орендарів» ====
Звіт має містити:

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

=== 8. Додаткові вимоги ===

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

== Технічні вимоги ==
{| class="wikitable"
!Параметр
!Опис
|-
|Бекенд
|PHP 8 або Python 3
|-
|Фреймворк
|K2 Core або Symfony Slim K2
|-
|БД
|PostgreSQL або MySQL
|-
|Фронтенд
|HTML5, JavaScript, AJAX через Fetch або Axios
|-
|UI-компоненти
|DataTables, Select2 для довідників
|-
|Друк
|Stimulsoft Reports або внутрішній PDF-генератор
|}

== Критерії оцінки ==
{| class="wikitable"
!Критерій
!Бали
|-
|Коректність розрахунків
|20
|-
|Зручність введення даних, UX
|20
|-
|Реалізація AJAX-інтерактиву
|20
|-
|Якість структури БД і коду
|20
|-
|Формування друкованих форм
|10
|-
|Формування звітів
|10
|-
!Разом
!100
|}

== Примітка ==
Це прикладна задача, яку реально використовують власники ТРЦ, бізнес-центри, склади, готелі та інші об’єкти нерухомості.

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

== Додаткові зауваження ==
Співробітники ТРЦ знімають показники лічильників, як правило, один раз на місяць. Усі зняті показники потрібно зберігати в системі.

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

=== Таблиця показників лічильників ===
{| class="wikitable"
!№
!Кімната / Приміщення
!№ лічильника (ID)
!Тип лічильника
!Одиниці
!Значення на початок періоду
!Значення на кінець періоду
!Різниця (витрата)
!Примітки
|-
|1
|
|
|
|
|
|
|
|
|-
|2
|
|
|
|
|
|
|
|
|-
|3
|
|
|
|
|
|
|
|
|-
|49
|
|
|
|
|
|
|
|
|-
|50
|
|
|
|
|
|
|
|
|-
!Разом
!
!
!
!
!
!
!0,00
!
|}
Нарахування робляться по події натисканням кнопки та формуються на певну дату. Усі нарахування потрібно зберігати в системі.

Приклад Excel-файлу нарахувань за 1 місяць:

* https://drive.google.com/file/d/1poPAq1mFiPM_8wVZ3WU3ipPeTkSSISmq/view?usp=drive_link

З таблиці нарахувань повинні виставлятись рахунки:

* по певному нарахуванню;
* по певному контрагенту;
* або по всіх нарахуваннях одразу.

== Очікуваний результат ==
У результаті виконання атестаційного завдання має бути створений модуль K2 ERP для обліку оренди та комунальних послуг у ТРЦ, який підтримує довідники орендарів, площ і послуг, журнал рахунків, форму рахунку з AJAX-інтерактивом, розрахунки за лічильниками і нормативами, друк документів, звітність, контроль оплат, боргів і масове завантаження показників з Excel.

== Рекомендовані сутності бази даних ==

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

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

* [[K2 Cloud ERP|K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Оренда]]
* [[Комунальні послуги]]
* [[ТРЦ]]
* [[Рахунок на оплату]]
* [[Акт виконаних робіт]]
* [[Баланс орендарів]]

Атестаційні завдання K2 ERP/WMS

2026-04-28T21:29:02Z

R: Виправлено УРЛ в кінці

'''Атестаційне завдання K2 ERP — Оптова торгівля, FIFO та документообіг''' — практична задача для перевірки навичок розробника у побудові веб-рішення для обліку закупівель, продажів, послуг, партійного обліку, списання собівартості за FIFO та формування звітів.

__TOC__

== Текст задачі ==

Компанія займається оптовою торгівлею. Надходження товарів відображається документом '''«Прибуткова накладна»''', продаж — документом '''«Видаткова накладна»'''. Крім продажу товару можуть надаватися додаткові послуги, наприклад доставка. І послуги, і товари зазначаються в одній табличній частині.

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

З документа '''«Рахунок-фактура»''' створюється документ '''«Видаткова накладна»'''. На основі видаткової накладної створюється '''«Податкова накладна»'''.

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

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

Необхідно побудувати звіти:

* продаж товарів за період;
* прибутки за період;
* залишки товару на зазначену дату.

== Документообіг ==

Основний ланцюжок документів:

# '''Замовлення''';
# '''Рахунок-фактура''';
# '''Видаткова накладна''';
# '''Податкова накладна'''.

Документи надходження оформлюються через '''прибуткову накладну'''. Документи продажу оформлюються через '''видаткову накладну'''.

== Виконання задачі ==

# Побудувати структуру бази даних у графічному вигляді та продемонструвати її.
# На основі графічної структури бази даних створити SQL для створення таблиць.
# Для вирішення задачі допускаються такі бази даних:
#* MySQL;
#* PostgreSQL;
#* SQLite.
# Веб-рішення має бути побудоване на фреймворку з відкритим вихідним кодом.
# При створенні сторінок документів усе має працювати без перезавантаження сторінок.
# Виконану роботу потрібно продемонструвати у вигляді веб-сторінки, доступної з інтернет-URL.
# При виконанні задачі потрібно зафіксувати час її виконання та повідомити його при здачі.
# При виконанні завдання потрібно використовувати об’єктно-орієнтований підхід.

== Пояснення до задачі ==

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

=== Прибуткова накладна ===

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

Зазвичай це реєстр документів, у якому можна знайти раніше створені документи, а також створити новий документ.

==== Реєстр прибуткових накладних ====

Реєстр повинен дозволяти переглядати, шукати та відкривати створені прибуткові накладні.

==== Форма прибуткової накладної ====

При відкритті або створенні прибуткової накладної документ повинен містити шапку документа та табличну частину.

У табличній частині мають бути товари та послуги.

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

Послуги мають обліковуватися в тій самій табличній частині, що і товари.

==== Друкована форма прибуткової накладної ====

Документ повинен мати друковану форму.

=== Реалізація товарів та послуг: видаткова накладна ===

Продаж товарів і послуг оформлюється документом '''«Видаткова накладна»'''.

==== Реєстр видаткових накладних ====

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

==== Реалізація послуг ====

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

==== Друкована форма видаткової накладної ====

Видаткова накладна повинна мати друковану форму.

== Звіт «Залишки по складу» ==

Потрібно реалізувати звіт '''«Залишки по складу»'''.

Звіт повинен показувати залишки товарів на складі на зазначену дату.

== Вимоги до вибору рядків у видатковій накладній ==

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

Якщо товару недостатньо, система повинна:

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

== FIFO ==

'''FIFO''' — метод списання, за яким фактично списується той товар, який першим надійшов.

Посилання для довідки:

* https://uk.wikipedia.org/wiki/Алгоритм_заміщення_комірок_пам%27яті_FIFO

У межах задачі FIFO використовується для списання собівартості товару за партіями.

== Очікувані звіти ==

Необхідно побудувати такі звіти:

=== Продаж товарів за період ===

Звіт має показувати реалізацію товарів за вибраний період.

=== Прибутки за період ===

Звіт має показувати прибуток за вибраний період з урахуванням собівартості, списаної за FIFO.

=== Залишки товару на дату ===

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

== Цілі теста ==

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

== Очікуваний результат ==

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

== Рекомендовані сутності бази даних ==

Для реалізації задачі доцільно передбачити такі сутності:

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

== Критерії перевірки ==

{| class="wikitable"
! Напрям перевірки !! Що перевіряється
|-
| Структура БД || Повнота моделі даних, наявність партій, документів, рядків, залишків і рухів
|-
| SQL || Коректність SQL-скриптів для MySQL, PostgreSQL або SQLite
|-
| Веб-рішення || Робота сторінок без перезавантаження
|-
| AJAX || Створення, редагування, проведення документів через AJAX
|-
| FIFO || Коректне списання собівартості за партіями
|-
| Контроль залишків || Заборона проведення при нестачі товару
|-
| Звіти || Продажі, прибутки, залишки на дату
|-
| ООП || Об’єктно-орієнтована структура коду
|-
| Демонстрація || Доступний веб-URL і зафіксований час виконання
|}

== Ілюстрації з документа ==

<gallery mode="packed" heights="180">
K2_Attestation_Wholesale_FIFO_01.png|Приблизний вигляд реєстру прибуткових накладних|посилання=Файл:K2_Attestation_Wholesale_FIFO_01.png
K2_Attestation_Wholesale_FIFO_02.png|Форма прибуткової накладної|посилання=Файл:K2_Attestation_Wholesale_FIFO_02.png
K2_Attestation_Wholesale_FIFO_03.png|Послуги у прибутковій накладній|посилання=Файл:K2_Attestation_Wholesale_FIFO_03.png
K2_Attestation_Wholesale_FIFO_04.png|Друкована форма прибуткової накладної|посилання=Файл:K2_Attestation_Wholesale_FIFO_04.png
K2_Attestation_Wholesale_FIFO_05.png|Реєстр видаткових накладних|посилання=Файл:K2_Attestation_Wholesale_FIFO_05.png
K2_Attestation_Wholesale_FIFO_06.png|Реалізація послуг у видатковій накладній|посилання=Файл:K2_Attestation_Wholesale_FIFO_06.png
K2_Attestation_Wholesale_FIFO_07.png|Друкована форма видаткової накладної|посилання=Файл:K2_Attestation_Wholesale_FIFO_07.png
K2_Attestation_Wholesale_FIFO_08.png|Звіт «Залишки по складу»|посилання=Файл:K2_Attestation_Wholesale_FIFO_08.png
K2_Attestation_Wholesale_FIFO_09.png|Ілюстрація до атестаційного завдання|посилання=Файл:K2_Attestation_Wholesale_FIFO_09.png
K2_Attestation_Wholesale_FIFO_10.png|Ілюстрація до атестаційного завдання|посилання=Файл:K2_Attestation_Wholesale_FIFO_10.png
</gallery>

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

* [[K2 Cloud ERP|K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Оптова торгівля]]
* [[FIFO]]
* [[Складський облік]]
* [[Прибуткова накладна]]
* [[Видаткова накладна]]
* [[Звіт залишків по складу]]

Атестаційні завдання K2 ERP/WMS

2026-04-28T21:28:26Z

R: Перенос з Гугл док.

Атестаційні завдання K2 ERP/WMS

2026-04-28T21:27:30Z

R: Створена сторінка: {{Картка документації K2 | назва = Атестаційне завдання K2 Cloud ERP — Оптова торгівля, FIFO та документообіг | система = K2 Cloud ERP | розділ = Оптова торгівля | тип = Атестаційне завдання для розробника }} '''Атестаційне завдання K2 Cloud ERP — Оптова торгівля, FIFO та докумен...

{{Картка документації K2
| назва = Атестаційне завдання K2 Cloud ERP — Оптова торгівля, FIFO та документообіг
| система = K2 Cloud ERP
| розділ = Оптова торгівля
| тип = Атестаційне завдання для розробника
}}

'''Атестаційне завдання K2 Cloud ERP — Оптова торгівля, FIFO та документообіг''' — практична задача для перевірки навичок розробника у побудові веб-рішення для обліку закупівель, продажів, послуг, партійного обліку, списання собівартості за FIFO та формування звітів.

__TOC__

== Текст задачі ==

Компанія займається оптовою торгівлею. Надходження товарів відображається документом '''«Прибуткова накладна»''', продаж — документом '''«Видаткова накладна»'''. Крім продажу товару можуть надаватися додаткові послуги, наприклад доставка. І послуги, і товари зазначаються в одній табличній частині.

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

З документа '''«Рахунок-фактура»''' створюється документ '''«Видаткова накладна»'''. На основі видаткової накладної створюється '''«Податкова накладна»'''.

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

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

Необхідно побудувати звіти:

* продаж товарів за період;
* прибутки за період;
* залишки товару на зазначену дату.

== Документообіг ==

Основний ланцюжок документів:

# '''Замовлення''';
# '''Рахунок-фактура''';
# '''Видаткова накладна''';
# '''Податкова накладна'''.

Документи надходження оформлюються через '''прибуткову накладну'''. Документи продажу оформлюються через '''видаткову накладну'''.

== Виконання задачі ==

# Побудувати структуру бази даних у графічному вигляді та продемонструвати її.
# На основі графічної структури бази даних створити SQL для створення таблиць.
# Для вирішення задачі допускаються такі бази даних:
#* MySQL;
#* PostgreSQL;
#* SQLite.
# Веб-рішення має бути побудоване на фреймворку з відкритим вихідним кодом.
# При створенні сторінок документів усе має працювати без перезавантаження сторінок.
# Виконану роботу потрібно продемонструвати у вигляді веб-сторінки, доступної з інтернет-URL.
# При виконанні задачі потрібно зафіксувати час її виконання та повідомити його при здачі.
# При виконанні завдання потрібно використовувати об’єктно-орієнтований підхід.

== Пояснення до задачі ==

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

=== Прибуткова накладна ===

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

Зазвичай це реєстр документів, у якому можна знайти раніше створені документи, а також створити новий документ.

==== Реєстр прибуткових накладних ====

Реєстр повинен дозволяти переглядати, шукати та відкривати створені прибуткові накладні.

==== Форма прибуткової накладної ====

При відкритті або створенні прибуткової накладної документ повинен містити шапку документа та табличну частину.

У табличній частині мають бути товари та послуги.

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

Послуги мають обліковуватися в тій самій табличній частині, що і товари.

==== Друкована форма прибуткової накладної ====

Документ повинен мати друковану форму.

=== Реалізація товарів та послуг: видаткова накладна ===

Продаж товарів і послуг оформлюється документом '''«Видаткова накладна»'''.

==== Реєстр видаткових накладних ====

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

==== Реалізація послуг ====

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

==== Друкована форма видаткової накладної ====

Видаткова накладна повинна мати друковану форму.

== Звіт «Залишки по складу» ==

Потрібно реалізувати звіт '''«Залишки по складу»'''.

Звіт повинен показувати залишки товарів на складі на зазначену дату.

== Вимоги до вибору рядків у видатковій накладній ==

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

Якщо товару недостатньо, система повинна:

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

== FIFO ==

'''FIFO''' — метод списання, за яким фактично списується той товар, який першим надійшов.

Посилання для довідки:

* https://uk.wikipedia.org/wiki/Алгоритм_заміщення_комірок_пам%27яті_FIFO

У межах задачі FIFO використовується для списання собівартості товару за партіями.

== Очікувані звіти ==

Необхідно побудувати такі звіти:

=== Продаж товарів за період ===

Звіт має показувати реалізацію товарів за вибраний період.

=== Прибутки за період ===

Звіт має показувати прибуток за вибраний період з урахуванням собівартості, списаної за FIFO.

=== Залишки товару на дату ===

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

== Цілі теста ==

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

== Очікуваний результат ==

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

== Рекомендовані сутності бази даних ==

Для реалізації задачі доцільно передбачити такі сутності:

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

== Критерії перевірки ==

{| class="wikitable"
! Напрям перевірки !! Що перевіряється
|-
| Структура БД || Повнота моделі даних, наявність партій, документів, рядків, залишків і рухів
|-
| SQL || Коректність SQL-скриптів для MySQL, PostgreSQL або SQLite
|-
| Веб-рішення || Робота сторінок без перезавантаження
|-
| AJAX || Створення, редагування, проведення документів через AJAX
|-
| FIFO || Коректне списання собівартості за партіями
|-
| Контроль залишків || Заборона проведення при нестачі товару
|-
| Звіти || Продажі, прибутки, залишки на дату
|-
| ООП || Об’єктно-орієнтована структура коду
|-
| Демонстрація || Доступний веб-URL і зафіксований час виконання
|}

== Ілюстрації з документа ==

<gallery mode="packed" heights="180">
K2_Attestation_Wholesale_FIFO_01.png|Приблизний вигляд реєстру прибуткових накладних
K2_Attestation_Wholesale_FIFO_02.png|Форма прибуткової накладної
K2_Attestation_Wholesale_FIFO_03.png|Послуги у прибутковій накладній
K2_Attestation_Wholesale_FIFO_04.png|Друкована форма прибуткової накладної
K2_Attestation_Wholesale_FIFO_05.png|Реєстр видаткових накладних
K2_Attestation_Wholesale_FIFO_06.png|Реалізація послуг у видатковій накладній
K2_Attestation_Wholesale_FIFO_07.png|Друкована форма видаткової накладної
K2_Attestation_Wholesale_FIFO_08.png|Звіт «Залишки по складу»
K2_Attestation_Wholesale_FIFO_09.png|Ілюстрація до атестаційного завдання
K2_Attestation_Wholesale_FIFO_10.png|Ілюстрація до атестаційного завдання
</gallery>

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

* [[K2 Cloud ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Оптова торгівля]]
* [[FIFO]]
* [[Складський облік]]
* [[Прибуткова накладна]]
* [[Видаткова накладна]]
* [[Звіт залишків по складу]]

[[Категорія:K2 ERP]]
[[Категорія:K2 Cloud ERP]]
[[Категорія:Атестаційні завдання K2]]
[[Категорія:Оптова торгівля]]
[[Категорія:Складський облік]]

Файл:K2 Attestation Wholesale FIFO 10.png

2026-04-28T21:27:26Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 Attestation Wholesale FIFO 09.png

2026-04-28T21:27:25Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 Attestation Wholesale FIFO 08.png

2026-04-28T21:27:23Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 Attestation Wholesale FIFO 07.png

2026-04-28T21:27:21Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 Attestation Wholesale FIFO 06.png

2026-04-28T21:27:19Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 Attestation Wholesale FIFO 05.png

2026-04-28T21:27:16Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 Attestation Wholesale FIFO 04.png

2026-04-28T21:27:14Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 Attestation Wholesale FIFO 03.png

2026-04-28T21:27:12Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 Attestation Wholesale FIFO 02.png

2026-04-28T21:27:10Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 Attestation Wholesale FIFO 01.png

2026-04-28T21:27:07Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Атестаційні завдання K2 ERP/Надходження товарів

2026-04-28T21:24:57Z

R: Перенос з Гугл документа

'''Атестаційне завдання K2 Cloud ERP — Надходження товарів''' — практична задача для розробника K2 Cloud ERP, що передбачає створення веб-модуля обліку надходження товарів на склад з управлінням партіями.

== Назва ==
'''Модуль обліку надходження товарів на склад з управлінням партіями'''.

== Опис задачі ==
Необхідно розробити веб-модуль для обліку приходу товарів на склад.

Кожен прихід реєструється у системі у вигляді документа '''«Надходження товарів»'''. Документ має містити детальну інформацію про партії товарів:

* кількість;
* ціна закупки;
* дата виробництва;
* дата постачання.

Кожен документ повинен:

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

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

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

== Поставлені задачі ==

=== 1. Створити довідники ===
Потрібно створити такі довідники:

==== Товари ====
Довідник товарів має містити поля:

* <code>id</code>;
* код;
* назва;
* одиниця виміру;
* тип товару;
* виробник;
* стандартна ціна закупки.

==== Постачальники ====
Довідник постачальників має містити поля:

* <code>id</code>;
* код;
* назва;
* контактні дані.

==== Функціональність довідників ====
Довідники мають підтримувати:

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

=== 2. Створити журнал документів «Надходження товарів» ===
Журнал документів має відображати список документів надходження товарів.

==== Колонки журналу ====
Таблиця журналу повинна містити такі колонки:

* номер документа;
* дата;
* постачальник;
* кількість товарних позицій;
* загальна сума;
* статус документа:
** чернетка;
** проведений;
** анульований.

==== Функціональність журналу ====
Журнал документів має підтримувати:

* фільтрацію за датами;
* фільтрацію за постачальниками;
* фільтрацію за статусом;
* пошук по номеру документа;
* підсумки за обраним періодом.

==== Підсумки журналу ====
За обраним періодом потрібно показувати:

* загальну кількість товарів;
* загальну суму надходжень.

=== 3. Створити форму введення документа «Надходження товарів» ===
Форма документа складається із заголовка документа та табличної частини.

==== Заголовок документа ====
Заголовок документа повинен містити:

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

==== Таблична частина ====
Таблична частина має бути багаторядковою формою та містити такі поля:

* товар — пошук у довіднику через AJAX;
* одиниця виміру — підтягується автоматично;
* кількість — ручне введення;
* ціна закупки — автоматично пропонується, але може бути змінена вручну;
* сума — розраховується автоматично за формулою <code>кількість × ціна закупки</code>.

==== Приховані або бекенд-розрахунки для товару ====
Для кожного товару необхідно передбачити:

* номер партії — автоматичне генерування на основі дати постачання та коду товару;
* дата виробництва — опціонально;
* термін придатності — опціонально.

=== 4. Реалізувати збереження та проведення документа ===
Потрібно реалізувати:

* збереження документа без перезавантаження сторінки — через AJAX;
* проведення документа;
* переведення статусу документа у '''«Проведений»''';
* зарахування товару на склад після проведення документа.

=== 5. Розрахунки ===

==== Розрахунки після збереження документа ====
Після збереження документа потрібно:

* розрахувати підсумкову кількість товарів;
* розрахувати загальну суму документа;
* розрахувати окремо ПДВ 20%.

==== Розрахунки у списку документів ====
При виведенні списку документів потрібно підраховувати:

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

=== 6. Друк документів ===
Потрібно створити шаблон друку '''«Товарна накладна»'''.

==== Дані для друку ====
У друкованій формі потрібно виводити:

* шапку документа:
** постачальник;
** дата;
** номер;
* табличну частину:
** товари;
** одиниці виміру;
** кількість;
** ціна;
** сума;
* підсумки:
** загальна сума;
** сума ПДВ.

Шаблон може бути реалізований у форматі HTML/PDF і використовувати Stimulsoft або внутрішні механізми друку K2.

=== 7. Звіт «Рух товарів за період» ===
Потрібно реалізувати звіт '''«Рух товарів за період»'''.

==== Дані звіту ====
У звіті потрібно показати:

* товари;
* кількість надходжень;
* загальну суму закупок.

==== Фільтри звіту ====
Звіт має підтримувати фільтрацію:

* по складу;
* по постачальнику;
* по товару.

==== Підсумки звіту ====
У звіті потрібно формувати підсумки по всіх стовпцях.

=== 8. Додаткові умови ===

==== Фронтенд ====
Фронтенд має відповідати таким вимогам:

* використання AJAX без повного перезавантаження сторінок;
* таблиці з сортуванням і фільтрацією;
* можна використовувати DataTables або власну реалізацію.

==== Бекенд ====
Бекенд має відповідати таким вимогам:

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

== Технічні вимоги ==

* PHP 8+ або Python для бекенду K2;
* MySQL або PostgreSQL;
* власний або стандартний MVC-фреймворк K2;
* HTML5;
* JavaScript;
* jQuery або Fetch API/Axios для AJAX.

== Критерії оцінки ==
{| class="wikitable"
!Критерій
!Бали
|-
|Правильність структури БД
|10
|-
|Реалізація довідників з пошуком і вибором
|10
|-
|Журнал документів і підсумки
|15
|-
|Форма документа з AJAX-збереженням
|20
|-
|Проведення документа і розрахунок партій
|15
|-
|Шаблон друку документа
|10
|-
|Формування звітів і підсумків
|10
|-
|Загальна якість коду: читабельність, безпека
|10
|-
!Разом
!100
|}

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

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

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

* [[K2 Cloud ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Надходження товарів]]
* [[Складський облік]]
* [[WMS]]
* [[Управління партіями товарів]]
* [[Звіт руху товарів]]

Розгортання системи K2 ERP Python для розробників

2026-04-28T21:20:25Z

R: Розгортання K2 ERP для розробників Python

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

== Розгортання локального робочого проєкту ==
Розгортання локально робочого проекту K2 ERP та підключення до нього розробника

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

* копіюєм з віддаленого сервера існуючий проект по ftp

* переходимо в каталог /K2CloudERP і запускаємо файл first_run для налаштування параметрів віртуального середовища в поточному локальному розташуванні командою:
<pre>
bash first_run.sh - для Linux
./first_run.bat - для Windows
</pre>

* переходимо в файл налаштувань /K2CloudERP/cfg/k2/k2/k2cfg.py і змінюємо там domain_protocol з https на http

* запускаємо додаток:
<pre>
bash run.sh - для Linux
./run.bat - для Windows
</pre>

== 2. Встановлення, середовища розробки Pycharm та відкриття проекту: ==

=== для Linux ===

* встановлення через snap
<pre>
sudo rm /etc/apt/preferences.d/nosnap.pref
sudo apt update
sudo apt install snapd
sudo snap install pycharm-community --classic
pycharm-community
</pre>

* встановлення через завантаження архіву з сайту

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

розпаковуємо архів, переходимо в папку bin і запускаємо<pre>
./pycharm.sh
</pre>якщо отримали помилку встановлюємо JRE/JDK командами:<pre>
sudo apt update
sudo apt install default-jdk
</pre>

=== для Windows ===

=== Завантаження архіву ===
завантажуємо архів https://www.jetbrains.com/pycharm/download/?section=windows

розпаковуємо архів, запускаємо файл встановленя і встановлюємо згідно інструкцій

* відкриваємо середовище розробки Pycharm,

* відкриваємо поточний завантажений проект та налаштовуємо змінне середовище для поточного проекту:

в правому нижньому куті вибираємо Python Interpreter --> Add new Interpreter -->

у полі locations додаємо шлях до поточної папки venv

у полі Base Interpreter додаємо шлях до поточного виконуваного Python файлу (Пр: ../K2CloudERP/venv/bin.python3.12.exe)

* запускаємо проект в дебаг режимі (кнопка в правому верхньому куті)

* запускаємо проект з консолі Pycharm командою:
<pre>
bash run.sh - для Linux
./run.bat - для Windows
</pre>

* активація віртуального середовища вручну
<pre>
source venv/bin/activate - для Linux
.\venv\Scripts\activate - для Windows
</pre>

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

* встановлення

=== для Linux ===
<pre>
sudo apt update
sudo apt install git
</pre>

=== для Windows ===
завантажуємо архів https://git-scm.com/downloads/win розпаковуємо архів, запускаємо файл встановленя і встановлюємо згідно інструкцій

* налалштування git

=== налаштування користувача ===
<pre>
git config --global user.name "Ваше Ім'я"
git config --global user.email "ваша_електронна_пошта@example.com"
</pre>

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

=== авторизація через ssh ===

=== Налаштування SSH ключа ===
<pre>
ssh-keygen -t rsa -b 4096 -C "ваша_електронна_пошта@example.com"
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa
cat ~/.ssh/id_rsa.pub
</pre>копіюєм отриманий ключ і вставляємо у віддалений репозиторій

== 4. підключаємо віддалений репозиторій git для певної компоненти або списку компонент ==
для списку компонент (скрипт auto_update)
копіюєм каталог із скриптом і вставляємо в корінь проекту на рівні з виконуваним файлом app.py https://git.corp2.eu/k2erp/python/k2/base/client/auto_update
відкриваємо проект в консолі і переходимо в каталог auto_update<pre>
cd auto_update
</pre>відкриваємо файл settings.py і додаємо в словник ключі з потрібними компонентами (повний список в файлі settings_example.py)

* виконуємо в консолі команду, для клонування актуальних версій компонент і перейменовування каталогів поточних версій компонент
<pre>
python git_cmd.py clone
</pre>

=== для одної компоненти вручну ===

* переходимо в папку необхідної компоненти, наприклад k2site
<pre>
cd components/k2site
</pre>

* ініціалізуєм git в поточній директорії
<pre>
git init
git checkout -b main (створюємо локальну гілку main і перемикаємось на неї)
git checkout master (переключаємось на іншу локальну гілку)
git remote add origin http://git.corp2.eu/k2erp/python/k2/base/site/k2site.git
git remote -v (перевірка)
</pre>

* отримуємо дані з віддаленого репозиторію але не змінюємо поточну робочу гілку
<pre>
git fetch origin
</pre>

* отримуємо дані з віддаленого репозиторію з віддаленого репозиторію та автоматично об'єднує їх з поточною локальною гілкою.
<pre>
git pull origin main
</pre>

* перевіряємо зміни локально скопійованої копії проекту з віддаленим репозиторієм
<pre>
git status
</pre>

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

=== автоматично (скрипт auto_update) ===
відкриваємо проект в консолі і переходимо в каталог auto_update<pre>
cd auto_update
</pre>клонуємо компоненти з віддаленого сервера<pre>
python git_cmd.py clone
</pre>перевірка статусу
python git_cmd.py status
коміт змін<pre>
python git_cmd.py commit
</pre>отримуємо зміни з віддаленого сервера<pre>
python git_cmd.py pull
</pre>пушимо зміни на віддалений репозиторій<pre>
python git_cmd.py push
</pre>

=== вручну ===

* після внесених в коді змін перевіряємо їх командою
<pre>
git status
</pre>

* додаємо зміни командою
<pre>
git add .
</pre>

* комітимо зміни:
<pre>
git commit -m "Назва комміту"
</pre>

* пушимо зміни на віддалений репозиторій
<pre>
git push
</pre>

* при подальшій роботі отримуємо зміни з віддаленого репозиторію командою
<pre>
git pull
</pre>

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

* відкриваємо папку builder/config

* в файлі component-list.txt додаємо список компонент, які будемо завантажувати на сервер оновлення, кожна компонента з нового рядка
<pre>
components/k2update
components/k2adm
components/k2site
</pre>

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

( приклад:<pre>
k2site.txt
__pycache__
.gitignore
.git
ej2.min.js
</pre>)

* в файлі token.txt додаємо токен доступу до сервера оновлення

== 7. Завантаження нової версії компоненти в систему оновлення ==
Для створення нової версії компоненти (stable або beta (testing) версії):

* змінюємо версію в файлі setup.py в корні каталогу компоненти (рядок 5 поле version, наприклад version=2.0.4.43, version_type='stable' (testing))

* додаємо опис змін в в файлі history.txt в корні каталогу компоненти (1 рядок, наприклад 2.0.4.43 - додавання додаткового поля в форму реєстрації)

* переходимо в корінь додатку, на рівні з виконуваним файлом app.py:
<pre>
cd k2
</pre>

* завантажуємо додані в файлі builder/config/component-list.txt компоненти командою:
<pre>
python k2update_push.py
</pre>

== 8. Оновлюємо змінені версії компонент на тестових доменах deb1-deb3 та тестуємо функціонал. ==

== Контрольний чек-лист розгортання ==

# Проєкт скопійовано з віддаленого сервера по FTP.
# Виконано <code>first_run.sh</code> або <code>first_run.bat</code>.
# У файлі <code>/K2CloudERP/cfg/k2/k2/k2cfg.py</code> для локального запуску змінено <code>domain_protocol</code> з <code>https</code> на <code>http</code>.
# Проєкт запускається через <code>run.sh</code> або <code>run.bat</code>.
# У PyCharm налаштовано Python Interpreter на локальне віртуальне середовище <code>venv</code>.
# Встановлено та налаштовано Git.
# Підключено віддалений репозиторій потрібної компоненти або список компонент через <code>auto_update</code>.
# Перевірено <code>git status</code>, <code>git pull</code>, <code>git push</code>.
# Налаштовано <code>builder/config/component-list.txt</code>, <code>ignore</code> та <code>token.txt</code> для сервера оновлень.
# Оновлено версію компоненти в <code>setup.py</code> і опис змін у <code>history.txt</code>.
# Виконано <code>python k2update_push.py</code>.
# Оновлено компоненти на тестових доменах <code>deb1</code>–<code>deb3</code> та перевірено функціонал.

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

* [[K2 Cloud ERP|K2 ERP]]
* [[K2 Cloud ERP Python для розробників|K2 ERP Python для розробників]]
* [[Python]]
* [[PyCharm]]
* [[Git]]
* [[Розгортання системи K2 Cloud ERP PHP|Розгортання системи K2 ERP PHP]]

Головна сторінка

2026-04-28T21:18:47Z

R: Розгортання K2 ERP

== Про систему K2 ERP ==

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

== Сайти K2 ERP ==
[[Ресурси K2 ERP]]

== Для користувачів ==

[[Початок роботи з K2 ERP]]

[[Хмара K2]]

[[Бухгалтерія K2 ERP]]

[[Управлінський облік K2 ERP]]

[[CRM K2 ERP]]

[[Складський облік K2 ERP]]

[[Інтернет-магазин K2 ERP]]

[[K2 VDoc]]

[[Галузеві рішення K2 ERP]]

[[Звіти та аналітика K2 ERP]]

[[Поширені питання K2 ERP]]

== Для програмістів ==

[[Розгортання системи K2 ERP Python для розробників]]

[[Архітектура K2 ERP]]

[[Встановлення K2 ERP]]

[[Розгортання K2 ERP]]

[[Створення модулів K2 ERP]]

[[База даних K2 ERP]]

[[API K2 ERP]]

[[Інтеграції K2 ERP]]

[[K2 CMS]]

[[Розробка веб-інтерфейсів K2]]

[[Бізнес-процеси K2 ERP]]

[[Права доступу K2 ERP]]

[[Рекомендації для розробників K2]]

[[Класи та команди K2 ERP Python]]

[[Стандарти UI K2 2025]]

== Атестаційні завдання по K2 ERP ==

[[Атестаційні завдання по K2 ERP]]

[[Регламент K2]]

== K2 ERP PHP ==

[[Практична робота в K2 ERP PHP]]

[[Інструкція по розгортанню K2 ERP PHP]]

[[Класи та команди K2 Cloud ERP PHP]]

== Робота в K2 ==
[[Налаштування WireGuard]]

== Довідник та модулі ==

* [[K2 CMS]]
* [[K2 VDoc (Електронний документообіг)]]
* [[Ліцензійна політика K2]]

== Навігація за категоріями ==
Усі статті бази знань автоматично групуються за категоріями:

* [[:Категорія:ERP-системи|ERP-системи]]
* [[:Категорія:Програмне забезпечення, розроблене в Україні|Українське ПЗ]]
* [[:Категорія:Програмне забезпечення для бізнесу|ПЗ для бізнесу]]

Інформацію про роботу з цією вікі можна знайти на сторінці [[mediawikiwiki:Special:MyLanguage/Help:Contents|Довідка:Вміст]].

== Деякі корисні ресурси ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Список налаштувань];
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ Часті питання з приводу MediaWiki];
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ Розсилка повідомлень про появу нових версій MediaWiki];
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Локалізувати MediaWiki своєю мовою]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Дізнатися, як боротися зі спамом у своїй вікі]

Класи та команди K2 ERP Python

2026-04-28T21:16:33Z

R: Прибрав слово Cloud

'''K2 ERP Python для розробників''' — документація з вимогами до створення компонентів, структури пакетів, системних класів, API, компонентних класів і допоміжних JavaScript-функцій системи [[K2 Cloud ERP|K2 ERP]].

__TOC__

== K2 ERP Python ==

Команда для автоматичної генерації html файлу з документацією по док стрінгах:
pydoc -w k2/k2obj.py, де k2/k2obj.py - шлях до файлу з корня

== Вимоги до створення компонент ==

==== Компоненти, які публікуються в K2 ERP повинні мати щонайменше такі атрибути ====

ORM структури. Структури, які потрібні для даної компоненти. (файл models.py)

==== Головний клас компоненти, роути та api (файл views.py) ====

Додаткові об’єкти компоненти. Додаткові класи від яких залежить функціонал компоненти. (каталог objects/)

Хуки. Використовуються для розширення або зміни поведінки стандартних методів системи (файл hooks.py)

Зележності від інших компонент. (файл requirements-components.txt)
приклад:

<pre>
k2log==2.0.0.2
k2grid==2.0.4.1
k2form==2.0.1.27
</pre>

Python залежності, якщо є. (файл requirements.txt)

Readme.md. Файл в якому написана ціль компоненти, як її використовувати. Та різні моменти, які потрібно знати програмістам, адмінам та користувачам

Історія змін. Документ, в якому описуються зміни текстом, зрозумілим для користувачів. (файл history.txt)

Структура бази даних. На даний час, в форматі SQL power Architech. (каталог doc/schema)

Бізнес-процеси, схеми роботи, які були втілені в проудкті. В форматі Draw.io. (каталог doc/business_processes)

Інструкція користувача. Де розписано, як користуватись продуктом. Інструкція користувача повинна автоматично підтягуватись системою документації K2 ERP, додаючи розділ документації для цього продукту і надаючи можливість пошуку інформації в документації. Зберігається в каталозі: doc/user_manual)

Документацію для розробників, що генерується автоматично з коментарів. Зберігається в каталозі: doc/developer_documentation )

(потрібно завершити автоматичне збирання із компонент)

Документація для розробників (не обов’язково, але желательно). Додатково, якщо потрібно, щось додатково відмітити. Каталог doc/additional_developer_docs)

Приклади програмного коду з використанням компонент. Які автоматично з’являються в Examples при встановленні компоненти. І по яким можна протестувати функціонал. /examples (потрібно вирішити як додавати)

Віджети. Дашборди та інші візуальні елементи для вставки на головну сторінку та інші сторінки, які можна додавати автоматично. (потрібно вирішити як додавати) /widgets

Юніт тести. Написати де і яка структура. Юніт тести повинні автоматично знаходитись системою і використовуватись для загального тестування системи. Каталог /tests (потрібно завершити автоматичне збирання із компонент)

Локалізації. В К2 використовуються щонайменше: українська та англійська мова. Ядро повинно вміти робити переклади і давати можливість працювати з перекладами стороннім користувачам, покращуючи якість перекладу. Зберігається в каталозі:

<pre>
/languages/en/LC_MESSAGES/messages.po
/languages/en/LC_MESSAGES/messages.mo
</pre>

Демо-дані. Це дані, які розгортаються на демо-базі даних для демонстрації роботи з продуктом. (потрібно вирішити як додавати)

Файли ресурсів (зображення, тексти): Каталог /static

YML, якщо є. Каталог /yml

Іконки, які будуть використовуватись для представлення компоненти. Каталог /static/img

Авторство. Якщо К2, то в форматі, як прийнято в цілому для К2, якщо сторонній розробник - інформація про стороннього розробника. Copyright © 2000-2025 К2®, Rudiuk Serhii. All rights reserved.

Шаблони, якщо є. Вказуємо каталог. Звертаю увагу, що К2 ERP повинна мати змогу використовувати не обмежену кількість шаблонів. Шаблони повинні бути так розроблені, щоб не конфліктувати з глобальними шаблонами системи. Каталог /templates

==== Приклад дерева структури компоненти ====

<pre>
components/
└── k2adm/
├── k2adm/
│ ├── data/
│ ├── languages/
│ ├── static/
│ ├── templates/
│ ├── yml/
│ ├── tests/
│ ├── examples/
│ ├── widgets/
│ ├── __init__.py
│ ├── objects/
│ ├── users/users.py
│ ├── roles/roles.py
│ ├── forms.py
│ ├── history.txt
│ ├── hooks.py
│ ├── models.py
│ ├── views.py│
├── __init__.py
├── doc/
├── schema/
├── business_processes/
├── user_manual/
├── developer_documentation/
├── additional_developer_docs/
├── history.txt
├── requirements-components.txt
├── requirements.txt
├── setup.py
</pre>

== Системні класи ==

=== Клас K2 ===

Ядро системи K2CloudERP.

==== Властивості ====

==== Властивості класу ====

domain_name #назва домену

domain_protocol #протокол

domain #домен

port #порт

db #підключення до БД

default_language #мова за замовчуванням

==== Властивості інстансу ====

==== self.secur #властивість що підключає до ядра клас безпеки ====

self.path #властивість що підключає до ядра клас пошуку шляхів по ієрархії self.data #властивість що підключає до ядра клас синхронізації даних

==== self.settings #властивість що підключає до ядра клас збереження та пошуку налаштувань ====

==== self.notifications #властивість що підключає до ядра клас створення та відправки сповіщень ====

<pre>
#отримати домен
</pre>

==== K2().domain ====

==== Методи ====

==== Методи інстансу ====

Приклад використання:

<pre>
#отримати id поточного контрагента
</pre>

==== K2().get_user_counterparts_id() ====

<pre>
# отримати список встановлених компонент
</pre>

==== K2().component_list() ====

<pre>
# отримати назву поточного проекту
</pre>

==== K2().get_user_project_name() ====

<pre>
#отримати id поточного користувача
</pre>

==== K2().get_current_user() ====

<pre>
#створити користувача на рівні БД
</pre>

==== K2().create_db_role(user_name, password) ====

==== __init__(self, *args, **kwargs) ====

Initialize self. See help(type(self)) for accurate signature.

==== add_authorized_users(self, user_id, login) ====

Додати користувача до списку авторизованих

==== check_authorized_users(self, user_id) ====

Перевірити чи користувач активний

==== check_logout_users(self, user_id) ====

Авторизовані користувачі

==== component_list() ====

Пошук встановлених компонент

==== create_db_file_config_user(self) ====

Створення файлу з параметрами підключенням до БД для користувача

==== create_db_role(self, user_name, password) ====

Створення користувача на рівні БД

==== current_template(self) ====

Search current template

==== db_custom_engine(self, db) ====

Зміна custom параметрів підключення

==== db_user_engine(self, db) ====

Зміна параметрів підключення для поточного користувача

==== dell_authorized_users(self, user_id) ====

Видалити користувача зі списку авторизованих

==== drop_db_role(self, user_name) ====

Видалення користувача на рівні БД

==== get_all_subclasses(cls) ====

==== Пошук підкласів ====

==== get_authorized_users(self) ====

Отримати список авторизованих користувачів

==== get_current_user(self) ====

Повертає об’єкт поточного користувача

==== K2().get_current_user() ====

==== get_menu_url(self) ====

Повертає список url активних пунктів меню

==== get_project_setting(self) ====

Форма зміни проекту

==== get_user_counterparts_id(self) ====

Пошук id поточного контрагента

==== K2().get_user_counterparts_id() ====

==== get_user_counterparts_name(self) ====

Пошук назви поточного контрагента

==== K2().get_user_counterparts_name() ====

==== get_user_project_id(self) ====

Пошук id поточного проекту користувача

==== K2().get_user_project_id() ====

==== get_user_project_name(self) ====

Пошук назви поточного проекту користувача

==== K2().get_user_project_name() ====

==== get_user_stoages_name(self) ====

Пошук назви поточного складу

==== K2().get_user_stoages_name() ====

==== get_user_storage_id(self) ====

Пошук id поточного складу

==== K2().get_user_storage_id() ====

==== get_user_structural_division_id(self) ====

Пошук id поточного підрозділу

==== K2().get_user_structural_division_id() ====

==== get_user_structural_division_id_tree(self) ====

Пошук всіх підрозділів за ієрархією від поточного підрозділу користувача у форматі tuple ('id1', 'id2', 'id3')

==== init_db(self) ====

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

==== init_db_custom(self, key) ====

Підключення custom db_uri за ключем.

==== init_db_uri(self) ====

Пошук і ініціалізація файлу з підключення до бази даних

==== init_db_uri_custom(self) ====

Зчитує всі підключення до бази даних з файлу db_custom.yml і зберігає їх у словник.

==== init_db_uri_user(self) ====

Пошук і ініціалізація файлу з підключення до бази даних для поточного користуача

==== init_db_user(self) ====

Підключення db_uri для користувача

==== init_lm(self, app) ====

Ініціалізація логін-менеджера

==== kill_user_sessions(self, target_username) ====

Завершення сесії підключення користувача на рівні БД

==== search_class_dict(self, parent_class=None) ====

==== Рекурсивний пошук властивостей нащадків базового класу ====

==== search_class_prop(path_objs) ====

<pre>
# Отримуємо значення з path_objs для розширення поточного класу
</pre>

==== search_menu_items(self) ====

Search menu items

==== search_menu_items_category(self) ====

Search menu items category

==== search_static_files(self) ====

==== url_map(self) ====

==== Методи класу ====

Приклад використання:

<pre>
id = K2.generate_id()
usr_perm = K2().get_user_permissions()
K2.get_platform()
yml_path = K2.search_yml('users')
</pre>

==== clear_logging_messages() ====

Clear all logging message by user

==== compare_versions(version1, version2) ====

порівняння версій

==== create_system_settings() ====

==== dump_stacks() ====

Request information about the running threads of the current process.

:return: A tuple containing:

* A sequence of text lines detailing the stacks of running

threads and greenlets. (One greenlet will duplicate one thread,

the current thread and greenlet.)

* The number of greenlets.

==== generate_id() ====

Генерація ID

==== get_active_lang_list() ====

Визначення id поточної мови

==== get_current_user_role_name() ====

Отрмання rolename поточного користувача

==== get_locale() ====

Визначення поточної мови

==== get_locale_id() ====

Визначення id поточної мови

==== get_path_abs(caller_file) ====

Абсолютний шлях до файлу, в якому виконується код.

Виклик K2.get_path_abs(__file__)

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

==== get_path_to_root(caller_file) ====

Відносний шлях до рута.

Виклик K2.get_path_to_root(__file__).

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

==== get_platform() ====

Визначення операційної системи

==== get_user_permissions() ====

Retrieve user permissions based on the URL.

This method fetches permissions for the current user based on the URL they are accessing.

Returns:

dict: A dictionary containing the user permissions, including 'roleid' and various permission flags

such as 'r' (read), 'w' (write), 'i' (insert), 'd' (delete), 'c' (create), 'exp' (export), 'imp' (import), 'del_' (undelete), 'settable' (set table), 'cutpast' (cut and paste), 'enable' (enable), and 'active' (active).

If the user is a superadmin, a default set of permissions is returned.

If no permissions are found for the user, an empty dictionary is returned.

Raises:

Exception: If an error occurs during database query execution.

Usage:

<pre>
current_user_permissions = K2().get_user_permissions()
</pre>

==== get_user_role(user_id) ====

Отрмання roleid користувача

==== ins_search_comp() ====

Вивід списку компонент з файлу components.yml у всіх шляхах пошуку

==== load_babel_translation_directories() ====

Завантаження перекладів

==== load_logging_message_by_id(error_id: str) ====

Load a logging message by its error_id from the error log file.

Parameters:

error_id (str): The ID of the error to load.

Returns:

dict: The logging message if found, None otherwise.

==== load_logging_messages(page_url: str) ====

Load logging messages for the curren page from the error log file.

Parameters:

name (str): Name of the object (page) to load messages for.

Returns:

dict: A dictionary containing formatted log messages, the count of 'error' messages, and the count of 'warning' messages.

==== log_entry(error_id, status, message, name) ====

==== logging_message(status, message, page_url=None, show_message=True) ====

Send a logging message to the client via Socket.IO.

This method emits a message to the client with a given status and message content.

The message is sent to a room identified by the current user's ID.

Parameters:

status (str): The status of the message (e.g., cls.log_error - 'ERROR', cls.log_warning - 'WARNING', cls.log_success - 'SUCCESS').

message (str): The content of the message to be sent.

<pre>
page_url(str): url of page with Errors.
</pre>

show_message (bool): True - save log and show windows, False - only save_log

Приклад використання функції:

K2.logging_message(K2.log_error, 'Operation completed with error.')

K2.logging_message(K2.log_success, 'Operation completed successfully.'1)

<pre>
K2.logging_message(status=K2.log_success, message='Operation completed successfully.', page_url='/kadm/users', show_message=False)
</pre>

Example:

==== namemenu(url) ====

Add identificators to url page

==== save_logging_message(error_id, status, message, name) ====

Save a logging message to the stack.

Parameters:

status (str): The status of the message (e.g., cls.log_error - 'ERROR', cls.log_warning - 'WARNING', cls.log_success - 'SUCCESS').

message (str): The content of the message to be saved.

name (str): Name of object where the message originated.

==== search_babel_translation_directories() ====

Пошук файлів з перекладами

==== search_comp_names() ====

Вивід списку ідентифікаторів компонент

у всіх шляхах пошуку

Rerurn: list of components identificators

==== search_yml(name_yml) ====

Search for a yml file in the caller directories of subclasses.

This method searches for a yml file with a specified name in the caller directories of all subclasses of K2Obj.

The search is performed in the 'yml' subdirectory of each caller directory.

Args:

name_yml: The name of the yml file to search for (without the '.yml' extension).

Returns:

The caller directory where the yml file was found, or None if the file was not found.

Usage:

To search for a yml file named 'users.yml', call this method as follows:

K2.search_yml('users')

== API ==

=== Клас K2Obj ===

З цього класу створюються всі об’єкти системи К2. Він має основну базову функціональність, що розширюється та розвивається та яка є у всіх класів системи

==== Властивості ====

==== Властивості класу ====

name #Назва компоненти.

version #Версія компоненти

==== Властивості інстансу ====

self._name_yml #назва конфігураційного файлу

self._name_yml_tree #назва конфігураційного файлу з деревом

self._new_buttons #назва кнопки

self._name_yml_master #назва конфігураційного файлу

self._send_params #параметри для конфігураційного файлу

self._send_group_params #параметри групи

self._report_id #id звіту

self._data_source #датасети

self._off_buttons #вимкнути кнопки

self._row_selection #вибір з рядка

==== Методи ====

==== Методи інстансу ====

Приклад використання:

==== __init__(self) ====

Initialize self. See help(type(self)) for accurate signature.

==== content(self) ====

==== create_names_yml(self, name_yml: str = '', name_yml_tree: str = '', ====

<pre>
name_yml_master: str = '')
</pre>

==== search_class_prop(path_objs) ====

==== Пошук властивостей для розширення класу ====

==== select_grid(self) ====

==== show_grid(self) ====

== API ==

=== Клас K2admin_menus ===

==== Даний клас формує список пунктів меню для конкретного користувача ====

=== Клас k2data ===

=== Клас k2datasync ===

=== Клас k2logging ===

==== Класk2mail ====

==== Класk2notifications ====

=== Клас k2path ===

=== Клас k2secur ===

=== Клас k2settings ===

=== Клас k2trans ===

=== Клас k2upd ===

== Класи компонент ==

=== Клас K2Site ===

=== Клас K2Grid ===

=== Клас K2WMS ===

=== K2UpdateRemainder ===

=== Клас для оновлення залишків на основі даних з отриманих від клієнтів. ===

Відповідає за обробку даних з логів, створення/оновлення записів про залишки товарів та керування їх статусами (новий, стабільний, старий).

==== Методи ====

==== __init__() ====

Ініціалізація класу.
Викликає конструктор батьківського класу K2Docs.

Параметри:
Відсутні.

Повертає:
Об'єкт класу K2UpdateRemainder.

==== update_pub_sub_remainder() ====

Оновлення залишків на основі даних Pub/Sub.
Витягує нові залишки з логів, додає їх у таблицю k2remainder_by_parties, оновлює статуси існуючих записів та видаляє застарілі залишки.

Логіка статусів:

'new' – нові залишки, отримані в поточному оновленні.

'stable' – залишки, які підтвердились та доступні користувачам.

'old' – застарілі дані, що підлягають видаленню.

Алгоритм роботи:

Отримує список pub_sub_list_id з логів k2pubsub_logs.

Витягує дані про залишки (inventSumLines).

Вставляє нові записи у таблицю k2remainder_by_parties зі статусом 'new'.

Масово оновлює статуси залишків:

Видаляє застарілі ('old').

Переводить стабільні ('stable') в старі ('old').

Нові ('new') переводить у стабільні ('stable').

Фіксує зміни у базі (commit).

У разі помилки виконує відкат (rollback).

==== _insert_new_pub_sub_nomenclature(session, nomenclature_data) ====

Додавання нової номенклатури.
Перевіряє наявність номенклатури у таблиці k2nomenclature. Якщо запису немає – створює його.

Параметри:

session (Session) – об'єкт сесії бази даних.

nomenclature_data (dict) – дані про номенклатуру:

itemId (str) – ідентифікатор номенклатури.

itemName (str) – назва товару.

unitId (str) – одиниця виміру (конвертується за фіксованим списком).

Повертає:
Нічого.

Винятки:

Логує помилку у разі невдалої вставки даних.

=== Клас K2CRM ===

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

управління лідами
- замовлення

* рахунки

* звіти

* налаштування системи CRM

=== Клас K2CRM наслідується від K2Obj, всі властивості та методи отримуються від батьківського класу. ===

=== K2DocsCRM ===

=== Клас K2DocsCRM є частиною системи K2CRM і наслідується від K2Obj. Він надає доступ до ключових глобальних налаштувань та ресурсів, необхідних для роботи з документами або іншими функціями CRM. ===

==== Атрибути ====

database:

База даних, доступна через глобальний об'єкт K2.db.

Призначення: Використовується для зберігання та обробки даних, пов'язаних з CRM.

time_zone:

Часовий пояс системи, визначений глобальним об'єктом K2.timezone.

Призначення: Забезпечує коректну обробку часу в межах системи.

domain:

Домен, на якому працює CRM, отримується з глобального об'єкта K2.domain.

Призначення: Використовується для побудови URL-адрес або інших задач, пов'язаних з доменним середовищем.

==== Властивості ====

==== Методи ====

<pre>
create_contact() - Цей метод створює контакт на основі даних існуючого ліда. Лід і контакт взаємодіють через базу даних, де дані ліда переносяться в таблицю контактів.
</pre>

Логіка роботи:

==== Метод очікує вхідний JSON, що містить ідентифікатор ліда (lead_id) ====

Перевіряє чи було надано lead_id. Якщо lead_id не надано то повертається помилка.

Шукає ліда в таблиці k2lead за наданим параметром.

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

У разі помилки скасовує транзакцію і повертає опис помилки.

==== Моделі які використовуються ====

K2Lead. Таблиця яка містить дані про лідів.

k2contacts. Таблиця, в яку додається новий контакт на основі даних ліда.

<pre>
check_lead() - Цей метод перевіряє, чи існує контакт із заданим номером телефону у базі даних (k2contacts). Якщо знайдено, оновлює дані ліда (ім'я, прізвище, email) у переданому об'єкті.
</pre>

Логіка роботи:

Отримає вхідний JSON, що містить options із даними для перевірки.

З options[‘dataField’] отримує номер телефону (phone)

Виконує SQL-запит до таблиці k2contacts для пошуку контакту за номером телефону.

Якщо контакт знайдено то відбувається оновлення даних у options[‘dataField’] (name, surname, email, lead_id)

Якщо контакт не знайдено то для полів name, surname, email встановлюється значення None.

У разі помилки повертає повідомлення з помилкою.

<pre>
crm_data(route, data) - Цей метод отримує дані із відповідних таблиць з бази даних на основі переданих параметрів для подальшого оформлення друкованої форми документів у компоненті k2CRM
</pre>

Логіка роботи:

Створює порожній словник result_dict, який буде наповнюватись даними та парсить вхідні дані data у форматі JSON і зберігає їх у result_dict[‘Header’].

Формує SQL-запити для витягування даних із таблиць бази даних (Товари, Організація, Контрагент, Склад, Договір, Відповідальна особа, Клієнт).

Для кожного запиту виконується SQL-запит та результат додається до result_dict.

Результати запитів конвертуються у словники (row_asdict) для зручного JSON-формату.

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

process_options - Метод обробляє різні параметри, передані через JSON-запит, і налаштовує об'єкти типу K2Grid для роботи з даними в залежності від значення ключа name у вхідних даних.

Основні операції:

Обробка k2doc_rows_detail:

Ім'я YML: 'k2doc_rows_detail'.

Вимикаються кнопки: add, delete, printReport.

Передаються параметри: row_id та storage_id.

Обробка k2doc_move:

Ім'я YML: 'k2doc_move'.

Вимикаються кнопки: add, edit, delete, printReport.

Передаються параметри: doc_id.

Логіка роботи:

Метод очікує вхідні дані у форматі JSON і доступ до них здійснюється через request.json.

Перевіряється значення ключа name у вхідних даних:

<pre>
Якщо name == 'k2doc_rows_detail':
Виділяється row_id із переданих даних. Створюється об’єкт K2Grid з іменем yml “'k2doc_rows_detail”. Вимикаються кнопки add, delete, printReport на панелі інструментів. Отримується storage_id через метод self.get_storage_id(). Параметри row_id та storage_id передаються через send_params.
Якщо name == 'k2doc_move':
</pre>

Виділяється doc_id із вхідних даних. Створюється об'єкт K2Grid з іменем yml 'k2doc_move'. Вимикаються кнопки add, edit, delete, printReport на панелі інструментів. Параметри (doc_id) передаються через send_params.

Повернення результату у форматі JSON

=== Клас K2Report ===

Цей клас забезпечує генерацію та друк звітів за допомогою API Stimulsoft.

==== Основні можливості модуля ====

створення звітів за допомогою конструктора звітів

управління друкованими формами

генерація друкованих документів

==== взаємодія з API Stimulsoft для візуалізації та експорту звітів ====

=== Клас K2Report наслідується від K2Obj, всі властивості та методи отримуються від батьківського класу.
Також клас K2Report є батьківським класом для K2ReportEmbed та K2ReportDesigner ===

==== Атрибути класу ====

==== Методи класу ====

==== __init__(sql=[]) ====

Ініціалізація класу. Отримує шлях до каталогу файлу, що викликав ініціалізацію.

Параметри:

sql (list, опціонально): Список SQL-запитів.

==== create_report(sql=None, data_source=None) ====

Створення звіту. Відображає HTML-сторінку редактора або переглядача звітів.

Параметри:

sql (dict, опціонально): SQL-запити.

data_source (dict, опціонально): Джерело даних.

Повертає:

HTML-сторінку редактора або переглядача звітів.

==== get_report(file_name) ====

Отримання звіту за його ім'ям.

Параметри:

file_name (str): Назва файлу звіту.

Повертає:

Файл звіту або помилку 404, якщо файл не знайдено.

==== execute_query(query, params=None) ====

Виконує SQL-запит.

Параметри:

query (str): SQL-запит.

params (dict, опціонально): Параметри запиту.

Повертає:

Результат виконання запиту.

==== get_report_designer(file_name, design_type_id) ====

Отримує дизайнер звіту за типом звіту.

Параметри:

file_name (str): Назва файлу.

design_type_id (str): Тип дизайну (1 - звіт, 2 - дашборд).

Повертає:

Файл дизайну або помилку 404.

==== add_reports_type(name, data) ====

Додає тип звіту до групи звітів.

Параметри:

name (str): Назва типу звіту.

data (dict): Дані для оновлення.

Повертає:

bool: True, якщо успішно.

=== Клас K2ReportEmbed ===

K2ReportEmbed - Компонент для вбудовування звітів у веб-додаток. Дозволяє отримувати та відображати звіти з бази даних на основі їх ідентифікаторів.

==== Атрибути класу ====

==== __init__(reports_id: List[str]) ====

Ініціалізує екземпляр класу K2ReportEmbed.

Аргументи:

reports_id (List[str]) – список ідентифікаторів звітів.

==== get_report_data() -> Optional[List[Dict[str, Any]]] ====

Отримує дані звітів з бази даних.

Повертає:

Optional[List[Dict[str, Any]]] – список даних звітів або None, якщо сталася помилка.

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

report_name – Назва звіту.

file_name – Ім'я файлу звіту.

json_data_list – JSON-структура, що містить дані для звіту.

Якщо під час виконання запитів виникає помилка, вона логуватиметься у системному журналі помилок

Приклад вбудовування звітів на веб-сторінку

==== Бекенд (Flask) ====

<pre>
@k2production.route('/test_dashboard', methods=['GET'])
def test_dashboard():
</pre>

""" Index page """

<pre>
reports_id = ['b452a5ae84f9e92e75eb0467c196fd71', '1673a4fab757fb6c5df970fdc6ee680c',
</pre>

'49952f397efff44d7ce0e5cb9aa625fb']

<pre>
k2report_embed = K2ReportEmbed(reports_id)
return render_template('k2dashboard_production/k2dashboard_production.html',
dashboard_settings=k2report_embed)
</pre>

==== Фронтенд (Jinja-шаблон) ====

<pre>
{% extends template_name + '/base.html' %}
{% block content %}
{% if error %}
{{ error }}
{% else %}
{% include dashboard_settings.template %}
{% endif %}
{% endblock %
</pre>

=== Клас K2ReportDesigner ===

=== Клас K2ReportDesigner надає функціональність для створення, редагування та перегляду звітів і дашбордів. Він взаємодіє з базою даних, управляє файлами звітів та генерує JSON-дані для подальшого використання. ===

==== Атрибути класу ====

==== Методи класу ====

==== designer() ====

Відображає сторінку редагування друкованої форми.

Повертає:

str: HTML-шаблон сторінки редагування.

==== viewer() ====

Відображає сторінку перегляду друкованої форми.

Повертає:

str: HTML-шаблон сторінки перегляду.

==== dashboard_viewer() ====

Відображає сторінку перегляду дашборду.

Повертає:

str: HTML-шаблон сторінки перегляду дашборду.

==== dashboard_designer() ====

Відображає сторінку редагування дашборду.

Повертає:

str: HTML-шаблон сторінки редагування дашборду.

<pre>
json_data_create(datasource_value, datasource_keys, datasource_is_counterpart_id, datasource_is_storage_id, period, date_from=None, date_to=None)
</pre>

Створює JSON-дані на основі джерел даних та періоду.

Параметри:

datasource_value (list): Список SQL-запитів.

datasource_keys (list): Список ключів для джерел даних.

datasource_is_counterpart_id (list): Список флагів, що вказують на наявність counterpart_id.

datasource_is_storage_id (list): Список флагів, що вказують на наявність storage_id.

period (int): Період вибірки даних.

date_from (str, опціонально): Початкова дата періоду.

date_to (str, опціонально): Кінцева дата періоду.

Повертає:

dict: Словник з результатами запитів або помилкою.

==== Приклад використання ====

<pre>
datasource_value = ["SELECT * FROM table1", "SELECT * FROM table2"]
datasource_keys = ["table1_data", "table2_data"]
datasource_is_counterpart_id = [True, False]
datasource_is_storage_id = [False, True]
period = 1
date_from = "2023-01-01"
date_to = "2023-12-31"
json_data = k2_designer.json_data_create(datasource_value, datasource_keys, datasource_is_counterpart_id, datasource_is_storage_id, period, date_from, date_to)
</pre>

==== save_report_id() ====

Зберігає ідентифікатор та налаштування звіту в JSON-файл.

Повертає:

Response: JSON-відповідь про результат збереження.

==== mrt_report_create(report_id, design_type_id=None) ====

Створює MRT-файл звіту на основі шаблону.

Параметри:

report_id (str): Ідентифікатор звіту.

design_type_id (str, опціонально): Тип дизайну звіту.

Повертає:

str: Ім'я створеного файлу або помилка.

==== table_report_data(datasource_value, datasource_keys) ====

Обробляє дані з SQL-запитів для кожного джерела даних і повертає їх у вигляді JSON.

Параметри:

datasource_value (list): Список SQL-запитів для виконання.

datasource_keys (list): Список ключів, які відповідають кожному SQL-запиту.

Повертає:

dict: Словник, де ключі — це значення з datasource_keys, а значення — дані у форматі JSON для кожного запиту.

==== save_info_report_designer() ====

Зберігає інформацію про репорт та генерує файл MRT.

Повертає:

Response: JSON-об'єкт із результатами генерації звіту та повідомленням про успішність.

==== data_source_lists_creating(group_reports_id) ====

Створює списки джерел даних для звіту.

Параметри:

group_reports_id (str): Ідентифікатор групи звітів.

Повертає:

list: Списки джерел даних.

=== Клас K2Production ===

==== Методи класу ====

Схема вибору обслуговування терміналу

=== Клас K2LogbookTMDoc ===

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

==== Методи класу ====

==== k2logbook_tm() ====

Відображає сторінку логбука технічного обслуговування.
Повертає:
str: HTML-шаблон сторінки логбука.

==== take_logbook_tm(task_id) ====

Створює форму логбука для конкретного завдання.
Параметри:

task_id (str): Ідентифікатор завдання.

Повертає:
str: HTML-шаблон форми логбука.

==== edit_logbook_tm(logbook_fields_tm_id) ====

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

logbook_fields_tm_id (str): Ідентифікатор запису логбука.

Повертає:
str: HTML-шаблон сторінки редагування.

==== select_current_step(connection, logbook_fields_tm_id) ====

Вибирає поточний активний крок логбука.
Параметри:

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

logbook_fields_tm_id (str): Ідентифікатор запису логбука.

Повертає:
str: Ідентифікатор поточного кроку.

==== planned_tm(data, connection) ====

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

data (dict): Дані завдання.

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

Повертає:
dict: Налаштування grid.

==== unplanned_tm(data, connection) ====

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

data (dict): Дані завдання.

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

Повертає:
dict: Налаштування grid.

==== write_logbook_params(data) ====

Зберігає параметри логбука в JSON-файл.
Параметри:

data (dict): Дані для збереження.

Повертає:
JSON: Відповідь про успішне збереження.

==== read_logbook_params() ====

Зчитує параметри логбука з JSON-файлу поточного користувача.
Повертає:
dict: Збережені параметри логбука.

==== fill_logbook_tm_rows(data) ====

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

data (dict): Параметри для заповнення рядків.

Повертає:
bool: True при успішному заповненні, False при помилці.

==== pull_spare_parts_data() ====

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

==== send_params_to_k2logbook_spare_parts(data) ====

Формує параметри та SQL-запит для отримання даних про запчастини.
Параметри:

data (dict): Параметри логбука.

Повертає:
dict: Інформація про запчастини або False при помилці.

==== instruments_and_equipment_parts_params() ====

Отримує параметри інструментів та запчастин для обладнання.
Повертає:
JSON: Відповідь з результатом операції або повідомленням про помилку.

==== task_step_form() ====

Формує форму кроку завдання технічного обслуговування.
Повертає:
JSON: Відповідь з параметрами кроку або повідомленням про помилку.

==== is_unplanned_step_form(step_data) ====

Обробляє форму кроку для позапланованого ТО.
Параметри:

step_data (dict): Дані кроку.

Повертає:
str: ID кроку або JSON з помилкою.

==== save_step(data) ====

Зберігає дані кроку (номенклатуру).
Параметри:

data (dict): Параметри кроку.

Повертає:
bool: True при успіху, False при помилці.

==== end_step(data, session_id, connection, post_request) ====

Завершує крок ТО. Обробляє запчастини, час, статус.
Параметри:

data (dict): Дані кроку.

session_id (str): ID сесії.

connection (опціонально): Підключення до БД.

post_request (bool): Чи це постобробка.

Повертає:
JSON або False.

==== step_image_check(connection, data) ====

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

connection: Підключення до БД.

data (dict): Дані кроку.

Повертає:
bool: True (є зображення), False (немає або помилка).

==== step_data_check(connection, data) ====

Перевіряє коректність даних про запчастини.
Параметри:

connection: Підключення до БД.

data (dict): Дані кроку.

Повертає:
bool: True (дані валідні), False (невалідні або помилка).

==== decline_task() ====

Відхиляє завдання. Деактивує запис у логбуці.
Повертає:
JSON: Результат операції.

==== write_user_comment() ====

Додає коментар користувача до кроку.
Повертає:
JSON: Результат збереження.

==== end_step_manager(data) ====

Керує завершенням кроку. Перевіряє матеріали, зображення.
Параметри:

data (dict): Дані кроку.

Повертає:
bool: True (успіх), False (помилка).

==== detail_check(connection, data) ====

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

connection: Підключення до БД.

data (dict): Дані кроку.

Повертає:
bool: True (відповідність є), False (немає або помилка).

==== send_params_to_k2mount_point_form() ====

Формує параметри для форми монтажних точок обладнання.
Повертає:
JSON: Параметри форми (точки монтування, URL зображення схеми).

==== change_scheme_equipment() ====

Оновлює схему обладнання шляхом заміни монтажних точок.
Повертає:
JSON: Результат операції.

==== pass_familiarisation() ====

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

==== create_write_off_act_logbook(connection, data) ====

Створює акт списання для логбука.
Параметри:

connection: Підключення до БД.

data: Дані для акту.

Повертає:
bool: True (акт створено), False (помилка).

==== create_doc_rows_for_write_of_act(connection, data) ====

Створює рядки документу для акту списання.
Параметри:

connection: Підключення до БД.

data: Дані документу.

Повертає:
bool: True (рядки створено), False (помилка).

==== write_off_part_logbook(connection, data) ====

Списати частину обладнання з логбука.
Параметри:

connection: Підключення до БД.

data: Дані для списання.

Повертає:
Нічого (помилки обробляються через rollback).

==== end_logbook() ====

Завершує роботу з журналом ТО.
Повертає:
JSON: Результат операції (успіх або помилка).

==== spare_parts_check() ====

Перевіряє наявність запасних частин для журналу.
Повертає:
JSON: Результат перевірки (успіх або помилка).

==== equipment_qr_confirmation() ====

Підтверджує відповідність QR-коду обладнання.
Повертає:
JSON: Результат перевірки (успіх або помилка).

==== add_new_equipment_parts(connection, data) ====

Додає нові частини обладнання до БД.
Параметри:

connection: Підключення до БД.

data: Дані про частини обладнання.

Повертає:
bool: True (успіх), False (помилка).

==== material_quantity() ====

Отримує інформацію про кількість матеріалів.
Повертає:
JSON: Дані про кількість матеріалів.

==== create_unplanned_task(data) ====

Створює незаплановане завдання.
Параметри:

data: Дані для створення завдання.

Повертає:
bool: True (успіх), False (помилка).

==== take_material_by_qr() ====

Резервує матеріал за допомогою QR-коду.
Повертає:
JSON: Результат операції (успіх або помилка).

==== return_material_by_qr() ====

Повертає матеріал за QR-кодом.
Повертає:
JSON: Результат операції (успіх або помилка).

==== requires_partner() ====

Встановлює статус завдання "потребує партнера".
Повертає:
JSON: Підтвердження операції.

==== join_task() ====

Додає користувача до завдання та змінює статус на "in_work".
Повертає:
JSON: Результат операції.

==== e_report_logbook(logbook_fields_tm_id) ====

Генерує звіт для журналу ТО у форматі HTML.
Параметри:

logbook_fields_tm_id: ID журналу.

Повертає:
HTML: Відображення звіту.

==== get_all_employee_image() ====

Отримує всі зображення журналу.
Повертає:
JSON: Список URL зображень.

==== get_employee_image() ====

Отримує зображення конкретного рядка журналу.
Повертає:
JSON: Список URL зображень.

==== get_image_logbook(image_data) ====

Перетворює шляхи зображень у URL.
Параметри:

image_data: Дані зображень з БД.

Повертає:
list: Список URL

==== confirm_task() ====

Підтверджує завершення завдання. Надсилає сповіщення.
Повертає:
JSON: Результат операції.

==== send_on_revision_task() ====

Надсилає завдання на доопрацювання.
Повертає:
JSON: Підтвердження операції.

==== send_to_the_task_list_revision() ====

Надсилає завдання на доопрацювання та деактивує виконавців.
Повертає:
JSON: Результат операції.

==== change_task_employee(connection, data) ====

Оновлює виконавців завдання.
Параметри:

connection: Підключення до БД.

data: Нові виконавці та рядки.

==== change_step_status_revision(connection, data) ====

Скидає статус виконання кроків.
Параметри:

connection: Підключення до БД.

data: Ідентифікатори кроків.

==== change_task_status_revision(connection, data, status) ====

Змінює статус завдання.
Параметри:

connection: Підключення до БД.

data: Ідентифікатор завдання.

status: Новий статус (за замовчуванням in_work).

=== Клас K2EquipmentFunction ===

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

==== Атрибути ====

path_class: 'components/k2production/k2production/k2equipment'

file_class: 'k2equipment'

==== Методи ====

==== init(self) ====

Конструктор класу, який викликає конструктор батьківського класу K2Obj.

<pre>
send_approval_request_from_hook(self, data) - Метод для відправлення запиту на затвердження змін у технічній карті обладнання.
</pre>

==== Параметри ====

data (dict): Словник з даними, що містить:

equipment_type_id (int): Ідентифікатор типу обладнання

changed_fields (dict): Словник зі зміненими полями та їх значеннями

==== Логіка роботи ====

Перевірка наявності записів з parentid:

<pre>
Перевіряє наявність записів у таблиці k2tm_fields з parentid != '0'
</pre>

Якщо записів немає, повертає помилку 404

Отримання інформації про тип обладнання:

Витягує equipment_type_name та equipment_type_code з таблиці k2equipment_type

Якщо тип обладнання не знайдено, повертає помилку 404

Пошук затверджувачів:

Отримує список активних користувачів для затвердження з таблиці k2users_for_approval

Якщо затверджувачів не знайдено, повертає помилку 404

Формування повідомлення:

Створює опис змін у форматі "поле: старе_значення → нове_значення"

Формує URL для сторінки затвердження

Відправка запиту на затвердження:

<pre>
Використовує K2Notifications.send_approval_request() для відправки повідомлення
</pre>

Передає список затверджувачів, ідентифікатор об'єкта, URL та опис змін

==== Повертає ====

У разі успіху: JSON з повідомленням про успішну відправку (код 200)

У разі помилки: JSON з описом помилки (код 404 або 500)

==== Залежності ====

Потребує доступу до бази даних через self.db

==== Використовує клас K2Notifications для відправки повідомлень ====

Працює з конфігурацією домену через K2.domain

== K2 ERP Javascript ==

==== createImageSliderModal(images, containerId = null) ====

Створює слайдер зображень у контейнері або модальному вікні.

Параметри:

images: Масив URL-адрес зображень.

containerId: Ідентифікатор контейнера для вставки слайдера (необов’язково).

Повертає:

Ідентифікатор створеного каруселя або модального вікна.

Якщо зображення відсутні, показує повідомлення та повертає null.

==== showBootstrapLoader(containerId) ====

Додає анімацію завантаження у вказаний контейнер.

Параметри:

containerId: Ідентифікатор контейнера, у який буде вставлений індикатор завантаження.

==== removeBootstrapLoader(containerId) ====

Видаляє анімацію завантаження з контейнера.

Параметри:

containerId: Ідентифікатор контейнера, з якого потрібно прибрати індикатор завантаження.

==== showUserAlert(message, type = 'light') ====

Відображає сповіщення користувача у вигляді Bootstrap Toast

.

Параметри:

message: Текст повідомлення. type: Тип сповіщення (primary, success, danger, warning, info, light). За замовчуванням 'light'.

== Стилі (Назва) ==

Подзаголовок

Заголовок 1

Заголовок 2

Заголовок 3

Заголовок 4

Заголовок 5

Заголовок 6

Звичвйний текст

== Ілюстрації з документа ==

<gallery mode="packed" heights="180">
K2_Cloud_ERP_Python_01.png|Ілюстрація K2 ERP Python|посилання=Файл:K2_Cloud_ERP_Python_01.png
</gallery>

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

* [[K2 Cloud ERP|K2 ERP]]
* [[K2 ERP]]
* [[Python]]
* [[API]]
* [[Документація для розробників]]
* [[K2 Cloud ERP Javascript|K2 ERP Javascript]]

[[index.php?title=Категорія:K2 ERP]]
[[Index.php?title=Категорія:K2 Cloud ERP|index.php?title=Категорія:K2 ERP]]
[[index.php?title=Категорія:Python]]
[[index.php?title=Категорія:Документація K2]]
[[index.php?title=Категорія:Документація для розробників]]

Стандарти UI K2 2025

2026-04-28T21:15:19Z

R: Прибрав шаблон

'''Стандарти UI K2 2025''' — документ, який описує єдині підходи до реалізації дизайнів, контролів, компонентів та програмної частини у проектах K2.

__TOC__

== Мета ==

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

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

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

Увага: різні компоненти можуть конфліктувати одне з одним. Тому дуже важливо правильно підбирати контроли, щоб не конфліктували друг з другом.

* P.S. Дуже стара версія стандартів (10-20 річної давнини): https://docs.google.com/document/d/1LjNHDyISGVkk7AnhXfWnTL9xChJqzKHchfTcVrTYWk8/edit

== Карти ==

[[Файл:K2_UI_Standards_2025_01.png|міні|центр|Ілюстрація до розділу «Карти»]]

=== OpenStreet ===

* https://tomickigrzegorz.github.io/leaflet-examples/#10.matching-all-markers-to-the-map-view

* https://leafletjs.com/

=== Карти 3D ===

* https://mapplic.com/maps/apartment

== Інструментарій ==

SQL Power Architech - моделювання структури бази даних:

* https://bestofbi.com/architect-download/

DBAver - редактор бази даних

* https://dbeaver.com/download/

* Редактор структури бази даних (для можливого використання редактора): https://www.drawdb.app/editor

== Шаблони ==

Багато прикладів роботи компонентів та їх поводження можна побачити в різних шаблонах.

* https://adminlte.io/themes/AdminLTE/index2.html#

* https://appstack.bootlab.io/dashboard-default.html

* https://themes.getbootstrap.com/preview/?theme_id=88616

* https://themes.getbootstrap.com/preview/?theme_id=28117

* https://themes.getbootstrap.com/product/keen-the-ultimate-bootstrap-admin-theme/

* https://themes.getbootstrap.com/preview/?theme_id=5824

* https://themes.getbootstrap.com/preview/?theme_id=1666

* https://themes.getbootstrap.com/preview/?theme_id=21888

== Google-теми ==

* https://themewagon.com/themes/tailadmin/

* https://startbootstrap.com/previews/material-admin-pro

* https://startbootstrap.com/previews/sb-admin-pro-angular

== Грід PHP Grid ==

* https://www.gridphp.com/demo-center/

== AG-Grid ==

* https://www.ag-grid.com/example/

== Telerik ==

* https://www.telerik.com/

* https://www.telerik.com/support/demos

== Report ==

* Stimul Report: https://demo.stimulsoft.com/#Net/BusinessInvoice

== Набори прикладів різних UI компонентів ==

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

* Syncfusion: https://ej2.syncfusion.com/vue/documentation/toolbar/responsive-mode

* jQWidgets: https://www.jqwidgets.com/jquery-widgets-demo/

* DHX (рекомендовано до використання): https://snippet.dhtmlx.com/i7cfddkl

* Різні UI-компоненти Telerik (більше під .Net): https://demos.telerik.com/kendo-ui/

* DevExpress (більше .Net): https://www.devexpress.com/support/demos/#

== VueRibbon: https://www.vueribbon.com/home ==

* MetroUI: https://korzh.com/metroui#licensing

* https://themes.org.ua/pandora/index.html#forms-extended

* https://metroui.org.ua/ribbon-menu.html

== Інструменти протопіювання дизайну ==

За допомогою цих інструментів ви можете зробити схему елементів дизайну.

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

* https://wireframe.cc

== Моделювання структури бази даних ==

* https://bestofbi.com/products/sql-power-architect-data-modeling/ - SQL Power Architech.

== Види компонентів ==

== Меню ==

[[Файл:K2_UI_Standards_2025_02.png|міні|центр|Ілюстрація до розділу «Меню»]]

Меню можуть бути: верхнє, нижнє, бокове (справа, або зліва), контекстне та інше.

Контекстне меню - з’являється тоді, коли ми клацаємо на елементі лівою клавішею миші. Можливі і інші варіанти визову контекстного меню.

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

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

* Приклади: https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/defaultfunctionality.htm

* https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/minimized.htm

=== Контектне меню ===

* https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/contextmenu.htm

== Таймлайн ==

[[Файл:K2_UI_Standards_2025_03.png|міні|центр|Ілюстрація до розділу «Таймлайн»]]

За допомогою Таймлайну можна показати красиво розвиток в часі дій.

Приклад:

* https://adminlte.io/themes/AdminLTE/pages/UI/timeline.html

== Тулбари ==

[[Файл:K2_UI_Standards_2025_04.png|міні|центр|Ілюстрація до розділу «Тулбари»]]

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

* Приклад: https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxtoolbar/index.htm#demos/jqxtoolbar/defaultfunctionality.htm

== Закладки (TabStrip) ==

[[Файл:K2_UI_Standards_2025_05.png|міні|центр|Ілюстрація до розділу «Закладки (TabStrip)»]]

Дозволяють розташувати інформацію по різним сторінкам. Розподіляючи інформацію по смислу.

* Приклад: https://demos.telerik.com/kendo-ui/tabstrip/tab-position

== Ribbon-інтерфейс ==

[[Файл:K2_UI_Standards_2025_06.png|міні|центр|Ілюстрація до розділу «Ribbon-інтерфейс»]]

Це інтерфейс в стилі Ms Office 2013.

== Приклади: https://snippet.dhtmlx.com/9ckg47ro?text=Ribbon ==

* https://www.vueribbon.com/home

== Таблиці (гриди) ==

[[Файл:K2_UI_Standards_2025_07.png|міні|центр|Ілюстрація до розділу «Таблиці (гриди)»]]

За допомогою гридів автоматизуються значні частини табличних даних.

Ми використовуємо в своїй практиці PHPGrid та AG-Grid.

Приклади роботи та функціоналу PHPGrid:

* https://www.gridphp.com/demo-center/

Приклади AG-Grid:

* https://www.ag-grid.com/example/

=== Master-Detail ===

[[Файл:K2_UI_Standards_2025_08.png|міні|центр|Ілюстрація до розділу «Master-Detail»]]

Це можливість показати співвідношення таблиць один до багатьох:

Приклад:

* https://www.gridphp.com/demo-center/

=== Під-гридом Master-Detail ===

[[Файл:K2_UI_Standards_2025_09.png|міні|центр|Ілюстрація до розділу «Під-гридом Master-Detail»]]

=== Multy-грід (Tab-грід) ===

[[Файл:K2_UI_Standards_2025_10.png|міні|центр|Ілюстрація до розділу «Multy-грід (Tab-грід)»]]

== Кнопки ==

[[Файл:K2_UI_Standards_2025_11.png|міні|центр|Ілюстрація до розділу «Кнопки»]]

Приклад зовнішнього вигляду кнопок:

* https://adminlte.io/themes/AdminLTE/pages/UI/buttons.html

== Кнопка може мати список (меню) ==

== Кнопки можуть мати картинку на підпис ==

Кнопки можуть розміщуватись не тільки горизонтально, але й вертикально:

== Спліттери (Splitter) ==

[[Файл:K2_UI_Standards_2025_12.png|міні|центр|Ілюстрація до розділу «Спліттери (Splitter)»]]

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

* Приклад: https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxsplitter/index.htm#demos/jqxsplitter/defaultfunctionality.htm

== Карти ==

[[Файл:K2_UI_Standards_2025_13.png|міні|центр|Ілюстрація до розділу «Карти»]]

== Прогрес-бари ==

[[Файл:K2_UI_Standards_2025_14.png|міні|центр|Ілюстрація до розділу «Прогрес-бари»]]

== Слайдери ==

[[Файл:K2_UI_Standards_2025_15.png|міні|центр|Ілюстрація до розділу «Слайдери»]]

За допомогою слайдеру можна вказувати диапазони зміни даних.

* Приклад: https://adminlte.io/themes/AdminLTE/pages/UI/sliders.html

== Звіти (Reports) ==

[[Файл:K2_UI_Standards_2025_16.png|міні|центр|Ілюстрація до розділу «Звіти (Reports)»]]

Звіти - це різновид інформації, яка підготовується для друку.

* Приклад: https://demo.stimulsoft.com/#Net/Order

== PivotGrid (OLAP), BI ==

[[Файл:K2_UI_Standards_2025_17.png|міні|центр|Ілюстрація до розділу «PivotGrid (OLAP), BI»]]

* Приклад: https://demo.stimulsoft.com/#Net/DashboardInsuranceSales2014-2022

== Вікна ==

[[Файл:K2_UI_Standards_2025_18.png|міні|центр|Ілюстрація до розділу «Вікна»]]

Модальне вікно - це вікно, яке виринає та не дає переключитись на інші дії, поки не даш відповідь, яке задає модальне вікно.

* Приклад модальних вікон: https://adminlte.io/themes/AdminLTE/pages/UI/modals.html

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

Елементи вікна повинні теж позіціонуватись так, щоб займати весь простір та легко читатись.

== Suite (комплект) ==

[[Файл:K2_UI_Standards_2025_19.png|міні|центр|Ілюстрація до розділу «Suite (комплект)»]]

Це стилистично росташований комплекс компонент.

* Приклад: https://snippet.dhtmlx.com/85fbitnu?mode=wide

== Додаткові ілюстрації ==

<gallery mode="packed" heights="180">
K2_UI_Standards_2025_20.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_20.png
K2_UI_Standards_2025_21.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_21.png
K2_UI_Standards_2025_22.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_22.png
K2_UI_Standards_2025_23.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_23.png
K2_UI_Standards_2025_24.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_24.png
K2_UI_Standards_2025_25.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_25.png
K2_UI_Standards_2025_26.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_26.png
K2_UI_Standards_2025_27.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_27.png
K2_UI_Standards_2025_28.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_28.png
K2_UI_Standards_2025_29.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_29.png
K2_UI_Standards_2025_30.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_30.png
K2_UI_Standards_2025_31.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_31.png
K2_UI_Standards_2025_32.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_32.png
K2_UI_Standards_2025_33.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_33.png
K2_UI_Standards_2025_34.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_34.png
K2_UI_Standards_2025_35.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_35.png
K2_UI_Standards_2025_36.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_36.png
K2_UI_Standards_2025_37.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_37.png
K2_UI_Standards_2025_38.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_38.png
K2_UI_Standards_2025_39.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_39.png
K2_UI_Standards_2025_40.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_40.png
K2_UI_Standards_2025_41.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_41.png
K2_UI_Standards_2025_42.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_42.png
K2_UI_Standards_2025_43.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_43.png
K2_UI_Standards_2025_44.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_44.png
K2_UI_Standards_2025_45.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_45.png
K2_UI_Standards_2025_46.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_46.png
K2_UI_Standards_2025_47.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_47.png
K2_UI_Standards_2025_48.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_48.png
K2_UI_Standards_2025_49.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_49.png
K2_UI_Standards_2025_50.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_50.png
K2_UI_Standards_2025_51.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_51.png
K2_UI_Standards_2025_52.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_52.png
K2_UI_Standards_2025_53.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_53.png
K2_UI_Standards_2025_54.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_54.png
K2_UI_Standards_2025_55.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_55.png
</gallery>

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

* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[UI]]
* [[UX]]
* [[Адміністративна панель]]
* [[Таблиці]]
* [[Грід]]

[[index.php?title=Категорія:K2 ERP]]
[[index.php?title=Категорія:UI]]
[[index.php?title=Категорія:Стандарти K2]]
[[index.php?title=Категорія:Документація K2]]

Класи та команди K2 ERP Python

2026-04-28T21:14:09Z

R: Прибрав шаблон

'''K2 Cloud ERP Python для розробників''' — документація з вимогами до створення компонентів, структури пакетів, системних класів, API, компонентних класів і допоміжних JavaScript-функцій системи [[K2 Cloud ERP]].

__TOC__

== K2 Cloud ERP Python ==

Команда для автоматичної генерації html файлу з документацією по док стрінгах:
pydoc -w k2/k2obj.py, де k2/k2obj.py - шлях до файлу з корня

== Вимоги до створення компонент ==

==== Компоненти, які публікуються в K2 Cloud ERP повинні мати щонайменше такі атрибути ====

ORM структури. Структури, які потрібні для даної компоненти. (файл models.py)

==== Головний клас компоненти, роути та api (файл views.py) ====

Додаткові об’єкти компоненти. Додаткові класи від яких залежить функціонал компоненти. (каталог objects/)

Хуки. Використовуються для розширення або зміни поведінки стандартних методів системи (файл hooks.py)

Зележності від інших компонент. (файл requirements-components.txt)
приклад:

<pre>
k2log==2.0.0.2
k2grid==2.0.4.1
k2form==2.0.1.27
</pre>

Python залежності, якщо є. (файл requirements.txt)

Readme.md. Файл в якому написана ціль компоненти, як її використовувати. Та різні моменти, які потрібно знати програмістам, адмінам та користувачам

Історія змін. Документ, в якому описуються зміни текстом, зрозумілим для користувачів. (файл history.txt)

Структура бази даних. На даний час, в форматі SQL power Architech. (каталог doc/schema)

Бізнес-процеси, схеми роботи, які були втілені в проудкті. В форматі Draw.io. (каталог doc/business_processes)

Інструкція користувача. Де розписано, як користуватись продуктом. Інструкція користувача повинна автоматично підтягуватись системою документації K2 Cloud ERP, додаючи розділ документації для цього продукту і надаючи можливість пошуку інформації в документації. Зберігається в каталозі: doc/user_manual)

Документацію для розробників, що генерується автоматично з коментарів. Зберігається в каталозі: doc/developer_documentation )

(потрібно завершити автоматичне збирання із компонент)

Документація для розробників (не обов’язково, але желательно). Додатково, якщо потрібно, щось додатково відмітити. Каталог doc/additional_developer_docs)

Приклади програмного коду з використанням компонент. Які автоматично з’являються в Examples при встановленні компоненти. І по яким можна протестувати функціонал. /examples (потрібно вирішити як додавати)

Віджети. Дашборди та інші візуальні елементи для вставки на головну сторінку та інші сторінки, які можна додавати автоматично. (потрібно вирішити як додавати) /widgets

Юніт тести. Написати де і яка структура. Юніт тести повинні автоматично знаходитись системою і використовуватись для загального тестування системи. Каталог /tests (потрібно завершити автоматичне збирання із компонент)

Локалізації. В К2 використовуються щонайменше: українська та англійська мова. Ядро повинно вміти робити переклади і давати можливість працювати з перекладами стороннім користувачам, покращуючи якість перекладу. Зберігається в каталозі:

<pre>
/languages/en/LC_MESSAGES/messages.po
/languages/en/LC_MESSAGES/messages.mo
</pre>

Демо-дані. Це дані, які розгортаються на демо-базі даних для демонстрації роботи з продуктом. (потрібно вирішити як додавати)

Файли ресурсів (зображення, тексти): Каталог /static

YML, якщо є. Каталог /yml

Іконки, які будуть використовуватись для представлення компоненти. Каталог /static/img

Авторство. Якщо К2, то в форматі, як прийнято в цілому для К2, якщо сторонній розробник - інформація про стороннього розробника. Copyright © 2000-2025 К2®, Rudiuk Serhii. All rights reserved.

Шаблони, якщо є. Вказуємо каталог. Звертаю увагу, що К2 Cloud ERP повинна мати змогу використовувати не обмежену кількість шаблонів. Шаблони повинні бути так розроблені, щоб не конфліктувати з глобальними шаблонами системи. Каталог /templates

==== Приклад дерева структури компоненти ====

<pre>
components/
└── k2adm/
├── k2adm/
│ ├── data/
│ ├── languages/
│ ├── static/
│ ├── templates/
│ ├── yml/
│ ├── tests/
│ ├── examples/
│ ├── widgets/
│ ├── __init__.py
│ ├── objects/
│ ├── users/users.py
│ ├── roles/roles.py
│ ├── forms.py
│ ├── history.txt
│ ├── hooks.py
│ ├── models.py
│ ├── views.py│
├── __init__.py
├── doc/
├── schema/
├── business_processes/
├── user_manual/
├── developer_documentation/
├── additional_developer_docs/
├── history.txt
├── requirements-components.txt
├── requirements.txt
├── setup.py
</pre>

== Системні класи ==

=== Клас K2 ===

Ядро системи K2CloudERP.

==== Властивості ====

==== Властивості класу ====

domain_name #назва домену

domain_protocol #протокол

domain #домен

port #порт

db #підключення до БД

default_language #мова за замовчуванням

==== Властивості інстансу ====

==== self.secur #властивість що підключає до ядра клас безпеки ====

self.path #властивість що підключає до ядра клас пошуку шляхів по ієрархії self.data #властивість що підключає до ядра клас синхронізації даних

==== self.settings #властивість що підключає до ядра клас збереження та пошуку налаштувань ====

==== self.notifications #властивість що підключає до ядра клас створення та відправки сповіщень ====

<pre>
#отримати домен
</pre>

==== K2().domain ====

==== Методи ====

==== Методи інстансу ====

Приклад використання:

<pre>
#отримати id поточного контрагента
</pre>

==== K2().get_user_counterparts_id() ====

<pre>
# отримати список встановлених компонент
</pre>

==== K2().component_list() ====

<pre>
# отримати назву поточного проекту
</pre>

==== K2().get_user_project_name() ====

<pre>
#отримати id поточного користувача
</pre>

==== K2().get_current_user() ====

<pre>
#створити користувача на рівні БД
</pre>

==== K2().create_db_role(user_name, password) ====

==== __init__(self, *args, **kwargs) ====

Initialize self. See help(type(self)) for accurate signature.

==== add_authorized_users(self, user_id, login) ====

Додати користувача до списку авторизованих

==== check_authorized_users(self, user_id) ====

Перевірити чи користувач активний

==== check_logout_users(self, user_id) ====

Авторизовані користувачі

==== component_list() ====

Пошук встановлених компонент

==== create_db_file_config_user(self) ====

Створення файлу з параметрами підключенням до БД для користувача

==== create_db_role(self, user_name, password) ====

Створення користувача на рівні БД

==== current_template(self) ====

Search current template

==== db_custom_engine(self, db) ====

Зміна custom параметрів підключення

==== db_user_engine(self, db) ====

Зміна параметрів підключення для поточного користувача

==== dell_authorized_users(self, user_id) ====

Видалити користувача зі списку авторизованих

==== drop_db_role(self, user_name) ====

Видалення користувача на рівні БД

==== get_all_subclasses(cls) ====

==== Пошук підкласів ====

==== get_authorized_users(self) ====

Отримати список авторизованих користувачів

==== get_current_user(self) ====

Повертає об’єкт поточного користувача

==== K2().get_current_user() ====

==== get_menu_url(self) ====

Повертає список url активних пунктів меню

==== get_project_setting(self) ====

Форма зміни проекту

==== get_user_counterparts_id(self) ====

Пошук id поточного контрагента

==== K2().get_user_counterparts_id() ====

==== get_user_counterparts_name(self) ====

Пошук назви поточного контрагента

==== K2().get_user_counterparts_name() ====

==== get_user_project_id(self) ====

Пошук id поточного проекту користувача

==== K2().get_user_project_id() ====

==== get_user_project_name(self) ====

Пошук назви поточного проекту користувача

==== K2().get_user_project_name() ====

==== get_user_stoages_name(self) ====

Пошук назви поточного складу

==== K2().get_user_stoages_name() ====

==== get_user_storage_id(self) ====

Пошук id поточного складу

==== K2().get_user_storage_id() ====

==== get_user_structural_division_id(self) ====

Пошук id поточного підрозділу

==== K2().get_user_structural_division_id() ====

==== get_user_structural_division_id_tree(self) ====

Пошук всіх підрозділів за ієрархією від поточного підрозділу користувача у форматі tuple ('id1', 'id2', 'id3')

==== init_db(self) ====

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

==== init_db_custom(self, key) ====

Підключення custom db_uri за ключем.

==== init_db_uri(self) ====

Пошук і ініціалізація файлу з підключення до бази даних

==== init_db_uri_custom(self) ====

Зчитує всі підключення до бази даних з файлу db_custom.yml і зберігає їх у словник.

==== init_db_uri_user(self) ====

Пошук і ініціалізація файлу з підключення до бази даних для поточного користуача

==== init_db_user(self) ====

Підключення db_uri для користувача

==== init_lm(self, app) ====

Ініціалізація логін-менеджера

==== kill_user_sessions(self, target_username) ====

Завершення сесії підключення користувача на рівні БД

==== search_class_dict(self, parent_class=None) ====

==== Рекурсивний пошук властивостей нащадків базового класу ====

==== search_class_prop(path_objs) ====

<pre>
# Отримуємо значення з path_objs для розширення поточного класу
</pre>

==== search_menu_items(self) ====

Search menu items

==== search_menu_items_category(self) ====

Search menu items category

==== search_static_files(self) ====

==== url_map(self) ====

==== Методи класу ====

Приклад використання:

<pre>
id = K2.generate_id()
usr_perm = K2().get_user_permissions()
K2.get_platform()
yml_path = K2.search_yml('users')
</pre>

==== clear_logging_messages() ====

Clear all logging message by user

==== compare_versions(version1, version2) ====

порівняння версій

==== create_system_settings() ====

==== dump_stacks() ====

Request information about the running threads of the current process.

:return: A tuple containing:

* A sequence of text lines detailing the stacks of running

threads and greenlets. (One greenlet will duplicate one thread,

the current thread and greenlet.)

* The number of greenlets.

==== generate_id() ====

Генерація ID

==== get_active_lang_list() ====

Визначення id поточної мови

==== get_current_user_role_name() ====

Отрмання rolename поточного користувача

==== get_locale() ====

Визначення поточної мови

==== get_locale_id() ====

Визначення id поточної мови

==== get_path_abs(caller_file) ====

Абсолютний шлях до файлу, в якому виконується код.

Виклик K2.get_path_abs(__file__)

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

==== get_path_to_root(caller_file) ====

Відносний шлях до рута.

Виклик K2.get_path_to_root(__file__).

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

==== get_platform() ====

Визначення операційної системи

==== get_user_permissions() ====

Retrieve user permissions based on the URL.

This method fetches permissions for the current user based on the URL they are accessing.

Returns:

dict: A dictionary containing the user permissions, including 'roleid' and various permission flags

such as 'r' (read), 'w' (write), 'i' (insert), 'd' (delete), 'c' (create), 'exp' (export), 'imp' (import), 'del_' (undelete), 'settable' (set table), 'cutpast' (cut and paste), 'enable' (enable), and 'active' (active).

If the user is a superadmin, a default set of permissions is returned.

If no permissions are found for the user, an empty dictionary is returned.

Raises:

Exception: If an error occurs during database query execution.

Usage:

<pre>
current_user_permissions = K2().get_user_permissions()
</pre>

==== get_user_role(user_id) ====

Отрмання roleid користувача

==== ins_search_comp() ====

Вивід списку компонент з файлу components.yml у всіх шляхах пошуку

==== load_babel_translation_directories() ====

Завантаження перекладів

==== load_logging_message_by_id(error_id: str) ====

Load a logging message by its error_id from the error log file.

Parameters:

error_id (str): The ID of the error to load.

Returns:

dict: The logging message if found, None otherwise.

==== load_logging_messages(page_url: str) ====

Load logging messages for the curren page from the error log file.

Parameters:

name (str): Name of the object (page) to load messages for.

Returns:

dict: A dictionary containing formatted log messages, the count of 'error' messages, and the count of 'warning' messages.

==== log_entry(error_id, status, message, name) ====

==== logging_message(status, message, page_url=None, show_message=True) ====

Send a logging message to the client via Socket.IO.

This method emits a message to the client with a given status and message content.

The message is sent to a room identified by the current user's ID.

Parameters:

status (str): The status of the message (e.g., cls.log_error - 'ERROR', cls.log_warning - 'WARNING', cls.log_success - 'SUCCESS').

message (str): The content of the message to be sent.

<pre>
page_url(str): url of page with Errors.
</pre>

show_message (bool): True - save log and show windows, False - only save_log

Приклад використання функції:

K2.logging_message(K2.log_error, 'Operation completed with error.')

K2.logging_message(K2.log_success, 'Operation completed successfully.'1)

<pre>
K2.logging_message(status=K2.log_success, message='Operation completed successfully.', page_url='/kadm/users', show_message=False)
</pre>

Example:

==== namemenu(url) ====

Add identificators to url page

==== save_logging_message(error_id, status, message, name) ====

Save a logging message to the stack.

Parameters:

status (str): The status of the message (e.g., cls.log_error - 'ERROR', cls.log_warning - 'WARNING', cls.log_success - 'SUCCESS').

message (str): The content of the message to be saved.

name (str): Name of object where the message originated.

==== search_babel_translation_directories() ====

Пошук файлів з перекладами

==== search_comp_names() ====

Вивід списку ідентифікаторів компонент

у всіх шляхах пошуку

Rerurn: list of components identificators

==== search_yml(name_yml) ====

Search for a yml file in the caller directories of subclasses.

This method searches for a yml file with a specified name in the caller directories of all subclasses of K2Obj.

The search is performed in the 'yml' subdirectory of each caller directory.

Args:

name_yml: The name of the yml file to search for (without the '.yml' extension).

Returns:

The caller directory where the yml file was found, or None if the file was not found.

Usage:

To search for a yml file named 'users.yml', call this method as follows:

K2.search_yml('users')

== API ==

=== Клас K2Obj ===

З цього класу створюються всі об’єкти системи К2. Він має основну базову функціональність, що розширюється та розвивається та яка є у всіх класів системи

==== Властивості ====

==== Властивості класу ====

name #Назва компоненти.

version #Версія компоненти

==== Властивості інстансу ====

self._name_yml #назва конфігураційного файлу

self._name_yml_tree #назва конфігураційного файлу з деревом

self._new_buttons #назва кнопки

self._name_yml_master #назва конфігураційного файлу

self._send_params #параметри для конфігураційного файлу

self._send_group_params #параметри групи

self._report_id #id звіту

self._data_source #датасети

self._off_buttons #вимкнути кнопки

self._row_selection #вибір з рядка

==== Методи ====

==== Методи інстансу ====

Приклад використання:

==== __init__(self) ====

Initialize self. See help(type(self)) for accurate signature.

==== content(self) ====

==== create_names_yml(self, name_yml: str = '', name_yml_tree: str = '', ====

<pre>
name_yml_master: str = '')
</pre>

==== search_class_prop(path_objs) ====

==== Пошук властивостей для розширення класу ====

==== select_grid(self) ====

==== show_grid(self) ====

== API ==

=== Клас K2admin_menus ===

==== Даний клас формує список пунктів меню для конкретного користувача ====

=== Клас k2data ===

=== Клас k2datasync ===

=== Клас k2logging ===

==== Класk2mail ====

==== Класk2notifications ====

=== Клас k2path ===

=== Клас k2secur ===

=== Клас k2settings ===

=== Клас k2trans ===

=== Клас k2upd ===

== Класи компонент ==

=== Клас K2Site ===

=== Клас K2Grid ===

=== Клас K2WMS ===

=== K2UpdateRemainder ===

=== Клас для оновлення залишків на основі даних з отриманих від клієнтів. ===

Відповідає за обробку даних з логів, створення/оновлення записів про залишки товарів та керування їх статусами (новий, стабільний, старий).

==== Методи ====

==== __init__() ====

Ініціалізація класу.
Викликає конструктор батьківського класу K2Docs.

Параметри:
Відсутні.

Повертає:
Об'єкт класу K2UpdateRemainder.

==== update_pub_sub_remainder() ====

Оновлення залишків на основі даних Pub/Sub.
Витягує нові залишки з логів, додає їх у таблицю k2remainder_by_parties, оновлює статуси існуючих записів та видаляє застарілі залишки.

Логіка статусів:

'new' – нові залишки, отримані в поточному оновленні.

'stable' – залишки, які підтвердились та доступні користувачам.

'old' – застарілі дані, що підлягають видаленню.

Алгоритм роботи:

Отримує список pub_sub_list_id з логів k2pubsub_logs.

Витягує дані про залишки (inventSumLines).

Вставляє нові записи у таблицю k2remainder_by_parties зі статусом 'new'.

Масово оновлює статуси залишків:

Видаляє застарілі ('old').

Переводить стабільні ('stable') в старі ('old').

Нові ('new') переводить у стабільні ('stable').

Фіксує зміни у базі (commit).

У разі помилки виконує відкат (rollback).

==== _insert_new_pub_sub_nomenclature(session, nomenclature_data) ====

Додавання нової номенклатури.
Перевіряє наявність номенклатури у таблиці k2nomenclature. Якщо запису немає – створює його.

Параметри:

session (Session) – об'єкт сесії бази даних.

nomenclature_data (dict) – дані про номенклатуру:

itemId (str) – ідентифікатор номенклатури.

itemName (str) – назва товару.

unitId (str) – одиниця виміру (конвертується за фіксованим списком).

Повертає:
Нічого.

Винятки:

Логує помилку у разі невдалої вставки даних.

=== Клас K2CRM ===

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

управління лідами
- замовлення

* рахунки

* звіти

* налаштування системи CRM

=== Клас K2CRM наслідується від K2Obj, всі властивості та методи отримуються від батьківського класу. ===

=== K2DocsCRM ===

=== Клас K2DocsCRM є частиною системи K2CRM і наслідується від K2Obj. Він надає доступ до ключових глобальних налаштувань та ресурсів, необхідних для роботи з документами або іншими функціями CRM. ===

==== Атрибути ====

database:

База даних, доступна через глобальний об'єкт K2.db.

Призначення: Використовується для зберігання та обробки даних, пов'язаних з CRM.

time_zone:

Часовий пояс системи, визначений глобальним об'єктом K2.timezone.

Призначення: Забезпечує коректну обробку часу в межах системи.

domain:

Домен, на якому працює CRM, отримується з глобального об'єкта K2.domain.

Призначення: Використовується для побудови URL-адрес або інших задач, пов'язаних з доменним середовищем.

==== Властивості ====

==== Методи ====

<pre>
create_contact() - Цей метод створює контакт на основі даних існуючого ліда. Лід і контакт взаємодіють через базу даних, де дані ліда переносяться в таблицю контактів.
</pre>

Логіка роботи:

==== Метод очікує вхідний JSON, що містить ідентифікатор ліда (lead_id) ====

Перевіряє чи було надано lead_id. Якщо lead_id не надано то повертається помилка.

Шукає ліда в таблиці k2lead за наданим параметром.

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

У разі помилки скасовує транзакцію і повертає опис помилки.

==== Моделі які використовуються ====

K2Lead. Таблиця яка містить дані про лідів.

k2contacts. Таблиця, в яку додається новий контакт на основі даних ліда.

<pre>
check_lead() - Цей метод перевіряє, чи існує контакт із заданим номером телефону у базі даних (k2contacts). Якщо знайдено, оновлює дані ліда (ім'я, прізвище, email) у переданому об'єкті.
</pre>

Логіка роботи:

Отримає вхідний JSON, що містить options із даними для перевірки.

З options[‘dataField’] отримує номер телефону (phone)

Виконує SQL-запит до таблиці k2contacts для пошуку контакту за номером телефону.

Якщо контакт знайдено то відбувається оновлення даних у options[‘dataField’] (name, surname, email, lead_id)

Якщо контакт не знайдено то для полів name, surname, email встановлюється значення None.

У разі помилки повертає повідомлення з помилкою.

<pre>
crm_data(route, data) - Цей метод отримує дані із відповідних таблиць з бази даних на основі переданих параметрів для подальшого оформлення друкованої форми документів у компоненті k2CRM
</pre>

Логіка роботи:

Створює порожній словник result_dict, який буде наповнюватись даними та парсить вхідні дані data у форматі JSON і зберігає їх у result_dict[‘Header’].

Формує SQL-запити для витягування даних із таблиць бази даних (Товари, Організація, Контрагент, Склад, Договір, Відповідальна особа, Клієнт).

Для кожного запиту виконується SQL-запит та результат додається до result_dict.

Результати запитів конвертуються у словники (row_asdict) для зручного JSON-формату.

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

process_options - Метод обробляє різні параметри, передані через JSON-запит, і налаштовує об'єкти типу K2Grid для роботи з даними в залежності від значення ключа name у вхідних даних.

Основні операції:

Обробка k2doc_rows_detail:

Ім'я YML: 'k2doc_rows_detail'.

Вимикаються кнопки: add, delete, printReport.

Передаються параметри: row_id та storage_id.

Обробка k2doc_move:

Ім'я YML: 'k2doc_move'.

Вимикаються кнопки: add, edit, delete, printReport.

Передаються параметри: doc_id.

Логіка роботи:

Метод очікує вхідні дані у форматі JSON і доступ до них здійснюється через request.json.

Перевіряється значення ключа name у вхідних даних:

<pre>
Якщо name == 'k2doc_rows_detail':
Виділяється row_id із переданих даних. Створюється об’єкт K2Grid з іменем yml “'k2doc_rows_detail”. Вимикаються кнопки add, delete, printReport на панелі інструментів. Отримується storage_id через метод self.get_storage_id(). Параметри row_id та storage_id передаються через send_params.
Якщо name == 'k2doc_move':
</pre>

Виділяється doc_id із вхідних даних. Створюється об'єкт K2Grid з іменем yml 'k2doc_move'. Вимикаються кнопки add, edit, delete, printReport на панелі інструментів. Параметри (doc_id) передаються через send_params.

Повернення результату у форматі JSON

=== Клас K2Report ===

Цей клас забезпечує генерацію та друк звітів за допомогою API Stimulsoft.

==== Основні можливості модуля ====

створення звітів за допомогою конструктора звітів

управління друкованими формами

генерація друкованих документів

==== взаємодія з API Stimulsoft для візуалізації та експорту звітів ====

=== Клас K2Report наслідується від K2Obj, всі властивості та методи отримуються від батьківського класу.
Також клас K2Report є батьківським класом для K2ReportEmbed та K2ReportDesigner ===

==== Атрибути класу ====

==== Методи класу ====

==== __init__(sql=[]) ====

Ініціалізація класу. Отримує шлях до каталогу файлу, що викликав ініціалізацію.

Параметри:

sql (list, опціонально): Список SQL-запитів.

==== create_report(sql=None, data_source=None) ====

Створення звіту. Відображає HTML-сторінку редактора або переглядача звітів.

Параметри:

sql (dict, опціонально): SQL-запити.

data_source (dict, опціонально): Джерело даних.

Повертає:

HTML-сторінку редактора або переглядача звітів.

==== get_report(file_name) ====

Отримання звіту за його ім'ям.

Параметри:

file_name (str): Назва файлу звіту.

Повертає:

Файл звіту або помилку 404, якщо файл не знайдено.

==== execute_query(query, params=None) ====

Виконує SQL-запит.

Параметри:

query (str): SQL-запит.

params (dict, опціонально): Параметри запиту.

Повертає:

Результат виконання запиту.

==== get_report_designer(file_name, design_type_id) ====

Отримує дизайнер звіту за типом звіту.

Параметри:

file_name (str): Назва файлу.

design_type_id (str): Тип дизайну (1 - звіт, 2 - дашборд).

Повертає:

Файл дизайну або помилку 404.

==== add_reports_type(name, data) ====

Додає тип звіту до групи звітів.

Параметри:

name (str): Назва типу звіту.

data (dict): Дані для оновлення.

Повертає:

bool: True, якщо успішно.

=== Клас K2ReportEmbed ===

K2ReportEmbed - Компонент для вбудовування звітів у веб-додаток. Дозволяє отримувати та відображати звіти з бази даних на основі їх ідентифікаторів.

==== Атрибути класу ====

==== __init__(reports_id: List[str]) ====

Ініціалізує екземпляр класу K2ReportEmbed.

Аргументи:

reports_id (List[str]) – список ідентифікаторів звітів.

==== get_report_data() -> Optional[List[Dict[str, Any]]] ====

Отримує дані звітів з бази даних.

Повертає:

Optional[List[Dict[str, Any]]] – список даних звітів або None, якщо сталася помилка.

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

report_name – Назва звіту.

file_name – Ім'я файлу звіту.

json_data_list – JSON-структура, що містить дані для звіту.

Якщо під час виконання запитів виникає помилка, вона логуватиметься у системному журналі помилок

Приклад вбудовування звітів на веб-сторінку

==== Бекенд (Flask) ====

<pre>
@k2production.route('/test_dashboard', methods=['GET'])
def test_dashboard():
</pre>

""" Index page """

<pre>
reports_id = ['b452a5ae84f9e92e75eb0467c196fd71', '1673a4fab757fb6c5df970fdc6ee680c',
</pre>

'49952f397efff44d7ce0e5cb9aa625fb']

<pre>
k2report_embed = K2ReportEmbed(reports_id)
return render_template('k2dashboard_production/k2dashboard_production.html',
dashboard_settings=k2report_embed)
</pre>

==== Фронтенд (Jinja-шаблон) ====

<pre>
{% extends template_name + '/base.html' %}
{% block content %}
{% if error %}
{{ error }}
{% else %}
{% include dashboard_settings.template %}
{% endif %}
{% endblock %
</pre>

=== Клас K2ReportDesigner ===

=== Клас K2ReportDesigner надає функціональність для створення, редагування та перегляду звітів і дашбордів. Він взаємодіє з базою даних, управляє файлами звітів та генерує JSON-дані для подальшого використання. ===

==== Атрибути класу ====

==== Методи класу ====

==== designer() ====

Відображає сторінку редагування друкованої форми.

Повертає:

str: HTML-шаблон сторінки редагування.

==== viewer() ====

Відображає сторінку перегляду друкованої форми.

Повертає:

str: HTML-шаблон сторінки перегляду.

==== dashboard_viewer() ====

Відображає сторінку перегляду дашборду.

Повертає:

str: HTML-шаблон сторінки перегляду дашборду.

==== dashboard_designer() ====

Відображає сторінку редагування дашборду.

Повертає:

str: HTML-шаблон сторінки редагування дашборду.

<pre>
json_data_create(datasource_value, datasource_keys, datasource_is_counterpart_id, datasource_is_storage_id, period, date_from=None, date_to=None)
</pre>

Створює JSON-дані на основі джерел даних та періоду.

Параметри:

datasource_value (list): Список SQL-запитів.

datasource_keys (list): Список ключів для джерел даних.

datasource_is_counterpart_id (list): Список флагів, що вказують на наявність counterpart_id.

datasource_is_storage_id (list): Список флагів, що вказують на наявність storage_id.

period (int): Період вибірки даних.

date_from (str, опціонально): Початкова дата періоду.

date_to (str, опціонально): Кінцева дата періоду.

Повертає:

dict: Словник з результатами запитів або помилкою.

==== Приклад використання ====

<pre>
datasource_value = ["SELECT * FROM table1", "SELECT * FROM table2"]
datasource_keys = ["table1_data", "table2_data"]
datasource_is_counterpart_id = [True, False]
datasource_is_storage_id = [False, True]
period = 1
date_from = "2023-01-01"
date_to = "2023-12-31"
json_data = k2_designer.json_data_create(datasource_value, datasource_keys, datasource_is_counterpart_id, datasource_is_storage_id, period, date_from, date_to)
</pre>

==== save_report_id() ====

Зберігає ідентифікатор та налаштування звіту в JSON-файл.

Повертає:

Response: JSON-відповідь про результат збереження.

==== mrt_report_create(report_id, design_type_id=None) ====

Створює MRT-файл звіту на основі шаблону.

Параметри:

report_id (str): Ідентифікатор звіту.

design_type_id (str, опціонально): Тип дизайну звіту.

Повертає:

str: Ім'я створеного файлу або помилка.

==== table_report_data(datasource_value, datasource_keys) ====

Обробляє дані з SQL-запитів для кожного джерела даних і повертає їх у вигляді JSON.

Параметри:

datasource_value (list): Список SQL-запитів для виконання.

datasource_keys (list): Список ключів, які відповідають кожному SQL-запиту.

Повертає:

dict: Словник, де ключі — це значення з datasource_keys, а значення — дані у форматі JSON для кожного запиту.

==== save_info_report_designer() ====

Зберігає інформацію про репорт та генерує файл MRT.

Повертає:

Response: JSON-об'єкт із результатами генерації звіту та повідомленням про успішність.

==== data_source_lists_creating(group_reports_id) ====

Створює списки джерел даних для звіту.

Параметри:

group_reports_id (str): Ідентифікатор групи звітів.

Повертає:

list: Списки джерел даних.

=== Клас K2Production ===

==== Методи класу ====

Схема вибору обслуговування терміналу

=== Клас K2LogbookTMDoc ===

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

==== Методи класу ====

==== k2logbook_tm() ====

Відображає сторінку логбука технічного обслуговування.
Повертає:
str: HTML-шаблон сторінки логбука.

==== take_logbook_tm(task_id) ====

Створює форму логбука для конкретного завдання.
Параметри:

task_id (str): Ідентифікатор завдання.

Повертає:
str: HTML-шаблон форми логбука.

==== edit_logbook_tm(logbook_fields_tm_id) ====

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

logbook_fields_tm_id (str): Ідентифікатор запису логбука.

Повертає:
str: HTML-шаблон сторінки редагування.

==== select_current_step(connection, logbook_fields_tm_id) ====

Вибирає поточний активний крок логбука.
Параметри:

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

logbook_fields_tm_id (str): Ідентифікатор запису логбука.

Повертає:
str: Ідентифікатор поточного кроку.

==== planned_tm(data, connection) ====

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

data (dict): Дані завдання.

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

Повертає:
dict: Налаштування grid.

==== unplanned_tm(data, connection) ====

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

data (dict): Дані завдання.

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

Повертає:
dict: Налаштування grid.

==== write_logbook_params(data) ====

Зберігає параметри логбука в JSON-файл.
Параметри:

data (dict): Дані для збереження.

Повертає:
JSON: Відповідь про успішне збереження.

==== read_logbook_params() ====

Зчитує параметри логбука з JSON-файлу поточного користувача.
Повертає:
dict: Збережені параметри логбука.

==== fill_logbook_tm_rows(data) ====

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

data (dict): Параметри для заповнення рядків.

Повертає:
bool: True при успішному заповненні, False при помилці.

==== pull_spare_parts_data() ====

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

==== send_params_to_k2logbook_spare_parts(data) ====

Формує параметри та SQL-запит для отримання даних про запчастини.
Параметри:

data (dict): Параметри логбука.

Повертає:
dict: Інформація про запчастини або False при помилці.

==== instruments_and_equipment_parts_params() ====

Отримує параметри інструментів та запчастин для обладнання.
Повертає:
JSON: Відповідь з результатом операції або повідомленням про помилку.

==== task_step_form() ====

Формує форму кроку завдання технічного обслуговування.
Повертає:
JSON: Відповідь з параметрами кроку або повідомленням про помилку.

==== is_unplanned_step_form(step_data) ====

Обробляє форму кроку для позапланованого ТО.
Параметри:

step_data (dict): Дані кроку.

Повертає:
str: ID кроку або JSON з помилкою.

==== save_step(data) ====

Зберігає дані кроку (номенклатуру).
Параметри:

data (dict): Параметри кроку.

Повертає:
bool: True при успіху, False при помилці.

==== end_step(data, session_id, connection, post_request) ====

Завершує крок ТО. Обробляє запчастини, час, статус.
Параметри:

data (dict): Дані кроку.

session_id (str): ID сесії.

connection (опціонально): Підключення до БД.

post_request (bool): Чи це постобробка.

Повертає:
JSON або False.

==== step_image_check(connection, data) ====

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

connection: Підключення до БД.

data (dict): Дані кроку.

Повертає:
bool: True (є зображення), False (немає або помилка).

==== step_data_check(connection, data) ====

Перевіряє коректність даних про запчастини.
Параметри:

connection: Підключення до БД.

data (dict): Дані кроку.

Повертає:
bool: True (дані валідні), False (невалідні або помилка).

==== decline_task() ====

Відхиляє завдання. Деактивує запис у логбуці.
Повертає:
JSON: Результат операції.

==== write_user_comment() ====

Додає коментар користувача до кроку.
Повертає:
JSON: Результат збереження.

==== end_step_manager(data) ====

Керує завершенням кроку. Перевіряє матеріали, зображення.
Параметри:

data (dict): Дані кроку.

Повертає:
bool: True (успіх), False (помилка).

==== detail_check(connection, data) ====

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

connection: Підключення до БД.

data (dict): Дані кроку.

Повертає:
bool: True (відповідність є), False (немає або помилка).

==== send_params_to_k2mount_point_form() ====

Формує параметри для форми монтажних точок обладнання.
Повертає:
JSON: Параметри форми (точки монтування, URL зображення схеми).

==== change_scheme_equipment() ====

Оновлює схему обладнання шляхом заміни монтажних точок.
Повертає:
JSON: Результат операції.

==== pass_familiarisation() ====

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

==== create_write_off_act_logbook(connection, data) ====

Створює акт списання для логбука.
Параметри:

connection: Підключення до БД.

data: Дані для акту.

Повертає:
bool: True (акт створено), False (помилка).

==== create_doc_rows_for_write_of_act(connection, data) ====

Створює рядки документу для акту списання.
Параметри:

connection: Підключення до БД.

data: Дані документу.

Повертає:
bool: True (рядки створено), False (помилка).

==== write_off_part_logbook(connection, data) ====

Списати частину обладнання з логбука.
Параметри:

connection: Підключення до БД.

data: Дані для списання.

Повертає:
Нічого (помилки обробляються через rollback).

==== end_logbook() ====

Завершує роботу з журналом ТО.
Повертає:
JSON: Результат операції (успіх або помилка).

==== spare_parts_check() ====

Перевіряє наявність запасних частин для журналу.
Повертає:
JSON: Результат перевірки (успіх або помилка).

==== equipment_qr_confirmation() ====

Підтверджує відповідність QR-коду обладнання.
Повертає:
JSON: Результат перевірки (успіх або помилка).

==== add_new_equipment_parts(connection, data) ====

Додає нові частини обладнання до БД.
Параметри:

connection: Підключення до БД.

data: Дані про частини обладнання.

Повертає:
bool: True (успіх), False (помилка).

==== material_quantity() ====

Отримує інформацію про кількість матеріалів.
Повертає:
JSON: Дані про кількість матеріалів.

==== create_unplanned_task(data) ====

Створює незаплановане завдання.
Параметри:

data: Дані для створення завдання.

Повертає:
bool: True (успіх), False (помилка).

==== take_material_by_qr() ====

Резервує матеріал за допомогою QR-коду.
Повертає:
JSON: Результат операції (успіх або помилка).

==== return_material_by_qr() ====

Повертає матеріал за QR-кодом.
Повертає:
JSON: Результат операції (успіх або помилка).

==== requires_partner() ====

Встановлює статус завдання "потребує партнера".
Повертає:
JSON: Підтвердження операції.

==== join_task() ====

Додає користувача до завдання та змінює статус на "in_work".
Повертає:
JSON: Результат операції.

==== e_report_logbook(logbook_fields_tm_id) ====

Генерує звіт для журналу ТО у форматі HTML.
Параметри:

logbook_fields_tm_id: ID журналу.

Повертає:
HTML: Відображення звіту.

==== get_all_employee_image() ====

Отримує всі зображення журналу.
Повертає:
JSON: Список URL зображень.

==== get_employee_image() ====

Отримує зображення конкретного рядка журналу.
Повертає:
JSON: Список URL зображень.

==== get_image_logbook(image_data) ====

Перетворює шляхи зображень у URL.
Параметри:

image_data: Дані зображень з БД.

Повертає:
list: Список URL

==== confirm_task() ====

Підтверджує завершення завдання. Надсилає сповіщення.
Повертає:
JSON: Результат операції.

==== send_on_revision_task() ====

Надсилає завдання на доопрацювання.
Повертає:
JSON: Підтвердження операції.

==== send_to_the_task_list_revision() ====

Надсилає завдання на доопрацювання та деактивує виконавців.
Повертає:
JSON: Результат операції.

==== change_task_employee(connection, data) ====

Оновлює виконавців завдання.
Параметри:

connection: Підключення до БД.

data: Нові виконавці та рядки.

==== change_step_status_revision(connection, data) ====

Скидає статус виконання кроків.
Параметри:

connection: Підключення до БД.

data: Ідентифікатори кроків.

==== change_task_status_revision(connection, data, status) ====

Змінює статус завдання.
Параметри:

connection: Підключення до БД.

data: Ідентифікатор завдання.

status: Новий статус (за замовчуванням in_work).

=== Клас K2EquipmentFunction ===

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

==== Атрибути ====

path_class: 'components/k2production/k2production/k2equipment'

file_class: 'k2equipment'

==== Методи ====

==== init(self) ====

Конструктор класу, який викликає конструктор батьківського класу K2Obj.

<pre>
send_approval_request_from_hook(self, data) - Метод для відправлення запиту на затвердження змін у технічній карті обладнання.
</pre>

==== Параметри ====

data (dict): Словник з даними, що містить:

equipment_type_id (int): Ідентифікатор типу обладнання

changed_fields (dict): Словник зі зміненими полями та їх значеннями

==== Логіка роботи ====

Перевірка наявності записів з parentid:

<pre>
Перевіряє наявність записів у таблиці k2tm_fields з parentid != '0'
</pre>

Якщо записів немає, повертає помилку 404

Отримання інформації про тип обладнання:

Витягує equipment_type_name та equipment_type_code з таблиці k2equipment_type

Якщо тип обладнання не знайдено, повертає помилку 404

Пошук затверджувачів:

Отримує список активних користувачів для затвердження з таблиці k2users_for_approval

Якщо затверджувачів не знайдено, повертає помилку 404

Формування повідомлення:

Створює опис змін у форматі "поле: старе_значення → нове_значення"

Формує URL для сторінки затвердження

Відправка запиту на затвердження:

<pre>
Використовує K2Notifications.send_approval_request() для відправки повідомлення
</pre>

Передає список затверджувачів, ідентифікатор об'єкта, URL та опис змін

==== Повертає ====

У разі успіху: JSON з повідомленням про успішну відправку (код 200)

У разі помилки: JSON з описом помилки (код 404 або 500)

==== Залежності ====

Потребує доступу до бази даних через self.db

==== Використовує клас K2Notifications для відправки повідомлень ====

Працює з конфігурацією домену через K2.domain

== K2 Cloud ERP Javascript ==

==== createImageSliderModal(images, containerId = null) ====

Створює слайдер зображень у контейнері або модальному вікні.

Параметри:

images: Масив URL-адрес зображень.

containerId: Ідентифікатор контейнера для вставки слайдера (необов’язково).

Повертає:

Ідентифікатор створеного каруселя або модального вікна.

Якщо зображення відсутні, показує повідомлення та повертає null.

==== showBootstrapLoader(containerId) ====

Додає анімацію завантаження у вказаний контейнер.

Параметри:

containerId: Ідентифікатор контейнера, у який буде вставлений індикатор завантаження.

==== removeBootstrapLoader(containerId) ====

Видаляє анімацію завантаження з контейнера.

Параметри:

containerId: Ідентифікатор контейнера, з якого потрібно прибрати індикатор завантаження.

==== showUserAlert(message, type = 'light') ====

Відображає сповіщення користувача у вигляді Bootstrap Toast

.

Параметри:

message: Текст повідомлення. type: Тип сповіщення (primary, success, danger, warning, info, light). За замовчуванням 'light'.

== Стилі (Назва) ==

Подзаголовок

Заголовок 1

Заголовок 2

Заголовок 3

Заголовок 4

Заголовок 5

Заголовок 6

Звичвйний текст

== Ілюстрації з документа ==

<gallery mode="packed" heights="180">
K2_Cloud_ERP_Python_01.png|Ілюстрація K2 Cloud ERP Python|посилання=Файл:K2_Cloud_ERP_Python_01.png
</gallery>

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

* [[K2 Cloud ERP]]
* [[K2 ERP]]
* [[Python]]
* [[API]]
* [[Документація для розробників]]
* [[K2 Cloud ERP Javascript]]

[[index.php?title=Категорія:K2 ERP]]
[[index.php?title=Категорія:K2 Cloud ERP]]
[[index.php?title=Категорія:Python]]
[[index.php?title=Категорія:Документація K2]]
[[index.php?title=Категорія:Документація для розробників]]

Класи та команди K2 ERP Python

2026-04-28T21:13:37Z

R: Створена сторінка: {{Картка документації K2 | назва = K2 Cloud ERP Python для розробників | система = K2 Cloud ERP | мова = Python | тип = Документація для розробників }} '''K2 Cloud ERP Python для розробників''' — документація з вимогами до створення компонентів, структури пакетів, системних класів, API, ко...

{{Картка документації K2
| назва = K2 Cloud ERP Python для розробників
| система = K2 Cloud ERP
| мова = Python
| тип = Документація для розробників
}}

'''K2 Cloud ERP Python для розробників''' — документація з вимогами до створення компонентів, структури пакетів, системних класів, API, компонентних класів і допоміжних JavaScript-функцій системи [[K2 Cloud ERP]].

__TOC__

== K2 Cloud ERP Python ==

Команда для автоматичної генерації html файлу з документацією по док стрінгах:
pydoc -w k2/k2obj.py, де k2/k2obj.py - шлях до файлу з корня

== Вимоги до створення компонент ==

==== Компоненти, які публікуються в K2 Cloud ERP повинні мати щонайменше такі атрибути ====

ORM структури. Структури, які потрібні для даної компоненти. (файл models.py)

==== Головний клас компоненти, роути та api (файл views.py) ====

Додаткові об’єкти компоненти. Додаткові класи від яких залежить функціонал компоненти. (каталог objects/)

Хуки. Використовуються для розширення або зміни поведінки стандартних методів системи (файл hooks.py)

Зележності від інших компонент. (файл requirements-components.txt)
приклад:

<pre>
k2log==2.0.0.2
k2grid==2.0.4.1
k2form==2.0.1.27
</pre>

Python залежності, якщо є. (файл requirements.txt)

Readme.md. Файл в якому написана ціль компоненти, як її використовувати. Та різні моменти, які потрібно знати програмістам, адмінам та користувачам

Історія змін. Документ, в якому описуються зміни текстом, зрозумілим для користувачів. (файл history.txt)

Структура бази даних. На даний час, в форматі SQL power Architech. (каталог doc/schema)

Бізнес-процеси, схеми роботи, які були втілені в проудкті. В форматі Draw.io. (каталог doc/business_processes)

Інструкція користувача. Де розписано, як користуватись продуктом. Інструкція користувача повинна автоматично підтягуватись системою документації K2 Cloud ERP, додаючи розділ документації для цього продукту і надаючи можливість пошуку інформації в документації. Зберігається в каталозі: doc/user_manual)

Документацію для розробників, що генерується автоматично з коментарів. Зберігається в каталозі: doc/developer_documentation )

(потрібно завершити автоматичне збирання із компонент)

Документація для розробників (не обов’язково, але желательно). Додатково, якщо потрібно, щось додатково відмітити. Каталог doc/additional_developer_docs)

Приклади програмного коду з використанням компонент. Які автоматично з’являються в Examples при встановленні компоненти. І по яким можна протестувати функціонал. /examples (потрібно вирішити як додавати)

Віджети. Дашборди та інші візуальні елементи для вставки на головну сторінку та інші сторінки, які можна додавати автоматично. (потрібно вирішити як додавати) /widgets

Юніт тести. Написати де і яка структура. Юніт тести повинні автоматично знаходитись системою і використовуватись для загального тестування системи. Каталог /tests (потрібно завершити автоматичне збирання із компонент)

Локалізації. В К2 використовуються щонайменше: українська та англійська мова. Ядро повинно вміти робити переклади і давати можливість працювати з перекладами стороннім користувачам, покращуючи якість перекладу. Зберігається в каталозі:

<pre>
/languages/en/LC_MESSAGES/messages.po
/languages/en/LC_MESSAGES/messages.mo
</pre>

Демо-дані. Це дані, які розгортаються на демо-базі даних для демонстрації роботи з продуктом. (потрібно вирішити як додавати)

Файли ресурсів (зображення, тексти): Каталог /static

YML, якщо є. Каталог /yml

Іконки, які будуть використовуватись для представлення компоненти. Каталог /static/img

Авторство. Якщо К2, то в форматі, як прийнято в цілому для К2, якщо сторонній розробник - інформація про стороннього розробника. Copyright © 2000-2025 К2®, Rudiuk Serhii. All rights reserved.

Шаблони, якщо є. Вказуємо каталог. Звертаю увагу, що К2 Cloud ERP повинна мати змогу використовувати не обмежену кількість шаблонів. Шаблони повинні бути так розроблені, щоб не конфліктувати з глобальними шаблонами системи. Каталог /templates

==== Приклад дерева структури компоненти ====

<pre>
components/
└── k2adm/
├── k2adm/
│ ├── data/
│ ├── languages/
│ ├── static/
│ ├── templates/
│ ├── yml/
│ ├── tests/
│ ├── examples/
│ ├── widgets/
│ ├── __init__.py
│ ├── objects/
│ ├── users/users.py
│ ├── roles/roles.py
│ ├── forms.py
│ ├── history.txt
│ ├── hooks.py
│ ├── models.py
│ ├── views.py│
├── __init__.py
├── doc/
├── schema/
├── business_processes/
├── user_manual/
├── developer_documentation/
├── additional_developer_docs/
├── history.txt
├── requirements-components.txt
├── requirements.txt
├── setup.py
</pre>

== Системні класи ==

=== Клас K2 ===

Ядро системи K2CloudERP.

==== Властивості ====

==== Властивості класу ====

domain_name #назва домену

domain_protocol #протокол

domain #домен

port #порт

db #підключення до БД

default_language #мова за замовчуванням

==== Властивості інстансу ====

==== self.secur #властивість що підключає до ядра клас безпеки ====

self.path #властивість що підключає до ядра клас пошуку шляхів по ієрархії self.data #властивість що підключає до ядра клас синхронізації даних

==== self.settings #властивість що підключає до ядра клас збереження та пошуку налаштувань ====

==== self.notifications #властивість що підключає до ядра клас створення та відправки сповіщень ====

<pre>
#отримати домен
</pre>

==== K2().domain ====

==== Методи ====

==== Методи інстансу ====

Приклад використання:

<pre>
#отримати id поточного контрагента
</pre>

==== K2().get_user_counterparts_id() ====

<pre>
# отримати список встановлених компонент
</pre>

==== K2().component_list() ====

<pre>
# отримати назву поточного проекту
</pre>

==== K2().get_user_project_name() ====

<pre>
#отримати id поточного користувача
</pre>

==== K2().get_current_user() ====

<pre>
#створити користувача на рівні БД
</pre>

==== K2().create_db_role(user_name, password) ====

==== __init__(self, *args, **kwargs) ====

Initialize self. See help(type(self)) for accurate signature.

==== add_authorized_users(self, user_id, login) ====

Додати користувача до списку авторизованих

==== check_authorized_users(self, user_id) ====

Перевірити чи користувач активний

==== check_logout_users(self, user_id) ====

Авторизовані користувачі

==== component_list() ====

Пошук встановлених компонент

==== create_db_file_config_user(self) ====

Створення файлу з параметрами підключенням до БД для користувача

==== create_db_role(self, user_name, password) ====

Створення користувача на рівні БД

==== current_template(self) ====

Search current template

==== db_custom_engine(self, db) ====

Зміна custom параметрів підключення

==== db_user_engine(self, db) ====

Зміна параметрів підключення для поточного користувача

==== dell_authorized_users(self, user_id) ====

Видалити користувача зі списку авторизованих

==== drop_db_role(self, user_name) ====

Видалення користувача на рівні БД

==== get_all_subclasses(cls) ====

==== Пошук підкласів ====

==== get_authorized_users(self) ====

Отримати список авторизованих користувачів

==== get_current_user(self) ====

Повертає об’єкт поточного користувача

==== K2().get_current_user() ====

==== get_menu_url(self) ====

Повертає список url активних пунктів меню

==== get_project_setting(self) ====

Форма зміни проекту

==== get_user_counterparts_id(self) ====

Пошук id поточного контрагента

==== K2().get_user_counterparts_id() ====

==== get_user_counterparts_name(self) ====

Пошук назви поточного контрагента

==== K2().get_user_counterparts_name() ====

==== get_user_project_id(self) ====

Пошук id поточного проекту користувача

==== K2().get_user_project_id() ====

==== get_user_project_name(self) ====

Пошук назви поточного проекту користувача

==== K2().get_user_project_name() ====

==== get_user_stoages_name(self) ====

Пошук назви поточного складу

==== K2().get_user_stoages_name() ====

==== get_user_storage_id(self) ====

Пошук id поточного складу

==== K2().get_user_storage_id() ====

==== get_user_structural_division_id(self) ====

Пошук id поточного підрозділу

==== K2().get_user_structural_division_id() ====

==== get_user_structural_division_id_tree(self) ====

Пошук всіх підрозділів за ієрархією від поточного підрозділу користувача у форматі tuple ('id1', 'id2', 'id3')

==== init_db(self) ====

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

==== init_db_custom(self, key) ====

Підключення custom db_uri за ключем.

==== init_db_uri(self) ====

Пошук і ініціалізація файлу з підключення до бази даних

==== init_db_uri_custom(self) ====

Зчитує всі підключення до бази даних з файлу db_custom.yml і зберігає їх у словник.

==== init_db_uri_user(self) ====

Пошук і ініціалізація файлу з підключення до бази даних для поточного користуача

==== init_db_user(self) ====

Підключення db_uri для користувача

==== init_lm(self, app) ====

Ініціалізація логін-менеджера

==== kill_user_sessions(self, target_username) ====

Завершення сесії підключення користувача на рівні БД

==== search_class_dict(self, parent_class=None) ====

==== Рекурсивний пошук властивостей нащадків базового класу ====

==== search_class_prop(path_objs) ====

<pre>
# Отримуємо значення з path_objs для розширення поточного класу
</pre>

==== search_menu_items(self) ====

Search menu items

==== search_menu_items_category(self) ====

Search menu items category

==== search_static_files(self) ====

==== url_map(self) ====

==== Методи класу ====

Приклад використання:

<pre>
id = K2.generate_id()
usr_perm = K2().get_user_permissions()
K2.get_platform()
yml_path = K2.search_yml('users')
</pre>

==== clear_logging_messages() ====

Clear all logging message by user

==== compare_versions(version1, version2) ====

порівняння версій

==== create_system_settings() ====

==== dump_stacks() ====

Request information about the running threads of the current process.

:return: A tuple containing:

* A sequence of text lines detailing the stacks of running

threads and greenlets. (One greenlet will duplicate one thread,

the current thread and greenlet.)

* The number of greenlets.

==== generate_id() ====

Генерація ID

==== get_active_lang_list() ====

Визначення id поточної мови

==== get_current_user_role_name() ====

Отрмання rolename поточного користувача

==== get_locale() ====

Визначення поточної мови

==== get_locale_id() ====

Визначення id поточної мови

==== get_path_abs(caller_file) ====

Абсолютний шлях до файлу, в якому виконується код.

Виклик K2.get_path_abs(__file__)

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

==== get_path_to_root(caller_file) ====

Відносний шлях до рута.

Виклик K2.get_path_to_root(__file__).

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

==== get_platform() ====

Визначення операційної системи

==== get_user_permissions() ====

Retrieve user permissions based on the URL.

This method fetches permissions for the current user based on the URL they are accessing.

Returns:

dict: A dictionary containing the user permissions, including 'roleid' and various permission flags

such as 'r' (read), 'w' (write), 'i' (insert), 'd' (delete), 'c' (create), 'exp' (export), 'imp' (import), 'del_' (undelete), 'settable' (set table), 'cutpast' (cut and paste), 'enable' (enable), and 'active' (active).

If the user is a superadmin, a default set of permissions is returned.

If no permissions are found for the user, an empty dictionary is returned.

Raises:

Exception: If an error occurs during database query execution.

Usage:

<pre>
current_user_permissions = K2().get_user_permissions()
</pre>

==== get_user_role(user_id) ====

Отрмання roleid користувача

==== ins_search_comp() ====

Вивід списку компонент з файлу components.yml у всіх шляхах пошуку

==== load_babel_translation_directories() ====

Завантаження перекладів

==== load_logging_message_by_id(error_id: str) ====

Load a logging message by its error_id from the error log file.

Parameters:

error_id (str): The ID of the error to load.

Returns:

dict: The logging message if found, None otherwise.

==== load_logging_messages(page_url: str) ====

Load logging messages for the curren page from the error log file.

Parameters:

name (str): Name of the object (page) to load messages for.

Returns:

dict: A dictionary containing formatted log messages, the count of 'error' messages, and the count of 'warning' messages.

==== log_entry(error_id, status, message, name) ====

==== logging_message(status, message, page_url=None, show_message=True) ====

Send a logging message to the client via Socket.IO.

This method emits a message to the client with a given status and message content.

The message is sent to a room identified by the current user's ID.

Parameters:

status (str): The status of the message (e.g., cls.log_error - 'ERROR', cls.log_warning - 'WARNING', cls.log_success - 'SUCCESS').

message (str): The content of the message to be sent.

<pre>
page_url(str): url of page with Errors.
</pre>

show_message (bool): True - save log and show windows, False - only save_log

Приклад використання функції:

K2.logging_message(K2.log_error, 'Operation completed with error.')

K2.logging_message(K2.log_success, 'Operation completed successfully.'1)

<pre>
K2.logging_message(status=K2.log_success, message='Operation completed successfully.', page_url='/kadm/users', show_message=False)
</pre>

Example:

==== namemenu(url) ====

Add identificators to url page

==== save_logging_message(error_id, status, message, name) ====

Save a logging message to the stack.

Parameters:

status (str): The status of the message (e.g., cls.log_error - 'ERROR', cls.log_warning - 'WARNING', cls.log_success - 'SUCCESS').

message (str): The content of the message to be saved.

name (str): Name of object where the message originated.

==== search_babel_translation_directories() ====

Пошук файлів з перекладами

==== search_comp_names() ====

Вивід списку ідентифікаторів компонент

у всіх шляхах пошуку

Rerurn: list of components identificators

==== search_yml(name_yml) ====

Search for a yml file in the caller directories of subclasses.

This method searches for a yml file with a specified name in the caller directories of all subclasses of K2Obj.

The search is performed in the 'yml' subdirectory of each caller directory.

Args:

name_yml: The name of the yml file to search for (without the '.yml' extension).

Returns:

The caller directory where the yml file was found, or None if the file was not found.

Usage:

To search for a yml file named 'users.yml', call this method as follows:

K2.search_yml('users')

== API ==

=== Клас K2Obj ===

З цього класу створюються всі об’єкти системи К2. Він має основну базову функціональність, що розширюється та розвивається та яка є у всіх класів системи

==== Властивості ====

==== Властивості класу ====

name #Назва компоненти.

version #Версія компоненти

==== Властивості інстансу ====

self._name_yml #назва конфігураційного файлу

self._name_yml_tree #назва конфігураційного файлу з деревом

self._new_buttons #назва кнопки

self._name_yml_master #назва конфігураційного файлу

self._send_params #параметри для конфігураційного файлу

self._send_group_params #параметри групи

self._report_id #id звіту

self._data_source #датасети

self._off_buttons #вимкнути кнопки

self._row_selection #вибір з рядка

==== Методи ====

==== Методи інстансу ====

Приклад використання:

==== __init__(self) ====

Initialize self. See help(type(self)) for accurate signature.

==== content(self) ====

==== create_names_yml(self, name_yml: str = '', name_yml_tree: str = '', ====

<pre>
name_yml_master: str = '')
</pre>

==== search_class_prop(path_objs) ====

==== Пошук властивостей для розширення класу ====

==== select_grid(self) ====

==== show_grid(self) ====

== API ==

=== Клас K2admin_menus ===

==== Даний клас формує список пунктів меню для конкретного користувача ====

=== Клас k2data ===

=== Клас k2datasync ===

=== Клас k2logging ===

==== Класk2mail ====

==== Класk2notifications ====

=== Клас k2path ===

=== Клас k2secur ===

=== Клас k2settings ===

=== Клас k2trans ===

=== Клас k2upd ===

== Класи компонент ==

=== Клас K2Site ===

=== Клас K2Grid ===

=== Клас K2WMS ===

=== K2UpdateRemainder ===

=== Клас для оновлення залишків на основі даних з отриманих від клієнтів. ===

Відповідає за обробку даних з логів, створення/оновлення записів про залишки товарів та керування їх статусами (новий, стабільний, старий).

==== Методи ====

==== __init__() ====

Ініціалізація класу.
Викликає конструктор батьківського класу K2Docs.

Параметри:
Відсутні.

Повертає:
Об'єкт класу K2UpdateRemainder.

==== update_pub_sub_remainder() ====

Оновлення залишків на основі даних Pub/Sub.
Витягує нові залишки з логів, додає їх у таблицю k2remainder_by_parties, оновлює статуси існуючих записів та видаляє застарілі залишки.

Логіка статусів:

'new' – нові залишки, отримані в поточному оновленні.

'stable' – залишки, які підтвердились та доступні користувачам.

'old' – застарілі дані, що підлягають видаленню.

Алгоритм роботи:

Отримує список pub_sub_list_id з логів k2pubsub_logs.

Витягує дані про залишки (inventSumLines).

Вставляє нові записи у таблицю k2remainder_by_parties зі статусом 'new'.

Масово оновлює статуси залишків:

Видаляє застарілі ('old').

Переводить стабільні ('stable') в старі ('old').

Нові ('new') переводить у стабільні ('stable').

Фіксує зміни у базі (commit).

У разі помилки виконує відкат (rollback).

==== _insert_new_pub_sub_nomenclature(session, nomenclature_data) ====

Додавання нової номенклатури.
Перевіряє наявність номенклатури у таблиці k2nomenclature. Якщо запису немає – створює його.

Параметри:

session (Session) – об'єкт сесії бази даних.

nomenclature_data (dict) – дані про номенклатуру:

itemId (str) – ідентифікатор номенклатури.

itemName (str) – назва товару.

unitId (str) – одиниця виміру (конвертується за фіксованим списком).

Повертає:
Нічого.

Винятки:

Логує помилку у разі невдалої вставки даних.

=== Клас K2CRM ===

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

управління лідами
- замовлення

* рахунки

* звіти

* налаштування системи CRM

=== Клас K2CRM наслідується від K2Obj, всі властивості та методи отримуються від батьківського класу. ===

=== K2DocsCRM ===

=== Клас K2DocsCRM є частиною системи K2CRM і наслідується від K2Obj. Він надає доступ до ключових глобальних налаштувань та ресурсів, необхідних для роботи з документами або іншими функціями CRM. ===

==== Атрибути ====

database:

База даних, доступна через глобальний об'єкт K2.db.

Призначення: Використовується для зберігання та обробки даних, пов'язаних з CRM.

time_zone:

Часовий пояс системи, визначений глобальним об'єктом K2.timezone.

Призначення: Забезпечує коректну обробку часу в межах системи.

domain:

Домен, на якому працює CRM, отримується з глобального об'єкта K2.domain.

Призначення: Використовується для побудови URL-адрес або інших задач, пов'язаних з доменним середовищем.

==== Властивості ====

==== Методи ====

<pre>
create_contact() - Цей метод створює контакт на основі даних існуючого ліда. Лід і контакт взаємодіють через базу даних, де дані ліда переносяться в таблицю контактів.
</pre>

Логіка роботи:

==== Метод очікує вхідний JSON, що містить ідентифікатор ліда (lead_id) ====

Перевіряє чи було надано lead_id. Якщо lead_id не надано то повертається помилка.

Шукає ліда в таблиці k2lead за наданим параметром.

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

У разі помилки скасовує транзакцію і повертає опис помилки.

==== Моделі які використовуються ====

K2Lead. Таблиця яка містить дані про лідів.

k2contacts. Таблиця, в яку додається новий контакт на основі даних ліда.

<pre>
check_lead() - Цей метод перевіряє, чи існує контакт із заданим номером телефону у базі даних (k2contacts). Якщо знайдено, оновлює дані ліда (ім'я, прізвище, email) у переданому об'єкті.
</pre>

Логіка роботи:

Отримає вхідний JSON, що містить options із даними для перевірки.

З options[‘dataField’] отримує номер телефону (phone)

Виконує SQL-запит до таблиці k2contacts для пошуку контакту за номером телефону.

Якщо контакт знайдено то відбувається оновлення даних у options[‘dataField’] (name, surname, email, lead_id)

Якщо контакт не знайдено то для полів name, surname, email встановлюється значення None.

У разі помилки повертає повідомлення з помилкою.

<pre>
crm_data(route, data) - Цей метод отримує дані із відповідних таблиць з бази даних на основі переданих параметрів для подальшого оформлення друкованої форми документів у компоненті k2CRM
</pre>

Логіка роботи:

Створює порожній словник result_dict, який буде наповнюватись даними та парсить вхідні дані data у форматі JSON і зберігає їх у result_dict[‘Header’].

Формує SQL-запити для витягування даних із таблиць бази даних (Товари, Організація, Контрагент, Склад, Договір, Відповідальна особа, Клієнт).

Для кожного запиту виконується SQL-запит та результат додається до result_dict.

Результати запитів конвертуються у словники (row_asdict) для зручного JSON-формату.

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

process_options - Метод обробляє різні параметри, передані через JSON-запит, і налаштовує об'єкти типу K2Grid для роботи з даними в залежності від значення ключа name у вхідних даних.

Основні операції:

Обробка k2doc_rows_detail:

Ім'я YML: 'k2doc_rows_detail'.

Вимикаються кнопки: add, delete, printReport.

Передаються параметри: row_id та storage_id.

Обробка k2doc_move:

Ім'я YML: 'k2doc_move'.

Вимикаються кнопки: add, edit, delete, printReport.

Передаються параметри: doc_id.

Логіка роботи:

Метод очікує вхідні дані у форматі JSON і доступ до них здійснюється через request.json.

Перевіряється значення ключа name у вхідних даних:

<pre>
Якщо name == 'k2doc_rows_detail':
Виділяється row_id із переданих даних. Створюється об’єкт K2Grid з іменем yml “'k2doc_rows_detail”. Вимикаються кнопки add, delete, printReport на панелі інструментів. Отримується storage_id через метод self.get_storage_id(). Параметри row_id та storage_id передаються через send_params.
Якщо name == 'k2doc_move':
</pre>

Виділяється doc_id із вхідних даних. Створюється об'єкт K2Grid з іменем yml 'k2doc_move'. Вимикаються кнопки add, edit, delete, printReport на панелі інструментів. Параметри (doc_id) передаються через send_params.

Повернення результату у форматі JSON

=== Клас K2Report ===

Цей клас забезпечує генерацію та друк звітів за допомогою API Stimulsoft.

==== Основні можливості модуля ====

створення звітів за допомогою конструктора звітів

управління друкованими формами

генерація друкованих документів

==== взаємодія з API Stimulsoft для візуалізації та експорту звітів ====

=== Клас K2Report наслідується від K2Obj, всі властивості та методи отримуються від батьківського класу.
Також клас K2Report є батьківським класом для K2ReportEmbed та K2ReportDesigner ===

==== Атрибути класу ====

==== Методи класу ====

==== __init__(sql=[]) ====

Ініціалізація класу. Отримує шлях до каталогу файлу, що викликав ініціалізацію.

Параметри:

sql (list, опціонально): Список SQL-запитів.

==== create_report(sql=None, data_source=None) ====

Створення звіту. Відображає HTML-сторінку редактора або переглядача звітів.

Параметри:

sql (dict, опціонально): SQL-запити.

data_source (dict, опціонально): Джерело даних.

Повертає:

HTML-сторінку редактора або переглядача звітів.

==== get_report(file_name) ====

Отримання звіту за його ім'ям.

Параметри:

file_name (str): Назва файлу звіту.

Повертає:

Файл звіту або помилку 404, якщо файл не знайдено.

==== execute_query(query, params=None) ====

Виконує SQL-запит.

Параметри:

query (str): SQL-запит.

params (dict, опціонально): Параметри запиту.

Повертає:

Результат виконання запиту.

==== get_report_designer(file_name, design_type_id) ====

Отримує дизайнер звіту за типом звіту.

Параметри:

file_name (str): Назва файлу.

design_type_id (str): Тип дизайну (1 - звіт, 2 - дашборд).

Повертає:

Файл дизайну або помилку 404.

==== add_reports_type(name, data) ====

Додає тип звіту до групи звітів.

Параметри:

name (str): Назва типу звіту.

data (dict): Дані для оновлення.

Повертає:

bool: True, якщо успішно.

=== Клас K2ReportEmbed ===

K2ReportEmbed - Компонент для вбудовування звітів у веб-додаток. Дозволяє отримувати та відображати звіти з бази даних на основі їх ідентифікаторів.

==== Атрибути класу ====

==== __init__(reports_id: List[str]) ====

Ініціалізує екземпляр класу K2ReportEmbed.

Аргументи:

reports_id (List[str]) – список ідентифікаторів звітів.

==== get_report_data() -> Optional[List[Dict[str, Any]]] ====

Отримує дані звітів з бази даних.

Повертає:

Optional[List[Dict[str, Any]]] – список даних звітів або None, якщо сталася помилка.

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

report_name – Назва звіту.

file_name – Ім'я файлу звіту.

json_data_list – JSON-структура, що містить дані для звіту.

Якщо під час виконання запитів виникає помилка, вона логуватиметься у системному журналі помилок

Приклад вбудовування звітів на веб-сторінку

==== Бекенд (Flask) ====

<pre>
@k2production.route('/test_dashboard', methods=['GET'])
def test_dashboard():
</pre>

""" Index page """

<pre>
reports_id = ['b452a5ae84f9e92e75eb0467c196fd71', '1673a4fab757fb6c5df970fdc6ee680c',
</pre>

'49952f397efff44d7ce0e5cb9aa625fb']

<pre>
k2report_embed = K2ReportEmbed(reports_id)
return render_template('k2dashboard_production/k2dashboard_production.html',
dashboard_settings=k2report_embed)
</pre>

==== Фронтенд (Jinja-шаблон) ====

<pre>
{% extends template_name + '/base.html' %}
{% block content %}
{% if error %}
{{ error }}
{% else %}
{% include dashboard_settings.template %}
{% endif %}
{% endblock %
</pre>

=== Клас K2ReportDesigner ===

=== Клас K2ReportDesigner надає функціональність для створення, редагування та перегляду звітів і дашбордів. Він взаємодіє з базою даних, управляє файлами звітів та генерує JSON-дані для подальшого використання. ===

==== Атрибути класу ====

==== Методи класу ====

==== designer() ====

Відображає сторінку редагування друкованої форми.

Повертає:

str: HTML-шаблон сторінки редагування.

==== viewer() ====

Відображає сторінку перегляду друкованої форми.

Повертає:

str: HTML-шаблон сторінки перегляду.

==== dashboard_viewer() ====

Відображає сторінку перегляду дашборду.

Повертає:

str: HTML-шаблон сторінки перегляду дашборду.

==== dashboard_designer() ====

Відображає сторінку редагування дашборду.

Повертає:

str: HTML-шаблон сторінки редагування дашборду.

<pre>
json_data_create(datasource_value, datasource_keys, datasource_is_counterpart_id, datasource_is_storage_id, period, date_from=None, date_to=None)
</pre>

Створює JSON-дані на основі джерел даних та періоду.

Параметри:

datasource_value (list): Список SQL-запитів.

datasource_keys (list): Список ключів для джерел даних.

datasource_is_counterpart_id (list): Список флагів, що вказують на наявність counterpart_id.

datasource_is_storage_id (list): Список флагів, що вказують на наявність storage_id.

period (int): Період вибірки даних.

date_from (str, опціонально): Початкова дата періоду.

date_to (str, опціонально): Кінцева дата періоду.

Повертає:

dict: Словник з результатами запитів або помилкою.

==== Приклад використання ====

<pre>
datasource_value = ["SELECT * FROM table1", "SELECT * FROM table2"]
datasource_keys = ["table1_data", "table2_data"]
datasource_is_counterpart_id = [True, False]
datasource_is_storage_id = [False, True]
period = 1
date_from = "2023-01-01"
date_to = "2023-12-31"
json_data = k2_designer.json_data_create(datasource_value, datasource_keys, datasource_is_counterpart_id, datasource_is_storage_id, period, date_from, date_to)
</pre>

==== save_report_id() ====

Зберігає ідентифікатор та налаштування звіту в JSON-файл.

Повертає:

Response: JSON-відповідь про результат збереження.

==== mrt_report_create(report_id, design_type_id=None) ====

Створює MRT-файл звіту на основі шаблону.

Параметри:

report_id (str): Ідентифікатор звіту.

design_type_id (str, опціонально): Тип дизайну звіту.

Повертає:

str: Ім'я створеного файлу або помилка.

==== table_report_data(datasource_value, datasource_keys) ====

Обробляє дані з SQL-запитів для кожного джерела даних і повертає їх у вигляді JSON.

Параметри:

datasource_value (list): Список SQL-запитів для виконання.

datasource_keys (list): Список ключів, які відповідають кожному SQL-запиту.

Повертає:

dict: Словник, де ключі — це значення з datasource_keys, а значення — дані у форматі JSON для кожного запиту.

==== save_info_report_designer() ====

Зберігає інформацію про репорт та генерує файл MRT.

Повертає:

Response: JSON-об'єкт із результатами генерації звіту та повідомленням про успішність.

==== data_source_lists_creating(group_reports_id) ====

Створює списки джерел даних для звіту.

Параметри:

group_reports_id (str): Ідентифікатор групи звітів.

Повертає:

list: Списки джерел даних.

=== Клас K2Production ===

==== Методи класу ====

Схема вибору обслуговування терміналу

=== Клас K2LogbookTMDoc ===

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

==== Методи класу ====

==== k2logbook_tm() ====

Відображає сторінку логбука технічного обслуговування.
Повертає:
str: HTML-шаблон сторінки логбука.

==== take_logbook_tm(task_id) ====

Створює форму логбука для конкретного завдання.
Параметри:

task_id (str): Ідентифікатор завдання.

Повертає:
str: HTML-шаблон форми логбука.

==== edit_logbook_tm(logbook_fields_tm_id) ====

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

logbook_fields_tm_id (str): Ідентифікатор запису логбука.

Повертає:
str: HTML-шаблон сторінки редагування.

==== select_current_step(connection, logbook_fields_tm_id) ====

Вибирає поточний активний крок логбука.
Параметри:

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

logbook_fields_tm_id (str): Ідентифікатор запису логбука.

Повертає:
str: Ідентифікатор поточного кроку.

==== planned_tm(data, connection) ====

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

data (dict): Дані завдання.

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

Повертає:
dict: Налаштування grid.

==== unplanned_tm(data, connection) ====

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

data (dict): Дані завдання.

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

Повертає:
dict: Налаштування grid.

==== write_logbook_params(data) ====

Зберігає параметри логбука в JSON-файл.
Параметри:

data (dict): Дані для збереження.

Повертає:
JSON: Відповідь про успішне збереження.

==== read_logbook_params() ====

Зчитує параметри логбука з JSON-файлу поточного користувача.
Повертає:
dict: Збережені параметри логбука.

==== fill_logbook_tm_rows(data) ====

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

data (dict): Параметри для заповнення рядків.

Повертає:
bool: True при успішному заповненні, False при помилці.

==== pull_spare_parts_data() ====

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

==== send_params_to_k2logbook_spare_parts(data) ====

Формує параметри та SQL-запит для отримання даних про запчастини.
Параметри:

data (dict): Параметри логбука.

Повертає:
dict: Інформація про запчастини або False при помилці.

==== instruments_and_equipment_parts_params() ====

Отримує параметри інструментів та запчастин для обладнання.
Повертає:
JSON: Відповідь з результатом операції або повідомленням про помилку.

==== task_step_form() ====

Формує форму кроку завдання технічного обслуговування.
Повертає:
JSON: Відповідь з параметрами кроку або повідомленням про помилку.

==== is_unplanned_step_form(step_data) ====

Обробляє форму кроку для позапланованого ТО.
Параметри:

step_data (dict): Дані кроку.

Повертає:
str: ID кроку або JSON з помилкою.

==== save_step(data) ====

Зберігає дані кроку (номенклатуру).
Параметри:

data (dict): Параметри кроку.

Повертає:
bool: True при успіху, False при помилці.

==== end_step(data, session_id, connection, post_request) ====

Завершує крок ТО. Обробляє запчастини, час, статус.
Параметри:

data (dict): Дані кроку.

session_id (str): ID сесії.

connection (опціонально): Підключення до БД.

post_request (bool): Чи це постобробка.

Повертає:
JSON або False.

==== step_image_check(connection, data) ====

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

connection: Підключення до БД.

data (dict): Дані кроку.

Повертає:
bool: True (є зображення), False (немає або помилка).

==== step_data_check(connection, data) ====

Перевіряє коректність даних про запчастини.
Параметри:

connection: Підключення до БД.

data (dict): Дані кроку.

Повертає:
bool: True (дані валідні), False (невалідні або помилка).

==== decline_task() ====

Відхиляє завдання. Деактивує запис у логбуці.
Повертає:
JSON: Результат операції.

==== write_user_comment() ====

Додає коментар користувача до кроку.
Повертає:
JSON: Результат збереження.

==== end_step_manager(data) ====

Керує завершенням кроку. Перевіряє матеріали, зображення.
Параметри:

data (dict): Дані кроку.

Повертає:
bool: True (успіх), False (помилка).

==== detail_check(connection, data) ====

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

connection: Підключення до БД.

data (dict): Дані кроку.

Повертає:
bool: True (відповідність є), False (немає або помилка).

==== send_params_to_k2mount_point_form() ====

Формує параметри для форми монтажних точок обладнання.
Повертає:
JSON: Параметри форми (точки монтування, URL зображення схеми).

==== change_scheme_equipment() ====

Оновлює схему обладнання шляхом заміни монтажних точок.
Повертає:
JSON: Результат операції.

==== pass_familiarisation() ====

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

==== create_write_off_act_logbook(connection, data) ====

Створює акт списання для логбука.
Параметри:

connection: Підключення до БД.

data: Дані для акту.

Повертає:
bool: True (акт створено), False (помилка).

==== create_doc_rows_for_write_of_act(connection, data) ====

Створює рядки документу для акту списання.
Параметри:

connection: Підключення до БД.

data: Дані документу.

Повертає:
bool: True (рядки створено), False (помилка).

==== write_off_part_logbook(connection, data) ====

Списати частину обладнання з логбука.
Параметри:

connection: Підключення до БД.

data: Дані для списання.

Повертає:
Нічого (помилки обробляються через rollback).

==== end_logbook() ====

Завершує роботу з журналом ТО.
Повертає:
JSON: Результат операції (успіх або помилка).

==== spare_parts_check() ====

Перевіряє наявність запасних частин для журналу.
Повертає:
JSON: Результат перевірки (успіх або помилка).

==== equipment_qr_confirmation() ====

Підтверджує відповідність QR-коду обладнання.
Повертає:
JSON: Результат перевірки (успіх або помилка).

==== add_new_equipment_parts(connection, data) ====

Додає нові частини обладнання до БД.
Параметри:

connection: Підключення до БД.

data: Дані про частини обладнання.

Повертає:
bool: True (успіх), False (помилка).

==== material_quantity() ====

Отримує інформацію про кількість матеріалів.
Повертає:
JSON: Дані про кількість матеріалів.

==== create_unplanned_task(data) ====

Створює незаплановане завдання.
Параметри:

data: Дані для створення завдання.

Повертає:
bool: True (успіх), False (помилка).

==== take_material_by_qr() ====

Резервує матеріал за допомогою QR-коду.
Повертає:
JSON: Результат операції (успіх або помилка).

==== return_material_by_qr() ====

Повертає матеріал за QR-кодом.
Повертає:
JSON: Результат операції (успіх або помилка).

==== requires_partner() ====

Встановлює статус завдання "потребує партнера".
Повертає:
JSON: Підтвердження операції.

==== join_task() ====

Додає користувача до завдання та змінює статус на "in_work".
Повертає:
JSON: Результат операції.

==== e_report_logbook(logbook_fields_tm_id) ====

Генерує звіт для журналу ТО у форматі HTML.
Параметри:

logbook_fields_tm_id: ID журналу.

Повертає:
HTML: Відображення звіту.

==== get_all_employee_image() ====

Отримує всі зображення журналу.
Повертає:
JSON: Список URL зображень.

==== get_employee_image() ====

Отримує зображення конкретного рядка журналу.
Повертає:
JSON: Список URL зображень.

==== get_image_logbook(image_data) ====

Перетворює шляхи зображень у URL.
Параметри:

image_data: Дані зображень з БД.

Повертає:
list: Список URL

==== confirm_task() ====

Підтверджує завершення завдання. Надсилає сповіщення.
Повертає:
JSON: Результат операції.

==== send_on_revision_task() ====

Надсилає завдання на доопрацювання.
Повертає:
JSON: Підтвердження операції.

==== send_to_the_task_list_revision() ====

Надсилає завдання на доопрацювання та деактивує виконавців.
Повертає:
JSON: Результат операції.

==== change_task_employee(connection, data) ====

Оновлює виконавців завдання.
Параметри:

connection: Підключення до БД.

data: Нові виконавці та рядки.

==== change_step_status_revision(connection, data) ====

Скидає статус виконання кроків.
Параметри:

connection: Підключення до БД.

data: Ідентифікатори кроків.

==== change_task_status_revision(connection, data, status) ====

Змінює статус завдання.
Параметри:

connection: Підключення до БД.

data: Ідентифікатор завдання.

status: Новий статус (за замовчуванням in_work).

=== Клас K2EquipmentFunction ===

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

==== Атрибути ====

path_class: 'components/k2production/k2production/k2equipment'

file_class: 'k2equipment'

==== Методи ====

==== init(self) ====

Конструктор класу, який викликає конструктор батьківського класу K2Obj.

<pre>
send_approval_request_from_hook(self, data) - Метод для відправлення запиту на затвердження змін у технічній карті обладнання.
</pre>

==== Параметри ====

data (dict): Словник з даними, що містить:

equipment_type_id (int): Ідентифікатор типу обладнання

changed_fields (dict): Словник зі зміненими полями та їх значеннями

==== Логіка роботи ====

Перевірка наявності записів з parentid:

<pre>
Перевіряє наявність записів у таблиці k2tm_fields з parentid != '0'
</pre>

Якщо записів немає, повертає помилку 404

Отримання інформації про тип обладнання:

Витягує equipment_type_name та equipment_type_code з таблиці k2equipment_type

Якщо тип обладнання не знайдено, повертає помилку 404

Пошук затверджувачів:

Отримує список активних користувачів для затвердження з таблиці k2users_for_approval

Якщо затверджувачів не знайдено, повертає помилку 404

Формування повідомлення:

Створює опис змін у форматі "поле: старе_значення → нове_значення"

Формує URL для сторінки затвердження

Відправка запиту на затвердження:

<pre>
Використовує K2Notifications.send_approval_request() для відправки повідомлення
</pre>

Передає список затверджувачів, ідентифікатор об'єкта, URL та опис змін

==== Повертає ====

У разі успіху: JSON з повідомленням про успішну відправку (код 200)

У разі помилки: JSON з описом помилки (код 404 або 500)

==== Залежності ====

Потребує доступу до бази даних через self.db

==== Використовує клас K2Notifications для відправки повідомлень ====

Працює з конфігурацією домену через K2.domain

== K2 Cloud ERP Javascript ==

==== createImageSliderModal(images, containerId = null) ====

Створює слайдер зображень у контейнері або модальному вікні.

Параметри:

images: Масив URL-адрес зображень.

containerId: Ідентифікатор контейнера для вставки слайдера (необов’язково).

Повертає:

Ідентифікатор створеного каруселя або модального вікна.

Якщо зображення відсутні, показує повідомлення та повертає null.

==== showBootstrapLoader(containerId) ====

Додає анімацію завантаження у вказаний контейнер.

Параметри:

containerId: Ідентифікатор контейнера, у який буде вставлений індикатор завантаження.

==== removeBootstrapLoader(containerId) ====

Видаляє анімацію завантаження з контейнера.

Параметри:

containerId: Ідентифікатор контейнера, з якого потрібно прибрати індикатор завантаження.

==== showUserAlert(message, type = 'light') ====

Відображає сповіщення користувача у вигляді Bootstrap Toast

.

Параметри:

message: Текст повідомлення. type: Тип сповіщення (primary, success, danger, warning, info, light). За замовчуванням 'light'.

== Стилі (Назва) ==

Подзаголовок

Заголовок 1

Заголовок 2

Заголовок 3

Заголовок 4

Заголовок 5

Заголовок 6

Звичвйний текст

== Ілюстрації з документа ==

<gallery mode="packed" heights="180">
K2_Cloud_ERP_Python_01.png|Ілюстрація K2 Cloud ERP Python
</gallery>

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

* [[K2 Cloud ERP]]
* [[K2 ERP]]
* [[Python]]
* [[API]]
* [[Документація для розробників]]
* [[K2 Cloud ERP Javascript]]

[[Категорія:K2 ERP]]
[[Категорія:K2 Cloud ERP]]
[[Категорія:Python]]
[[Категорія:Документація K2]]
[[Категорія:Документація для розробників]]

Файл:K2 Cloud ERP Python 01.png

2026-04-28T21:13:27Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Головна сторінка

2026-04-28T21:11:52Z

R: Класи та команди K2 ERP Python

== Про систему K2 ERP ==

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

== Сайти K2 ERP ==
[[Ресурси K2 ERP]]

== Для користувачів ==

[[Початок роботи з K2 ERP]]

[[Хмара K2]]

[[Бухгалтерія K2 ERP]]

[[Управлінський облік K2 ERP]]

[[CRM K2 ERP]]

[[Складський облік K2 ERP]]

[[Інтернет-магазин K2 ERP]]

[[K2 VDoc]]

[[Галузеві рішення K2 ERP]]

[[Звіти та аналітика K2 ERP]]

[[Поширені питання K2 ERP]]

== Для програмістів ==

[[Архітектура K2 ERP]]

[[Встановлення K2 ERP]]

[[Розгортання K2 ERP]]

[[Створення модулів K2 ERP]]

[[База даних K2 ERP]]

[[API K2 ERP]]

[[Інтеграції K2 ERP]]

[[K2 CMS]]

[[Розробка веб-інтерфейсів K2]]

[[Бізнес-процеси K2 ERP]]

[[Права доступу K2 ERP]]

[[Рекомендації для розробників K2]]

[[Класи та команди K2 ERP Python]]

[[Стандарти UI K2 2025]]

== Атестаційні завдання по K2 ERP ==

[[Атестаційні завдання по K2 ERP]]

[[Регламент K2]]

== K2 ERP PHP ==

[[Практична робота в K2 ERP PHP]]

[[Інструкція по розгортанню K2 ERP PHP]]

[[Класи та команди K2 Cloud ERP PHP]]

== Робота в K2 ==
[[Налаштування WireGuard]]

== Довідник та модулі ==

* [[K2 CMS]]
* [[K2 VDoc (Електронний документообіг)]]
* [[Ліцензійна політика K2]]

== Навігація за категоріями ==
Усі статті бази знань автоматично групуються за категоріями:

* [[:Категорія:ERP-системи|ERP-системи]]
* [[:Категорія:Програмне забезпечення, розроблене в Україні|Українське ПЗ]]
* [[:Категорія:Програмне забезпечення для бізнесу|ПЗ для бізнесу]]

Інформацію про роботу з цією вікі можна знайти на сторінці [[mediawikiwiki:Special:MyLanguage/Help:Contents|Довідка:Вміст]].

== Деякі корисні ресурси ==
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Список налаштувань];
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ Часті питання з приводу MediaWiki];
* [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ Розсилка повідомлень про появу нових версій MediaWiki];
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Локалізувати MediaWiki своєю мовою]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Дізнатися, як боротися зі спамом у своїй вікі]

Стандарти UI K2 2025

2026-04-28T21:09:57Z

R: Створена сторінка: {{Картка документації K2 | назва = Стандарти UI K2 2025 | система = K2 | тип = UI-стандарти | рік = 2025 }} '''Стандарти UI K2 2025''' — документ, який описує єдині підходи до реалізації дизайнів, контролів, компонентів та програмної частини у проектах K2. __TOC__ == Мета == Цей док...

{{Картка документації K2
| назва = Стандарти UI K2 2025
| система = K2
| тип = UI-стандарти
| рік = 2025
}}

'''Стандарти UI K2 2025''' — документ, який описує єдині підходи до реалізації дизайнів, контролів, компонентів та програмної частини у проектах K2.

__TOC__

== Мета ==

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

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

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

Увага: різні компоненти можуть конфліктувати одне з одним. Тому дуже важливо правильно підбирати контроли, щоб не конфліктували друг з другом.

* P.S. Дуже стара версія стандартів (10-20 річної давнини): https://docs.google.com/document/d/1LjNHDyISGVkk7AnhXfWnTL9xChJqzKHchfTcVrTYWk8/edit

== Карти ==

[[Файл:K2_UI_Standards_2025_01.png|міні|центр|Ілюстрація до розділу «Карти»]]

=== OpenStreet ===

* https://tomickigrzegorz.github.io/leaflet-examples/#10.matching-all-markers-to-the-map-view

* https://leafletjs.com/

=== Карти 3D ===

* https://mapplic.com/maps/apartment

== Інструментарій ==

SQL Power Architech - моделювання структури бази даних:

* https://bestofbi.com/architect-download/

DBAver - редактор бази даних

* https://dbeaver.com/download/

* Редактор структури бази даних (для можливого використання редактора): https://www.drawdb.app/editor

== Шаблони ==

Багато прикладів роботи компонентів та їх поводження можна побачити в різних шаблонах.

* https://adminlte.io/themes/AdminLTE/index2.html#

* https://appstack.bootlab.io/dashboard-default.html

* https://themes.getbootstrap.com/preview/?theme_id=88616

* https://themes.getbootstrap.com/preview/?theme_id=28117

* https://themes.getbootstrap.com/product/keen-the-ultimate-bootstrap-admin-theme/

* https://themes.getbootstrap.com/preview/?theme_id=5824

* https://themes.getbootstrap.com/preview/?theme_id=1666

* https://themes.getbootstrap.com/preview/?theme_id=21888

== Google-теми ==

* https://themewagon.com/themes/tailadmin/

* https://startbootstrap.com/previews/material-admin-pro

* https://startbootstrap.com/previews/sb-admin-pro-angular

== Грід PHP Grid ==

* https://www.gridphp.com/demo-center/

== AG-Grid ==

* https://www.ag-grid.com/example/

== Telerik ==

* https://www.telerik.com/

* https://www.telerik.com/support/demos

== Report ==

* Stimul Report: https://demo.stimulsoft.com/#Net/BusinessInvoice

== Набори прикладів різних UI компонентів ==

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

* Syncfusion: https://ej2.syncfusion.com/vue/documentation/toolbar/responsive-mode

* jQWidgets: https://www.jqwidgets.com/jquery-widgets-demo/

* DHX (рекомендовано до використання): https://snippet.dhtmlx.com/i7cfddkl

* Різні UI-компоненти Telerik (більше під .Net): https://demos.telerik.com/kendo-ui/

* DevExpress (більше .Net): https://www.devexpress.com/support/demos/#

== VueRibbon: https://www.vueribbon.com/home ==

* MetroUI: https://korzh.com/metroui#licensing

* https://themes.org.ua/pandora/index.html#forms-extended

* https://metroui.org.ua/ribbon-menu.html

== Інструменти протопіювання дизайну ==

За допомогою цих інструментів ви можете зробити схему елементів дизайну.

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

* https://wireframe.cc

== Моделювання структури бази даних ==

* https://bestofbi.com/products/sql-power-architect-data-modeling/ - SQL Power Architech.

== Види компонентів ==

== Меню ==

[[Файл:K2_UI_Standards_2025_02.png|міні|центр|Ілюстрація до розділу «Меню»]]

Меню можуть бути: верхнє, нижнє, бокове (справа, або зліва), контекстне та інше.

Контекстне меню - з’являється тоді, коли ми клацаємо на елементі лівою клавішею миші. Можливі і інші варіанти визову контекстного меню.

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

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

* Приклади: https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/defaultfunctionality.htm

* https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/minimized.htm

=== Контектне меню ===

* https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/contextmenu.htm

== Таймлайн ==

[[Файл:K2_UI_Standards_2025_03.png|міні|центр|Ілюстрація до розділу «Таймлайн»]]

За допомогою Таймлайну можна показати красиво розвиток в часі дій.

Приклад:

* https://adminlte.io/themes/AdminLTE/pages/UI/timeline.html

== Тулбари ==

[[Файл:K2_UI_Standards_2025_04.png|міні|центр|Ілюстрація до розділу «Тулбари»]]

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

* Приклад: https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxtoolbar/index.htm#demos/jqxtoolbar/defaultfunctionality.htm

== Закладки (TabStrip) ==

[[Файл:K2_UI_Standards_2025_05.png|міні|центр|Ілюстрація до розділу «Закладки (TabStrip)»]]

Дозволяють розташувати інформацію по різним сторінкам. Розподіляючи інформацію по смислу.

* Приклад: https://demos.telerik.com/kendo-ui/tabstrip/tab-position

== Ribbon-інтерфейс ==

[[Файл:K2_UI_Standards_2025_06.png|міні|центр|Ілюстрація до розділу «Ribbon-інтерфейс»]]

Це інтерфейс в стилі Ms Office 2013.

== Приклади: https://snippet.dhtmlx.com/9ckg47ro?text=Ribbon ==

* https://www.vueribbon.com/home

== Таблиці (гриди) ==

[[Файл:K2_UI_Standards_2025_07.png|міні|центр|Ілюстрація до розділу «Таблиці (гриди)»]]

За допомогою гридів автоматизуються значні частини табличних даних.

Ми використовуємо в своїй практиці PHPGrid та AG-Grid.

Приклади роботи та функціоналу PHPGrid:

* https://www.gridphp.com/demo-center/

Приклади AG-Grid:

* https://www.ag-grid.com/example/

=== Master-Detail ===

[[Файл:K2_UI_Standards_2025_08.png|міні|центр|Ілюстрація до розділу «Master-Detail»]]

Це можливість показати співвідношення таблиць один до багатьох:

Приклад:

* https://www.gridphp.com/demo-center/

=== Під-гридом Master-Detail ===

[[Файл:K2_UI_Standards_2025_09.png|міні|центр|Ілюстрація до розділу «Під-гридом Master-Detail»]]

=== Multy-грід (Tab-грід) ===

[[Файл:K2_UI_Standards_2025_10.png|міні|центр|Ілюстрація до розділу «Multy-грід (Tab-грід)»]]

== Кнопки ==

[[Файл:K2_UI_Standards_2025_11.png|міні|центр|Ілюстрація до розділу «Кнопки»]]

Приклад зовнішнього вигляду кнопок:

* https://adminlte.io/themes/AdminLTE/pages/UI/buttons.html

== Кнопка може мати список (меню) ==

== Кнопки можуть мати картинку на підпис ==

Кнопки можуть розміщуватись не тільки горизонтально, але й вертикально:

== Спліттери (Splitter) ==

[[Файл:K2_UI_Standards_2025_12.png|міні|центр|Ілюстрація до розділу «Спліттери (Splitter)»]]

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

* Приклад: https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxsplitter/index.htm#demos/jqxsplitter/defaultfunctionality.htm

== Карти ==

[[Файл:K2_UI_Standards_2025_13.png|міні|центр|Ілюстрація до розділу «Карти»]]

== Прогрес-бари ==

[[Файл:K2_UI_Standards_2025_14.png|міні|центр|Ілюстрація до розділу «Прогрес-бари»]]

== Слайдери ==

[[Файл:K2_UI_Standards_2025_15.png|міні|центр|Ілюстрація до розділу «Слайдери»]]

За допомогою слайдеру можна вказувати диапазони зміни даних.

* Приклад: https://adminlte.io/themes/AdminLTE/pages/UI/sliders.html

== Звіти (Reports) ==

[[Файл:K2_UI_Standards_2025_16.png|міні|центр|Ілюстрація до розділу «Звіти (Reports)»]]

Звіти - це різновид інформації, яка підготовується для друку.

* Приклад: https://demo.stimulsoft.com/#Net/Order

== PivotGrid (OLAP), BI ==

[[Файл:K2_UI_Standards_2025_17.png|міні|центр|Ілюстрація до розділу «PivotGrid (OLAP), BI»]]

* Приклад: https://demo.stimulsoft.com/#Net/DashboardInsuranceSales2014-2022

== Вікна ==

[[Файл:K2_UI_Standards_2025_18.png|міні|центр|Ілюстрація до розділу «Вікна»]]

Модальне вікно - це вікно, яке виринає та не дає переключитись на інші дії, поки не даш відповідь, яке задає модальне вікно.

* Приклад модальних вікон: https://adminlte.io/themes/AdminLTE/pages/UI/modals.html

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

Елементи вікна повинні теж позіціонуватись так, щоб займати весь простір та легко читатись.

== Suite (комплект) ==

[[Файл:K2_UI_Standards_2025_19.png|міні|центр|Ілюстрація до розділу «Suite (комплект)»]]

Це стилистично росташований комплекс компонент.

* Приклад: https://snippet.dhtmlx.com/85fbitnu?mode=wide

== Додаткові ілюстрації ==

<gallery mode="packed" heights="180">
K2_UI_Standards_2025_20.png|Ілюстрація UI K2
K2_UI_Standards_2025_21.png|Ілюстрація UI K2
K2_UI_Standards_2025_22.png|Ілюстрація UI K2
K2_UI_Standards_2025_23.png|Ілюстрація UI K2
K2_UI_Standards_2025_24.png|Ілюстрація UI K2
K2_UI_Standards_2025_25.png|Ілюстрація UI K2
K2_UI_Standards_2025_26.png|Ілюстрація UI K2
K2_UI_Standards_2025_27.png|Ілюстрація UI K2
K2_UI_Standards_2025_28.png|Ілюстрація UI K2
K2_UI_Standards_2025_29.png|Ілюстрація UI K2
K2_UI_Standards_2025_30.png|Ілюстрація UI K2
K2_UI_Standards_2025_31.png|Ілюстрація UI K2
K2_UI_Standards_2025_32.png|Ілюстрація UI K2
K2_UI_Standards_2025_33.png|Ілюстрація UI K2
K2_UI_Standards_2025_34.png|Ілюстрація UI K2
K2_UI_Standards_2025_35.png|Ілюстрація UI K2
K2_UI_Standards_2025_36.png|Ілюстрація UI K2
K2_UI_Standards_2025_37.png|Ілюстрація UI K2
K2_UI_Standards_2025_38.png|Ілюстрація UI K2
K2_UI_Standards_2025_39.png|Ілюстрація UI K2
K2_UI_Standards_2025_40.png|Ілюстрація UI K2
K2_UI_Standards_2025_41.png|Ілюстрація UI K2
K2_UI_Standards_2025_42.png|Ілюстрація UI K2
K2_UI_Standards_2025_43.png|Ілюстрація UI K2
K2_UI_Standards_2025_44.png|Ілюстрація UI K2
K2_UI_Standards_2025_45.png|Ілюстрація UI K2
K2_UI_Standards_2025_46.png|Ілюстрація UI K2
K2_UI_Standards_2025_47.png|Ілюстрація UI K2
K2_UI_Standards_2025_48.png|Ілюстрація UI K2
K2_UI_Standards_2025_49.png|Ілюстрація UI K2
K2_UI_Standards_2025_50.png|Ілюстрація UI K2
K2_UI_Standards_2025_51.png|Ілюстрація UI K2
K2_UI_Standards_2025_52.png|Ілюстрація UI K2
K2_UI_Standards_2025_53.png|Ілюстрація UI K2
K2_UI_Standards_2025_54.png|Ілюстрація UI K2
K2_UI_Standards_2025_55.png|Ілюстрація UI K2
</gallery>

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

* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[UI]]
* [[UX]]
* [[Адміністративна панель]]
* [[Таблиці]]
* [[Грід]]

[[Категорія:K2 ERP]]
[[Категорія:UI]]
[[Категорія:Стандарти K2]]
[[Категорія:Документація K2]]

Файл:K2 UI Standards 2025 55.png

2026-04-28T21:07:44Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 54.png

2026-04-28T21:07:42Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 53.png

2026-04-28T21:07:39Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 52.png

2026-04-28T21:07:36Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 51.png

2026-04-28T21:07:34Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 50.png

2026-04-28T21:07:31Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 49.png

2026-04-28T21:07:29Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 48.png

2026-04-28T21:07:25Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 47.png

2026-04-28T21:07:22Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 46.png

2026-04-28T21:07:21Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 45.png

2026-04-28T21:07:18Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 44.png

2026-04-28T21:07:15Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 43.png

2026-04-28T21:07:13Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 42.png

2026-04-28T21:07:12Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 41.png

2026-04-28T21:07:11Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload

Файл:K2 UI Standards 2025 40.png

2026-04-28T21:07:08Z

R: Файл завантажений з MsUpload

Файл завантажений з MsUpload