Доставлена одна коробка из трёх: как учитывать места

Если заказ отправлен в трёх коробках, событие вручения одной коробки не должно автоматически закрывать остальные. Система должна знать состав отправки и принадлежность события конкретному месту. Общий статус «доставлено» без этой связи создаёт ложную картину: менеджер перестаёт искать две коробки, а покупатель видит завершённую операцию, которую фактически ещё нужно разбирать.

Рассмотрим предлагаемую модель учёта для магазина или службы доставки. Она не описывает действующие возможности определённого перевозчика и не устанавливает юридическую силу сканирования, подписи либо фотографии. Правила подтверждения вручения согласуют отдельно. Все номера и события ниже учебные. Задача программы — сохранять различие между заказом, отправкой, физическими местами и наблюдениями об их движении.

Начните с состава, а не с красивого статуса

Условный заказ З-42 отправлен как О-17 и содержит места М-1, М-2 и М-3. Для М-1 получено согласованное подтверждение вручения. У М-2 пока есть только событие передачи на доставку. По М-3 ожидается уточнение. Сводка должна показывать частичное исполнение и оставшуюся работу, не превращая известный успех в успех всей группы.

Фраза «одно из трёх» полезнее зелёной галочки, но количество не заменяет перечень. Менеджер должен открыть конкретные незавершённые места. Если после перепаковки состав поменялся, знаменатель тоже требует объяснения. В противном случае экран может показать три из трёх, используя уже устаревший список коробок.

Заказ, отправка и коробка отвечают на разные вопросы

Заказ хранит договорённый состав обращения покупателя. Отправка объединяет определённый набор мест для доставки. Место обозначает отдельную физическую единицу, если именно такой учёт предусмотрен процессом. Событие сообщает, что произошло с выбранным объектом. Сведение этих уровней к одной карточке затрудняет и частичное исполнение, и исправление ошибок.

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

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

Событие должно находить свой объект

Для каждого входящего сообщения сохраняйте источник и доступный идентификатор события, объект, тип и переданное время. Если есть время получения системой, храните его отдельно. Запоздавшее сообщение о промежуточном этапе не должно автоматически отменять уже подтверждённый позднейший результат только потому, что пришло последним.

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

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

Повторное сканирование не увеличивает число вручённых мест

Допустим, подтверждение М-1 пришло дважды. Количество полученных коробок остаётся равным одному, если повтор относится к тому же месту и тому же подтверждённому действию. Не считайте входящие сообщения как доставленные единицы. Для сводки используются состояния разных мест, а сообщения сохраняют историю наблюдений.

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

Для оператора полезно явно показать, что новое сообщение не изменило итог, потому что относится к уже учтённому объекту. Это уменьшает попытки вручную увеличить количество ради совпадения с журналом. При этом повторное подтверждение другого места должно обработаться отдельно, даже если его текст и время похожи на первое.

Перепаковка требует истории состава

Если одна коробка заменена двумя, нельзя просто удалить её из перечня и добавить новые без объяснения связи. В предлагаемой модели сохраняется изменение состава: какой объект перестал участвовать, какие появились и с какого момента применяется новый набор. Допустимость такой операции и её подтверждение устанавливает компания.

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

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

Незавершённое место должно порождать работу

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

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

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

Проверьте частичную доставку до запуска

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

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

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