Для автоматизации отгрузки после выбора склада нужна цепочка статусов, где каждый шаг меняет остаток и документ в учётной системе только при выполненном условии: остаток подтверждён, резерв создан, товар собран, накладная выпущена, груз принят перевозчиком. Языковая модель в этой цепочке объясняет исключения и пишет сообщения клиентам, а менять статус может только сервер по правилам. Схема рассчитана на склад с учётной системой, где остатки ведутся по позициям.
Остаток и резерв
Отгрузка запускается только после резерва: скрипт проверяет доступный остаток, создаёт резерв под заказ и лишь затем отправляет заказ на комплектование.
Склад уже выбран: куда отправлять заказ, решает отдельная задача, и её разбирает статья про распределение заказов по складам. Эта статья начинается на следующем шаге, когда заказ лежит в очереди выбранного склада и должен дойти до перевозчика.
Условный пример: интернет-магазин товаров для дома получил заказ на три позиции. Физический остаток по одной из них показывает пять штук, но две уже отложены под другие заказы. Доступный остаток равен физическому за вычетом резервов, и именно его проверяет скрипт. Если доступного хватает, создаётся резерв, а если нет, заказ уходит в ветку исключений и ждёт решения оператора.
Если товар продаётся через несколько каналов, резерв должен учитывать их все. Иначе два заказа из разных мест займут одну и ту же последнюю единицу, и расхождение вскроется только при подборе. Поэтому запись резерва проходит через единую точку в учётной системе, а каналы читают доступный остаток оттуда и обходятся без собственных копий.
- Доступный остаток считает учётная система или склад, цифры в модель приходят готовыми и остаются без пересчёта.
- Резерв создаётся одной операцией на все позиции заказа, чтобы избежать частичного резерва.
- Повторный вызов с тем же номером заказа возвращает существующий резерв и дубль исключён.
Подбор и документы
Когда резерв подтверждён, система формирует лист подбора: позиции, ячейки, количество. Кладовщик отмечает собранное сканером или в приложении. Каждая отметка меняет статус позиции, а статус заказа становится «собран» только при совпадении всех строк с резервом.
Сканирование при подборе служит проверкой: код позиции сверяется с листом, и лишний или неверный товар отклоняется сразу, ещё до упаковки. Расхождение превращается в исключение с кодом, и заказ остаётся в комплектовании, до решения оператора по недостающей позиции.
| Статус заказа | Кто меняет | Условие перехода |
|---|---|---|
| Зарезервирован | Сервер | Резерв создан по всем позициям |
| В комплектовании | Сервер | Лист подбора выдан сотруднику |
| Собран | Кладовщик через сканер | Количество совпало с резервом |
| Документы готовы | Сервер | Накладная и упаковочный лист сформированы |
| Передан перевозчику | Сервер по подтверждению | Получен номер отправления |
Документы формирует учётная система по шаблонам: накладная, упаковочный лист, этикетка перевозчика. Подписание документов и назначение номеров остаются за системой и людьми, у модели таких прав нет. Если нужно подсказать кладовщику, где искать позицию или как упаковывать хрупкий товар, помогает чат-бот склада, который отвечает по инструкциям, а любые правки в учёте для него закрыты.
Передача перевозчику
Передача — единственный шаг, после которого посылка выходит за пределы склада, поэтому проверок здесь больше. Сервер сверяет количество мест, вес по документам и этикетки, затем отправляет заявку в систему перевозчика по его программному интерфейсу и сохраняет присвоенный номер отправления. Номер возвращается ответом на заявку, и до его получения статус «передан» остаётся недоступным.
Порядок проверок перед передачей зафиксирован, и любой пропуск шага сервер отклоняет.
- Проверьте, что накладная выпущена и количество мест совпадает с упаковочным листом.
- Отправьте заявку перевозчику и дождитесь номера отправления в ответе.
- Сохраните номер в заказе и привяжите его к этикетке.
- Подтвердите приём актом или отметкой курьера и только после этого меняйте статус.
Если перевозчик вернул ошибку, заказ остаётся в статусе «документы готовы», а причина записывается рядом. Повторная отправка допустима после исправления причины: сервер хранит номер заказа и номер отправления и блокирует вторую заявку, пока первая остаётся открытой. Подробнее об общем маршруте заказа от приёма до подтверждения рассказывает материал про обработку заказов.
Разбор исключений
Исключения возникают на каждом шаге: на полке оказалось меньше товара, чем в учёте, при подборе нашёлся брак, перевозчик отклонил адрес, клиент попросил изменить состав. Скрипт ловит такие случаи по правилам и переводит заказ в отдельный статус с кодом причины.
| Исключение | Что делает скрипт | Что предлагает модель | Решает человек |
|---|---|---|---|
| Нехватка при подборе | Снимает резерв и фиксирует расхождение | Варианты: частичная отгрузка или ожидание | Оператор выбирает вариант |
| Брак товара | Блокирует позицию и создаёт акт | Текст клиенту с вариантами замены | Менеджер подтверждает замену |
| Отказ перевозчика | Возвращает заказ к документам | Объяснение причины простыми словами | Оператор уточняет адрес |
Модель получает от скрипта код причины и короткие факты заказа, а возвращает черновик пояснения для оператора и текст сообщения клиенту. Пересчёт остатков и смена статуса закрыты для неё правами на сервере. Работает это как очередь: оператор видит исключение, читает подсказку и нажимает нужное действие.
Накопленные исключения полезны и как источник улучшений. Для этого фиксируйте код причины в каждом случае. Через период по таблице видно, какие причины повторяются, и часть работы переходит к устранению источника: неверный остаток в карточке, ошибочный адрес в форме заказа, неточный вес в описании товара. Каждую такую причину закрывает владелец данных, а модель в этом разборе помогает сгруппировать похожие обращения и описать закономерность словами для планёрки склада.
Какие исключения чаще всего останавливают ваши отгрузки?
Статус клиенту
Клиент узнаёт о заказе из уведомлений, и каждое привязано к статусу, который выставил сервер: заказ собран, передан перевозчику, получен номер отправления. Текст сообщения модель может подготовить по шаблону, но отправляется он только после смены статуса, и факт события берётся из учётной системы.
Для интеграций между складом, учётной системой и перевозчиком удобны вебхуки: система сообщает о смене статуса сама, и опрос по кругу отпадает. Входящие события проверяются подписью и обрабатываются идемпотентно, чтобы повторная доставка одного уведомления вела к одному письму клиенту.
Для исключений клиент получает другое сообщение, чем для штатного хода. В нём названа причина задержки, предложены варианты и указан способ ответить. Тон задаёт шаблон, фактами служат данные заказа, а менеджер видит текст до отправки и может его поправить.
- Сообщение формируется из подтверждённого статуса и номера отправления, домыслов в тексте нет.
- Для исключений клиенту уходит нейтральное пояснение и предложение вариантов, окончательный ответ подтверждает менеджер.
- Все отправленные сообщения сохраняются вместе со статусом, на основании которого они созданы.
Журнал событий отгрузки пригодится при спорах с клиентом и перевозчиком: по нему восстанавливается, когда создан резерв, кто подтвердил сборку, какой номер присвоен и какое сообщение ушло. Храните его в учётной системе рядом с заказом, а доступ к записям ограничьте ролями склада и службы поддержки.
Нарисуйте цепочку статусов своей отгрузки на одном листе и подпишите рядом с каждым переходом, кто его выполняет. Все переходы без владельца отдайте серверу или назначьте ответственного, а подключение модели начинайте с одного исключения, например нехватки при подборе.
Когда цепочка работает без сбоев, её можно расширять на другие склады и перевозчиков в рамках общей автоматизации бизнес-процессов.