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

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

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

У межах одного бронювання потрібно зберігати список туристів і документи кожного туриста. Бронювання має дозволяти додавати кількох туристів:

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

критично. Курс, використаний у бронюванні, має зберігатися. SEO-опис Через AJAX мають працювати:

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

BB Сніданок
HB Напівпансіон
FB Повний пансіон
AI Все включено
UAI Ультра все включено

Документи мають формуватися у форматах:

Туристичний ваучер

Критично. платформа повинна показувати реальний залишок до оплати. * додавання клієнта вручну;

  • редагування даних клієнта;
  • пошук за ПІБ;
  • пошук за телефоном;
  • пошук за email;
  • перегляд усіх бронювань клієнта;
  • зв’язок клієнта з кількома турами;
  • зберігання паспортних даних для документів. Бали

Договір із клієнтом має містити:


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

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

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

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

Мінімально потрібно підтримати:

! Об’єкт

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

  • клієнта;
  • бронювання;
  • тур;
  • загальну вартість;
  • внесені оплати;
  • залишок до оплати;
  • дату повної оплати;
  • прострочення, якщо воно виступає як;
  • менеджера. 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 |- | Баланс до оплати | Залишок, який потрібно доплатити |- | Менеджер | Відповідальний за бронювання |- | Статус | Заброньовано, частково оплачено, оплачено, відмінено |}

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

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

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

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

! Поле

! Призначення !== Статуси бронювання ==

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

| Назва країни | як приклад: Туреччина, Єгипет, Іспанія, Польща |- | Код країни | Короткий код або службове позначення |- | Активність | Чи доступна країна для створення турів |}

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

Звіт «Бронювання за період»

Мета задача

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

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

  • 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]]
Туристична компанія-користувач продає пакетні та індивідуальні тури через менеджерів. ! Поле

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

Поля туру

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

Довідник готелів містить варіанти проживання, які використовуються в турах. Тип |- | Чернетка | Бронювання створюється, але ще не підтверджене |- | Заброньовано | Тур заброньовано для клієнта |- | Частково оплачено | Внесено передоплату, але виступає як залишок до оплати |- | Оплачено | Бронювання оплачено на 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, якщо потрібно редагування

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

  • країни;
  • міста;
  • готелі;
  • типи харчування;
  • тури;
  • клієнти;
  • туристи;
  • бронювання;
  • рядки туристів у бронюванні;
  • оплати;
  • валюти;
  • курси валют;
  • договори;
  • ваучери;
  • рахунки на оплату;
  • менеджери;
  • нагадування;
  • журнал змін;
  • шаблони документів;
  • звіти. Журнал клієнтів має підтримувати:
  • неможливо створити тур;
  • неможливо створити клієнта;
  • неможливо створити бронювання;
  • кількість осіб не впливає на загальну вартість;
  • оплата не зменшує баланс до оплати;
  • бронювання не показує реальний борг;
  • повна оплата не змінює статус бронювання;
  • договір не формується з даними клієнта і туру;
  • ваучер не містить даних готелю, трансферу або перевезення;
  • рахунок на оплату не містить деталізації вартості;
  • курс валюти не фіксується в бронюванні;
  • старі бронювання змінюють суму через зміну курсу без контролю;
  • менеджер не бачить наближення строку доплати;
  • звіти не відповідають бронюванням і оплатам;
  • зміни бронювання або оплат не логуються. | Договір із клієнтом, туристичний ваучер, рахунок на оплату
Що має підтримувати мультивалютність?== Очікуваний результат ==
  • номер рахунку;
  • дату;
  • клієнта;
  • бронювання;
  • тур;
  • кількість осіб;
  • деталізацію вартості;
  • суму до оплати;
  • валюту;
  • реквізити для оплати;
  • коментар щодо строку оплати. Умова складання. задача не здатна бути зараховане, якщо платформа не дає можливість пройти базовий цикл туристичної фірми: тур → клієнт ERP → бронювання → оплата → залишок до оплати → договір → ваучер → звіт. Значення

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

Довідник «Готелі»

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

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

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

Сума UAH = Сума у валюті × Курс

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

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

Мета задача — створити в K2 ERP компонент для автоматизації роботи туристичної компанії. | UAH, USD, EUR, курси та перерахунок вартості

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

Нагадування має спрацьовувати, якщо:

  • створення клієнта;
  • вибір туру;
  • підтягування ціни туру;
  • розрахунок загальної вартості;
  • додавання туристів у бронювання;
  • реєстрація оплати;
  • перерахунок залишку до оплати;
  • зміна статусу бронювання;
  • формування документів;
  • фільтрація журналів. Якщо ціна задана в USD або EUR, платформа повинна коректно перераховувати суму в гривню за курсом, який діє для бронювання. Довідник країн і міст застосовують, коли потрібно для структурування туристичних напрямів. | Бронювання туру
- 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.