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

Атестаційне завдання K2 ERP — Пропускна в концертний зал — це практична задача для перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля перевірки квитків, контролю проходів і обліку відвідувачів на заходах.

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

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

Назва завдання

Модуль перевірки квитків і обліку проходів на заходах.

Мета завдання

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

Система повинна дозволяти:

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

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

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

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

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

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

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

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

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

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

1. адміністратор створює захід;
2. для заходу створюються або імпортуються квитки;
3. кожен квиток має унікальний номер або QR-код;
4. контролер відкриває екран сканування;
5. відвідувач показує квиток;
6. контролер сканує QR-код або вводить номер вручну;
7. система перевіряє квиток;
8. якщо квиток активний і дійсний — прохід дозволено;
9. статус квитка змінюється на «Використаний»;
10. фіксується час, пункт входу і контролер;
11. якщо квиток уже використаний або недійсний — прохід заборонено;
12. спроба входу записується в журнал;
13. керівник бачить статистику проходів у реальному часі.

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

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

Довідник «Заходи»

Довідник заходів містить події, для яких потрібно перевіряти квитки.

Поля заходу

Поле	Опис
Назва заходу	Назва концерту, вистави, конференції або іншої події
Дата і час	Коли відбувається захід
Зал проведення	Місце проведення
Кількість місць	Загальна кількість місць або доступних квитків
Статус	Запланований, активний, завершений, скасований
Час відкриття входу	Коли дозволено починати пропуск
Час закриття входу	Коли пропуск завершується

Довідник «Квитки»

Квиток є основним об’єктом перевірки.

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

Поля квитка

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

Статуси квитка

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

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

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

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

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

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

Процес перевірки квитка

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

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

1. Контролер відкриває екран сканування.
2. Обирає захід і пункт входу.
3. Сканує QR-код квитка або вводить номер вручну.
4. Система шукає квиток.
5. Перевіряє, чи належить квиток до обраного заходу.
6. Перевіряє статус квитка.
7. Перевіряє, чи не був квиток уже використаний.
8. Показує результат перевірки.
9. Якщо прохід дозволено — фіксує прохід.
10. Якщо прохід заборонено — записує неуспішну спробу.

Результати перевірки

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

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

Після сканування система має показати чіткий результат.

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

Ситуація	Повідомлення
Успішний прохід	Прохід дозволено
Повторне сканування	Квиток уже використаний
Недійсний квиток	Квиток недійсний
Інший захід	Квиток не належить цьому заходу
Неоплачений квиток	Квиток не оплачений
Невідомий код	Квиток не знайдено

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

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

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

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

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

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

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

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

Такі квитки можуть використовуватися для:

• VIP;
• Staff Pass;
• організаторів;
• технічного персоналу;
• охорони;
• преси.

Поля спеціальної перепустки

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

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

Залишок проходів = Дозволені проходи - Використані проходи

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

Журнал проходів містить усі успішні проходи.

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

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

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

Журнал спроб входу має фіксувати не тільки успішні, а й неуспішні спроби.

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

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

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

Модуль має підтримувати сканування QR-коду.

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

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

Ручний режим

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

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

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

Система повинна показувати статистику в реальному часі.

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

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

Оперативний екран контролю

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

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

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

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

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

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

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

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

Опціонально можна реалізувати режим часткової роботи при нестабільному інтернеті.

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

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

Примітка. Офлайн-режим є розширеною функцією. У базовій реалізації достатньо стабільної онлайн-перевірки через AJAX.

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

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

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

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

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

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

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

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

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

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

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

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

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

Звіт показує навантаження на входи.

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

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

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

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

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

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

Логування змін

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

Журнал змін має зберігати:

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

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

Модуль має підтримувати розмежування прав.

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

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

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

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

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

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

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

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

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

1. створити захід;
2. створити зал;
3. створити кілька квитків;
4. згенерувати або вказати QR-коди;
5. створити пункт входу;
6. створити контролера;
7. відкрити екран сканування;
8. перевірити активний квиток;
9. дозволити прохід;
10. перевірити зміну статусу на «Використаний»;
11. повторно просканувати той самий квиток;
12. перевірити заборону повторного проходу;
13. перевірити недійсний квиток;
14. перевірити квиток, що не належить цьому заходу;
15. виконати ручне введення номера квитка;
16. створити спеціальну перепустку з кількома проходами;
17. перевірити кілька проходів по спеціальній перепустці;
18. переглянути журнал проходів;
19. переглянути журнал неуспішних спроб;
20. переглянути статистику заходу;
21. сформувати звіт дубльованих спроб;
22. сформувати звіт по пунктах входу.

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

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

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

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

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

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

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

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

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

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

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

Примітка

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

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

Коротко

Питання	Відповідь
Що потрібно створити?	Модуль перевірки квитків і обліку проходів
Які довідники потрібні?	Заходи, квитки, пункти входу, контролери
Який головний об’єкт?	Квиток з унікальним номером або QR-кодом
Яке головне правило?	Один звичайний квиток — один прохід
Що має робити система після проходу?	Змінити статус квитка на використаний і записати час проходу
Що має бути при повторному скануванні?	Прохід заборонено, спроба записується в журнал
Які звіти потрібні?	Проходи, неуспішні спроби, дублікати, статистика по входах
Що є критичною вимогою?	Захист від повторного проходу за тим самим квитком

Див. також

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