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

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

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

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

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

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

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

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

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

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

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

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

Події для email

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

як ілюстрація:

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

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

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

Довідник залів містить місця проведення подій.;== Довідник «Вистави і заходи» ==

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

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

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

!; Відповідь

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

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

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

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

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

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

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

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

!;

Схема залу

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

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

Поля події

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

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

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

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

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

Назва задача

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

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

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

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

!; Після успішної оплати платформа повинна сформувати електронний квиток.; Кабінет адміністратора потрібен для керування подіями, квитками, бронюваннями та продажами.; Після скасування бронювання платформа повинна: Звіт показує фінансовий результат по кожній події.;== Звіт «Заповненість залу» ==

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

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

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

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


</div>

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

* подію;
* кількість проданих квитків;
* загальний дохід;
* повернення;
* чистий дохід;
* заповненість залу.; # Якщо квитки не оплачені вчасно, бронювання автономно скасовується.; характеристика
!; Бронювання квитків на події''' — це практична задача; додатково реалізовано концерти.; | Зали, місця, події, жанри, покупці
|-
| Який центральний об’єкт?; Такий компонент підвищує доступність заходів для глядачів, автоматизує продажі та реалізація, зменшує ручну роботу касирів, запобігає подвійним продажам і дає організатору прозору аналітику по заповненості та доходах.; Об’єкт

[[Категорія:Бронювання квитків]]

* зал;
* усі активні місця;
* категорії місць;
* ціну;
* сектори;
* ряди;
* місця;
* статус '''«Вільне»''' для доступних квитків.; # користувач системи вводить ПІБ, телефон і email.; Критичними помилками вважаються ситуації, коли:

!; | Квиток стає проданим, формується PDF із QR-кодом
|-
| Які звіти потрібні?;== Логування змін ==

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

[[Категорія:Атестаційні завдання K2]]

!; # платформа формує електронні квитки.; !; {| class="wikitable" style="width:100%;"

платформа повинна дозволяти:
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
компонент має підтримувати зали, схеми місць, події, афішу, генерацію квитків, бронювання, онлайн-оплату, електронні PDF-квитки, QR-коди, перевірку квитків, email-нотифікації, кабінет адміністратора, скасування бронювань, звіти, AJAX-інтерактив і логування змін.;== Захист від подвійного бронювання ==
!; | Захист від подвійного бронювання або продажу одного місця
|}

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

* [[K2 Cloud ERP|K2 ERP]]
* [[K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Бронювання]]
* [[Квиток]]
* [[Електронний квиток]]
* [[QR-код]]
* [[Платіжні системи]]
* [[WayForPay]]
* [[LiqPay]]
* [[Stripe]]
* [[Афіша]]
* [[CRM]]
* [[Звітність]]

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

Журнал квитків показує всі місця, згенеровані для конкретної події.; характеристика
!;</div>
|-
| Що потрібно створити?; * які події заплановані;
* скільки місць доступно;
* які місця заброньовані;
* які місця продані;
* які бронювання скоро закінчаться;
* скільки коштів отримано;
* яка заповненість залу;
* які події продаються найкраще.; | Квиток на конкретну подію, ряд і місце
|-
| Які статуси потрібні?; * вести довідник залів;
* налаштовувати місткість залу;
* створювати схему місць;
* створювати вистави, концерти та інші заходи;
* публікувати афішу подій;
* автономно генерувати квитки для заходу;
* показувати статус кожного місця;
* бронювати квитки онлайн;
* обмежувати час дії бронювання;
* приймати онлайн-оплату;
* переводити квиток у статус проданого після оплати;
* формувати електронний квиток у PDF;
* додавати QR-код для перевірки квитка;
* надсилати підтвердження на email;
* скасовувати бронювання;
* контролювати заповненість залу;
* формувати звіти по продажах, бронюваннях і відвідуваності.;== Статуси квитка ==

</div>

!; # Платіжна платформа повертає результат.; Максимальна оцінка
== QR-код квитка ==
{| class="wikitable" style="width:100%;"
|-
| Бекенд
| K2 Cloud ERP на Python або PHP
|-
| База даних
| PostgreSQL або MySQL
|-
| Фронтенд
| HTML5, JavaScript
|-
| AJAX
| Axios або Fetch API
|-
| UI-компоненти
| DataTables, Select2
|-
| Схема залу
| SVG або Canvas, опціонально
|-
| Платежі
| WayForPay, LiqPay, Stripe або інший шлюз
|-
| Друк
| PDF-квитки з QR-кодами
|-
| Email
| Відправка підтверджень і квитків покупцям
|}

== Афіша подій ==

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

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

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

!; # користувач системи вибирає одне або кілька місць.;== Звіт «продажі та реалізація квитків» ==
!; Питання
== Жанри подій ==

Купівля квитка має змогу відбуватися одразу або після бронювання.; # платформа створює бронювання.; Призначення

Звіт показує, скільки місць доступно, заброньовано і продано.; # Якщо оплата успішна, квитки переходять у статус '''«Продане»'''.; Після завершення строку платформа повинна:

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

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

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

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

* створювати зали;
* налаштовувати схеми місць;
* створювати події;
* відкривати або закривати продаж;
* переглядати бронювання;
* переглядати продані квитки;
* скасовувати бронювання;
* блокувати окремі місця;
* змінювати ціни;
* переглядати продажі та реалізація в реальному часі;
* формувати звіти.; При скануванні QR-коду платформа повинна показати:
!; * чи існує квиток;
* чи належить він до цієї події;
* чи оплачений він;
* чи не був уже використаний;
* ряд і місце;
* статус перевірки.; # Покупець отримує PDF-квитки на email.; Роль
|-
| Номер платежу
| Унікальний номер платежу
|-
| Бронювання або замовлення
| До чого належить оплата
|-
| Сума
| Сума платежу
|-
| Валюта
| Валюта оплати
|-
| Платіжна платформа
| WayForPay, LiqPay, Stripe або інша
|-
| Статус платежу
| Очікує, успішний, відхилений, повернений
|-
| Дата платежу
| Коли виконано оплату
|-
| Технічний ідентифікатор
| ID транзакції з платіжної системи
|}

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

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

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

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

* номер квитка;
* назву події;
* дату і час;
* зал;
* сектор;
* ряд;
* місце;
* ПІБ покупця;
* ціну;
* QR-код;
* правила відвідування, якщо потрібно.;<div style="border:2px solid #f57c00; background:#fff3e0; padding:14px; margin:16px 0;">

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

{| class="wikitable" style="width:100%;"
!; Поле

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

== Технічні вимоги ==
компонент має підтримувати розмежування прав.; Після створення події платформа повинна автономно створити квитки на основі схеми залу.; {| class="wikitable" style="width:100%;"

# користувач системи вибирає подію з афіші.; Інакше зал буде штучно заблокований неоплаченими бронюваннями.; * подію;
* зал;
* загальну кількість місць;
* вільні місця;
* заброньовані місця;
* продані місця;
* заблоковані місця;
* відсоток заповненості.; Він має бути пов’язаний із подією, залом, рядом, місцем, покупцем, оплатою, статусом і QR-кодом для перевірки на вході.; Журнал змін має зберігати:

== інформаційні дані електронного квитка ==

* перевіряти статус місця перед бронюванням;
* блокувати місце на час створення бронювання;
* використовувати транзакції на рівні бази даних;
* повторно перевіряти доступність перед оплатою;
* не дозволяти оплату вже зайнятого місця.; !;{{DISPLAYTITLE:Атестаційні завдання K2 ERP/Бронювання квитків на події}}

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

Розширена схема має змогу бути інтерактивною: SVG або Canvas із візуальним вибором місць.;<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
Максимум 5 квитків за одне бронювання
|-
| 90–100
| Відмінно
| компонент в цілому функціонує: зали, події, квитки, бронювання, оплата, PDF, QR-коди, звіти й AJAX реалізовані коректно
|-
| 75–89
| Добре
| Основна логіка функціонує, є собою незначні недоліки, які не руйнують бізнес-процес бронювання та продажу квитків
|-
| 60–74
| Зараховано
| Базовий сценарій функціонує, але частина функцій реалізована неповно або потребує доопрацювання
|-
| 0–59
| Не зараховано
| Відсутня критична логіка: події, квитки, бронювання, оплата, статуси місць або електронні квитки
|}

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

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

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

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

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

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

Коротко

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

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

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

|- | Реалізація журналу вистав і квитків | 20 | Зали, події, схема місць, генерація квитків, статуси місць |- | бізнес-процес бронювання і купівлі квитків | 20 | Вибір місць, бронювання, таймер, оплата, зміна статусів |- | Генерація електронних квитків | 20 | PDF-квиток, QR-код, email-відправка, перевірка квитка |- | формування звітів і обліковий облік заповненості залу | 20 | Заповненість, продажі та реалізація, бронювання, відвідуваність, доходи |- | Інтерактивність через AJAX і супровід платіжних систем | 20 | AJAX-вибір місць, перевірка доступності, інтеграційні функціональні можливості з WayForPay/LiqPay/Stripe |- Мета задача — створити в K2 ERP компонент для автоматизації бронювання та продажу квитків на культурні, освітні або розважальні події.;== Мета задача ==

!; Практичний сенс. QR-код захищає від повторного проходу за одним квитком і надає можливість оперативно перевіряти відвідувачів на вході.; компонент має надсилати email-повідомлення покупцю.; Критично. Якщо бронювання закінчилося і не було оплачено, місця мають автономно повернутися в продаж.; 100

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

центральний принцип. Квиток — це не без ускладнень запис у таблиці.;

Після успішного проходу квиток має змогу отримати статус «Використано».; # користувач системи отримує підтвердження на email.; * зали;

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

|- | Які довідники потрібні?; характеристика

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

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

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

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

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

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

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

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

; # користувач системи вибирає квитки.; # платформа перевіряє, чи місця ще вільні.; * змінити статус квитка;

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

формування звітів

Зали

Місця проведення подій

Схеми залів

Ряди, місця, сектори, зони

Події

Вистави, концерти, лекції, кіносеанси або інші заходи

Афіша

Публічний список доступних подій

Квитки

Місця на конкретну подію зі статусом і ціною

Бронювання

Тимчасове резервування квитків

Покупці

Користувачі, які бронюють або купують квитки

Оплати

Платежі через платіжні системи

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

PDF-документи з QR-кодом

QR-перевірка

Перевірка квитка на вході

Звіти

продажі та реалізація, бронювання, заповненість залу, доходи

Опціонально компонент має змогу підтримувати повернення проданого квитка.; {| class="wikitable" style="width:100%;"

WayForPay;
LiqPay;
Stripe;
інший платіжний сервіс.; # платформа відкриває схему залу або список доступних місць.; # платформа створює замовлення або бронювання.; Разом

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

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

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

; Параметр

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

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

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