Возвраты, брак, фото дефектов и история решений

Часть товара приезжает с дефектом или мнётся при приёмке. Если это фиксировать «в тетрадке», через неделю никто не вспомнит, сколько было брака, что с ним сделали и почему. А когда селлер спрашивает «где мои 12 единиц», доказать состояние товара нечем.

На приёмке из 100 единиц 8 — с повреждённой упаковкой, 3 — без бирки (обезличка). Оператор фиксирует это прямо на приёмке, фотографирует, и по каждому виду брака заводится карточка. Дальше по ним нужно принять решение — в ремонт, вернуть в остаток, вернуть поставщику или списать — и чтобы каждое решение осталось в истории.

• Фиксировать брак на приёмке с разделением по типу и с фото.
• Вести реестр брака со статусами, а не одним полем «брак / не брак».
• Показывать, как решение влияет на доступные остатки.
• Хранить историю: кто, когда и какое решение принял.

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

Статусы брака. Карточка проходит по статусам: «На складе FF», «В ремонте», «Ожидает решения», «Возвращено в остаток», «Возврат поставщику», «Утилизация», «Архив». Исправимый брак стартует «На складе FF», неисправимый и обезличка — «Ожидает решения». Разрешённые переходы заданы матрицей: например, из «В ремонте» можно «вернулся исправным — в остаток» или «неисправим — поставщику / утилизация».

Влияние на остатки. Решения не правят склад «вручную», а питают формулу доступного остатка: возврат в остаток — количество возвращается в доступное; возврат поставщику и утилизация — списываются как потеря; архив — закрытие без изменения остатка.

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

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

Фулфилмент. Оператор с правом просмотра склада видит реестр брака и историю; с правом редактирования склада — принимает решения; с правом на приёмку — фиксирует брак и загружает фото.

Селлер. В своём кабинете селлер видит фотографии брака по своей приёмке и агрегированные количества брака и обезлички в своих остатках — как доказательство и цифру. А вот workflow-статусы, решения и историю действий по браку ведёт и видит фулфилмент; отдельного «решения селлера» по браку в системе нет.

• Это учёт брака и решений на складе фулфилмента. Автоматический контур возвратов покупателей маркетплейса (когда WB/Ozon возвращают заказ) в этот процесс не заведён — «возвраты» здесь означают внутренние решения: вернуть в остаток или поставщику.
• Решение по браку принимает человек (оператор фулфилмента), система ведёт реестр, маршрут и историю — но не решает автоматически.

Можно ли вернуть отремонтированный товар в продажу? Да — из статуса «В ремонте» есть переход «вернулся исправным — в остаток», и количество возвращается в доступные остатки.

Что с обезличкой? Обезличенный товар заводится как отдельный тип брака и идёт по тем же решениям.

Увидит ли селлер, что мы списали брак? Селлеру доступны фото по приёмке и агрегированные количества брака и обезлички в остатках; конкретные workflow-статусы, решения и история — внутренняя работа фулфилмента.

• Остатки и адресное хранение — как считаются доступные остатки.
• Услуги, прайс и счета — как учитываются работы фулфилмента.
• Как это работает — полный цикл поставки.

Посмотреть в демо →