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

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

Матеріал з K2 ERP Wiki
R (обговорення | внесок)
Бюрократи, Адміністратори інтерфейсу, Адміністратори
2367 редагувань
ВізуальнийВікірозмітка
Створена сторінка: = Модуль управління турами, клієнтами та бронюваннями для туристичної фірми = == Реальний бізнес-контекст == Туристична компанія організовує продаж турів: пакетних та індивідуальних — через менеджерів. Необхідно: * вести довідники турів, готелів, пер...
 
Немає опису редагування
 
Рядок 1: Рядок 1:
Необхідно:
</div>


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


* вибір туру із довідника;
{| class="wikitable" style="width:100%;"
* підрахунок загальної вартості залежно від кількості осіб;
== Розрахунок вартості бронювання ==
* реєстрація передоплати або повної оплати;
'''критично.''' Курс, використаний у бронюванні, має зберігатися. SEO-опис
* відображення залишку до оплати. Бали
Через AJAX мають працювати:
== Рекомендовані сутності бази даних ==
|-
| BB
| Сніданок
|-
| HB
| Напівпансіон
|-
| FB
| Повний пансіон
|-
| AI
| Все включено
|-
| UAI
| Ультра все включено
|}
 
Документи мають формуватися у форматах:
 
== Туристичний ваучер ==
 
'''Критично.''' платформа повинна показувати реальний залишок до оплати. * додавання клієнта вручну;
* редагування даних клієнта;
* пошук за ПІБ;
* пошук за телефоном;
* пошук за email;
* перегляд усіх бронювань клієнта;
* зв’язок клієнта з кількома турами;
* зберігання паспортних даних для документів. Бали
 
Договір із клієнтом має містити:
 
{{DISPLAYTITLE:Атестаційні завдання K2 ERP/Турфірма}}
компонент має забезпечувати повний цикл роботи туристичної фірми: від створення туру й заведення клієнта до бронювання, оплати, формування договору, ваучера, рахунку та контролю заборгованості перед виїздом. SEO-опис
 
* [[K2 Cloud ERP|K2 ERP]]
* [[K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Турфірма]]
* [[CRM]]
* [[Бронювання]]
* [[Рахунок на оплату]]
* [[Договір]]
* [[Ваучер]]
* [[Мультивалютність]]
* [[Клієнти]]
* [[Фінансовий облік]]
 
'''компонент керування турами, клієнтами та бронюваннями для туристичної фірми'''.== Типи харчування ==
{| class="wikitable" style="width:100%;"
== Практичне задача ==
|-
| Дата оплати
| Коли отримано кошти
|-
| Бронювання
| До якого бронювання належить оплата
|-
| Сума
| Сума платежу
|-
| Валюта
| Валюта платежу
|-
| Курс
| Курс, якщо потрібен перерахунок
|-
| Спосіб оплати
| Готівка, карта, банківський переказ або інший спосіб
|-
| Коментар
| Додаткова інформаційні матеріали
|}


інформаційні матеріали в рахунку:
Мінімально потрібно підтримати:


== Примітка ==
! Об’єкт


* ПІБ;
У звіті потрібно відображати:
* паспортні інформаційні інформаційні дані;
* дата народження;
* телефон;
* Email.==== Рахунок на оплату ====


* додавання нових клієнтів вручну;
* клієнта;
* зв’язок клієнтів із бронюваннями.== Реальний бізнес-контекст ==
* бронювання;
* тур;
* загальну вартість;
* внесені оплати;
* залишок до оплати;
* дату повної оплати;
* прострочення, якщо воно виступає як;
* менеджера. SEO-опис
== Технічні вимоги ==
|}


* робота через AJAX без перезавантаження сторінки;
! | Бронювання, оплати, борги, продажі та реалізація по менеджерах, популярність турів
* технічна технічна підтримка мультивалютності:
|-
** UAH;
| Що виступає як критичною вимогою? {| class="wikitable" style="width:100%;"
** USD;
** EUR;
* автоматичний перерахунок вартості туру при зміні курсу валюти;
* зв’язування клієнтів із кількома турами, як приклад:
** родина;
** групові тури;
* повідомлення менеджерам про наближення строку повної оплати.==== Формати документів ====


Поля довідника:
! !== Туристи в бронюванні ==
{| class="wikitable" style="width:100%;"
|-
| Що потрібно створити? Критерій


* генерація шаблону з даними клієнта і туру. Додаткові функції ===
== Довідник «Країни і міста» ==


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


==== функції ERP ====
компонент має підтримувати бронювання на кількох осіб. Поле


* назва туру;
У результаті виконання атестаційного задача має бути створений компонент туристичної фірми в K2 ERP. SEO-опис
* країна / місто;
* готель;
* дати початку і закінчення туру;
* кількість ночей;
* тип харчування;
* базова вартість за людину;
* SEO-опис програми туру. Журнал «Клієнти» ===


==== Колонки журналу ====
* членів родини;
* дітей;
* друзів;
* учасників групового туру.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">


! функції ERP:
Оплата здатна бути:


==== Довідник «Готелі» ====
! Форма бронювання повинна дозволяти менеджеру оперативно оформити продаж туру. SEO-опис


* назва готелю;
== Рахунок на оплату ==
* країна / місто;
== Розрахунок залишку до оплати ==
* кількість зірок;
== Поля готелю ==
* типи харчування:
|-
** BB;
| Назва готелю
** HB;
| Офіційна або комерційна назва готелю
** AI;
|-
** інші. через менеджерів виступає ключовою рисою Туристична компанія-користувач організовує продаж турів: пакетних та індивідуальних. |-
| Країна
| Бекенд
| Країна розташування
| K2 Cloud ERP на Python або PHP
|-
| Місто або курорт
| Місто, курорт або регіон
|-
|-
| БД
| Кількість зірок
| PostgreSQL або MySQL
| Рейтинг готелю
|-
|-
| Фронтенд
| Типи харчування
| HTML5, JavaScript, AJAX, Fetch API або Axios
| BB, HB, FB, AI або інші варіанти
|-
|-
| UI-компоненти
| SEO-опис
| DataTables, Select2
| Короткий SEO-опис готелю
|-
|-
| Друк
| Статус
| Формування PDF-документів: договори, ваучери, рахунки
| Активний або прихований
|}
|}


!=== 3. інформаційні матеріали у ваучері:
Документи мають формуватися автоматизовано на основі даних клієнта, туру та бронювання.== Формати документів ==
компонент має підтримувати розмежування прав. | Загальну вартість, передоплату, залишок до оплати
|-
| Які документи потрібні? Якщо оплати не впливають на баланс бронювання, менеджер не зможе контролювати борги клієнтів. !== Формування документів ==


* PDF;
! Максимальна оцінка
Документи формуються автоматизовано на основі даних клієнта. обліковий обліковий облік оплат ===
Це потрібно для:
== Договір із клієнтом ==


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


==== Довідник «Тури» ====
== Поля бронювання ==


Поля довідника:
== Критерії оцінювання ==


* номер бронювання;
* номер бронювання;
* дата бронювання;
* дату;
* клієнт ERP ERP;
* клієнта;
* тур;
* тур;
* менеджера;
* кількість осіб;
* кількість осіб;
* загальна вартість;
* загальну суму;
* внесена передоплата;
* статус;
* баланс до оплати;
* суму оплат;
* статус:
* баланс до оплати.<pre>
** броньована;
** оплачена;
** відмінена. !==== Договір із клієнтом ====
==== Туристичний ваучер ====
|-
|-
| Реалізація довідників турів, готелів, клієнтів
| Менеджер
| Створює клієнтів, бронювання, оплати, документи по своїх клієнтах
|-
| Старший менеджер
| Бачить бронювання кількох менеджерів, контролює борги та скасування
|-
| Бухгалтер
| Перевіряє оплати, рахунки, заборгованість і фінансові звіти
|-
| Керівник
| Переглядає всі бронювання, продажі та реалізація, ефективність менеджерів
|-
| Адміністратор
| Налаштовує довідники, права, валюти, курси та шаблони документів
|}
 
== формування звітів ==
 
== Вимоги до мультивалютності ==
Звіт показує всі бронювання за вибраний період.== Групові та сімейні тури ==
компонент має дозволяти реєструвати оплати за бронювання.[[Категорія:Турфірма]]
 
== Основні об’єкти модуля ==
 
{| class="wikitable" style="width:100%;"
== Критичні помилки ==
<div style="border:2px solid #f57c00; background:#fff3e0; padding:14px; margin:16px 0;">
 
{| class="wikitable" style="width:100%;"
 
компонент повинен фіксувати важливі зміни. SEO-опис
 
== Журнал «Бронювання турів» ==
 
</pre>
Журнал змін має зберігати:
'''провідний принцип.''' Туристичний компонент — це не без зусиль список турів. Якщо курс у довіднику зміниться пізніше, старі бронювання не повинні неконтрольовано змінювати суму.== Нагадування про доплату ==
 
* передоплатою;
* частковою оплатою;
* повною оплатою;
* поверненням коштів при скасуванні бронювання. * вести довідник країн і міст;
* вести довідник готелів;
* вести довідник турів;
* вести клієнтів і туристів;
* створювати бронювання турів;
* розраховувати вартість туру за кількістю осіб;
* враховувати передоплати та повні оплати;
* контролювати залишок до оплати;
* формувати договір із клієнтом;
* формувати туристичний ваучер;
* формувати рахунок на оплату;
* підтримувати мультивалютність;
* перераховувати суми при зміні курсу;
* нагадувати менеджеру про необхідність доплати;
* формувати звіти по бронюваннях, оплатах, боргах і менеджерах. | Повний цикл: тур → бронювання → оплата → документи → звіт
|}
 
!== Реальний бізнес-контекст ==
 
Клієнти можуть купувати тур для себе, родини або групи людей. Колонка
</pre>
|-
| Номер бронювання
| Унікальний номер документа
|-
| Дата бронювання
| Коли створено бронювання
|-
| клієнт ERP
| Покупець туру
|-
| Тур
| Обраний тур
|-
| Кількість осіб
| Кількість туристів у бронюванні
|-
| Загальна вартість
| Повна вартість бронювання
|-
| Внесена передоплата
| Сума, яку вже оплатив клієнт ERP
|-
| Баланс до оплати
| Залишок, який потрібно доплатити
|-
| Менеджер
| Відповідальний за бронювання
|-
| Статус
| Заброньовано, частково оплачено, оплачено, відмінено
|}
 
== Права доступу ==
 
== Функціональність журналу клієнтів ==
У ваучері потрібно показати:
! Рівень
 
* номер договору;
* дату;
* інформаційні дані клієнта;
* паспортні інформаційні дані;
* назву туру;
* країну та місто;
* готель;
* дати туру;
* кількість туристів;
* вартість;
* порядок оплати;
* реквізити сторін;
* підписи сторін. Для реалізації задачі доцільно передбачити такі сутності:
 
! Поле
 
! Призначення
!== Статуси бронювання ==
 
# створити країну і місто;
# створити готель;
# створити типи харчування;
# створити тур із датами, готелем, ціною та валютою;
# створити клієнта;
# створити бронювання;
# додати кількох туристів;
# перевірити розрахунок загальної вартості;
# внести передоплату;
# перевірити залишок до оплати;
# внести повну оплату;
# перевірити зміну статусу бронювання;
# сформувати договір із клієнтом;
# сформувати туристичний ваучер;
# сформувати рахунок на оплату;
# перевірити мультивалютний перерахунок;
# створити нагадування про доплату;
# сформувати звіт бронювань;
# сформувати звіт оплат і боргів;
# сформувати звіт продажів по менеджерах. ! платформа повинна повідомляти менеджеру про наближення строку повної оплати. |-
| Назва країни
| як приклад: Туреччина, Єгипет, Іспанія, Польща
|-
| Код країни
| Короткий код або службове позначення
|-
| Активність
| Чи доступна країна для створення турів
|}
 
[[Категорія:Бронювання]]
 
Після кожної оплати платформа повинна автоматизовано перераховувати баланс до оплати. Колонка
 
== Звіт «Бронювання за період» ==
 
== Мета задача ==
 
'''критично.''' Вартість туру має зберігатися разом із валютою. Питання
 
платформа повинна підтримувати:
 
* PDF;
* DOCX, якщо потрібне редагування перед підписанням. SEO-опис
== Шкала оцінювання ==
 
! Окремо варто відзначити бронюваннями, оплатами, документами і фінансовою аналітикою туристичної компанії виступає ключовою рисою перевірки навичок розробника або впроваджувача [[K2 ERP]] у створенні модуля керування турами забезпечується через '''Атестаційне задача K2 ERP. * країну;
* місто або курорт;
* тур;
* готель;
* кількість бронювань;
* кількість туристів;
* суму продажів. Ваучер має містити інформацію, потрібну для подорожі. Що перевіряється
 
Звіт показує ефективність менеджерів. |-
| Назва міста
| як приклад: Анталія, Хургада, Барселона
|-
| Країна
| Країна, до якої належить місто
|-
| Активність
| Чи застосовується для місто в поточних турах
|}
 
== Форма бронювання ==
 
Якщо тур у валюті, а оплата ведеться в гривні:
 
! Один клієнт ERP здатна мати кілька бронювань у різний час, а одне бронювання здатна включати кількох туристів. ! | Країни, міста, готелі, типи харчування, тури, клієнти
|-
| Який провідний документ? !== Журнал «Клієнти» ==
Журнал клієнтів містить людей, які звернулися до туристичної компанії або придбали тур. '''Коротко.''' Потрібно реалізувати компонент для турфірми: країни, міста, готелі, тури, клієнти, бронювання, оплати, борги, договори, ваучери, рахунки, мультивалютність, нагадування менеджерам і звіти по бронюваннях, оплатах та менеджерах. ! ! 100
{| class="wikitable" style="width:100%;"
== обліковий облік оплат ==
|-
| Реалізація довідників турів, готелів і клієнтів
| 20
| 20
| Країни, міста, готелі, харчування, тури, клієнти, туристи
|-
|-
| Бронювання турів і обліковий обліковий облік оплат
| Бронювання турів і обліковий облік оплат
| 20
| 20
| Створення бронювання, розрахунок вартості, передоплата, повна оплата, борг
|-
|-
| Генерація документів
| Генерація документів
| 20
| 20
| Договір, ваучер, рахунок на оплату у PDF або DOCX
|-
|-
| Мультивалютність і перерахунок сум
| Мультивалютність і перерахунок сум
| 20
| 20
| UAH, USD, EUR, курси, фіксація курсу в бронюванні, перерахунок
|-
|-
| Інтерактивність через AJAX
| Інтерактивність через AJAX
| 10
| 10
| Вибір туру, розрахунки, оплати, статуси й документи без перезавантаження
|-
|-
| Звіти по бронюванням і оплатах
| Звіти по бронюваннях і оплатах
| 10
| 10
| Бронювання, оплати, борги, продажі та реалізація по менеджерах
|-
</div>
! {| class="wikitable" style="width:100%;"
== Колонки журналу клієнтів ==
Менеджеру потрібно оперативно підібрати тур, оформити бронювання, зафіксувати передоплату, бачити залишок до оплати, сформувати договір, ваучер і рахунок. Параметр
== Звіт «продажі та реалізація по менеджерах» ==
<pre>
Рахунок на оплату має містити:
Звіт показує, які напрями та тури продаються найкраще. 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]]
Туристична компанія-користувач продає пакетні та індивідуальні тури через менеджерів. ! Поле
</pre>
== Логування змін ==
== Поля туру ==
! Поле
* номер бронювання;
* клієнта або туристів;
* країну;
* місто або курорт;
* готель;
* тип харчування;
* дати проживання;
* трансфер;
* переліт або перевезення;
* контактні інформаційні дані туроператора або агенції. |-
| ПІБ
| Прізвище, ім’я та по батькові клієнта
|-
| Дата народження
| Дата народження клієнта
|-
| Паспортні інформаційні дані
| інформаційні дані паспорта або закордонного паспорта
|-
| Телефон
| Контактний номер
|-
| Email
| Електронна адреса
|-
| Менеджер
| Відповідальний менеджер
|-
| Кількість бронювань
| Скільки турів оформлено на клієнта
|}
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
Довідник готелів містить варіанти проживання, які використовуються в турах. Тип
|-
| Чернетка
| Бронювання створюється, але ще не підтверджене
|-
| Заброньовано
| Тур заброньовано для клієнта
|-
| Частково оплачено
| Внесено передоплату, але виступає як залишок до оплати
|-
| Оплачено
| Бронювання оплачено на 100%
|-
| Документи видані
| Договір, ваучер або інші документи сформовано і передано клієнту
|-
| Відмінено
| Бронювання скасовано
|}
|}


==== Довідник «Країни і Міста» ====
{| class="wikitable" style="width:100%;"
 
Основна формула:
 
Довідник турів містить туристичні пропозиції, які продає компанія-користувач. Бронювання — базовий документ продажу туру. Турфірма''' — це практична задача; так само реалізовано клієнтами. {| class="wikitable" style="width:100%;"
 
[[Категорія:CRM]]
 
* валюту туру;
* валюту оплати;
* курс валюти;
* перерахунок вартості туру в гривню;
* фіксацію курсу на момент бронювання;
* перерахунок при зміні курсу, якщо це дозволено правилами;
* звіти у валюті туру та в базовій валюті. Бали
== AJAX-інтерактив ==
 
!== Назва задача ==
|-
| Бекенд
| K2 Cloud ERP на Python або PHP
|-
| База даних
| PostgreSQL або MySQL
|-
| Фронтенд
| HTML5, JavaScript
|-
| AJAX
| Fetch API або Axios
|-
| UI-компоненти
| DataTables, Select2
|-
| Друк
| PDF-документи: договори, ваучери, рахунки
|-
| Документи
| PDF та DOCX, якщо потрібно редагування
|}
 
платформа повинна дозволяти:
 
{| class="wikitable" style="width:100%;"
 
* країни;
* міста;
* готелі;
* типи харчування;
* тури;
* клієнти;
* туристи;
* бронювання;
* рядки туристів у бронюванні;
* оплати;
* валюти;
* курси валют;
* договори;
* ваучери;
* рахунки на оплату;
* менеджери;
* нагадування;
* журнал змін;
* шаблони документів;
* звіти. Журнал клієнтів має підтримувати:
 
* неможливо створити тур;
* неможливо створити клієнта;
* неможливо створити бронювання;
* кількість осіб не впливає на загальну вартість;
* оплата не зменшує баланс до оплати;
* бронювання не показує реальний борг;
* повна оплата не змінює статус бронювання;
* договір не формується з даними клієнта і туру;
* ваучер не містить даних готелю, трансферу або перевезення;
* рахунок на оплату не містить деталізації вартості;
* курс валюти не фіксується в бронюванні;
* старі бронювання змінюють суму через зміну курсу без контролю;
* менеджер не бачить наближення строку доплати;
* звіти не відповідають бронюванням і оплатам;
* зміни бронювання або оплат не логуються. | Договір із клієнтом, туристичний ваучер, рахунок на оплату
|-
| Що має підтримувати мультивалютність?== Очікуваний результат ==
 
[[Категорія:Атестаційні завдання K2]]
 
* номер рахунку;
* дату;
* клієнта;
* бронювання;
* тур;
* кількість осіб;
* деталізацію вартості;
* суму до оплати;
* валюту;
* реквізити для оплати;
* коментар щодо строку оплати. '''Умова складання.''' задача не здатна бути зараховане, якщо платформа не дає можливість пройти базовий цикл туристичної фірми: тур → клієнт ERP → бронювання → оплата → залишок до оплати → договір → ваучер → звіт. Значення
 
У межах атестації потрібно продемонструвати робочий сценарій. ! Керівнику потрібно бачити продажі та реалізація, борги, ефективність менеджерів і фінансову картину по турах. Туристичний компонент виступає як критичним для агенцій, які займаються продажем пакетних турів, індивідуальних подорожей, групових поїздок, бронюванням готелів і супровідних послуг. ! Значення
 
== Довідник «Готелі» ==


=== 4. Параметр
</div>


* назва країни;
* сімейних турів;
* міста для подорожей. {| class="wikitable"
* групових поїздок;
* корпоративних подорожей;
* дитячих таборів;
* екскурсійних груп. | компонент керування турами, клієнтами та бронюваннями
|-
| Які довідники потрібні?== базовий бізнес-процес ==
</div>


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


* деталізація вартості туру;
== Довідник «Тури» ==
* DOCX. * вести довідники турів, готелів, перевезень;
* бронювати тури для клієнтів;
* формувати документи:
** договір із клієнтом;
** ваучер;
* вести обліковий обліковий облік оплат і заборгованостей;
* автоматизовано створювати фінансову аналітику по турах і менеджерах. SEO-опис


{| class="wikitable"
__TOC__
критичний; так само реалізовано які займаються продажем пакетних турів, індивідуальних подорожей і бронюванням готелів виступає ключовою рисою агенцій забезпечується через Туристичний компонент. Критерій
==== функції ERP ====
! Такий функції ERP дає можливість:


==== Колонки журналу ====
Сума UAH = Сума у валюті × Курс


=== 1. Бронювання турів ===
Мінімальний сценарій:


=== 6. Структура довідників ===
== Звіт «Популярність турів» ==


* реєстрація оплат за бронювання;
Мета задача — створити в K2 ERP компонент для автоматизації роботи туристичної компанії. | UAH, USD, EUR, курси та перерахунок вартості
* відображення поточного балансу по кожному бронюванню;
|-
* підказки про необхідність доплати перед виїздом. Формування документів ===
| Які звіти потрібні? {| class="wikitable" style="width:100%;"


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


* на 100% цифровізувати бізнес-процес продажу;
* створення клієнта;
* цифровізувати підготовку документів;
* вибір туру;
* підвищити якість обслуговування клієнтів.
* підтягування ціни туру;
* розрахунок загальної вартості;
* додавання туристів у бронювання;
* реєстрація оплати;
* перерахунок залишку до оплати;
* зміна статусу бронювання;
* формування документів;
* фільтрація журналів. Якщо ціна задана в USD або EUR, платформа повинна коректно перераховувати суму в гривню за курсом, який діє для бронювання. Довідник країн і міст застосовують, коли потрібно для структурування туристичних напрямів. | Бронювання туру
|-
| Що має рахувати платформа? |-
| 90–100
| Відмінно
| компонент на 100% функціонує: тури, клієнти, бронювання, оплати, документи, мультивалютність, нагадування і звіти реалізовані коректно
|-
| 75–89
| Добре
| Основна логіка функціонує, виступає як незначні недоліки, які не руйнують бізнес-процес продажу туру
|-
| 60–74
| Зараховано
| Базовий сценарій функціонує, але частина функцій реалізована неповно або потребує доопрацювання
|-
| 0–59
| Не зараховано
| Відсутня критична логіка: тури, бронювання, оплати, документи, валюти або звіти
|}
 
компонент має підтримувати країни, міста, готелі, типи харчування, тури, клієнтів, туристів, бронювання, оплати, мультивалютність, договори, туристичні ваучери, рахунки на оплату, нагадування про доплату, звіти по бронюваннях, оплатах, боргах і менеджерах. ! {| class="wikitable" style="width:100%;"
 
* хто створив бронювання;
* хто змінив тур;
* хто змінив кількість осіб;
* хто додав оплату;
* хто змінив статус;
* хто сформував договір;
* хто скасував бронювання;
* дату й час зміни;
* старе та нове значення, якщо це можливо.</div>
|-
| Назва туру
| Комерційна назва туру
|-
| Тип туру
| Пакетний або індивідуальний
|-
| Країна
| Країна подорожі
|-
| Місто або курорт
| Місце відпочинку
|-
| Готель
| Готель із довідника
|-
| Дата початку
| Початок туру
|-
| Дата завершення
| Кінець туру
|-
| Кількість ночей
| Розраховується або вводиться вручну
|-
| Тип харчування
| BB, HB, AI тощо
|-
| Базова вартість за людину
| Ціна за одного туриста
|-
| Валюта туру
| UAH, USD, EUR або інша валюта
|-
| SEO-опис програми туру
| Детальний SEO-опис туру
|-
| Статус
| Активний, архівний, призупинений
|}
 
== Примітка ==
Звіт показує фінансовий стан бронювань. Критичними помилками вважаються ситуації, коли:
Повідомлення здатна бути внутрішнім, email або іншим способом, який застосовується для в K2 ERP.

Поточна версія на 18:45, 1 травня 2026

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

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

критично. Курс, використаний у бронюванні, має зберігатися. 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. 

  2. створити готель;
    3. 

  3. створити типи харчування;
    4. 

  4. створити тур із датами, готелем, ціною та валютою;
    5. 

  5. створити клієнта;
    6. 

  6. створити бронювання;
    7. 

  7. додати кількох туристів;
    8. 

  8. перевірити розрахунок загальної вартості;
    9. 

  9. внести передоплату;
    10. 

  10. перевірити залишок до оплати;
    11. 

  11. внести повну оплату;
    12. 

  12. перевірити зміну статусу бронювання;
    13. 

  13. сформувати договір із клієнтом;
    14. 

  14. сформувати туристичний ваучер;
    15. 

  15. сформувати рахунок на оплату;
    16. 

  16. перевірити мультивалютний перерахунок;
    17. 

  17. створити нагадування про доплату;
    18. 

  18. сформувати звіт бронювань;
    19. 

  19. сформувати звіт оплат і боргів;
    20. 

  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.



Отримано з https://wiki.kyiv.ua/index.php?title=Атестаційні_завдання_K2_ERP/Турфірма&oldid=523