Несколько заказов на одной тележке: общий отбор без потери назначения товара

Когда объединять заказы в один отбор

В кластерном отборе сотрудник одновременно собирает несколько заказов, раскладывая товары в выделенные позиции тележки. Один визит к общей ячейке может обеспечить несколько строк. Microsoft описывает эту схему для штучного отбора с заранее связанными заказами и позициями. Microsoft Learn: cluster picking.

Здесь рассматриваются обычные товары с фиксированной единицей «штука». Переменный вес и подбор по массе в этот сценарий не входят. Применимость каждого режима проверяется отдельно; наличие двух возможностей в документации не означает, что они совместимы друг с другом.

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

Заказ, контейнер и позиция — разные идентификаторы

Заказ A остаётся тем же заказом, когда его контейнер сняли с тележки. Контейнер T101 остаётся тем же физическим местом при переносе на участок упаковки. Позиция 1 — место на конкретной тележке или в конкретном кластере; завтра там может стоять другой контейнер.

Поэтому сохраняйте связь «кластер K7 → позиция 1 → T101 → A» с моментом назначения. Аналогично позиция 2 связана с T102 и B, позиция 3 — с T103 и C. Одна цифра «1» вне своего кластера не идентифицирует заказ. Пустой контейнер можно переиспользовать лишь после завершения прежней связи и проверки отсутствия содержимого.

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

Учебный пример: общий отбор 6 X и 4 Y

Все числа условные. В заказах обычные взаимозаменяемые внутри SKU штучные товары. Каждое плановое содержимое помещается в свой контейнер; специальных условий совместного размещения в примере нет.

• A в T101: 2 X и 1 Y, всего 3 штуки.
• B в T102: 1 X и 3 Y, всего 4 штуки.
• C в T103: 3 X, всего 3 штуки.

Общий план требует X: 2 + 1 + 3 = 6; Y: 1 + 3 = 4. Всего десять штук. Исходно в ячейках хранения 20 X и 15 Y. Других движений и резервов, мешающих этому отбору, в примере нет.

Сотрудник подтверждает источник X и отбирает шесть. Затем подтверждает раскладку двух в T101, одной в T102 и трёх в T103. Для Y подтверждаются четыре отобранные, из них одна в T101 и три в T102. Сканирование источника отвечает «что взяли», проверка позиции — «куда положили». Одно не заменяет другое.

После завершённой раскладки в исходных ячейках остаётся 14 X и 11 Y, в контейнерах — 6 X и 4 Y. Общий складской итог пока не уменьшился: X = 14 + 6 = 20, Y = 11 + 4 = 15. Перемещение к упаковке ещё не является внешней отгрузкой клиенту.

Почему правильной суммы недостаточно

Предположим, X ошибочно разложили как 3 в A, 1 в B и 2 в C. Общая сумма всё равно шесть. Если Y размещены правильно, суммарно на тележке по-прежнему десять штук. Однако у A лишняя X, у C одной X не хватает.

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

Если ошибка найдена до закрытия контейнеров, связанное исправление переносит одну X из T101 в T103. Дополнительного отбора из исходной ячейки не требуется. Количество X в хранении остаётся 14; содержимое заказов становится правильным. Повторное списание одной X со стеллажа создало бы уже новую ошибку.

Нехватка одной единицы не обнуляет весь кластер

Отдельный проверочный сценарий: вместо достаточного X для отбора доступно только пять, хотя план требует шесть. По заранее согласованному решению A получает две, B одну, C две. У C остаётся одна непокрытая X. Состав Y не изменился.

Теперь в контейнерах девять подтверждённых штук. A и B могут перейти к следующему этапу после своих проверок, а C сохраняет состояние частичной сборки и конкретный остаток. Если условия требуют целого заказа, C не становится готовым к выдаче. Общий статус завершения текущего прохода не должен скрывать его недостающую строку.

Для продолжения нужен идентификатор исходной строки C и уже собранные две. Новое задание требуется только на одну X, а не на исходные три. Решение, кому досталась нехватка, должно существовать до исполнения; эта статья не заменяет политику распределения дефицита.

Полный контейнер не означает полный заказ

Другая ситуация: коробка B физически заполнилась раньше завершения своей строки Y. Оператор не должен помещать остаток в соседний свободный на вид контейнер A. Он фиксирует фактический состав B и причину остановки.

Если разрешено разбиение, B может получить два связанных места: B1 содержит 1 X и 2 Y, B2 — оставшуюся 1 Y. B2 назначают допустимому следующему проходу или другому явно определённому месту; его нельзя незаметно добавить в кластер с уже занятыми тремя позициями. Готовность B требует учёта обоих мест.

Microsoft отдельно описывает обработку заполненной позиции кластера. Конкретное поведение оставшейся работы зависит от реализации и настройки, поэтому нельзя предполагать, что кнопка «полно» сама создаст корректное продолжение. Microsoft Learn: заполненная позиция.

Данные и устойчивость подтверждений

У задания храните строку заказа, SKU, план, подтверждённый отбор, распределённое по контейнерам количество и остаток работы. У раскладки нужны кластер, позиция, контейнер, источник и событие подтверждения. Если товар уже взят, но ещё не разложен, его промежуточное состояние должно быть видно, чтобы следующий сотрудник не взял его повторно.

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

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

Приёмочный чек-лист

• Три позиции K7 однозначно связаны с T101/A, T102/B и T103/C.
• План 6 X и 4 Y раскрывается по каждому заказу.
• Ошибка X = 3/1/2 обнаруживается при правильной общей сумме шесть.
• Исправление между контейнерами не создаёт повторного отбора со стеллажа.
• При пяти доступных X у C остаётся одна, а уже собранные две сохраняются.
• Полная коробка B1 не закрывает B без второй коробки с оставшейся Y.
• Повтор события отличается от нового законного отбора такой же штуки.
• Передача другой смене сохраняет местонахождение и открытые строки.

В складе SABSUS и управлении заказами проверьте эти связи на реальной конфигурации. Поддержку кластеров, позиций, сканирования и обработки исключений подтвердите отдельно. Описание процесса не обещает готовый WMS-режим.

Частые вопросы

Общий вес или количество тележки доказывает правильную сборку?

Нет. Один заказ может иметь излишек, другой — соответствующую недостачу при правильной сумме.

Можно ли использовать номер позиции вместо номера контейнера?

Только внутри однозначно сохранённой связи. При снятии и переносе контейнеру нужна собственная идентичность.

Завершение кластера означает, что все заказы готовы?

Не обязательно. Частичные строки и дополнительные места должны сохраняться до подтверждённого исполнения.

Источники

• Microsoft Learn: system-directed cluster picking.
• Microsoft Learn: cluster position full.