Атестаційні завдання K2 ERP/Пропускна в концертний зал: відмінності між версіями

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

! функції ERP

Звіт «Проходи за заходом»

Після сканування платформа має показати чіткий результат. платформа повинна дозволяти: ! |- | Дата і час | Коли була спроба |- | Введений код | Що було відскановано або введено |- | Захід | Для якого заходу виконувалася перевірка |- | Пункт входу | Де була спроба |- | Контролер | Хто виконував перевірку |- | Результат | Дозволено або заборонено |- | Причина відмови | Використаний, недійсний, не знайдено, інший захід тощо |}

!== Поля заходу ==

Звіт показує навантаження на входи.== Журнал спроб входу ==

камера не функціонує;
QR-код пошкоджений;
сканер не читає код;
квиток надруковано неякісно;
потрібно перевірити квиток за номером. ! Що перевіряється

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

|- | Активний | Квиток дійсний і готовий для проходу |- | Використаний | За квитком уже здійснено прохід |- | Недійсний | Квиток не здатна бути використаний |- | Не оплачений | Квиток створено або заброньовано, але оплата не підтверджена |- | Скасований | Квиток анульовано |- | Повернений | Квиток повернено покупцем |- | Заблокований | Квиток заблоковано адміністратором |}

Звіт «Дубльовані спроби»

Поля квитка

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

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

Колонки журналу спроб

Назва пункту входу	як приклад: Центральний вхід, Вхід №2, VIP-вхід
Захід	До якого заходу належить пункт
Зал	Де розташований вхід
Відповідальний	Контролер або група контролерів
Статус	Активний або неактивний

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

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

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

компонент повинен фіксувати важливі дії. 100

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

Звіт показує всі успішні проходи на конкретний захід. ! У звіті потрібно відображати: Інтерфейс має працювати оперативно та без перезавантаження сторінки. SEO-опис

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

Пропускна платформа потрібна для:

компонент має підтримувати сканування QR-коду. SEO-опис

# адміністратор створює захід;
# для заходу створюються або імпортуються квитки;
# кожен квиток має унікальний номер або QR-код;
# контролер відкриває екран сканування;
# відвідувач показує квиток;
# контролер сканує QR-код або вводить номер вручну;
# платформа перевіряє квиток;
# якщо квиток активний і дійсний — прохід дозволено;
# статус квитка змінюється на '''«Використаний»''';
# фіксується час, пункт входу і контролер;
# якщо квиток уже використаний або недійсний — прохід заборонено;
# спроба входу записується в журнал;
# керівник бачить статистику проходів у реальному часі. ! # Контролер відкриває екран сканування.== Ручний режим ==

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

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

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

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

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

Критичними помилками вважаються ситуації, коли:

! ! '''компонент перевірки квитків і обліку проходів на заходах'''. SEO-опис

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

! Критерій

компонент має підтримувати заходи, зали, квитки, QR-коди, пункти входу, контролерів, сканування, ручне введення, перевірку статусу, фіксацію проходу, захист від повторного використання квитка, спеціальні перепустки, журнали проходів, журнали спроб, статистику, звіти, AJAX-інтерактив і логування змін. ! SEO-опис
!== Довідник «Пункти входу» ==
Мінімальний сценарій:

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

== Основні показники ==

== Колонки журналу проходів ==

[[Категорія:Події]]
== Результати перевірки ==
{| class="wikitable" style="width:100%;"
|-
| Дата і час
| Коли здійснено прохід
|-
| Захід
| На який захід пройшов відвідувач
|-
| Квиток
| Номер квитка або QR-код
|-
| Ряд і місце
| Місце відвідувача, якщо виступає як
|-
| Пункт входу
| Через який вхід пройшов відвідувач
|-
| Контролер
| Хто виконав перевірку
|-
| Результат
| Дозволено
|}

== Примітка ==

! Значення
__TOC__
!== Довідник «Заходи» ==
== Спеціальні перепустки ==
{| class="wikitable" style="width:100%;"

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

Для керівника або адміністратора потрібен екран контролю заходу. * поточну кількість пропущених гостей;
* залишок непройдених квитків;
* проблемні спроби входу;
* дубльовані спроби;
* активність по пунктах входу;
* останні сканування;
* загальний відсоток проходу. ! SEO-опис
|-
| Тип перепустки
| VIP, Staff Pass, Press, Organizer
|-
| Кількість дозволених проходів
| Скільки разів можна пройти
|-
| Кількість використаних проходів
| Скільки проходів уже зафіксовано
|-
| Залишок проходів
| Скільки проходів ще доступно
|}

== Повідомлення контролеру ==

'''Критично.''' Повторне сканування вже використаного квитка не повинно дозволяти прохід. | Проходи, неуспішні спроби, дублікати, статистика по входах
|-
| Що виступає як критичною вимогою?== Статуси квитка ==

компонент має забезпечувати швидку перевірку квитків на вході, сканування QR-кодів, ручне введення номера квитка, контроль статусу квитка, захист від повторного проходу, фіксацію всіх спроб входу, статистику відвідуваності та оперативний контроль заповненості залу. # Перевіряє, чи не був квиток уже використаний.== Довідник «Квитки» ==

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

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

== Безпека перевірки ==

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

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

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

! Він оптимізує уникати черг, запобігати повторному використанню квитків, контролювати фактичну відвідуваність і забезпечувати швидкий та зручний вхід для гостей. # Обирає захід і пункт входу. '''Коротко.''' Потрібно реалізувати пропускну систему для заходів: сканування QR-квитків, ручне введення номера, перевірка дійсності, фіксація проходу, заборона повторного входу, логування спроб і статистика проходів у реальному часі. # Перевіряє статус квитка. Разом

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

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

* [[K2 Cloud ERP|K2 ERP]]
* [[K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Бронювання квитків на події]]
* [[Квиток]]
* [[QR-код]]
* [[Концертний зал]]
* [[Подія]]
* [[Пропускна система]]
* [[Звітність]]
* [[AJAX]]

{{DISPLAYTITLE:Атестаційні завдання K2 ERP/Пропускна в концертний зал}}
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
<pre>
Один квиток = один прохід
Після продажу або бронювання квитків організатор заходу повинен забезпечити контроль входу в зал. платформа має оперативно визначати, чи виступає як квиток дійсним, чи він оплачений, чи належить саме цьому заходу, чи не був використаний раніше.== Практичне задача ==
У результаті виконання атестаційного задача має бути створений компонент пропускної системи в K2 ERP. |-
| Назва заходу
| Назва концерту, вистави, конференції або іншої події
|-
| Дата і час
| Коли відбувається захід
|-
| Зал проведення
| Місце проведення
|-
| Кількість місць
| Загальна кількість місць або доступних квитків
|-
| Статус
| Запланований, активний, завершений, скасований
|-
| Час відкриття входу
| Коли дозволено починати пропуск
|-
| Час закриття входу
| Коли пропуск завершується
|}

Опціонально можна реалізувати режим часткової роботи при нестабільному інтернеті. У звіті потрібно відображати:
!== базовий бізнес-процес ==

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

<div style="border:2px solid #f57c00; background:#fff3e0; padding:14px; margin:16px 0;">

* дату і час;
* введений код;
* захід;
* пункт входу;
* контролера;
* причину відмови. Бали
Базове правило:
</div>
|-
| Бекенд
| K2 Cloud ERP на Python або PHP
|-
| База даних
| PostgreSQL або MySQL
|-
| Фронтенд
| HTML5, JavaScript
|-
| AJAX
| Fetch API або Axios
|-
| Сканування QR-коду
| Через камеру пристрою або підключений сканер
|-
| Ручний режим
| Введення номера квитка вручну
|-
| UI
| Велике контрастне повідомлення: дозволено / заборонено
|-
| Друк
| Не обов’язково, основна робота виконується електронно
|-
| Експорт
| Excel або PDF для звітів
|}

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

* камера мобільного пристрою;
* планшет;
* ноутбук із камерою;
* стаціонарний USB-сканер;
* ручне введення номера квитка як резервний варіант. # Перевіряє, чи належить квиток до обраного заходу. компонент пропускної системи критично важливий для концертів, фестивалів, вистав, конференцій, спортивних подій і великих масових заходів. Відповідь
|-
| Прохід дозволено
| Квиток активний, статус змінюється на використаний, прохід фіксується
|-
| Квиток уже використаний
| Прохід заборонено, показується попередження
|-
| Квиток недійсний
| Прохід заборонено, причина фіксується в журналі
|-
| Квиток не оплачений
| Прохід заборонено
|-
| Квиток не належить цьому заходу
| Прохід заборонено
|-
| Квиток не знайдено
| Прохід заборонено, спроба фіксується
|}

! !== Журнал проходів ==

== Звіт «Неуспішні спроби входу» ==

Квиток виступає як основним об’єктом перевірки. У звіті потрібно відображати:

Опціонально платформа здатна підтримувати квитки з кількома проходами. SEO-опис

Такі квитки можуть використовуватися для:
== Сканування QR-кодів ==
== Логіка одного проходу ==
|-
| Успішний прохід
| Прохід дозволено
|-
| Повторне сканування
| Квиток уже використаний
|-
| Недійсний квиток
| Квиток недійсний
|-
| Інший захід
| Квиток не належить цьому заходу
|-
| Неоплачений квиток
| Квиток не оплачений
|-
| Невідомий код
| Квиток не знайдено
|}

</div>

платформа повинна показувати статистику в реальному часі. '''провідний принцип.''' Пропускна платформа повинна миттєво відповісти контролеру: пропустити людину чи ні.== Критичні помилки ==

Типовий бізнес-процес роботи пропускної системи виглядає так:

* номер квитка;
* перший час проходу;
* час повторної спроби;
* пункт входу;
* контролера;
* кількість повторних спроб. SEO-опис

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

Після успішного проходу платформа повинна:

! Поле
</div>
! * загальна кількість квитків;
* кількість активних квитків;
* кількість використаних квитків;
* кількість невикористаних квитків;
* кількість недійсних спроб;
* кількість повторних спроб;
* кількість проходів по кожному пункту входу;
* відсоток заповненості залу. | Один звичайний квиток — один прохід
|-
| Що має робити платформа після проходу? ! Дія системи

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

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

'''критично.''' Для проходу має підходити тільки квиток зі статусом '''«Активний»''' або спеціальна перепустка з дозволеним залишком проходів. | Заходи, квитки, пункти входу, контролери
|-
| Який провідний об’єкт?

}

Звіт «Статистика по пунктах входу»

! Залишок проходів = Дозволені проходи - Використані проходи	== На екрані контролю потрібно бачити == Шкала оцінювання Журнал змін має зберігати:	Поле
Номер квитка	Унікальний номер квитка
QR-код	Унікальний код для сканування
Захід	На який захід діє квиток
Ряд	Номер ряду, якщо застосовується для посадка
Місце	Номер місця
Сектор	Сектор залу, якщо виступає як
Покупець	ПІБ або контакт покупця, якщо зберігається
Статус	Активний, використаний, недійсний, скасований
Тип квитка	Звичайний, VIP, Staff Pass, службовий
Кількість дозволених проходів	Зазвичай 1, для спеціальних перепусток здатна бути більше

Робота при нестабільному інтернеті

Формула залишку проходів

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

Роль

Примітка. Офлайн-режим виступає як розширеною функцією. | компонент перевірки квитків і обліку проходів

Які довідники потрібні?

Реальний бізнес-контекст

змінити статус квитка на «Використаний»;
зафіксувати дату і час проходу;
зафіксувати пункт входу;
зафіксувати контролера;
заборонити повторний вхід за тим самим квитком. Колонка

== Статистика проходів ==

VIP;
Staff Pass;
організаторів;
технічного персоналу;
охорони;
преси. Ручне введення потрібне, якщо:

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

Основні вимоги безпеки

Реалізація перевірки квитка і зміни статусу

20

Пошук квитка, перевірка заходу, статусу, оплати, зміна на використаний після проходу

Логування проходів

20

Успішні проходи, неуспішні спроби, контролер, пункт входу, дата і причина відмови

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

20

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

керування статистикою проходів

20

Кількість пропущених, невикористаних, проблемних і повторних спроб у реальному часі

Робота з QR-кодами і ручний режим

20

Сканування QR, ручне введення номера, технічна підтримка різних сценаріїв перевірки

Заходи	Події, на які здійснюється пропуск
Зали	Місця проведення заходів
Квитки	Унікальні електронні або паперові квитки
QR-коди	Коди для швидкої перевірки квитків
Пункти входу	Входи, через які проходять відвідувачі
Контролери	Працівники, які перевіряють квитки
Проходи	Успішні факти входу за квитком
Спроби входу	Усі успішні й неуспішні перевірки
Статистика	інформаційні дані про кількість пропущених і непропущених гостей
Звіти	аналітичні інструменти по проходах, квитках, пунктах входу і подіях

На вході працюють контролери, які сканують квитки відвідувачів.== Варіанти сканування ==

Див. так само

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

Поля пункту входу

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

Кроки перевірки

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

|- | Що має бути при повторному скануванні? Журнал проходів містить усі успішні проходи. Результат У межах атестації потрібно продемонструвати робочий сценарій. Кожен квиток повинен мати унікальний ідентифікатор. Звіт показує повторні спроби проходу за вже використаним квитком. Усі деталі — статус квитка, повторний прохід, час, пункт входу і контролер — мають фіксуватися автоматизовано. * вести заходи;

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

! | Квиток з унікальним номером або QR-кодом |- | Яке головне правило?== Можливі підходи ==

! # Якщо прохід дозволено — фіксує прохід. Об’єкт

Мета задача

! # Сканує QR-код квитка або вводить номер вручну. # Показує результат перевірки. Питання |- | Що потрібно створити? Поле

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

Назва задача

створити захід;
створити зал;
створити кілька квитків;
згенерувати або вказати QR-коди;
створити пункт входу;
створити контролера;
відкрити екран сканування;
перевірити активний квиток;
дозволити прохід;
перевірити зміну статусу на «Використаний»;
повторно просканувати той самий квиток;
перевірити заборону повторного проходу;
перевірити недійсний квиток;
перевірити квиток, що не належить цьому заходу;
виконати ручне введення номера квитка;
створити спеціальну перепустку з кількома проходами;
перевірити кілька проходів по спеціальній перепустці;
переглянути журнал проходів;
переглянути журнал неуспішних спроб;
переглянути статистику заходу;
сформувати звіт дубльованих спроб;
сформувати звіт по пунктах входу. {| class="wikitable" style="width:100%;"