Сайт гостиницы на 1С-Битрикс: онлайн-бронирование и PMS-интеграция

Гостиничный сайт отличается от обычного каталога тем, что посетитель выбирает не товар, а временной слот. Номер сам по себе — набор характеристик (площадь, вместимость, вид из окна). Но без свободных дат это мёртвая карточка. Весь проект строится вокруг календаря доступности и механики бронирования, а не вокруг красивой вёрстки. Проблема: посетитель видит красивые фото, но при попытке забронировать — календарь не обновлён или цена не соответствует сезону. Или интеграция с Booking.com отсутствует, и отель получает овербукинг. Мы решаем эти проблемы на уровне архитектуры: движок бронирования на Highload-блоках, сезонные тарифы, синхронизация с PMS.

Как работает система бронирования?

Ядро проекта — управление доступностью номеров. Задача: пользователь выбирает даты, система показывает доступные типы с ценами, бронирует и блокирует номер.

Хранение доступности — Highload-блок RoomInventory. Каждая строка — одна ночь для одного физического номера.

Highload-блок — ORM-обёртка над таблицей с автоматическим API. При 100 номерах и горизонте 365 дней — 36 500 строк. Обязательные индексы: составной на (UF_DATE, UF_ROOM_TYPE_ID, UF_STATUS) и (UF_BOOKING_ID).

Алгоритм проверки доступности. Гость вводит check_in, check_out, guests. Система находит типы номеров с хотя бы одним физическим номером, свободным на все ночи.

public function getAvailableRoomTypes(
    \Bitrix\Main\Type\Date $checkIn,
    \Bitrix\Main\Type\Date $checkOut,
    int $guests
): array {
    $nights = $checkOut->getDiff($checkIn)->days;
    $dates = [];
    for ($i = 0; $i < $nights; $i++) {
        $d = clone $checkIn;
        $d->add(new \DateInterval("P{$i}D"));
        $dates[] = $d->format('Y-m-d');
    }

    // Находим номера, занятые хотя бы в одну из ночей
    $busyRooms = RoomInventoryTable::getList([
        'select' => ['UF_ROOM_ID'],
        'filter' => [
            'UF_DATE' => $dates,
            '!UF_STATUS' => 0,
        ],
        'group' => ['UF_ROOM_ID'],
    ])->fetchAll();

    $busyRoomIds = array_column($busyRooms, 'UF_ROOM_ID');
    // Далее — исключаем занятые номера и фильтруем по вместимости
}

Подход через HAVING COUNT(*) = {$nights} корректнее:

SELECT UF_ROOM_ID, UF_ROOM_TYPE_ID
FROM hl_room_inventory
WHERE UF_DATE IN ('2025-07-15','2025-07-16','2025-07-17')
  AND UF_STATUS = 0
GROUP BY UF_ROOM_ID, UF_ROOM_TYPE_ID
HAVING COUNT(*) = 3

Календарь доступности на фронте. Два поля — дата заезда и выезда. Реализация на flatpickr в режиме range. При открытии — AJAX-запрос за матрицей доступности: массив дат с признаком «есть свободные номера». Endpoint возвращает JSON:

{
  "2025-07": {
    "15": {"available": true, "min_rate": 4500},
    "16": {"available": true, "min_rate": 4500},
    "17": {"available": false, "min_rate": null},
    "18": {"available": true, "min_rate": 6200}
  }
}

Недоступные даты блокируются в календаре (disable). Минимальный тариф — при наведении. Запросы кэшируются через Bitrix\Main\Data\Cache с ключом availability_{month}_{year}.

Почему сезонное ценообразование увеличивает прибыль?

Highload-блок RatePlan:

При расчёте стоимости бронирования система перебирает каждую ночь, находит подходящий тарифный план и суммирует. Итоговая сумма — сумма по всем ночам.

Архитектура номерного фонда

Каждый тип номера — элемент инфоблока «Номерной фонд». Важно разделять тип (например, «Стандарт двухместный») и физические номера (20 комнат). Это ключевое архитектурное решение.

Структура инфоблока:

Удобства (AMENITIES) — множественное свойство типа «Список». Не Highload-блок, потому что набор фиксирован (30-50 позиций). На фронте значения маппятся на иконки через конфиг.

Фотогалерея и виртуальный тур. Множественное свойство типа «Файл». Рендер — Swiper.js с lazy-загрузкой, превью через CFile::ResizeImageGet() на 600x400 с BX_RESIZE_IMAGE_PROPORTIONAL. Для 360-панорамы — Pannellum.js: библиотека принимает equirectangular-изображение и рендерит интерактивный обзор. Хранение — строковое свойство PANORAMA_URL. Pannellum инициализируется на клиенте:

pannellum.viewer('panorama-container', {
    type: 'equirectangular',
    panorama: roomData.panoramaUrl,
    autoLoad: true,
    compass: true,
    hotSpots: [
        { pitch: -5, yaw: 120, type: 'info', text: 'Ванная комната' },
        { pitch: 0, yaw: 240, type: 'info', text: 'Балкон с видом на море' }
    ]
});

Hotspots задаются в JSON-свойстве инфоблока или в Highload-блоке, если нужна админ-панель.

Как iCal-синхронизация предотвращает овербукинг?

Гостиница продаёт номера на сайте и через OTA (Booking.com, Expedia). Без синхронизации — овербукинг. Channel Manager синхронизирует доступность и тарифы между PMS, сайтом и каналами.

iCal-синхронизация — простейший вариант. Booking.com и Airbnb отдают .ics-файлы. Битрикс-агент раз в 15 минут:

1. Забирает .ics по URL (file_get_contents или cURL)
2. Парсит VEVENT — извлекает DTSTART, DTEND, SUMMARY
3. Обновляет RoomInventory: UF_STATUS = 2 (заблокирован)
4. Генерирует исходящий .ics с бронированиями сайта

Ограничение iCal: нет тарифов, задержка до 15 минут. Для 100+ номеров нужен API-коннектор. XML Push / API — через REST или SOAP (Booking.com Connectivity API). iCal-синхронизация в 10 раз проще API-интеграции, но менее гибкая.

PMS-интеграция. 1С:Отель — обмен через HTTP-сервис. Opera / Fidelio — SOAP с WSDL. Мы реализуем класс-обёртку над SoapClient с логированием.

Онлайн-оплата и предоплата. Бронирование через модуль sale. Заказ — одна позиция «Проживание в {тип}, {check_in} — {check_out}». Предоплата (20-30%) — кастомный обработчик OnSaleBeforeOrderAdd. Процент и первая ночь — типовые схемы.

Дополнительные модули

Личный кабинет гостя: авторизация (email + OAuth), мои бронирования, история поездок, программа лояльности. Баллы начисляются через обработчик OnSaleStatusOrderChange.

Мультиязычность: языковые версии (/en/, /de/), контент через свойства инфоблоков, hreflang.

SEO и микроразметка: Schema.org Hotel + HotelRoom + Offer. Разметка генерируется автоматически.

Фотоцентричный дизайн: WebP с fallback, <picture> с srcset, lazy-load. Оригиналы до 3000px, превью 800x600.

Отзывы: Highload-блок Reviews с модерацией. Агрегированный рейтинг в свойстве инфоблока AVG_RATING.

Что входит в работу

• Аналитика и прототипирование (карта номерного фонда, логика бронирования)
• Дизайн (фотоцентричный UI, мобильная версия, календарь)
• Ядро бронирования (RoomInventory, проверка доступности, оформление заказа, оплата)
• Интеграции (PMS, Channel Manager, платёжные системы, REST API)
• Контент и SEO (микроразметка, мультиязычность, мета-шаблоны)
• Тестирование и запуск (нагрузочное, кроссбраузерное, деплой)
• Документация и обучение администраторов
• Постпроектное сопровождение и гарантия

Этапы и сроки

Сроки не включают фотосъёмку и создание 360-панорам — это параллельный процесс.

Прямое бронирование через сайт в 2-3 раза выгоднее для отеля, чем через OTA, за счёт отсутствия комиссии. Экономия составляет 15-25% от выручки. Система бронирования окупается в среднем за 6-12 месяцев за счёт роста прямых продаж.

Мы работаем в гостиничной разработке более 8 лет, выполнили более 50 проектов для гостиничного бизнеса. Наши инженеры — сертифицированные специалисты 1С-Битрикс. Закажите разработку сайта гостиницы — мы подберём архитектуру под ваш номерной фонд. Получите консультацию по архитектуре вашего сайта — оценим задачу и предложим решение.

Как правильно проектировать инфоблоки?

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

Наш подход: проектируем инфоблоки до первой строки кода. Отдельные инфоблоки под сущности (товары, категории, бренды), свойства-справочники через highload-блоки, торговые предложения для SKU. Это закладывает производительность на годы вперёд. Если хотите получить предварительный аудит вашей схемы инфоблоков — свяжитесь с нами, разберём типовые ошибки и дадим рекомендации бесплатно.

Почему 1С-Битрикс выгоднее альтернатив?

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

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

Что дают HL-блоки и как мы ускоряем каталог

Highload-блоки — это альтернатива расширенным свойствам инфоблоков, когда список значений может расти до тысяч записей. Типичный пример: производители, страны, цвета. Если хранить их как свойства-списки в инфоблоке, каждая фильтрация вызывает полное сканирование таблицы b_iblock_property_enum. С HL-блоками выборка идёт по индексу — время ответа фильтра снижается с 1–2 секунд до 50 мс. Мы используем 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 — закажите аудит производительности и миграцию на Битрикс.