Разработка сайта туроператора на 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-летним опытом помогут вам избежать типичных ошибок и построить производительное решение.