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

Атестаційне завдання K2 ERP — Турфірма — це практична задача для перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля управління турами, клієнтами, бронюваннями, оплатами, документами та фінансовою аналітикою туристичної компанії.

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

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

Назва завдання

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

Мета завдання

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

Система повинна дозволяти:

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

Головний принцип. Туристичний модуль — це не просто список турів. Це ланцюжок: тур → клієнт → бронювання → оплата → документи → контроль доплати → виїзд → фінансова аналітика.

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

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

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

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

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

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

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

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

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

Довідник «Країни і міста»

Довідник країн і міст використовується для структурування туристичних напрямів.

Поля країни

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

Поля міста

Поле	Опис
Назва міста	Наприклад: Анталія, Хургада, Барселона
Країна	Країна, до якої належить місто
Активність	Чи використовується місто в поточних турах

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

Довідник готелів містить варіанти проживання, які використовуються в турах.

Поля готелю

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

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

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

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

Довідник турів містить туристичні пропозиції, які продає компанія.

Поля туру

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

Важливо. Вартість туру має зберігатися разом із валютою. Якщо ціна задана в USD або EUR, система повинна коректно перераховувати суму в гривню за курсом, який діє для бронювання.

Журнал «Клієнти»

Журнал клієнтів містить людей, які звернулися до туристичної компанії або придбали тур.

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

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

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

Журнал клієнтів має підтримувати:

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

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

Клієнт, який оплачує тур, не завжди є єдиним туристом.

Бронювання має дозволяти додавати кількох туристів:

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

Для кожного туриста потрібно зберігати ПІБ, дату народження, паспортні дані та примітки.

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

Бронювання — основний документ продажу туру.

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

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

Статуси бронювання

Статус	Значення
Чернетка	Бронювання створюється, але ще не підтверджене
Заброньовано	Тур заброньовано для клієнта
Частково оплачено	Внесено передоплату, але є залишок до оплати
Оплачено	Бронювання оплачено повністю
Документи видані	Договір, ваучер або інші документи сформовано і передано клієнту
Відмінено	Бронювання скасовано

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

Форма бронювання повинна дозволяти менеджеру швидко оформити продаж туру.

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

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

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

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

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

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

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

Розрахунок залишку до оплати

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

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

Критично. Система повинна показувати реальний залишок до оплати. Якщо оплати не впливають на баланс бронювання, менеджер не зможе контролювати борги клієнтів.

Облік оплат

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

Оплата може бути:

• передоплатою;
• частковою оплатою;
• повною оплатою;
• поверненням коштів при скасуванні бронювання.

Поля оплати

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

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

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

Система повинна повідомляти менеджеру про наближення строку повної оплати.

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

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

Повідомлення може бути внутрішнім, email або іншим способом, який використовується в K2 ERP.

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

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

Договір із клієнтом

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

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

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

Ваучер має містити інформацію, потрібну для подорожі.

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

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

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

Рахунок на оплату має містити:

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

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

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

• PDF;
• DOCX, якщо потрібне редагування перед підписанням.

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

Туристичний бізнес часто працює з кількома валютами.

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

• UAH;
• USD;
• EUR.

Вимоги до мультивалютності

Система повинна підтримувати:

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

Важливо. Курс, використаний у бронюванні, має зберігатися. Якщо курс у довіднику зміниться пізніше, старі бронювання не повинні неконтрольовано змінювати суму.

Групові та сімейні тури

Модуль має підтримувати бронювання на кількох осіб.

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

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

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

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

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

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

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

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

Звіт показує фінансовий стан бронювань.

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

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

Звіт «Продажі по менеджерах»

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

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

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

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

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

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

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

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

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

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

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

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

Модуль повинен фіксувати важливі зміни.

Журнал змін має зберігати:

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

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

Модуль має підтримувати розмежування прав.

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

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

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

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

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

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

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

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

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

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

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

Критерій	Бали	Що перевіряється
Реалізація довідників турів, готелів і клієнтів	20	Країни, міста, готелі, харчування, тури, клієнти, туристи
Бронювання турів і облік оплат	20	Створення бронювання, розрахунок вартості, передоплата, повна оплата, борг
Генерація документів	20	Договір, ваучер, рахунок на оплату у PDF або DOCX
Мультивалютність і перерахунок сум	20	UAH, USD, EUR, курси, фіксація курсу в бронюванні, перерахунок
Інтерактивність через AJAX	10	Вибір туру, розрахунки, оплати, статуси й документи без перезавантаження
Звіти по бронюваннях і оплатах	10	Бронювання, оплати, борги, продажі по менеджерах
Разом	100	Максимальна оцінка

Шкала оцінювання

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

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

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

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

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

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

У результаті виконання атестаційного завдання має бути створений модуль туристичної фірми в K2 ERP.

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

Примітка

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

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

Коротко

Питання	Відповідь
Що потрібно створити?	Модуль управління турами, клієнтами та бронюваннями
Які довідники потрібні?	Країни, міста, готелі, типи харчування, тури, клієнти
Який головний документ?	Бронювання туру
Що має рахувати система?	Загальну вартість, передоплату, залишок до оплати
Які документи потрібні?	Договір із клієнтом, туристичний ваучер, рахунок на оплату
Що має підтримувати мультивалютність?	UAH, USD, EUR, курси та перерахунок вартості
Які звіти потрібні?	Бронювання, оплати, борги, продажі по менеджерах, популярність турів
Що є критичною вимогою?	Повний цикл: тур → бронювання → оплата → документи → звіт

Див. також

• K2 ERP
• K2 ERP
• Атестаційні завдання K2 ERP
• Турфірма
• CRM
• Бронювання
• Рахунок на оплату
• Договір
• Ваучер
• Мультивалютність
• Клієнти
• Фінансовий облік