Контрактные цены для дилеров в 1С-Битрикс: настройка и интеграция

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

Контрактные цены для дилеров в 1С-Битрикс: настройка и интеграция

Цены и скидкиПростой~1 день
Часто задаваемые вопросы

Контрактные цены в Битрикс: где ломается логика скидок для дилеров

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

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

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

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

Что даёт управляемая система цен для дилерской сети

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

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

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

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

Способы настройки цен в Битрикс: сравнение вариантов

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

Вариант Когда подходит Ограничения
Штатные типы цен Договорной прайс на группу контрагентов, номенклатура меняется редко Тип цены нужен на каждую группу; смена условий — ручной пересчёт или скрипт
Правила корзины Цена зависит от суммы, количества или категории товара в заказе Цена не хранится как сущность: снятие правила возвращает базовую
Доработка обмена ценами Прайс приходит из учётной системы отдельно по каждому договору Нужны свой формат выгрузки, сопоставление номенклатуры и контроль рассинхрона

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

Порядок внедрения: от аудита до передачи регламентов

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

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

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

Что остаётся у заказчика: конфигурации, регламенты, документация

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

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

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

Кейс: переход от ручных скидок к управляемым условиям для дилеров

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

Что показали замеры до внедрения

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

Что изменили и что получилось

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

Через два месяца после запуска доля ошибочных заказов упала с 8% до 1,2%, время оформления сократилось с 40 до 12 минут, а объём ручных правок — почти в шесть раз. Отдел продаж переключился с разбора расхождений на работу с сетью: дилеров стало возможно подключать по типовому договору, не расширяя штат согласующих.

Что делать, если каталог уже синхронизирован с учётной системой

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

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

Вариант Когда подходит Ограничения
Расширение текущего обмена Условия поставки ведутся в учётной системе, правил немного Правка правил обмена, нужен тестовый контур
Отдельный обработчик контрактных цен Цены считаются вне учёта, привязаны к договору или менеджеру Своя сверка с базовой ценой и логирование
Гибрид: базовый прайс в обмене плюс надстройка Базовая цена нужна всем, контрактная — части дилеров Два источника цены, нужен явный приоритет

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

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

Технические сомнения перед стартом: частые вопросы

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

Обмен с 1С придётся переделывать целиком?

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

Как решается округление и налог в цене?

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

Можно ли показать цену только конкретному дилеру?

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

Доработка под дилера сломает обновления?

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

Что будет со старыми заказами?

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

Обсудим задачу: с чего начнём и что подготовить

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

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

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

Наши компетенции:

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1543
  • Разработка веб-сайта для компании ФИКСПЕР
    Разработка веб-сайта для компании ФИКСПЕР
    1060
  • Разработка виджета онлайн-записи на прием для медицинского центра
    Разработка виджета онлайн-записи на прием для медицинского центра
    837
  • Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    928
  • Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    865
  • Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1223