Цены и скидки на 1С-Битрикс

Таблица b_catalog_price и как в ней не запутаться

Типичный кейс: маркетолог создал акцию «-20% на электронику», менеджер вручную поставил спеццену VIP-клиенту, а система лояльности насчитала ещё 10%. Итого покупатель видит -44% вместо запланированных -20%, товар уходит ниже себестоимости. Корень проблемы — неправильно настроенные приоритеты правил корзины в модуле sale и конфликт типов цен в 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 условия

Накопительные скидки

Программа лояльности

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

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

Реализация пороговой системы

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

Фишки:

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

Промокоды

Управление через 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

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

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

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

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

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

Сроки

Правильно настроенное ценообразование автоматизирует рутину и убирает человеческий фактор из расчёта скидок. Маржинальность остаётся под контролем — даже когда одновременно работают сотни правил на тысячи SKU.