Priceman: автоматический расчёт цен и наценок по правилам

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

Наценка обычно живёт в голове у владельца и в чужом самописном скрипте: «электроника плюс 15, аксессуары плюс 40, но не ниже закупки и с окончанием на 90». Пока позиций сотня, это делается руками. На нескольких тысячах уже нет, и цены расходятся с задуманным тем сильнее, чем чаще приходит обмен из 1С.

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

Профиль отвечает на два вопроса: какие товары и как считаем. Товары отбираются инфоблоком, разделами (с вложенными или без) и деревом условий И/ИЛИ по свойствам, ценам, датам.

Внутри профиля лежит таблица правил, упорядоченная вручную. Срабатывает первое подошедшее:

• диапазон цены-источника, «от и до»; соседние диапазоны стыкуются без дыр;
  
• процент, у которого явно выбирается смысл: наценка на закупку (из 1000 получится 1300) или целевая маржа (из 1000 получится 1428). При одних и тех же 30 % это разные числа;
  
• фиксированная сумма, вместе с процентом или вместо него: упаковка, логистика, комиссия;
  
• свой шаблон округления для конкретного диапазона.
  

Наценка без границ ломает каталог на первом же нестандартном товаре. Поэтому у правила есть:

• не ниже закупки, закупки плюс N %, минимальной наценки X ₽, другого типа цены или числового свойства товара. Последнее про МРЦ, минимальную розничную цену, ниже которой поставщик запрещает продавать;
  
• не выше РРЦ (отдельный тип цены или свойство товара);
  
• порог записи: не трогать цену, если она изменилась меньше чем на X ₽ или X %;
  
• предел изменения: не менять цену, если она изменилась больше чем на X ₽ или X %. Такая позиция уходит в срез ошибок с посчитанным значением, а в каталоге остаётся прежняя цена. Так видно битую выгрузку, где закупка приехала в копейках вместо рублей.
  

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

Шаблоны округления заводятся отдельно и переиспользуются профилями и правилами: шаг (до 1, 0.5, 10, 100) или окончание цены (…90, …99, …990, …999), направление вниз, вверх или по математическим правилам.

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

У каждой строки есть колонка «Почему»: по какому правилу считалось, от какой базы, что дало округление и какой ограничитель сработал.

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

Товары без базовой цены не получают ноль. Они попадают в срез ошибок и остаются нетронутыми.

Каждый прогон сохраняется документом: профиль, снимок правил на момент расчёта, кто или что запустило, счётчики, все изменившиеся строки со значениями «было» и «стало».

Откат сверяет текущую цену со значением «стало». Если после установки цену успели изменить руками или обменом, модуль не затирает её молча, а показывает конфликт и даёт выбрать: перезаписать или пропустить.

Срок хранения документов настраивается.

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

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

Это единственное место, где модуль требует от вас настройки, а не просто работает. Разобраться стоит до покупки.

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

Рабочая схема одна, развести владение:

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

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

Совпадение источника и приёмника запрещено на уровне формы.

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

Цены-источники в другой валюте приводятся к валюте профиля, поэтому диапазоны правил остаются осмысленными на мультивалютном каталоге.

У модуля свои уровни доступа. Они раздаются группам пользователей на вкладке «Доступ» в настройках модуля:

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

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

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

• 1С-Битрикс «Управление сайтом», главный модуль 20.0.0 и выше. Модуль написан на D7.
  
• Нужны «Информационные блоки» и «Торговый каталог», то есть редакция с интернет-магазином.
  
• PHP 8.1 и выше.
  
• Нужен свободный тип цены под витрину, которого нет в выгрузке из 1С. Подробности в разделе «Как это работает с 1С».
  
• Автоматический пересчёт выполняет агент, поэтому агенты на сайте должны работать на кроне. Если они работают в режиме хитов, модуль скажет об этом на своей странице настроек.