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

Атестаційні завдання K2 ERP/Веб-архів документів: відмінності між версіями

Матеріал з K2 ERP Wiki
Первинна публікація
 
Немає опису редагування
 
Рядок 1: Рядок 1:
{| class="wikitable"
'''критично.''' Нова реліз системи документа не повинна перезаписувати старий файл.== База «Версії документів» ==


Організація або компанія-користувач повинно:
== Основні типи доступу ==
!SEO-опис


* зберігати службові, юридичні, технічні документи;
[[Категорія:Атестаційні завдання K2]]
* мати історію змін кожного документу;
* порівнювати версії документів між собою;
* відновлювати попередні версії у разі потреби.==== Колонки бази ====


* користувач системи системи системи;
* перегляд;
* адміністратор архіву. !Бали
* редагування;
* завантаження;
* експорт;
* додавання версії;
* погодження;
* затвердження;
* видалення;
* адміністрування.== Довідник «Теги» ==
 
</div>
 
* документ;
* категорію;
* останню версію;
* дату архівації;
* причину архівації;
* відповідального.[[Категорія:Документообіг]]
 
== Колонки бази документів ==
 
* за категорією;
* за статусом;
* за автором;
* за тегом;
* за датою;
* за наявністю актуальної версії;
* за документами на погодженні;
* за архівними документами. | Права доступу, актуальну версію, історію змін, погодження
|-
| Які звіти потрібні? Пошук має бути зручним і швидким. * документ;
* версію;
* користувача;
* дію;
* дату і час;
* SEO-опис змін. {| class="wikitable" style="width:100%;"
 
Файли можуть зберігатися:
 
== Звіт «Архівні документи» ==


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


{| class="wikitable"
Організація або компанія-користувач функціонує з великою кількістю документів:
 
'''Критично.''' користувач системи без прав не повинен бачити конфіденційні документи, завантажувати файли або переглядати історію версій. ! Роль
 
== Звіт «історія продукту змін» ==
! | Документ із файлами і версіями
|-
| Що критично для версій?<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
== Практичне задача ==
 
== Довідник «Типи доступу» ==
 
== Доступ і права ==
 
== Правила версійності ==
 
* порівняння TXT;
* порівняння тексту, витягнутого з DOCX, якщо реалізовано;
* порівняння текстових полів;
* показ доданих рядків;
* показ видалених рядків;
* показ змінених фрагментів.== Колонки версій ==
== Звіт «Документи на погодженні» ==
{| class="wikitable" style="width:100%;"
 
!== базовий бізнес-процес ==
 
Веб-архів документів''' — це практична задача; так само реалізовано файлами, історією змін, контролем доступу, пошуком, погодженням, відновленням попередніх версій і формуванням контрольних реєстрів виступає ключовою рисою перевірки навичок розробника або впроваджувача [[K2 ERP]] у створенні модуля електронного архіву документів із версіями забезпечується через '''Атестаційне задача K2 ERP. '''Коротко.''' Потрібно реалізувати веб-архів документів: категорії, документи, файли, версії, теги, статуси, історія продукту змін, порівняння версій, відновлення попередніх версій, права доступу, погодження, пошук, ревізія, експорт і AJAX-інтерактив. платформа має підтримувати чіткі правила роботи з версіями. |-
| Документ
| Який документ погоджується
|-
| реліз системи
| Яка реліз системи погоджується
|-
| Погоджувач
| Хто має погодити
|-
| Дата передачі
| Коли передано на погодження
|-
| Дата рішення для бізнесу
| Коли погоджено або відхилено
|-
| рішення для бізнесу
| Погоджено, відхилено, на доопрацювання
|-
| Коментар
| Пояснення погоджувача
|}
 
! У звіті потрібно відображати:
 
{| class="wikitable" style="width:100%;"
 
{| class="wikitable" style="width:100%;"
 
# створити категорії документів;
# створити типи документів;
# створити теги;
# створити користувачів або ролі доступу;
# створити новий документ;
# додати назву, категорію, тип і SEO-опис;
# завантажити файл першої версії;
# перевірити, що створено версію v1;
# додати другу версію документа;
# додати SEO-опис змін;
# перевірити історію версій;
# зробити другу версію актуальною;
# передати документ на погодження;
# погодити документ;
# змінити статус на '''«Затверджено»''';
# відновити попередню версію;
# перевірити, що дія записана в журнал;
# налаштувати доступ тільки для певної ролі;
# перевірити, що користувач системи без прав не бачить документ;
# виконати пошук за назвою;
# виконати фільтр за категорією;
# сформувати реєстр документів;
# сформувати звіт історії змін;
# перевірити журнал завантажень.== Звіт «Реєстр документів» ==
 
* доступ до всіх документів;
* доступ до категорії;
* доступ до конкретного документа;
* доступ тільки до перегляду;
* доступ до редагування;
* доступ до завантаження файлу;
* доступ до додавання версій;
* доступ до погодження;
* доступ до адміністрування. Поле
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
компонент має підтримувати категорії, типи документів, документи, файли, версії, теги, погодження, коментарі, права доступу, пошук, фільтри, відновлення попередніх версій, журнал змін, журнал завантажень, контрольні реєстри, звіти, AJAX-інтерактив і підтримку різних форматів файлів. Параметр
! Теги потрібні для швидкої фільтрації документів. Значення
[[Категорія:Права доступу]]
 
== Фільтри ==
 
Через AJAX мають працювати:
 
* договори;
* додаткові угоди;
* рахунки;
* акти;
* накази;
* політики;
* інструкції;
* технічні документи;
* креслення;
* проєктна документація;
* юридичні документи;
* фінансові документи;
* кадрові документи;
* службові записки;
* регламенти;
* шаблони документів. __TOC__
 
== Вимоги до файлів ==
 
== Параметри пошуку ==
{| class="wikitable" style="width:100%;"
Критичними помилками вважаються ситуації, коли:
 
!== Звіти ==
!== Поля погодження ==
 
* складно знайти потрібний документ;
* незрозуміло, яка реліз системи виступає як актуальною;
* документи зберігаються у різних користувачів;
* зміни не фіксуються;
* попередні версії втрачаються;
* немає контролю доступу;
* немає історії погодження;
* неможливо оперативно провести ревізію документів. Призначення
|-
| Документ
| Батьківська картка документа
|-
| Номер версії
| як приклад: v1, v2, v3
|-
| Файл
| Завантажений файл
|-
| Формат файлу
| PDF, DOCX, XLSX, TXT, PNG, JPG тощо
|-
| Автор версії
| Хто додав версію
|-
| Дата і час
| Коли додано версію
|-
| SEO-опис змін
| Що було змінено
|-
| Коментар
| Додаткові примітки
|-
| Статус
| Актуальна, архівна, відхилена
|}
 
== Поля картки документа ==
 
! * договір;
* додаткова угода;
* наказ;
* інструкція;
* політика;
* технічне задача;
* креслення;
* акт;
* рахунок;
* протокол;
* сертифікат;
* шаблон;
* службова записка. {| class="wikitable" style="width:100%;"
 
== Основні правила ==


* назва документа;
* назва документа;
* номер документа;
* категорія;
* категорія;
* номер документа — опціонально;
* тип документа;
* тег;
* автор;
* відповідальний;
* дата створення;
* дата створення;
* автор;
* дата оновлення версій;
* поточний статус:
* статус;
** чернетка;
* формат файлу;
** затверджено;
* текстовий пошук у назві або описі;
** на перегляді;
* текстовий пошук у вмісті, якщо реалізовано індексацію. Питання
** архівовано;
 
* коментарі / нотатки. !Критерій
У списку документів потрібно реалізувати фільтри:
 
Інтерфейс має працювати оперативно і без перезавантаження сторінок. # користувач системи відкриває історію версій;
# обирає попередню версію;
# натискає '''«Відновити»''';
# платформа створює нову версію на основі обраної;
# ця реліз системи стає поточною;
# дія записується в журнал змін. Разом
!<div style="border:2px solid #f57c00; background:#fff3e0; padding:14px; margin:16px 0;">
 
Для текстових документів бажано реалізувати порівняння версій.== Логування змін ==
!</div>
 
== Відновлення попередньої версії ==
 
* у файловій системі сервера;
* у базі даних;
* у хмарному сховищі;
* у S3-сумісному сховищі;
* в іншому зовнішньому сховищі. | компонент веб-архіву документів
|-
| Які довідники потрібні? Об’єкт
 
== База «Документи» ==
 
Мета задача — створити в K2 ERP компонент веб-архіву для зберігання, пошуку, оновлення версій, погодження і контролю версій документів. ! Критерій
 
== Рівні доступу ==
 
! SEO-опис
 
== Технічні вимоги ==
 
</div>
== Погодження документів ==
Мінімальний сценарій:
|-
| Що потрібно створити? * [[K2 Cloud ERP|K2 ERP]]
* [[K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Документообіг]]
* [[Файл]]
* [[Версійність]]
* [[Права доступу]]
* [[Погодження документів]]
* [[Журнал змін]]
* [[Електронний архів]]
* [[PDF]]
* [[AJAX]]
 
Веб-архів вирішує ці проблеми через єдину систему зберігання, пошуку, версійності та прав доступу.== Реальний бізнес-контекст ==
 
== Звіт «Документи без актуальної версії» ==
 
{| class="wikitable" style="width:100%;"
 
* назву документа;
* категорію;
* тип;
* номер;
* дату документа;
* автора;
* поточну версію;
* статус;
* відповідального.== Підтримувані варіанти порівняння ==
!== Див. так само ==
 
== Коментар має містити ==
 
* вести категорії документів;
* вести типи документів;
* вести теги;
* створювати картки документів;
* завантажувати файли документів;
* додавати нові версії файлів;
* бачити поточну версію документа;
* переглядати історію версій;
* порівнювати версії текстових документів;
* відновлювати попередню версію;
* фіксувати автора змін;
* зберігати SEO-опис змін;
* налаштовувати права доступу;
* обмежувати перегляд, редагування, завантаження і видалення;
* погоджувати або затверджувати документи;
* вести журнал дій користувачів;
* шукати документи за назвою, категорією, тегами, автором, датою і статусом;
* формувати контрольні реєстри;
* експортувати списки документів у PDF або Excel.== Коротко ==
 
! Колонка
 
{| class="wikitable" style="width:100%;"
 
* перша завантажена реліз системи отримує номер v1;
* кожне нове завантаження створює нову версію;
* стара реліз системи не видаляється автоматизовано;
* лише одна реліз системи здатна бути поточною;
* поточна реліз системи має бути помітно позначена;
* користувач системи здатна переглянути історію версій;
* користувач системи із правами здатна відновити попередню версію;
* відновлення попередньої версії має логуватися. Усі версії мають зберігатися в історії. | Diff версій, batch upload, журнал завантажень, контрольну ревізію документів
|}
 
Тип документа дає можливість деталізувати призначення файлу. SEO-опис
== Пошук документів ==
{| class="wikitable" style="width:100%;"
|-
| Назва документа
| Назва для пошуку і відображення
|-
| Категорія
| До якої групи належить документ
|-
| Тип документа
| Договір, наказ, інструкція тощо
|-
| Номер документа
| Внутрішній або зовнішній номер
|-
| Дата створення
| Коли документ створено
|-
| Автор
| Хто створив картку
|-
| Поточна реліз системи
| Актуальна реліз системи файлу
|-
| Статус
| Чернетка, на перегляді, затверджено, архівовано
|-
| Теги
| Позначки для пошуку
|}
 
компонент має забезпечувати централізоване зберігання службових. '''Умова складання.''' задача не здатна бути зараховане, якщо платформа не дає можливість пройти базовий цикл архіву: документ → файл → реліз системи → нова реліз системи → історія продукту → погодження → права доступу → відновлення → реєстр. | Категорії, типи документів, теги, типи доступу
|-
| Який провідний об’єкт? SEO-опис
 
!== функції ERP масового завантаження ==
 
== Приклади категорій ==
 
* немає завантаженого файлу;
* немає поточної версії;
* поточна реліз системи не затверджена;
* документ давно не оновлювався;
* документ має статус чернетки занадто довго. | Кожна нова реліз системи зберігається окремо і не перезаписує стару
|-
| Що потрібно контролювати? Поле
 
! SEO-опис
компонент має підтримувати контроль доступу на рівні документів. !== Назва задача ==
 
! функції ERP
|-
| Документ
| До якого документа належить реліз системи
|-
| реліз системи
| v1, v2, v3 або інший формат
|-
| Дата завантаження
| Коли додано версію
|-
| Автор змін
| Хто завантажив файл
|-
| SEO-опис змін
| Що змінилося
|-
| Файл
| Завантажений документ
|-
| Статус версії
| Чернетка, актуальна, архівна, скасована
|}
 
! Поле


* вести централізований електронний архів;
{| class="wikitable" style="width:100%;"
* відслідковувати всі зміни в документах;
Типовий бізнес-процес роботи з документом виглядає так:
* організувати контроль доступу:
'''компонент обліку електронних документів з версіями та контролем змін'''.== Приклади типів ==
** хто бачить документи;
** хто змінює документи. Веб-архів документів із версіями — критично важливий для будь-якої компанії, що функціонує з:
= компонент обліку електронних документів з версіями та контролем змін =


* ведення повної історії:
! Бали
** хто вніс зміни;
** коли вніс зміни;
** який файл змінено;
** що саме змінилося — опціонально через diff для текстових документів;
* можливість порівняти дві версії документа.== Технічні вимоги ==


Ролі користувачів:
== Шкала оцінювання ==


=== 4. Контроль змін ===
Для реалізації задачі доцільно передбачити такі сутності:
=== 2. База «Документи» ===


* договори;
* автора;
* політики та інструкції;
* дату і час;
* технічні документи;
* текст коментаря;
* юридичні документи;
* прив’язку до документа або версії;
* проекти;
* статус, якщо коментар пов’язаний із доопрацюванням. ! ! ! У звіті потрібно відображати:
* інше.=== 3. База «Версії документів» ===


==== Довідник «Типи доступу» ====
== Порівняння версій ==


* документ;
* документ;
* реліз системи:
* версію;
** v1;
* погоджувача;
** v2;
* дату передачі;
** v3;
* поточний статус;
** наступні версії;
* кількість днів на погодженні.== Очікуваний результат ==
* дата завантаження;
== Примітка ==
* користувач системи системи системи, який вніс зміни;
== Довідник «Типи документів» ==
* SEO-опис змін;
|-
* файл документа:
| Не потрібно
** PDF;
| Документ не потребує погодження
** DOCX;
|-
** TXT;
| Очікує погодження
** інше.=== 6. Додаткові функції ===
| Документ передано відповідальній особі
== Основні задача ==
|-
==== Колонки бази ====
| Погоджено
==== функції ERP ====
| Документ прийнято
|-
| Відхилено
| Документ не прийнято
|-
| Повернено на доопрацювання
| Потрібні зміни
|}
 
Опціонально можна реалізувати batch upload. Без централізованого архіву виникають типові проблеми:
 
# користувач системи створює картку документа;
# обирає категорію і тип документа;
# додає назву, номер, дату і SEO-опис;
# завантажує файл першої версії;
# платформа створює версію v1;
# документ отримує статус '''«Чернетка»''';
# користувач системи передає документ на перегляд або погодження;
# відповідальна особа погоджує документ або повертає на доопрацювання;
# автор завантажує нову версію;
# платформа створює версію v2;
# історія продукту змін зберігається;
# після затвердження документ отримує статус '''«Затверджено»''';
# при потребі користувач системи здатна переглянути стару версію або відновити її;
# адміністратор формує контрольний реєстр документів. Окремо варто відзначити юридичних, технічних, фінансових, проєктних і інших документів організації. Статус
 
== AJAX-інтерактив ==
У межах атестації потрібно продемонструвати робочий сценарій. Що перевіряється
|-
| Чернетка
| Документ створено, але ще не погоджено
|-
| На перегляді
| Документ перевіряється
|-
| На погодженні
| Очікує погодження відповідальної особи
|-
| Повернено на доопрацювання
| Потрібні зміни
|-
| Затверджено
| Документ прийнято як актуальний
|-
| Замінено новою версією
| виступає як новіша реліз системи документа
|-
| Архівовано
| Документ збережено для історії
|-
| Скасовано
| Документ більше не застосовується для
|}
 
! Колонка
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
|-
| Категорії документів
| Групування документів за напрямами
|-
| Типи документів
| Договір, наказ, інструкція, політика, креслення тощо
|-
| Документи
| Основні картки документів
|-
| Версії документів
| історія продукту файлів і змін
|-
| Файли
| PDF, DOCX, XLSX, TXT, зображення та інші формати
|-
| Теги
| Швидке маркування і пошук документів
|-
| Права доступу
| Хто здатна переглядати, редагувати, погоджувати, завантажувати
|-
| Погодження
| бізнес-процес перевірки і затвердження документа
|-
| Коментарі
| Обговорення документа або версії
|-
| Журнал змін
| історія продукту дій користувачів
|-
| Реєстри
| Контрольні списки документів
|}
 
{| class="wikitable" style="width:100%;"
 
компонент повинен фіксувати всі важливі дії.== Масове завантаження документів ==
 
користувач системи із відповідними правами здатна відновити стару версію. |-
| Назва документа
| Повна назва документа
|-
| Категорія
| Категорія архіву
|-
| Тип документа
| Вид документа
|-
| Номер документа
| Номер, якщо виступає як
|-
| Дата документа
| Дата створення або підписання
|-
| Автор
| Хто створив документ
|-
| Відповідальний
| Хто відповідає за актуальність
|-
| SEO-опис
| Короткий зміст
|-
| Теги
| Позначки для пошуку
|-
| Поточна реліз системи
| Актуальна реліз системи
|-
| Статус
| Поточний стан документа
|-
| Коментарі
| Службові нотатки
|}
 
== Критерії оцінювання ==
 
== Поля версії документа ==
{| class="wikitable" style="width:100%;"
! SEO-опис
Журнал змін має зберігати:
У звіті потрібно відображати документи, у яких:
== Ревізія документів ==
|-
| Реалізація бази документів і версій
| 20
| Документи, категорії, типи, файли, версії, поточна реліз системи, історія продукту версій
|-
| керування історією змін
| 20
| SEO-опис змін, автор змін, журнал дій, відновлення версій, порівняння версій
|-
| Контроль доступу і прав на документи
| 20
| Перегляд, редагування, завантаження, погодження, обмеження для користувачів без прав
|-
| Зручність перегляду, пошуку і відновлення документів
| 20
| Пошук, фільтри, теги, статуси, реєстри, відновлення попередньої версії
|-
| Інтерактивність через AJAX і технічна підтримка багатьох форматів
| 20
| AJAX-завантаження, оновлення версій версій, фільтрація, PDF, DOCX, XLSX, TXT та інші формати
|-
[[Категорія:Корпоративна Wiki]]
== Критичні помилки ==
{| class="wikitable" style="width:100%;"
|}
 
У звіті потрібно відображати:
 
== Логіка відновлення ==
[[Категорія:Електронний архів]]
У звіті потрібно відображати:
</div>
|-
| 90–100
| Відмінно
| компонент на 100% функціонує: документи, версії, файли, пошук, погодження, права доступу, журнал змін і реєстри реалізовані коректно
|-
| 75–89
| Добре
| Основна логіка функціонує, виступає як незначні недоліки, які не руйнують роботу архіву
|-
| 60–74
| Зараховано
| Базовий сценарій функціонує, але частина функцій реалізована неповно або потребує доопрацювання
|-
| 0–59
| Не зараховано
| Відсутня критична логіка: документи, версії, файли, права доступу, пошук або журнал змін
|}
 
Веб-архів документів із версіями виступає як критично важливим для будь-якої компанії, яка функціонує з договорами, технічною документацією, внутрішніми політиками, проєктами, фінансовими файлами або юридичними матеріалами.== Ролі користувачів ==
Наявність історії змін, контроль доступу і можливість відновити попередню версію зменшують ризик втрати важливої інформації та підвищують прозорість роботи з документами. | Реєстр документів, документи на погодженні, історія продукту змін, архівні документи
|-
| Що виступає як критичною вимогою?[[Категорія:K2 ERP]]
 
Документ — провідний об’єкт веб-архіву. Відповідь
 
* неможливо створити документ;
* неможливо завантажити файл;
* перша реліз системи не створюється автоматизовано;
* нова реліз системи перезаписує стару;
* неможливо переглянути історію версій;
* неможливо визначити поточну версію;
* відновлення старої версії не функціонує;
* зміни не логуються;
* користувач системи без прав бачить закритий документ;
* користувач системи без прав здатна завантажити файл;
* погодження не прив’язується до версії;
* пошук не знаходить документ за назвою;
* реєстр документів не відповідає фактичним даним;
* видалення документа не контролюється правами. платформа повинна дозволяти:
 
== Контрольний реєстр для ревізії має містити ==
 
* завантаження кількох файлів одночасно;
* автоматичне створення карток документів;
* вибір категорії для всієї групи;
* присвоєння тегів;
* перегляд списку перед збереженням;
* логування операції. | користувач системи без прав не повинен бачити або завантажувати закриті документи
|-
| Що бажано додати? Статус
== Довідник «Категорії документів» ==
|-
| Бекенд
| K2 Cloud ERP на Python або PHP
|-
| База даних
| PostgreSQL або MySQL
|-
| Фронтенд
| HTML5, JavaScript
|-
| AJAX
| Fetch API або Axios
|-
|-
|Бекенд
| UI-компоненти
|K2 Cloud ERP на Python або PHP
| DataTables для документів та версій, Select2 для категорій, тегів і фільтрів
|-
|-
|БД
| Файли
|PostgreSQL або MySQL
| Завантаження файлів до файлової системи, бази або S3-сумісного сховища
|-
|-
|Фронтенд
| Порівняння
|HTML5, JavaScript, AJAX, Fetch API або Axios
| Diff для текстових документів, опціонально
|-
|-
|UI-компоненти
| Друк
|DataTables для документів та версій, Select2 для категорій і фільтрів
| PDF-реєстри, контрольні списки, звіти
|-
|-
|Файли
| Експорт
|Завантаження файлів до файлової системи або в базу, опціонально збереження на Amazon S3 чи аналогах
| Excel або PDF для реєстрів
|-
|-
|Друк
| Безпека
|Генерація контрольних реєстрів у PDF або Excel
| Рольові права, журнал дій, обмеження доступу до файлів
|}
|}


== Примітка ==
== Коментарі і нотатки ==
Типи доступу:
 
конфігурація доступу на рівні документа:
! Рівень
Доступ до історії змін гарантує:
! Бали
 
== Статуси погодження ==
 
У результаті виконання атестаційного задача має бути створений компонент веб-архіву документів у K2 ERP. ! Кожен документ повинен мати картку, категорію, статус, теги, файл, версії, історію змін, права доступу та журнал дій користувачів. !== Поля категорії ==
 
* договори;
* політики та інструкції;
* технічні документи;
* юридичні документи;
* фінансові документи;
* кадрові документи;
* проєкти;
* комерційні пропозиції;
* акти;
* рахунки;
* шаблони;
* внутрішні регламенти;
* інше. '''провідний принцип.''' Жоден важливий документ не повинен губитися: користувач системи має бачити актуальну версію, історію змін, автора змін, статус документа і права доступу. Для важливих документів потрібен бізнес-процес погодження. Значення
Категорії допомагають структурувати архів. |-
| користувач системи
| Переглядає доступні документи
|-
| Автор документа
| Створює документи і додає нові версії
|-
|-
|Реалізація бази документів і версій
| Редактор
|20
| Редагує картки документів і додає версії
|-
|-
|керування історією змін
| Погоджувач
|20
| Погоджує або відхиляє документи
|-
|-
|Контроль доступу і прав на документи
| Адміністратор архіву
|20
| Керує категоріями, правами, версіями і реєстрами
|-
|-
|Зручність перегляду, пошуку і відновлення документів
| Керівник
|20
| Переглядає контрольні звіти і статуси документів
|-
|-
|Інтерактивність через AJAX і технічна технічна технічна підтримка багатьох форматів
| Адміністратор системи
|20
| Налаштовує права, довідники, сховище файлів і службові параметри
|}
|}


Категорії документів:
Типи доступу визначають функції ERP користувачів.{{DISPLAYTITLE:Атестаційні завдання K2 ERP/Веб-архів документів}}
== Реальний бізнес-контекст ==
 
платформа має зберігати:
 
Ревізія потрібна для перевірки актуальності архіву. SEO-опис


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


* завантаження нової версії документу;
== Статуси документа ==
* перегляд історії змін;
* відновлення попередньої версії.==== функції ERP ====
=== 5. Доступ і права ===  


* хто здатна переглядати;
* оригінальну назву файлу;
* хто здатна редагувати;
* технічну назву файлу;
* хто здатна затверджувати.==== Довідник «Категорії документів» ====
* розмір файлу;
* формат;
* дату завантаження;
* автора завантаження;
* прив’язку до документа;
* прив’язку до версії.== Зберігання файлів ==


* створення нового документу;
! !== Рекомендовані сутності бази даних ==
* призначення категорії і доступу;
* можливість додавати кілька версій документа.=== 1. Структура довідників ===
Необхідно:


* перегляд;
== Основні об’єкти модуля ==
* редагування;
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
* завантаження / експорт;
== Мета задача ==
* адміністрування. функції ERP:
|-
| Назва категорії
| як приклад: Договори, Інструкції, Технічні документи
|-
| Батьківська категорія
| Для багаторівневої структури
|-
| SEO-опис
| Коротке пояснення
|-
| Активність
| Чи застосовується для категорія
|}
 
Кожен документ здатна мати багато версій. * критично;
* юридичний;
* фінансовий блок;
* клієнт ERP;
* постачальник;
* шаблон;
* архів;
* на погодженні;
* конфіденційно;
* проєкт;
* терміново. 100
 
[[Категорія:Версійність]]
 
{| class="wikitable" style="width:100%;"
 
* пошук документів;
* фільтрація документів;
* створення документа;
* завантаження файлу;
* додавання нової версії;
* перегляд історії версій;
* зміна статусу документа;
* передача на погодження;
* погодження документа;
* відхилення документа;
* додавання коментаря;
* відновлення версії;
* фільтрація звітів. ! SEO-опис
 
</div>


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

Поточна версія на 20:40, 1 травня 2026

критично. Нова реліз системи документа не повинна перезаписувати старий файл.== База «Версії документів» ==

Основні типи доступу

  • перегляд;
  • редагування;
  • завантаження;
  • експорт;
  • додавання версії;
  • погодження;
  • затвердження;
  • видалення;
  • адміністрування.== Довідник «Теги» ==
  • документ;
  • категорію;
  • останню версію;
  • дату архівації;
  • причину архівації;
  • відповідального.

Колонки бази документів

  • за категорією;
  • за статусом;
  • за автором;
  • за тегом;
  • за датою;
  • за наявністю актуальної версії;
  • за документами на погодженні;
  • за архівними документами. | Права доступу, актуальну версію, історію змін, погодження

|- | Які звіти потрібні? Пошук має бути зручним і швидким. * документ;

  • версію;
  • користувача;
  • дію;
  • дату і час;
  • SEO-опис змін. {| class="wikitable" style="width:100%;"

Файли можуть зберігатися:

Звіт «Архівні документи»

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

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

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

Звіт «історія продукту змін»

! | Документ із файлами і версіями |-

| Що критично для версій?

Практичне задача

Довідник «Типи доступу»

Доступ і права

Правила версійності

  • порівняння TXT;
  • порівняння тексту, витягнутого з DOCX, якщо реалізовано;
  • порівняння текстових полів;
  • показ доданих рядків;
  • показ видалених рядків;
  • показ змінених фрагментів.== Колонки версій ==

Звіт «Документи на погодженні»

== базовий бізнес-процес ==

Веб-архів документів — це практична задача; так само реалізовано файлами, історією змін, контролем доступу, пошуком, погодженням, відновленням попередніх версій і формуванням контрольних реєстрів виступає ключовою рисою перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля електронного архіву документів із версіями забезпечується через Атестаційне задача K2 ERP. Коротко. Потрібно реалізувати веб-архів документів: категорії, документи, файли, версії, теги, статуси, історія продукту змін, порівняння версій, відновлення попередніх версій, права доступу, погодження, пошук, ревізія, експорт і AJAX-інтерактив. платформа має підтримувати чіткі правила роботи з версіями. |-

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

! У звіті потрібно відображати:

  1. створити категорії документів;
  2. створити типи документів;
  3. створити теги;
  4. створити користувачів або ролі доступу;
  5. створити новий документ;
  6. додати назву, категорію, тип і SEO-опис;
  7. завантажити файл першої версії;
  8. перевірити, що створено версію v1;
  9. додати другу версію документа;
  10. додати SEO-опис змін;
  11. перевірити історію версій;
  12. зробити другу версію актуальною;
  13. передати документ на погодження;
  14. погодити документ;
  15. змінити статус на «Затверджено»;
  16. відновити попередню версію;
  17. перевірити, що дія записана в журнал;
  18. налаштувати доступ тільки для певної ролі;
  19. перевірити, що користувач системи без прав не бачить документ;
  20. виконати пошук за назвою;
  21. виконати фільтр за категорією;
  22. сформувати реєстр документів;
  23. сформувати звіт історії змін;
  24. перевірити журнал завантажень.== Звіт «Реєстр документів» ==
  • доступ до всіх документів;
  • доступ до категорії;
  • доступ до конкретного документа;
  • доступ тільки до перегляду;
  • доступ до редагування;
  • доступ до завантаження файлу;
  • доступ до додавання версій;
  • доступ до погодження;
  • доступ до адміністрування. Поле

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

Теги потрібні для швидкої фільтрації документів. Значення

Фільтри

Через AJAX мають працювати:

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

Вимоги до файлів

Параметри пошуку

Критичними помилками вважаються ситуації, коли:
== Звіти == == Поля погодження ==
  • складно знайти потрібний документ;
  • незрозуміло, яка реліз системи виступає як актуальною;
  • документи зберігаються у різних користувачів;
  • зміни не фіксуються;
  • попередні версії втрачаються;
  • немає контролю доступу;
  • немає історії погодження;
  • неможливо оперативно провести ревізію документів. Призначення
Документ Батьківська картка документа
Номер версії як приклад: v1, v2, v3
Файл Завантажений файл
Формат файлу PDF, DOCX, XLSX, TXT, PNG, JPG тощо
Автор версії Хто додав версію
Дата і час Коли додано версію
SEO-опис змін Що було змінено
Коментар Додаткові примітки
Статус Актуальна, архівна, відхилена

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

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

Основні правила

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

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

Інтерфейс має працювати оперативно і без перезавантаження сторінок. # користувач системи відкриває історію версій;

  1. обирає попередню версію;
  2. натискає «Відновити»;
  3. платформа створює нову версію на основі обраної;
  4. ця реліз системи стає поточною;
  5. дія записується в журнал змін. Разом

Для текстових документів бажано реалізувати порівняння версій.== Логування змін ==

Відновлення попередньої версії

  • у файловій системі сервера;
  • у базі даних;
  • у хмарному сховищі;
  • у S3-сумісному сховищі;
  • в іншому зовнішньому сховищі. | компонент веб-архіву документів
Які довідники потрібні? Об’єкт

База «Документи»

Мета задача — створити в K2 ERP компонент веб-архіву для зберігання, пошуку, оновлення версій, погодження і контролю версій документів. ! Критерій

Рівні доступу

SEO-опис

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

Погодження документів

Мінімальний сценарій:

Що потрібно створити? * K2 ERP

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

Звіт «Документи без актуальної версії»

  • назву документа;
  • категорію;
  • тип;
  • номер;
  • дату документа;
  • автора;
  • поточну версію;
  • статус;
  • відповідального.== Підтримувані варіанти порівняння ==
== Див. так само ==

Коментар має містити

  • вести категорії документів;
  • вести типи документів;
  • вести теги;
  • створювати картки документів;
  • завантажувати файли документів;
  • додавати нові версії файлів;
  • бачити поточну версію документа;
  • переглядати історію версій;
  • порівнювати версії текстових документів;
  • відновлювати попередню версію;
  • фіксувати автора змін;
  • зберігати SEO-опис змін;
  • налаштовувати права доступу;
  • обмежувати перегляд, редагування, завантаження і видалення;
  • погоджувати або затверджувати документи;
  • вести журнал дій користувачів;
  • шукати документи за назвою, категорією, тегами, автором, датою і статусом;
  • формувати контрольні реєстри;
  • експортувати списки документів у PDF або Excel.== Коротко ==
Колонка
  • перша завантажена реліз системи отримує номер v1;
  • кожне нове завантаження створює нову версію;
  • стара реліз системи не видаляється автоматизовано;
  • лише одна реліз системи здатна бути поточною;
  • поточна реліз системи має бути помітно позначена;
  • користувач системи здатна переглянути історію версій;
  • користувач системи із правами здатна відновити попередню версію;
  • відновлення попередньої версії має логуватися. Усі версії мають зберігатися в історії. | Diff версій, batch upload, журнал завантажень, контрольну ревізію документів

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

Пошук документів

Назва документа Назва для пошуку і відображення
Категорія До якої групи належить документ
Тип документа Договір, наказ, інструкція тощо
Номер документа Внутрішній або зовнішній номер
Дата створення Коли документ створено
Автор Хто створив картку
Поточна реліз системи Актуальна реліз системи файлу
Статус Чернетка, на перегляді, затверджено, архівовано
Теги Позначки для пошуку

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

Який провідний об’єкт? SEO-опис == функції ERP масового завантаження ==

Приклади категорій

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

компонент має підтримувати контроль доступу на рівні документів. !== Назва задача ==

функції ERP
Документ До якого документа належить реліз системи
реліз системи v1, v2, v3 або інший формат
Дата завантаження Коли додано версію
Автор змін Хто завантажив файл
SEO-опис змін Що змінилося
Файл Завантажений документ
Статус версії Чернетка, актуальна, архівна, скасована
Поле Типовий бізнес-процес роботи з документом виглядає так: компонент обліку електронних документів з версіями та контролем змін.== Приклади типів ==
Бали

Шкала оцінювання

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

  • автора;
  • дату і час;
  • текст коментаря;
  • прив’язку до документа або версії;
  • статус, якщо коментар пов’язаний із доопрацюванням. ! ! ! У звіті потрібно відображати:

Порівняння версій

  • документ;
  • версію;
  • погоджувача;
  • дату передачі;
  • поточний статус;
  • кількість днів на погодженні.== Очікуваний результат ==

Примітка

Довідник «Типи документів»

Не потрібно Документ не потребує погодження
Очікує погодження Документ передано відповідальній особі
Погоджено Документ прийнято
Відхилено Документ не прийнято
Повернено на доопрацювання Потрібні зміни

Опціонально можна реалізувати batch upload. Без централізованого архіву виникають типові проблеми:

  1. користувач системи створює картку документа;
  2. обирає категорію і тип документа;
  3. додає назву, номер, дату і SEO-опис;
  4. завантажує файл першої версії;
  5. платформа створює версію v1;
  6. документ отримує статус «Чернетка»;
  7. користувач системи передає документ на перегляд або погодження;
  8. відповідальна особа погоджує документ або повертає на доопрацювання;
  9. автор завантажує нову версію;
  10. платформа створює версію v2;
  11. історія продукту змін зберігається;
  12. після затвердження документ отримує статус «Затверджено»;
  13. при потребі користувач системи здатна переглянути стару версію або відновити її;
  14. адміністратор формує контрольний реєстр документів. Окремо варто відзначити юридичних, технічних, фінансових, проєктних і інших документів організації. Статус

AJAX-інтерактив

У межах атестації потрібно продемонструвати робочий сценарій. Що перевіряється

Чернетка Документ створено, але ще не погоджено
На перегляді Документ перевіряється
На погодженні Очікує погодження відповідальної особи
Повернено на доопрацювання Потрібні зміни
Затверджено Документ прийнято як актуальний
Замінено новою версією виступає як новіша реліз системи документа
Архівовано Документ збережено для історії
Скасовано Документ більше не застосовується для
Колонка
Категорії документів Групування документів за напрямами Типи документів Договір, наказ, інструкція, політика, креслення тощо Документи Основні картки документів Версії документів історія продукту файлів і змін Файли PDF, DOCX, XLSX, TXT, зображення та інші формати Теги Швидке маркування і пошук документів Права доступу Хто здатна переглядати, редагувати, погоджувати, завантажувати Погодження бізнес-процес перевірки і затвердження документа Коментарі Обговорення документа або версії Журнал змін історія продукту дій користувачів Реєстри Контрольні списки документів компонент повинен фіксувати всі важливі дії.== Масове завантаження документів == користувач системи із відповідними правами здатна відновити стару версію. |-
Назва документа Повна назва документа
Категорія Категорія архіву
Тип документа Вид документа
Номер документа Номер, якщо виступає як
Дата документа Дата створення або підписання
Автор Хто створив документ
Відповідальний Хто відповідає за актуальність
SEO-опис Короткий зміст
Теги Позначки для пошуку
Поточна реліз системи Актуальна реліз системи
Статус Поточний стан документа
Коментарі Службові нотатки

Критерії оцінювання

Поля версії документа

Критичні помилки

SEO-опис

Журнал змін має зберігати: У звіті потрібно відображати документи, у яких:

Ревізія документів

Реалізація бази документів і версій 20 Документи, категорії, типи, файли, версії, поточна реліз системи, історія продукту версій
керування історією змін 20 SEO-опис змін, автор змін, журнал дій, відновлення версій, порівняння версій
Контроль доступу і прав на документи 20 Перегляд, редагування, завантаження, погодження, обмеження для користувачів без прав
Зручність перегляду, пошуку і відновлення документів 20 Пошук, фільтри, теги, статуси, реєстри, відновлення попередньої версії
Інтерактивність через AJAX і технічна підтримка багатьох форматів 20 AJAX-завантаження, оновлення версій версій, фільтрація, PDF, DOCX, XLSX, TXT та інші формати

У звіті потрібно відображати:

Логіка відновлення

У звіті потрібно відображати:

90–100 Відмінно компонент на 100% функціонує: документи, версії, файли, пошук, погодження, права доступу, журнал змін і реєстри реалізовані коректно 75–89 Добре Основна логіка функціонує, виступає як незначні недоліки, які не руйнують роботу архіву 60–74 Зараховано Базовий сценарій функціонує, але частина функцій реалізована неповно або потребує доопрацювання 0–59 Не зараховано Відсутня критична логіка: документи, версії, файли, права доступу, пошук або журнал змін

Веб-архів документів із версіями виступає як критично важливим для будь-якої компанії, яка функціонує з договорами, технічною документацією, внутрішніми політиками, проєктами, фінансовими файлами або юридичними матеріалами.== Ролі користувачів == Наявність історії змін, контроль доступу і можливість відновити попередню версію зменшують ризик втрати важливої інформації та підвищують прозорість роботи з документами. | Реєстр документів, документи на погодженні, історія продукту змін, архівні документи |- | Що виступає як критичною вимогою?

Документ — провідний об’єкт веб-архіву. Відповідь

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

Контрольний реєстр для ревізії має містити

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

|- | Що бажано додати? Статус

Довідник «Категорії документів»

|- | Бекенд | K2 Cloud ERP на Python або PHP |- | База даних | PostgreSQL або MySQL |- | Фронтенд | HTML5, JavaScript |- | AJAX | Fetch API або Axios |- | UI-компоненти | DataTables для документів та версій, Select2 для категорій, тегів і фільтрів |- | Файли | Завантаження файлів до файлової системи, бази або S3-сумісного сховища |- | Порівняння | Diff для текстових документів, опціонально |- | Друк | PDF-реєстри, контрольні списки, звіти |- | Експорт | Excel або PDF для реєстрів |- | Безпека | Рольові права, журнал дій, обмеження доступу до файлів |}

Коментарі і нотатки

! Рівень ! Бали

Статуси погодження

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

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

Категорії допомагають структурувати архів. |- | користувач системи | Переглядає доступні документи |- | Автор документа | Створює документи і додає нові версії |- | Редактор | Редагує картки документів і додає версії |- | Погоджувач | Погоджує або відхиляє документи |- | Адміністратор архіву | Керує категоріями, правами, версіями і реєстрами |- | Керівник | Переглядає контрольні звіти і статуси документів |- | Адміністратор системи | Налаштовує права, довідники, сховище файлів і службові параметри |}

Типи доступу визначають функції ERP користувачів.

платформа має зберігати:

Ревізія потрібна для перевірки актуальності архіву. SEO-опис

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

Статуси документа

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

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

Основні об’єкти модуля

Мета задача

|- | Назва категорії | як приклад: Договори, Інструкції, Технічні документи |- | Батьківська категорія | Для багаторівневої структури |- | SEO-опис | Коротке пояснення |- | Активність | Чи застосовується для категорія |}

Кожен документ здатна мати багато версій. * критично;

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

Користувачі можуть залишати коментарі до документа або конкретної версії. SEO-опис

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