Два закупщика открывают один товар и видят разную цену. Для оптового каталога это обычная ситуация: условия зависят от договора, объёма закупки и выбранной организации. Проблема начинается, когда цена в карточке отличается от цены в корзине, а менеджер потом присылает третью сумму.
Персональные цены требуют согласованных правил расчёта. Нужно определить источник суммы, порядок применения скидок и момент подтверждения заказа. Без этих решений разработчик сможет красиво показать число, смысл которого остаётся спорным.
Разберём шесть правил на учебном примере поставщика крепежа. У компании есть открытый каталог, дилерские договоры и несколько складов. Все названия групп и суммы ниже придуманы для объяснения устройства системы. Они не описывают цены или проекты Feature IT.
1. Привяжите цену к договору и организации
Один пользователь может закупать товары для нескольких юридических лиц. Если цену привязали только к его адресу электронной почты, система рискует применить условия первой организации к заказу второй. Сначала определите, от чьего имени человек оформляет покупку.
В личном кабинете выбор организации должен быть заметен до добавления товара в корзину. Возле него полезно показать договор или название согласованного набора условий, когда у одного клиента их несколько. Человек сможет проверить контекст заказа без звонка менеджеру.
На сервере этот выбор нужно сверить с правами пользователя. Само наличие идентификатора организации в запросе не доказывает, что покупатель имеет к ней доступ. Правило относится к каждой операции получения цены и оформления заказа.
В учебной схеме организация «Север» покупает по дилерскому договору, а «Север-Сервис» получает базовую цену. Сотрудник работает с обеими компаниями. При переключении организации система пересчитывает корзину и объясняет изменение итоговой суммы. Молчаливое сохранение старой цены создаёт спор при подтверждении заказа.
Заранее решите, могут ли в одной корзине лежать товары для разных организаций. Если нет, предложите сохранить текущую корзину и начать отдельную. Пользователь должен понимать, что произойдёт с уже выбранными позициями. Это поведение стоит показать в макете до подключения учётной системы.
2. Выберите один источник расчёта
Персональную цену может рассчитывать учётная система, отдельный сервис или сам сайт по выгруженным правилам. Каждый вариант требует явного договора между участниками обмена. Опишите, какие данные принимает расчёт и что он возвращает.
Для крепежа входными данными могут быть товар, организация, договор, количество и склад. Иногда нужны дата отгрузки или способ оплаты. Если сайт отправляет только артикул, а в учётной системе цена зависит от остальных условий, результат будет неполным.
В ответе полезно получать цену за единицу, единицу измерения, валюту и признак применённого правила. Формат налоговых сведений согласуйте с бухгалтерией и используемой системой учёта. Техническая команда должна отображать подтверждённые значения по принятому в компании порядку.
Сохраните тестовые примеры расчёта вместе с ответственным сотрудником. Например, десять коробок одного товара по договору клиента дают конкретный результат. После обновления программы эти примеры помогут увидеть расхождение. Числа в тестах берите из согласованной проверки, чтобы разработчик не угадывал коммерческую логику.
Если обмен идёт через 1С, подготовка начинается с описания интеграции учётной системы и сайта. Название метода передачи данных само по себе не определяет порядок расчёта скидок. Эти правила нужно отдельно записать и подтвердить со стороны бизнеса.
3. Установите порядок скидок
У клиента есть договорная цена, на товар действует акция, а количество в корзине даёт право на объёмную скидку. Без согласованного приоритета разработчики могут сложить преимущества, которые коммерческий отдел никогда не обещал.
Для каждого сочетания условий укажите итоговое правило. В учебном примере персональная договорная цена имеет приоритет над общей акцией. Количественная скидка применяется только к базовому прайс-листу. Это один из возможных вариантов, который нужен для разбора; ваша компания может работать иначе.
Запишите правила в виде таблицы с конкретными входными данными. В строке должны быть организация, товар, количество и активное предложение. Последняя колонка содержит ожидаемую цену с объяснением выбранного правила.
| Условие учебного заказа |
Правило расчёта |
| Открытый каталог без входа |
Базовая цена |
| Дилерский договор |
Цена договора |
| Базовая цена и достаточное количество |
Объёмная скидка |
| Договор и общая акция |
Цена договора по условиям примера |
| Нет действующего прайс-листа |
Запрос подтверждения у менеджера |
Таблица полезна и для интерфейса. Если после увеличения количества цена за единицу изменилась, покупателю стоит показать причину. Короткое сообщение «Применена цена для заказа от десяти коробок» объясняет результат лучше, чем просто обновлённое число.
Границу скидки проверяйте на соседних количествах. Для условия от десяти коробок подготовьте заказы на девять, десять и одиннадцать. Проверка только ровно на пороге пропустит ошибку, при которой правило срабатывает на любое количество.
4. Договоритесь, сколько живёт показанная цена
Между открытием карточки и оформлением заказа может пройти несколько часов. За это время поставщик обновит прайс-лист. Сайт должен объяснять, когда сумма окончательная, и повторно проверять её в нужный момент.
Один вариант предполагает расчёт при каждом оформлении заказа. Другой сохраняет коммерческое предложение на оговорённый срок. В обоих случаях пользователю нужно заранее знать правило. Формулировку и условия подтверждения согласуйте с ответственными сотрудниками компании.
Если цена изменилась, покажите старую и новую суммы до завершения покупки. Дайте человеку просмотреть изменившиеся позиции. Простое уведомление «Корзина обновлена» скрывает смысл и заставляет самостоятельно искать разницу.
У сохранённой корзины должен быть статус проверки. Когда сведения о цене устарели, кнопка оформления может сначала запустить пересчёт. После успешного ответа корзина показывает актуальные условия. При недоступности источника цены компания выбирает безопасное для своего процесса действие, например заявку на подтверждение менеджером.
Не подменяйте отсутствие цены нулём. Нулевая сумма может означать бесплатный товар, подарок или ошибку обмена. Для неизвестного значения используйте отдельное состояние. Оно должно корректно отображаться и в карточке, и в корзине, и в отправленном заказе.
Проблемы актуальности часто связаны с ошибками обмена 1С с сайтом. Во время разработки оптового каталога мы в Feature IT связываем интерфейс с источником цен и согласуем поведение страницы на случай задержки обновления. Для обсуждения нужны примеры текущих прайс-листов и договорных правил.
5. Проверьте, кому доступны персональные значения
Закрытая цена должна оставаться доступной только тому пользователю, которому компания её назначила. Скрытие числа в браузере решает задачу отображения, но данные могут по-прежнему уходить в ответе сервера. Проверка доступа нужна до передачи персональной информации.
Попросите разработчика показать ответы сайта для гостя и для вошедшего клиента. В гостевом ответе должны оставаться только разрешённые сведения. Это касается карточки товара, поиска, выгрузки каталога и служебных методов получения цены.
Отдельно проверьте сохранённые ответы. Сайт может временно хранить готовую страницу или результат расчёта, чтобы быстрее отдавать его при повторном запросе. Это называется кэшированием. Для персональных данных правило хранения должно учитывать пользователя и условия, от которых зависит цена.
Учебный тест выглядит так: первый клиент открывает товар, затем второй клиент открывает тот же адрес. Второй должен получить собственные условия. Повторите проверку после выхода из кабинета и в отдельном браузере. Такие действия дают понятный бизнесу сценарий приёмки, хотя техническая проверка на сервере остаётся необходимой.
Если каталог отправляют файлом, доступ к выгрузке тоже нужно ограничить. Ссылка, которая работает без входа, может быть переслана другому человеку. Решите, допустимо ли это для вашей модели продаж. При закрытой выгрузке контролируйте права при каждом скачивании и указывайте дату формирования файла.
Похожие вопросы передачи данных разобраны в статье о настройке API на сайте. API здесь означает способ, которым программы запрашивают и передают сведения. Доступность этого способа для браузера ещё не даёт пользователю права получить чужую цену.
6. Сверьте сумму после оформления
Правильная карточка товара не гарантирует правильный заказ. Цена может измениться при передаче в учётную систему, округлении или пересчёте единиц. Проверьте весь путь одного заказа до того места, где его берёт в работу менеджер.
В учебном каталоге крепёж продаётся коробками по сто штук. Если карточка показывает цену коробки, а обмен передаёт её как цену штуки, итог отличается в сто раз. Возле суммы нужна единица, а в передаваемых данных должно быть явное соответствие между количеством упаковок и количеством штук.
Для дробных значений договоритесь о правилах округления с владельцем расчёта. Важно сравнивать итог каждой строки и общую сумму. Если сайт округляет цену раньше учётной системы, расхождение может появиться только на крупном заказе.
Храните сведения о том, какой расчёт подтвердил покупатель. Это поможет при разборе обращения: команда увидит цену на момент оформления, применённый договор и выбранное количество. Пересчитывать исторический заказ по сегодняшнему прайс-листу для такого разбора бесполезно.
Если менеджер вправе изменить цену вручную, запишите порядок согласования. Клиенту нужно показать обновлённое предложение и получить требуемое подтверждение. В истории сохраняют прежний и новый результат, автора изменения и причину. Тогда сотрудник поддержки сможет объяснить конкретное расхождение.
Как принять работу на реальных условиях
Выберите несколько обезличенных клиентов с разными договорами. Для каждого подготовьте одинаковую корзину и согласованный ожидаемый расчёт. Сначала проверьте обычный заказ, затем измените количество и организацию. Сравнивайте данные на экране с теми, которые получила учётная система.
Добавьте сценарий истёкшего договора. Команда должна решить, какие цены получит клиент после его окончания и что произойдёт с сохранённой корзиной. Если условия зависят от даты, проверьте их смену в тестовой среде, установив согласованное время. Часовой пояс расчёта следует зафиксировать заранее.
Следующая проверка касается неполных данных. Удалите цену одного тестового товара из выгрузки и посмотрите на каталог. Остальные позиции должны продолжить работать по принятой схеме. Проблемный товар получает понятное состояние, которое не превращается в бесплатное предложение.
В завершение попросите менеджера найти оформленный тестовый заказ и объяснить его сумму без помощи разработчика. Он должен видеть договор, позиции и итоговые условия. Если для ответа нужно открывать технический журнал, рабочему интерфейсу сотрудников не хватает информации.
Сохраните результаты приёмки рядом с таблицей коммерческих правил. Когда меняется скидка или тип договора, соответствующий пример обновляют вместе с настройкой. Так тестовая подборка остаётся полезной после первого запуска каталога.
Обсудите оптовый каталог с Feature IT, если персональные цены сейчас собирают вручную или они расходятся между сайтом и учётной системой. Подготовьте один обычный заказ и один спорный: по ним проще определить источник расчёта и границы первого этапа разработки.
Читайте также
