# Карточка сверки передачи и статусов FBS

Одна карточка относится к одному отправлению или сборочному заданию в одном кабинете. Это рабочий лист проверки, а не подключение к API и не средство изменения статусов.

## Файлы

- `m17-delivery-check-template.csv` — пустые значения с подсказками для заполнения.
- `m17-delivery-check-example.csv` — заполненный учебный случай. Все ID, документы, времена и события вымышлены. Он показывает открытое расхождение, а не устранённый дефект конкретной системы.

CSV сохранены в UTF-8 с BOM, разделитель — запятая, поля заключены в кавычки. В Excel или другом редакторе используйте импорт текста/CSV с этими настройками. Если редактор спрашивает тип данных, выберите текст: ID, машинные статусы и исходное смещение времени должны сохраниться. CSV не хранит оформление, фильтры и формулы.

## Порядок заполнения

1. Сделайте копию шаблона и заполните столбец «Значение». Сначала укажите площадку, схему, кабинет, склад, номер отправления и связь с локальным заданием. Номер заказа не заменяет номер отправления.
2. Запишите последнее подтверждённое физическое место и доказательство передачи. Отличайте созданный документ от подтверждения принимающей стороны. Сопоставьте строку документа, этикетку и каждое грузоместо.
3. Снимите локальный статус, статус конкретного отправления в кабинете площадки и, если доступно уполномоченному специалисту, результат информационного метода API. Сохраните исходные машинные значения и дополнительную ось/подстатус, когда они возвращены.
4. Для каждого наблюдения запишите время чтения. Время самого события укажите отдельно и только если источник его сообщает с понятным значением. Не подставляйте сюда дату создания заказа. Формат времени в примере — ISO 8601 со смещением; префикс `ISO:` сохраняет строку при импорте.
5. Разведите подтверждённое расхождение и гипотезу причины. Если данных нет, пишите «неизвестно» или «не получено», а не выдуманное значение. «Неприменимо» используйте только с причиной.
6. Назначьте ответственного, следующее действие и свою контрольную точку. При споре о передаче отдельно проверьте актуальное правило и срок обращения площадки. Внутренний срок команды не заменяет его.
7. Закрывайте разбор по проверенному результату. Если причина ещё неизвестна, оставьте карточку открытой; уже назначенная контрольная точка не означает, что проблема решена.

## Что показывает пример

В учебном случае кабинет и снимок API относятся к `TRAIN-POST-001-1` и показывают завершение доставки. Локальный экран ещё показывает «В доставке». Последнее подтверждённое получение данных в локальной системе старше нового снимка API. Возможная причина — давность данных, но также нужно проверить сопоставление ID и отображение.

Время реального изменения статуса площадки неизвестно. Разница между 17:12 и 17:14 — интервал между наблюдениями, а не точная задержка синхронизации. Значение 17:30 в примере — выбранная командой контрольная точка, не обещанный срок Ozon или Skirbo.

## Безопасная передача карточки

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

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

Методика: [Заказ остаётся «в доставке»](https://skirbo.ru/blog/zakaz-ostaetsya-v-dostavke). Источники и ограничения указаны в статье. Версия рабочего листа: 31.10.2026.
