Контрактные цены в Битрикс: где ломается логика скидок для дилеров
Обычно расхождение начинается с того, что контрактные цены в Битрикс живут отдельно от реальности отдела продаж. У дилера есть свой прайс в таблице, у компании — типы цен для дилеров в каталоге, и синхронизируют их вручную. Пока групп три-четыре, это терпимо; на десятой появляются позиции, которые одному дилеру считаются по старой цене, а другому — по новой.
Дальше ломается логика скидок для оптовиков. Скидка настраивается от базовой цены, а не от контрактной, поэтому дилер с индивидуальными условиями получает процент не от той суммы. Накопительные пороги и округление добавляют второй слой: при заказе на границе диапазона итог отличается на несколько процентов, и менеджер узнаёт об этом уже после согласования.
Самое дорогое — ошибки расчёта цены в заказе. Цена фиксируется в момент оформления, но прайс успевает обновиться, и повторный пересчёт даёт другую сумму. Отсюда споры о сумме, ручные пересчёты и возвраты, а склад и логистика получают заказ, который приходится переоформлять.
Причина не в одной настройке, а в том, что ручные прайс-листы дилеров и типы цен не связаны единым источником. Разбираем, как это закрывается: где хранить контрактные условия, как выстроить приоритет скидок и что фиксировать в заказе, чтобы сумма не менялась задним числом.
Что даёт управляемая система цен для дилерской сети
В дилерской сети цена зависит не от розничной витрины, а от уровня партнёра, объёма выборки и условий договора. Если эти правила живут в таблице у менеджера, каждый заказ проходит через ручную сверку: поиск нужной колонки, проверку срока договора, расчёт скидки. На потоке из десятков позиций это даёт задержку и ошибки — строка уходит по неверной цене, а расхождение всплывает уже в счёте или на отгрузке.
Управляемая система цен переносит правила в саму платформу. Контрагент привязывается к типу цены, тип цены — к правилу пересчёта: процент от базовой, фиксированная цена по договору, ступенчатая шкала от объёма. Пересчёт идёт автоматически при формировании заказа, с приоритетом скидок и округлением, а срок действия договора ограничивает применение условий.
Эффект виден на трёх точках. Скорость оформления заказа растёт: менеджер не сверяет прайс вручную, а выбирает контрагента и получает корректные цены в корзине. Доля ошибок в заказах падает — неверная цена не попадает в документ, если правило задано. Обновление условий поставки превращается в одну правку в типе цены вместо рассылки нового прайса по филиалам.
Единый прайс для дилеров становится источником правды: изменения применяются сразу ко всем новым заказам и фиксируются в истории, поэтому закрытые сделки сохраняют прежние условия. В 1С-Битрикс это ложится на штатные типы цен и правила работы с корзиной, а нестандартная логика договоров достраивается отдельным модулем.
Способы настройки цен в Битрикс: сравнение вариантов
Контрактные цены в 1С-Битрикс закрывают тремя механизмами, и они не взаимозаменяемы: штатные типы цен работают на уровне каталога, правила корзины — на уровне расчёта заказа, а доработка обмена ценами — на уровне данных из учётной системы. Выбор зависит от того, где у заказчика лежит привязка контрагента к прайсу и как часто она меняется.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Штатные типы цен | Договорной прайс на группу контрагентов, номенклатура меняется редко | Тип цены нужен на каждую группу; смена условий — ручной пересчёт или скрипт |
| Правила корзины | Цена зависит от суммы, количества или категории товара в заказе | Цена не хранится как сущность: снятие правила возвращает базовую |
| Доработка обмена ценами | Прайс приходит из учётной системы отдельно по каждому договору | Нужны свой формат выгрузки, сопоставление номенклатуры и контроль рассинхрона |
Ограничения стоит проверить до старта, а не в момент, когда менеджер видит в корзине чужую цену. Выбор способа реализации обычно сводится к комбинации: тип цены хранит договорной прайс, правило корзины считает порог по объёму заказа, обмен наполняет данные из учётной системы. Такой набор даёт предсказуемый расчёт и оставляет точку отката, если условия договора меняются.
Порядок внедрения: от аудита до передачи регламентов
Внедрение контрактных цен — это не галочка в настройках, а перенос логики дилерского ценообразования в структуру каталога: типы цен, привязка к контрагентам, правила скидок и ограничения видимости. Порядок работ выстроен так, чтобы расхождения всплывали на тестовых заказах, а не в боевых счетах дилеров.
- Аудит ценообразования. Собираем действующие прайсы и группы дилеров, пороги и отсрочки, отмечаем цены, заданные вручную, и правила, которые живут только в переписке менеджеров.
- Схема сопоставления цен. Определяем, какой тип цены соответствует каждой дилерской группе и как в каталоге связаны контрагент, договор и профиль покупателя.
- Настройка типов цен и правил. Создаём типы цен и скидочные правила, ограничиваем выборку по группам, задаём пересчёт при обновлении прайса и поведение кэша каталога.
- Обмен с учётной системой. Настраиваем соответствие кодов номенклатуры и контрагентов, обработку новых позиций и позиций, выпавших из прайса.
- Тестовые заказы дилеров. Прогоняем сценарии по каждой группе: вход под дилером, корзина, оформление, счёт, повторный заказ, смена условий в середине сделки.
- Приёмочная проверка. Сверяем итоговые цены и документы с эталонной таблицей, проверяем граничные случаи: несколько договоров, смешанная корзина, откат условий.
- Передача настроек заказчику. Отдаём регламенты по типам цен и группам, инструкции для менеджеров, доступы и карту изменений с точками отката.
Каждый этап заканчивается артефактом — схемой, таблицей соответствий или актом сверки, — и без него следующий не начинается. Так сопровождение передаётся внутри команды заказчика без восстановления логики по памяти.
Что остаётся у заказчика: конфигурации, регламенты, документация
Сдача работ — это не только работающий функционал, но и комплект артефактов, по которому ваша команда сможет развивать контрактные цены без нас. Всё передаём на вашем контуре и под вашим контролем версий.
- Конфигурация типов цен: какие типы созданы, к каким группам пользователей привязаны, от какого типа считается скидка и как отрабатывает округление.
- Схема сопоставления номенклатуры: по каким реквизитам — артикул, код, внешний идентификатор — позиция дилера связывается с каталогом и что происходит с несовпавшими строками.
- Права доступа к прайсу: матрица ролей — кто видит контрактный тип цены, кто может его править, кому разрешён экспорт.
- Регламент подключения дилера: пошаговый порядок от заявки до персонального прайса, с ответственными и точками проверки на каждом шаге.
- Документация по ценам: приоритеты типов, когда за одну позицию конкурируют несколько, и поведение при отсутствии контрактного совпадения.
- Журнал изменений и откат: где хранится история правок, как вернуть предыдущее состояние прайса и как отличить ручную корректировку от расчётной.
- Инструкция по диагностике: типовые причины, по которым дилер видит базовую цену, и какие записи смотреть первыми.
Замыкает передачу чек-лист приёмки: сценарии, которые мы прогоняем вместе с вашим специалистом, — от создания дилера до пересчёта цен после изменения прайса. Пункты подписаны, так что при вводе нового дилера или смене ответственного ничего не приходится восстанавливать по памяти.
Кейс: переход от ручных скидок к управляемым условиям для дилеров
Дилерская сеть жила на согласованных вручную ценах: менеджер открывал заявку, сверял условия договора с таблицей в почте и только потом выставлял счёт с нужным типом цены. Пока отгрузок было десять в день, схема держалась. На объёме в сотню заказов каждый пятый счёт уходил на пересчёт, а часть дилеров получала цены своей категории с запозданием на день-два.
Что показали замеры до внедрения
За месяц собрали статистику по отделу продаж: 8% заказов возвращались на исправление цены, среднее время оформления составляло 40 минут, и больше половины уходило на согласование условий. Ручных правок в прайсе набиралось до 120 в неделю, а расхождения между ценой в счёте и в учётной системе находили уже на этапе отгрузки — со стороны дилера это выглядело как необязательность поставщика.
Что изменили и что получилось
На 1С-Битрикс настроили контрактные цены: тип цены жёстко привязан к договору контрагента, ценовая группа дилера определяется правилами, предельная скидка ограничена порогом для каждой категории, а любое изменение фиксируется в журнале с автором и временем. Обмен с учётной системой подтягивает согласованные значения автоматически, поэтому менеджер больше не считает цену руками.
Через два месяца после запуска доля ошибочных заказов упала с 8% до 1,2%, время оформления сократилось с 40 до 12 минут, а объём ручных правок — почти в шесть раз. Отдел продаж переключился с разбора расхождений на работу с сетью: дилеров стало возможно подключать по типовому договору, не расширяя штат согласующих.
Что делать, если каталог уже синхронизирован с учётной системой
Каталог пересобирать не нужно: обмен с учётной системой остаётся тем же узлом, а контрактные цены добавляются поверх существующего типа цен как отдельный слой. Позиции, остатки и свойства не трогаются — расширяется только часть выгрузки, отвечающая за ценообразование.
Путь выбирают по двум признакам: как часто меняются условия поставки и насколько полно они описаны в учётной системе. Если соглашения с дилерами ведутся там же, дешевле расширить текущий обмен; если цены считаются вне её, их подают отдельным обработчиком и раскладывают по группам покупателей на стороне 1С-Битрикс.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Расширение текущего обмена | Условия поставки ведутся в учётной системе, правил немного | Правка правил обмена, нужен тестовый контур |
| Отдельный обработчик контрактных цен | Цены считаются вне учёта, привязаны к договору или менеджеру | Своя сверка с базовой ценой и логирование |
| Гибрид: базовый прайс в обмене плюс надстройка | Базовая цена нужна всем, контрактная — части дилеров | Два источника цены, нужен явный приоритет |
Пошаговое расширение выглядит так: в учётной системе заводят типы цен и соглашения, в правилах обмена добавляют их в выгрузку, на сайте сопоставляют с группами покупателей. Дальше — прогон на тестовом контуре и включение по одной группе дилеров; рабочий обмен при этом не останавливается.
Такой порядок минимизирует переделки: существующий обмен продолжает работать, а надстройку отключают одной настройкой и возвращаются к единому прайсу. Новые условия поставки добавляются расширением правил, без повторной сборки каталога.
Технические сомнения перед стартом: частые вопросы
Базовый обмен каталогом, остатками и заказами остаётся нетронутым: контрактные цены — это отдельный тип цен, который передаётся дополнительно и не переписывает розничный. Поэтому синхронизация продолжает работать по штатному расписанию, а сбой в правилах дилерских цен не останавливает выгрузку товаров. Разбираем, что чаще всего вызывает вопросы до старта.
Обмен с 1С придётся переделывать целиком?
Нет. Дилерский тип цен добавляется к существующему обмену отдельным узлом: состав полей расширяется, порядок выгрузки и сопоставление номенклатуры сохраняются. Правки локализованы в правилах и не затрагивают логику остатков и заказов.
Как решается округление и налог в цене?
Округление и налог считаются на стороне учётной системы — на сайт приходит уже готовая цена. Иначе витрина и счёт разойдутся на копейки, и это всплывёт в сверке. Правила округления задаём один раз и переносим в обмен.
Можно ли показать цену только конкретному дилеру?
Да. Дилерский тип цены привязывается к группе пользователей или к контрагенту, а витрина отдаёт её только после авторизации. Для остальных посетителей остаётся розничная цена, кэш страниц не смешивает варианты.
Доработка под дилера сломает обновления?
Нет, если расширяем штатные механизмы, а не правим ядро: своя логика живёт в модуле и переживает обновление платформы. Перед выкаткой прогоняем обмен на копии базы — расхождения видно до продакшена.
Что будет со старыми заказами?
Ничего: цена фиксируется в заказе в момент оформления и не пересчитывается задним числом. Новый тип цен влияет только на заказы, созданные после включения правил, — история и документы остаются корректными.
Обсудим задачу: с чего начнём и что подготовить
Чтобы разговор шёл про архитектуру, а не про пересказ текущего процесса, полезно принести несколько вводных. По ним мы сразу видим, где контрактная цена считается в 1С, а где должна подставляться на стороне сайта.
- выгрузку номенклатуры и список типов цен — какие уровни уже заведены в 1С, а какие имитируются вручную;
- список дилеров и признак принадлежности к группе: договор, сегмент, регион или отдельное поле в карточке контрагента;
- правила расчёта: порог входа, кратность отгрузки, объёмный диапазон, условия поставки — всё, что влияет на итоговую цену;
- поведение при смене статуса дилера внутри периода: с какой даты применяется новый уровень и что делать с уже выставленными документами;
- примеры реальных документов — счёт, отгрузка, спецификация, — чтобы видеть, где контрактная цена обязана подставляться автоматически;
- доступы к тестовому стенду и копии базы: обмен проверяем на ваших данных, а не на демонстрационных;
- ограничения: что нельзя менять в текущей конфигурации, кто согласует правила, какой срок отводится на откат.
По этим данным вернёмся с оценкой и планом работ: очередность этапов, точки приёмки, схема обмена ценами и порядок переключения. Если часть вводных ещё не определена — обсудим на разговоре, зафиксируем допущения и вынесем их отдельными пунктами плана, чтобы они не стали неожиданностью на приёмке.







