Управление заказами: 11 статусов, умные подсказки, авторасчёт по позициям
Заказ в AIERP — это единая запись с 11 чёткими статусами (Новый, Подтверждён, В обработке, В пути, Поступил, Отгружен, У доставщика, Закрыт, На отмене, Отменён, Думает) и 6 способами оплаты (Наличные, Карта, Безнал, Кредит, Рассрочка, Онлайн). Статус заказа не выставляется руками — он рассчитывается из 13 статусов позиций и принятых оплат, с учётом заявок поставщикам. 5 видов умных подсказок и 3 сводных баннера предупреждают о горящих сроках, неуведомлённых клиентах, открытых проблемах и подтверждённых, но неоплаченных заказах. Доступ к заказу даётся по магазину оформления или магазину получателя плюс через подписку наблюдателей, документы (УПД, счета, акты) формируются одной операцией.
Что получает бизнес от модуля
11 статусов заказа из коробки
Новый, Подтверждён, В обработке, В пути, На отмене, Отменён, Закрыт, Поступил, Думает, Отгружен, У доставщика. У каждого свой смысл и набор разрешённых действий — менеджер не может «случайно» перевести заказ в финальное состояние.
Авторасчёт статуса из позиций
Статус заказа не верит ручному вводу: он вычисляется из агрегата по 13 статусам позиций (ожидает → заказан → в пути → принят → реализован) и принятых оплат — Подтверждён, Закрыт, Поступил, Отгружен и так далее. Финальные «Отменён/На отмене» уже не пересчитываются.
Все каналы в одной системе
Розничные продажи на кассе, оптовые заказы, заявки с сайта, маркетплейсы — одна модель заказа с указанием источника и организации-продавца. У каждого канала свои документы и оплаты, но общий список и отчёты.
5 видов умных подсказок
Система считает 5 видов подсказок по простым правилам: просрочена отгрузка, срок горит, есть открытые проблемы, готов к выдаче, но клиент не уведомлён, заказ подтверждён, но не оплачен. На странице — 3 сводных баннера по этим же темам.
Доступ по двум магазинам и наблюдатели
Сотрудник видит заказ, если у него есть доступ к магазину оформления ИЛИ магазину получателя. Через подписку наблюдателей можно подключиться к чужому заказу — увидеть его независимо от своих магазинов.
Заявки поставщикам
Если товар нужно заказать у поставщика — на позицию создаются заявки с собственным идентификатором, 13 статусами (от «ожидает обработки» до «реализован»/«отменён») и 3 статусами подтверждения. Одна позиция → несколько заявок: разные склады-отправители, накладные, закупочные цены.
Согласование цен по позиции
Цены ниже порога ловятся и отправляются на согласование. Хранятся согласованная и первоначальная цена, а также верхняя граница допустимой скидки. Без согласования заказ не уйдёт «в работу».
Документы УПД и финансовый контур
Одной операцией формируются УПД, счёт, акты приёмки. Связь с платежами, возвратами, актами возврата — финансы и возвраты считаются по тем же первичкам.
Полный журнал изменений
Каждое создание, изменение, удаление и восстановление пишется в журнал. Плюс отдельные понятные записи: подтверждение, переход в «Думает», изменение даты доставки, начисление бонусов, смена способа оплаты и так далее.
Что входит в Заказы
- 01
11 статусов заказа
Новый, Подтверждён, В обработке, В пути, Отменён, На отмене, Закрыт, Поступил, Думает, Отгружен, У доставщика. Каждый — отдельное чёткое значение для безопасной работы и валидации в интерфейсе.
- 02
13 статусов позиции
ожидает обработки, запросили у поставщика, заказан, подготовлен у поставщика, в пути, принят на складе, подготовлен на складе, подготовлен в магазине, загружен в машину, поступил, реализован, передан доставщику, отсутствует. Эти статусы агрегируются и определяют общий статус заказа.
- 03
Заявки поставщикам с идентификатором и подтверждением
Заявка на товар поставщику: собственный идентификатор, статус (13 значений, включая «в списке водителя» и «отменён»), статус подтверждения (ожидает/подтверждена/отклонена), накладная поставщика, его внутренний номер заказа, ссылка на УПД, дата самовывоза, дата заказа. Одна позиция → несколько заявок.
- 04
6 способов оплаты
Наличные, Банковской картой, Безнал, Кредит, Рассрочка, Онлайн. Изначальный выбор клиента сохраняется отдельным полем — для аудита смен.
- 05
Доступ к заказу по 2 магазинам
Сотрудник видит заказ, если его перечень доступных магазинов пересекается с магазином оформления ИЛИ магазином получателя. Если у пользователя нет ограничений по магазинам (директор сети) — доступ ко всем.
- 06
Наблюдатели заказа
Сотрудник подписывается на чужой заказ и видит его независимо от своих магазинов. Используется для контроля сделок руководителем и для совместной работы юриста и менеджера.
- 07
Подсказка: просрочена отгрузка
Если плановая дата отгрузки уже прошла и статус не финальный, система показывает «Дата отгрузки просрочена на N дней» с действиями «Поменять дату» / «Уведомить клиента» прямо в строке заказа.
- 08
Подсказка: срок горит
Если до плановой отгрузки осталось мало дней и заказ ещё не отгружен и не у доставщика, баннер показывает «Срок горит — отгрузка через N дней, заказ ещё в работе» — менеджер не пропустит подготовку.
- 09
Подсказка: есть открытые проблемы
Если у заказа есть открытые проблемы и он активный, подсказка зовёт «Открыть проблемы». Связано с модулем «Проблемы» — открытые проблемы по заказу всегда наверху списка.
- 10
Подсказка: клиент не уведомлён
Если статус подходит для выдачи, но клиент не уведомлён, подсказка зовёт уведомить клиента. Чтобы товар не лежал «в углу» по две недели без звонка.
- 11
Подсказка: подтверждён, но не оплачен
Если заказ подтверждён, прошло несколько дней с момента подтверждения, а сумма оплат меньше суммы заказа — подсказка с расчётом «Подтверждён 4 дня назад, осталось получить 23 400 ₽» и переходом в оплаты.
- 12
Сводные баннеры по странице
По всему списку заказов на странице: сколько горящих или просроченных, сколько готовых без уведомления, сколько с открытыми проблемами. Меняют тон страницы — фильтр в один клик.
- 13
Сборка и склад позиции
У позиции есть склад-отправитель (откуда едет), организация закупки, физическое местоположение (ряд, стеллаж, полка, ячейка), ожидаемая дата прибытия, дата получения, дата закрытия. Складские сотрудники видят, где лежит конкретная позиция.
- 14
Ценовая история и бонусы по позиции
У позиции хранятся текущая и первоначальная цена, текущая и первоначальная закупочная цена, закупочная цена с расходами, закупочная скидка, бонус продавца (сумма и категория бонуса), флаг ручного бонуса, накопленные и применённые бонусы клиента с их датами.
- 15
Больше 30 фильтров на список
Номер, источник, тип клиента, статус (массив), организация-продавец, компания, клиент (по идентификатору, ФИО, телефону, e-mail), магазин оформления, магазин получателя, способ оплаты, есть сборка/доставка/проблемы, в работе/у кого в работе, кто подтвердил, поиск по тексту и по позициям, диапазон дат создания и плановой отгрузки, сортировка, диапазон сумм.
- 16
Конструктор массовых действий
Пакетные операции по списку заказов: массовая отправка УПД, массовое уведомление клиентов, перевод набора заказов в новый магазин получателя, перерасчёт бонусов. Действия настраиваются в админке без программистов.
- 17
Полный журнал изменений
В журнал пишутся: создание, изменение, удаление, восстановление, смена даты доставки, изменение оплаты, организации, склада-получателя, начисление и возврат бонусов, переход в «Думает» и подтверждение, добавление/удаление/изменение позиций, ручное переопределение «не вина менеджера».
- 18
Связанные объекты и вложения
У заказа есть позиции, услуги (доставка и сборка), платежи, файлы, комментарии (с предпросмотром последнего), замечания руководителя, возвраты, наблюдатели. Всё в одном объекте без ручных склеек.
- 19
Действия через интерфейс и интеграции
Полный набор операций: создание из модального окна, активные магазины, магазины сотрудника, счётчики статусов, счётчики фильтров, менеджеры, кандидаты в наблюдатели, источники, восстановление, массовые действия, подтверждение, перевод в «Думает», отмена, согласование отмены (с отдельным правом доступа), отказ от отмены, реализация, акт приёмки, генерация УПД, отметка об отгрузке.
Как это выглядит в системе
Частые вопросы
Сколько статусов у заказа?
Одиннадцать: Новый, Подтверждён, В обработке, В пути, Отменён, На отмене, Закрыт, Поступил, Думает, Отгружен, У доставщика. Каждый имеет свой смысл и набор разрешённых действий, а в интерфейсе доступна полная карта статусов с русскими названиями.
Кто выставляет статус заказа?
Система — автоматически, по агрегату статусов позиций и оплат. Менеджер не выставляет статус руками для активных заказов — это исключает расхождения между «формальным» и реальным состоянием. Финальные «Отменён/На отмене» уже не пересчитываются. Для исключительных случаев есть принудительная смена статуса с логированием.
Сколько статусов у позиции заказа?
Тринадцать: ожидает обработки, запросили у поставщика, заказан, подготовлен у поставщика, в пути, принят на складе, подготовлен на складе, подготовлен в магазине, загружен в машину, поступил, реализован, передан доставщику, отсутствует. Они отражают физический путь товара от заявки до выдачи клиенту.
Что такое заявка поставщику?
Это запись на товар к поставщику. У позиции может быть несколько таких заявок — например, часть заказали у поставщика A, часть у B, часть везут со склада. У каждой заявки есть собственный идентификатор, статус (13 значений, включая «в списке водителя» и «отменён»), статус подтверждения (ожидает/подтверждена/отклонена), накладная поставщика, его внутренний номер заказа, ссылка на УПД, дата самовывоза, первоначальная дата самовывоза, дата заказа.
Какие способы оплаты поддерживаются?
Шесть фиксированных: Наличные, Банковской картой, Безнал, Кредит, Рассрочка, Онлайн. Изначальный выбор клиента хранится отдельным полем — если потом сменили способ, история сохранится. Сумма оплат собирается из платежей с фильтром «принят».
Как работает доступ сотрудника к заказу?
Сотрудник видит заказ, если его перечень доступных магазинов пересекается с магазином оформления ИЛИ магазином получателя. Это важно для перемещений между магазинами: продавец магазина-получателя видит заказ, и продавец магазина-отправителя тоже. Директор сети (без ограничений по магазинам) видит всё.
Кто такие наблюдатели заказа?
Это сотрудники, которые подписаны на чужой заказ. Например, руководитель — на крупную сделку юриста — видит его в своих списках независимо от своих магазинов. Используется для контроля, юридического сопровождения, совместной работы.
Что такое умные подсказки на заказе?
Это короткие напоминания, которые система показывает прямо в строке заказа. Возвращается первая сработавшая по приоритету: открытые проблемы → просрочена отгрузка → клиент не уведомлён → подтверждён, но не оплачен → срок горит. У каждой подсказки есть текст с подстановкой данных, основное и дополнительное действие. Это простые правила, не искусственный интеллект.
Какие бывают баннеры на странице заказов?
По коллекции заказов на странице система покажет до 3 баннеров: сколько горящих или просроченных отгрузок, сколько готовых без уведомления, сколько с открытыми проблемами. У каждого — уровень важности, основное действие и список заказов для фильтра в один клик.
Что означает «срок горит»?
До плановой даты отгрузки осталось мало дней (порог настраивается), статус заказа не финальный, и он ещё не отгружен и не у доставщика. Подсказка показывает «Срок горит — отгрузка через N дней, заказ ещё в работе», менеджер видит её и в строке заказа, и в баннере страницы.
Что значит «подтверждён, но не оплачен»?
Заказ подтверждён, прошло несколько дней с момента подтверждения, а сумма принятых оплат меньше суммы заказа. Подсказка показывает «Заказ подтверждён 4 дня назад, осталось получить 23 400 ₽» — это сигнал бухгалтерии и менеджеру вернуться к клиенту.
Можно ли отменить заказ?
Да. Заказ сначала уходит в «На отмене». Финальное подтверждение отмены требует отдельного права согласования. Отказ от отмены возвращает заказ в работу. После согласования заказ становится «Отменён» и больше не пересчитывается.
Как формируются документы (УПД, счёт, акты)?
Одной операцией. УПД получает ссылку в связанных заявках поставщикам, акт приёмки — на отдельной странице. Документы привязываются к позициям через позиции документов.
Что такое статус «Думает»?
Промежуточный статус для клиента, который ещё не определился: получил коммерческое предложение, ушёл подумать. Перевод в «Думает» сохраняет данные клиента, но не запускает сборку. Удобно для долгих B2B-переговоров — заказ не «висит в новом» и не «стартует преждевременно».
Как работают два магазина у заказа?
У заказа два связанных магазина: где оформили (магазин оформления) и куда поедет (магазин получателя). Сотрудник магазина-отправителя и сотрудник магазина-получателя видят один и тот же заказ. Отдельно фиксируется, кто взял заказ в работу (для перемещений).
Что хранят первоначальные количество и цена на позиции?
Первоначальные значения количества и цены при создании позиции. Это нужно для аудита изменений (кто и когда снизил цену, кто увеличил количество) и для согласования цен — система сравнивает текущую цену с первоначальной или с верхней границей допустимой скидки.
Кто пишет журнал изменений по заказу?
Сама система. В журнал автоматически пишутся создание, изменение, удаление, восстановление и принудительное удаление. Параллельно есть понятные именованные записи: подтверждение, переход в «Думает», изменение даты доставки, уведомление клиента, смена менеджера, добавление и удаление позиций, изменение количества позиций, начисление и возврат бонусов, смена организации, смена способа оплаты, смена магазина получателя.
Какие фильтры есть на список заказов?
Больше 30: идентификатор, номер, источник, тип клиента, статус (массив), организация-продавец, компания, клиент (по идентификатору, ФИО, телефону, e-mail), магазин оформления, магазин получателя, способ оплаты, есть сборка/доставка/проблемы, в работе/у кого в работе, кто подтвердил, поиск по тексту, поиск по позициям, диапазон дат создания и плановой отгрузки, сортировка, диапазон сумм.
Сколько каналов продаж поддерживается?
Источник — свободное текстовое поле, поддерживается любое количество. Можно получить список уникальных значений, которые встречались. Типовые: «Лид» (из лидов), сайт, маркетплейс, касса, опт. У каждого свои метрики в отчётах.
Может ли заказ быть оплачен бонусами?
Бонусы списываются на уровне позиции через применённые бонусы клиента и дату их применения, общая сумма заказа уменьшается. Параллельно начисление при покупке хранится в накопленных бонусах и дате их начисления. Вся эта арифметика считается отдельно и возвращает бонусы при отмене или возврате.
Что такое массовые действия?
Конструктор пакетных операций: уведомить клиентов выбранных заказов одним нажатием, сменить организацию или магазин-получателя, пересчитать бонусы по заказам, отправить УПД пачкой. Настройки действия задаются в админке, без программистов.
Что такое флаги «есть проблемы» и «не вина менеджера»?
«Есть проблемы» означает, что у заказа есть открытые записи проблем. Тогда зажигается соответствующая подсказка. «Не вина менеджера» — ручное переопределение для KPI, чтобы не штрафовать за форс-мажор; ставится руководителем и логируется.
Удаляется ли заказ физически?
Нет. У заказа, позиций и заявок поставщикам включено мягкое удаление — записи скрываются, но остаются в базе. Связи (платежи, документы, бонусы, возвраты) сохраняются. Восстановление возможно. Это нужно для аудита и юридических разбирательств.
Где хранятся комментарии, файлы, услуги к заказу?
Прямо у заказа в виде связей: комментарии (с предпросмотром последнего), файлы, услуги (доставка и сборка, у каждой свои платежи), платежи (прямые оплаты заказа), замечания руководителя сотруднику, возвраты.
Что меняется на реальной сети
- Было
- Раньше статусы заказов выставляли менеджеры руками: один писал «отгружен», когда машина ещё стоит во дворе, второй — когда клиент уже забрал. Бухгалтерия видела «отгружено», финансы видели «не оплачено», склад продолжал держать резерв. Конфликты разбирали почтой неделями.
- Сделали
- Перевели расчёт статуса на автоматический — он смотрит статусы 13-этапной позиции и оплаты и выставляет статус заказа сам: «Подтверждён» пока есть позиции в ожидании, «В пути» если хоть одна в пути, «Поступил» если все на складе, «Отгружен»/«Закрыт» по факту реализации и оплаты. Менеджеры больше не двигают статус руками.
- Стало
- Разрыв между формальным и реальным состоянием схлопнулся: что показывает система = что есть на самом деле. Бухгалтерия и склад читают один источник правды, конфликты ушли. Внедрение убрало ~14% возвратов «случайно отгрузили», потому что «Подтверждён + не оплачен» теперь подсвечено баннером.
- Было
- B2B-заказы лежали по 5–10 дней «подтверждённые, но не оплаченные» — клиент тянул с оплатой, менеджер забывал напомнить, склад держал резерв. Бухгалтерия пилила менеджеров за «висящую дебиторку», менеджеры — клиентов, клиенты — обещали и снова не платили.
- Сделали
- Включили подсказку «подтверждён, но не оплачен»: если заказ подтверждён, прошло несколько дней с момента подтверждения и сумма оплат меньше суммы заказа — в строке заказа красным «Подтверждён 4 дня назад, осталось получить 410 200 ₽» с кнопкой «Открыть оплаты». Сводный баннер на странице сразу показывает, сколько таких.
- Стало
- Менеджеры перестали забывать — подсказка не пропадает, пока заказ не оплачен или не отменён. Дебиторка прошла «жирный» этап, сборы ускорились почти на неделю. Конфликты с бухгалтерией сошли на нет — теперь они видят прогресс по тем же заказам.
- Было
- Сборщики не понимали, какой заказ горит, а какой можно отложить. Брали по дате создания, в итоге заказ от вчера с доставкой через неделю собирали раньше, чем сегодняшний «надо отправить через 4 часа». Срывы доставок копились.
- Сделали
- Включили подсказку «срок горит» по плановой дате отгрузки: если до отгрузки осталось мало дней и заказ ещё не отгружен и не у доставщика — «Срок горит». Сборщикам показали баннер сверху списка с кнопкой «Показать только горящие» — фильтр на ровно тот набор, который надо собрать сейчас.
- Стало
- Сборщики сначала закрывают горящие, потом обычные. Срывы доставок упали в 4 раза. У руководителя теперь конкретный показатель «сколько баннер показал утром vs к концу смены» — можно мерить производительность смены.
- Было
- Заказ оформляли в одном магазине, товар везли из другого — оба магазина «своим» считали именно свой. Видеть заказ в списке мог только один. Информации о статусе у второго не было — продавцы звонили, чтобы узнать «приехало уже?», и переключались, забывали.
- Сделали
- Перевели доступ на правило «магазин оформления ИЛИ магазин получателя»: сотрудник видит заказ, если у него есть доступ к одному из этих магазинов. Подключили наблюдателей для случаев, когда нужен дополнительный контроль третьих сторон — руководителя региона, юриста, специалиста по экспортным сделкам.
- Стало
- Оба магазина видят один и тот же заказ — звонки «приехало уже?» прекратились. Руководители регионов через наблюдателей видят все крупные заказы вне зависимости от магазина. Время информирования клиента упало в 3 раза.
- Было
- Часть позиций заказа была на складе, часть приходилось заказывать у разных поставщиков с разными сроками. В таблице вели «реестр позиций» — кто откуда, когда обещали, кто заказал. Постоянные ошибки: заказали дважды, не заказали совсем, забыли о подтверждении от поставщика.
- Сделали
- Перевели заявки поставщикам на отдельные записи с собственным идентификатором и статусом подтверждения (ожидает/подтверждена/отклонена). Одна позиция может породить несколько заявок — например, 5 шт. у поставщика A, 3 шт. со склада B. Накладная поставщика, его внутренний номер заказа, ссылка на УПД хранятся в заявке; статус заявки (13 значений) обновляет статус позиции, а тот — статус заказа.
- Стало
- Ошибки «заказали дважды» исчезли — система не даст создать вторую заявку на ту же позицию без действий. Подтверждения от поставщиков фиксируются, отклонения видны и автоматически возвращают позицию в ожидание. Поставщики работают по единому идентификатору, документы складываются в нужную заявку автоматически.
- Было
- При проверках налоговой не могли восстановить, кто, когда и какую цену согласовал на оптовый заказ — менеджер ставил, документ оформляли, в таблице вели «согласования» отдельно. Сходимости документов и системы не было.
- Сделали
- Включили полный журнал изменений — автоматический по всем событиям плюс понятные именованные записи: подтверждение, начисление бонусов, смена способа оплаты, смена магазина получателя, добавление позиций и так далее. На позиции хранятся первоначальная и текущая цена, первоначальная и текущая закупочная, верхняя граница допустимой скидки — видно, кто и когда менял.
- Стало
- Проверка налоговой закрылась за 4 часа вместо двух недель — все согласования цен есть в журнале, имена согласующих и времена видны. Бонус: внутренний аудит за квартал теперь проходит без авральных правок — журналу можно доверять.
Как модуль помогает розничной сети
Заказ в ERP: одна модель для розницы, опта, сайта и маркетплейсов
AIERP не делит заказы по каналам на разные сущности. Любая продажа — розничный чек на кассе, оптовый счёт B2B-клиенту, заказ с сайта, поступление с маркетплейса — это одна запись заказа с указанием источника (свободная строка) и организации-продавца. Это даёт единый список с фильтрами и аналитикой по каналам, но позволяет каждому каналу иметь свои документы, оплаты и сборку.
Структура заказа: номер, источник, статус, организация продажи и компания, контакты клиента (привязка к клиенту из базы или ручные ФИО/телефон/e-mail), магазины (где оформили, куда поедет, кто взял в работу), способ оплаты и изначальный способ, флаги услуг (есть сборка, есть доставка), флаг проблем, флаги уведомления и подтверждения клиентом, даты (плановая отгрузка и её первоначальное значение, дата взятия в работу, дата подтверждения, дата поступления, дата выдачи, дата закрытия), денежные показатели (количество позиций, общая сумма), описание.
Связи — это то, что превращает заказ в полноценный финансово-логистический объект: позиции (с 13 статусами), услуги (доставка и сборка с собственными платежами), платежи, файлы, комментарии (с предпросмотром последнего), замечания руководителя, возвраты, наблюдатели. Всё в одном объекте, без ручных склеек.
11 статусов заказа и 13 статусов позиции: явный жизненный цикл
У заказа одиннадцать чётких статусов: Новый (по умолчанию), Подтверждён, В обработке, В пути, Поступил (на склад/в магазин получателя), Отгружен, У доставщика, Закрыт (реализован и оплачен), Думает (клиент берёт паузу), На отмене, Отменён (финальный). В интерфейсе доступна полная карта статусов с русскими названиями для валидации.
У позиции тринадцать статусов, которые отражают физический путь товара от заявки до выдачи: ожидает обработки, запросили у поставщика, заказан, подготовлен у поставщика, в пути, принят на складе, подготовлен на складе, подготовлен в магазине, загружен в машину, поступил, реализован, передан доставщику, отсутствует.
Эти статусы — не «декорация» в интерфейсе, а сильный контракт. По ним пересчитывается статус заказа, выставляется подсказка, генерируются документы, считаются KPI, начисляются бонусы продавцов. Сменить статус позиции «случайно» нельзя — все переходы проходят через сервисы и логируются.
Автоматический пересчёт статуса по позициям
Главная боль учёта заказов — расхождение между «формальным» и «реальным» статусом. Менеджер пишет «отгружен», когда машина стоит во дворе; кладовщик считает позицию «принятой», когда она ещё в пути. AIERP убирает это, передавая расчёт статуса заказа автоматике.
Алгоритм: финальные «Отменён»/«На отмене» не пересчитываются; если заказ не подтверждён клиентом — статус «Новый»; есть позиции в ожидании → «Подтверждён»; все активные позиции реализованы → «Закрыт» (если оплачен полностью) или «Отгружен»; все активные = принято + реализовано → «Поступил»; есть передано доставщику → «У доставщика»; есть позиции в пути или загружены в машину → «В пути»; иначе «В обработке». Активные позиции считаются без «отсутствует» — отсутствующие не блокируют закрытие.
Проверка полной оплаты внутри суммирует платежи заказа и платежи по сервисам (доставка, сборка) с фильтром «принят» и сравнивает с суммой заказа. Если сумма ≥ — заказ «Закрыт», иначе «Отгружен». Это убирает ситуацию «отгружен и забыли о долге» — финансовый и логистический статусы синхронизированы.
Статистика по позициям агрегирует их по статусам с фильтром «не учитывать нулевые количества». Кэш означает, что массивный пересчёт не бьёт по базе на каждый чих — система умеет аккуратно сбрасывать его по событию.
Заявки поставщикам и перемещения между складами
Позиция заказа в реальной торговле редко закрывается «одной строкой со склада». Бывает: 3 шт. у поставщика A, 2 шт. со склада B, 5 шт. придётся ждать недельной поставки. AIERP моделирует это через отдельную сущность «заявка на товар», связанную с позицией заказа.
У каждой заявки 13 статусов (по сути, проекция статусов позиции плюс «в списке водителя» и «отменён»), 3 статуса подтверждения (ожидает / подтверждена / отклонена), накладная поставщика, его внутренний номер заказа, ссылка на УПД, дата самовывоза, первоначальная дата самовывоза, дата заказа, ссылки на склад-отправитель, остаток, организацию, сотрудника, обработавшего заявку. Собственный идентификатор — стабильный ключ для коммуникации с поставщиками.
Связи: заявка → позиция заказа, документы (через позиции документов на позицию заказа), комментарии, файлы, логистика, проблемы, история переносов. Это даёт полную картину судьбы каждой штуки товара в заказе — от заявки до УПД и доставки клиенту.
Бизнес-сценарии: «дозаказ» (заявка дополнительной партии под открытую позицию), «передвинуть с другого склада» (заявка со склада-отправителем = другой магазин — оформляется межмагазинное перемещение), «у поставщика подтверждено» (статус подтверждения — подтверждена, дата заказа — дата подтверждения, внутренний номер — у поставщика). Каждое действие фиксируется в журнале.
5 видов умных подсказок и 3 сводных баннера: фокус менеджера
Подсказки — это набор детерминированных правил (не искусственный интеллект, не машинное обучение — простые правила, поэтому стабильно и предсказуемо). На каждом заказе система проверяет 5 условий по приоритету и возвращает первое сработавшее: есть открытые проблемы (заказ активный и есть проблемы), просрочена отгрузка (плановая дата уже прошла), клиент не уведомлён (статус готов к выдаче, но не уведомлён), подтверждён, но не оплачен (подтверждён несколько дней назад, оплат меньше суммы заказа), срок горит (до даты отгрузки осталось мало времени).
Каждая подсказка имеет: тип, текст (с подставленными числами — «4 дня», «410 200 ₽»), основное действие («Открыть проблемы», «Поменять дату», «Уведомить клиента», «Открыть оплаты»), дополнительное действие. Это совместимо с интерфейсом — приходит с заказом и рендерится в строке заказа сразу.
Сводные баннеры считаются на уровне страницы — по коллекции. Три типа: «На странице 7 заказов с просроченным или горящим сроком отгрузки» (высокая важность, действие «Показать только горящие» — фильтр по списку идентификаторов), «Готово к выдаче, но клиент не уведомлён по 4 заказам», «Открытые проблемы по N заказам». У каждого баннера — список идентификаторов для перехода прямо к нужному набору заказов.
Это меняет работу: менеджеру не надо просматривать сотни заказов глазами. Система сама подсвечивает горящее, недоделанное и зависшее. Сборщики берут в работу горящие, менеджеры закрывают долги, операторы — уведомляют ожидающих выдачи.
Доступ по двум магазинам, наблюдатели, мульти-юрлица
У заказа два «магазинных» поля: магазин оформления (где оформили) и магазин получателя (куда товар поедет). При перемещениях это разные магазины. Правило фильтрации даёт сотруднику видеть заказ, если у него есть доступ к одному из них (или обоим). Перечень доступных магазинов пользователя пересекается с этими полями.
Если у пользователя нет ограничений по магазинам (директор сети, бэк-офис, аудит) — видны все заказы сети. Это даёт правильный баланс: продавец видит свои, руководитель региона — свой регион, директор — всё.
Сверху работает механизм наблюдателей. Сотрудник может стать наблюдателем чужого заказа (например, юрист — за оптовой сделкой, руководитель региона — за крупным перемещением, методист обучения — за заказом с жалобой). Наблюдатель видит заказ в своих списках независимо от магазинов.
Мульти-юрлица — через организацию-продавца и компанию-клиента. Это работает в связке с проверкой системы налогообложения: при создании заказа система проверяет, что система налогообложения организации-продавца совместима со способом оплаты и составом заказа.
Документы, журнал, фильтры, массовые действия
Формирование УПД, счетов, актов приёмки из заказа — одной операцией. Создаётся реализационный документ и проставляется ссылка на него в связанных заявках поставщикам. Приёмные акты со стороны клиента — отдельной операцией. Документы привязаны к позициям через позиции документов, что даёт прямую трассируемость «позиция заказа ↔ строка УПД».
Журнал изменений двухслойный. Первый слой — автоматическое логирование создания, изменения, удаления, восстановления, принудительного удаления с разницей полей. Второй слой — понятные именованные записи для бизнес-событий: подтверждение (с данными подтверждения), переход в «Думает», изменение даты доставки (старая и новая дата с причиной), бонус за задержку, уведомление клиента, смена менеджера, добавление/удаление/изменение количества позиций (с названием позиции и ценой), начисление/возврат бонусов, смена организации, смена способа оплаты, смена магазина получателя. Это даёт «человеческие» строки в журнале вместо сырой разницы.
Больше 30 параметров поиска покрывают все типовые сценарии: по номеру, источнику, типу клиента, статусу (массив — можно одновременно несколько), организации, компании, клиенту, ФИО, телефону, e-mail, обоим магазинам, способу оплаты, флагам сборки/доставки/проблем, флагу «в работе» и магазину, в котором взяли в работу, подтвердившему сотруднику, тексту (по описанию и комментариям), тексту по позициям, периоду создания и плановой отгрузки, сумме от-до, сортировке.
Массовые действия — конструктор в админке: выбрали действие, выбрали список заказов, нажали — операция применилась пачкой с логированием и веб-уведомлениями. Типовое: пакетная отправка УПД, пакетное уведомление клиентов, пакетная смена организации-получателя при реструктуризации сети.
Готовы автоматизировать?
Покажем модуль на ваших данных и подключим за 1–2 недели.