Сайт готелю на 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 секунди, а вартість підтримки значно скоротилася — за рахунок усунення надлишкових запитів та агентів.

Наш підхід: проектуємо інфоблоки до першого рядка коду. Окремі інфоблоки під сутності (товари, категорії, бренди), властивості-довідники через 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 — замовте аудит продуктивності та міграцію на Бітрікс.