Настройка оптовых цен по объему заказа 1С-Битрикс

Почему оптовые цены в Битрикс не срабатывают в корзине

Крупный покупатель собирает корзину на десятки позиций, а на оформлении видит розничную стоимость. Правила по объёму заказа в системе заведены, но расчёт в корзине их не подхватывает: условие привязано к карточке товара или к группе покупателя, а стоимость пересчитывается по базовой цене в момент добавления и больше не обновляется, когда количество меняется.

Вторая типовая поломка — порядок применения условий. Оптовые цены в Битрикс часто собраны из нескольких независимых механизмов: скидка за объём, скидка на категорию, персональное соглашение с клиентом. Они не согласованы между собой, поэтому побеждает то правило, которое применилось последним, а не то, которое выгоднее покупателю. Стоит убрать позицию или опуститься ниже порога — цена не возвращается к исходной, и итог в счёте расходится с тем, что клиент видел в корзине.

Цена такой ошибки — ручной пересчёт заказов. Менеджер открывает каждое крупное оформление, сверяет объём с прайсом, правит строки руками: на потоке это десятки операций за смену, задержка счёта и расхождения между корзиной, документом и отгрузкой. Отдельно мешает кеширование каталога — обновлённый прайс не доезжает до витрины, пока не сброшен кеш, и покупатель продолжает видеть старую цену.

Причины обычно одни и те же: не описана матрица порогов, условия навешены поверх стандартного расчёта, нет набора проверочных сценариев на пересчёт при изменении состава заказа. Дальше разбираем, как это закрывается — от постановки правил до проверки на реальных заказах.

Что даёт автоматический расчёт по объёму заказа

Оптовые условия перестают быть договорённостью в переписке и становятся частью каталога: в Битрикс тип цены привязывается к группе покупателей, а порог срабатывает по сумме заказа или по количеству позиций в корзине. Проверка идёт в момент добавления товара, а не в момент согласования с менеджером.

Пересчёт выполняется на стороне каталога, поэтому итоговая цена и скидка видны покупателю ещё в корзине — до отправки заявки. Это и есть автоматический расчёт по объёму: скидка растёт ступенями, и клиент на каждой следующей позиции видит, сколько добавить, чтобы попасть в следующий порог.

Дальше заказ уходит в учётную систему уже с применённым типом цены, поэтому счёт, отгрузка и документ совпадают по суммам и позициям. Ручная правка счёта после оформления — самый частый источник расхождений между тем, что пообещали клиенту, и тем, что попало в накладную.

Эффект виден в цифрах: скорость оформления заказа растёт, потому что исчезает переписка с пересчётом; доля заказов, которые менеджер правит руками, падает до единичных случаев; ошибки в отгрузках, связанные с несогласованной ценой, уходят как класс. Условия для групп покупателей — опт, дилер, розница — задаются раздельно и не пересекаются между собой.

Способы задать условия по объёму: сравнение подходов

Условие по объёму можно задать несколькими механизмами, и они не взаимозаменяемы: каждый держит свою зону ответственности — от корзины до учётной системы. Разница проявляется в том, где хранится правило, на каком шаге оно срабатывает и что ломается при росте ассортимента и числа договоров.

Граница между подходами проходит по моменту, когда объём становится известен. Правила корзины считают по факту заказа, группы и прайс-листы задают условие заранее, учётная система выводит его из накопленной истории. Совмещать схемы можно, но у каждого правила должен быть один владелец — иначе при возврате или частичной отмене позиции цена пересчитается дважды, и покупатель увидит расхождение между сайтом и счётом.

Этапы настройки: от аудита каталога до передачи

Правила оптовых цен ломаются не в момент настройки, а на этапе решения: если пороги и приоритеты не зафиксированы до начала работ, менеджеры получают расхождения с расчётом в 1С, а покупатели — разные цены на одинаковые корзины. Поэтому работу ведём по регламенту: сначала разбираем структуру каталога и типы покупателей, только потом включаем расчёт.

1. Аудит каталога и типов покупателей: смотрим разделы, торговые предложения и свойства, по которым определяется объём, сверяем типы цен на сайте с базой 1С, находим позиции без привязки к цене — они первыми дают сбои.
2. Схема правил расчёта на согласование: фиксируем пороги по количеству и сумме, приоритет правил при пересечении, поведение на границе порога и способ округления — до того, как что-то включено на живом каталоге.
3. Настройка уровней цен и привязок правил к разделам и группам покупателей: одна линейка не должна перекрывать другую, для каждой группы явно определён источник цены.
4. Прогон на тестовом контуре: копия каталога и обмена, сценарии на одну единицу, ровно на порог, на порог плюс единица и на смешанную корзину, сверка результата с расчётом менеджера.
5. Перенос настроек на рабочий контур: в окно низкой нагрузки, с выборочной сверкой цен по группам и контрольным списком позиций, где ранее были расхождения.
6. Обучение и передача: регламент правки порогов, чтобы менеджер менял условия без разработчика, описание логики и журнал изменений.

Каждый этап закрывается проверкой, поэтому расхождения ловятся до включения правил, а не после жалоб покупателей.

Что входит в комплект передачи: правила и регламенты

Правила оптовых цен работают ровно до тех пор, пока их можно передать другому человеку. Поэтому внедрение заканчивается не включённой настройкой, а комплектом документации: по нему менеджер, контент-редактор и администратор площадки дальше действуют без нас.

• Настроенные правила расчёта: пороги по количеству, шаг скидки, приоритет правил при пересечении условий и поведение корзины на граничных значениях.
• Профили покупателей и привязка групп к типам цен — какая категория клиентов видит какую цену в каталоге, в карточке товара и на оформлении заказа.
• Схема расчёта с примерами на реальных корзинах: от сработавшего порога до итоговой суммы в заказе, включая округление и сочетание скидок.
• Инструкция для менеджера: как выдать индивидуальные условия вне общей сетки, как проверить применённое правило в заказе и что делать при конфликте условий.
• Регламент изменений: кто согласует новый порог, как правка проходит проверку на тестовом контуре и в какой момент попадает в рабочую систему.
• Порядок ведения справочников: как добавлять новые группы товаров, что обновлять при пересмотре цен поставщика и как помечать правила, срок действия которых истёк.
• Журнал версий правил с датой и ответственным — чтобы вернуть предыдущие условия, если новая сетка дала неожиданный результат.

Такой комплект убирает главный риск: знание о том, как считается оптовая цена, перестаёт жить в переписке и в голове одного администратора, а изменение порога превращается в регламентную операцию.

Кейс: как убрали ручной пересчёт крупных заказов

Оптовый поставщик с несколькими складами принимал заказы через личный кабинет на 1С-Битрикс, но скидка по объёму жила не в системе, а в голове менеджера: сумму сделки считали вручную и вписывали в счёт. Каждый пятый крупный заказ уходил клиенту с пересчётом — пауза от нескольких часов до суток, если менеджер был на другом звонке.

Что изменили

Настроили уровни оптовых цен, привязанные к объёму заказа в корзине: порог по сумме позиций, порог по количеству единиц одной номенклатуры и отдельные условия для групп товаров. Правила считаются на стороне сервера в момент оформления — цена пересчитывается в корзине и фиксируется в заказе, а ручная правка суммы требует отдельного права доступа.

Результат

Метрики держатся не за счёт ужесточения контроля, а потому что расчёт стал единственным источником цены: счёт, отгрузка и документ в учётной системе формируются из одного значения. Это закрыло и человеческий фактор — менеджер больше не может отгрузить по цене, которой нет в правилах.

Что делать, если оптовые условия уже настроены вручную?

Ручные правила редко живут в одном месте: скидка может быть зашита в карточке покупателя, в группе пользователей, в персональных условиях договора и в доработке, которая считает корзину. Правила наслаиваются друг на друга, порядок их применения уже никто не помнит, и правка одной ставки ломает расчёт у части оптовиков.

Поэтому начинаем с инвентаризации настроек: выгружаем все источники, где вообще задаётся цена, — правила расчёта корзины, привязки групп, договорные условия, нештатные доработки в шаблонах, обмен с учётной системой. По каждому пункту фиксируем условие срабатывания, владельца и приоритет. Получается реестр, по которому видно, какие правила дублируют друг друга, а какие уже не срабатывают ни на одном заказе.

Переход без простоя строим так: новая схема расчёта работает параллельно со старой, а переключение происходит только после сверки. Прогоняем оба расчёта на реальной истории заказов и разбираем каждое расхождение — цена в корзине, итог в счёте, значение в отгрузке. Пока цифры не совпадают у всех типов покупателей, прежний механизм остаётся рабочим.

Отдельно закрываем обратную совместимость. Договорённости с конкретными покупателями переносим как персональные исключения поверх новых правил, чтобы клиент не увидел другую цену в следующей отгрузке. Внешний обмен продолжает отдавать те же данные в прежнем виде.

Само переключение ставим в окно минимальной нагрузки и держим старый контур под рукой для быстрого возврата. Так оптовые цены переезжают в управляемую схему, а текущие отгрузки и договорённости с покупателями остаются нетронутыми.

Технические вопросы, которые задают чаще всего

Объёмных и накопительных скидок почти никогда не бывает одна: правила делят по категориям, суммам и группам покупателей. Основные сомнения возникают там, где условия пересекаются или встречаются с индивидуальными договорённостями. Разберём поведение системы по умолчанию и то, что настраивается под ваш процесс.

Как считается округление итога?

Округление настраивается отдельно для строки и для итога заказа, а скидка считается до налога или после — это меняет конечную сумму. Порядок фиксируется в самом правиле, поэтому одна и та же корзина всегда даёт одинаковый результат, а расхождение с расчётом менеджера объяснимо и проверяемо.

Совместимо ли это с договорными условиями?

Индивидуальные соглашения имеют приоритет над автоматикой: для контрагента заводится персональное правило, перекрывающее общие пороги. Договорные цены можно ограничить сроком или объёмом отгрузки, а после его окончания система сама вернётся к стандартной сетке.

Повлияет ли настройка на уже оформленные заказы?

Цена и скидка фиксируются в момент оформления, поэтому изменение правил не пересчитывает закрытые и текущие заказы. Массовый пересчёт выполняется только отдельной операцией — запускаем её осознанно, после согласования списка.

Обсудим задачу — вернёмся с оценкой и планом

Первый разговор — про данные, а не про презентации. Чтобы вернуться с оценкой работ и планом внедрения, нам нужно понять структуру каталога: как устроены типы цен, есть ли уже скидки от количества, как выгрузка из 1С попадает на сайт и что происходит с ценой в корзине. По этим вводным сразу видно, потребуется ли доработка обмена или задача закрывается правилами в существующем контуре «Битрикс».

• Выгрузка каталога: сколько товаров и торговых предложений, есть ли варианты по цвету, размеру, фасовке.
• Текущие типы цен и правила скидок: от объёма в штуках, от суммы заказа или по категориям.
• Источник цен: выгрузка из 1С, ручное заполнение, прайс поставщика — и как часто он обновляется.
• Примеры реальных заказов: какие объёмы считаются оптовыми и как должна меняться цена на каждом шаге.
• Требования к отображению: показывать шкалу скидок в карточке и корзине, считать цену сразу или после подтверждения менеджером.
• Роли и доступы: кто утверждает оптовые цены, кто видит их до публикации, нужны ли отдельные условия для групп покупателей.
• Схема обмена: как часто синхронизируются цены и остатки, что делать при расхождении и кто отвечает за конфликт данных.

Если чего-то из списка нет под рукой — не страшно, соберём вместе: обычно хватает выгрузки каталога и короткого разговора с тем, кто ведёт прайс. Опишите задачу, укажите, где сейчас болит — и мы вернёмся с оценкой работ, порядком внедрения и точками, где нужна ваша проверка.