Настройка автоматической корректировки цен по конкурентам 1С-Битрикс

Настройка автоматической корректировки цен по конкурентам 1С-Битрикс

Мы настраиваем автоматическую корректировку цен в 1С-Битрикс — систему, которая сама меняет цены товаров при изменении цен конкурентов. Без правил такая система быстро приводит к ценовым войнам: магазин снижает цену, конкурент отвечает, и через несколько часов оба торгуют в убыток. Чтобы этого избежать, мы проектируем гибкие правила с полом, потолком и приоритетами. Работаем под ключ — от модели данных до агента и админ-интерфейса. Сроки — 11–13 дней, в зависимости от объёма каталога. За 5 лет мы реализовали более 50 проектов по автоматизации ценообразования в 1С-Битрикс. Имеем сертификацию «1С-Битрикс: Разработчик» и опыт интеграции с CommerceML, ОФД и системами трекинга конкурентов.

Почему нужна защита от ценовых войн?

Автокорректировка без защиты — прямой путь к демпингу. Конкуренты могут выставлять акционные цены на 15–20 минут, и ваш магазин бездумно копирует их. Мы реализуем четыре механизма защиты: cooldown (пауза между изменениями), лимит дневного изменения (не более X% за сутки), верификация конкурента (не реагировать на акции короче 30 минут) и блокировка по минимальной марже. Например, для каталога электроники с 10 000 товаров эти механизмы снижают количество ошибочных срабатываний на 70%.

По данным официальной документации 1С-Битрикс, механизм агентов позволяет выполнять фоновые задачи без участия пользователя.

Как мы проектируем модель правил

Правила хранятся в таблице bl_repricing_rules. Каждое правило определяет стратегию (beat_min, match_min, avg, position), границы (пол и потолок) и список конкурентов. Выбор стратегии зависит от маржинальности товара и целей магазина.

CREATE TABLE bl_repricing_rules (
    id              SERIAL PRIMARY KEY,
    name            VARCHAR(255) NOT NULL,
    scope_type      VARCHAR(20) NOT NULL,       -- 'product', 'section', 'all'
    scope_id        INT,                        -- ID товара или раздела
    strategy        VARCHAR(30) NOT NULL,       -- 'beat_min', 'match_min', 'avg', 'position'
    value           NUMERIC(8,4),               -- для beat_min: -50 (руб) или -0.05 (5%)
    value_type      VARCHAR(10) DEFAULT 'abs',  -- 'abs' | 'pct'
    floor_type      VARCHAR(10) DEFAULT 'margin', -- 'margin' | 'abs' | 'cost_pct'
    floor_value     NUMERIC(8,4),               -- минимальная маржа или абс. порог
    ceiling_type    VARCHAR(10) DEFAULT 'abs',
    ceiling_value   NUMERIC(12,2),              -- не выше этой цены
    competitor_ids  INT[],                      -- NULL = все конкуренты
    priority        SMALLINT DEFAULT 10,
    active          BOOLEAN DEFAULT true
);

Движок расчёта новой цены

Движок RepricingEngine получает применимое правило для товара, собирает цены конкурентов и вычисляет целевое значение. Затем применяет ограничения (пол и потолок) и округляет до маркетингово привлекательного формата (оканчивается на 0 или 9 копеек). Если новая цена отличается от текущей менее чем на 1 копейку, изменение не происходит — это предотвращает микроколебания.

Автоматический репрайсинг в 5 раз быстрее ручного изменения цен — система обрабатывает до 10 000 товаров за один запуск агента.

class RepricingEngine
{
    public function calculate(int $productId): ?array
    {
        $rule = $this->getApplicableRule($productId);
        if (!$rule) return null;

        $competitorPrices = $this->getCompetitorPrices($productId, $rule['competitor_ids']);
        if (empty($competitorPrices)) return null;

        $targetPrice = match($rule['strategy']) {
            'beat_min'  => $this->beatMin($competitorPrices, $rule),
            'match_min' => min($competitorPrices),
            'avg'       => array_sum($competitorPrices) / count($competitorPrices),
            'position'  => $this->targetPosition($competitorPrices, $rule['value']),
            default     => null,
        };

        if ($targetPrice === null) return null;

        // Применяем ограничения
        $floor   = $this->calcFloor($productId, $rule);
        $ceiling = (float)$rule['ceiling_value'];

        $finalPrice = max($targetPrice, $floor);
        if ($ceiling > 0) $finalPrice = min($finalPrice, $ceiling);

        // Округление до 0 или 9 в копейках
        $finalPrice = $this->roundPrice($finalPrice);

        $currentPrice = $this->getCurrentPrice($productId);
        if (abs($finalPrice - $currentPrice) < 0.01) return null; // Нет изменений

        return [
            'product_id'    => $productId,
            'current_price' => $currentPrice,
            'new_price'     => $finalPrice,
            'rule_id'       => $rule['id'],
            'reason'        => $rule['strategy'],
            'competitor_min'=> min($competitorPrices),
        ];
    }

    private function beatMin(array $prices, array $rule): float
    {
        $min = min($prices);
        return $rule['value_type'] === 'pct'
            ? $min * (1 + $rule['value'] / 100)
            : $min + $rule['value'];
    }

    private function calcFloor(int $productId, array $rule): float
    {
        if ($rule['floor_type'] === 'margin') {
            $cost = $this->getCostPrice($productId);
            return $cost > 0 ? $cost * (1 + $rule['floor_value'] / 100) : 0;
        }
        return (float)$rule['floor_value'];
    }
}

Как применяется цена в Битрикс?

Класс RepricingApplicator логирует изменение до обновления цены через CCatalogProduct::SetPrice. Если что-то пошло не так — статус в логе меняется на error, менеджер получает уведомление. Мы используем REST API для интеграции с внешними системами, если требуется получить цены от партнёров.

class RepricingApplicator
{
    public function apply(array $change): void
    {
        // Логируем ДО изменения
        RepricingLogTable::add([
            'PRODUCT_ID'    => $change['product_id'],
            'RULE_ID'       => $change['rule_id'],
            'OLD_PRICE'     => $change['current_price'],
            'NEW_PRICE'     => $change['new_price'],
            'REASON'        => $change['reason'],
            'APPLIED_AT'    => new \Bitrix\Main\Type\DateTime(),
        ]);

        // Обновляем цену
        $priceResult = \CCatalogProduct::SetPrice(
            $change['product_id'],
            BASE_PRICE_TYPE_ID,
            $change['new_price'],
            'RUB'
        );

        if (!$priceResult) {
            // Откат и уведомление об ошибке
            RepricingLogTable::update($logId, ['STATUS' => 'error']);
        }
    }
}

Как работает агент репрайсинга?

Агент запускается раз в час. Он собирает товары, у которых за последний час обновились цены конкурентов, прогоняет через движок и применяет изменения (или ставит на одобрение, если раздел в режиме manual). Конфигурация гибкая — для каждого раздела каталога можно задать свой режим.

Что входит в настройку

В результат входит: документация схемы БД, код движка и агента, админ-интерфейс, инструкция по эксплуатации, 1 месяц поддержки после запуска.

Почему доверяют нам

За 5 лет мы реализовали более 50 проектов по автоматизации ценообразования в 1С-Битрикс. Имеем сертификацию «1С-Битрикс: Разработчик» и опыт интеграции с CommerceML, ОФД и системами трекинга конкурентов. Гарантируем прозрачность кода и полную документацию.

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

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

Мы сталкиваемся с ситуацией, когда маркетолог запустил акцию «−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 день оценим проект.