Автоматизация ценообразования в собственных B2B и розничных каналах означает расчёт предложенной цены по утверждённым правилам с проверкой себестоимости, нижней границы маржи и исключений перед публикацией. Скрипт рассчитывает цены для всех относящихся к выбранному каналу и периоду товарных строк, ИИ помогает объяснить спорные случаи, а ответственный сотрудник утверждает изменение. Такой процесс начинается с согласованной карточки товара и правил канала. Команда «подними цену» без этих данных даёт непроверяемый результат.
Правила изменения
Предложение цены формируется только для строки, где известны себестоимость, канал и сегмент покупателя; запись новой цены проходит после проверки ограничений и ручного утверждения.
Начните с того, кто и где видит цену. В розничном магазине действует публичная цена, в B2B договор может задавать индивидуальные условия, скидку или срок действия предложения. Общая таблица без признака канала смешает эти правила. Поэтому карточка для расчёта должна содержать товарный идентификатор, действующий прайс, валюту, единицу продажи, сегмент, канал, источник себестоимости и версию правил. Ответственный за коммерческую политику закрепляет допустимые основания для изменения.
Входящие данные часто расходятся уже на уровне названий и упаковок. Сначала приведите позиции к устойчивым кодам и единицам, затем сверьте источник себестоимости с учётной системой. Разбор этого этапа есть в статье о нормализации прайса. Если у позиции пропал код или обновилась единица продажи, строка отправляется на разбор. Подтверждение требует совпадения товарного кода и единицы продажи. Отдельно проверьте товары, которые продаются комплектом: их код и себестоимость должны соответствовать именно комплекту. При смешении единичной позиции и набора расчёт создаст убедительную, но экономически неверную цену.
Для собственного сайта и отдела продаж правила можно хранить в одной версионируемой таблице, а результаты готовить отдельной выгрузкой. Редактирование правил и утверждение цен разделяют по ролям. Тогда причина изменения понятна из записи: какой вход изменился, какое правило сработало и кто согласовал итог. ИИ пригодится для текстового пояснения, когда у менеджера возник вопрос по конкретной строке.
Нижняя граница
Себестоимость для расчёта должна соответствовать товару, единице продажи и действующей версии учёта. Коммерческая команда отдельно определяет состав затрат: закупка, доставка, упаковка, обработка заказа и другие статьи, которые относятся к выбранному каналу. Маржу считают по принятой в компании методике. Порог берут из утверждённой политики для группы товаров и сегмента; универсальный порог для всего каталога способен скрыть убыточные исключения.
| Ситуация | Действие расчёта | Решение сотрудника |
|---|---|---|
| Данные полные, предел соблюдён | Создать предложение цены и указать версию правила | Сверить изменение с планом продаж |
| Себестоимость отсутствует | Остановить расчёт строки и показать источник пробела | Восстановить исходные данные |
| Цена нарушает нижнюю границу | Пометить конфликт и сохранить исходную цену | Отклонить или согласовать исключение по полномочиям |
| Договорная цена действует | Сохранить условия договора отдельно от общего прайса | Проверить срок и условия клиента |
Здесь полезна простая причинная запись: «изменились входные затраты», «порог сегмента сохранён», «расчёт остановлен из-за отсутствия себестоимости». Скрипт выдаёт такую запись вместе с исходными полями, чтобы коммерческий сотрудник сверил вывод с цифрами в учёте. Для формул и выбранного набора товаров нужен расчётный код, в котором проверяются единицы, округление и пустые значения. Языковая модель объясняет отклонение и предлагает гипотезу о его причине; окончательный вывод человек сверяет с исходной строкой.
Исключение оформляют отдельным решением с основанием и владельцем. Например, договорная уступка может быть допустима по согласованию, тогда общий алгоритм сохраняет её в журнале и показывает ответственному. Молчаливое изменение общего порога ради одной сделки разрушит проверяемость всего прайса.
Маршрут правки
Предложенный пилот можно ограничить одной товарной группой в собственном канале продаж. Возьмите копию действующего прайса и сверенную выгрузку себестоимости. Затем опишите правила сегментов и договорные ограничения на языке коммерческого сотрудника. Для запуска подойдёт расчётный скрипт с таблицей правил; Google Таблицы могут служить экраном просмотра, если объём данных и порядок доступа этому соответствуют. Скрипт обрабатывает все относящиеся к пилоту товарные строки, а таблица показывает результат для утверждения.
- Сопоставьте строки прайса с карточками товаров по устойчивым идентификаторам и сохраните исходную версию.
- Посчитайте предложения цены по версии правил; для каждой строки сохраните входы, причину изменения и проверку нижней границы.
- Выделите договорные цены, отсутствующую себестоимость, смену единицы и значения за пределами правил в очередь исключений.
- Передайте согласующему сравнительную ведомость старой и предложенной цены. После решения сохраните автора, основание и утверждённую версию.
- Выгрузите только утверждённые изменения в нужный канал и повторно сверьте опубликованный прайс с ведомостью.
Такой маршрут отделяет расчёт от записи в канал. Серверная часть проверяет роль сотрудника и факт утверждения перед изменением прайса; фраза в промпте лишь поясняет желаемый результат. Защиту доступа обеспечивает сервер. О согласовании версии каталога подробнее рассказано в материале о прайс-листах и сверке версий. В собственном канале результат публикации нужно прочитать обратно: успешная выгрузка подтверждает передачу файла, но видимую покупателю цену подтверждает только обратная сверка.
Какие исключения мешают обновлять ваш прайс по правилам?
Исключения и откат
Главная рабочая очередь состоит из строк, для которых обычное правило дало сомнительный результат. Причины лучше разделять: пробел в себестоимости, несогласованная единица, действующая договорная цена, ручная скидка или конфликт порогов разных сегментов. Каждая причина требует своего владельца. Финансовый сотрудник уточняет затратную базу, менеджер по клиенту проверяет условия договора, руководитель утверждает исключение в рамках полномочий. Один общий статус «ошибка» скрывает следующую задачу.
Представьте условную ситуацию: поставщик изменил цену упаковки, а в карточке товара осталась себестоимость за единицу. Алгоритм видит резкий скачок и останавливает предложение. Сотрудник сравнивает единицы в накладной и карточке, исправляет источник данных, затем повторяет расчёт. Языковая модель может назвать возможную причину расхождения по журналу, но исправление исходной себестоимости требует сверки документа человеком.
Выберите группу товаров с понятной себестоимостью и закрепите владельца исключений. Критерий проверки пилота — совпадение опубликованных цен с утверждённой ведомостью и наличие причины у каждой остановленной строки.
Для отката сохраните исходную версию прайса, утверждённую ведомость и отметку о фактической публикации. Если после загрузки канал показывает другую цену, ответственный возвращает предыдущую утверждённую версию и разбирает различие до следующей записи. Проверка ограничений должна работать и при повторной публикации: старая ведомость может конфликтовать с обновлённой себестоимостью или новым договором. Так процесс остаётся управляемым при изменении данных. В журнале укажите канал и группу товаров, которых коснулся возврат. Это позволит отличить локальную ошибку загрузки от проблемы в общем правиле расчёта.
Зона ответственности
Ответственность распределяют по действиям. Учётная система даёт исходные затраты, расчётный код применяет правила, ИИ формулирует понятные объяснения, коммерческий сотрудник проверяет смысл предложения, руководитель утверждает исключение, а сервер допускает запись только при нужной роли и подтверждении. Результат каждого этапа сохраняют вместе с версией данных. Такой журнал позволяет восстановить, почему цена изменилась, даже когда исходный прайс уже обновлён.
Управление ценами собственного сайта и B2B предложений имеет другие входы, чем ценообразование на маркетплейсе. Площадка добавляет собственные комиссии, акции и правила отображения. Этот контекст раскрывает статья о ценах на Ozon; текущая схема сосредоточена на каналах, где компания сама утверждает прайс и маршрут его публикации. Прогноз спроса тоже отдельная задача: для старта достаточно прозрачных входных затрат и правил.
Чтобы расширять процесс, проверьте качество идентификаторов, право на редактирование правил, наличие договорных условий для B2B клиентов и возможность обратного чтения опубликованной цены. Затем сравните журнал решений с фактическим прайсом и разберите расхождения. Если требуется связать учёт, таблицу согласования и каналы продаж, обсудите автоматизацию бизнес-процессов под ваш прайс. Напишите нам, и мы оценим состав работ по вашим источникам данных и правилам согласования. Решение о расширении принимайте по доле строк с подтверждёнными входами, качеству очереди исключений и возможности объяснить каждую опубликованную правку. При росте каталога эти проверки сохраняют свой смысл.
Стоимость проекта зависит от качества карточек, числа каналов, сложности сегментов и требований к журналу решений. Смета должна показывать отдельно расчёт правил, обработку исключений, маршрут утверждения и сверку публикации. Так легче увидеть, какие исходные данные команда готовит сама, а какие связи и проверки входят в работу подрядчика.