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

Атестаційні завдання K2 ERP/Бронювання квитків на події

Матеріал з K2 ERP Wiki Ukraine — База знань з автоматизації та санкцій в Україні
Версія від 19:01, 1 травня 2026, створена R (обговорення | внесок)
(різн.) ← Попередня версія | Поточна версія (різн.) | Новіша версія → (різн.)


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

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

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

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

Модуль онлайн-бронювання квитків на вистави і заходи.

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

Мета завдання — створити в K2 ERP модуль для автоматизації бронювання та продажу квитків на культурні, освітні або розважальні події.

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

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

Головний принцип. Квиток — це не просто запис у таблиці. Він має бути пов’язаний із подією, залом, рядом, місцем, покупцем, оплатою, статусом і QR-кодом для перевірки на вході.

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

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

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

Адміністратор повинен бачити:

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

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

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

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

  1. адміністратор створює зал;
  2. налаштовує ряди та місця;
  3. створює подію;
  4. система генерує квитки для події;
  5. користувач відкриває афішу;
  6. вибирає подію;
  7. бачить доступні місця;
  8. вибирає одне або кілька місць;
  9. вводить ПІБ, телефон і email;
  10. підтверджує бронювання;
  11. система тимчасово блокує місця;
  12. користувач оплачує квитки онлайн;
  13. після успішної оплати квитки стають проданими;
  14. система формує PDF-квиток із QR-кодом;
  15. покупець отримує квиток на email;
  16. адміністратор бачить продаж у журналі та звітах.

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

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

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

Довідник залів містить місця проведення подій.

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

Поля залу

Поле Опис
Назва залу Наприклад: Театр Шевченка, Концерт-хол, Велика сцена
Місткість Загальна кількість місць
Адреса Місце проведення
Опис Короткий опис залу
Схема залу SVG, Canvas, файл або таблична схема місць
Статус Активний або неактивний

Схема залу

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

Мінімальна схема може бути табличною: ряд і місце.

Розширена схема може бути інтерактивною: SVG або Canvas із візуальним вибором місць.

Поля місця в залі

Поле Опис
Зал До якого залу належить місце
Сектор Партер, балкон, ложа або інша зона
Ряд Номер або назва ряду
Місце Номер місця
Категорія місця VIP, стандарт, економ або інша категорія
Базова ціна Опціонально, якщо ціна залежить від місця
Активність Чи доступне місце для продажу

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

Довідник «Вистави і заходи»

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

Поля події

Поле Опис
Назва події Назва вистави, концерту або заходу
Дата і час проведення Коли відбувається подія
Зал Де проходить подія
Опис Короткий опис для афіші
Афіша Зображення або постер події
Тривалість Тривалість у хвилинах
Жанр Драма, опера, концерт, лекція, кіно, фестиваль тощо
Вікове обмеження Опціонально, наприклад 6+, 12+, 16+
Статус Чернетка, опубліковано, продаж відкрито, продаж закрито, скасовано

Жанри подій

Приклади жанрів:

  • драма;
  • комедія;
  • опера;
  • балет;
  • концерт;
  • лекція;
  • кіно;
  • фестиваль;
  • дитяча вистава;
  • стендап.

Афіша подій

Афіша — це публічний список подій, доступних для перегляду та купівлі квитків.

У афіші потрібно показувати:

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

Журнал «Квитки»

Журнал квитків показує всі місця, згенеровані для конкретної події.

Колонки журналу квитків

Колонка Опис
Номер квитка Унікальний номер квитка
Подія На який захід створено квиток
Зал Зал проведення
Сектор Зона залу
Ряд Номер ряду
Місце Номер місця
Статус Вільне, заброньоване, продане, скасоване
Ціна Вартість квитка
Покупець Дані покупця, якщо квиток заброньований або проданий

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

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

Генерація квитків для події

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

При генерації потрібно врахувати:

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

Процес бронювання квитка

Бронювання дозволяє тимчасово закріпити місце за покупцем до моменту оплати.

Кроки бронювання

  1. Користувач вибирає подію з афіші.
  2. Система відкриває схему залу або список доступних місць.
  3. Користувач вибирає одне або кілька місць.
  4. Система перевіряє, чи місця ще вільні.
  5. Користувач вводить ПІБ, телефон і email.
  6. Система створює бронювання.
  7. Місця переходять у статус «Заброньоване».
  8. Користувач отримує підтвердження на email.
  9. Якщо квитки не оплачені вчасно, бронювання автоматично скасовується.

Поля бронювання

Поле Опис
Номер бронювання Унікальний номер бронювання
Подія Подія, на яку бронюються квитки
Покупець ПІБ покупця
Телефон Контактний номер
Email Адреса для підтвердження та квитків
Квитки Вибрані місця
Сума Загальна вартість бронювання
Час створення Коли створено бронювання
Час дії До якого часу бронювання активне
Статус Активне, оплачене, прострочене, скасоване

Обмеження часу бронювання

Бронювання може мати обмежений час дії, наприклад 30 хвилин.

Після завершення строку система повинна:

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

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

Ліміти бронювання

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

Наприклад:

Максимум 5 квитків за одне бронювання

Система повинна перевіряти ліміт перед створенням бронювання або оплатою.

Купівля квитка

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

Процес купівлі

  1. Користувач вибирає квитки.
  2. Система створює замовлення або бронювання.
  3. Користувач переходить до оплати.
  4. Платіжна система повертає результат.
  5. Якщо оплата успішна, квитки переходять у статус «Продане».
  6. Система формує електронні квитки.
  7. Покупець отримує PDF-квитки на email.

Платіжні системи

Модуль може підтримувати інтеграцію з платіжними шлюзами:

  • WayForPay;
  • LiqPay;
  • Stripe;
  • інший платіжний сервіс.

Поля оплати

Поле Опис
Номер платежу Унікальний номер платежу
Бронювання або замовлення До чого належить оплата
Сума Сума платежу
Валюта Валюта оплати
Платіжна система WayForPay, LiqPay, Stripe або інша
Статус платежу Очікує, успішний, відхилений, повернений
Дата платежу Коли виконано оплату
Технічний ідентифікатор ID транзакції з платіжної системи

Електронний квиток

Після успішної оплати система повинна сформувати електронний квиток.

Дані електронного квитка

У PDF-квитку потрібно показати:

  • номер квитка;
  • назву події;
  • дату і час;
  • зал;
  • сектор;
  • ряд;
  • місце;
  • ПІБ покупця;
  • ціну;
  • QR-код;
  • правила відвідування, якщо потрібно.

QR-код квитка

QR-код потрібен для перевірки квитка на вході.

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

Перевірка QR-коду

При скануванні QR-коду система повинна показати:

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

Після успішного проходу квиток може отримати статус «Використано».

Практичний сенс. QR-код захищає від повторного проходу за одним квитком і дозволяє швидко перевіряти відвідувачів на вході.

Кабінет адміністратора

Кабінет адміністратора потрібен для управління подіями, квитками, бронюваннями та продажами.

Функції адміністратора

Адміністратор повинен мати можливість:

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

Скасування бронювання

Скасування бронювання може виконуватися:

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

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

  • змінити статус бронювання;
  • повернути квитки у статус «Вільне»;
  • записати причину скасування;
  • за потреби надіслати повідомлення покупцю.

Повернення квитка

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

При поверненні потрібно:

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

Звітність

Звіт «Заповненість залу»

Звіт показує, скільки місць доступно, заброньовано і продано.

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

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

Звіт «Продажі квитків»

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

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

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

Звіт «Бронювання»

Звіт показує активні, оплачені, прострочені та скасовані бронювання.

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

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

Звіт «Відвідуваність»

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

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

  • подію;
  • продані квитки;
  • використані квитки;
  • невикористані квитки;
  • відсоток фактичної відвідуваності.

Звіт «Доходи по подіях»

Звіт показує фінансовий результат по кожній події.

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

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

Email-нотифікації

Модуль має надсилати email-повідомлення покупцю.

Події для email

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

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

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

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

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

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

Захист від подвійного бронювання

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

Для цього потрібно:

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

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

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

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

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

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

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

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

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

Параметр Опис
Бекенд K2 Cloud ERP на Python або PHP
База даних PostgreSQL або MySQL
Фронтенд HTML5, JavaScript
AJAX Axios або Fetch API
UI-компоненти DataTables, Select2
Схема залу SVG або Canvas, опціонально
Платежі WayForPay, LiqPay, Stripe або інший шлюз
Друк PDF-квитки з QR-кодами
Email Відправка підтверджень і квитків покупцям

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

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

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

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

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

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

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

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

Критерій Бали Що перевіряється
Реалізація журналу вистав і квитків 20 Зали, події, схема місць, генерація квитків, статуси місць
Процес бронювання і купівлі квитків 20 Вибір місць, бронювання, таймер, оплата, зміна статусів
Генерація електронних квитків 20 PDF-квиток, QR-код, email-відправка, перевірка квитка
Звітність і облік заповненості залу 20 Заповненість, продажі, бронювання, відвідуваність, доходи
Інтерактивність через AJAX і підтримка платіжних систем 20 AJAX-вибір місць, перевірка доступності, інтеграція з WayForPay/LiqPay/Stripe
Разом 100 Максимальна оцінка

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

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

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

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

  • неможливо створити зал;
  • неможливо створити подію;
  • квитки не генеруються для місць залу;
  • два користувачі можуть забронювати одне й те саме місце;
  • бронювання не змінює статус місця;
  • прострочене бронювання не повертає місце у продаж;
  • оплата не переводить квиток у статус «Продане»;
  • PDF-квиток не формується;
  • QR-код не є унікальним;
  • QR-код можна використати повторно без контролю;
  • звіт заповненості не відповідає реальним статусам квитків;
  • адміністратор не може скасувати бронювання;
  • email-підтвердження не надсилається, якщо ця функція заявлена;
  • зміни статусів квитків не логуються.

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

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

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

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

Примітка

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

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

Коротко

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

Див. також