Атестаційні завдання K2 ERP/Турфірма
У межах одного бронювання потрібно зберігати список туристів і документи кожного туриста. Бронювання має дозволяти додавати кількох туристів:
Розрахунок вартості бронювання
критично. Курс, використаний у бронюванні, має зберігатися. SEO-опис Через AJAX мають працювати:
Рекомендовані сутності бази даних
| BB | Сніданок |
| HB | Напівпансіон |
| FB | Повний пансіон |
| AI | Все включено |
| UAI | Ультра все включено |
Документи мають формуватися у форматах:
Туристичний ваучер
Критично. платформа повинна показувати реальний залишок до оплати. * додавання клієнта вручну;
- редагування даних клієнта;
- пошук за ПІБ;
- пошук за телефоном;
- пошук за email;
- перегляд усіх бронювань клієнта;
- зв’язок клієнта з кількома турами;
- зберігання паспортних даних для документів. Бали
Договір із клієнтом має містити:
компонент має забезпечувати повний цикл роботи туристичної фірми: від створення туру й заведення клієнта до бронювання, оплати, формування договору, ваучера, рахунку та контролю заборгованості перед виїздом. SEO-опис
- K2 ERP
- K2 ERP
- Атестаційні завдання K2 ERP
- Турфірма
- CRM
- Бронювання
- Рахунок на оплату
- Договір
- Ваучер
- Мультивалютність
- Клієнти
- Фінансовий облік
компонент керування турами, клієнтами та бронюваннями для туристичної фірми.== Типи харчування ==
Практичне задача
| Дата оплати | Коли отримано кошти |
| Бронювання | До якого бронювання належить оплата |
| Сума | Сума платежу |
| Валюта | Валюта платежу |
| Курс | Курс, якщо потрібен перерахунок |
| Спосіб оплати | Готівка, карта, банківський переказ або інший спосіб |
| Коментар | Додаткова інформаційні матеріали |
Мінімально потрібно підтримати:
! Об’єкт
У звіті потрібно відображати:
- клієнта;
- бронювання;
- тур;
- загальну вартість;
- внесені оплати;
- залишок до оплати;
- дату повної оплати;
- прострочення, якщо воно виступає як;
- менеджера. SEO-опис
Технічні вимоги
|}
! | Бронювання, оплати, борги, продажі та реалізація по менеджерах, популярність турів |- | Що виступає як критичною вимогою? {| class="wikitable" style="width:100%;"
! !== Туристи в бронюванні ==
Що потрібно створити? Критерій
Довідник «Країни і міста»У звіті потрібно відображати: |
Роль
Поля країни |
|---|---|
| Країни і міста | Напрями подорожей |
| Готелі | Варіанти проживання в турах |
| Типи харчування | BB, HB, FB, AI та інші варіанти |
| Тури | Пакетні або індивідуальні туристичні пропозиції |
| Клієнти | Покупці турів |
| Туристи | Особи, які фактично їдуть у тур |
| Бронювання | базовий документ продажу туру |
| Оплати | Передоплати, часткові та повні оплати |
| Документи | Договір, ваучер, рахунок на оплату |
| Менеджери | Працівники, які ведуть клієнтів і бронювання |
| Курси валют | Курси для перерахунку вартості турів |
| Звіти | Бронювання, оплати, борги, продажі та реалізація, ефективність менеджерів |
!== Коротко == Для кожного туриста потрібно зберігати ПІБ, дату народження, паспортні інформаційні дані та примітки. Поле
компонент має підтримувати бронювання на кількох осіб. Поле
У результаті виконання атестаційного задача має бути створений компонент туристичної фірми в K2 ERP. SEO-опис
- членів родини;
- дітей;
- друзів;
- учасників групового туру.
Оплата здатна бути:
! Форма бронювання повинна дозволяти менеджеру оперативно оформити продаж туру. SEO-опис
Рахунок на оплату
Розрахунок залишку до оплати
Поля готелю
|- | Назва готелю | Офіційна або комерційна назва готелю |- | Країна | Країна розташування |- | Місто або курорт | Місто, курорт або регіон |- | Кількість зірок | Рейтинг готелю |- | Типи харчування | BB, HB, FB, AI або інші варіанти |- | SEO-опис | Короткий SEO-опис готелю |- | Статус | Активний або прихований |}
Документи мають формуватися автоматизовано на основі даних клієнта, туру та бронювання.== Формати документів == компонент має підтримувати розмежування прав. | Загальну вартість, передоплату, залишок до оплати |- | Які документи потрібні? Якщо оплати не впливають на баланс бронювання, менеджер не зможе контролювати борги клієнтів. !== Формування документів ==
! Максимальна оцінка Це потрібно для:
Договір із клієнтом
Якщо баланс до оплати дорівнює нулю, бронювання здатна переходити в статус «Оплачено». У звіті потрібно відображати:
Поля бронювання
Критерії оцінювання
- номер бронювання;
- дату;
- клієнта;
- тур;
- менеджера;
- кількість осіб;
- загальну суму;
- статус;
- суму оплат;
- баланс до оплати.
|- | Менеджер | Створює клієнтів, бронювання, оплати, документи по своїх клієнтах |- | Старший менеджер | Бачить бронювання кількох менеджерів, контролює борги та скасування |- | Бухгалтер | Перевіряє оплати, рахунки, заборгованість і фінансові звіти |- | Керівник | Переглядає всі бронювання, продажі та реалізація, ефективність менеджерів |- | Адміністратор | Налаштовує довідники, права, валюти, курси та шаблони документів |} == формування звітів == == Вимоги до мультивалютності == Звіт показує всі бронювання за вибраний період.== Групові та сімейні тури == компонент має дозволяти реєструвати оплати за бронювання.[[Категорія:Турфірма]] == Основні об’єкти модуля == {| class="wikitable" style="width:100%;" == Критичні помилки == <div style="border:2px solid #f57c00; background:#fff3e0; padding:14px; margin:16px 0;"> {| class="wikitable" style="width:100%;" компонент повинен фіксувати важливі зміни. SEO-опис == Журнал «Бронювання турів» ==
Журнал змін має зберігати: провідний принцип. Туристичний компонент — це не без зусиль список турів. Якщо курс у довіднику зміниться пізніше, старі бронювання не повинні неконтрольовано змінювати суму.== Нагадування про доплату ==
- передоплатою;
- частковою оплатою;
- повною оплатою;
- поверненням коштів при скасуванні бронювання. * вести довідник країн і міст;
- вести довідник готелів;
- вести довідник турів;
- вести клієнтів і туристів;
- створювати бронювання турів;
- розраховувати вартість туру за кількістю осіб;
- враховувати передоплати та повні оплати;
- контролювати залишок до оплати;
- формувати договір із клієнтом;
- формувати туристичний ваучер;
- формувати рахунок на оплату;
- підтримувати мультивалютність;
- перераховувати суми при зміні курсу;
- нагадувати менеджеру про необхідність доплати;
- формувати звіти по бронюваннях, оплатах, боргах і менеджерах. | Повний цикл: тур → бронювання → оплата → документи → звіт
|}
!== Реальний бізнес-контекст ==
Клієнти можуть купувати тур для себе, родини або групи людей. Колонка
|- | Номер бронювання | Унікальний номер документа |- | Дата бронювання | Коли створено бронювання |- | клієнт ERP | Покупець туру |- | Тур | Обраний тур |- | Кількість осіб | Кількість туристів у бронюванні |- | Загальна вартість | Повна вартість бронювання |- | Внесена передоплата | Сума, яку вже оплатив клієнт ERP |- | Баланс до оплати | Залишок, який потрібно доплатити |- | Менеджер | Відповідальний за бронювання |- | Статус | Заброньовано, частково оплачено, оплачено, відмінено |}
Права доступу
Функціональність журналу клієнтів
У ваучері потрібно показати: ! Рівень
- номер договору;
- дату;
- інформаційні дані клієнта;
- паспортні інформаційні дані;
- назву туру;
- країну та місто;
- готель;
- дати туру;
- кількість туристів;
- вартість;
- порядок оплати;
- реквізити сторін;
- підписи сторін. Для реалізації задачі доцільно передбачити такі сутності:
! Поле
! Призначення !== Статуси бронювання ==
- створити країну і місто;
- створити готель;
- створити типи харчування;
- створити тур із датами, готелем, ціною та валютою;
- створити клієнта;
- створити бронювання;
- додати кількох туристів;
- перевірити розрахунок загальної вартості;
- внести передоплату;
- перевірити залишок до оплати;
- внести повну оплату;
- перевірити зміну статусу бронювання;
- сформувати договір із клієнтом;
- сформувати туристичний ваучер;
- сформувати рахунок на оплату;
- перевірити мультивалютний перерахунок;
- створити нагадування про доплату;
- сформувати звіт бронювань;
- сформувати звіт оплат і боргів;
- сформувати звіт продажів по менеджерах. ! платформа повинна повідомляти менеджеру про наближення строку повної оплати. |-
| Назва країни | як приклад: Туреччина, Єгипет, Іспанія, Польща |- | Код країни | Короткий код або службове позначення |- | Активність | Чи доступна країна для створення турів |}
Після кожної оплати платформа повинна автоматизовано перераховувати баланс до оплати. Колонка
Звіт «Бронювання за період»
Мета задача
критично. Вартість туру має зберігатися разом із валютою. Питання
платформа повинна підтримувати:
- PDF;
- DOCX, якщо потрібне редагування перед підписанням. SEO-опис
Шкала оцінювання
! Окремо варто відзначити бронюваннями, оплатами, документами і фінансовою аналітикою туристичної компанії виступає ключовою рисою перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля керування турами забезпечується через Атестаційне задача K2 ERP. * країну;
- місто або курорт;
- тур;
- готель;
- кількість бронювань;
- кількість туристів;
- суму продажів. Ваучер має містити інформацію, потрібну для подорожі. Що перевіряється
Звіт показує ефективність менеджерів. |- | Назва міста | як приклад: Анталія, Хургада, Барселона |- | Країна | Країна, до якої належить місто |- | Активність | Чи застосовується для місто в поточних турах |}
Форма бронювання
Якщо тур у валюті, а оплата ведеться в гривні:
! Один клієнт ERP здатна мати кілька бронювань у різний час, а одне бронювання здатна включати кількох туристів. ! | Країни, міста, готелі, типи харчування, тури, клієнти |- | Який провідний документ? !== Журнал «Клієнти» == Журнал клієнтів містить людей, які звернулися до туристичної компанії або придбали тур. Коротко. Потрібно реалізувати компонент для турфірми: країни, міста, готелі, тури, клієнти, бронювання, оплати, борги, договори, ваучери, рахунки, мультивалютність, нагадування менеджерам і звіти по бронюваннях, оплатах та менеджерах. ! ! 100
обліковий облік оплат
| Реалізація довідників турів, готелів і клієнтів | 20 | Країни, міста, готелі, харчування, тури, клієнти, туристи | |
| Бронювання турів і обліковий облік оплат | 20 | Створення бронювання, розрахунок вартості, передоплата, повна оплата, борг | |
| Генерація документів | 20 | Договір, ваучер, рахунок на оплату у PDF або DOCX | |
| Мультивалютність і перерахунок сум | 20 | UAH, USD, EUR, курси, фіксація курсу в бронюванні, перерахунок | |
| Інтерактивність через AJAX | 10 | Вибір туру, розрахунки, оплати, статуси й документи без перезавантаження | |
| Звіти по бронюваннях і оплатах | 10 | Бронювання, оплати, борги, продажі та реалізація по менеджерах | |
class="wikitable" style="width:100%;"
Колонки журналу клієнтівМенеджеру потрібно оперативно підібрати тур, оформити бронювання, зафіксувати передоплату, бачити залишок до оплати, сформувати договір, ваучер і рахунок. Параметр Звіт «продажі та реалізація по менеджерах»Рахунок на оплату має містити:
Звіт показує, які напрями та тури продаються найкраще. SEO-опис
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
# адміністратор створює країни, міста, готелі та тури;
# менеджер додає нового клієнта;
# клієнт ERP обирає тур;
# менеджер створює бронювання;
# платформа розраховує загальну вартість за кількістю осіб;
# клієнт ERP вносить передоплату або повну оплату;
# платформа показує залишок до оплати;
# автоматизовано формується договір із клієнтом;
# формується туристичний ваучер;
# формується рахунок на оплату;
# менеджер контролює доплату перед датою виїзду;
# після повної оплати бронювання переходить у відповідний статус;
# інформаційні дані потрапляють у звіти по продажах, оплатах і менеджерах.== Поля міста ==
|-
| клієнт ERP
| Вибір із довідника або створення нового клієнта
|-
| Тур
| Вибір із довідника турів
|-
| Кількість осіб
| Скільки туристів їде
|-
| Туристи
| Список осіб, які їдуть у тур
|-
| Базова ціна за людину
| Підтягується з туру
|-
| Валюта
| Валюта туру або бронювання
|-
| Курс
| Курс для перерахунку
|-
| Загальна вартість
| Розраховується автоматизовано
|-
| Передоплата
| Сума першого платежу
|-
| Баланс до оплати
| Розраховується автоматизовано
|-
| Дата повної оплати
| Дата, до якої клієнт ERP має внести залишок
|-
| Менеджер
| Відповідальний менеджер
|-
| Коментар
| Додаткова інформаційні матеріали
|}
Інтерфейс модуля має працювати оперативно та інтуїтивно для менеджера. Це ланцюжок: тур → клієнт ERP → бронювання → оплата → документи → контроль доплати → виїзд → фінансова аналітичні інструменти. ! ! Разом
! Поле
! ! {| class="wikitable" style="width:100%;"
== Звіт «Оплати і заборгованість» ==
[[Категорія:Туризм]]
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
клієнт ERP, який оплачує тур, не завжди виступає як єдиним туристом.<pre>
!<div style="border:2px solid #f57c00; background:#fff3e0; padding:14px; margin:16px 0;">
Типовий бізнес-процес роботи туристичної фірми виглядає так:
!== Мультивалютність ==
[[Категорія:Фінансовий облік]]
{| class="wikitable" style="width:100%;"
! функції ERP
Загальна вартість = Базова вартість за людину × Кількість осіб
У звіті потрібно бачити:
* бронювання не оплачене на 100%;
* дата повної оплати наближається;
* до виїзду залишилось мало часу;
* виступає як прострочена заборгованість. Статус
! Відповідь
Туристичний бізнес-середовище часто функціонує з кількома валютами. {| class="wikitable" style="width:100%;"
== Колонки журналу бронювань ==
[[Категорія:Корпоративна Wiki]]
* UAH;
* USD;
* EUR. Такий функції ERP дає можливість цифровізувати бізнес-процес продажу, підготовку документів, контроль оплат і якість обслуговування клієнтів. SEO-опис
== Поля оплати ==
== Див. так само ==
* менеджера;
* кількість бронювань;
* кількість туристів;
* суму продажів;
* суму оплат;
* суму боргу;
* кількість скасованих бронювань. SEO-опис
</div>
[[Категорія:K2 ERP]]
Туристична компанія-користувач продає пакетні та індивідуальні тури через менеджерів. ! Поле
Логування змінПоля туру |
Поле
|
ПІБ | Прізвище, ім’я та по батькові клієнта |
|---|---|---|---|
| Дата народження | Дата народження клієнта | ||
| Паспортні інформаційні дані | інформаційні дані паспорта або закордонного паспорта | ||
| Телефон | Контактний номер | ||
| Електронна адреса | |||
| Менеджер | Відповідальний менеджер | ||
| Кількість бронювань | Скільки турів оформлено на клієнта |
Довідник готелів містить варіанти проживання, які використовуються в турах. Тип |- | Чернетка | Бронювання створюється, але ще не підтверджене |- | Заброньовано | Тур заброньовано для клієнта |- | Частково оплачено | Внесено передоплату, але виступає як залишок до оплати |- | Оплачено | Бронювання оплачено на 100% |- | Документи видані | Договір, ваучер або інші документи сформовано і передано клієнту |- | Відмінено | Бронювання скасовано |}
Основна формула: Довідник турів містить туристичні пропозиції, які продає компанія-користувач. Бронювання — базовий документ продажу туру. Турфірма — це практична задача; так само реалізовано клієнтами. {| class="wikitable" style="width:100%;"- валюту туру;
- валюту оплати;
- курс валюти;
- перерахунок вартості туру в гривню;
- фіксацію курсу на момент бронювання;
- перерахунок при зміні курсу, якщо це дозволено правилами;
- звіти у валюті туру та в базовій валюті. Бали
AJAX-інтерактив
| == Назва задача == | |
|---|---|
| Бекенд | K2 Cloud ERP на Python або PHP |
| База даних | PostgreSQL або MySQL |
| Фронтенд | HTML5, JavaScript |
| AJAX | Fetch API або Axios |
| UI-компоненти | DataTables, Select2 |
| Друк | PDF-документи: договори, ваучери, рахунки |
| Документи | PDF та DOCX, якщо потрібно редагування |
платформа повинна дозволяти:
- країни;
- міста;
- готелі;
- типи харчування;
- тури;
- клієнти;
- туристи;
- бронювання;
- рядки туристів у бронюванні;
- оплати;
- валюти;
- курси валют;
- договори;
- ваучери;
- рахунки на оплату;
- менеджери;
- нагадування;
- журнал змін;
- шаблони документів;
- звіти. Журнал клієнтів має підтримувати:
- неможливо створити тур;
- неможливо створити клієнта;
- неможливо створити бронювання;
- кількість осіб не впливає на загальну вартість;
- оплата не зменшує баланс до оплати;
- бронювання не показує реальний борг;
- повна оплата не змінює статус бронювання;
- договір не формується з даними клієнта і туру;
- ваучер не містить даних готелю, трансферу або перевезення;
- рахунок на оплату не містить деталізації вартості;
- курс валюти не фіксується в бронюванні;
- старі бронювання змінюють суму через зміну курсу без контролю;
- менеджер не бачить наближення строку доплати;
- звіти не відповідають бронюванням і оплатам;
- зміни бронювання або оплат не логуються. | Договір із клієнтом, туристичний ваучер, рахунок на оплату
Що має підтримувати мультивалютність?== Очікуваний результат ==
У межах атестації потрібно продемонструвати робочий сценарій. ! Керівнику потрібно бачити продажі та реалізація, борги, ефективність менеджерів і фінансову картину по турах. Туристичний компонент виступає як критичним для агенцій, які займаються продажем пакетних турів, індивідуальних подорожей, групових поїздок, бронюванням готелів і супровідних послуг. ! Значення Довідник «Готелі»
| |||
| Які довідники потрібні?== базовий бізнес-процес ==
Баланс до оплати = Загальна вартість - Сума оплат Довідник «Тури»Сума UAH = Сума у валюті × Курс Мінімальний сценарій: Звіт «Популярність турів»Мета задача — створити в K2 ERP компонент для автоматизації роботи туристичної компанії. | UAH, USD, EUR, курси та перерахунок вартості | |||
| class="wikitable" style="width:100%;"
Нагадування має спрацьовувати, якщо:
| |||
| - | 90–100 | Відмінно | компонент на 100% функціонує: тури, клієнти, бронювання, оплати, документи, мультивалютність, нагадування і звіти реалізовані коректно |
| 75–89 | Добре | Основна логіка функціонує, виступає як незначні недоліки, які не руйнують бізнес-процес продажу туру | |
| 60–74 | Зараховано | Базовий сценарій функціонує, але частина функцій реалізована неповно або потребує доопрацювання | |
| 0–59 | Не зараховано | Відсутня критична логіка: тури, бронювання, оплати, документи, валюти або звіти |
компонент має підтримувати країни, міста, готелі, типи харчування, тури, клієнтів, туристів, бронювання, оплати, мультивалютність, договори, туристичні ваучери, рахунки на оплату, нагадування про доплату, звіти по бронюваннях, оплатах, боргах і менеджерах. ! {| class="wikitable" style="width:100%;"
- хто створив бронювання;
- хто змінив тур;
- хто змінив кількість осіб;
- хто додав оплату;
- хто змінив статус;
- хто сформував договір;
- хто скасував бронювання;
- дату й час зміни;
- старе та нове значення, якщо це можливо.
|- | Назва туру | Комерційна назва туру |- | Тип туру | Пакетний або індивідуальний |- | Країна | Країна подорожі |- | Місто або курорт | Місце відпочинку |- | Готель | Готель із довідника |- | Дата початку | Початок туру |- | Дата завершення | Кінець туру |- | Кількість ночей | Розраховується або вводиться вручну |- | Тип харчування | BB, HB, AI тощо |- | Базова вартість за людину | Ціна за одного туриста |- | Валюта туру | UAH, USD, EUR або інша валюта |- | SEO-опис програми туру | Детальний SEO-опис туру |- | Статус | Активний, архівний, призупинений |}
Примітка
Звіт показує фінансовий стан бронювань. Критичними помилками вважаються ситуації, коли: Повідомлення здатна бути внутрішнім, email або іншим способом, який застосовується для в K2 ERP.