Персональные цены в B2B-магазине: как согласовать правила и исключения

За фразой «у каждого своя цена» скрывается несколько договорённостей

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

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

В B2B-магазине, который я разрабатывал, есть общий коэффициент покупателя, коэффициенты товарных групп и отдельная цена для пары «покупатель — товар». В расчёте также участвуют акции. Основная сложность здесь — определить, в каком порядке эти условия применяются, а затем выдержать этот порядок во всём кабинете.

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

Договорная цена не обязательно самая низкая

Допустим, базовая цена товара — 1 000 рублей. Общее условие клиента даёт 900 рублей, скидка на группу — 850, а персональная договорная цена — 880. Если персональная цена имеет высший приоритет, покупатель увидит 880 рублей. Если магазин всегда выбирает минимальный вариант — 850. Это два разных порядка расчёта.

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

Ещё одна распространённая неоднозначность — сложение скидок. Общие 10% и групповые 15% могут означать выбор 15%, последовательное уменьшение цены или скидку 25%. При базе 1 000 рублей это даст 850, 765 или 750 рублей. Одинаковые проценты в настройках ещё не означают одинаковую формулу.

Проверьте порядок правил на своём примере

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

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

Как устроен расчёт в рабочем проекте

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

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

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

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

Одна цена должна пройти через весь заказ

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

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

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

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

Копейки и упаковки лучше обсудить заранее

При базе 19,99 рубля и скидке 15% получается 16,9915 рубля за штуку. Если округлить цену единицы до 16,99 и умножить на 100, выйдет 1 699 рублей. Если сначала посчитать всю строку и округлить только итог — 1 699,15. Разница появилась без единой ошибки арифметики: изменился момент округления.

К этому добавляется единица продажи. Цена может быть указана за штуку, а заказ оформляться упаковками. В прайсе должны быть видны и единица цены, и минимальное количество. Иначе покупатель сравнивает несопоставимые суммы и получает неожиданный итог.

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

Прайс-лист — снимок условий в определённый момент

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

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

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

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