МИГ24: Компонента, API и обработки 1С

Техническая инструкция для сопровождения интеграции ЭДО/ЭПД • Комплекты 1С 8.2 и 8.3

1. Общие принципы и архитектура

1.1. Слои решения

Интеграция состоит из пяти слоев. Каждый слой решает отдельную задачу и не должен подменять соседний:

Обычная форма «ФормаОбмен» — пользовательские команды, выбор организации, периода, документов и сертификата.
Модуль объекта внешней обработки — сбор структур JSON, вызов компоненты, обработка ответов, старый контур ЭДО.
ОбщийМодульМИГ24 — серверные вызовы, прямые GET-запросы ЭПД, генерация XML T1, чтение и запись регистров.
Native-компонента КомпонентМИГ24.bin — HTTP-взаимодействие, доступ к сертификатам ОС, криптографическая подпись и составные сценарии API.
API МИГ24 — два логических контура: /api/v1 для ЭДО и /epd/v1 для ЭПД/ЭТрН.

Форма 1С → функция модуля обработки или общего модуля → JSON { settings, data } → Mig24AddinExtension.ВызовМетодаJSON(Команда, JSON) → локальная криптография и/или HTTP API МИГ24 ← JSON { response, data } ← Структура 1С ← сообщение пользователю и запись регистров

1.2. Различие ЭДО и ЭПД

Признак	ЭДО	ЭПД/ЭТрН
Основной API	`/api/v1`	`/epd/v1`
Основной объект	документ → пакет → группа пакетов	перевозка `transportationId` → титулы
Идентификаторы	`documentId`, `packageId`, `packageGroupId`	`transportationId`, `signingEntity`, УИД накладной
Документы 1С	реализация, счет, акт сверки	реализация для Т1, поступление для Т3
Состояния	события `package-status-updated`	GET перевозки, действия и серверная валидация

1.3. Состав Native-компоненты

КомпонентМИГ24.bin является ZIP-контейнером Native API 1С. В поставке находятся Mig24Addin_32.dll, Mig24Addin_64.dll, libMig24Addin.so и manifest.xml. Манифест объявляет Windows i386, Windows x86_64 и Linux x86_64. Это не COM-компонента: regsvr32 не используется.

Класс: Mig24AddinExtension.
Основной метод из 1С: ВызовМетодаJSON(ИмяКоманды, СтрокаJSON).
В клиентском модуле подключение выполняется под именем МИГ24AddinClient; в общем модуле — МИГ24Addin.
Для 1С 8.2 JSON сериализуется собственным совместимым кодом общего модуля; в 1С 8.3 применяются ЗаписьJSON и ЧтениеJSON.

1.4. Единый формат вызова

Практически все сетевые команды получают корневую структуру из двух разделов:

{ "settings": { "host": "epd.mig24.online", "token": "<секретный API-токен>" }, "data": { "...": "параметры конкретной команды" } }

settings.host — узел сервиса выбранной организации. Код умеет нормализовать схему для прямых GET ЭПД; компонента обычно получает адрес из регистра.
settings.token — токен именно выбранной организации. Токен другой организации меняет роль и доступные данные.
data — параметры команды. Для некоторых команд раздел отсутствует.

Важно. В существующем контракте httpCode, valid и hasData часто представлены строками, а не числами/булевыми. Сравнение с "200" и "0" менять без проверки версии компоненты нельзя.

1.5. Почему в коде есть английские имена

В формах встречаются host, token, thumbprint, mchdnlfold, documentId, packageId, packageGroupId, transportationId, signingEntity, response, data, user_data, issuer, validTo и другие имена. Это не случайно вставленный иностранный код. Большая часть имен является контрактом API, ответа компоненты или существующих регистров 1С.

Строки внутри Вставить("documentId", …) формируют JSON. Перевод ключа изменит запрос и сломает API.
Обращение Ответ.data.user_data читает точное поле ответа. Переименование приведет к отсутствию значения.
Реквизиты регистра documentId/packageId уже являются именами метаданных. Их переименование требует миграции конфигурации и данных.
Русифицировать безопасно локальные переменные, комментарии и пользовательские сообщения.

1.6. Безопасность

token является секретом. Не помещать его в Сообщить(), журнал регистрации, скриншоты и текст ошибок.
Протоколировать имя команды, HTTP-код и обезличенный идентификатор; тело запроса — только после маскирования token.
МИГ24_НастройкиОрганизаций и МИГ24_Пользователи закрыть правами от обычного просмотра.
pincode не хранить и не передавать. При необходимости PIN запрашивает криптопровайдер в своем интерфейсе.
Полный JSON МЧД может содержать персональные данные; доступ к МИГ24_МЧД_Кэш ограничить.

2. Методы Native-компоненты

2.1. Методы, которые вызывает текущая обработка

Таблица фиксирует фактические строки команд из исходников. Маршруты указаны по исходникам общего модуля и строкам бинарной компоненты.

Команда	Контур	API/ресурс	Назначение	Ключевые параметры
`create-upd`	ЭДО	`/api/v1/documents/upd`	Создание/выгрузка УПД	`settings`; `data.documentId`; `data.document`
`create-payment-invoice`	ЭДО	`/api/v1/documents/payment-invoice`	Выгрузка счета на оплату	`settings`; `data.documentId`; `data.document`
`checking-payments-act`	ЭДО	`/api/v1/documents/checking-payments-act`	Выгрузка акта сверки	`settings`; `data.documentId`; `data.document`
`create-package-group`	ЭДО	`/api/v1/package-groups`	Создание группы пакетов	получатель; `packageGroupId`; `documents[]`
`delete-package-group`	ЭДО	`/api/v1/package-groups/id`	Удаление неподписанной группы пакетов	`data.packageGroupId`
`sign-package-group`	ЭДО	`/api/v1/sign/package-group/*`	Подготовка, локальная подпись и завершение подписи группы	`packageGroupId`; `thumbprint`; необязательный `mchdnfold`
`certificates-list`	Общий	Локальные хранилища сертификатов	Получение доступных сертификатов	`data.hardware`; `data.snils`
`certificates-list-match`	Общий	`/api/v1/organization-users` + локальное хранилище	Сопоставление локальных сертификатов пользователям организации и МЧД	`settings` с обязательными `host`/`token`
`abonents-by-requisites`	ЭДО	`/api/v1/abonents/by-requisites`	Поиск абонентов по ИНН/КПП	`data.in`; необязательный `data.kpp`
`counteragents`	ЭДО	`/api/v1/counteragents`	Получение подключенных контрагентов	`settings`
`counteragent-requests`	ЭДО	`/api/v1/counteragent-requests`	Отправка приглашения контрагенту	`abonentCode`; `name`; `inn`; необязательный `kpp`
`operators`	ЭДО	`/api/v1/operators`	Получение справочника операторов	`settings`
`package-status-updated`	ЭДО	`/api/v1/events/package-status-updated`	Чтение событий изменения статуса пакетов	`orderBy`; `orderDir`
`ack-single-event`	ЭДО	`/api/v1/events/eventId/ack`	Подтверждение обработки одного события	`data.eventId`
`epd-create-transportation`	ЭПД	`/epd/v1/transportations`	Создание перевозки и серверного черновика T1	`fileName`; XML-файл/содержимое; параметры вызова
`epd-sign-entity`	ЭПД	`/epd/v1/signing-transactions/prepare` и `/finish`	Подписание полученного `signingEntity`	`signingEntity`; `signingEntityType`; `thumbprint`; `mchdnfold`

Важно. Команды package-groups-list, package-info и package-actions присутствуют в обертках общего модуля, но отсутствуют в реестре строк JSON-команд поставляемого бинарника. Перед включением страницы входящих ЭДО их необходимо проверить с фактической версией компоненты или заменить поддерживаемыми командами.

2.2. Полный реестр команд компоненты

В Mig24Addin_32.dll 54 команды JSON. Статус «не вызывается» означает только отсутствие прямого вызова в текущих исходниках; команда может использоваться внутри составной команды компоненты.

Команда	Связанный ресурс	Прямой вызов обработкой
`abonents-by-requisites`	`/api/v1/abonents/by-requisites`	Да
`abonents-requisites`	`/api/v1/abonents/(код)`	Нет, доступен компонентой
`ack-events`	`/api/v1/events/ack`	Нет, доступен компонентой
`ack-single-event`	`/api/v1/events/(id)/ack`	Да
`certificate-to-base64`	Локальная криптография	Нет, доступен компонентой
`certificates-list`	Локальное хранилище	Да
`certificates-list-match`	Локальное хранилище + `/api/v1/organization-users`	Да
`checking-payments-act`	`/api/v1/documents/checking-payments-act`	Да
`counteragent-created`	`/api/v1/events/counteragent-created`	Нет, доступен компонентой
`counteragent-requests`	`/api/v1/counteragent-requests`	Да
`counteragents`	`/api/v1/counteragents`	Да
`create-informal`	`/api/v1/documents` (неформализованный документ)	Нет, доступен компонентой
`create-package-group`	`/api/v1/package-groups`	Да
`create-payment-invoice`	`/api/v1/documents/payment-invoice`	Да
`create-upd`	`/api/v1/documents/upd`	Да
`delete-document`	`/api/v1/documents/{id}`	Нет, доступен компонентой
`delete-package-group`	`/api/v1/package-groups/{id}`	Да
`epd-ack-events`	`/epd/v1/events/ack`	Нет, доступен компонентой
`epd-ack-single-event`	`/epd/v1/events/{id}/ack`	Нет, доступен компонентой
`epd-create-transportation`	`/epd/v1/transportations`	Да
`epd-sign-entity`	подготовка + локальная подпись + завершение транзакции	Да
`epd-transportations`	`/epd/v1/transportations`	Нет, доступен компонентой
`operators`	`/api/v1/operators`	Да
`organization-users`	`/api/v1/organization-users`	Нет, доступен компонентой
`package-status-updated`	`/api/v1/events/package-status-updated`	Да
`sign-package-group`	`/api/v1/sign/package-group/prepare, user, finish`	Да

2.3. Пример вызова компоненты

Клиентский вызов из модуля объекта обработки:

НастройкиВызова = Новый Структура("host,token", host, token); ДанныеВызова = Новый Структура; ДанныеВызова.Вставить("inn", Контрагент.ИНН); ДанныеВызова.Вставить("kpp", Контрагент.КПП); ПолезнаяНагрузка = Новый Структура; ПолезнаяНагрузка.Вставить("settings", НастройкиВызова); ПолезнаяНагрузка.Вставить("data", ДанныеВызова); Ответ = ВызовМетодаJSON("abonents-by-requisites", ПолезнаяНагрузка);

Серверный вызов через общий модуль отличается только местом подключения макета:

Макет = ПолучитьОбщийМакет("КомпонентМИГ24"); Ответ = ОбщийМодульМИГ24.ВызовМетодаНаСервереJSON( Макет, "epd-create-transportation", ПолезнаяНагрузка);

2.4. Правила обработки ответа

Сначала проверить наличие response и response.httpCode.
Успех текущего контракта — строка response.httpCode = "200". Для прямого HTTP ЭПД используется числовой КодСостояния.
response.hasData = "0" означает корректный ответ без массива данных, а не сетевую ошибку.
Текст response.error показывает пользователю без settings.token и полного запроса.
После исключения компоненты формировать унифицированный локальный ответ с httpCode = "500" и понятным источником ошибки.

3. Устройство обработок 1С

3.1. Основные модули

Объект	Ответственность
ФормаОбмен	Организация, период, отбор документов, команды ЭДО/ЭПД, сертификат, входящие и запуск Т1/Т3
МодульОбъекта	JSON-модели ЭДО, клиентское подключение компоненты, документы и пакеты, сертификаты, события
ОбщийМодульМИГ24	серверное подключение компоненты, HTTP GET ЭПД, XML Т1, регистры, защита от дублей
Форма ДанныеТ1	редактирование и сохранение параметров/грузов Т1, выбор перевозчика, водителя и ТС
ФормаТ3	ввод фактической приемки и формирование данных титула Т3
ФормаКарточкиВходящего	представление входящего пакета и связанных действий
Форма Настройка	открытие списков регистров и получение списка операторов
Макет КомпонентМИГ24	бинарный контейнер Native-компоненты
Макет Протокол	табличное представление вызовов компоненты

3.2. Хранение данных

Регистр/объект	Ключ	Основные поля	Назначение
`МИГ24_НастройкиОрганизаций`	Организация	`host`, `token`	Адрес и API-токен выбранной организации
`МИГ24_НастройкиКонтрагентов`	Организация + Контрагент + `AbonentCode`	реквизиты, статус, `ПоУмолчанию`, флаги ЭДО	Маршрутизация старого ЭДО и автоматический отбор реализаций
`МИГ24_Операторы`	Префикс	Оператор, Продукт	Расшифровка кода оператора ЭДО
`МИГ24_Документы`	Документ 1С	`documentId`	Идентификатор ЭДО; для ЭТрН здесь хранится `transportationId`
`МИГ24_Пакеты`	`documentId`	`packageId`, `packageGroupId`	Связь документа ЭДО с пакетом и группой
`МИГ24_Состояния`	Период + `packageId`	`EventId`, `StatusId`, `UpdateDataTime`, `host`, `token`	История событий ЭДО
`МИГ24_СписокСостояний`	`StatusId`	Status, StatusName	Локальная расшифровка статусов ЭДО
`МИГ24_Пользователи`	Организация + Пользователь	`thumbprint`, `mchdlnfold`, `pincode`, ФИО	Привязка сертификата; `pincode` должен оставаться пустым
`МИГ24_ВходящиеПакеты`	`packageId`	отправитель, документ, статусы, признаки обработки	Локальный список входящих
`МИГ24_ВходящиеПодписи`	`packageId` + НомерПодписи	подписант, Thumbprint, МЧД, результат проверки	Подписи входящего пакета
`МИГ24_МЧД_Кэш`	номер МЧД + ИНН сторон	сроки, полномочия, полный JSON	Кэш сведений МЧД
`МИГ24_ПараметрыЭТРН`	РеализацияТоваровУслуг	маршрут, перевозчик, водитель, ТС, времена, роли, УИД	Черновые и сохраненные поля титула Т1
`МИГ24_ГрузыЭТРН`	Документ + номер строки	описание, упаковка, места, масса, маркировка	Строки груза Т1
`МИГ24_НастройкиТ1Организаций`	Организация	адреса, телефоны и значения по умолчанию	Настройки грузоотправителя для Т1
`МИГ24_МаршрутыЭТРН`	Организация + Контрагент	пункты погрузки/доставки и коды	Маршрут Т1
`МИГ24_Перевозчики`	Организация + Перевозчик	`AbonentCode`, телефон, признаки	Выбор перевозчика Т1
`МИГ24_Водители`	Перевозчик + водитель	ФИО, ИНН, телефон, водительское удостоверение	Выбор водителя Т1
`МИГ24_ТранспортныеСредства`	Перевозчик + ТС	номер, тип, марка, грузоподъемность, вместимость	Выбор автомобиля Т1

Важно. В комплекте 8.2 измерение строки груза называется НомерСтрокиГруза. В текущем комплекте 8.3 используется НомерСтроки. Программист должен применять имя своей конфигурации и не смешивать тексты модулей между версиями.

3.3. Жизненный цикл идентификаторов

Идентификатор	Кем создается	Где хранится	Когда нужен
`documentId`	1С для документа ЭДО	`МИГ24_Документы.documentId`	создание документа, пакета, повторные операции
`packageId`	1С/контур ЭДО	`МИГ24_Пакеты.packageId`	подпись документа и статусы
`packageGroupId`	1С/контур ЭДО	`МИГ24_Пакеты.packageGroupId`	создание, подписание и удаление группы
`eventId`	API	`МИГ24_Состояния` или `МИГ24_ВходящиеПакеты`	защита от повторной обработки события
`transportationId`	API ЭПД	`МИГ24_Документы.documentId`	все последующие действия с перевозкой
`signingEntity`	API при создании/действии	ресурсы `МИГ24_Документы` для черновика подписи	локальная подпись через `epd-sign-entity`
`thumbprint`	хранилище сертификатов ОС	`МИГ24_Пользователи`	выбор закрытого ключа
`mchdnfold`	API при сопоставлении сертификата	`МИГ24_Пользователи`	передается только при наличии действующей МЧД

3.4. Сертификат и МЧД

Сертификат выбирается не из регистра 1С, а из локального хранилища сертификатов пользователя Windows. Регистр хранит только привязку результата к паре Организация + Пользователь.

Выбранная организация → чтение host/token → certificates-list-match → локальные сертификаты + /api/v1/organization-users → фильтрация просроченных → выбор thumbprint и необязательного mchdnfoId → запись МИГ24_Пользователи

Важно. Привязанный thumbprint не заменяет host/token. certificates-list-match сначала должен определить пользователей организации на сервере. Запрос с {"host":"","token":""} завершится до проверки сертификата. Формы должны перечитывать настройки непосредственно перед вызовом и не отправлять пустые settings.

4. Контур ЭДО

4.1. Назначение

Контур ЭДО обслуживает формализованные документы и пакетную модель /api/v1. В текущей обработке создаются УПД из реализации, счета на оплату и акты сверки. Документ сначала получает documentId, затем выгружается, включается в пакет/группу и подписывается.

4.2. Настройка организации и контрагентов

В МИГ24_НастройкиОрганизаций создается одна запись на каждую организацию с host/token.
Команда counteragents получает подключенных контрагентов сервера.
Обработка сопоставляет их со справочником Контрагенты по ИНН/КПП и записывает МИГ24_НастройкиКонтрагентов.
abonents-by-requisites применяется для поиска кодов абонентов по реквизитам.
counteragent-requests создает приглашение; локальный статус меняется на ОжиданиеПрисоединения или Ошибка.
Проведенная реализация подключенного контрагента автоматически попадает в 8.2-список, если Статус = Присоединен и ЭДО_Реализация = Истина. ЭДО_МИГ24 = Истина остается ручным разрешением.

4.3. Создание документа

Документ 1С	Команда	Результат
РеализацияТоваровУслуг	`create-upd`	УПД `/api/v1/documents/upd`
СчетНаОплатуПокупателю	`create-payment-invoice`	счет `/api/v1/documents/payment-invoice`
АктСверкиВзаиморасчетов	`checking-payments-act`	акт сверки `/api/v1/documents/checking-payments-act`

До вызова создается и сохраняется documentId. Повторная операция обязана использовать тот же идентификатор, пока пользователь явно не выполнил сброс. JSON-поля документа имеют английские имена, поскольку повторяют DTO API.

4.4. Пакет и подпись

СоздатьПакет получает documentId, создает/читает packageId и packageGroupId, определяет получателя и вызывает create-package-group. ПодписатьПакет передает packageGroupId, thumbprint и при наличии mchdlnfold в sign-package-group.

Документ 1C ➔ documentId ➔ create-upd / create-payment-invoice / checking-payments-act ➔ packageId + packageGroupId ➔ create-package-group ➔ sign-package-group ➔ package-status-updated ➔ запись МИГ24_Состояния ➔ ack-single-event

4.5. События и статусы

package-status-updated запрашивается с orderBy = ModificationDateTime и orderDir = ASC.
Каждое событие записывается в периодический регистр МИГ24_Состояния.
После успешной локальной записи eventId подтверждается через ack-single-event.
При StatusId = 4 обработка устанавливает АктСдан у связанного документа 1С.

4.6. Входящие ЭДО

Общий модуль содержит обертки списка групп, карточки пакета и доступных действий. Они подготовлены под GET /api/v1/package-groups, /api/v1/packages/{id} и /actions. Однако строковые команды этих трех оберток не обнаружены в поставляемой компоненте. До подтверждения версии компоненты страницу входящих следует считать интеграционным заделом, а не гарантированно рабочим маршрутом.

4.7. Минимальная проверка ЭДО

Выбрать организацию и убедиться, что host/token непустые.
Получить контрагентов и проверить запись с корректным AbonentCode.
Выгрузить один документ и убедиться, что documentId сохранен.
Создать пакет и проверить МИГ24_Пакеты.
Выбрать сертификат, подписать и получить серверное событие.
Повторить обновление: уже подтвержденное eventId не должно обрабатываться как новое.

5. Контур ЭПД и электронная транспортная накладная

5.1. Определение режима

Форма определяет контур по host. Известные узлы старого ЭДО test-еdo.ntssoft.ru и edo.mig24.online относятся к ЭДО; остальные заполненные узлы рассматриваются как ЭПД. Заголовок формы меняется на «МИГ24 — ЭПД / ЭТрН» или «МИГ24 — ЭДО». Это эвристика: при появлении нового домена ЭДО список необходимо обновить.

5.2. Какие вызовы выполняются компонентой, а какие HTTPСоединением

Операция	Механизм	Ресурс
Создание перевозки/T1	Native-компонента	`epd-create-transportation` → POST `/epd/v1/transportations`
Подпись signingEntity	Native-компонента + криптопровайдер	`epd-sign-entity` → prepare/finish signing-transactions
Код текущего абонента	Прямой GET общего модуля	`/epd/v1/abonents/me`
Состояние перевозки	Прямой GET	`/epd/v1/transportations/(transportationId)`
Поиск ранее отправленной перевозки	Прямой GET со страницами	`/epd/v1/transportations?Page=...`
Доступные действия	Прямой GET	`/epd/v1/transportations/(id)/actions`
Состояние проверки подписи	Прямой GET	`/epd/v1/validation/packages/(id)` и `/validation/(id)`

5.3. Подготовка Т1

Основание Т1 — проведенная РеализацияТоваровУслуг. Форма «ДанныеТ1» объединяет данные документа и специализированных регистров.

Код грузоотправителя получается по токену через /epd/v1/abonents/me.
Код грузополучателя берется из маршрута/параметров Т1.
Код перевозчика берется из МИГ24_Перевозчики и сохраняется в параметрах Т1.
Маршрут определяется по Организация + Контрагент.
Водитель и транспорт фильтруются по выбранному перевозчику.
При смене перевозчика зависимые поля водителя и ТС очищаются.
Грузы читаются из МИГ24_ГрузыЭТРН; при первом заполнении создаются из товаров реализации.
УИД транспортной накладной создается и записывается при отсутствии.

Общий модуль формирует XML ФНС во временном файле в кодировке windows-1251. Имя файла включает коды участников и УИД. Временный файл должен удаляться после завершения сценария.

5.4. Создание, сохранение и защита от дублей

Реализация ➔ чтение сохраненных параметров Т1 ➔ получение ролей/кодов ➔ генерация XML ➔ epd-create-transportation ➔ transportationId + signingEntity ➔ немедленная запись transportationId и signingEntity ➔ epd-sign-entity ➔ GET состояния перевозки ➔ после успеха очистка signingEntity

Важно. transportationId и signingEntity должны сохраняться до подписи. Если криптопровайдер или сервер подписи вернул ошибку, повторный запуск подписывает сохраненный черновик и не создает новую перевозку.

Перед новым созданием обработка выполняет две проверки:

если transportationId уже хранится — запрашивает его серверное состояние и продолжает допустимое действие;
если локального идентификатора нет — ищет перевозку по номеру документа на сервере и при нахождении восстанавливает transportationId в 1С.

5.5. Подписание Т1

Ответ создания содержит signingEntity — серверное представление подписываемой сущности. Оно передается в epd-sign-entity вместе с типом сущности, thumbprint и необязательным mchdlnfold. Компонента получает данные для подписи, обращается к закрытому ключу через криптопровайдер и завершает серверную транзакцию подписи.

Закрытый ключ не передается в 1С и не отправляется на сервер.
thumbprint выбирает сертификат в локальном хранилище.
mchdlnfold передается только когда API сопоставил действующую МЧД.
PIN не берется из регистра; интерактивный запрос выполняет криптопровайдер.
После вызова обработка перечитывает перевозку и различает принятую подпись и завершенную серверную регистрацию Т1.

5.6. Т2 и Т3

Т2 в текущей обработке не формируется. Его оформляет перевозчик в кабинете МИГ24 или другой интеграцией. Пока Т2 не принят, сервер не разрешает грузополучателю Т3.

Для Т3 обработка использует ПоступлениеТоваровУслуг, связанное с transportationId. Перед открытием формы проверяются организация, роль грузополучателя и список доступных действий. ФормаТЗ собирает фактические данные приемки. Сервер возвращает новый signingEntity, который подписывается той же командой epd-sign-entity с типом титула Т3.

5.7. Стадии перевозки

Локальная стадия	Смысл	Действие формы
`НетТитула1`	перевозка еще не создана	Создать и подписать Т1
`ОжидаетсяТитул2`	Т1 принят, ожидается перевозчик	Ожидать подпись Т2
`МожноФормироватьТитул3`	Т2 принят	Грузополучатель оформляет Т3
`ОжидаетсяТитул4`	Т3 принят	Ожидать подпись Т4 перевозчиком
`Завершена`	комплект титулов завершен	Только просмотр состояния

5.8. Дополнительные команды ЭПД в компоненте

Компонента содержит команды carrier-acceptance, carrier-cargo-release, carrier-financial-change, consignee-acceptance, partial-acceptance, refusal, driver-vehicle-replacement, readdressing и shipper-financial-change-confirmation. Текущая обработка напрямую использует только сценарии, необходимые для Т1 и Т3. Остальные команды нельзя подключать одной кнопкой без проектирования формы данных и проверки допустимых ролей/стадий на /actions.

6. Диагностика

6.1. Ошибка certificates-list-match / OrganizationUsers 404

Если в тексте ошибки виден запрос {"settings":{"host":"","token":""}}, проблема возникает до проверки сертификата. Компонента не может обратиться к /api/v1/organization-users без настроек организации.

Проверить запись МИГ24_НастройкиОрганизаций именно для выбранной ссылки Организация.
Проверить непустые host и token без пробелов и переносов.
Перечитать настройки после изменения организации.
Не считать запись МИГ24_Пользователи источником host/token: она хранит только привязку сертификата.
В исправленных формах 8.2/8.3 настройки перечитываются при открытии и непосредственно перед выбором сертификата; пустой запрос блокируется локально.

6.2. Разделение источников ошибки

Признак	Источник	Проверка
Не создается AddIn	установка/разрядность компоненты	макет, разрешение внешних компонент, 32/64-bit
Исключение при подписи	криптопровайдер/закрытый ключ	наличие контейнера, права пользователя, сертификат
HTTP 401/403	токен или полномочия	организация токена, срок и доступ к методу
HTTP 404	host, маршрут, идентификатор или версия компоненты	settings, имя команды, endpoint, ID
HTTP 409	конфликт состояния/дубль	сохраненный documentId/transportationId и серверный статус
HTTP 422/400	неполные/невалидные данные	data/XML, обязательные поля, роли и стадия
Ошибка JSON	несовместимый тип или ответ	строки кодов, даты, сериализатор версии 8.2/8.3

6.3. Что собирать для разбора

Версия платформы 1С и разрядность процесса.
Имя команды компоненты и HTTP-код.
host без token; token передавать только защищенным каналом ответственному специалисту.
Тип документа, его ссылка/номер и сохраненные ID.
Стадия перевозки и ответ /actions для ЭПД.
Текст исключения криптопровайдера без PIN и закрытых данных.

7. Правила изменения кода

Не переводить и не менять регистр строковых команд Native-компоненты.
Не переводить JSON-ключи и свойства ответа. Для понятности использовать русские локальные переменные и комментарии вокруг них.
Не смешивать модуль 8.2 с модулем 8.3: сериализация JSON и доступные методы платформы различаются.
Не создавать новый transportationId/documentId при повторной попытке подписи.
Не подтверждать eventId до успешной записи события в 1С.
Не выполнять действие ЭПД без проверки /actions и роли организации.
Не хранить PIN и не выводить token в протокол.
После изменения исходника формы обновить тот же модуль внутри EPF и проверить выгрузку Конфигуратором.

8. Контрольный сценарий сопровождения

После установки или изменения выполнить последовательно:

Открыть обработку, выбрать организацию и убедиться, что заголовок показывает правильный контур.
Проверить host/token и выполнить безопасный запрос списка контрагентов или состояния.
Выбрать сертификат; проверить восстановление привязки после повторного открытия формы.
Для ЭДО создать документ, пакет, подпись и обработать событие статуса.
Для ЭПД создать Т1, проверить сохранение transportationId до подписи и отсутствие дубля при повторе.
После Т2 проверить доступность Т3 и серверное подтверждение его регистрации.
Проверить регистры и отсутствие token/PIN в пользовательских сообщениях.

9. Карта исходных файлов

Версия	Файл	Назначение
8.2	`МодульОбъекта_8_2_БОЕВОЙ.txt`	модуль объекта EPF
8.2	`ФормаОбмен_8_2_БОЕВАЯ.txt`	главная обычная форма
8.2	`ОбщийМодульМИГ24_8_2_БОЕВОЙ.txt`	общий модуль с JSON 8.2 и ЭПД
8.2	`ФормаДанныеT1_8_2_БОЕВАЯ.txt`	форма параметров T1
8.3	`МодульОбъекта_8_3_БОЕВОЙ.txt`	модуль объекта EPF
8.3	`ФормаОбмен_8_3_БОЕВАЯ.txt`	главная обычная форма
8.3	`ОбщийМодульМИГ24_8_3_БОЕВОЙ.txt`	общий модуль с JSON платформы 8.3 и ЭПД
Обе	`КомпонентМИГ24.bin`	одинаковый Native-бинарник в обоих комплектах

Запросить исходные файлы можно через info@mig24.ru