Согласование цен позиции заказа: 4 статуса, встречное предложение, автозакрытие

Отдельная сущность под каждое снижение цены

В AIERP цена позиции заказа — это контрактное значение. Менять её «по ходу» нельзя без следа: любое снижение проходит через отдельную заявку на согласование, которая фиксирует, кто запросил, сколько было, сколько просят, насколько это меньше (в рублях и процентах), кто одобрил или отклонил и с каким комментарием. Это не «галочка в интерфейсе» — это полноценная сущность с мягким удалением, поиском по ключевым полям и полным журналом изменений.

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

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

Повышение цены — без согласования, понижение — только с заявкой

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

Сценарий: менеджер видит, что клиент готов взять три позиции по чуть более высокой цене (например, +3% за срочную сборку). Раньше пришлось бы создавать «согласование на повышение» (что абсурд) или править цену напрямую (без следа). Теперь он подаёт «заявку на повышение» через ту же операцию — но получает мгновенное обновление с сообщением «цена повышена напрямую», без участия руководителя. «Зачёркнутая» цена сохраняет историю, журнал фиксирует изменение позиции.

Снижение цены — другая история. Сразу создаётся заявка со статусом «Ожидает», возникает событие «создана» и в фоне отправляется уведомление всем пользователям с правом одобрять цены. Пока статус «Ожидает», цена позиции не меняется — даже если позицию в заказе обновляют по другим полям, цена остаётся прежней.

4 статуса жизненного цикла заявки и защита от двух активных

Статусы фиксированы: Ожидает рассмотрения (по умолчанию), Одобрена, Отклонена, Закрыта. В интерфейсе доступна полная карта статусов с русскими названиями. Хелперы для каждого статуса позволяют ветвить логику без сравнения строк.

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

«Закрыта» — финальный, для случая «заявка перестала быть актуальной». Главный сценарий — автозакрытие при продаже: когда позицию переводят в «Реализована» (позиция реализована — деньги получены, товар у клиента), фоновый процесс массово переводит активные заявки этой позиции в «Закрыта» и проставляет дату закрытия. Так в списке «Ожидает» не висят «зомби» по уже завершённым позициям.

Защита от двух активных заявок: при создании система проверяет, есть ли уже заявка в статусе «Ожидает» по этой позиции. Если есть — возвращается ошибка «уже есть активная заявка». На одну позицию — одна активная заявка в один момент времени. Это устраняет гонки и противоречивые решения «один одобрил на 18 000, другой — на 16 000».

Встречное предложение: альтернатива «отклонить и переподать»

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

Если итоговая цена задана — система одобряет заявку именно по ней, а не по запрошенной. Внутри: итоговая цена = переданное значение или запрошенная цена (если не передали). Позиция обновляется: новая цена = итоговая, «зачёркнутая» — если её не было. Заявка обновляется так: статус «Одобрена», согласующий, комментарий, запрошенная цена заменяется на фактически согласованную, разница и проценты пересчитываются по новой цене, дата рассмотрения фиксируется. Оригинальный запрос менеджера остаётся в комментарии согласующего («одобрено по 19 500 вместо запрошенных 18 000»).

Это убирает пинг-понг «отклонил → переподай → отклонил → переподай». Согласующий сразу ставит цену, на которую готов, и инициатор моментально видит через уведомление результат: «одобрено по 19 500». Если не устраивает — менеджер обсуждает с руководителем напрямую, но процесс в системе уже завершён.

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

Решение «согласовывать или нет» зависит от маржи. Маржа = цена − закупочная цена. Если закупочная не проставлена, маржу не посчитать, и руководитель решает «на ощупь». AIERP это закрывает двумя механизмами.

Первый: при создании заявки система проверяет закупочную цену позиции. Если она не положительная, в фоне отправляется уведомление. Оно находит всех с правом видеть закупочные цены — это менеджеры закупа — и каждому шлёт сообщение «Не указана закупочная стоимость по товару „X" в заказе №Y. Проставьте закуп». В данных уведомления — идентификатор позиции, заказа, название товара, ссылка.

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

Когда закуп проставлен, карточка заявки подтягивает закупочную цену (и минимальную закупочную со склада) прямо на верхний уровень. Интерфейс страницы согласования читает оттуда и показывает руководителю реальную маржу в строке заявки: «было 54 900, просят 49 900, закуп 38 200, маржа упадёт с 30.4% до 23.4%». Решение принимается на цифрах, а не на чутье.

Уведомления, события, журнал

Жизненный цикл заявки полностью прокачан через события и фоновые задачи. При создании возникает событие «создана», при одобрении или отклонении — «рассмотрена» (с указанием действия: одобрено/отклонено). Слушатели транслируют изменения в реальном времени, обновляют счётчик «новые согласования» в шапке у пользователей с правом одобрять, и пишут метрики.

Параллельно работает уведомление в двух режимах. «Создана»: рассылка всем с правом одобрять цены, текст содержит знак изменения («увеличение/уменьшение на N%»). «Рассмотрена»: точечно инициатору, текст «одобрена ✅» либо «отклонена ❌» с эмодзи. Для интеграции с Telegram/email — те же фоновые задачи отправки уведомлений.

Журнал — двухслойный. Автоматическое логирование пишет создание, изменение, удаление, восстановление, принудительное удаление с разницей полей. Параллельно мягкое удаление гарантирует, что удалённые заявки физически остаются — восстановление возможно. Это критично, если кто-то «спрятал» неудобную заявку: её всё равно найдут.

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

Фильтры, группировка, статистика, массовые действия

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

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

Группировка по инициатору меняет сортировку на «сначала по инициатору, затем по дате создания (по убыванию)». Интерфейс получает плоский список, уже сгруппированный по сотрудникам с актуальными датами внутри группы — расставляет заголовки групп без второго запроса. Это паттерн «дешёвая группировка»: одна выборка, интерфейс строит заголовки.

Действия «статистика» (счётчики по статусам с учётом фильтров) и «инициаторы» (список инициаторов с количествами) — для виджетов дашборда и отчётов. Массовые операции принимают список идентификаторов и общие параметры (комментарий согласующего, итоговая цена; причина отклонения). Система обходит список, вызывает одобрение или отклонение по одной (с сохранением всей валидации и журнала), и возвращает «одобрено столько-то, не прошло столько-то, перечень не прошедших с причинами». Интерфейс показывает таблицу «прошли» / «не прошли с причиной» — никакого «всё или ничего».