Налаштування округлення цін в 1С-Бітрікс: точність і маркетинг
Ми часто стикаємося з ситуацією: клієнт оновлює 1С, а на сайті з'являється ціна 324,57 гривні для товару за 349 гривень зі знижкою 7%. Менеджери скаржаться на «негарні» ціни, бухгалтерія — на розбіжності з 1С. Округлення цін в Бітріксі — точка, де математично коректний результат перетворюється на артефакт, якщо не налаштувати правила правильно. Наш досвід показує: правильно налаштовані правила округлення економлять години узгоджень і підвищують довіру клієнтів. В одному з проектів з каталогом із 50 000 товарів і трьома типами цін ручне коригування займало до 3 годин на день — після автоматизації округлення проблема зникла за 4 години. Наш підхід скорочує час налаштування правил у 3 рази порівняно з типовими рішеннями.
За 10+ років ми виконали понад 200 проектів по Бітрікс, сертифіковані як «1С-Бітрікс: Розробник». Кожне рішення тестується на копії сайту перед деплоєм.
Докладніше про психологію цін — у Wikipedia
Де налаштовується округлення?
Налаштування → Налаштування продуктів → Каталог → Округлення цін. У ранніх версіях — у налаштуваннях компонента bitrix:catalog.element та bitrix:catalog.section параметри PRICE_VAT_INCLUDE та окремі округлення.
Глобальні правила округлення — CCatalogProduct::getRoundRules() читає з b_catalog_rounding_rule. Таблиця проста: ID типу ціни, діапазон, тип і точність. Але в проектах з десятками типів цін і складною знижковою логікою ручне налаштування через адмінку перетворюється на пекло. Ми пишемо скрипти міграцій через \Bitrix\Catalog\RoundingTable.
Які типи правил округлення підтримує Бітрікс?
| Правило | Опис | Приклад |
|---|---|---|
| Математичне | Стандартне: 0.5 → вгору | 324.57 → 325 |
| Завжди вниз | floor() |
324.57 → 324 |
| Завжди вгору | ceil() |
324.01 → 325 |
| До потрібного знака | Точність у налаштуваннях | 324.57 → 320 або 324.6 |
Математичне округлення — базовий вибір для бухгалтерії, але воно не дає «гарних» цін для вітрини. Округлення вниз часто використовують у маркетингу: ціна 324 замість 324.57 виглядає привабливіше. Округлення вгору — рідко, коли потрібно уникнути збитку на копійках.
Як ми налаштовуємо округлення: реальний кейс
В одному проекті з каталогом із 50 000 товарів і трьома типами цін (роздріб, опт, дрібний опт) стояло завдання: для роздробу округлювати до цілих вниз, для опту — до десятків вгору, для дрібного опту — математично до 0.1. Плюс для цін від 10 000 гривень — своє правило. Ми написали скрипт на PHP 8.1 з використанням \Bitrix\Catalog\RoundingTable::add() та міграцію через Yurii\BitrixModels\Migration. Весь процес зайняв 4 години, включаючи тестування на копії. Після деплою розбіжності з 1С зникли, менеджери перестали правити ціни вручну.
// Додавання правила округлення \Bitrix\Catalog\RoundingTable::add([ 'CATALOG_GROUP_ID' => $priceTypeId, // 0 = всі типи цін 'PRICE_FROM' => 0, 'PRICE_TO' => 999.99, 'ROUND_TYPE' => \Bitrix\Catalog\RoundingTable::ROUND_MATH, 'ROUND_PRECISION' => 0, // до цілих ]); // Для цін від 1000 — інше правило \Bitrix\Catalog\RoundingTable::add([ 'CATALOG_GROUP_ID' => $priceTypeId, 'PRICE_FROM' => 1000, 'PRICE_TO' => null, 'ROUND_TYPE' => \Bitrix\Catalog\RoundingTable::ROUND_MATH, 'ROUND_PRECISION' => -1, // до десятків ]); ROUND_PRECISION — кількість знаків після коми (від'ємні значення округлюють до десятків, сотень). Важливо: якщо у вас типи цін з ПДВ, округлення застосовується до додавання податку. Це стандартна поведінка, але часто викликає питання.
Чому округлення в кошику відрізняється від вітрини?
Правила округлення застосовуються при обчисленні підсумкової ціни через CCatalogProduct::GetOptimalPrice(). У компоненті кошика — при перерахунку суми рядка. Але знижки, купони та ПДВ можуть спотворити результат. Наприклад: на вітрині ціна з ПДВ — 1200 грн., без ПДВ — 1000 грн. У кошику при застосуванні знижки 10% базова ціна округлюється до 1080 (з ПДВ) або 900 (без). Якщо ПДВ додається після округлення, підсумок може відрізнятися на копійки. Це нормально і регулюється налаштуваннями комплексного компонента.
Психологічне ціноутворення
Для цін виду «.99» правила округлення не підходять — це маркетингове завдання, яке вирішується постфіксним обробником. Приклад — обробник події OnSaleOrderBeforeSaved або кастомний метод перерахунку цін. Ми реалізуємо такі сценарії під ключ: налаштовуємо логіку «ціна завжди закінчується на 9», «округлення до 49 або 99 копійок» тощо.
Що входить у роботу
- Аудит поточних правил округлення: аналіз таблиці
b_catalog_rounding_rule, виявлення дублювання та конфліктів. - Розробка кастомних правил: написання скриптів міграцій, кастомних обробників для психологічних цін.
- Тестування на копії сайту: перевірка всіх типів цін, знижок, кошика, вивантаження в 1С.
- Документація: опис створених правил, інструкція для менеджерів.
- Навчання: як додавати нові правила через API, а не адмінку.
Строки та гарантії
Базове налаштування правил округлення для всіх типів цін — від 1 до 3 годин. Нестандартна логіка (психологічні ціни, різні правила для категорій, інтеграція з 1С) — від 4 до 8 годин. Ми гарантуємо, що після налаштування ціни на вітрині та в кошику відображатимуться коректно, а розбіжності з 1С зникнуть. Оцінимо ваш проект безкоштовно — отримайте консультацію, написавши нам у чат або на пошту. Досвід нашої команди — 10+ років розробки на Бітріксі, понад 200 завершених проектів, сертифікація «1С-Бітрікс: Розробник».
Порівняння підходів до округлення
Порівняємо підходи. Математичне округлення (ROUND_MATH) дає бухгалтерську точність, але на вітрині виглядає негарно. Округлення вниз (ROUND_DOWN) привабливе для клієнтів, але трохи знижує маржу. Округлення вгору (ROUND_UP) захищає від збитку, але клієнти можуть помітити завищення. Психологічний обробник дає маркетинговий ефект, але потребує розробки. Для більшості проектів ми рекомендуємо комбінацію: для роздробу — округлення вниз до цілих, для опту — математичне до десятків, а для акційних цін — кастомний обробник.
Покрокова інструкція з налаштування правил округлення
1. Визначте типи цін та вимоги до точності для кожного. 2. Напишіть скрипт міграції через `\Bitrix\Catalog\RoundingTable::add()`. 3. Протестуйте на копії сайту: перевірте вітрину, кошик, вивантаження в 1С. 4. Задокументуйте правила для менеджерів. 5. Навчіть команду додавати нові правила через API.Зв'яжіться з нами, щоб обговорити ваш проект. Ми безкоштовно проаналізуємо поточні правила та запропонуємо оптимальний варіант.