Задача
Дилер не мог заказать рекламную продукцию самостоятельно. Он звонил в отдел по работе с дилерами, сотрудник вручную проверял, положен ли дилеру этот материал и в каком объёме, согласовывал исключения, выяснял наличие на складах, связывался с типографией и организовывал доставку. По описанию владельца, обработкой этого потока занималось почти 50 человек.
Отдельным ручным процессом была аренда возвратных баннеров и стендов под мероприятия: свободен ли комплект в нужные даты, кто согласует выдачу, кто везёт и кто помнит про дату возврата.
Дорого обходилась и логистика. Если части тиража не хватало, допечатку сначала отправляли на центральный склад, там объединяли с остатками и только потом пересылали дилеру. Лишнее плечо удлиняло сроки и увеличивало стоимость каждой такой заявки.
Решение
Платформа — один продукт из трёх связанных модулей: дилерского портала, DAMS и оркестратора исполнения.
Портал и допуски. Дилер входит через корпоративный SSO, и система получает его идентификатор, организацию, категорию и группы доступа. Профиль решает, какие разделы и материалы он видит, что может заказать физически, что только скачать, куда разрешена доставка и какой объём проходит без отдельного решения. Интерфейс на Magento привычно магазинный: категории, поиск, карточка, избранное, корзина, история заказов. Оплаты нет, на её месте права, лимиты, согласования и служебная стоимость исполнения. Приложения iOS/Android и iPad работают через тот же API и те же серверные правила, отдельной копии бизнес-логики в мобильном клиенте нет.
Лимит, который не блокирует. Заявка сверх допуска уходит по маршруту согласования. Матрица согласований смотрит на сочетание факторов: категорию и программу дилера, тип материала, запрошенное количество, регион, арендуемый или расходуемый тип позиции, стоимость печати и доставки, доступность и необходимость допечатки. Согласующий видит заказ, сработавшее правило, допустимый объём, превышение, предполагаемый источник исполнения и связанные затраты. Он может подтвердить заказ, согласовать уменьшенное количество, вернуть на изменение или отклонить с комментарием. После правки количества или состава правила пересчитываются заново: старое решение не переносится на новую версию заказа.
DAMS без двойного ввода. Symfony-приложение хранит рабочие файлы, макеты, PDF и производственные версии. Один файл лежит сразу в нескольких логических папках без физического дублирования, у актива есть версии и история замены. Карточка отделена от файла: к позиции привязываются варианты, главное изображение, галерея, PDF для скачивания и производственный оригинал, а маркетолог решает, что уходит в портал, а что остаётся внутренним. Публикация версионна. Повторная доставка события не создаёт вторую карточку, снятый материал исчезает из новых заказов и не ломает историю уже созданных. Ошибки синхронизации попадают в отдельную очередь с причиной и безопасным повторным запуском.
Оркестратор исполнения. Остатки нескольких WMS приводятся к единой модели: фактический, доступный и зарезервированный объём, склад и его география, время последнего обновления, габариты. Дальше для каждой строки заказа выбирается способ исполнения по полной стоимости и сроку. Сценарий владельца: дилер запросил 100 экземпляров, на складах суммарно есть 70, 30 нужно печатать. Система может отгрузить 70 со склада и 30 напрямую от типографии. Но если рядом лежат только 20, а остальные 50 на другом конце страны и их перевозка дороже или дольше локальной допечатки, дальний остаток не трогают: недостающее сразу производит подходящий вендор. Если заказ нужен к дате мероприятия, дешёвый вариант, не укладывающийся в срок, вообще не считается допустимым. Задание с приоритетом, утверждённым файлом из DAMS, тиражом, форматом, упаковкой и требуемой датой уходит прямо в производственную очередь типографии, а готовая продукция едет дилеру, минуя центральный склад.
Аренда как отдельный жизненный цикл. Календарь возвратных конструкций учитывает подтверждённые брони, время доставки и обратной перевозки, технологический буфер между арендами, текущее местонахождение комплекта и статус возврата. Бронь занимает комплект на весь операционный интервал, а не только на даты мероприятия; просрочка или неполный возврат создают исключение и влияют на следующие брони.
Четыре мастера данных. Контент — из DAMS, дилеры и допуски — из SSO, остатки — из WMS, заказ с согласованиями и планом исполнения — внутри платформы. Каждая внешняя операция идемпотентна и хранит correlation id, исходный запрос, результат и число попыток: повторный webhook не должен создать второй тираж, вторую отгрузку или двойной резерв. При частичном сбое выполненное физически не откатывается, поэтому оркестратор запускает компенсирующее действие: освободить ошибочный резерв, выбрать другого вендора, отменить ещё не начатую печать. Правила лимитов и маршрутов версионны и имеют период действия, чтобы старый заказ объяснялся настройками, которые действовали в момент его создания.
Результат
Телефонные заявки заменил единый портал самообслуживания. Дилер видит разрешённые ему материалы, запрашивает превышение лимита, следит за согласованием и статусом каждой части заказа: при разделённом исполнении у каждой посылки свой источник, этикетка и номер отслеживания, но заказ для дилера остаётся одним.
Типовые запросы проходят без ручного сопровождения, а сотрудники отдела по работе с дилерами занимаются исключениями: конфликтующим резервом, недоступным производственным файлом, невозможной датой доставки, отказом вендора, просроченным возвратом. Маркетологи управляют каталогом из DAMS, не перенося карточки руками.
Ключевой для сети стала автоматизация исполнения: платформа выбирает источник и маршрут, а прямая отгрузка убрала лишние перемещения через центральный склад. Операционная аналитика показывает, сколько заказов закрывается складом, допечаткой и смешанным режимом и какие ручные исключения пора сделать правилом.
Дилерская сеть получила прозрачный путь заказа от выбора материала до доставки или возврата конструкции, а операционная команда — единый механизм управления исключениями, производством, складами и логистикой.
