Послуги з налаштування цін та знижок на 1С-Бітрікс

Ціни та знижки на 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.