Международный WB API возвращает для задания два поля: supplierStatus и wbStatus. Первое отражает состояние сборочного задания, второе — состояние на стороне площадки. В частности, complete означает доставку, а sold — продажу. Если свести оба значения в одну локальную колонку без правил, менеджер может увидеть выручку там, где товар только отправляется.

Сохраните исходные значения отдельно

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

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

Опишите смысл бизнес-показателей

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

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

Отдельно обрабатывайте неизвестное состояние

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

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

Сверяйте изменение с конкретным заданием

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

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