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

Атестаційні завдання K2 ERP/Турфірма

Матеріал з K2 ERP Wiki

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

Поля готелю

; !; Бали ; * країни;
  • міста;
  • готелі;
  • типи харчування;
  • тури;
  • клієнти;
  • туристи;
  • бронювання;
  • рядки туристів у бронюванні;
  • оплати;
  • валюти;
  • курси валют;
  • договори;
  • ваучери;
  • рахунки на оплату;
  • менеджери;
  • нагадування;
  • журнал змін;
  • шаблони документів;
  • звіти.;== Коротко ==

Розрахунок вартості бронювання

Назва готелю Офіційна або комерційна назва готелю
Країна Країна розташування
Місто або курорт Місто, курорт або регіон
Кількість зірок Рейтинг готелю
Типи харчування BB, HB, FB, AI або інші варіанти
характеристика Короткий характеристика готелю
Статус Активний або прихований

Поля міста

Якщо баланс до оплати дорівнює нулю, бронювання має змогу переходити в статус «Оплачено».;

компонент має дозволяти реєструвати оплати за бронювання.; характеристика

Основна формула:

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

Загальна вартість = Базова вартість за людину × Кількість осіб

Поля оплати

; Значення

Назва задача

компонент має підтримувати бронювання на кількох осіб.; !;== Поля країни ==
  • UAH;
  • USD;
  • EUR.; функціональні можливості
Довідник готелів містить варіанти проживання, які використовуються в турах.; | Країни, міста, готелі, типи харчування, тури, клієнти
Який центральний документ?; Керівнику потрібно бачити продажі та реалізація, борги, ефективність менеджерів і фінансову картину по турах.; Поле

Довідник «Тури»

  • валюту туру;
  • валюту оплати;
  • курс валюти;
  • перерахунок вартості туру в гривню;
  • фіксацію курсу на момент бронювання;
  • перерахунок при зміні курсу, якщо це дозволено правилами;
  • звіти у валюті туру та в базовій валюті.; Турфірма — це практична задача; додатково реалізовано клієнтами.; | Договір із клієнтом, туристичний ваучер, рахунок на оплату
- BB Сніданок
HB Напівпансіон
FB Повний пансіон
AI Все включено
UAI Ультра все включено
; характеристика компонент повинен фіксувати важливі зміни.;

Ваучер має містити інформацію, потрібну для подорожі.; !; характеристика
== Критичні помилки ==
<pre>
|-
| Назва країни
| як ілюстрація: Туреччина, Єгипет, Іспанія, Польща
|-
| Код країни
| Короткий код або службове позначення
|-
| Активність
| Чи доступна країна для створення турів
|}

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

У звіті потрібно відображати:
== Розрахунок залишку до оплати ==
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
|-
| Назва міста
| як ілюстрація: Анталія, Хургада, Барселона
|-
| Країна
| Країна, до якої належить місто
|-
| Активність
| Чи застосовується місто в поточних турах
|}

== Звіт «Оплати і заборгованість» ==

!; !; '''Критично.''' платформа повинна показувати реальний залишок до оплати.; характеристика

* членів родини;
* дітей;
* друзів;
* учасників групового туру.; Поле

; Поле

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

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

!;

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

Поля туру

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

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

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

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

Якщо тур у валюті, а оплата ведеться в гривні:

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

!; !; Значення

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

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

Умова складання. задача не має змогу бути зараховане, якщо платформа не надає можливість пройти базовий цикл туристичної фірми: тур → замовник → бронювання → оплата → залишок до оплати → договір → ваучер → звіт.;== Довідник «Готелі» ==

компонент має підтримувати розмежування прав.; Менеджеру потрібно оперативно підібрати тур, оформити бронювання, зафіксувати передоплату, бачити залишок до оплати, сформувати договір, ваучер і рахунок.; * номер рахунку;

  • дату;
  • клієнта;
  • бронювання;
  • тур;
  • кількість осіб;
  • деталізацію вартості;
  • суму до оплати;
  • валюту;
  • реквізити для оплати;
  • коментар щодо строку оплати.;== Вимоги до мультивалютності ==
  1. адміністратор створює країни, міста, готелі та тури;
  2. менеджер додає нового клієнта;
  3. замовник обирає тур;
  4. менеджер створює бронювання;
  5. платформа розраховує загальну вартість за кількістю осіб;
  6. замовник вносить передоплату або повну оплату;
  7. платформа показує залишок до оплати;
  8. автономно формується договір із клієнтом;
  9. формується туристичний ваучер;
  10. формується рахунок на оплату;
  11. менеджер контролює доплату перед датою виїзду;
  12. після повної оплати бронювання переходить у відповідний статус;
  13. інформаційні дані потрапляють у звіти по продажах, оплатах і менеджерах.; У звіті потрібно бачити:

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

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

Після кожної оплати платформа повинна автономно перераховувати баланс до оплати.; Договір із клієнтом має містити:

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

Мінімально потрібно підтримати: !; {| class="wikitable" style="width:100%;" !; Питання

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

|- | Які документи потрібні?; Журнал клієнтів має підтримувати:

!; !;

|- | Країни і міста | Напрями подорожей |- | Готелі | Варіанти проживання в турах |- | Типи харчування | BB, HB, FB, AI та інші варіанти |- | Тури | Пакетні або індивідуальні туристичні пропозиції |- | Клієнти | Покупці турів |- | Туристи | Особи, які фактично їдуть у тур |- | Бронювання | ключовий документ продажу туру |- | Оплати | Передоплати, часткові та повні оплати |- | Документи | Договір, ваучер, рахунок на оплату |- | Менеджери | Працівники, які ведуть клієнтів і бронювання |- | Курси валют | Курси для перерахунку вартості турів |- | Звіти | Бронювання, оплати, борги, продажі та реалізація, ефективність менеджерів |}

Журнал «Бронювання турів»

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

компонент керування турами, клієнтами та бронюваннями
Які довідники потрібні?;== Журнал «Клієнти» ==

Звіт показує, які напрями та тури продаються найкраще.; Параметр

  • PDF;
  • DOCX, якщо потрібне редагування перед підписанням.; Для кожного туриста потрібно зберігати ПІБ, дату народження, паспортні інформаційні дані та примітки.; Якщо оплати не впливають на баланс бронювання, менеджер не зможе контролювати борги клієнтів.;== ключовий бізнес-процес ==
Бронювання, оплати, борги, продажі та реалізація по менеджерах, популярність турів
Що є собою критичною вимогою?; * неможливо створити тур;
  • неможливо створити клієнта;
  • неможливо створити бронювання;
  • кількість осіб не впливає на загальну вартість;
  • оплата не зменшує баланс до оплати;
  • бронювання не показує реальний борг;
  • повна оплата не змінює статус бронювання;
  • договір не формується з даними клієнта і туру;
  • ваучер не містить даних готелю, трансферу або перевезення;
  • рахунок на оплату не містить деталізації вартості;
  • курс валюти не фіксується в бронюванні;
  • старі бронювання змінюють суму через зміну курсу без контролю;
  • менеджер не бачить наближення строку доплати;
  • звіти не відповідають бронюванням і оплатам;
  • зміни бронювання або оплат не логуються.; | UAH, USD, EUR, курси та перерахунок вартості
Які звіти потрібні?; характеристика

Довідник країн і міст застосовують, коли потрібно для структурування туристичних напрямів.; * хто створив бронювання;

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

Туристи в бронюванні

Нагадування про доплату

  • країну;
  • місто або курорт;
  • тур;
  • готель;
  • кількість бронювань;
  • кількість туристів;
  • суму продажів.;== Примітка ==

Звіт показує ефективність менеджерів.; !; Максимальна оцінка

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

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

Рахунок на оплату

У ваучері потрібно показати:

Бекенд K2 Cloud ERP на Python або PHP
База даних PostgreSQL або MySQL
Фронтенд HTML5, JavaScript
AJAX Fetch API або Axios
UI-компоненти DataTables, Select2
Друк PDF-документи: договори, ваучери, рахунки
Документи PDF та DOCX, якщо потрібно редагування

Форма бронювання

Інтерфейс модуля має працювати оперативно та комфортно для менеджера.; характеристика

!; * номер договору;

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

!; Звіт показує всі бронювання за вибраний період.; Роль

Мета задача — створити в K2 ERP компонент для автоматизації роботи туристичної компанії.; Тип

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

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

Журнал змін має зберігати: |- | Реалізація довідників турів, готелів і клієнтів | 20 | Країни, міста, готелі, харчування, тури, клієнти, туристи |- | Бронювання турів і обліковий облік оплат | 20 | Створення бронювання, розрахунок вартості, передоплата, повна оплата, борг |- | Генерація документів | 20 | Договір, ваучер, рахунок на оплату у PDF або DOCX |- | Мультивалютність і перерахунок сум | 20 | UAH, USD, EUR, курси, фіксація курсу в бронюванні, перерахунок |- | Інтерактивність через AJAX | 10 | Вибір туру, розрахунки, оплати, статуси й документи без перезавантаження |- | Звіти по бронюваннях і оплатах | 10 | Бронювання, оплати, борги, продажі та реалізація по менеджерах |- Повідомлення має змогу бути внутрішнім, email або іншим способом, який застосовується в K2 ERP.; Бали

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

| Що потрібно створити?; !;== Групові та сімейні тури == Коротко. Потрібно реалізувати компонент для турфірми: країни, міста, готелі, тури, клієнти, бронювання, оплати, борги, договори, ваучери, рахунки, мультивалютність, нагадування менеджерам і звіти по бронюваннях, оплатах та менеджерах.;

!; Колонка

Бронювання — ключовий документ продажу туру.; характеристика Довідник турів містить туристичні пропозиції, які продає організація.; Що перевіряється |- | Назва туру | Комерційна назва туру |- | Тип туру | Пакетний або індивідуальний |- | Країна | Країна подорожі |- | Місто або курорт | Місце відпочинку |- | Готель | Готель із довідника |- | Дата початку | Початок туру |- | Дата завершення | Кінець туру |- | Кількість ночей | Розраховується або вводиться вручну |- | Тип харчування | BB, HB, AI тощо |- | Базова вартість за людину | Ціна за одного туриста |- | Валюта туру | UAH, USD, EUR або інша валюта |- | характеристика програми туру | Детальний характеристика туру |- | Статус | Активний, архівний, призупинений |}

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

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

компонент має забезпечувати повний цикл роботи туристичної фірми: від створення туру й заведення клієнта до бронювання, оплати, формування договору, ваучера, рахунку та контролю заборгованості перед виїздом.; Колонка |- | Дата оплати | Коли отримано кошти |- | Бронювання | До якого бронювання належить оплата |- | Сума | Сума платежу |- | Валюта | Валюта платежу |- | Курс | Курс, якщо потрібен перерахунок |- | Спосіб оплати | Готівка, карта, банківський переказ або інший спосіб |- | Коментар | Додаткова відомості |}

Звіт показує фінансовий стан бронювань.;== Звіт «Бронювання за період» == |- | Чернетка | Бронювання створюється, але ще не підтверджене |- | Заброньовано | Тур заброньовано для клієнта |- | Частково оплачено | Внесено передоплату, але є собою залишок до оплати |- | Оплачено | Бронювання оплачено в цілому |- | Документи видані | Договір, ваучер або інші документи сформовано і передано клієнту |- | Відмінено | Бронювання скасовано |}

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

Типи харчування

Оплата має змогу бути:

замовник Вибір із довідника або створення нового клієнта
Тур Вибір із довідника турів
Кількість осіб Скільки туристів їде
Туристи Список осіб, які їдуть у тур
Базова ціна за людину Підтягується з туру
Валюта Валюта туру або бронювання
Курс Курс для перерахунку
Загальна вартість Розраховується автономно
Передоплата Сума першого платежу
Баланс до оплати Розраховується автономно
Дата повної оплати Дата, до якої замовник має внести залишок
Менеджер Відповідальний менеджер
Коментар Додаткова відомості
У звіті потрібно відображати:

Звіт «Популярність турів»

Бронювання туру
class="wikitable" style="width:100%;"

Див.; додатково

  1. створити країну і місто;
  2. створити готель;
  3. створити типи харчування;
  4. створити тур із датами, готелем, ціною та валютою;
  5. створити клієнта;
  6. створити бронювання;
  7. додати кількох туристів;
  8. перевірити розрахунок загальної вартості;
  9. внести передоплату;
  10. перевірити залишок до оплати;
  11. внести повну оплату;
  12. перевірити зміну статусу бронювання;
  13. сформувати договір із клієнтом;
  14. сформувати туристичний ваучер;
  15. сформувати рахунок на оплату;
  16. перевірити мультивалютний перерахунок;
  17. створити нагадування про доплату;
  18. сформувати звіт бронювань;
  19. сформувати звіт оплат і боргів;
  20. сформувати звіт продажів по менеджерах.; !; !;== Туристичний ваучер ==

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

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

істотно. Курс, використаний у бронюванні, має зберігатися.;== Практичне задача ==

істотно. Вартість туру має зберігатися разом із валютою.; Поле

  • додавання клієнта вручну;
  • редагування даних клієнта;
  • пошук за ПІБ;
  • пошук за телефоном;
  • пошук за email;
  • перегляд усіх бронювань клієнта;
  • зв’язок клієнта з кількома турами;
  • зберігання паспортних даних для документів.; Якщо ціна задана в USD або EUR, платформа повинна коректно перераховувати суму в гривню за курсом, який діє для бронювання.; центральний принцип. Туристичний компонент — це не без ускладнень список турів.;== Довідник «Країни і міста» ==
; 100

Формати документів

Колонки журналу бронювань

; Поле

Мультивалютність

Функціональність журналу клієнтів

компонент керування турами, клієнтами та бронюваннями для туристичної фірми.; характеристика

; Якщо курс у довіднику зміниться пізніше, старі бронювання не повинні неконтрольовано змінювати суму.; Бронювання має дозволяти додавати кількох туристів:

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

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

Баланс до оплати = Загальна вартість - Сума оплат

платформа повинна підтримувати:

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

обліковий облік оплат

Це потрібно для:

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

Документи мають формуватися автономно на основі даних клієнта, туру та бронювання.;
  • передоплатою;
  • частковою оплатою;
  • повною оплатою;
  • поверненням коштів при скасуванні бронювання.; !; !; Документи мають формуватися у форматах:

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

  • бронювання не оплачене в цілому;
  • дата повної оплати наближається;
  • до виїзду залишилось мало часу;
  • є собою прострочена заборгованість.;== Договір із клієнтом ==
  • номер бронювання;
  • дату;
  • клієнта;
  • тур;
  • менеджера;
  • кількість осіб;
  • загальну суму;
  • статус;
  • суму оплат;
  • баланс до оплати.; |-
ПІБ Прізвище, ім’я та по батькові клієнта
Дата народження Дата народження клієнта
Паспортні інформаційні дані інформаційні дані паспорта або закордонного паспорта
Телефон Контактний номер
Email Електронна адреса
Менеджер Відповідальний менеджер
Кількість бронювань Скільки турів оформлено на клієнта
; Об’єкт

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

У результаті виконання атестаційного задача має бути створений компонент туристичної фірми в K2 ERP.; Сума UAH = Сума у валюті × Курс Рахунок на оплату має містити:

== Формування документів ==