Налаштування автокорекції цін у 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, ОФД і системами трекінгу конкурентів. Гарантуємо прозорість коду та повну документацію.

Бажаєте виключити ручний моніторинг і отримувати актуальні ціни автоматично? Зв'яжіться з нами — оцінимо ваш проєкт за один робочий день. Отримайте консультацію з налаштування репрайсингу для вашого каталогу.

Ціни та знижки: коли акція дає −44% замість −20%

У нашій практиці поширена ситуація: маркетолог запустив акцію «−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) — конструктор умов без розробника, але з можливістю все зламати.

«Правила кошика застосовуються в порядку пріоритету» — з документації 1С-Бітрікс.

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

• Знижка від суми: 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. Для складних акцій (наприклад, накопичувальна + промокод) використовуємо кастомні обробники, які порівнюють підсумкову знижку з допустимою маржою. Це гарантує, що клієнт не піде зі збитковим чеком. Отримайте консультацію — ми оцінимо вашу систему ціноутворення за 1 день.

Накопичувальні знижки та програми лояльності

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

• Порогова — знижка зростає із сумою покупок. Простіше для клієнта та підтримки.
• Бальна — нарахування за покупки, оплата балами. Гнучкіше, але складніше у сприйнятті.
• Рівнева — срібний/золотий/платиновий. Гейміфікація утримує.
• Кешбек — повернення на внутрішній рахунок (b_sale_user_account).

Порогова система: приклад реалізації

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

Додаткові можливості:

• Повідомлення «Вам залишилося 3 200 руб. до золотого статусу» — через кастомний компонент в особистому кабінеті.
• Термін дії рівня — річний (перерахунок агентом CAgent) або безстроковий.
• Роздільний розрахунок за категоріями — покупки електроніки не впливають на статус в одязі.

Кейс з нашої практики: побутова техніка, 15 000 SKU

Ми налаштували накопичувальну програму для нашого клієнта — інтернет-магазину побутової техніки з товарною матрицею в 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.

Як ми налаштовуємо ціни та знижки: покроковий процес

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

Що входить у роботу

• Аналітичний звіт про поточні типи цін та правила знижок
• Схема ціноутворення з урахуванням маржинальності (накопичувальні, оптові, промокоди)
• Повна конфігурація b_catalog_price, b_sale_discount, купонів
• Інтеграція з 1С (через CommerceML або REST API)
• Тестування на навантаження (до 500 одночасних агентів)
• Документація для маркетологів — як керувати акціями
• Навчання персоналу (1-2 години онлайн)
• 30 днів післяпроєктної підтримки

Строки

Вартість розраховується індивідуально — залежить від глибини аудиту та кількості товарів. Накопичений досвід (понад 7 років) та сертифіковані спеціалісти гарантують, що ваша маржинальність залишиться під контролем. Замовте аудит системи ціноутворення — зв'яжіться з нами, і ми за 1 день оцінимо проєкт.