Настройка округления цен в 1С-Битрикс: точность и маркетинг

Настройка округления цен в 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.

Какие типы правил округления поддерживает Битрикс?

Математическое округление — базовый выбор для бухгалтерии, но оно не даёт «красивых» цен для витрины. Округление вниз часто используют в маркетинге: цена 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) защищает от убытка, но клиенты могут заметить завышение. Психологический обработчик даёт маркетинговый эффект, но требует разработки. Для большинства проектов мы рекомендуем комбинацию: для розницы — округление вниз до целых, для опта — математическое до десятков, а для акционных цен — кастомный обработчик.

Свяжитесь с нами, чтобы обсудить ваш проект. Мы бесплатно проанализируем текущие правила и предложим оптимальный вариант.