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

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

!;== Поля спеціальної перепустки == Примітка. Офлайн-режим є собою розширеною функцією.; # Сканує QR-код квитка або вводить номер вручну.; | Один звичайний квиток — один прохід |- | Що має робити платформа після проходу?; Після успішного проходу платформа повинна:

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

Логіка одного проходу

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

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

компонент має підтримувати заходи, зали, квитки, QR-коди, пункти входу, контролерів, сканування, ручне введення, перевірку статусу, фіксацію проходу, захист від повторного використання квитка, спеціальні перепустки, журнали проходів, журнали спроб, статистику, звіти, AJAX-інтерактив і логування змін.; | компонент перевірки квитків і обліку проходів |- | Які довідники потрібні?; !; Відповідь

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

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

Варіанти сканування

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

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

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

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

Назва задача

ключовий бізнес-процес

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

Кожен квиток повинен мати унікальний ідентифікатор.; У звіті потрібно відображати:

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

; Параметр
Що потрібно створити?; !; Статус
Реалізація перевірки квитка і зміни статусу	20	Пошук квитка, перевірка заходу, статусу, оплати, зміна на використаний після проходу
Логування проходів	20	Успішні проходи, неуспішні спроби, контролер, пункт входу, дата і причина відмови
Інтерактивність і миттєве відображення результату	20	Швидке сканування, зрозуміле повідомлення, AJAX-оновлення без перезавантаження
керування статистикою проходів	20	Кількість пропущених, невикористаних, проблемних і повторних спроб у реальному часі
Робота з QR-кодами і ручний режим	20	Сканування QR, ручне введення номера, супровід різних сценаріїв перевірки

; Колонка

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

Можливі підходи

; Результат ; # Якщо прохід заборонено — записує неуспішну спробу.; Звіт показує повторні спроби проходу за вже використаним квитком.; Призначення ;== Поля пункту входу == Заходи, квитки, пункти входу, контролери Який центральний об’єкт?;== Очікуваний результат == Захист від повторного проходу за тим самим квитком

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

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

== Спеціальні перепустки ==

!; # Перевіряє, чи не був квиток уже використаний.; Квиток є собою основним об’єктом перевірки.; характеристика

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

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

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

'''Критично.''' Повторне сканування вже використаного квитка не повинно дозволяти прохід.; Бали

* захід;
* дату і час проходу;
* номер квитка;
* ряд і місце;
* пункт входу;
* контролера.; | Квиток з унікальним номером або QR-кодом
|-
| Яке головне правило?; # Перевіряє статус квитка.; | Змінити статус квитка на використаний і записати час проходу
|-
| Що має бути при повторному скануванні?; Критерій

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

Журнал проходів містить усі успішні проходи.; У звіті потрібно відображати:

Ручне введення потрібне, якщо:

!; компонент повинен фіксувати важливі дії.; Поле
__TOC__

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

Один квиток = один прохід

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

== Довідник «Пункти входу» ==

<pre>
Пункт входу — це місце, де здійснюється перевірка квитків.;<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
|-
| Бекенд
| K2 Cloud ERP на Python або PHP
|-
| База даних
| PostgreSQL або MySQL
|-
| Фронтенд
| HTML5, JavaScript
|-
| AJAX
| Fetch API або Axios
|-
| Сканування QR-коду
| Через камеру пристрою або підключений сканер
|-
| Ручний режим
| Введення номера квитка вручну
|-
| UI
| Велике контрастне повідомлення: дозволено / заборонено
|-
| Друк
| Не обов’язково, основна робота виконується електронно
|-
| Експорт
| Excel або PDF для звітів
|}

</div>

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

* заходи;
* зали;
* квитки;
* типи квитків;
* QR-коди;
* пункти входу;
* контролери;
* проходи;
* спроби входу;
* статуси квитків;
* спеціальні перепустки;
* статистика заходу;
* журнал змін;
* звіти;
* права доступу.; Дія системи
|-
| Успішний прохід
| Прохід дозволено
|-
| Повторне сканування
| Квиток уже використаний
|-
| Недійсний квиток
| Квиток недійсний
|-
| Інший захід
| Квиток не належить цьому заходу
|-
| Неоплачений квиток
| Квиток не оплачений
|-
| Невідомий код
| Квиток не знайдено
|}

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

Звіт показує всі успішні проходи на конкретний захід.; характеристика

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

== Поля квитка ==

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

<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">

# створити захід;
# створити зал;
# створити кілька квитків;
# згенерувати або вказати QR-коди;
# створити пункт входу;
# створити контролера;
# відкрити екран сканування;
# перевірити активний квиток;
# дозволити прохід;
# перевірити зміну статусу на '''«Використаний»''';
# повторно просканувати той самий квиток;
# перевірити заборону повторного проходу;
# перевірити недійсний квиток;
# перевірити квиток, що не належить цьому заходу;
# виконати ручне введення номера квитка;
# створити спеціальну перепустку з кількома проходами;
# перевірити кілька проходів по спеціальній перепустці;
# переглянути журнал проходів;
# переглянути журнал неуспішних спроб;
# переглянути статистику заходу;
# сформувати звіт дубльованих спроб;
# сформувати звіт по пунктах входу.; * загальна кількість квитків;
* кількість активних квитків;
* кількість використаних квитків;
* кількість невикористаних квитків;
* кількість недійсних спроб;
* кількість повторних спроб;
* кількість проходів по кожному пункту входу;
* відсоток заповненості залу.; платформа повинна бути захищена від помилок і повторного використання квитків.; # Обирає захід і пункт входу.;

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

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

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

Ручний режим

На екрані контролю потрібно бачити

; компонент пропускної системи критично важливий для концертів, фестивалів, вистав, конференцій, спортивних подій і великих масових заходів.;== Поля заходу ==
Тип перепустки	VIP, Staff Pass, Press, Organizer
Кількість дозволених проходів	Скільки разів можна пройти
Кількість використаних проходів	Скільки проходів уже зафіксовано
Залишок проходів	Скільки проходів ще доступно

Приклади повідомлень

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

Сканування QR-кодів

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

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

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

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

; * поточну кількість пропущених гостей;

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

Журнал спроб входу

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

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

; характеристика

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

; Базове правило:

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

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

Контролер відкриває екран сканування.; Усі деталі — статус квитка, повторний прохід, час, пункт входу і контролер — мають фіксуватися автономно.; Рівень

істотно. Для проходу має підходити тільки квиток зі статусом «Активний» або спеціальна перепустка з дозволеним залишком проходів.; !; характеристика

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

У межах атестації потрібно продемонструвати робочий сценарій.;== бізнес-процес перевірки квитка ==

VIP;
Staff Pass;
організаторів;
технічного персоналу;
охорони;
преси.; # Показує результат перевірки.; Ситуація

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

Опціонально платформа має змогу підтримувати квитки з кількома проходами.; Журнал змін має зберігати: компонент перевірки квитків і обліку проходів на заходах.;== формування звітів ==

; компонент має підтримувати розмежування прав.; # платформа шукає квиток.; характеристика Інтерфейс має працювати оперативно та без перезавантаження сторінки.; Максимальна оцінка концертів; фестивалів; театральних вистав; конференцій; спортивних подій; виставок; закритих корпоративних заходів; лекцій і навчальних подій.; Колонка Реальний бізнес-контекст камера мобільного пристрою; планшет; ноутбук із камерою; стаціонарний USB-сканер; ручне введення номера квитка як резервний варіант.; Журнал спроб входу має фіксувати не тільки успішні, а й неуспішні спроби.; Роль Логування змін Мінімальний сценарій: Після сканування платформа має показати чіткий результат.; \| Проходи, неуспішні спроби, дублікати, статистика по входах
Що є собою критичною вимогою?;== Основні вимоги безпеки == Довідник «Заходи» Через AJAX мають працювати: Такі квитки можуть використовуватися для:	; функціональні можливості Безпека перевірки	; !;== Результати перевірки == Звіт «Статистика по пунктах входу» компонент має забезпечувати швидку перевірку квитків на вході, сканування QR-кодів, ручне введення номера квитка, контроль статусу квитка, захист від повторного проходу, фіксацію всіх спроб входу, статистику відвідуваності та оперативний контроль заповненості залу.; Залишок проходів = Дозволені проходи - Використані проходи
Заходи	Події, на які здійснюється пропуск
Зали	Місця проведення заходів
Квитки	Унікальні електронні або паперові квитки
QR-коди	Коди для швидкої перевірки квитків
Пункти входу	Входи, через які проходять відвідувачі
Контролери	Працівники, які перевіряють квитки
Проходи	Успішні факти входу за квитком
Спроби входу	Усі успішні й неуспішні перевірки
Статистика	інформаційні дані про кількість пропущених і непропущених гостей
Звіти	аналітичні інструменти по проходах, квитках, пунктах входу і подіях

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

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

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

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

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

Які звіти потрібні?; Мета задача — створити в K2 ERP компонент для контролю входу на концерт, виставу, фестиваль, конференцію або інший захід.; характеристика

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

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

компонент має підтримувати сканування QR-коду.; {| class="wikitable" style="width:100%;"

;== Критичні помилки == Звіт показує проблемні перевірки.; Опціонально можна реалізувати режим часткової роботи при нестабільному інтернеті.;== Див.; додатково == Звіт показує навантаження на входи.; 100

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