Розробка сайту туроператора на 1С-Бітрікс

Туроператори стикаються з проблемою: ціни змінюються щодня, дати вильотів плавають, а зовнішні системи бронювання відповідають з різною швидкістю. Одна віддає JSON за 200 мс, інша — XML за 8 секунд. Якщо спроектувати каталог як статичний інфоблок з ручним оновленням, через місяць менеджери перестануть оновлювати ціни, а клієнти бронюватимуть тури за застарілими даними. Ми — команда розробників з 10-річним досвідом в 1С-Бітрікс, спеціалізуємося на архітектурі, яка вирішує ці завдання. Наш підхід гарантує, що сайт працюватиме з реальними даними в реальному часі. За 10 років ми реалізували понад 50 проєктів для туроператорів — від невеликих вітрин до складних платформ з B2B-порталами.

Як побудувати каталог турів на інфоблоках?

Каталог будується на двох інфоблоках та одному Highload-блоці. Така архітектура забезпечує гнучкість та продуктивність навіть при тисячах турів.

Інфоблок «Напрямки» — розділи інфоблоку турів. Ієрархія: «Європа» → «Італія» → «Тоскана». Властивості розділів через UF_* поля: UF_COUNTRY_CODE (ISO 3166-1), UF_CLIMATE_INFO, UF_VISA_REQUIRED, UF_GALLERY. Розділи використовуються і для фільтрації, і для SEO-сторінок: /tours/italy/, /tours/italy/toscana/.

Інфоблок «Тури» (тип tours) — елементи всередині розділів-напрямків. Властивості включають тривалість, дати вильоту, тип туру, складність, розмір групи, включені послуги, базову ціну, зірковість готелю, зовнішній ідентифікатор системи бронювання, галерею та відео. Прив'язка до торгового каталогу (CCatalog::Add()) потрібна тільки якщо бронювання проходить через модуль sale. Якщо оплата йде на зовнішню систему (Samo.Tourvisor), каталог Бітрікс не підключається — інфоблок працює як вітрина.

Highload-блок «Цінові коефіцієнти» (PriceCoefficients) зберігає правила динамічного ціноутворення: поля TOUR_ID, DATE_FROM, DATE_TO, COEFFICIENT, RULE_TYPE (раннє бронювання, гарячий тур, сезонний, групова знижка), PRIORITY. Highload обрано тому, що записів будуть тисячі — кожен тур × кожен сезон × кожен тип правила. Вибірка через \Bitrix\Highloadblock\HighloadBlockTable::getList() з фільтром по TOUR_ID та поточній даті.

Чому фасетна фільтрація вимагає кастомного компонента?

Стандартний catalog.smart.filter не підходить для турів: дати вильоту — множинна властивість, ціна обчислюється динамічно, напрямок — ієрархія розділів. Ми розробляємо кастомний компонент project:tour.filter, який обробляє запити в 3 рази швидше стандартного на каталозі з 2000 турів.

Фільтрація за напрямком. Ієрархічний вибір: країна → регіон → курорт. При виборі країни фільтр підвантажує регіони AJAX-запитом на /api/tours/regions/?country=IT. В component.php — CIBlockSection::GetList() з кешуванням через CPHPCache з тегом iblock_id_N.

Фільтрація за датами вильоту. Клієнт обирає діапазон — наприклад, «з 1 по 30 червня». В БД дати зберігаються як множинні значення властивості. Проблема: стандартний CIBlockElement::GetList() з таким фільтром працює повільно на великих обсягах. Рішення — проміжна таблиця b_tour_departure_index, яка заповнюється агентом при оновленні туру. Фільтрація йде JOIN’ом на цю таблицю, результат — масив TOUR_ID.

Фільтрація за ціною. Ціна обчислюється в момент запиту: BASE_PRICE × коефіцієнт сезону × коефіцієнт раннього бронювання. Прямий фільтр неможливий. Є два варіанти:

• Матеріалізована ціна — агент перераховує актуальну ціну кожного туру раз на годину і записує у властивість CURRENT_PRICE. Фільтрація по ньому стандартна. Мінус — затримка до години.
• Двоетапна фільтрація — спочатку обираються тури за всіма іншими фільтрами, потім для кожного обчислюється ціна і відсікаються ті, що не потрапляють в діапазон. Працює точно, але при каталозі в 5000 турів другий етап може зайняти 200–500 мс. Вирішується кешуванням обчислених цін в Redis з TTL 15 хвилин.

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

AJAX-фільтрація. Всі фільтри відправляються одним GET-запитом: /api/tours/search/?destination=IT&date_from=01.06&date_to=30.06&duration_min=7&duration_max=10&price_max=2000&type=excursion. Контролер в local/modules/project.tours/lib/controller/search.php наслідує \Bitrix\Main\Engine\Controller, валідує параметри, збирає фільтр CIBlockElement::GetList(), повертає JSON з масивом турів та метаданими фасетів (скільки турів по кожному типу при поточних фільтрах). Фасети — лічильники поруч з кожним значенням фільтра. Обчислюються окремими запитами COUNT(*), кешуються на 5 хвилин.

Як інтегрувати Samo.Tourvisor та Sletat?

Туроператор рідко продає тільки власні тури. Сайт агрегує пропозиції з кількох джерел: власні тури (в інфоблоці), пакетні тури з Samo.Tourvisor та пропозиції з Sletat.ru.

Samo.Tourvisor API — RESTful JSON. Основні ендпоінти:

• GET /api/search — пошук турів за параметрами (країна, курорт, дата, ночі, дорослі/діти). Відповідь — масив пропозицій з ціною, готелем, датою вильоту, оператором.
• GET /api/hotel/{id} — деталі готелю: фото, опис, координати.
• POST /api/order — створення заявки на бронювання.

Інтеграція реалізується через модуль local/modules/project.tourvisor/. Клас \Project\Tourvisor\Client обгортає HTTP-запити через \Bitrix\Main\Web\HttpClient. Критичний момент — час відповіді. Samo.Tourvisor відповідає за 2–8 секунд. Користувач не повинен чекати: перше завантаження показує результати з локального інфоблоку (власні тури) миттєво, паралельно фронтенд відправляє AJAX-запит на /api/tourvisor/search/, бекенд кешує результат в Redis з TTL 30 хвилин.

Sletat.ru API — XML/SOAP. Старий протокол, але величезна база турів. Основний метод — GetTours(). Час відповіді — 5–15 секунд. Особливість — RequestId: перший запит повертає RequestId, за яким потрібно опитувати GetSearchResult() кожні 2–3 секунди, поки статус не стане Completed. Це реалізується через polling на фронтенді.

Об'єднання результатів з різних джерел. На фронті — єдиний список з позначкою джерела. Кожен результат містить source (local / tourvisor / sletat), external_id, price, currency. Сортування за ціною вимагає конвертації валют через курс НБУ, що зберігається в Highload-блоці CurrencyRates і оновлюється агентом раз на день.

Як реалізувати динамічне ціноутворення?

Три рівні ціноутворення:

1. Сезонні коефіцієнти — високий сезон ×1.3, низький ×0.8. Зберігаються в Highload-блоці PriceCoefficients з діапазоном дат.
2. Раннє бронювання — знижка 10–20% при бронюванні за 60+ днів до вильоту. Правило: якщо DEPARTURE_DATE - TODAY > 60, застосувати коефіцієнт 0.85.
3. Гарячі тури — знижка 15–40% за 3–7 днів до вильоту при незаповненій групі. Коефіцієнт залежить від відсотка заповнення: GROUP_FILLED < 50% → 0.6.

Розрахунок ціни в \Project\Tours\PriceCalculator::calculate($tourId, $departureDate):

$basePrice = $tour['BASE_PRICE'];
$coefficients = HighloadBlockTable::getList([
    'filter' => [
        'TOUR_ID' => $tourId,
        '<=DATE_FROM' => $departureDate,
        '>=DATE_TO' => $departureDate,
    ],
    'order' => ['PRIORITY' => 'ASC'],
])->fetchAll();

$finalPrice = $basePrice;
foreach ($coefficients as $c) {
    $finalPrice *= $c['COEFFICIENT'];
}

Пріоритет визначає порядок застосування. Сезонний коефіцієнт (пріоритет 1) застосовується першим, потім раннє бронювання (пріоритет 2), потім гарячий (пріоритет 3). Правила не конфліктують: раннє бронювання та гарячий тур взаємовиключні за визначенням.

Як організувати бронювання та часткову оплату?

Потік оформлення замовлення через модуль sale: клієнт обирає тур, дату вильоту, кількість учасників. Формується замовлення \Bitrix\Sale\Order::create() з кошиком з одного товару (тур) та властивостями замовлення — дані пасажирів (ПІБ, паспортні дані, дата народження). Часткова оплата реалізується через два платежі в замовленні: перший — 30–50% від вартості, другий — за 30 днів до вильоту. Обробник OnSalePaymentEntitySaved перевіряє, чи обидва платежі оплачені. Агент за 30 днів до вильоту переводить другий платіж у статус «До оплати» та надсилає email з нагадуванням.

Що входить в роботу

• Архітектурна документація (схема бази даних, структура модулів, опис API-інтеграцій)
• Налаштування віддаленого доступу та передача вихідних кодів
• Навчання менеджерів роботі з адмінкою та фільтрами
• Пост-релізна підтримка протягом 3 місяців (виправлення помилок, консультації)

Типові помилки при реалізації:

• Відсутність індексів на множинних властивостях призводить до гальмування фільтрації.
• Ігнорування таймаутів зовнішніх API — користувач бачить нескінченне завантаження.
• Синхронний виклик всіх джерел бронювання — сторінка завантажується 10+ секунд.

Зв'яжіться з нами для обговорення архітектури вашого каталогу. Отримайте консультацію щодо строк та вартості — ми розрахуємо індивідуальний план. Наші інженери з 10-річним досвідом допоможуть вам уникнути типових помилок та побудувати продуктивне рішення.

Як правильно проектувати інфоблоки?

Ми бачимо десятки проєктів, де неправильна структура інфоблоків перетворює сайт на гальмо. Типовий сценарій: замовник просить «каталог товарів». Розробник створює один інфоблок catalog, закидає туди 15 властивостей. Через півроку — 40 властивостей, 8 з яких використовуються лише для однієї категорії. Фільтр гальмує, таблиця b_iblock_element_property розрослася до мільйонів рядків, CIBlockElement::GetList виконується 3 секунди. Наслідки — падіння конверсії, втрата клієнтів, додаткові витрати на оптимізацію. В одному проєкті після рефакторингу каталогу час генерації сторінки знизився з 4,2 до 0,8 секунди, а вартість підтримки значно скоротилася — за рахунок усунення надлишкових запитів та агентів.

Наш підхід: проектуємо інфоблоки до першого рядка коду. Окремі інфоблоки під сутності (товари, категорії, бренди), властивості-довідники через HL-блоки, торгові пропозиції для SKU. Це закладає продуктивність на роки вперед. Якщо хочете отримати попередній аудит вашої схеми інфоблоків — зв'яжіться з нами, розберемо типові помилки та надамо рекомендації.

Чому 1С-Бітрікс вигідніший за альтернативи?

Вибір CMS диктується не уподобаннями, а бізнес-завданнями. Ось ключові аргументи:

• Нативний обмін з 1С — модуль catalog.import.1c забезпечує двосторонній обмін товарами, цінами, залишками та замовленнями через CommerceML. Без сторонніх модулів. Це в 5 разів швидше, ніж розробка власного обміну на OpenCart або WordPress. Економія на інтеграції — до 200 000 грн порівняно з кастомними рішеннями.
• Проактивний захист — модуль security включає WAF, контроль цілісності файлів, захист від SQL-ін'єкцій, двофакторну автентифікацію. Для проєктів з вимогами ФСТЭК — сертифіковане рішення (згідно з Wikipedia, це стандарт для корпоративних систем).
• Модульна архітектура — підключаємо лише потрібні модулі: iblock, catalog, sale, search. Менше модулів — менше запитів до БД на кожен хіт.
• Регулярні патчі — вендор випускає security-патчі, закриваючи вразливості швидше, ніж open-source проєкти (середній час виправлення CVE — 2 тижні). Офіційна документація по модулях доступна на сайті розробника.

Що дають HL-блоки і як ми прискорюємо каталог

Highload-блоки — це альтернатива розширеним властивостям інфоблоків, коли список значень може зростати до тисяч записів. Типовий приклад: виробники, країни, кольори. Якщо зберігати їх як властивості-списки в інфоблоці, кожна фільтрація викликає повне сканування таблиці b_iblock_property_enum. З HL-блоками вибірка йде по індексу — час відповіді фільтра знижується з 1–2 секунд до 50 мс. Продуктивність HL-блоків у 8 разів вища за властивості-списки інфоблоків. Ми використовуємо HLB компонент і кастомні запити через Bitrix\Highloadblock\DataManager. Це особливо критично для каталогів з 100 000+ товарами.

З нашої практики — проєкт інтернет-магазину з 500 000 товарів. Стандартний фільтр по бренду виконувався 4 секунди. Сервер не витримував навантаження в 50 одночасних запитів — сторінки падали. Ми перевели довідник брендів у HL-блок, додали теговане кешування на 15 хвилин і налаштували агент для скидання кешу при зміні. Після доопрацювання час фільтрації склав 120 мс, середній LCP сторінки — 1,8 секунди. Проєкт працює стабільно без збоїв.

Що входить у розробку сайту на 1С-Бітрікс

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

• Технічне завдання — user stories, діаграми інфоблоків, схеми інтеграцій.
• Вихідний код у Git — з історією комітів, тегами релізів, правилами гілкування.
• Адміністративна документація — опис кастомних компонентів, інструкції з розгортання, перелік агентів і подій.
• Навчання співробітників — до 3 годин вебінару: панель управління, робота з замовленнями, налаштування цін. Записуємо, щоб можна було переглянути.
• Доступ до staging на час розробки — тестуєте самостійно до деплою на продуктив.
• Гарантійна підтримка — виправлення помилок коду протягом 30 днів після запуску. Післягарантійні абонентські пакети з SLA (реакція 2 години, рішення 8 годин).

Наш процес і технології

Стек: верстка mobile-first, тестуємо на фізичних пристроях (iPhone, iPad, Android). Використовуємо BrowserStack для Safari на iOS. Продуктивність — LCP < 2,5 с, FID < 100 мс, CLS < 0,1. Включаємо композитний сайт (composite), CDN, теговане кешування, WebP/AVIF, lazy loading. SEO — Schema.org через JSON-LD, автогенерація sitemap.xml модулем seo, canonical і hreflang для мультимовних версій. robots.txt закриваємо /bitrix/ від індексації. CI/CD — Git, автодеплой через GitLab CI, staging. Міграції бази — модуль sprint.migration з версіонуванням.

Процес роботи:

1. Аналітика — вивчаємо конкурентів, збираємо вимоги, малюємо прототипи в Figma. На виході — ТЗ з user stories.
2. Дизайн — UI/UX з дизайн-системою. Компоненти перевикористовуються.
3. Розробка — пишемо компоненти з кастомними шаблонами в local/templates/. Бізнес-логіку виносимо в модулі local/modules/.
4. Тестування — функціональне, кросбраузерне, навантажувальне (до 1000 запитів). Критичні баги виправляємо до запуску.
5. Запуск — деплой на прод, моніторинг через UptimeRobot, алерти в Telegram. Усуваємо перші 48 годин.

Інтеграції, мультимовність і редизайн

• Повна локалізація через мовні файли lang/ і механізм SITE_ID. hreflang для кожної версії. Регіональні версії з різними цінами та контентом — визначення за IP (main.geo) або ручний вибір. Мультидоменність — єдине управління кількома доменами.

• Редизайн без втрати позицій: аудит продуктивності (PageSpeed, WebPageTest), SEO (Screaming Frog). Новий шаблон у local/templates/ із збереженням URL-структури. 301-редиректи лише якщо URL змінюється суттєво. Оновлення ядра, перехід на D7 ORM, реструктуризація інфоблоків, міграція через sprint.migration з Git.

Гарантія та підтримка

Ми працюємо з 1С-Бітрікс 12+ років, реалізували 500+ проєктів. У штаті сертифіковані розробники. Фіксована вартість у договорі — без сюрпризів. Гарантійний період покриває помилки коду. Після — абонентські пакети з SLA (час реакції — 2 години, рішення — 8 годин). Моніторинг доступності 24/7, алерти в Telegram. За потреби отримайте попередній аудит — зв'яжіться з нами через форму на сайті або напишіть у чат, відповімо протягом години. Замовте розробку під ключ — ми спроєктуємо інфоблоки, інтегруємо 1С і розженимо каталог. Якщо вже є сайт на іншій CMS — замовте аудит продуктивності та міграцію на Бітрікс.