Начните с фактического процесса, который можно восстановить
Выберите один типовой для вашей организации сценарий и опишите его от подготовки сведений до завершения движения. Например, можно взять условную отгрузку партии с участием отправителя, перевозчика и получателя. Это пример структуры проверки, а не утверждение о том, какие роли или документы обязательны для каждой перевозки.
Для каждого шага установите, кто действует, какой документ использует и где получает исходные сведения. Отдельно отметьте ручное повторное внесение данных. Именно эти точки позволяют сформулировать вопрос оператору о будущем обмене, не выдумывая ещё не подтверждённый API.
Рабочая таблица подготовки предприятия
| Шаг или участник | Что описать в текущем процессе | Какое подтверждение сохранить | Вопрос к будущему сценарию |
|---|---|---|---|
| Подготовка сведений о продукции | Кто формирует исходные данные, какие идентификаторы применяет и в какой системе | Название документа, версия формы, используемая инструкция | Какие поля будут источником для обмена, а какие останутся ручными |
| Отправитель | Кто оформляет или подтверждает конкретный документ | Организация, роль сотрудника, последовательность действий | Кто будет инициировать перенос или связывание документов |
| Перевозчик | Какая операция действительно относится к нему в вашем процессе | Используемый сервис ЭПД и инструкция именно этого сервиса | Требуется ли участие в объявленном сценарии для данного типа перевозки |
| Получатель | Как фиксируется результат движения и расхождение | Текущая процедура проверки сведений | Кто подтверждает получение и как обрабатывается расхождение |
| Учётная система предприятия | Где хранятся значения и кто их изменяет | Названия полей, внутренние идентификаторы и владелец данных | Как сопоставить записи без потери исходной связи |
| ФГИС «Зерно» | Какие операции и роли реально используются организацией | Точная действующая инструкция оператора для операции | Какую часть процесса изменит новая опубликованная инструкция |
| Исправление или отмена | Кто исправляет сведения и как сохраняется история | Текущая последовательность исправления | Как избежать повторного исполнения или рассогласования документов |
Это рекомендуемая форма инвентаризации процесса. Она не определяет обязательный состав электронного перевозочного документа и не назначает права участникам.
Сверьте идентификаторы до автоматизации
Для пары документов недостаточно найти одинаковую дату или массу. Внутренняя таблица сопоставления должна объяснять, какой идентификатор означает партию, какой — документ, какой — транспортную операцию. Один идентификатор может повторяться в нескольких строках; такое повторение не следует автоматически считать дубликатом.
Полезно проверить три случая на обезличенных или специально подготовленных данных:
- Обычный процесс: исходные сведения совпали, все действия имеют известного владельца.
- Расхождение: одна из сторон обнаружила иной объём или реквизит; известно, кто принимает решение и какой документ корректирует.
- Повтор или отмена: пришло повторное сообщение либо операция отменена; сохранена связь с первоначальной записью, а команда не создаёт новый факт движения без основания.
Это предложения для приёмки будущего решения. Формат сообщений, допустимые статусы и правила исправления должны следовать точной инструкции соответствующего обмена, когда она будет подтверждена.
Что можно делать до выхода новой инструкции
Собрать карту участников и документов, перечень действующих учётных записей по должностным функциям и список ручных переносов. Для каждого переноса записать источник, получателя, поля, ответственного и способ проверки. Пароли и ключи подписи в такую карту не включают.
Определить вопросы к оператору: охватывает ли сценарий ваш тип движения, кто участвует, какой сервис ЭПД используется, какие документы связываются и где опубликована актуальная инструкция. Наличие инструкции отдельного каботажного сервиса не подтверждает правила всех электронных перевозочных документов.
Также можно подготовить внутренние критерии проверки: связь исходного и полученного документа, сохранение истории исправлений, отсутствие необоснованных повторов и возможность объяснить результат по одному сценарию. Эти критерии не означают, что интеграция уже работает или что предприятию доступен конкретный API.
Когда пересматривать план
Повторная сверка нужна при публикации инструкции интеграции, сообщения о её фактическом запуске или изменении объявленного сценария. Тогда обновляют статус, состав участников, версию документов и технические условия. Новость о планируемой дате нельзя незаметно заменить утверждением «запущено».
Для обсуждения общей автоматизации обмена на сайте есть страница интеграций СМЭВ, ГИС и API. Она не удостоверяет доступность конкретного обмена «Зерно»/ЭПД и не заменяет инструкции оператора.
Результат подготовки — описанный текущий сценарий, таблица документов и данных, вопросы об объявленной интеграции и перечень проверок после появления её точных условий. Такой пакет даёт предмет для технического обсуждения без предположений о сроке обязанности или готовности внешнего сервиса.
Редакционная подготовка: 2 октября 2026 года. Сообщение оператора проверено существующим владельцем источников 1 октября 2026 года. Планируемая дата 01.03.2027 сохранена как план; фактический запуск, авторизованный доступ и API не подтверждались.