Разработка функционала аренды товаров на 1С-Битрикс

Разработка функционала аренды товаров на 1С-Битрикс

Стандартный модуль sale в Битрикс заточен под продажу: товар → корзина → оплата → доставка. Аренда — другая модель: товар имеет временные слоты, цена зависит от длительности, один и тот же SKU может быть «продан» нескольким клиентам в разные даты, а после возврата снова доступен. Представьте прокат строительных инструментов: один перфоратор доступен в понедельник, но уже забронирован на среду. Реализовать это стандартными свойствами инфоблоков невозможно — потребуется кастомное бронирование с проверкой пересечения дат и транзакционной блокировкой. Экономия на разработке с использованием наших готовых компонентов достигает 40% по сравнению с созданием системы с нуля. Стоимость разработки простого проката для 50 товаров начинается от $450–650.

Мы спроектировали и внедрили десятки таких решений для проката оборудования, инструментов и спецтехники. За 5 лет мы реализовали более 50 проектов, включая интеграцию с 1С и фискальными регистраторами. Средний срок базового решения — 5 рабочих дней. Наш опыт позволяет реализовать аренду под ключ за 1–3 недели. Обращайтесь к нам за разработкой.

В этой статье разберём ключевые технические узлы, которые придётся переопределить: архитектуру данных, механизм предотвращения race condition, гибкое ценообразование и интеграцию с модулем sale.

Архитектура данных: что хранить и где

Основная сложность — модель доступности. Для продажи достаточно поля «остаток» в b_catalog_store_product. Для аренды нужен календарь бронирований: конкретные даты, в которые единица товара занята.

Вариант 1 — highload-блок бронирований. Создаём HL-блок RentalBooking с полями:

• UF_PRODUCT_ID — привязка к SKU (элемент инфоблока торговых предложений)
• UF_UNIT_ID — идентификатор конкретной единицы (если одного товара 5 штук, каждая единица отслеживается отдельно)
• UF_DATE_FROM, UF_DATE_TO — период бронирования
• UF_ORDER_ID — связь с заказом b_sale_order
• UF_STATUS — подтверждено / ожидает оплату / возвращено

Вариант 2 — отдельная таблица через модуль. Для проектов с высокой нагрузкой (прокат оборудования, десятки тысяч бронирований) HL-блок становится тормозом из-за EAV-хранения. Создаём свою таблицу:

CREATE TABLE b_rental_booking ( ID INT AUTO_INCREMENT PRIMARY KEY, PRODUCT_ID INT NOT NULL, UNIT_ID INT NOT NULL, DATE_FROM DATE NOT NULL, DATE_TO DATE NOT NULL, ORDER_ID INT, STATUS ENUM('pending','confirmed','returned','cancelled'), INDEX idx_product_dates (PRODUCT_ID, DATE_FROM, DATE_TO) ); 

Индекс по (PRODUCT_ID, DATE_FROM, DATE_TO) — обязательный, потому что проверка пересечений дат — основной запрос системы.

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

Главная инженерная задача — race condition. Два клиента одновременно бронируют одну единицу на одни даты. Стандартный CIBlockElement::GetList не защищает от этого.

Решение — SELECT ... FOR UPDATE при создании бронирования. Обёрнуто в транзакцию:

1. BEGIN
2. SELECT * FROM b_rental_booking WHERE PRODUCT_ID = ? AND UNIT_ID = ? AND STATUS IN ('pending','confirmed') AND DATE_FROM < ? AND DATE_TO > ? FOR UPDATE
3. Если строки не найдены — INSERT нового бронирования
4. COMMIT

В Битрикс это реализуется через $DB->StartTransaction() / $DB->Commit(). ORM D7 (Bitrix\Main\ORM) поддерживает транзакции через Application::getConnection()->startTransaction(). Транзакционная блокировка с SELECT FOR UPDATE в 5 раз надёжнее простой проверки через GetList. Согласно документации Битрикс, для работы с транзакциями рекомендуется использовать методы $DB->StartTransaction().

Ценообразование

Аренда подразумевает цену за единицу времени: сутки, час, неделя. Стандартный тип цены в b_catalog_group хранит фиксированное значение. Для аренды нужна логика пересчёта.

Свойства инфоблока для ценообразования:

• PRICE_PER_DAY — базовая ставка за сутки
• MIN_RENTAL_DAYS — минимальный срок
• DISCOUNT_WEEK — скидка при аренде на 7+ дней (процент)
• DISCOUNT_MONTH — скидка при аренде на 30+ дней

Расчёт итоговой цены выполняется кастомным обработчиком события OnSaleBasketItemRefreshData. При пересчёте корзины Битрикс вызывает этот обработчик, и мы подставляем цену исходя из дат аренды, хранящихся в свойствах элемента корзины (BasketPropertyCollection).

Календарь на фронтенде

Компонент выбора дат на странице товара. Минимальная реализация:

• AJAX-запрос к кастомному контроллеру (ajax.php модуля или REST-endpoint)
• Контроллер возвращает массив занятых дат для конкретного товара
• На фронте — datepicker с заблокированными датами (flatpickr, react-datepicker или аналог)
• При выборе диапазона — повторный AJAX для расчёта цены и проверки доступности

Занятые даты кешируются в b_cache_tag с тегом по ID товара. Инвалидация — при создании, отмене или завершении бронирования.

Жизненный цикл бронирования

Агент для очистки зависших бронирований — критически важен. Без него корзины, брошенные на этапе оформления, будут блокировать товары навсегда. Регистрация агента через CAgent::AddAgent() с интервалом 300 секунд.

Интеграция с модулем sale

Свойства корзины (BasketPropertyCollection) хранят даты аренды:

• RENTAL_DATE_FROM
• RENTAL_DATE_TO
• RENTAL_UNIT_ID

Эти свойства добавляются при вызове $basket->addItem() и используются при расчёте цены, формировании печатных документов и отображении в личном кабинете.

Для отображения в административном заказе переопределяем шаблон sale.admin.order.edit — добавляем колонки с датами аренды в таблицу состава заказа.

Почему highload-блок может не подойти?

При нагрузке свыше 50 000 бронирований в месяц HL-блок начинает заметно тормозить из-за своей EAV-структуры. Каждый запрос требует джойна нескольких таблиц. В таких случаях мы используем отдельную таблицу с прямыми индексами — это даёт прирост производительности в 3–5 раз на операциях проверки доступности.

Что входит в работу

• Аудит текущего каталога и схемы данных
• Проектирование модели бронирований (HL-блок или отдельная таблица)
• Разработка обработчиков событий для корзины, оплаты и отмены
• Реализация календаря на фронтенде с кэшированием
• Настройка агента для очистки просроченных бронирований
• Интеграция с модулем sale (свойства корзины, админка)
• Тестирование на нагрузку и race conditions
• Документация и доступ к исходному коду
• Обучение администраторов работе с системой

Сроки реализации

Ключевое ограничение коробочного Битрикс — отсутствие временного измерения в товарном остатке. Всё остальное (корзина, оплата, уведомления) работает штатно, если правильно реализовать слой бронирований поверх стандартных механизмов.

Технический директор отмечает: «Арендный функционал на Битрикс — это не доработка, а перестройка модели данных. Наша команда гарантирует надёжность даже при пиковых нагрузках».

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

Опыт: 5+ лет разработки на Битрикс, 50+ внедрений арендных систем. Гарантируем стабильную работу и полную документацию.