Цена в карточке одна, в корзине другая, в заказе третья, а бухгалтерия в 1С видит четвёртую. Клиент замечает расхождение в чеке — и доверие к магазину рушится мгновенно, потому что ошибка в цене воспринимается либо как обман, либо как непрофессионализм. При этом каждый слой считал «правильно» — просто по своим правилам. Это классическая беда ценообразования, где нет единой логики расчёта.
Разберём, как устроен расчёт цены в 1С-Битрикс с учётом акций, валют и налогов: из каких слоёв складывается итог, в каком порядке применяются скидки, как работают валюты и НДС, где возникает копеечное расхождение и почему сложную логику стоит собрать в единый сервис. Навести порядок в связке «сайт — 1С» помогает аудит и оптимизация 1С.
Коротко
- Цена — это вычисление из слоёв: базовая по типу цены группы, затем скидки на товар, затем правила корзины (акции, промокоды).
- Явно задайте порядок и суммируемость скидок, иначе итог непредсказуем; фиксируйте курс валюты на момент заказа.
- Определите, включает цена НДС или добавляет его сверху, и единое правило округления — иначе в чеке появляются расхождения.
- Сложную логику вынесите в единый сервис на D7, чтобы витрина, корзина и API считали цену одинаково, и покройте тестами.
Почему цена — это вычисление, а не число
Кажется, что у товара «есть цена». На деле итоговая сумма к оплате — результат цепочки вычислений: берётся базовая цена, к ней применяются скидки, акции и промокоды, всё это, возможно, конвертируется из валюты, облагается или не облагается налогом и округляется. На каждом шаге можно ошибиться, и ошибка проявится не сразу, а в конкретном заказе с конкретным сочетанием условий.
Главная опасность — когда разные части системы считают цену независимо: витрина показывает одно, корзина пересчитывает по-своему, а заказ фиксирует третье. Пока условия простые, расхождений не видно. Но стоит добавить акцию, вторую валюту или B2B-цены без НДС — и слои начинают расходиться. Поэтому ценообразование проектируют как единую логику, а не как набор независимых расчётов.
Слои ценообразования
Итоговую цену удобно представлять как последовательность слоёв, каждый из которых преобразует результат предыдущего.
| Слой | Что делает | Где настраивается |
|---|---|---|
| Базовая цена | Цена по типу цены группы клиента | Типы цен, обмен с 1С |
| Скидки на товар | Персональные и товарные скидки | Скидки каталога |
| Правила корзины | Акции, промокоды, пороги | Правила работы с корзиной |
| Валюта | Конвертация к валюте показа/заказа | Модуль «Валюты» |
| Налог | НДС в цене или сверху | Ставки НДС у товара |
| Округление | Приведение к нужной точности | Настройки/сервис расчёта |
Порядок слоёв важен: применить скидку до или после конвертации валюты, выделить НДС до или после округления — всё это меняет итог. Спроектировать порядок нужно один раз и соблюдать его везде.
Базовая цена: типы цен и группы
Фундамент расчёта — базовая цена, и в 1С-Битрикс она не единственная. Механизм типов цен позволяет вести у товара несколько цен (розничная, оптовая, дилерская), а группы пользователей определяют, какой тип видит конкретный клиент.
Логика такая: у авторизованного пользователя есть группа, группе сопоставлен тип цены, и в расчёт берётся именно он. Розничный гость видит розничную цену, дилер — дилерскую. Это базовый механизм B2B-ценообразования, поверх которого работают все остальные слои. Ошибка здесь — например, неверная привязка группы к типу цены — искажает цену для целого сегмента клиентов, поэтому базовый слой проверяют в первую очередь.
Скидки и акции: порядок применения
Самый частый источник ошибок — скидки, потому что их несколько и они взаимодействуют. В 1С-Битрикс скидки на товар и правила работы с корзиной (акции, промокоды) применяются последовательно, и результат зависит от приоритетов и от того, складываются скидки или взаимоисключают друг друга.
- Возьмите базовую цену. По типу цены группы клиента.
- Примените товарные скидки. Персональные и каталожные скидки на позицию.
- Примените правила корзины. Акции, промокоды, пороги — по приоритету.
- Решите про суммирование. Явно: скидки складываются или действует только максимальная.
Ключевое решение — суммируемость. Если не задать её явно, клиент может получить скидку на скидку и обвал маржи, либо наоборот — недополучить обещанное. Это правило фиксируют на уровне бизнеса и переносят в настройки один раз. Порядок и приоритеты скидок стоит задокументировать, чтобы маркетинг не ломал расчёт новыми акциями.
Валюты и курсы
Если магазин работает с несколькими валютами, добавляется слой конвертации. Модуль «Валюты» хранит список валют и курсы; цены могут вестись в одной валюте, а показываться в другой. Здесь два принципиальных вопроса: по какому курсу конвертировать и в какой момент фиксировать цену.
Правильный подход — фиксировать цену в валюте заказа на момент оформления. Тогда последующее изменение курса не трогает уже оформленные заказы: клиент заплатит ровно ту сумму, которую видел при заказе. Если этого не сделать, при скачке курса суммы «поплывут» и в учёте появятся расхождения. Курс и валюта заказа — часть данных заказа, а не глобальная настройка «на сейчас». Про современную работу с такими данными на бэкенде — в статье про ядро D7 и ORM в 1С-Битрикс.
НДС: в цене или сверху
Налог — слой, где легко ошибиться на ровном месте. В 1С-Битрикс ставка НДС задаётся у товара, а отдельный флаг определяет, включена ли сумма налога в цену или начисляется сверху. От этого флага зависит весь чек.
- Розница. Обычно цена показывается с НДС «в том числе» — покупатель видит финальную сумму.
- B2B. Часто нужна цена без НДС с выделением налога отдельной строкой в заказе.
- Смешанный сценарий. Разным группам — по-разному; логика показа налога зависит от сегмента.
- Согласование с учётом. Ставки и способ начисления должны совпадать с тем, что ведётся в 1С.
Ошибка в способе учёта НДС — одна из самых дорогих: она искажает и цену для клиента, и данные для бухгалтерии. Поэтому способ учёта налога согласуют с бухгалтерией до запуска, а не после первых заказов.
Округление без расхождений
Копеечные расхождения в заказе почти всегда — следствие несогласованного округления. Если округлять на каждом промежуточном шаге (цену за единицу, потом позицию, потом заказ), сумма строк перестаёт сходиться с итогом. Клиент видит, что 3 × 33,33 не равно 100, и это подрывает доверие.
Решение — единое правило: договориться, на каком этапе и до какой точности округляется величина, и применять это правило одинаково везде. Обычно округляют итог позиции и итог заказа по согласованному правилу, а промежуточные величины держат в полной точности. Правило округления, как и порядок скидок, — часть архитектуры расчёта, а не случайная настройка компонента.
Связь с ценами из 1С
В магазине на 1С-Битрикс цены не рождаются на сайте — значительная часть приходит обменом CommerceML из учётной системы. Базовые цены, типы цен по группам, часть скидок ведутся в 1С и выгружаются на сайт. Задача архитектуры — чтобы правила расчёта на сайте не противоречили заложенным в 1С.
Главный принцип — однозначность источника: у каждой составляющей цены должен быть один хозяин. Базовые цены и типы цен ведёт 1С, акции витрины и промокоды — сайт. Когда одна и та же скидка настроена и там, и там, начинается двойное применение и хаос. Как выстроить надёжный и безопасный обмен данными между системами, мы разбираем в статье про безопасность REST и вебхуков в 1С-Битрикс, а сам обмен и учёт закрываем услугой автоматизации продаж и склада на 1С.
Единый сервис расчёта на D7
Когда ценообразование выходит за рамки простых скидок — появляются валюты, персональные условия, разный НДС для сегментов — логику расчёта стоит вынести в отдельный сервисный слой на современном ядре D7, а не размазывать по компонентам витрины и корзины.
Единый сервис даёт три вещи: цену считает одна функция, поэтому витрина, корзина, оформление и API возвращают одинаковый результат; логику можно покрыть автотестами; изменения вносятся в одном месте, а не в пяти. Это устраняет главную причину расхождений — независимый расчёт в разных частях системы. Про переход со старого API на D7 и почему это важно для такой логики — в материале про D7 и ORM в 1С-Битрикс.
Тестирование ценообразования
Ценообразование — та область, где ошибка сразу бьёт по деньгам, поэтому его тестируют системно. Нужен набор тест-кейсов на граничные случаи с заранее посчитанным вручную ожидаемым итогом.
- Скидка и промокод вместе. Проверить суммирование и приоритеты.
- Разные группы клиентов. Розница, опт, дилер — своя цена у каждого.
- Валюты. Конвертация и фиксация курса в заказе.
- НДС в цене и сверху. Оба сценария и выделение налога.
- Округление. Позиции с некруглыми ценами и количеством.
Автотесты на расчёт цены окупаются быстро: они ловят регрессию, когда новая акция или доработка ломает старую логику. Ошибку в чеке дешевле поймать тестом, чем разбором жалобы клиента.
Частые ошибки
- Независимый расчёт в разных местах. Витрина, корзина и заказ считают цену по-своему — слои расходятся.
- Не задана суммируемость скидок. Скидка на скидку рушит маржу или клиент недополучает обещанное.
- Курс не зафиксирован в заказе. Изменение курса меняет сумму уже оформленных заказов.
- Неверный флаг НДС. Налог выделяется не так — искажён и чек, и учёт.
- Округление на каждом шаге. Сумма строк не сходится с итогом заказа.
- Двойной источник цены. Одна скидка настроена и в 1С, и на сайте — двойное применение.
- Нет тестов. Ошибку в цене ловят клиенты, а не разработчики.
Чек-лист внедрения
- Слои спроектированы. Порядок: базовая цена, скидки, правила корзины, валюта, налог, округление.
- Типы цен по группам. Каждой группе клиентов сопоставлен свой тип цены.
- Суммируемость скидок задана. Явно: складываются или действует максимальная.
- Курс фиксируется в заказе. Сумма оформленного заказа не зависит от изменения курса.
- НДС согласован с учётом. Способ начисления совпадает с 1С и аудиторией.
- Округление единое. Одно правило и этап применения по всей системе.
- Источники цены однозначны. У каждой составляющей один хозяин — 1С или сайт.
- Расчёт покрыт тестами. Граничные случаи проверяются автоматически.
Вывод
Расчёт цены в магазине на 1С-Битрикс — это не одно число, а цепочка вычислений из слоёв: базовая цена по группе, скидки, акции, валюта, налог и округление. Ошибка в любом слое или, чаще, независимый расчёт в разных частях системы приводят к расхождениям, которые клиент замечает в чеке, а бухгалтерия — в учёте.
Спроектируйте порядок слоёв один раз, явно задайте суммируемость скидок, фиксируйте курс в заказе, согласуйте НДС и округление с учётом и — главное — соберите сложную логику в единый сервис на D7, который считает цену одинаково для витрины, корзины и API. Покройте расчёт тестами на граничные случаи. Тогда цена будет одной и той же на всех экранах и во всех документах, а доверие клиента останется целым.
