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

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

Скасування бронювання здатна виконуватися:

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

Поля залу

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

Жанри подій

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

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

! | Тимчасово блокувати місце і повертати його в продаж після завершення строку |- | Що відбувається після оплати? SEO-опис

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

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

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

Схема залу

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

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

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

Звіт «продажі та реалізація квитків»

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

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

Без такого модуля продаж квитків часто ведеться вручну, через таблиці, телефони або месенджери. Об’єкт компонент повинен фіксувати важливі дії.== Генерація квитків для події ==

Події для email

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

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

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

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

Див. так само

|- | Бекенд | 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-перевірка → звіт. {| class="wikitable" style="width:100%;"

Театр, концерт-хол, культурний центр, кінотеатр, філармонія або організатор подій хоче продавати квитки онлайн. # Якщо оплата успішна, квитки переходять у статус «Продане». * перевіряти статус місця перед бронюванням;

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

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

! # Платіжна платформа повертає результат. # створити зал;

створити ряди та місця;
створити подію;
додати афішу, SEO-опис, дату й час;
згенерувати квитки для події;
відкрити афішу;
вибрати подію;
вибрати кілька місць;
створити бронювання;
перевірити зміну статусу місць на «Заброньоване»;
перевірити таймер бронювання;
оформити оплату;
перевести квитки у статус «Продане»;
сформувати PDF-квиток із QR-кодом;
надіслати підтвердження на email;
перевірити QR-код на вході;
скасувати тестове бронювання;
перевірити повернення місць у статус «Вільне»;
сформувати звіт заповненості залу;
сформувати звіт продажів;
сформувати звіт бронювань;
сформувати звіт відвідуваності. * K2 ERP

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

Афіша подій

Мета задача — створити в K2 ERP компонент для автоматизації бронювання та продажу квитків на культурні, освітні або розважальні події. # Покупець отримує PDF-квитки на email. # платформа створює замовлення або бронювання.

платформа повинна дозволяти:

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

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

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

! # Якщо квитки не оплачені вчасно, бронювання автоматизовано скасовується.== Платіжні системи ==

! SEO-опис

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

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

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

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

! Після скасування бронювання платформа повинна:
компонент має підтримувати розмежування прав. У звіті потрібно відображати:

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

<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">

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

<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">

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

== QR-код квитка ==

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

'''Критично.''' Якщо бронювання закінчилося і не було оплачено, місця мають автоматизовано повернутися в продаж. {| class="wikitable" style="width:100%;"

Після завершення строку платформа повинна:
== Довідник «Вистави і заходи» ==
== Очікуваний результат ==

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

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

Бронювання здатна мати обмежений час дії, як приклад 30 хвилин. Повідомлення потрібно надсилати:
== Перевірка QR-коду ==
== Email-нотифікації ==
|-
| Назва події
| Назва вистави, концерту або заходу
|-
| Дата і час проведення
| Коли відбувається подія
|-
| Зал
| Де проходить подія
|-
| SEO-опис
| Короткий SEO-опис для афіші
|-
| Афіша
| Зображення або постер події
|-
| Тривалість
| Тривалість у хвилинах
|-
| Жанр
| Драма, опера, концерт, лекція, кіно, фестиваль тощо
|-
| Вікове обмеження
| Опціонально, як приклад 6+, 12+, 16+
|-
| Статус
| Чернетка, опубліковано, продаж відкрито, продаж закрито, скасовано
|}

== Мета задача ==

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

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

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

! # Місця переходять у статус '''«Заброньоване»'''. | Заповненість залу, продажі та реалізація, бронювання, відвідуваність, доходи
|-
| Що виступає як критичною вимогою? Максимальна оцінка

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

Адміністратор повинен мати можливість:
== Журнал «Квитки» ==
'''критично.''' Схема залу має виключати подвійне бронювання або продаж одного й того самого місця на одну подію. # адміністратор створює зал;
# налаштовує ряди та місця;
# створює подію;
# платформа генерує квитки для події;
# користувач системи відкриває афішу;
# вибирає подію;
# бачить доступні місця;
# вибирає одне або кілька місць;
# вводить ПІБ, телефон і email;
# підтверджує бронювання;
# платформа тимчасово блокує місця;
# користувач системи оплачує квитки онлайн;
# після успішної оплати квитки стають проданими;
# платформа формує PDF-квиток із QR-кодом;
# покупець отримує квиток на email;
# адміністратор бачить продаж у журналі та звітах.== Поля події ==

! # платформа формує електронні квитки.[[Категорія:Електронні квитки]]

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

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

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

</div>

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

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

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

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

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

Критичними помилками вважаються ситуації, коли:
{| class="wikitable" style="width:100%;"
Максимум 5 квитків за одне бронювання
|-
| Зал
| До якого залу належить місце
|-
| Сектор
| Партер, балкон, ложа або інша зона
|-
| Ряд
| Номер або назва ряду
|-
| Місце
| Номер місця
|-
| Категорія місця
| VIP, стандарт, економ або інша категорія
|-
| Базова ціна
| Опціонально, якщо ціна залежить від місця
|-
| Активність
| Чи доступне місце для продажу
|}

Окремо варто відзначити лекції, кіносеанси, фестивалі і інші заходи.== Практичне задача ==

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

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

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

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

! Призначення

платформа повинна перевіряти ліміт перед створенням бронювання або оплатою.== Критичні помилки ==
'''Практичний сенс.''' QR-код захищає від повторного проходу за одним квитком і дає можливість оперативно перевіряти відвідувачів на вході. |-
| Номер квитка
| Унікальний номер квитка
|-
| Подія
| На який захід створено квиток
|-
| Зал
| Зал проведення
|-
| Сектор
| Зона залу
|-
| Ряд
| Номер ряду
|-
| Місце
| Номер місця
|-
| Статус
| Вільне, заброньоване, продане, скасоване
|-
| Ціна
| Вартість квитка
|-
| Покупець
| інформаційні дані покупця, якщо квиток заброньований або проданий
|}

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

Звіт показує, скільки проданих квитків реально було використано на вході. компонент має надсилати email-повідомлення покупцю. # платформа перевіряє, чи місця ще вільні. Звіт показує продажі та реалізація за вибраний період. Поле
Опціонально компонент здатна підтримувати повернення проданого квитка. Відповідь
== AJAX-інтерактив ==
У межах атестації потрібно продемонструвати робочий сценарій. Це створює ризик подвійного продажу одного місця, втрати бронювань і помилок у звітності. ! Бали

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

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

Купівля квитка здатна відбуватися одразу або після бронювання. Довідник залів містить місця проведення подій.== Звіт «Доходи по подіях» ==

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

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

Адміністратор повинен бачити:
== Звіт «Бронювання» ==
== Критерії оцінювання ==
== Поля місця в залі ==
|-
| Реалізація журналу вистав і квитків
| 20
| Зали, події, схема місць, генерація квитків, статуси місць
|-
| бізнес-процес бронювання і купівлі квитків
| 20
| Вибір місць, бронювання, таймер, оплата, зміна статусів
|-
| Генерація електронних квитків
| 20
| PDF-квиток, QR-код, email-відправка, перевірка квитка
|-
| формування звітів і обліковий облік заповненості залу
| 20
| Заповненість, продажі та реалізація, бронювання, відвідуваність, доходи
|-
| Інтерактивність через AJAX і технічна підтримка платіжних систем
| 20
| AJAX-вибір місць, перевірка доступності, інтеграційні функції ERP з WayForPay/LiqPay/Stripe
|-
Після успішного проходу квиток здатна отримати статус '''«Використано»'''. # платформа створює бронювання. ! | Квиток на конкретну подію, ряд і місце
|-
| Які статуси потрібні? |-
| Що потрібно створити? | Квиток стає проданим, формується PDF із QR-кодом
|-
| Які звіти потрібні?== Коротко ==

</div>

* WayForPay;
* LiqPay;
* Stripe;
* інший платіжний сервіс. !<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">

* подію;
* зал;
* загальну кількість місць;
* вільні місця;
* заброньовані місця;
* продані місця;
* заблоковані місця;
* відсоток заповненості. У PDF-квитку потрібно показати:

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

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

Звіт показує активні, оплачені, прострочені та скасовані бронювання. Інакше зал буде штучно заблокований неоплаченими бронюваннями. При скануванні QR-коду платформа повинна показати:

! | Зали, місця, події, жанри, покупці
|-
| Який провідний об’єкт?[[Категорія:Бронювання квитків]]

* змінити статус квитка;
* зафіксувати причину;
* створити запис про повернення коштів;
* не дозволити повторне використання старого QR-коду;
* відобразити операцію у звітах. | Вільне, заброньоване, очікує оплати, продане, скасоване
|-
| Що має робити бронювання? Мінімальна схема здатна бути табличною: ряд і місце.== Обмеження часу бронювання ==

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

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

== Поля оплати ==

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

компонент здатна підтримувати інтеграцію з платіжними шлюзами:
! ! # користувач системи вводить ПІБ, телефон і email. Статус

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

* перегляд афіші;
* вибір події;
* завантаження схеми залу;
* вибір місця;
* перевірка доступності місця;
* створення бронювання;
* таймер бронювання;
* перехід до оплати;
* оновлення версій статусу квитка;
* скасування бронювання;
* фільтрація бронювань і продажів;
* оновлення версій звітів. перевірки навичок розробника або впроваджувача [[K2 ERP]] у створенні модуля онлайн-бронювання та продажу квитків на вистави забезпечується через '''Атестаційне задача K2 ERP — Бронювання квитків на події''' — це практична задача; так само реалізовано концерти. SEO-опис

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

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

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

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

== Звіт «Відвідуваність» ==
! Він має бути пов’язаний із подією, залом, рядом, місцем, покупцем, оплатою, статусом і QR-кодом для перевірки на вході.== Колонки журналу квитків ==

# користувач системи вибирає подію з афіші. '''провідний принцип.''' Квиток — це не без зусиль запис у таблиці. SEO-опис

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

! {| class="wikitable" style="width:100%;"
! | Захист від подвійного бронювання або продажу одного місця
|}

Афіша — це публічний список подій, доступних для перегляду та купівлі квитків. # користувач системи переходить до оплати. | компонент онлайн-бронювання і продажу квитків
|-
| Які довідники потрібні? функції ERP

!

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

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