Атестаційні завдання K2 ERP/Пропускна в концертний зал
Атестаційне завдання K2 ERP — Пропускна в концертний зал — це практична задача для перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля перевірки квитків, контролю проходів і обліку відвідувачів на заходах.
Модуль має забезпечувати швидку перевірку квитків на вході, сканування QR-кодів, ручне введення номера квитка, контроль статусу квитка, захист від повторного проходу, фіксацію всіх спроб входу, статистику відвідуваності та оперативний контроль заповненості залу.
Коротко. Потрібно реалізувати пропускну систему для заходів: сканування QR-квитків, ручне введення номера, перевірка дійсності, фіксація проходу, заборона повторного входу, логування спроб і статистика проходів у реальному часі.
Назва завдання
Модуль перевірки квитків і обліку проходів на заходах.
Мета завдання
Мета завдання — створити в K2 ERP модуль для контролю входу на концерт, виставу, фестиваль, конференцію або інший захід.
Система повинна дозволяти:
- вести заходи;
- вести квитки по заходах;
- перевіряти квиток за QR-кодом;
- перевіряти квиток за ручним введенням номера;
- визначати статус квитка;
- дозволяти або забороняти прохід;
- змінювати статус квитка після проходу;
- запобігати повторному проходу за одним квитком;
- фіксувати час проходу;
- фіксувати пункт входу;
- фіксувати контролера;
- логувати всі успішні та неуспішні спроби входу;
- показувати статистику проходів у реальному часі;
- працювати швидко на мобільному пристрої або стаціонарному сканері;
- підтримувати спеціальні типи перепусток, якщо потрібно;
- формувати звіти по відвідуваності, дублях і проблемних квитках.
Головний принцип. Пропускна система повинна миттєво відповісти контролеру: пропустити людину чи ні. Усі деталі — статус квитка, повторний прохід, час, пункт входу і контролер — мають фіксуватися автоматично.
Реальний бізнес-контекст
Після продажу або бронювання квитків організатор заходу повинен забезпечити контроль входу в зал.
На вході працюють контролери, які сканують квитки відвідувачів. Система має швидко визначати, чи є квиток дійсним, чи він оплачений, чи належить саме цьому заходу, чи не був використаний раніше.
Пропускна система потрібна для:
- концертів;
- фестивалів;
- театральних вистав;
- конференцій;
- спортивних подій;
- виставок;
- закритих корпоративних заходів;
- лекцій і навчальних подій.
Без такої системи виникають черги, дублювання проходів, ризик використання скопійованих квитків, складність у підрахунку фактичної відвідуваності та проблеми з контролем залу.
Основний бізнес-процес
Типовий процес роботи пропускної системи виглядає так:
- адміністратор створює захід;
- для заходу створюються або імпортуються квитки;
- кожен квиток має унікальний номер або QR-код;
- контролер відкриває екран сканування;
- відвідувач показує квиток;
- контролер сканує QR-код або вводить номер вручну;
- система перевіряє квиток;
- якщо квиток активний і дійсний — прохід дозволено;
- статус квитка змінюється на «Використаний»;
- фіксується час, пункт входу і контролер;
- якщо квиток уже використаний або недійсний — прохід заборонено;
- спроба входу записується в журнал;
- керівник бачить статистику проходів у реальному часі.
Основні об’єкти модуля
| Об’єкт | Призначення |
|---|---|
| Заходи | Події, на які здійснюється пропуск |
| Зали | Місця проведення заходів |
| Квитки | Унікальні електронні або паперові квитки |
| QR-коди | Коди для швидкої перевірки квитків |
| Пункти входу | Входи, через які проходять відвідувачі |
| Контролери | Працівники, які перевіряють квитки |
| Проходи | Успішні факти входу за квитком |
| Спроби входу | Усі успішні й неуспішні перевірки |
| Статистика | Дані про кількість пропущених і непропущених гостей |
| Звіти | Аналітика по проходах, квитках, пунктах входу і подіях |
Довідник «Заходи»
Довідник заходів містить події, для яких потрібно перевіряти квитки.
Поля заходу
| Поле | Опис |
|---|---|
| Назва заходу | Назва концерту, вистави, конференції або іншої події |
| Дата і час | Коли відбувається захід |
| Зал проведення | Місце проведення |
| Кількість місць | Загальна кількість місць або доступних квитків |
| Статус | Запланований, активний, завершений, скасований |
| Час відкриття входу | Коли дозволено починати пропуск |
| Час закриття входу | Коли пропуск завершується |
Довідник «Квитки»
Квиток є основним об’єктом перевірки.
Кожен квиток повинен мати унікальний ідентифікатор.
Поля квитка
| Поле | Опис |
|---|---|
| Номер квитка | Унікальний номер квитка |
| QR-код | Унікальний код для сканування |
| Захід | На який захід діє квиток |
| Ряд | Номер ряду, якщо використовується посадка |
| Місце | Номер місця |
| Сектор | Сектор залу, якщо є |
| Покупець | ПІБ або контакт покупця, якщо зберігається |
| Статус | Активний, використаний, недійсний, скасований |
| Тип квитка | Звичайний, VIP, Staff Pass, службовий |
| Кількість дозволених проходів | Зазвичай 1, для спеціальних перепусток може бути більше |
Статуси квитка
| Статус | Значення |
|---|---|
| Активний | Квиток дійсний і готовий для проходу |
| Використаний | За квитком уже здійснено прохід |
| Недійсний | Квиток не може бути використаний |
| Не оплачений | Квиток створено або заброньовано, але оплата не підтверджена |
| Скасований | Квиток анульовано |
| Повернений | Квиток повернено покупцем |
| Заблокований | Квиток заблоковано адміністратором |
Важливо. Для проходу має підходити тільки квиток зі статусом «Активний» або спеціальна перепустка з дозволеним залишком проходів.
Довідник «Пункти входу»
Пункт входу — це місце, де здійснюється перевірка квитків.
Поля пункту входу
| Поле | Опис |
|---|---|
| Назва пункту входу | Наприклад: Центральний вхід, Вхід №2, VIP-вхід |
| Захід | До якого заходу належить пункт |
| Зал | Де розташований вхід |
| Відповідальний | Контролер або група контролерів |
| Статус | Активний або неактивний |
Процес перевірки квитка
Перевірка квитка повинна бути максимально швидкою.
Кроки перевірки
- Контролер відкриває екран сканування.
- Обирає захід і пункт входу.
- Сканує QR-код квитка або вводить номер вручну.
- Система шукає квиток.
- Перевіряє, чи належить квиток до обраного заходу.
- Перевіряє статус квитка.
- Перевіряє, чи не був квиток уже використаний.
- Показує результат перевірки.
- Якщо прохід дозволено — фіксує прохід.
- Якщо прохід заборонено — записує неуспішну спробу.
Результати перевірки
| Результат | Дія системи |
|---|---|
| Прохід дозволено | Квиток активний, статус змінюється на використаний, прохід фіксується |
| Квиток уже використаний | Прохід заборонено, показується попередження |
| Квиток недійсний | Прохід заборонено, причина фіксується в журналі |
| Квиток не оплачений | Прохід заборонено |
| Квиток не належить цьому заходу | Прохід заборонено |
| Квиток не знайдено | Прохід заборонено, спроба фіксується |
Повідомлення контролеру
Після сканування система має показати чіткий результат.
Приклади повідомлень
| Ситуація | Повідомлення |
|---|---|
| Успішний прохід | Прохід дозволено |
| Повторне сканування | Квиток уже використаний |
| Недійсний квиток | Квиток недійсний |
| Інший захід | Квиток не належить цьому заходу |
| Неоплачений квиток | Квиток не оплачений |
| Невідомий код | Квиток не знайдено |
Логіка одного проходу
Базове правило:
Один квиток = один прохід
Після успішного проходу система повинна:
- змінити статус квитка на «Використаний»;
- зафіксувати дату і час проходу;
- зафіксувати пункт входу;
- зафіксувати контролера;
- заборонити повторний вхід за тим самим квитком.
Критично. Повторне сканування вже використаного квитка не повинно дозволяти прохід. Система має показати попередження і записати спробу в журнал.
Спеціальні перепустки
Опціонально система може підтримувати квитки з кількома проходами.
Такі квитки можуть використовуватися для:
- 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-коди;
- пункти входу;
- контролери;
- проходи;
- спроби входу;
- статуси квитків;
- спеціальні перепустки;
- статистика заходу;
- журнал змін;
- звіти;
- права доступу.
Практичне завдання
У межах атестації потрібно продемонструвати робочий сценарій.
Мінімальний сценарій:
- створити захід;
- створити зал;
- створити кілька квитків;
- згенерувати або вказати QR-коди;
- створити пункт входу;
- створити контролера;
- відкрити екран сканування;
- перевірити активний квиток;
- дозволити прохід;
- перевірити зміну статусу на «Використаний»;
- повторно просканувати той самий квиток;
- перевірити заборону повторного проходу;
- перевірити недійсний квиток;
- перевірити квиток, що не належить цьому заходу;
- виконати ручне введення номера квитка;
- створити спеціальну перепустку з кількома проходами;
- перевірити кілька проходів по спеціальній перепустці;
- переглянути журнал проходів;
- переглянути журнал неуспішних спроб;
- переглянути статистику заходу;
- сформувати звіт дубльованих спроб;
- сформувати звіт по пунктах входу.
Критерії оцінювання
| Критерій | Бали | Що перевіряється |
|---|---|---|
| Реалізація перевірки квитка і зміни статусу | 20 | Пошук квитка, перевірка заходу, статусу, оплати, зміна на використаний після проходу |
| Логування проходів | 20 | Успішні проходи, неуспішні спроби, контролер, пункт входу, дата і причина відмови |
| Інтерактивність і миттєве відображення результату | 20 | Швидке сканування, зрозуміле повідомлення, AJAX-оновлення без перезавантаження |
| Управління статистикою проходів | 20 | Кількість пропущених, невикористаних, проблемних і повторних спроб у реальному часі |
| Робота з QR-кодами і ручний режим | 20 | Сканування QR, ручне введення номера, підтримка різних сценаріїв перевірки |
| Разом | 100 | Максимальна оцінка |
Шкала оцінювання
| Бали | Рівень | Опис |
|---|---|---|
| 90–100 | Відмінно | Модуль повністю працює: QR-сканування, ручний режим, статуси, захист від повторного проходу, логи, статистика і звіти реалізовані коректно |
| 75–89 | Добре | Основна логіка працює, є незначні недоліки, які не руйнують процес пропуску гостей |
| 60–74 | Зараховано | Базовий сценарій працює, але частина функцій реалізована неповно або потребує доопрацювання |
| 0–59 | Не зараховано | Відсутня критична логіка: перевірка квитка, зміна статусу, захист від повторного проходу або журнал спроб |
Критичні помилки
Критичними помилками вважаються ситуації, коли:
- неможливо створити захід;
- неможливо створити квиток;
- квиток не має унікального номера або QR-коду;
- активний квиток не пропускається;
- використаний квиток повторно пропускається;
- квиток іншого заходу пропускається;
- недійсний або неоплачений квиток пропускається;
- після проходу статус квитка не змінюється;
- час проходу не фіксується;
- пункт входу не фіксується;
- контролер не фіксується;
- неуспішні спроби не логуються;
- статистика не відповідає фактичним проходам;
- ручний режим не працює;
- дубльовані спроби не відображаються у звіті.
Умова складання. Завдання не може бути зараховане, якщо система не дозволяє пройти базовий цикл пропускної системи: квиток → сканування → перевірка → дозвіл або відмова → фіксація проходу → захист від повторного входу → звіт.
Очікуваний результат
У результаті виконання атестаційного завдання має бути створений модуль пропускної системи в K2 ERP.
Модуль має підтримувати заходи, зали, квитки, QR-коди, пункти входу, контролерів, сканування, ручне введення, перевірку статусу, фіксацію проходу, захист від повторного використання квитка, спеціальні перепустки, журнали проходів, журнали спроб, статистику, звіти, AJAX-інтерактив і логування змін.
Примітка
Модуль пропускної системи критично важливий для концертів, фестивалів, вистав, конференцій, спортивних подій і великих масових заходів.
Він допомагає уникати черг, запобігати повторному використанню квитків, контролювати фактичну відвідуваність і забезпечувати швидкий та зручний вхід для гостей.
Коротко
| Питання | Відповідь |
|---|---|
| Що потрібно створити? | Модуль перевірки квитків і обліку проходів |
| Які довідники потрібні? | Заходи, квитки, пункти входу, контролери |
| Який головний об’єкт? | Квиток з унікальним номером або QR-кодом |
| Яке головне правило? | Один звичайний квиток — один прохід |
| Що має робити система після проходу? | Змінити статус квитка на використаний і записати час проходу |
| Що має бути при повторному скануванні? | Прохід заборонено, спроба записується в журнал |
| Які звіти потрібні? | Проходи, неуспішні спроби, дублікати, статистика по входах |
| Що є критичною вимогою? | Захист від повторного проходу за тим самим квитком |