Концепт «СнабЛиния»

Повторная закупка начинается с принятого заказа. Изменившиеся остатки, условия и замены видны до согласования.

Концепт-проект: «СнабЛиния» — вымышленная компания. Результатов работы здесь нет: только решения и гипотезы.

О заказчике

• Сценарий: Повторные заказы промышленных расходников
• Участники: Закупщик, согласующий и менеджер поставщика
• Первая версия: История заказа, актуализация, согласование и документы
• Граница: Не подбор оборудования и не замена всей учётной системы
• Данные: Компании, позиции, суммы и события являются учебными

Задача

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

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

Риски исходного процесса

Копия заказа сохраняет старые условия

Новый черновик сверяется с актуальным источником, а отличия видны до подтверждения.

Замена попадает без решения

Предложенная альтернатива требует выбора пользователя и проверки единиц, количества и условий.

Одобрение относится к старой версии

После существенной правки ранее принятую версию нельзя использовать как основание новой отправки.

Повтор создаёт второй заказ

Ключ операции связывает подтверждение с результатом; поддержка может восстановить неизвестное состояние.

Решение

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

Закупщик отправляет конкретную версию на согласование. Руководитель видит сумму, изменённые условия и основание. После правки одобрение пересматривается. Принятый заказ получает отдельный номер и историю; повтор отправки не создаёт вторую покупку. Финансовый учёт и юридически значимый документооборот интегрируются только в согласованной границе.

Как устроен продукт

1. История закупок. Заказы с составом, документами и связью новой попытки. Зачем: Повтор начинается с известного основания.
2. Новый черновик. Позиции, единицы, упаковки и текущая доступность. Зачем: Копирование не выдаёт прошлое за актуальное.
3. Изменения и замены. Старые и новые условия, доступные варианты и решение. Зачем: Предложение не становится закупкой само.
4. Согласование. Версия, сумма, основания и комментарий руководителя. Зачем: Одобрение относится к конкретному составу.
5. Принятый заказ. Результат операции, этап обработки и документы. Зачем: Повторный запрос восстанавливает состояние.
6. Контроль обмена. Источник, время сверки, ошибки и процедура восстановления. Зачем: Недоступный источник не превращается в нулевой остаток.

Что помогает пройти сценарий

Повтор с явной разницей

Сохраняем связь с прежним заказом, показывая текущие условия новой попытки.

Одобрение версии

Затронутые параметры пересматриваются после правки. Сервер проверяет роль и разрешённый лимит.

Замена с основанием

Альтернатива показывает упаковку и единицы. Выбор фиксируется до отправки на согласование.

Ключевые сценарии

Повторить закупку

Прежний состав становится новой проверяемой попыткой.

На входе: В заказе были три позиции; одна упаковка изменилась, другой товар временно недоступен.

1. Выбрать исходный принятый заказ.
2. Создать новый черновик со связью.
3. Сверить текущие условия и единицы.
4. Разрешить изменения до согласования.

На выходе: Новая версия показывает актуальный состав и основания отклонений.

Если что-то пошло не так: Недоступный источник отмечается как отсутствие проверки, а не отсутствие товара.

Критерий приёмки: Исходный заказ не меняется; новый не использует старые условия без явного решения.

Согласовать новую версию

Подтверждение относится к показанному составу.

На входе: Закупщик отправил версию на согласование, затем изменил количество одной позиции.

1. Открыть актуальный состав и изменения.
2. Проверить права и пределы согласующего.
3. Сопоставить версию с подтверждением.
4. Принять или вернуть с объяснением.

На выходе: Заказ проходит дальше только с основанием для актуальной версии.

Если что-то пошло не так: Устаревшее одобрение не отправляет изменённый состав поставщику.

Критерий приёмки: Журнал связывает пользователя, версию и решение; исполняется именно принятый состав.

Выбрать замену

Предложенная альтернатива сохраняет решение закупщика.

На входе: Нужный расходник отсутствует; поставщик предлагает другое число единиц в упаковке.

1. Сравнить назначение, упаковку и условия.
2. Пересчитать количество в согласованной единице.
3. Зафиксировать выбор и изменение суммы.
4. Повторить затронутое согласование.

На выходе: Альтернатива включена только после принятого решения.

Если что-то пошло не так: Неизвестная единица блокирует автоматический пересчёт; менеджер уточняет условия.

Критерий приёмки: Итоговый заказ не содержит невыбранной замены и совпадает с одобренной версией.

Роли пользователей

Закупщик

Повторяет принятую закупку и разбирает изменения.

Что осталось прежним и какие позиции нужно решить?

Согласующий

Проверяет конкретную версию в пределах полномочий.

Что покупаем и какие условия изменились?

Менеджер

Работает с принятым заказом и исключениями обмена.

Есть ли основание для передачи и какая версия принята?

Как устроено технически

Предметная модель

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

Операции и конкуренция

Проверяем актуальную версию при сохранении. Идемпотентное подтверждение возвращает один связанный результат.

Интеграция учёта

Согласовываем владельца данных и направление обмена. Повтор внешнего события не создаёт второй заказ.

Документы и права

Доступ определяется организацией и ролью. Ссылка на документ не предоставляет права другой компании.

Что входит в разработку

• Одна модель расходников и единиц
• Организации и роли
• История с повтором закупки
• Актуализация из одного источника
• Разбор изменений и замены
• Согласование конкретной версии
• Принятие заказа и восстановление
• Документы с проверкой доступа
• Журнал и испытание обмена

План реализации

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

Что замеряем после запуска

• Понятность изменений — Проверяем, обнаруживает ли закупщик изменённую упаковку, недоступную позицию и новые условия.
• Целостность одобрения — Исполненный состав совпадает с одобренной версией; существенная правка требует нового основания.
• Отсутствие дублей — Параллельные повторы одной операции дают один принятый заказ и согласованные последствия.
• Доступ организации — Проверяем документы и заказы с пользователями разных компаний. Это критерии приёмки, не полученные метрики.

Стек

React, TypeScript, PostgreSQL, API учётной системы.

Все кейсы · Услуга · Калькулятор стоимости

Шесть экранов рабочего сценария

Полноценные макеты на русском: выбор, решение, история и мобильный маршрут. Данные вымышлены; достигнутые результаты не заявляются.