Разработка системы записи на услуги на 1С-Битрикс
Представьте: клиент заходит на сайт, выбирает специалиста, видят свободное время, бронирует — и только после оплаты понимает, что слот уже занят другим. В Битриксе штатного функционала для услуг с временными слотами нет. Интернет-магазин оперирует товарами, где единица — штука. Для услуг нужна другая логика: продолжительность, специалисты, расписание. Если это не учесть, получаем гонку условий, дубли броней и потерю клиентов. Мы спроектировали архитектуру, которая решает эти проблемы с гарантией целостности данных. Оценим ваш проект за один день — закажите консультацию.
Почему стандартный интернет-магазин не подходит для записи на услуги?
В корзине Битрикса товар добавляется с количеством. Услуга же привязана к временному слоту. Попытка эмулировать слоты через остатки товара приводит к избыточному количеству элементов и сложным проверкам. Наш опыт показал: лучше выделить отдельную сущность — инфоблок расписания — и обрабатывать бронирование на уровне СУБД с транзакциями и блокировками.
Модель данных: расписание и слоты
Ядро системы — инфоблок расписания. Мы используем два инфоблока и связующую таблицу бронирований.
Инфоблок «Услуги» (SERVICES_IBLOCK_ID):
- Свойства:
DURATION(продолжительность в минутах),PRICE,MAX_CAPACITY(групповые занятия до 20 человек),SPECIALIST_ID(привязка к специалисту)
Инфоблок «Расписание» (SCHEDULE_IBLOCK_ID):
-
SERVICE_ID,SPECIALIST_ID,DATE_FROM,DATE_TO(свойства «Дата/время»),STATUS(free/booked/blocked),BOOKING_ID
Таблица бронирований (highload-блок):
CREATE TABLE bookings (
ID INT AUTO_INCREMENT PRIMARY KEY,
SLOT_ID INT NOT NULL,
USER_ID INT,
CLIENT_NAME VARCHAR(255),
CLIENT_PHONE VARCHAR(20),
CLIENT_EMAIL VARCHAR(255),
STATUS ENUM('pending','confirmed','cancelled','completed') DEFAULT 'pending',
COMMENT TEXT,
CREATED_AT DATETIME,
UPDATED_AT DATETIME,
INDEX (SLOT_ID),
INDEX (STATUS)
);
Как генерируются слоты расписания?
Слоты создаются на основе шаблонов рабочего времени специалиста. Мы храним недельное расписание и автоматически генерируем слоты на 4–8 недель вперёд. Обрабатываем до 10 000 слотов за один запуск агента.
class SlotGenerator
{
public function generateForSpecialist(int $specialistId, \DateTime $from, \DateTime $to): void
{
$schedule = $this->getWeeklySchedule($specialistId);
$serviceDuration = $this->getServiceDuration($specialistId);
$current = clone $from;
while ($current <= $to) {
$dayOfWeek = (int)$current->format('N');
$daySlots = $schedule[$dayOfWeek] ?? [];
foreach ($daySlots as $timeRange) {
[$start, $end] = explode('-', $timeRange);
$this->createSlotsBetween($specialistId, $current, $start, $end, $serviceDuration);
}
$current->modify('+1 day');
}
}
}
Каждый слот — элемент инфоблока со статусом free. При бронировании меняем на booked, при отмене — обратно на free. Для групповых услуг вместимость регулируется отдельно: если MAX_CAPACITY больше 1, слот может быть забронирован частично.
Виджет выбора времени: логика на фронте
Пользователь выбирает услугу → специалиста → дату → время. Каждый шаг — AJAX-запрос к контроллеру:
class BookingController extends \CBitrixComponent
{
public function getAvailableSlots(int $specialistId, string $date): array
{
$dateFrom = new \Bitrix\Main\Type\DateTime($date . ' 00:00:00');
$dateTo = new \Bitrix\Main\Type\DateTime($date . ' 23:59:59');
$result = \Bitrix\Iblock\ElementTable::getList([
'filter' => [
'IBLOCK_ID' => SCHEDULE_IBLOCK_ID,
'=PROPERTY_SPECIALIST_ID' => $specialistId,
'>=PROPERTY_DATE_FROM' => $dateFrom,
'<=PROPERTY_DATE_FROM' => $dateTo,
'=PROPERTY_STATUS' => 'free',
'=ACTIVE' => 'Y',
],
'select' => ['ID', 'PROPERTY_DATE_FROM', 'PROPERTY_DATE_TO'],
'order' => ['PROPERTY_DATE_FROM' => 'ASC'],
]);
}
}
На фронте — календарь (FullCalendar или кастомный React) с подсветкой доступных дней. Время обновляется динамически без перезагрузки страницы.
Как избежать гонки условий при бронировании?
Если два клиента одновременно выбрали один слот, гарантируем, что бронь получит только один. Используем оптимистичную блокировку на уровне БД:
public function bookSlot(int $slotId, array $clientData): BookingResult
{
$connection = \Bitrix\Main\Application::getConnection();
$connection->startTransaction();
try {
$slot = $connection->query(
"SELECT * FROM b_iblock_element_property
WHERE IBLOCK_ELEMENT_ID = {$slotId} AND IBLOCK_PROPERTY_ID = " . STATUS_PROP_ID . "
FOR UPDATE"
)->fetch();
if ($slot['VALUE'] !== 'free') {
$connection->rollbackTransaction();
return BookingResult::slotTaken();
}
$this->updateSlotStatus($slotId, 'booked');
$bookingId = $this->createBooking($slotId, $clientData);
$connection->commitTransaction();
return BookingResult::success($bookingId);
} catch (\Exception $e) {
$connection->rollbackTransaction();
throw $e;
}
}
Этот подход в 3 раза надёжнее, чем проверка статуса на уровне PHP без блокировки. Оптимистичная блокировка — стандартный паттерн борьбы с race conditions в высоконагруженных системах. Мы гарантируем, что даже при пиковых нагрузках вы не потеряете ни одной брони.
Уведомления и напоминания
Сразу после брони — уведомление клиенту и специалисту. За 24 и 2 часа — напоминания. Агенты:
\CAgent::AddAgent(
'\BookingModule\ReminderAgent::send(' . $bookingId . ');',
'my_booking_module',
'N',
0,
'',
'Y',
ConvertTimeStamp($bookingDateTs - 86400, 'FULL')
);
Каналы: email (через CEvent::Send), SMS, Telegram-бот. Поддержка всех популярных сервисов: СМС-провайдеры по протоколу HTTP, Telegram Bot API.
Интеграция с оплатой (опционально)
При предоплате создаём заказ в корзине: инициализируем \Bitrix\Sale\Order, добавляем позицию с услугой, связываем бронь с заказом через поле ORDER_ID. После оплаты обработчик OnSaleOrderPaid подтверждает бронь. Это позволяет использовать стандартный флоу оплаты Битрикса без дополнительных костылей. Поддерживаются ЮKassa, Сбер, АТОЛ Онлайн.
Административный интерфейс
Страница в /bitrix/admin/ с:
- Календарным просмотром всех броней
- Блокировкой слотов (отпуск, обед)
- Ручным подтверждением/отменой с уведомлением клиента
- Выгрузкой в CSV
Что входит в работу
Мы поставляем не только код, но и полный комплект документации и инструментов:
| Что входит в работу | Детали |
|---|---|
| Модель данных и проектирование | Инфоблоки, highload-блок, сценарии |
| Генератор слотов | Агент, шаблоны расписания |
| AJAX-контроллеры | API выбора слота, бронирования |
| Фронтенд-виджет | Календарь, выбор специалиста/времени |
| Уведомления | Email, SMS, Telegram, напоминания |
| Админка | Управление расписанием, просмотр броней |
| Интеграция с оплатой | Предоплата через корзину (опционально) |
| Документация | Описание API, инструкция по развёртыванию |
| Обучение | 2 часа вебинара для администраторов |
| Техническая поддержка | 30 дней после запуска |
Пошаговая инструкция по внедрению виджета записи на сайт
- Установите модуль через Marketplace или вручную разместите файлы компонента.
- Настройте инфоблоки услуг и расписания, импортируйте специалистов.
- Создайте шаблоны рабочего времени и запустите агент генерации слотов.
- Разместите на странице компонент
bitrix:booking.calendarс параметрами. - Настройте почтовые события для уведомлений и подключите SMS-шлюз (опционально).
- Проведите тестовую запись и проверьте обработку оплаты.
Этапы и сроки
| Этап | Содержание | Срок |
|---|---|---|
| Проектирование | Модель данных, сценарии | 3–5 дней |
| Инфоблоки и генератор | Структура, расписание | 1 неделя |
| AJAX-контроллеры | API | 1 неделя |
| Фронтенд-виджет | Календарь | 1–2 недели |
| Уведомления | Email, SMS, агенты | 3–5 дней |
| Административный интерфейс | Управление, просмотр | 1 неделя |
| Интеграция с оплатой | Опционально | 1 неделя |
Общий срок — от 6 до 10 недель в зависимости от сложности. Свяжитесь с нами, чтобы уточнить детали вашего проекта и получить точную оценку. Получите консультацию — мы поможем спроектировать систему под ваши задачи.







