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

Овербукинг — головная боль любого отельного бизнеса. Когда два гостя одновременно бронируют последний номер, стандартный Битрикс не может гарантировать, что не возникнет двойной записи. Потери от таких конфликтов могут достигать $4.5k–6.5k в год для небольшой сети. Мы разработали кастомную систему бронирования на 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-таблицу, раз в неделю сверялись — периодически случались двойные брони, скандалы с гостями. Потери от овербукинга до внедрения составляли около $4.5k–6.5k в год.

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

• Инфоблок 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 рабочего дня. Свяжитесь с нами для оценки сроков и стоимости разработки под ваши задачи.