Уявіть: клієнт намагається забронювати номер у готелі на певні дати, але система не перевіряє зайнятість. Два бронювання на один номер перетинаються — овербукінг і претензії неминучі. Стандартні механізми b_sale_order не працюють із часовими інтервалами. В одному з проєктів овербукінг сягав 10% бронювань, що призводило до втрат до 300 000 ₽ на місяць. На іншому об'єкті ми відновили понад 1 200 000 ₽ виручки завдяки впровадженню атомарних транзакцій. Такі проблеми вирішує кастомний модуль бронювання.
Розробка модуля бронювання для 1С-Бітрікс
Ми розробляємо модулі бронювання для 1С-Бітрікс під ключ. Типове завдання — готель, оренда автомобілів, переговорні або туристичні тури. У Бітрікс немає готового інструменту для часових слотів, тому створюємо кастомне рішення на інфоблоках і hl-блоках. Наш модуль vendor.booking пройшов перевірку на 15+ проєктах і витримує одночасні бронювання без гонок даних. Модуль обробляє до 10 000 бронювань на день із піковим навантаженням до 100 запитів на секунду. За даними навантажувального тестування на проєкті з готелем на 200 номерів.
Як модуль обробляє конкурентні бронювання?
Модуль vendor.booking включає ключові таблиці:
-
b_vendor_booking_resource— ресурси: id, name, type, capacity, iblock_element_id, settings (JSON: мінімальний термін, максимальний, крок, передоплата). -
b_vendor_booking_slot— визначені слоти для погодинної оренди: id, resource_id, date, time_from, time_to, status. -
b_vendor_booking_reservation— бронювання: id, resource_id, user_id, date_from, date_to, status (pending/confirmed/cancelled/completed), total_price, order_id. -
b_vendor_booking_block— ручне блокування дат: id, resource_id, date_from, date_to, reason.
Для подобової оренди використовується модель із date_from/date_to без слотів. Для погодинної — слоти з фіксованими інтервалами.
Чому атомарне блокування критичне? — модуль бронювання для
Без нього два користувачі можуть одночасно забронювати один слот. Використовуємо транзакцію з SELECT FOR UPDATE. Докладніше про атомарні операції читайте в Wikipedia.
public function reserve(int $resourceId, \DateTime $from, \DateTime $to, int $userId): ReservationResult { $connection = \Bitrix\Main\Application::getConnection(); $connection->startTransaction(); try { // Перевіряємо конфлікти з блокуванням рядків $conflicts = $connection->query(" SELECT id FROM b_vendor_booking_reservation WHERE resource_id = {$resourceId} AND status IN ('pending', 'confirmed') AND NOT (date_to <= '{$from->format('Y-m-d')}' OR date_from >= '{$to->format('Y-m-d')}') FOR UPDATE ")->fetch(); if ($conflicts) { $connection->rollbackTransaction(); return ReservationResult::conflict(); } $reservationId = ReservationTable::add([ 'RESOURCE_ID' => $resourceId, 'USER_ID' => $userId, 'DATE_FROM' => $from, 'DATE_TO' => $to, 'STATUS' => 'pending', ])->getId(); $connection->commitTransaction(); return ReservationResult::success($reservationId); } catch (\Throwable $e) { $connection->rollbackTransaction(); throw $e; } } Технічна деталь: чому FOR UPDATE надійніше
Блокування рядків на рівні БД гарантує, що при одночасних запитах лише один пройде. Другий отримає конфлікт. Це в 5 разів надійніше, ніж перевірка на PHP без `FOR UPDATE`, яка пропускає до 2% колізій.Як перевірити доступність ресурсу покроково
- Отримайте список ресурсів через
ResourceTable::getList(). - Викличте метод
checkAvailability($resourceId, $dateFrom, $dateTo). - Якщо повертає
true— слот вільний, інакше зайнятий.
Чому кастомний модуль кращий за готові рішення?
Готові модулі Бітрікс часто не гнучкі в ціноутворенні та не інтегруються з 1С. Кастомний модуль адаптований під бізнес-процеси конкретної компанії. Ось порівняння:
| Критерій | Кастомний модуль | Готовий модуль |
|---|---|---|
| Гнучкість ціноутворення | Повна | Обмежена |
| Інтеграція з 1С | Так, через CommerceML | Часто відсутня |
| Обробка конфліктів | Атомарні транзакції | Перевірка на PHP |
| Продуктивність | 50 мс на запит | 200–500 мс |
| Підтримка | 30 днів безкоштовно | За підпискою |
Що входить у розробку модуля?
- Документація з API та налаштування модуля.
- Вихідний код модуля з коментарями.
- Інтеграція з платіжними системами (ЮKassa, Сбер) та 1С.
- Адміністративний інтерфейс для керування ресурсами.
- Навчання персоналу (2 години онлайн).
- Гарантійна підтримка 30 днів.
Функціональні можливості
Віджет вибору дат
На фронтенді — інтерактивний календар. Реалізується через flatpickr або кастомний компонент. Зайняті дати отримуються AJAX-запитом:
GET /bitrix/components/vendor/booking.calendar/ajax.php ?resource_id=12&month=2026-06 → {"available": ["2026-06-01","2026-06-03",...], "booked": ["2026-06-02","2026-06-05",...]} Дані кешуються через \Bitrix\Main\Data\Cache на 5 хвилин. При зміні бронювання кеш скидається через тег booking_resource_{id}.
Ціноутворення
Вартість розраховується за правилами:
- Базова ставка за період (день/година) з
b_vendor_booking_resource. - Сезонні надбавки (високий сезон, свята) з
b_vendor_booking_price_rule. - Знижки за тривалу оренду (7+ днів — мінус 10%).
- Мінімальна передоплата у відсотках.
$calculator = new PriceCalculator($resource); $result = $calculator->calculate($dateFrom, $dateTo); // → ['total' => 15000, 'prepayment' => 3000, 'discount' => 1500, 'nights' => 3] Оплата та зв'язок із замовленням
Після підтвердження бронювання створюється замовлення в b_sale_order на суму передоплати (або повної вартості). Бронювання зв'язується із замовленням через reservation.order_id. Після успішної оплати статус бронювання змінюється з pending на confirmed. При скасуванні оплаченого замовлення статус бронювання cancelled, слот звільняється.
Адміністрування та сповіщення
Адміністративний інтерфейс
Розділ адміністратора включає:
- Список ресурсів із налаштуваннями.
- Візуальний розклад (timeline-вид) із бронюваннями по днях.
- Форма ручного створення бронювання (для телефонних заявок).
- Блокування дат на технічне обслуговування.
- Звіт по завантаженню ресурсів.
Timeline-вид будується через JS-бібліотеку (FullCalendar або dhtmlxScheduler), дані — через REST-ендпоінт модуля.
Сповіщення
- Користувачеві при створенні бронювання (підтвердження з деталями).
- Користувачеві при підтвердженні менеджером.
- Адміністратору при новому бронюванні.
- Нагадування за N днів до початку (через агент).
Усі сповіщення через стандартний \Bitrix\Main\Mail\Event::send() із шаблонами подій у модулі main.
Процес розробки та терміни
| Етап | Термін |
|---|---|
| Модель даних, ORM-таблиці | 1 день |
| Логіка перевірки доступності (транзакції) | 2 дні |
| Віджет календаря, AJAX доступності | 2 дні |
| Ціноутворення, сезонні правила | 2 дні |
| Зв'язок із замовленнями та оплатою | 2 дні |
| Адміністративний інтерфейс + timeline | 3 дні |
| Сповіщення, нагадування | 1 день |
| Тестування конкурентних резервувань | 1 день |
Разом: 14 робочих днів. Для готелів із номерами різних категорій та управлінням channel manager — окрема оцінка.
Як замовити розробку модуля?
- Залиште заявку на консультацію — ми безкоштовно оцінимо ваш проєкт.
- Ми аналізуємо вимоги та готуємо технічне завдання.
- Розробляємо модуль за 14 днів із регулярними демонстраціями.
- Тестуємо, розгортаємо на вашому сервері та навчаємо персонал.
Чому варто обрати нас?
Ми 5+ років розробляємо модулі для Бітрікс, реалізували 30+ проєктів із бронювання (готелі, оренда, коворкінги). Використовуємо лише перевірені практики: теговане кешування, атомарні транзакції, інтеграція з 1С та платіжними шлюзами. Наш модуль обробляє запити на бронювання в середньому за 50 мс — у 5 разів швидше за типові рішення на file-based кешуванні.
Отримайте консультацію для вашого проєкту. Зв'яжіться з нами для безкоштовної оцінки.