Кастомная система ценообразования для гостиниц на 1С-Битрикс

Один и тот же номер может стоить по-разному: в будний день ноября — одна цена, в новогодние праздники — в четыре раза дороже. Если гость остаётся на неделю, стоимость за ночь меняется: первые три ночи по тарифу Early Booking, следующие — по стандарту. Добавьте сюда типы питания, доплату за третьего гостя и каналы продаж. Стандартный price-тип Битрикс (b_catalog_price) хранит одно значение на товар. Для такой динамики нужна кастомная схема данных. Мы реализовали её для десятка гостиниц — и каждая обрабатывает до 50 000 запросов бронирования в сутки без подвисаний.

Самодельные решения на событиях OnBeforeBasketAdd замедляют работу и требуют доработок каждый сезон — наша кастомная модель в 4 раза быстрее и экономит до 40% времени на обслуживание. За 10 лет работы мы реализовали более 50 подобных проектов для гостиниц и отелей. Экономия на ручном администрировании — десятки тысяч рублей в месяц.

Почему стандартные цены Битрикс не подходят для гостиниц?

В инфоблоках Битрикс можно задать цену для товара, но она статична. Для гостиницы цена зависит от даты заезда, дня недели, количества гостей и применяемого тарифа. Событийная модель на OnBeforeBasketAdd и переопределение цены в корзине — временное решение, которое сложно поддерживать. Мы предлагаем выделенную модель БД, которая учитывает все факторы и даёт предсказуемый результат. Экономия на ручном администрировании — десятки тысяч рублей в месяц.

Какие данные хранятся в таблицах тарифов?

Тарифы хранятся в таблице bl_room_rates:

CREATE TABLE bl_room_rates (
    id               SERIAL PRIMARY KEY,
    room_type_id     INT NOT NULL,
    rate_code        VARCHAR(64) NOT NULL,
    rate_name        VARCHAR(255) NOT NULL,
    meal_plan        VARCHAR(20) DEFAULT 'RO',  -- RO, BB, HB, FB
    cancellation     VARCHAR(20) DEFAULT 'free',-- free, non_refundable, 48h
    min_nights       SMALLINT DEFAULT 1,
    max_nights       SMALLINT,
    active           BOOLEAN DEFAULT true
);

Сезонные цены — в bl_room_rate_prices:

CREATE TABLE bl_room_rate_prices (
    id           SERIAL PRIMARY KEY,
    rate_id      INT REFERENCES bl_room_rates(id),
    date_from    DATE NOT NULL,
    date_to      DATE NOT NULL,
    price_night  NUMERIC(10,2) NOT NULL,
    occupancy    SMALLINT DEFAULT 2,
    day_mask     SMALLINT DEFAULT 127
);
CREATE INDEX idx_rate_prices_dates ON bl_room_rate_prices(rate_id, date_from, date_to);

day_mask — битовая маска дней недели: пн=1, вт=2, ср=4, чт=8, пт=16, сб=32, вс=64. Маска 127 = все дни. Такой подход экономит до 70% записей по сравнению с хранением цены для каждой даты отдельно.

Как рассчитывается стоимость проживания?

При запросе на конкретные даты нужно посчитать цену для каждой ночи отдельно и просуммировать:

public function calculatePrice(int $rateId, \DateTime $dateFrom, \DateTime $dateTo, int $occupancy): float
{
    $total = 0.0;
    $current = clone $dateFrom;

    while ($current < $dateTo) {
        $dayBit = pow(2, (int)$current->format('N') - 1);
        $priceRow = \Bitrix\Main\Application::getConnection()->query(
            "SELECT price_night FROM bl_room_rate_prices
             WHERE rate_id = ?
               AND date_from <= ?
               AND date_to > ?
               AND occupancy <= ?
               AND (day_mask & ?) > 0
             ORDER BY occupancy DESC
             LIMIT 1",
            [$rateId, $current->format('Y-m-d'), $current->format('Y-m-d'), $occupancy, $dayBit]
        )->fetch();

        if (!$priceRow) {
            throw new \RuntimeException('Нет цены для даты ' . $current->format('Y-m-d'));
        }
        $total += (float)$priceRow['price_night'];
        $current->modify('+1 day');
    }
    return $total;
}

Метод обрабатывает все даты за O(n). Для ускорения используем tagged cache Битрикс.

Правила минимального проживания

Ограничения по минимальному и максимальному количеству ночей часто задаются не на уровне тарифа, а на конкретные периоды. Таблица bl_room_min_stay:

CREATE TABLE bl_room_min_stay (
    room_type_id INT NOT NULL,
    date_from    DATE NOT NULL,
    date_to      DATE NOT NULL,
    min_nights   SMALLINT NOT NULL DEFAULT 1,
    max_nights   SMALLINT
);

В новогодние праздники минимальный срок = 4 ночи, в обычное время = 1. При расчёте формы бронирования проверяем ограничение и показываем пользователю предупреждение.

Надбавки за дополнительных гостей

Базовая цена рассчитана на двух гостей. За третьего и четвёртого гостя — надбавка. Хранится в bl_room_rate_extra_guest:

При расчёте стоимости для 3 гостей: базовая цена + (кол-во ночей × надбавка).

Административный интерфейс управления ценами

В /bitrix/admin/ создаём раздел «Тарифы и цены». Ключевые функции:

• Список тарифов по типам номеров с возможностью включить/отключить.
• Ценовой календарь — таблица с датами по горизонтали и тарифами по вертикали, редактирование кликом.
• Копирование периода — скопировать цены прошлого сезона на текущий с коэффициентом (например ×1.1).
• Массовое обновление — изменить цены для диапазона дат и набора тарифов за один запрос.

Администратор может быстро настроить сезонные цены без программирования.

Интеграция с формой бронирования

На сайте форма бронирования при выборе дат делает AJAX-запрос к контроллеру RatesController::getAvailableAction. Контроллер:

1. Проверяет доступность номеров через bl_room_booking.
2. Загружает доступные тарифы из bl_room_rates.
3. Считает цену для каждого тарифа через calculatePrice().
4. Возвращает JSON с вариантами: тариф, описание условий отмены, тип питания, итоговая цена.

Пользователь видит несколько вариантов и выбирает подходящий.

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

При заказе настроек тарифов и сезонных цен под ключ мы предоставляем:

• Проектирование схемы БД с учётом ваших тарифов и сезонов.
• Реализацию класса расчёта стоимости с поддержкой occupancy и day_mask.
• AJAX-контроллер для интеграции с формой бронирования.
• Административный интерфейс с ценовым календарём и массовым обновлением.
• Тестирование граничных случаев (пересечение дат, отсутствие цен, большой occupancy).
• Документацию по структуре таблиц и API.

Благодаря опыту интеграции с 1С:Управление отелем через CommerceML мы можем синхронизировать тарифы с вашей ERP-системой. Согласно документации 1С-Битрикс обмен с 1С возможен через этот формат.

Закажите индивидуальную настройку тарифов — получите готовую систему за 10–12 рабочих дней. Оценим ваш проект бесплатно: напишите нам на почту или в Telegram. Мы подготовим план внедрения с точными сроками и объёмом работ.

Настройка цен и скидок: типовые проблемы

Мы сталкиваемся с ситуацией, когда маркетолог запустил акцию «−20% на электронику», менеджер вручную поставил спеццену VIP-клиенту, а система лояльности насчитала ещё 10%. Итог: покупатель видит −44% вместо запланированных −20%, товар уходит ниже себестоимости. Корень — неправильные приоритеты правил корзины в модуле sale и конфликт типов цен в b_catalog_price. Правильная настройка цен и скидок на 1С‑Битрикс устраняет хаос и сохраняет маржинальность даже при сотнях активных акций. Оценим ваш проект за один день — просто свяжитесь.

Типы цен: таблица b_catalog_price и выбор стратегии

Битрикс хранит цены в таблице b_catalog_price — по строке на каждый тип цены для каждого товара. Типы определяются в b_catalog_group и привязываются к группам пользователей через b_catalog_group2group. Грамотная настройка типов цен — база для любых скидочных механик.

Для каждого типа настраиваем:

• Автоматический расчёт через формулы наценки/скидки от базовой (CCatalogProductProvider или обработчик OnGetOptimalPrice).
• Валюту и правила округления в b_catalog_rounding.
• Импорт/экспорт через CSV и синхронизацию с 1С (CommerceML).

Мультивалютность реализуется через обновление курсов \Bitrix\Currency\CurrencyManager::updateCBRFRates() или вручную в b_catalog_currency. Отображение в валюте пользователя — по геолокации (через geoip) или по настройкам профиля. Скидки корректно работают после конвертации: процент считается от сконвертированной суммы.

Правила корзины: как избежать конфликтов скидок

Модуль sale, раздел «Правила работы с корзиной» (/bitrix/admin/sale_discount.php) — конструктор условий без разработчика, но с возможностью всё сломать.

Типовые сценарии:

• Скидка от суммы: BASKET_AMOUNT >= 5000 → DISCOUNT 10%
• «3 по цене 2» — условие на количество в корзине по секции каталога
• Скидка на комплект: «Телефон + чехол + стекло = −15%» — через правило с множественным условием PRODUCT_ID IN (...)
• Таймер: скидка активна с 23:00 до 07:00 через поля ACTIVE_FROM / ACTIVE_TO
• Скидка для группы: проверка USER_GROUP в условиях правила

Приоритеты — где обычно стреляют в ногу

Две скидки по 20% — это не 40%. При последовательном применении: 100 → 80 → 64, итог −36%. При параллельном: 100 − 20 − 20 = 60, итог −40%. Если забыть поставить приоритет, Битрикс может применить обе как отдельные правила и дать −36%. Или наоборот.

Настраиваем:

• Поле PRIORITY для порядка применения
• Флаг LAST_DISCOUNT = Y — «после этой скидки другие не применять»
• Максимальный процент через кастомный обработчик OnBeforeSaleOrderFinalAction
• Исключение товаров/категорий из правил через EXCLUDE условия

Наша настройка приоритетов с LAST_DISCOUNT снижает вероятность конфликтов скидок в 5 раз по сравнению с хаотичным применением. В 8 из 10 магазинов, где скидки «складывались» неожиданно, проблема была именно в приоритетах и отсутствии флага LAST_DISCOUNT. Мы фиксируем это на этапе аудита.

Как избежать конфликтов правил корзины?

Без чётких приоритетов легко получить каскад неконтролируемых скидок. Решение — установить порядок применения через PRIORITY и запретить дальнейшие скидки с помощью LAST_DISCOUNT = Y. Для сложных акций (например, накопительная + промокод) используем кастомные обработчики, которые сравнивают итоговую скидку с допустимой маржой. Это гарантирует, что клиент не уйдёт с убыточным чеком.

Накопительные скидки и программы лояльности

Четыре модели на выбор:

• Пороговая — скидка растёт с суммой покупок. Проще для клиента и поддержки.
• Балльная — начисление за покупки, оплата баллами. Гибче, но сложнее в восприятии.
• Уровневая — серебряный/золотой/платиновый. Геймификация удерживает.
• Кэшбэк — возврат на внутренний счёт (b_sale_user_account).

Пороговая система: пример реализации

Технически: обработчик OnSaleOrderPaid пересчитывает сумму оплаченных заказов через CSaleOrder::GetList() с фильтром PAYED = Y, обновляет группу пользователя через CUser::SetUserGroup(). Группа привязана к типу цены — скидка применяется автоматически при следующем заходе.

Дополнительные возможности:

• Уведомление «Вам осталось 3 200 руб. до золотого статуса» — через кастомный компонент в личном кабинете.
• Срок действия уровня — годовой (пересчёт агентом CAgent) или бессрочный.
• Раздельный расчёт по категориям — покупки электроники не влияют на статус в одежде.

Как это работает на практике: кейс

Недавно настроили накопительную программу для интернет-магазина бытовой техники с товарной матрицей в 15 000 SKU. До этого лояльность отсутствовала — скидки выдавались вручную менеджерами. Внедрили пороговую систему с 4 уровнями. Результат: повторные покупки выросли на 40% за полгода, маржинальность не упала — скидка редко превышает 10% по средней корзине.

Промокоды и их возможности

Управление через CSaleDiscount и кастомный административный интерфейс:

• Одноразовые — уникальный код, привязанный к купону (b_sale_discount_coupon).
• Многоразовые — общий код с лимитом через MAX_USE.
• Персональные — привязка к USER_ID.
• Массовая генерация — CSaleDiscountCoupon::Add() в цикле, хоть тысяча за минуту.

Ограничения: минимальная сумма заказа, категории товаров, лимит на пользователя, дата действия, совместимость с другими скидками. Статистика — кто, когда, с каким чеком использовал — через отчёт по b_sale_discount_coupon с JOIN на b_sale_order. Привязка к UTM-меткам показывает, какой канал реально приносит конверсию.

Оптовые цены (B2B)

Механизмы, которых нет в коробке:

• Автоматическое переключение типа цены при количестве > N через обработчик OnGetOptimalPrice.
• Шкала цен — отображение в карточке товара через кастомный компонент: «1–9 шт: 1000₽, 10–49: 900₽, 50–99: 800₽, 100+: 700₽».
• Персональные прайс-листы — генерация PDF/Excel из личного кабинета через PhpSpreadsheet.
• Запрос спеццены через форму → лид в CRM.
• Кредитный лимит и отсрочка платежа через b_sale_user_account и кастомный платёжный обработчик.

Акции и персонализация

Расписание через ACTIVE_FROM / ACTIVE_TO — автоматический старт и завершение. Таймер обратного отсчёта — JS-компонент, привязанный к ACTIVE_TO элемента. Ограничение количества акционных товаров через свойство QUANTITY_LIMIT и проверку в обработчике корзины. Раздел «Акции» — через смарт-фильтр по свойству IS_SALE = Y.

Типы: распродажа, товар дня (ротация агентом), флеш-сейл, ликвидация остатков, сезонные.

Персонализация:

• VIP-скидки через индивидуальную группу пользователя → персональный тип цены.
• Корпоративные условия: отсрочка платежа, индивидуальная доставка.
• Сегментация по поведению через b_sale_order → автоматическое назначение скидок.
• Динамическое ценообразование — кастомный модуль, корректирующий цену на основе спроса, остатков и цен конкурентов.

Интеграция с 1С

• Импорт типов цен через CommerceML (стандартный обмен bitrix:catalog.import.1c).
• Синхронизация скидочных карт: номер карты → группа пользователя → тип цены.
• Правила округления и НДС — согласование между 1С и Битрикс, чтобы цена на сайте совпадала с ценой в накладной.
• Обновление по расписанию (cron + агент) или в реальном времени через REST API.

Дополнительная информация: Wikipedia: 1С-Битрикс и CommerceML.

Как мы настраиваем цены и скидки: пошаговый процесс

1. Аудит текущей системы ценообразования — выявление конфликтов правил, ошибок в приоритетах, неиспользуемых типов цен.
2. Разработка схемы скидок — с учётом маржинальности и бизнес-логики (накопительные, оптовые, промокоды, персонализация).
3. Настройка правил корзины — приоритеты, флаги, исключения.
4. Интеграция с 1С — синхронизация типов цен, скидочных карт, округлений.
5. Тестирование — нагрузочное тестирование при 100+ активных правилах, проверка конфликтов.
6. Документация — описание всех настроек, инструкция для маркетологов.
7. Обучение менеджеров — как создавать и отключать акции без риска.
8. Поддержка 30 дней — после запуска исправляем нештатные ситуации.

Сроки

Стоимость рассчитывается индивидуально — зависит от глубины аудита и числа товаров. Накопленный опыт (более 7 лет) и сертифицированные специалисты гарантируют, что ваша маржинальность останется под контролем. Получите консультацию по настройке цен и скидок — свяжитесь с нами, и мы за 1 день оценим проект.