— Нормативная база МЭДО
Формат МЭДО версии 2.7.1 предполагает передачу следующих элементов:
- — реквизиты документа в файле xml в соответствии с новым форматом, не связанным с МЭДО;
- — файл документа, который подписан ЭП автора;
- — файл ЭП автора документа;
- — штамп регистрации (номер и дата) и штамп ЭП в виде отдельных графических файлов, координаты для их позиционирования на документе;
- — файл ЭП контейнера (объединения совокупности файлов транспортного контейнера в определенном порядке).
Все вышеперечисленные файлы объединяются в один zip-файл транспортного контейнера, этот файл передается в новом типе сообщения МЭДО (добавлен в МЭДО 2.7.1) – «Транспортный контейнер».
Документ, подписанный ЭП, передаваемый в соответствии со схемой ЭСД МЭДО версии 2.7.1
При отображении на экране и при печати документа графические штампы регистрации и ЭП должны накладываться на страницы документа в соответствии с данными об их местоположении, указанных в соответствующих элементах xml-файла описания транспортного контейнера.
При отправке и получении документов по МЭДО системой обеспечивается проверка целостности транспортного контейнера, соответствие файла описания содержимому транспортного контейнера и отсутствие в нем вредоносных программ, проверка на соответствие требованиям к взаимодействию. При положительном результате проверки полученный документ в электронном виде регистрируется в системе электронного документооборота. По результатам проверки отправителю направляется уведомление.
В случае отрицательного результата проверки оператор не позднее одного часа с момента проведения проверки направляет отправителю транспортную квитанцию в формате, установленном требованиями к взаимодействию.
- — сообщение МЭДО — физически это папка
- — транспортный контейнер МЭДО – это *.edc.zip файл внутри папки
- — файл описания сообщения МЭДО это *.xml файл внутри папки
- — файл описания транспортного контейнера МЭД. это passport.xml находящийся в архиве *.edc.zip
2.5 Приказ Министерства связи и массовых коммуникаций Российской Федерации и Федеральной службы охраны Российской Федерации от 27.05.2015 N 186/258 «ТРЕБОВАНИЯ К ОРГАНИЗАЦИОННО-ТЕХНИЧЕСКОМУ ВЗАИМОДЕЙСТВИЮ ГОСУДАРСТВЕННЫХ ОРГАНОВ И ГОСУДАРСТВЕННЫХ ОРГАНИЗАЦИЙ ПОСРЕДСТВОМ ОБМЕНА ДОКУМЕНТАМИ В ЭЛЕКТРОННОМ ВИДЕ» текст приказа
ПРИКАЗ МИНЦИФРЫ РОССИИ N 667, ФСО РОССИИ N 233 ОТ 04.12.2020 «ОБ УТВЕРЖДЕНИИ ТРЕБОВАНИЙ К ОРГАНИЗАЦИОННО-ТЕХНИЧЕСКОМУ ВЗАИМОДЕЙСТВИЮ ГОСУДАРСТВЕННЫХ ОРГАНОВ И ГОСУДАРСТВЕННЫХ ОРГАНИЗАЦИЙ» (ЗАРЕГИСТРИРОВАНО В МИНЮСТЕ РОССИИ 05.03.2021 N 62668) текст приказа
Постановление Правительства РФ от 24 июля 2021 г. N 1264 «Об утверждении Правил обмена документами в электронном виде при организации информационного взаимодействия» текст приказа
Как транспортный контейнер создать для мэдо
В раздел «Конвертер документов» автоматически попадает транспортный контейнер документа, удовлетворяющий следующим требованиям:
- Находится в каталоге с отправляемыми из системы электронного документооборота (СЭД) электронными сообщениями.
- Вид документа соответствует одному из видов, выбранных в настройках конвертера.
- Не содержит структурированных данных (файл digital.xml).
Каталог отправляемых электронных сообщений указывается в разделе «Настройки», в группе параметров «МЭДО», в поле «Папка исходящих сообщений ГосЭДО из СЭДа» путём ввода с клавиатуры (Рисунок 4.2).
Рисунок 4.2. Поле для указания каталога с отправляемыми из СЭД электронными сообщениями
Виды исходящих документов, которые будут задержаны в конвертере Порталом ГосЭДО перед отправкой, указываются в разделе «Настройки», в группе параметров «Конвертер документов» (Рисунок 4.3).
Рисунок 4.3. Параметры фильтрации, по которым исходящие документы будут помещены в конвертер Портала ГосЭДО
Перед началом работы необходимо настроить параметры фильтрации исходящих документов для конвертера. Подробнее о настройках для конвертера смотрите в разделе Группа «Конвертер документов».
Помимо автоматического наполнения существует возможность ручной загрузки транспортного контейнера МЭДО в конвертер. Для этого предусмотрена кнопка «Загрузить сообщение МЭДО», нажатие на которую приведёт к открытию окна выбора файла, в котором следует выбрать архив, сформированный системой электронного документооборота для отправки. Контейнер будет загружен не зависимо от настроек вида документа, но если в нём уже присутствуют структурированные данные, то он будет проигнорирован конвертером.
Особенности интеграции СЭД с МЭДО
За десятилетия реализации проектов по внедрению, поддержке и развитию систем электронного документооборота у Digital Design накопилось много информации о том, как выполнять работы быстрее и эффективнее. В новой статье Денис Стогов, руководитель проектов направления автоматизации бизнес-процессов, делится опытом и секретами успешных работ по интеграции СЭД с МЭДО.
Денис Стогов
Руководитель проектов направления автоматизации бизнес-процессов, Digital Design
В случае возникновения у организации потребности подключиться к системе межведомственного электронного документооборота (МЭДО) необходимо осуществить соответствующую интеграцию со своей системой электронного документооборота (СЭД).
Интеграция с МЭДО выполняется в несколько этапов:
- Подготовка. Данный этап инициируется при обращении в Федеральную службу охраны РФ (ФСО), где организация добавляется в состав участников МЭДО и фиксируется адрес организации в системе. Организовывается инфраструктура для подключения СЭД к МЭДО через защищённые каналы связи. ФСО согласно постановлению РФ №477 является организатором МЭДО, поэтому посредством данной службы подключаются новые участники обмена: федеральные органы исполнительной власти субъектов РФ, иные государственные органы и государственные внебюджетные фонды.
- Создание модуля интеграции, посредством которого осуществляется обмен данными между МЭДО и системой документационного управления, выполнение функционального и нагрузочного тестирования, разработка пакета документов по установке, настройке и использованию модуля.
- Промышленное внедрение модуля для обмена данными между МЭДО и СЭД.
Этап №1 (организационно-технический)
Для организации, которая планирует стать участником обмена, необходимо оформить документы в ФСО и осуществить закупку оборудования для подключения СЭД по защищённому каналу к шлюзу МЭДО. На этом этапе особых проблем обычно не возникает, а если и присутствуют какие-либо задержки, то повлиять на них крайне сложно. В основном данным этапом занимаются непосредственно сотрудники организации, назначенные ответственными за подключение, такие как технический руководитель.
Этап №2 (создание модуля)
В данной же статье будут приведены некоторые сложности и особенности этапа №2, с которыми может столкнуться организация, выполняющая разработку/адаптацию модуля интеграции. Компания Digital Design не раз столкнулась с особенностями интеграции МЭДО при адаптации СЭД для государственных органов на платформе Docsvision.
Задача этапа №2 заключается в том, чтобы создать модуль или, как его ещё называют, адаптер, автоматизирующий в организации обмен документами с участниками, подключёнными к МЭДО, посредством СЭД. При этом необходимо учесть особенности взаимодействия через государственную систему документоборота, реализовать интуитивно понятный интерфейс, обеспечить надёжность, безопасность и мониторинг интеграции и сохранить целостность уже существующих в системе автоматизированных процессов.
С одной стороны, кажется, что в части входящих документов достаточно принять пакет, полученный по МЭДО, распарсить полученное xml-описание и аккуратно уложить данные в СЭД, а в части исходящих документов – упаковать подготовленные файлы, создать стандартизированное xml-описание и выложить полученный пакет на отправку в МЭДО. Всё верно, но с достаточным количеством нюансов, о которых и будет идти речь.
Особенности исходящих документов
Рекомендация по выбору вида доставки МЭДО
Если в организации процессом оформления и отправки исходящих документов по МЭДО будет заниматься специальный сотрудник или даже целый отдел, то проблемы «Как идентифицировать, что документ может быть отправлен по МЭДО?» нет, потому что специалисты прошли инструктаж, обучены и знают, как оформлять документы и какие контрагенты подключены к МЭДО. Но что, если по процессам организации не предусмотрен такой отдел, и с оформлением документа для отправки по МЭДО должен справиться любой рядовой сотрудник, не подозревающий о существовании способа отправки документа по МЭДО?
В таком случае необходимо, чтобы СЭД помогала пользователю выполнить правильное оформление. Для этого была разработана выдача рекомендации по выбору вида доставки МЭДО. В справочник контрагентов СЭД вносятся все организации-участники обмена со специальным свойством, определяющим возможность отправки по МЭДО. Если сотрудник, оформляя исходящий документ, выбирает в качестве адресата организацию-контрагента, являющуюся участником обмена по МЭДО, то в виде диалогового окна отображается рекомендация, предлагающая установить вид доставки МЭДО для выбранного контрагента. С этого момента пользователь начинает знакомиться с МЭДО.
Требования к оформлению документа
Далее необходимо решить проблему правильного оформления документа, ведь пользователь ещё не знает, что для отправки по МЭДО необходимо соблюсти некоторые правила. Поэтому если пользователь согласился установить вид доставки МЭДО, то после рекомендации из п.1 отображается информационное окно с описанием шагов, которые необходимо выполнить для оформления документа:
- Провести согласования документа, консолидировав все правки в одном главном файле;
- Перед отправкой руководителю на утверждение необходимо сконвертировать главный файл в формат PDF\A-1.
В системе должна быть предусмотрена возможность быстрого конвертирования выбранного главного файла в PDF\A-1.
Очень важно отравлять на подпись (утверждение) уже сконвертированный в PDF\A-1 файл, в противном случае (если сначала подписать, например, DOCX, а затем его сконвертировать в PDF\A-1) электронная подпись перестанет быть действительной из-за изменения контрольной суммы файла.
Далее необходимо обеспечить, чтобы СЭД при отправке документа на утверждение и подписание проверяла формат главного файла. Для проверки файла документа на соответствие формату PDF/A-1 в методических рекомендациях предлагается использовать утилиту veraPDF.
После подписания руководителем и присвоения документу регистрационного номера регистратор документа должен нанести на главный файл штамп электронной подписи и регистрационных данных. Для этого был разработан мастер нанесения штампов, с помощью которого регистратор за несколько кликов размещает штампы на документе. При этом главный файл не изменяется: создаются файлы штампов (PNG), файл визуализации с нанесёнными штампами и запоминаются координаты их размещения на документе. На этом оформление можно считать завершённым, документ готов к отправке.
Требования к оформлению предъявляются согласно последнему на текущий момент формату МЭДО 2.7. Во-первых, для единообразия, чтобы пользователь всегда оформлял документ для отправки по МЭДО по одному и тому же пути. Во-вторых, предыдущие форматы теоретически могут быть сняты с поддержки, и регулятор может принудить все ведомства обновиться до последней актуальной версии 2.7. Но о версионности чуть позже.
Наличие усиленной квалифицированной электронной подписи (УКЭП)
Для отправки документа по МЭДО 2.7 необходимо, чтобы утверждающее лицо подписало главный файл УКЭП, поэтому было принято решение предусмотреть в СЭД 3 проверки:
- При отправке файлов на утверждение выполняется проверка наличия УКЭП у утверждающего лица. Если УКЭП отсутствует, то автор документа получает об этом сообщение. Далее пользователь решает, отправлять документ текущему утверждающему лицу или заменить его.
- Когда утверждающее лицо получает на подпись документ и решает его подписать, то система производит проверку, является ли его сертификат квалифицированным. Если нет, то система поясняет, что такой документ должен быть подписан УКЭП и предлагает оформить выпуск квалифицированного сертификата в случае его отсутствия.
- Дополнительно перед непосредственной отправкой документа по МЭДО система выполняет проверку подписи главного файла. Если она нанесена с помощью квалифицированного сертификата, то проверка считается пройденной. Если подпись не является квалифицированной, то пользователь уведомляется, что документ без УКЭП отправить по МЭДО не представляется возможным, и система просит отправить документ на утверждение с подписанием УКЭП.
Название и идентификатор организации
После того, как ФСО добавит организацию в список участников обмена по МЭДО, за организацией закрепляются 2 параметра:
- Название;
- Идентификатор (GUID).
Данные параметры присылает ФСО, и их необходимо использовать при формировании xml-описания исходящих пакетов в тегах Source (Источник) и Organization (Организация). Для этого, разумеется, необходимо предусмотреть системные настраиваемые поля, в которых будут указаны 2 параметра. В целом всё элементарно, за исключением того, что тег Organization, в отличии от Source, встречается не один раз, и если в прикладном справочнике СЭД название вашей организации отличается от того названия, которое было присвоено ФСО, то необходимо в каждом таком случае заполнять название организации из настройки, а не из прикладного справочника. На это просто стоит обратить внимание.
Запрет отправки конфиденциальных документов
Если СЭД используется для конфиденциального документооборота, то необходимо обеспечить ограничение отправки конфиденциальных документов по каналу МЭДО. Для этого в СЭД было реализовано 2 механизма:
- Взаимная проверка полей «Гриф» и «Вид доставки». Если пользователь попытается установить гриф о конфиденциальности документа, в котором уже установлен вид доставки МЭДО, то система не позволит этого сделать, отображая соответствующее информационное окно. Аналогична и обратная проверка: система не позволит установить вид доставки МЭДО в том документе, в котором уже установлен конфиденциальный гриф.
- Проверка из п.1 реализована посредством настроек свойств вида доставки, поэтому в теории недобропорядочный администратор мог бы на время отключить проверку и попробовать отправить документ с грифом о конфиденциальности по МЭДО. Для предотвращения последствий такой ситуации была реализована дополнительная проверка грифа при непосредственной отправке документа по МЭДО. При наличии грифа о конфиденциальности проверка считается непройденной и пользователь получает информационное сообщение о невозможности отправки по МЭДО конфиденциального документа.
Гибкость уведомлений
В модуле (адаптере) СЭД необходимо предусмотреть возможность настраивать и отключать любое из заявленных уведомлений. В зависимости от специфики ведомства/организации определённое уведомление может быть неприменимо.
Версионность МЭДО
И напоследок в части исходящих документов один из самых важных нюансов – это различные версии форматов (схем) МЭДО. Последний формат МЭДО 2.7 зарегистрирован в Минюсте России 22.09.2015 № 38956. Для межведомственного электронного взаимодействия с внешними системами используются форматы МЭДО 2.2, МЭДО 2.5, МЭДО 2.6, МЭДО 2.7, отличающееся друг от друга составом передаваемых элементов. До МЭДО 2.6 включительно изменения были незначительные, но с МЭДО 2.7 существенно изменился состав – добавился новый тип сообщения под названием «Транспортный контейнер». Ранее все документы передавались как сообщения под названием «Документ». Тип сообщения – это, по сути, определённый набор элементов (файлов), который будет передан по каналу МЭДО.
Состав компонентов «Транспортного контейнера» схемы МЭДО 2.7:
- файл описания транспортного контейнера;
- файл документа;
- файл(ы) ЭП документа;
- файлы графических элементов регистрации и отметки об ЭП;
- файл(ы) приложений, файл(ы) ЭП приложений (при наличии);
- файл ЭП транспортного контейнера.
При этом по версиям ниже 2.7 можно отправить неподписанный ЭП файл формате, например, TIFF.
Главные отличия нового типа сообщения от старого заключаются в следующем:
- Основной файл теперь должен иметь формат PDF/A-1;
- Основной файл должен быть подписан усиленной квалифицированной электронной подписью в формате PKCS#7;
- Должны быть сгенерированы и указаны в xml-описании файлы штампов (регистрационных данных и штампы-отметки УКЭП) и координаты их размещения на основном файле.
Различные версии схем МЭДО влияют как на исходящие, так и на входящие документы. Какое влияние оказывается на исходящие? Дело в том, что на текущий момент к МЭДО подключено более 300 участников, различных ведомств, ФОИВов, и среди них некоторые до сих пор поддерживают только изначально внедрённую версию 2.2, кто-то установил по схеме 2.5, а ещё кто-то уже давно перешёл на последний формат 2.7. Не существует приказа об обновлении адаптера СЭД до новой схемы МЭДО. То есть многие организации со схемой ниже 2.7 не способны принять «Транспортный контейнер», потому что на момент внедрения у них не было знания о таком типе сообщения. Они способны принять только сообщение типа «Документ».
Поэтому важно, чтобы модуль СЭД был способен формировать сообщения разных типов («Документ» и «Транспортный контейнер») в рамках одной отправки документа по МЭДО, так как в адресатах могут быть указаны организации-контрагенты, имеющие разные версии схем МЭДО.
При этом важно понимать, что у МЭДО нет API, по которому вы смогли бы в автоматическом режиме запросить актуальные данные по всем подключенным организациям и их версиям. Можно регулярно вне СЭД обращаться к ФСО, получать от этой службы список организаций как, например, этот, и на его основе вести в своём прикладном справочнике контрагентов СЭД версионность схем МЭДО для каждой организации. Таким образом для всех организаций, у которых установлен адаптер по схеме 2.7 отправлять «Транспортный контейнер», а всем остальным – тип сообщения «Документ». Именно поэтому важно, чтобы все исходящие документы изначально шли по пути оформления и формирования набора элементов, достаточного для «Транспортного контейнера», так как из элементов «Транспортного контейнера» можно сгенерировать сообщение типа «Документа», а наоборот невозможно. Либо можно пойти по более простому пути и отправлять всем участникам МЭДО сообщения типа «Документ», так как независимо от версии схемы любой участник будет способен обработать такой тип сообщения. При этом необходимо быть готовыми к гипотетическому принудительному переходу на тип сообщения «Транспортный контейнер», поэтому, как уже было сказано выше, стоит заранее озаботиться настройками в СЭД по отправке сообщений различных типов.
Особенности входящих документов
Обязательность элементов разных XSD схем
При получении входящих документов необходимо учитывать, что документы могут быть присланы одним из двух типов сообщения, о которых говорилось выше. Для каждого из этих типов есть XSD схема, в которой обозначены обязательности элементы. В основном они совпадают, но есть и несовпадающие. Например, в XSD схеме «Документ» элемент «Вид документа» является необязательным, а в XSD схеме «Транспортный контейнер» это элемент уже обязательный. Поэтому при парсинге xml описания входящего пакета нужно либо определять тип сообщения и вести проверку элементов по XSD схеме определённого типа, либо отсутствие элемента не должно быть трактовано как ошибка, если этот элемент в одной из схем задан как необязательный.
Ошибка указания идентификатора в квитанции
Данный пункт, очевидно, не фигурирует ни в одной методической рекомендации или нормативном документе, так как относится к человеческому фактору. В ходе промышленной эксплуатации оказалось, что многие участники МЭДО при формировании квитанции, представляющей xml файл, некорректно указывают идентификатор в атрибуте acknowledgment. Возможно, это связано с интуитивным противоречием, но, тем не менее, многие ведомства ошибочно заполняют этот атрибут идентификатором документа вместо идентификатора сообщения. Как результат, если модуль будет искать в СЭД идентификатор сообщения по идентификатору из атрибута acknowledgment, как указано в нормативной документации, то поиск завершится нулевым результатом и входящая квитанция не будет присоединена к документу. Поэтому стоит учитывать, что некоторые участники МЭДО при адаптации своих СЭД могли допустить ошибку, и выполнять поиск необходимо не только по идентификатору сообщения, но и по идентификатору документа СЭД. Получение коллизий при этом невозможно.
Проверка электронной подписи
По канонам безопасности электронная подпись содержит в себе всю цепочку сертификатов, кроме корневого, а именно личный сертификат пользователя и промежуточные сертификаты. Так как файлы входящего документа подписаны УКЭП, то необходимо проверять саму ЭП, статус сертификата (цепочки сертификатов), а также принадлежность удостоверяющего центра (УЦ) к аккредитованным и не отозванным. Сложность в том, что МЭДО не предоставляет всех актуальных данных для проверки и необходимо заранее озаботиться созданием механизма по проверке входящих ЭП от внешней организации.
Общие особенности
Мониторинг
В рамках обмена по МЭДО возможны ситуации, когда принимающая организация отказала в регистрации документа, но не отправила уведомление об отказе в регистрации или по техническим причинам не смогла принять и обработать документ. К сожалению, сама система МЭДО не реагирует на подозрительное отсутствие соответствующих квитанций или уведомлений, не отслеживает, удалось ли принимающей стороне правильно обработать документ. Подразумевается, что адаптеры СЭД должны идеально информировать друг друга с помощью квитанций и уведомлений. Поэтому во избежание потери контроля за жизненным циклом документа в мониторинге входящих и исходящих документов МЭДО необходимо отслеживать наличие необходимых квитанций и уведомлений в том числе по прошествии определённого времени. Для вывода документов в мониторинг можно в качестве точечных примеров использовать следующие критерии:
- Не отправлены более 30 мин.;
- Не зарегистрировано > 1 дня;
- Отказано в регистрации.
- Уведомление/квитанция не отправлено более 30 мин.;
- Ошибка отправки уведомления/квитанции;
- Отклонен, но уведомление не отправлено;
- Зарегистрирован, но уведомление не отправлено.
Так как потеря одного документа МЭДО может обернуться для организации серьёзными последствиями, то стоит озаботиться выявлением битых пакетов или объектов СЭД путём их дополнительного мониторинга и уведомления администратора.
Отсутствие тестовой среды
На текущий момент тестовая среда для проверки функциональности адаптера СЭД и обмена пакетами МЭДО отсутствует. Фактически существует два варианта тестирования:
- Подготовить различного рода пакеты (Документы, Транспортный контейнеры, Уведомления, Квитанции) и имитировать вторую сторону обмена путём подкладывания таких пакетов напрямую в адаптер СЭД.
- Осуществить договорённость с определённым участником МЭДО и обменяться тестовыми документами через промышленную среду.
Digital Design при разработке и внедрении адаптера для МЭДО выполняет тестирование на обширном количестве тестовых пакетов, охватывающих все выявленные за многие годы нюансы и кейсы. Тестовый обмен по договорённости с другим участником МЭДО в промышленной среде организация выполняет на своё усмотрение при нашем сопровождении.
Заключение
Если принять во внимание и учесть все вышеуказанные пункты, то разработка и внедрение адаптера СЭД для обмена документами по МЭДО могут быть выполнены в разумные сроки с минимальным количеством сложностей и неожиданностей. Желаем всем заказчикам и исполнителям правильных внедрений!
Как транспортный контейнер создать для мэдо
4 февраля 2024 Регистрация Войти
6 февраля 2024
(1).jpg)
Об актуальных изменениях в КС узнаете, став участником программы, разработанной совместно с АО »СБЕР А». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.
12 февраля 2024
Программа разработана совместно с АО »СБЕР А». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.
Продукты и услуги Информационно-правовое обеспечение ПРАЙМ Документы ленты ПРАЙМ Приказ Министерства цифрового развития, связи и массовых коммуникаций РФ и Федеральной службы охраны РФ от 29 июня 2022 г. № 500/82 «Об утверждении Технических требований к порядку ведения нормативно-справочной информации системы межведомственного электронного документооборота»
Обзор документа
Приказ Министерства цифрового развития, связи и массовых коммуникаций РФ и Федеральной службы охраны РФ от 29 июня 2022 г. № 500/82 «Об утверждении Технических требований к порядку ведения нормативно-справочной информации системы межведомственного электронного документооборота»
19 декабря 2022
В соответствии с пунктом 10 Правил обмена документами в электронном виде при организации информационного взаимодействия, утвержденных постановлением Правительства Российской Федерации от 24 июля 2021 г. № 1264 (Собрание законодательства Российской Федерации 2021, № 31, ст. 5927), приказываем:
Утвердить прилагаемые Технические требования к порядку ведения нормативно-справочной информации системы межведомственного электронного документооборота.
| Министр цифрового развития, связи и массовых коммуникаций Российской Федерации |
М.И. Шадаев |
| Директор Федеральной службы охраны Российской Федерации |
Д.В. Кочнев |
Зарегистрировано в Минюсте РФ 16 декабря 2022 г.
УТВЕРЖДЕНЫ
приказом Министерства цифрового развития,
связи и массовых коммуникаций
Российской Федерации
и Федеральной службы охраны
Российской Федерации
от 29 июня 2022 г. № 500/82
Технические требования к порядку ведения нормативно-справочной информации системы межведомственного электронного документооборота
1. Настоящий документ устанавливает технические требования к порядку ведения нормативно-справочной информации системы межведомственного электронного документооборота в части сведений, содержащихся в глобальном адресном справочнике, необходимых для формирования транспортных контейнеров и электронных сообщений.
2. Настоящие Технические требования определяют:
а) технические требования к структуре данных и формату глобального адресного справочника;
б) технологический регламент создания, формирования и рассылки глобального адресного справочника (приложение № 1 к настоящим Техническим требованиям);
в) формат технологического сообщения в соответствии с подпунктом «а» пункта 5 Порядка информационного взаимодействия при ведении глобального адресного справочника, являющегося приложением к Правилам обмена документами в электронном виде при организации информационного взаимодействия, утвержденным постановлением Правительства Российской Федерации от 24 июля 2021 г. № 1264 (Собрание законодательства Российской Федерации 2021, № 31, ст. 5927) (приложение № 2 к настоящим Техническим требованиям).
3. Глобальный адресный справочник должен содержать:
а) сведения об организаторе межведомственного электронного документооборота (далее — организатор), в том числе уникальный идентификатор организатора для адресации технологических сообщений, информацию об организации и лицах, ответственных за решение технических вопросов:
б) сведения об операторах информационного взаимодействия (далее — операторы), в том числе уникальные идентификаторы операторов для адресации технологических сообщений, информацию об организации и лицах, ответственных за решение технических вопросов;
в) сведения об участниках информационного взаимодействия (далее — участники), в том числе уникальные идентификаторы участников для адресации электронных сообщений, идентификаторы обслуживающих операторов, информацию об организации и лицах, ответственных за решение технических вопросов, статус готовности участника к обмену информацией, доступ к которой ограничен в соответствии с законодательством Российской Федерации;
г) сведения об организациях участников, в том числе полное фирменное наименование юридического лица, номер телефона, электронной почты (при наличии), адрес в пределах места нахождения юридического лица, а также сведения об итогах аттестации, используемой в организации участника системы электронного документооборота, о подразделениях и должностных лицах организаций участников, при наличии технической возможности формирования и предоставления участником таких сведений.
4. Организатор межведомственного электронного документооборота (далее — организатор) ведет справочники в соответствии с пунктами 6, 9, 10 Правил обмена документами в электронном виде при организации информационного взаимодействия, утвержденных постановлением Правительства Российской Федерации от 24 июля 2021 г. № 1264 (Собрание законодательства Российской Федерации 2021, № 31, ст. 5927).
5. Передача технологического сообщения осуществляется в составе транспортного контейнера технологического сообщения, содержащего следующие элементы формата:
а) описание транспортного контейнера технологического сообщения;
б) данные технологического сообщения;
в) визуализацию технологического сообщения (необязательно);
г) файл контроля целостности содержимого транспортного контейнера технологического сообщения (необязательно).
Приложение № 1
к Техническим требованиям
к порядку ведения нормативно-
справочной информации системы
межведомственного электронного
документооборота
Технологический регламент создания, формирования и рассылки глобального адресного справочника
1. Организатор межведомственного электронного документооборота (далее — организатор) создает централизованный информационный ресурс для организации ведения глобального адресного справочника (далее — ГАС).
2. ГАС содержит отдельные виды сведений (далее — реестры), определяемые в соответствии с требованиями к структуре данных и формату ГАС, установленными Техническими требованиями к порядку ведения нормативно-справочной информации системы межведомственного электронного документооборота, утвержденными приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации и Федеральной службы охраны Российской Федерации от 29 июня 2022 г. № 500/82 (далее — Технические требования).
3. Организатор формирует запись об организаторе и связанные с ней записи реестра операторов в соответствии с текущим состоянием подключения операторов к межведомственному электронному документообороту.
4. Процедура добавления в реестр новых операторов включает выполнение следующих мероприятий:
а) юридическое лицо, планирующее получить статус оператора, направляет в адрес организатора официальное письмо с заявкой на создание нового оператора информационного взаимодействия, содержащее:
информацию о лицах, ответственных за решение технических вопросов;
основания для создания нового оператора;
параметры создания и функционирования нового оператора (в том числе описание предполагаемого состава участников, описание архитектуры присоединения участников);
описание программного обеспечения для автоматизации функций оператора;
правила допуска участников, которые будут использоваться оператором при присоединении участников информационного взаимодействия;
б) организатор получает от участника заявку, проверяет ее на обоснованность включения предполагаемого состава участников в глобальный адресный справочник, а также на возможность реализации всех требований Правил обмена документами в электронном виде при организации информационного взаимодействия, утвержденных постановлением Правительства Российской Федерации от 24 июля 2021 г. № 1264, в рамках используемой архитектуры присоединения участников и направляет участнику в ответ:
результат рассмотрения заявки (с обоснованием);
идентификатор нового оператора (при положительном решении).
5. Правила допуска участников формируются юридическим лицом, планирующим получить статус оператора, и содержат критерии допуска новых организаций в состав участников оператора.
6. Изменение параметров функционирования операторов, в случае необходимости изменения правил допуска участников или архитектуры присоединения участников, выполняется путем обмена официальными письмами между организатором и участником.
7. Организатор формирует записи реестра участников по информации об участниках, получаемой от операторов, посредством обмена технологическими сообщениями в формате транспортного контейнера для глобального адресного справочника, установленном Техническими требованиями.
8. Для добавления новых участников выполняются следующие процедуры:
а) оператор направляет в адрес организатора технологическое сообщение «Заявка оператора на добавление новых участников», содержащее:
уникальный идентификатор заявки;
номер и дату заявки (по данным оператора);
идентификатор оператора в справочнике ГАС;
перечень новых участников, содержащий сведения об участниках информационного взаимодействия, а также основания добавления. Основания добавления участников определяются оператором самостоятельно с учетом согласованных с организатором правил допуска участников, исходя из (включая, но не ограничиваясь) их организационно-правовой формы, подведомственной принадлежности к органам государственной власти, принадлежности к территориальным органам федеральных органов исполнительной власти, территориальной принадлежности к субъекту Российской Федерации;
б) организатор получает технологическое сообщение от оператора и проверяет его на соответствие формату. При выявлении отклонений от требований формата организатор прекращает рассмотрение заявки и направляет оператору технологическое сообщение «Ответ организатора по добавлению новых участников», содержащее:
уникальный идентификатор ответа;
уникальный идентификатор исходной заявки;
комментарий с описанием выявленных отклонений;
в) организатор по каждой позиции заявки принимает решение о включении нового участника в ГАС, с учетом ранее согласованных с данным оператором правил допуска участников, после чего направляет оператору технологическое сообщение «Ответ организатора по добавлению новых участников», содержащее:
уникальный идентификатор ответа;
уникальный идентификатор исходной заявки;
принятые решения по каждому участнику исходной заявки;
сведения новых зарегистрированных участников, включающие присвоенные уникальные идентификаторы — по согласованным позициям;
комментарий с причиной отклонения (в том числе наличие участника в реестре, некорректные сведения об участнике, недостаточные основания для добавления участника) — по отклоненным позициям.
9. Для изменения в реестре существующих записей об участниках выполняются следующие процедуры:
а) оператор направляет в адрес организатора технологическое сообщение «Заявка оператора на изменение сведений об участниках», содержащее:
уникальный идентификатор заявки;
номер и дату заявки (по данным оператора);
идентификатор оператора в справочнике ГАС;
перечень уникальных идентификаторов участников и обновленные сведения по ним, а также основания для внесения изменений;
б) организатор получает технологическое сообщение от оператора и проверяет его на соответствие формату. При выявлении отклонений от требований формата организатор прекращает рассмотрение заявки и направляет оператору технологическое сообщение «Ответ организатора по изменению сведений об участниках», содержащее:
уникальный идентификатор ответа;
уникальный идентификатор исходной заявки;
комментарий с описанием выявленных отклонений;
в) организатор по каждой позиции заявки принимает решение о внесении обновленных сведений в глобальный адресный справочник с учетом ранее согласованных с данным оператором формальных правил допуска участников, после чего направляет оператору технологическое сообщение «Ответ организатора по изменению сведений об участниках», содержащее:
уникальный идентификатор ответа;
уникальный идентификатор исходной заявки;
принятые решения по каждому участнику исходной заявки;
обновленные сведения участников — по согласованным позициям;
комментарий с причиной отклонения (в том числе некорректные сведения об участнике, недостаточные основания для изменения сведений об участнике) — по отклонённым позициям.
10. Организатор осуществляет первичное формирование записи об организации в реестре организаций участников по информации от операторов и дальнейшее обновление записи об организации, а также формирование сведений о подразделениях и должностных лицах от участников, получаемой посредством обмена технологическими сообщениями в формате, содержащемся в приложении № 2 к Техническим требованиям.
11. Добавление новых записей в реестр организаций участников происходит при добавлении новых записей в реестр участников. При этом новые записи в реестре организаций участников содержат сведения, предоставляемые оператором в «Заявке оператора на добавление новых участников»:
ОГРН организации участника;
полное фирменное наименование юридического лица — участника;
адрес юридического лица в пределах места нахождения юридического лица.
12. Для изменения в реестре существующих записей об организациях участников выполняются следующие процедуры:
а) участник направляет в адрес организатора технологическое сообщение «Заявка участника на изменение сведений об организации», содержащее:
уникальный идентификатор заявки;
номер и дату заявки (по данным участника);
идентификатор участника в справочнике ГАС;
обновлённые реквизиты организации участника;
сведения об итогах аттестации систем электронного документооборота участника;
перечень подразделений, сведения о которых изменяются;
перечень должностных лиц, сведения о которых изменяются;
б) организатор получает технологическое сообщение от участника и проверяет его на соответствие формату транспортного контейнера для ГАС. При выявлении отклонений от требований формата организатор прекращает рассмотрение заявки и направляет участнику технологическое сообщение «Ответ организатора по изменению сведений об организации», содержащее:
уникальный идентификатор ответа;
уникальный идентификатор исходной заявки;
комментарий с описанием выявленных отклонений;
в) организатор вносит обновленные сведения в ГАС, после чего направляет участнику технологическое сообщение «Ответ организатора по изменению сведений об организации», содержащее:
уникальный идентификатор ответа;
уникальный идентификатор исходной заявки;
обновленные сведения об организации участника (в том числе реквизиты организации участника, перечень подразделений и должностных лиц организации участника).
13. Организатор рассылает сведения из ГАС (в том числе при появлении в нем новых операторов или участников либо при обновлении сведений об операторах, участниках или организациях участников).
14. Для рассылки сведений из ГАС выполняются следующие процедуры:
а) организатор создает новую версию публикации сведений и направляет участникам межведомственного электронного документооборота технологическое сообщение «Актуальный глобальный адресный справочник»;
б) операторы в течение одного часа с момента получения технологического сообщения обеспечивают доведение полученных сведений до всех обслуживаемых ими участников, в зависимости от имеющейся у оператора технической возможности:
посредством загрузки в систему электронного документооборота, используемую участниками (в случае использования участниками единой системы электронного документооборота);
посредством отправки полученного технологического сообщения в адреса соответствующих участников (в случае использования участниками собственных систем электронного документооборота, интегрированных с использованием информационно-телекоммуникационных технологий).
15. Для рассылки сведений из глобального адресного справочника по индивидуальному запросу выполняются следующие процедуры:
а) оператор или участник направляет в адрес организатора технологическое сообщение «Запрос глобального адресного справочника» с указанием параметров получения сведений в соответствии с форматом, содержащимся в приложении № 2 к Технологическим требованиям;
б) организатор получает технологическое сообщение и направляет в ответ технологическое сообщение «Отправка глобального адресного справочника», содержащее запрошенные сведения из глобального адресного справочника.
Приложение № 2
к Техническим требованиям
к порядку ведения нормативно-
справочной информации системы
межведомственного электронного
документооборота
Формат транспортного контейнера для глобального адресного справочника
I. Формат транспортного контейнера
1. Файл транспортного контейнера должен иметь название «addressees.edc.zip».
Тип транспортного контейнера, указываемый в файле описания электронного сообщения, должен иметь значение «Сведения глобального адресного справочника (далее — ГАС)» (обязательно для заполнения).
2. Транспортный контейнер должен содержать файл паспорта транспортного контейнера, в котором совмещены элементы «описание транспортного контейнера» и «данные технологического сообщения» (далее — паспорт).
3. Транспортный контейнер может содержать визуализацию технологического сообщения (в виде отдельного файла в формате HTML), предназначенную для просмотра человеком при отсутствии возможности машинной обработки. При её наличии название файла указывается в описании транспортного контейнера.
4. Транспортный контейнер может содержать электронную подпись основных элементов транспортного контейнера (в виде отдельного файла в формате P7S), предназначенную для контроля целостности содержимого. При ее наличии название файла указывается в описании транспортного контейнера.
5. Файл паспорта транспортного контейнера должен иметь название «passport.xml».
Файл паспорта транспортного контейнера представляется в формате XML, в соответствии со схемой, приведенной в разделе III настоящего приложения.
6. Файл паспорта транспортного контейнера оформляется в кодировке «UTF-8», первая строка содержит текст: «».
7. Номер версии формата файла описания транспортного контейнера — 2.7.1.
II. Правила заполнения отдельных элементов паспорта
8. Правила заполнения отдельных элементов паспорта транспортного контейнера приведены в таблице 1 настоящего приложения.
9. Кратность элемента должна определять его минимальное и максимальное допустимое число повторений в файле описания, а также обязательность его заполнения:
1 — элемент указывается один раз и заполняется обязательно;
1..n — элемент повторяется необходимое число раз и заполняется обязательно;
0..1 — элемент либо не указывается, либо указывается один раз и заполняется обязательно, если выполняются условия его обязательного заполнения, указанные в описании элемента;
0..n — элемент либо не указывается, либо повторяется необходимое число раз и заполняется обязательно, если выполняются условия его обязательного заполнения, указанные в описании элемента.
Таблица 1. Список элементов схемы
| Пункт № | Идентификатор | Тип | Кратность | Описание элемента |
|---|---|---|---|---|
| Описание корневых типов данных: | ||||
| 1 | container | Сложный | 1 | Паспорт транспортного контейнера ГАС |
| 1.1 | @version | Строка | 1 | Версия XML-схемы паспорта: «2.7.1» |
| 1.2 | header | Сложный | 1 | Описание транспортного контейнера |
| 1.2.1 | uid | Заданный | 1 | Уникальный идентификатор контейнера Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 1.2.2 | created | Заданный | 1 | Дата и время создания контейнера Заданный тип: «dateTimeZone» (пункт 7 настоящей таблицы) |
| 1.2.3 | previewFile | Заданный | 0 | Название файла визуализации технологического сообщения Заданный тип: «fileName» (пункт 5 настоящей таблицы) |
| 1.2.4 | signatureFile | Заданный | 0 | Название файла электронной подписи транспортного контейнера Заданный тип: «fileName» (пункт 5 настоящей таблицы) |
| Данные технологического сообщения — одно из следующих значений: | ||||
| referenceActual | Заданный | 1 | Актуальные сведения ГАС Заданный тип: «referenceActual» (пункт 20 настоящей таблицы) | |
| 1.3 | referenceHistory | Заданный | 1 | Исторические сведения ГАС Заданный тип: «referenceHistory» (пункт 21 настоящей таблицы) |
| referenceRequest | Заданный | 1 | Запрос глобального адресного справочника Заданный тип: «referenceRequest» (пункт 22 настоящей таблицы) | |
| referenceResponse | Заданный | 1 | Отправка глобального адресного справочника Заданный тип: «referenceResponse» (пункт 23 настоящей таблицы) | |
| docAddParticipantsRequest | Заданный | 1 | Заявка оператора на добавление новых участников Заданный тип: «docAddParticipantsRequest» (пункт 24 настоящей таблицы) | |
| docAddParticipantsResponse | Заданный | 1 | Ответ организатора по добавлению новых участников Заданный тип: «docAddParticipantsResponse» (пункт 25 настоящей таблицы) | |
| docUpdateParticipantsRequest | Заданный | 1 | Заявка оператора на изменение сведений об участниках Заданный тип: «docUpdateParticipantsRequest» (пункт 26 настоящей таблицы) | |
| docUpdateParticipantsResponse | Заданный | 1 | Ответ организатора по изменению сведений об участниках Заданный тип: «docUpdateParticipantsResponse» (пункт 27 настоящей таблицы) | |
| docUpdateOrganizationDataRequest | Заданный | 1 | Заявка участника на изменение сведений об организации Заданный тип: «docUpdateOrganizationDataRequest» (пункт 28 настоящей таблицы) | |
| docUpdateOrganizationDataResponse | Заданный | 1 | Ответ организатора по изменению сведений об организации Заданный тип: «docUpdateOrganizationDataResponse» (пункт 29 настоящей таблицы) | |
| Описание задаваемых типов данных: | ||||
| 2 | numberValue | Простой | — | Базовый тип: число (от 1 до ) |
| 3 | stringValue | Простой | — | Базовый тип: строка (от 1 до 511 символов) |
| 4 | identityValue | Простой | — | Идентификатор объекта (код) |
| 5 | fileName | Простой | — | Имя файла внутри контейнера |
| 6 | globalUniqueldentifier | Простой | — | Универсальный уникальный идентификатор Вид: «iiiiiiii-iiii-iiii-iiii-iiiiiiiiiiii» |
| 7 | dateTimeZone | Простой | — | Дата и время с указанием часового пояса Вид: «YYYY-MM-DDThh:mm:ss hh:mm» |
| 8 | orgRegNum | Простой | — | Базовый тип: нормализованная строка Ограничение: длина 13 символов |
| 9 | qualifiedValue | Сложный | — | Базовый тип: строка |
| 9.1 | @id | Заданный | 1 | Заданный тип: «identity Value» |
| 10 | communicationPartner | Сложный | — | Регистрационная информация организатора/оператора/участника |
| 10.1 | title | Строка | 1 | Сокращенное (при наличии) наименование организатора/оператора/участника |
| 10.2 | organization | Строка | 1 | Полное фирменное наименование юридического лица (организации) |
| 10.3 | authority | Строка | 1 | Фамилия, имя, отчество (при наличии) лица, ответственного за решение технических вопросов (далее — ответственное лицо) |
| 10.4 | phone | Строка | 1 | Номер телефона ответственного лица |
| 10.5 | Строка | 1 | Адрес электронной почты ответственного лица | |
| 11 | communicationServi ce | Сложный | — | Параметры взаимодействия с организатором/оператором/участником |
| 11.1 | operatorUid | Заданный | 1 | Идентификатор обслуживающего оператора Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 11.2 | isActive | Булево | 1 | Готовность к обмену информацией (активность подключения) |
| 11.3 | isSecure | Булево | 1 | Готовность к обмену информацией ограниченного распространения |
| 12 | abonent | Сложный | — | Адресная информация организатора/ оператора/участника Базовый тип: «communicationPartner» (пункт 10 настоящей таблицы) |
| 12.1 | @uid | Заданный | 1 | Уникальный идентификатор организатора/оператора/участника Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 12.2 | @iedmsld | Строка | 0..1 | Технологический идентификатор МЭДО |
| 13 | organizator | Сложный | — | Базовый тип: «abonent» (пункт 12 настоящей таблицы) |
| 14 | operator | Сложный | — | Базовый тип: «abonent» (пункт 12 настоящей таблицы) |
| 15 | participant | Сложный | — | Базовый тип: «abonent» (пункт 12 настоящей таблицы) |
| 15.1 | communicationService | Заданный | 1 | Параметры взаимодействия с организатором/оператором/участником Заданный тип: «communicationService» (пункт 11 настоящей таблицы) |
| 16 | organization | Сложный | — | Базовая информация по организации |
| 16.1 | @orgRegNum | Заданный | 1 | ОГРН организации (уникальный) Заданный тип: «orgRegNum» (пункт 8 настоящей таблицы) |
| 16.2 | title | Строка | 1 | Полное фирменное наименование юридического лица |
| 16.3 | address | Строка | 0..1 | Адрес юридического лица в пределах места нахождения юридического лица |
| 16.4 | phone | Строка | 0..1 | Номер телефона организации |
| 16.5 | Строка | 0..1 | Адрес электронной почты (при наличии) организации | |
| 16.6 | website | Строка | 0..1 | Адрес Web страницы организации |
| 17 | department | Сложный | — | Подразделение организации Базовый тип: Строка |
| 17.1 | @id | Заданный | 1 | Идентификатор подразделения Заданный тип: «identity Value» (пункт 4 настоящей таблицы) |
| 17.2 | @parentld | Заданный | 0..1 | Идентификатор вышестоящего подразделения (необязательный) Заданный тип: «identityValue» (пункт 4 настоящей таблицы) |
| 18 | person | Сложный | — | Сведения об ответственном лице |
| 18.1 | @id | Заданный | 1 | Идентификатор ответственного лица Заданный тип: «identity Value» (пункт 4 настоящей таблицы) |
| 18.2 | @departmentld | Заданный | 0..1 | Идентификатор подразделения. Заданный тип: «identityValue» (пункт 4 настоящей таблицы) |
| 18.3 | post | Строка | 1 | Почтовый адрес ответственного лица |
| 18.4 | name | Строка | 1 | ФИО ответственного лица |
| 18.5 | phone | Строка | 0..1 | Номер телефона ответственного лица |
| 18.6 | Строка | 0..1 | Адрес электронной почты ответственного | |
| 19 | organizationData | Сложный | ~— | Сведения об организации участника |
| 19.1 | @participantUid | Заданный | 1 | Уникальный идентификатор участника Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 19.2 | organization | Заданный | 1 | Базовая информация по организации (реквизиты, адреса, телефоны) Заданный тип: «organization» (пункт 16 настоящей таблицы) |
| 19.3 | attestations | Сложный | 0..1 | Информация о готовности участника к обмену информацией ограниченного распространения (об аттестации системы электронного документооборота) |
| 19.3.1 | classification | Заданный | 1..n | Допущенные к обмену грифы из перечня значений справочника «Грифы ограничения доступа к документам» Заданный тип: «qualifiedValue» (пункт 9 настоящей таблицы) |
| 19.4 | departments | Сложный | 0..1 | Сведения о подразделениях организации |
| 19.4.1 | department | Заданный | 1..n | Сведения о подразделении организации Заданный тип: «department» (пункт 17 настоящей таблицы) |
| 19.5 | persons | Сложный | 0..1 | Сведения об ответственных лицах организации |
| 19.5.1 | person | Сложный | 1..n | Сведения о ответственном лице Заданный тип: «person» (пункт 18 настоящей таблицы) |
| 20 | referenceActual | Сложный | — | Актуальный глобальный адресный справочник |
| 20.1 | extractionDate | Заданный | 1 | Дата и время извлечения сведений ГАС Заданный тип: «dateTimeZone» (пункт 7 настоящей таблицы) |
| 20.2 | dataVersion | Число | 1 | Порядковый номер версии сведений ГАС, присвоенный организатором |
| 20.3 | organizators | Сложный | 1 | Информация по организаторам |
| 20.3.1 | organizator | Заданный | 1..n | Информация по организатору Заданный тип: «organizator» (пункт 13 настоящей таблицы) |
| 20.4 | operators | Сложный | 1 | Информация по операторам |
| 20.4.1 | operator | Заданный | 1..n | Информация по оператору Заданный тип: «ореrаtоr» (пункт 14 настоящей таблицы) |
| 20.5 | participants | Сложный | 1 | Информация по участникам |
| 20.5.1 | participant | Сложный | 1..n | Информация по участнику Заданный тип: «participant» (пункт 15 настоящей таблицы) |
| 20.6 | organizationsData | Сложный | 1 | Сведения об организациях участников |
| 20.6.1 | organizationData | Заданный | 1..n | Сведения об организации участника Заданный тип: «organizationData» (пункт 19 настоящей таблицы) |
| 21 | referenceHistory | Сложный | — | Структура для публикации исторических сведений ГАС |
| 21.1 | extractionDate | Заданный | 1 | Дата и время извлечения сведений из ГАС Заданный тип: «dateTimeZone» (пункт 7 настоящей таблицы) |
| 21.2 | organizatorsHistory | Сложный | 1 | Информация по организаторам с версиями |
| 21.2.1 | organizatorHistory | Сложный | 0..n | Информация по организатору с версиями |
| 21.2.1.1 | @uid | Заданный | 1 | Уникальный идентификатор организатора Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 21.2.1.2 | Сложный | 1..n | История изменения версий | |
| 21.2.1.2.1 | startDate | Заданный | 1 | Дата и время начала действия версии Заданный тип: «dateTimeZone» (пункт 7 настоящей таблицы) |
| 21.2.1.2.2 | organizator | Заданный | 1 | Историческая запись на дату версии Заданный тип: «organizator» (пункт 13 настоящей таблицы) |
| 21.3 | operatorsHistory | Сложный | 1 | Информация по операторам с версиями |
| 21.3.1 | operatorHistory | Сложный | 0..n | Информация по оператору с версиями |
| 21.3.1.1 | @uid | Заданный | 1 | Уникальный идентификатор оператора Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 21.3.1.2 | Сложный | 1..n | История изменения версий | |
| 21.3.1.2.1 | startDate | Заданный | 1 | Дата и время начала действия версии Заданный тип: «dateTimeZone» (пункт 7 настоящей таблицы) |
| 21.3.1.2.2 | operator | Заданный | 1 | Историческая запись на дату версии Заданный тип: «operator» (пункт 14 настоящей таблицы) |
| 21.4 | participantsHistory | Сложный | 1 | Информация по участникам с версиями |
| 21.4.1 | participantHistory | Сложный | 0..n | Информация по участнику с версиями |
| 21.4.2 | @uid | Заданный | 1 | Уникальный идентификатор участника Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 21.4.2.1 | Сложный | 1..n | История изменения версий | |
| 21.4.2.1.1 | startDate | Заданный | 1 | Дата начала действия версии Заданный тип: «dateTimeZone» (пункт 7 настоящей таблицы) |
| 21.4.2.1.2 | participant | Заданный | 1 | Историческая запись на дату версии Заданный тип: «participant» (пункт 15 настоящей таблицы) |
| 22 | referenceRequest | Сложный | — | Структура запроса «Запрос глобального адресного справочника» |
| 22.1 | @requestUid | Заданный | 1 | Уникальный идентификатор запроса Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 22.2 | abonentUid | Заданный | 1 | Идентификатор источника запроса Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 22.3 | extractionKind | Строка | 1 | Вид запрашиваемых сведений: «Актуальные сведения» или «Исторические сведения» |
| 23 | referenceResponse | Сложный | — | Структура ответа «Отправка глобального адресного справочника» |
| 23.1 | @responseUid | Заданный | 1 | Уникальный идентификатор ответа Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 23.2 | requestUid | Заданный | 1 | Идентификатор запроса, на который подготовлен ответ Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 23.3 | Сведения ГАС в ответ на запрос — одно из следующих значений: | |||
| referenceActual | Заданный | 0..1 | Заданный тип: «referenceActual» (пункт 20 настоящей таблицы) | |
| referenceHistory | Заданный | 0..1 | Заданный тип: «referenceHistory» (пункт 21 настоящей таблицы) | |
| 24 | docAddParticipants Request | Сложный | — | Структура документа «Заявка оператора на добавление новых участников» |
| 24.1 | @docUid | Заданный | 1 | Уникальный идентификатор документа Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 24.2 | docNumber | Заданный | 1 | Локальный номер документа Заданный тип: «identityValue» (пункт 4 настоящей таблицы) |
| 24.3 | docCreated | Заданный | 1 | Дата и время создания документа Заданный тип: «dateTimeZone» (пункт 7 настоящей таблицы) |
| 24.4 | operatorUid | Заданный | 1 | Идентификатор обслуживающего оператора Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 24.5 | addParticipantsRequest | Сложный | 1 | Тело заявки на добавление участников. |
| 24.5.1 | addRecordRequest | Сложный | 1..n | Информация по добавляемому участнику |
| 24.5.1.1 | @requestld | Число | 1 | Локальный идентификатор запроса в заявке (номер строки) |
| 24.5.1.2 | orgRegNum | Заданный | 1 | ОГРН организации участника, уникальный в рамках ГАС Заданный тип: «orgRegNum» (пункт 8 настоящей таблицы) |
| 24.5.1.3 | orgAddress | Строка | 1 | Адрес юридического лица в пределах места нахождения юридического лица |
| 24.5.1.4 | communicationPartner | Заданный | 1 | Регистрационная информация организатора/оператора/участника Заданный тип: «communicationPartner» (пункт 10 настоящей таблицы) |
| 24.5.1.5 | communicationService | Заданный | 1 | Параметры взаимодействия с организатором/оператором/участником Заданный тип: «communicationService» (пункт 11 настоящей таблицы) |
| 24.5.1.6 | justification | Строка | 1 | Официальное основание для добавления |
| 25 | docAddParticipantsResponse | Сложный | — | Структура документа «Ответ организатора по добавлению новых участников» |
| 25.1 | @docUid | Заданный | 1 | Уникальный идентификатор документа Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 25.2 | docRequestUid | Заданный | 1 | Уникальный идентификатор документа (заявки), на который подготовлен ответ Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 25.3 | addParticipantsResponse | Сложный | 0..1 | Тело ответа по добавлению участников |
| 25.3.1 | Сложный | 1 | Один из вариантов: подпункт 25.3.2 или подпункт 25.3.3 пункта 25 настоящей таблицы | |
| 25.3.2 | requestInvalid | Сложный | 1 | Структура ответа «Запрос некорректный» |
| 25.3.2.1 | rejectionReason | Строка | 1 | Комментарий организатора с причиной отклонения запроса |
| 25.3.3 | addRecordsResponcе | Сложный | 1 | Ответы на заявки по отдельным участникам |
| 25.3.3.1 | Сложный | 1..n | Один из вариантов: подпункт 25.3.3.2 или подпункт 25.3.3.3 пункта 25 настоящей таблицы | |
| 25.3.3.2 | requestAccepted | Сложный | 1 | Структура ответа «Запрос принят» |
| 25.3.3.2.1 | @requestld | Число | 1 | Локальный идентификатор запроса в заявке |
| 25.3.3.2.2 | participant | Заданный | 1 | Сведения по новому участнику Заданный тип: «participant» (пункт 15 настоящей таблицы) |
| 25.3.3.3 | requestRejected | Сложный | 1 | Структура ответа «Запрос отклонен» |
| 25.3.3.3.1 | @requestld | Число | 1 | Локальный идентификатор запроса в заявке |
| 25.3.3.3.2 | rejectionReason | Строка | 1 | Комментарий организатора с причиной отклонения запроса |
| 26 | docUpdateParticipantsRequest | Сложный | — | Структура документа «Заявка оператора на изменение сведений об участниках» |
| 26.1 | @docUid | Заданный | 1 | Уникальный идентификатор документа Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 26.2 | docNumber | Заданный | 1 | Локальный номер документа Заданный тип: «identityValue» (пункт 4 настоящей таблицы) |
| 26.3 | docCreated | Заданный | 1 | Дата и время создания заявки Заданный тип: «dateTimeZone» (пункт 7 настоящей таблицы) |
| 26.4 | operatorUid | Заданный | 1 | Идентификатор обслуживающего оператора Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 26.5 | updateParticipantsRe quest | Заданный | 1 | Тело заявки на изменение сведений Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 26.5.1 | updRecordRequest | Сложный | 1 | Информация по изменяемым участникам |
| 26.5.1.1 | @requestld | Число | 1 | Локальный идентификатор запроса в заявке (номер строки) |
| 26.5.1.2 | participant | Заданный | 1 | Измененные сведения по участнику Заданный тип: «participant» (пункт 15 настоящей таблицы) |
| 26.5.1.3 | justification | Строка | 1 | Официальное основание для изменений данных по участнику |
| 27 | docUpdateParticipantsResponse | Сложный | — | Структура документа «Ответ организатора по изменению сведений об участниках» |
| 27.1 | @docUid | Заданный | 1 | Уникальный идентификатор документа Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 27.2 | docRequestUid | Заданный | 1 | Уникальный идентификатор документа (заявки), на который подготовлен ответ Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 27.3 | updateParticipantsResponse | Сложный | 1 | Тело ответа по изменению сведений |
| 27.3.1 | Сложный | 1 | Один из вариантов: подпункт 27.3.2 или подпункт 27.3.3 пункта 27 настоящей таблицы | |
| 27.3.2 | requestInvalid | Сложный | 1 | Структура ответа «Запрос некорректный» |
| 27.3.2.1 | rejectionReason | Строка | 1 | Комментарий организатора с причиной отклонения запроса |
| 27.3.3 | updRecordsResponse | Сложный | 1 | Ответы на заявки по отдельным участникам |
| 27.3.3.1 | Сложный | 1..n | Один из вариантов: подпункт 27.3.3.2 или подпункт 27.3.3.3 пункта 27 настоящей таблицы | |
| 27.3.3.2 | requestAccepted | Сложный | 1 | Структура ответа «Запрос принят» |
| 27.3.3.2.1 | @requestld | Число | 1 | Локальный идентификатор запроса в заявке |
| 27.3.3.2.2 | participant | Заданный | 1 | Обновлённые сведения об участнике Заданный тип: «participant» (пункт 15 настоящей таблицы) |
| 27.3.3.3 | requestRejected | Сложный | 1 | Структура ответа «Запрос отклонен» |
| 27.3.3.3.1 | @requestId | Число | 1 | Локальный идентификатор запроса в заявке |
| 27.3.3.3.2 | rejectionReason | Строка | 1 | Комментарий организатора с причиной отклонения запроса |
| 28 | docUpdateOrganizationDataRequest | Сложный | — | Структура документа «Заявка участника на изменение сведений об организации» |
| 28.1 | @docUid | Заданный | 1 | Уникальный идентификатор документа Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 28.2 | docNumber | Заданный | 1 | Локальный номер документа Заданный тип: «identityValue» (пункт 4 настоящей таблицы) |
| 28.3 | docCreated | Заданный | 1 | Дата и время создания заявки Заданный тип: «dateTimeZone» (пункт 7 настоящей таблицы) |
| 28.4 | participantUid | Заданный | 1 | Идентификатор участника в ГАС Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 28.5 | updateOrganization DataRequest | Сложный | 1 | Тело запроса на изменение сведений по организации участника |
| 28.5.1 | organizationData | Заданный | 1 | Измененные сведения по организации Заданный тип: «organizationData» (пункт 19 настоящей таблицы) |
| 28.5.2 | justification | Строка | 1 | Официальное основание для изменений данных по организации участника |
| 29 | docUpdateOrganizationDataResponse | Сложный | — | Структура документа «Ответ организатора по изменению сведений об организации» |
| 29.1 | @docUid | Заданный | 1 | Уникальный идентификатор документа (ответа) Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 29.2 | docRequestUid | Заданный | 1 | Уникальный идентификатор документа (заявки), на который подготовлен ответ Заданный тип: «globalUniqueIdentifier» (пункт 6 настоящей таблицы) |
| 29.3 | updateOrganizationDataResponse | Сложный | 1 | Тело ответа по изменению сведений |
| 29.3.1 | Сложный | 1 | Один из вариантов: подпункт 29.3.2 или подпункт 29.3.3 пункта 29 настоящей таблицы | |
| 29.3.2 | requestAccepted | Сложный | 1 | Структура ответа «Запрос принят» |
| 29.3.2.1 | organizationData | Заданный | 1 | Обновленные сведения об организации Заданный тип: «organizationData» (пункт 19 настоящей таблицы) |
| 29.3.3 | requestRejected | Сложный | 1 | Структура ответа «Запрос отклонен» |
| 29.3.3.1 | rejectionReason | Строка | 1 | Комментарий организатора с причиной отклонения запроса |
10. XML-схема паспорта транспортного контейнера
Обзор документа
Установлены технические требования к порядку ведения нормативно-справочной информации системы межведомственного электронного документооборота (МЭДО) в части сведений, содержащихся в глобальном адресном справочнике (ГАС), необходимых для формирования транспортных контейнеров и электронных сообщений.
Определены технические требования к структуре данных и формату ГАС; технологический регламент создания, формирования и рассылки ГАС; формат технологического сообщения.
Глобальный адресный справочник должен содержать сведения об организаторе МЭДО; об операторах и участниках информационного взаимодействия; об организациях участников. Организатор МЭДО ведет справочники в соответствии с правилами обмена документами в электронном виде при организации информационного взаимодействия.
Для просмотра актуального текста документа и получения полной информации о вступлении в силу, изменениях и порядке применения документа, воспользуйтесь поиском в Интернет-версии системы ГАРАНТ: