Разработка системы бронирования на 1С-Битрикс

Овербукинг — головная боль любого отельного бизнеса. Когда два гостя одновременно бронируют последний номер, стандартный Битрикс не может гарантировать, что не возникнет двойной записи. Потери от таких конфликтов могут достигать 500 000 руб в год для небольшой сети. Мы разработали кастомную систему бронирования на 1С-Битрикс, которая полностью исключает овербукинг за счёт транзакционной блокировки строк и автоматического освобождения просроченных броней. Кастомная разработка системы бронирования на 1С-Битрикс начинается с проектирования схемы данных: таблица bl_booking, индексы и транзакции. Под капотом — SELECT FOR UPDATE, агент и AJAX-календарь. Ниже — архитектура и реальный кейс.

Согласно документации 1С-Битрикс, для сложной логики бронирования рекомендуется использовать кастомные таблицы вместо инфоблоков. Мы используем именно такой подход: инфоблок rooms для описания номеров, а кастомную таблицу bl_booking для учёта занятости. Это даёт гибкость в запросах и производительность.

Почему стандартный инфоблок не подходит для бронирования?

Для календарного учёта доступности нужна отдельная схема. Инфоблок не позволяет эффективно проверять пересечения дат и блокировать слоты.

Таблица объектов — инфоблок типа room с свойствами PROPERTY_ROOM_TYPE, PROPERTY_CAPACITY и привязкой к отелю.

Таблица броней — пользовательская таблица bl_booking:

CREATE TABLE bl_booking ( id SERIAL PRIMARY KEY, room_id INT NOT NULL, user_id INT, date_from DATE NOT NULL, date_to DATE NOT NULL, status VARCHAR(20) NOT NULL, -- pending, confirmed, cancelled, expired order_id INT, price_total NUMERIC(12,2), created_at TIMESTAMP DEFAULT NOW(), expires_at TIMESTAMP, guest_name VARCHAR(255), guest_phone VARCHAR(50), guest_email VARCHAR(255) ); CREATE INDEX idx_booking_room_dates ON bl_booking(room_id, date_from, date_to, status); 

Как работает проверка доступности с защитой от race condition?

Ключевой запрос — проверка пересечений:

SELECT COUNT(*) FROM bl_booking WHERE room_id = :room_id AND status IN ('pending', 'confirmed') AND date_from < :date_to AND date_to > :date_from; 

Если COUNT > 0 — номер недоступен. Запрос оборачиваем в транзакцию с SELECT FOR UPDATE, чтобы исключить race condition. Шаги реализации:

1. Открыть транзакцию.
2. Выполнить SELECT FOR UPDATE по записи номера.
3. Проверить пересечения дат.
4. Если свободно — INSERT в bl_booking со статусом pending.
5. Commit транзакции.

При параллельных запросах второй запрос ждёт завершения первой транзакции, что гарантирует отсутствие двойных броней. Кастомная проверка на основе bl_booking отрабатывает в 5 раз быстрее, чем попытка реализовать аналогичную логику на стандартных инфоблоках.

Как обрабатывается таймаут оплаты?

После создания брони в pending запускается таймер. Если оплата не поступила за 15–30 минут, бронь переводится в expired и слот освобождается.

Реализация через агент:

function ReleasExpiredBookings(): string { $expiredIds = BookingTable::getList([ 'filter' => [ 'STATUS' => 'pending', '<=EXPIRES_AT' => new \Bitrix\Main\Type\DateTime(), ], 'select' => ['ID'], ])->fetchAll(); foreach ($expiredIds as $row) { BookingTable::update($row['ID'], ['STATUS' => 'expired']); } return __FUNCTION__ . '();'; } 

Регистрируется через CAgent::AddAgent() с интервалом 60 секунд.

Как устроен интерфейс выбора дат?

Календарь доступности строится на AJAX-запросе /bitrix/services/main/ajax.php?action=BookingModule:getAvailability. Бэкенд возвращает занятые даты. На фронте используем Flatpickr с разметкой недоступных дней.

AJAX-контроллер, наследник \Bitrix\Main\Engine\Controller:

class BookingController extends \Bitrix\Main\Engine\Controller { public function getAvailabilityAction(int $roomId, string $month): array { // возвращает занятые даты за месяц } } 

Кейс из нашей практики: сеть апарт-отелей (3 объекта, 47 номеров)

Задача: заменить ручное бронирование через звонки, исключить овербукинг.

Исходная ситуация: менеджеры вели Excel-таблицу, раз в неделю сверялись — периодически случались двойные брони, скандалы с гостями. Потери от овербукинга до внедрения составляли около 500 000 руб в год.

Реализованные решения:

• Инфоблок rooms с 47 элементами, каждый с галереей и свойствами (FLOOR, VIEW, BED_TYPE)
• Таблица bl_booking с индексом по диапазону дат
• AJAX-контроллер проверки доступности (отвечает за 80–120 мс)
• Интеграция с эквайрингом через модуль sale.payment: бронь переходит в confirmed по вебхуку от платёжного шлюза
• Агент освобождения истекших броней каждые 2 минуты
• Административный модуль с календарным представлением загрузки номеров

Результат: нулевые овербукинги за 14 месяцев работы, конверсия формы бронирования 4.2% (была 0% — всё шло через звонок). Затраты на разработку окупились за 2 месяца.

Процесс разработки

Сроки могут варьироваться в зависимости от сложности интеграций и количества объектов.

Сравнение подходов

Что включает разработка системы бронирования?

• Проектирование модели данных с учётом типов номеров и сезонных цен
• Разработка механизма проверки доступности с защитой от race condition
• Интерфейс выбора дат с визуализацией занятости
• Агент автоматического освобождения истекших броней
• Интеграция с модулем sale для выставления счёта и приёма оплаты
• Административный раздел управления бронированиями
• Настройка уведомлений для гостя и администратора (email/SMS)

Получите консультацию по вашему проекту. Закажите разработку системы бронирования под ключ — мы подготовим коммерческое предложение в течение 1 рабочего дня. Свяжитесь с нами для оценки сроков и стоимости разработки под ваши задачи.