packagedescription xml что это
РАСПОРЯЖЕНИЕ Правления ПФ РФ от 11.10.2007 N 190р (ред. от 10.06.2009) «О ВНЕДРЕНИИ ЗАЩИЩЕННОГО ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА В СИСТЕМЕ ИНДИВИДУАЛЬНОГО (ПЕРСОНИФИЦИРОВАННОГО) УЧЕТА ДЛЯ ЦЕЛЕЙ ОБЯЗАТЕЛЬНОГО ПЕНСИОННОГО СТРАХОВАНИЯ» (вместе с «РЕГЛАМЕНТОМ ОБМЕНА ДОКУМЕНТАМИ ИНДИВИДУАЛЬНОГО (ПЕРСОНИФИЦИРОВАННОГО) УЧЕТА СТРАХОВЫХ ВЗНОСОВ ПО ТЕЛЕКОММУНИКАЦИОННЫМ КАНАЛАМ СВЯЗИ В СИСТЕМЕ ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА ПЕНСИОННОГО ФОНДА РОССИЙСКОЙ ФЕДЕРАЦИИ С ВНЕШНИМИ ОРГАНИЗАЦИЯМИ», «РЕГЛАМЕНТОМ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ ИНФОРМАЦИИ ПРИ ЗАЩИЩЕННОМ ОБМЕНЕ ЭЛЕКТРОННЫМИ ДОКУМЕНТАМИ В СИСТЕМЕ ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА ПЕНСИОННОГО ФОНДА РОССИЙСКОЙ ФЕДЕРАЦИИ ПО ТЕЛЕКОММУНИКАЦИОННЫМ КАНАЛАМ СВЯЗИ»)
4. Формат транспортного сообщения (пакета)
В рамках каждой транзакции всех типов документооборота все файлы необходимых документов и их подписей пересылаются объединенными в один файл. Такой файл называется пакетом.
На рисунке ниже приведена схема внутреннего устройства пакета.
Подробнее см. пункт «Объединение и сжатие файлов».
— файл «packageDescription.xml» с описанием содержимого пакета в формате xml;
— файл «packageDescription.sign» с содержимым подписи под описанием содержимого пакета;
— архивные файлы с содержимым передаваемых документов;
— файлы с содержимым передаваемых подписей под каждым документом.
Подробнее см. пункт «Универсальные уникальные идентификаторы».
4.1. Описание содержимого пакета
Файл с описанием содержимого пакета представляет собой xml-документ, соответствующий схеме из Приложения 1. Пример описания содержимого пакета дан в Приложении 2.
Корневой узел пакет документа содержит следующие обязательные атрибуты:
Узел пакет также содержит необязательный атрибут датаВремяПоступления, в котором указывается дата и время поступления документов от отправителя документов на транспортный сервер. Данная техническая информация может впоследствии использоваться для выявления участков, на которых произошла задержка при передаче транспортного пакета.
Внутри узла пакет содержатся немножественные узлы отправитель, получатель и системаОтправителя (или системаПолучателя) со следующими обязательными атрибутами:
В элементе отправитель описывается отправитель пакета. В элементе получатель описывается получатель пакета. В элементе системаОтправителя описывается система электронного документооборота, от которой получателю поступает пакет. В элементе системаПолучателя описывается система электронного документооборота, которой отправитель передает пакет для доставки получателю.
Также внутри узла пакет содержится немножественный узел СКЗИ с обязательным атрибутом типСКЗИ, в котором в виде строки указывается тип СКЗИ, используемый для формирования пакета. В настоящий момент поддерживаются следующие строковые обозначения типов СКЗИ: «Крипто-Про», «Домен-КС2», «Верба-OW». Строковые обозначения для новых типов СКЗИ выбираются по согласованию с заинтересованными разработчиками систем электронного документооборота.
Дополнительно внутри узла пакет в одном или нескольких дочерних узлах документ перечисляются документы, передаваемые в этом пакете.
Узел документ имеет следующие обязательные атрибуты:
Подробнее см. пункт «Объединение и сжатие файлов».
Подробнее см. пункт «Криптография».
Содержимое всех документов в документообороте зашифровывается в адрес представителя органа ПФР и лиц, участвующих в документообороте со стороны Абонента СЭД, если в описании соответствующего документооборота явно не оговорен другой вариант.
Содержимое всех подписей под документами в документообороте не шифруется.
Кроме того, узел документ содержит необязательный дочерний немножественный узел содержимое с атрибутом имяФайла, значением которого является имя файла (из набора файлов пакета) с содержимым описываемого документа. Узел содержимое может отсутствовать, если в транзакции передается лишь подпись под документом без содержимого документа.
Также внутри узла документ в дочерних узлах подпись перечисляются подписи, стоящие под документом.
Узел подпись имеет следующие обязательные атрибуты:
Файл с описанием содержимого пакета не шифруется.
Файл с описанием содержимого пакета подписывается сертификатом ЭЦП отправителя пакета. При добавлении на транспортном сервере даты с времени поступления пакета описание пакета переподписывается сертификатом ЭЦП транспортного сервера.
4.2. Имя файла пакета
Пакет передается в виде файла с уникальным именем по формату
Идентификационные номера отправителя и получателя в имени файла должны совпадать с соответствующей информацией в транспортном описании пакета.
Идентификационные номера в имени файла пакета указываются исключительно для удобства служб технической поддержки.
Пример имени файла пакета:
4.3. Универсальные уникальные идентификаторы
Для идентификации типов документооборота, документов и для генерации имен файлов в пакете используются универсальные уникальные идентификаторы.
Используемые универсальные уникальные идентификаторы должны генерироваться согласно общим принципам формирования UUID, изложенным в открытом документе RFC 4122 (http://www.letf.org/rfc/rfc4122.txt). Все современные операционные системы имеют встроенные средства или отдельные библиотеки для генерации универсальных уникальных идентификаторов согласно указанному стандарту.
Везде в настоящем протоколе используется представление универсальных уникальных идентификаторов в виде шестнадцатеричного числа из 32 разрядов, записанного в нижнем регистре.
Пример представления универсального уникального идентификатора:
4.4. Объединение и сжатие файлов
Для объединения нескольких файлов в один пакет и для сжатия файлов используется формат zip-архива.
Формат zip-архива описывается в открытой спецификации, доступной по адресу /content/base/.
Требования к используемым СКЗИ и сертификатам ЭЦП приведены в документе «Регламент обеспечения безопасности информации при защищенной обмене электронными документами в системе электронного документооборота Пенсионного фонда Российской Федерации по телекоммуникационным каналам связи».
Зашифрованные данные передаются в виде структуры ContentInfo со структурой EnvelopedData в качестве содержимого, для сохранения в файл используется DER-кодировка.
ЭЦП передаются в виде структуры ContentInfo со структурой SignedData в качестве содержимого. Для сохранения в файл используется DER-кодировка.
В xml-описании пакета и xml-документах, участвующих в документообороте, дата и время указывается в формате xs:dateTime с указанием часового пояса. Если часовой пояс не указан, то дата и время считаются относительно часового пояса органа ПФР, с которым осуществляется взаимодействие.
NuGet упаковать и восстановить как MSBuild целевые объекты
Порядок сборки целевого объекта
Поскольку pack и restore являются MSBuild целевыми объектами, к ним можно обращаться для улучшения рабочего процесса. Например, предположим, что вы хотите скопировать пакет в сетевую папку после упаковки. Это можно сделать, добавив следующий код в файл проекта:
Аналогичным образом можно написать MSBuild задачу, написать собственный целевой объект и использовать NuGet свойства в MSBuild задаче.
$(OutputPath) является относительным и предполагает, что команда выполняется из корневого каталога проекта.
Целевой объект pack
В следующей таблице описаны MSBuild свойства, которые можно добавить в файл проекта в пределах первого
Входные данные целевого объекта pack
Сценарии использования pack
Подавление зависимостей
Чтобы исключить зависимости пакета из созданного NuGet пакета, задайте для значение, SuppressDependenciesWhenPacking true которое позволит пропустить все зависимости из созданного файла nupkg.
PackageIconUrl
PackageIcon
Упаковка файла изображения значка
При упаковке файла изображения значка используйте PackageIcon свойство, чтобы указать путь к файлу значка относительно корня пакета. Кроме того, убедитесь, что файл включен в пакет. Размер файла изображения ограничен 1 МБ. Поддерживаются следующие форматы файлов: JPEG и PNG. Рекомендуется разрешение изображения 128×128.
паккажереадмефиле
Поддерживается с 5.10.0 Preview 2 .NET SDK 5.0.300 и выше
При упаковке файла сведений необходимо использовать PackageReadmeFile свойство, чтобы указать путь к пакету относительно корня пакета. Помимо этого, необходимо убедиться, что файл включен в пакет. Поддерживаемые форматы файлов включают только Markdown (. md).
Выходные сборки
Существует два MSBuild свойства, которые можно использовать в файле проекта или командной строке для управления размещением выходных сборок:
Ссылки на пакеты
Перекрестные ссылки между проектами
Project ссылок на проекты по умолчанию считаются NuGet ссылками на пакеты. Пример:
Вы также можете добавить в ссылку на проект следующие метаданные:
Включение содержимого в пакет
По умолчанию все данные добавляются в корень папки content и contentFiles\any\ в пакете и сохраняют относительную структуру папок, если только не указан путь к пакету:
Другие метаданные, относящиеся к пакету, которые можно задать для любого из перечисленных выше элементов, включают
Кроме элементов содержимого, метаданные
также можно задать для файлов с действием сборки Compile, EmbeddedResource, ApplicationDefinition, Page, Resource, SplashScreen, DesignData, DesignDataWithDesignTimeCreateableTypes, CodeAnalysisDictionary, AndroidAsset, AndroidResource, BundleResource или None.
Чтобы объект pack добавил имя файла в путь к пакету при использовании стандартных масок, путь к пакету должен заканчиваться символом разделителя папок, в противном случае этот путь считается полным путем, включающим имя файла.
IncludeSymbols
IncludeSource
Если файл типа Compile находится вне папки проекта, он просто добавляется в src\
Упаковка выражения лицензии или файла лицензии
При упаковке файла лицензии используйте свойство, PackageLicenseFile чтобы указать путь к пакету относительно корня пакета. Кроме того, убедитесь, что файл включен в пакет. Пример:
Упаковка файла без расширения
В некоторых сценариях, например при упаковке файла лицензии, может потребоваться включить файл без расширения. По историческим причинам следует NuGet&MSBuild рассматривать пути без расширения в качестве каталогов.
IsTool
Если вы используете dotnet.exe для упаковки проекта, воспользуйтесь командой, аналогичной следующей:
Если вы используете MSBuild для упаковки проекта, воспользуйтесь командой, аналогичной следующей:
Пример файла . csproj для упаковки файла:
Улучшенные точки расширения для создания настраиваемого пакета
pack Целевой объект предоставляет две точки расширения, которые выполняются во внутренней и целевой сборке конкретной платформы. Поддержка точек расширения включает в пакет содержимое и сборки, относящиеся к целевой платформе.
TargetsForTfmSpecificBuildOutput
TargetsForTfmSpecificContentInPackage
Целевой объект restore
restore Целевой объект работает для проектов, использующих формат PackageReference. MSBuild 16.5+ также имеет MSBuild 16.5+ для packages.config формата.
Свойства восстановления
Примеры
Выходные данные восстановления
Операция восстановления создает в папке сборки obj следующие файлы:
| Файл | Описание |
|---|---|
| project.assets.json | Содержит диаграмму зависимостей всех ссылок на пакеты. |
| Ссылки на свойства MSBuild Props, содержащиеся в пакетах | |
| Ссылки на MSBuild целевые объекты, содержащиеся в пакетах |
Восстановление и сборка с помощью одной MSBuild команды
Из-за того факта, что NuGet можно восстановить пакеты, которые предоставляют MSBuild целевые объекты и свойства, оценки восстановления и сборки выполняются с разными глобальными свойствами. Это означает, что следующие действия будут иметь непредсказуемое и неправильное поведение.
Вместо этого рекомендуемый подход:
Восстановление проектов PackageReference и packages.config с помощью MSBuild
Восстановление с помощью MSBuild статической оценки графа
В MSBuild 16.6 + NuGet Добавлена экспериментальная функция для использования статической оценки графа из командной строки, значительно повышающей время восстановления больших репозиториев.
Кроме того, его можно включить, задав свойство в каталоге. Build. props.
начиная с Visual Studio 2019. x и NuGet 5. x, эта функция считается экспериментальной и явной. NuGet для получения дополнительных сведений о том, когда эта функция будет включена по умолчанию, выполните NuGet/Home/issues/9803 «data-/Home =» external «># 9803.
При восстановлении статического графа изменяется часть MSBuild, вычисление и чтение проекта, но не алгоритм восстановления. Алгоритм восстановления одинаков во всех NuGet инструментах ( NuGet.exe, MSBuild.exe, dotnet.exe и Visual Studio).
В очень редких случаях восстановление статических графов может отличаться от текущего при восстановлении, а некоторые объявленные PackageReferences или ссылками могут отсутствовать.
Для упрощения проверки при переходе к статическому восстановлению графа можно выполнить следующие действия.
Замена одной библиотеки из графа восстановления
Если операция восстановления предоставляет неправильную сборку, вы можете исключить значение по умолчанию для этого пакета, заменив его своим значением. Первый с PackageReference верхнего уровня, исключите все ресурсы:
После этого добавьте собственную ссылку на соответствующую локальную копию библиотеки DLL:
Packagedescription xml что это
(1).jpg "packagedescription xml что это. Смотреть фото packagedescription xml что это. Смотреть картинку packagedescription xml что это. Картинка про packagedescription xml что это. Фото packagedescription xml что это")
Об актуальных изменениях в КС узнаете, став участником программы, разработанной совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу выдаются удостоверения установленного образца.
Программа разработана совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.
Обзор документа
Приказ Федеральной службы государственной статистики от 4 мая 2018 г. № 281 «О внесении изменений в приложение к приказу Росстата от 7 июля 2011 г. № 313 «Об утверждении Унифицированного формата транспортного сообщения при обмене электронными документами между территориальными органами Росстата и респондентами»
Приложение к приказу Росстата от 7 июля 2011 г. № 313 «Об утверждении Унифицированного формата транспортного сообщения при обмене электронными документами между территориальными органами Росстата и респондентами» изложить в редакции, согласно приложению к настоящему приказу.
| Временно исполняющий обязанности руководителя Федеральной службы государственной статистики | С.Н. Егоренко |
Приложение
к приказу Росстата
от 04.05.2018 № 281
«УТВЕРЖДЕН
приказом Росстата
от 7 июля 2011 г. № 313
Унифицированный формат
транспортного сообщения при обмене электронными документами между территориальными органами Росстата и респондентами
I. Общие положения
Информационное взаимодействие по телекоммуникационным каналам связи по обмену электронными документами с применением электронной подписи, идущее по определенным правилам между территориальными органами Федеральной службы государственной статистики либо Федеральной службой государственной статистики с одной стороны, и Респондентами либо Специализированным оператором связи с другой стороны, называется документооборотом.
Осуществление документооборота происходит через проведение транзакций, т.е. передачи от одного участника документооборота другому фиксированного набора документов в согласованном с органами государственной статистики формате вместе с подписями под этими документами, сделанными от имени определенных участников документооборота.
1.1 Осуществление документооборота
Документооборот при обработке может содержать несколько транзакций. Типовому содержанию транзакций соответствуют:
отправитель передает по телекоммуникационным каналам связи пакет документов Получателю;
получатель по результатам проверки документов, их электронных подписей и сертификатов направляет Отправителю электронный документ фиксированного формата, содержащий положительный или отрицательный ответ на пакет документов Отправителя.
1.2 Типы участников документооборота
В ходе документооборота осуществляется взаимодействие между следующими типами участников документооборота:
Респондент. В качестве респондента может выступать либо юридическое лицо, либо обособленное подразделение (при условии наделения его соответствующим юридическим лицом полномочиями по предоставлению статистической отчётности от имени юридического лица) либо индивидуальный предприниматель, осуществляющий деятельность без образования юридического лица, предоставляющие первичные статистические данные по формам федерального статистического наблюдения.
ТОГС. В качестве ТОГС может выступать либо территориальный орган Федеральной службы государственной статистики (включая межрайонные Управления), так и его структурные подразделения в районах и городах, осуществляющие в установленном Росстатом порядке сбор первичных статистических данных по формам федерального статистического наблюдения от респондентов, осуществляющих деятельность на территории субъекта Российской Федерации.
Оператор. (Организация, предоставляющая услуги по обмену открытой и конфиденциальной информацией между органами государственной статистики и респондентами, в том числе гарантирующая доставку электронных документов в границах своей зоны ответственности, установленной соглашениями с территориальными органами государственной статистики и договорами с респондентами.)
Росстат. (Федеральная служба государственной статистики.)
1.3 Типы подписантов
Подписи под документами от имени участников документооборота ставят должностные лица или уполномоченные от их имени лица, обладающие правом подписи соответствующих документов:
При работе через Оператора в пакете вместо представителей указываются типы субъектов в соответствии с описанием конкретного типа документооборота.
1.4 Типы содержимого
В ходе документооборота происходит обмен различными типами документов.
Список типов документов, допустимых к использованию при работе через Оператора, представлен в Приложении 3.
II. Структура унифицированного формата транспортного сообщения, передаваемого по телекоммуникационным каналам связи
В рамках сдачи первичных статистических данных в электронном виде между ТОГС и Респондентами может осуществляться два типа электронного документооборота:
электронный документооборот в рамках сдачи первичных статистических данных через систему сбора статистической отчетности (ССО);
электронный документооборот в рамках первичных статистических данных через Оператора.
Ниже представлено описание структуры и транспортного контейнера, формируемого в рамках, перечисленных выше типов электронного документооборота между Респондентами и ТОГС.
2. Описание структуры транспортного сообщения при работе через ССО
2.1 Структура формата транспортного сообщения
Транспортное сообщение состоит из набора служебных полей транспортного сообщения и прикрепленного к нему транспортного контейнера.
Структура формата транспортного сообщения представлена на рисунке ниже (см. Рисунок 1).
Для обеспечения обработки транспортного сообщения приемным комплексом ТОГС в структуре транспортного сообщения предусмотрены следующие обязательные поля (реквизиты транспортного сообщения):
Присоединенному файлу вложения должны соответствовать поля:
Транспортный контейнер прикрепляется (ключевое слово «attachment») к транспортному сообщению, передаваемому по телекоммуникационным каналам связи, как файл-вложение, имя которого указано в поле «Content-Disposition:» (параметр «filename»). Размер файла транспортного контейнера не может быть нулевым и сам транспортный контейнер не может содержать файлы нулевой длины. К транспортному сообщению может быть присоединен только один файл транспортного контейнера.
Размер транспортного сообщения, передаваемого по телекоммуникационным каналам связи, не должен превышать 512 МБайт. В случае принятия к обработке приемным комплексом транспортного сообщения организации, контейнер с одним и тем же именем не может быть передан одним и тем же отправителем вторично.
2.2 Содержание и структура транспортного контейнера (пакета)
В рамках каждой транзакции документооборота файлы всех логически связанных документов и относящихся к ним электронных подписей, сопровождаемые сопутствующей транспортной информацией, пересылаются объединенными в один файл. Такой файл называется транспортным контейнером (или пакетом).
На рисунке ниже приведена схема внутренней структуры пакета.
Транспортный контейнер представляет собой zip-архив, содержащий:
необязательный файл «packageDescription.xml» с описанием содержимого пакета в формате xml. В документообороте «сбор отчетности ЕССО» может не использоваться;
необязательный файл «packageDescription.sign» с электронной подписью под описанием содержимого пакета (должен присутствовать, если есть файл «packageDescription.xml»);
необязательный файл «packageDescription.cer» с сертификатом для проверки электронной подписи под описанием содержимого пакета (должен присутствовать, если есть файл «packageDescription.sign» и он не содержит внутри себя сертификат);
файлы с содержимым передаваемых документов (могут быть зашифрованы и заархивированы);
файлы с содержимым передаваемых электронных подписей под каждым документом;
файлы с содержимым сертификата для проверки электронной подписи под каждым документом (если электронная подпись документа не содержит внутри себя сертификат).
2.3 Формат описания содержимого транспортного контейнера (пакета)
Файл с описанием содержимого пакета представляет собой xml-документ, соответствующий схеме из Приложения 1. Пример описания содержимого пакета дан в Приложении 2.
Корневой узел документа «пакет» содержит следующие обязательные атрибуты:
Внутри узла пакет содержатся немножественные узлы «отправитель», получатель и системаОтправителя (или системаПолучателя) со следующими обязательными атрибутами:
В элементе «отправитель» описывается отправитель пакета. В элементе получатель описывается получатель пакета. В элементе системаОтправителя описывается система электронного документооборота, от которой получателю поступает пакет. В необязательном элементе системаПолучателя описывается система электронного документооборота, которой отправитель передает пакет для доставки получателю.
Дополнительно внутри узла «пакет» в одном или нескольких дочерних узлах документ перечисляются документы, передаваемые в этом пакете.
Узел документ имеет следующие обязательные атрибуты:
Узел документ имеет необязательный атрибут исходноеИмяФайла, в котором указывается исходное имя файла документа.
Содержимое всех документов в документообороте зашифровывается, если явно не оговорен другой вариант.
Содержимое всех подписей под документами в документообороте не шифруется.
Кроме того, узел документ содержит необязательный дочерний немножественный узел содержимое с атрибутом имяФайла, значением которого является имя файла (из набора файлов пакета) с содержимым описываемого документа. Узел содержимое может отсутствовать, если в транзакции передается лишь подпись под документом без содержимого документа.
Также внутри узла документ в дочерних узлах «подпись» перечисляются подписи, стоящие под документом.
Узел подпись имеет следующие обязательные атрибуты:
Файл с описанием содержимого пакета не шифруется и не архивируется.
2.4 Объединение и сжатие файлов
Для объединения нескольких файлов в один пакет и для сжатия файлов используется формат zip-архива.
Формат zip-архива описывается в открытой спецификации, доступной по адресу http://www.pkwarexom/documents/casestudies/APPNOTE.TXT.
Архивирование должно проводиться без использования шифрования.
2.5 Криптография
Требования к используемым средствам криптографической защиты информации и сертификатам электронных подписей приведены в документе «Регламент использования электронной подписи».
Зашифрованные данные должны передаваться в виде структуры ContentInfo со структурой EnvelopedData в качестве содержимого, для сохранения в файл используется DER-кодировка.
Электронные подписи передаются в виде структуры ContentInfo со структурой SignedData в качестве содержимого. Для сохранения в файл используется DER-кодировка.
Электронная подпись может включать в себя сертификат и может не включать подписанное содержимое.
Нешифрованные данные (сертификаты, электронные подписи) передаются в виде своего содержимого, сериализованного с использованием base64-кодирования.
2.6 Документооборот «сбор отчетности ЕССО»
Транзакция «отчет ЕССО», передаваемая от Респондента в ТОГС, позволяет передавать в zip-архиве несколько файлов отчетов-ЭВФ в формате XML, опуская файл описания. При этом подразумевается, что отчеты передаются не зашифрованным и не сжатым, а электронная подпись интегрирована в отчет.
Транзакция «квитанция ЕССО», передаваемая от ТОГС к Респонденту, позволяет передавать в zip-архиве восемь файлов в формате XML, опуская файл описания. При этом подразумевается, что все файлы передаются не зашифрованными и не сжатыми. Состав пакета:
Транзакция «уведомление ЕССО», передаваемая от ТОГС к Респонденту, позволяет передавать в zip-архиве 5 файлов в формате XML, опуская файл описания. При этом подразумевается, что все файлы передаются не зашифрованными и не сжатыми. Состав пакета:
Под подразумевается уникальное имя файла отчета, формируемое по следующему шаблону:
3. Описание структуры транспортного сообщения при работе через Оператора
3.1 Структура транспортного сообщения 1
При обмене через Операторов используется транспортное сообщение, структура которого аналогична структуре, описанной в п. 2.1 раздела II.
Принцип формирования транспортного сообщения изложен в документе RFC 2822 (http://www.ietf.org/rfc/rfc2822.txt).
Транспортный контейнер прикрепляется к транспортному сообщению, передаваемому по телекоммуникационным каналам связи, как файл-вложение. Размер файла транспортного контейнера не может быть нулевым и сам транспортный контейнер не может содержать файлы нулевой длины. К транспортному сообщению может быть присоединен только один файл транспортного контейнера.
Размер транспортного сообщения, передаваемого по телекоммуникационным каналам связи, не должен превышать 100 МБайт.
3.2 Содержимое транспортного контейнера
Транспортный контейнер представляет собой zip-архив, содержащий файл «packageDescription.xmb с транспортной информацией в формате XML, файлы с содержимым передаваемых документов и файлы с содержимым передаваемых электронных подписей. Схема транспортного контейнера приведена на рисунке ниже (см. Рисунок 3).
Транспортная информация и файлы с содержимым документов и электронных подписей объединяются в zip-архив в режиме STORE.
В одном транспортном контейнере передаются документы и электронные подписи, относящиеся к одной транзакции.
3.3 Формат описания транспортного контейнера
Файл с транспортной информацией представляет собой XML-документ, соответствующий схеме из Приложения 4.
Корневой узел пакет документа содержит следующие обязательные атрибуты:
Внутри узла пакет содержатся немножественные узлы отправитель, получатель и системаОтправителя (или системаПолучателя) со следующими атрибутами:
В элементе отправитель описывается отправитель контейнера. В элементе получатель описывается получатель контейнера. В элементе системаОтправителя описывается система электронного документооборота, от которой получателю поступает контейнер. В элементе системаПолучателя описывается система электронного документооборота, которой отправитель передает контейнер для доставки получателю. В элементе идентификаторПодразделения описывается подразделение ТОГС, в которое направлен контейнер / из которого направлен контейнер.
Дополнительно внутри узла пакет в одном или нескольких дочерних узлах документ перечисляются документы, передаваемые в этом транспортном контейнере. Узел документ имеет следующие обязательные атрибуты:
Также узел документ имеет атрибут исходноеИмяФайла, в котором указывается исходное имя файла документа с расширением. Данный атрибут является обязательным для документов отчет и приложениеПисьма. Для прочих документов данный атрибут является необязательным.
Узел документ содержит необязательный дочерний немножественный узел содержимое с атрибутом имяФайла, значением которого является имя файла (из набора файлов транспортного контейнера) с содержимым описываемого документа. Узел содержимое может отсутствовать, если в транзакции передается лишь электронная подпись под документом и не передается содержимое документа.
Внутри узла документ в дочерних узлах подпись перечисляются электронные подписи, стоящие под документом. Узел подпись имеет следующие обязательные атрибуты:
Узел пакет содержит необязательный узел расширение, который может содержать любые атрибуты и дочерние узлы. Данный узел используется для указания дополнительных данных в транспортной информации контейнера с сохранением обратной совместимости. Формат использования узла расширение определяется по согласованию с заинтересованными разработчиками систем электронного документооборота.
Файл с транспортной информацией при передаче в транспортном контейнере не сжимается и не шифруется.
3.4 Имя файла транспортного контейнера
Транспортный контейнер передается в виде файла с уникальным именем по формату
Идентификаторы отправителя и получателя в имени файла должны совпадать с соответствующей информацией в транспортной информации контейнера.
UUID в имени файла контейнера представляет собой глобальный уникальный идентификатор, обеспечивающий уникальность имени файла контейнера.
Код типа документооборота представляет собой число, присвоенное типу документооборота, в рамках которого отправляются документы в данном транспортном контейнере. Код типа транзакции представляет собой число, присвоенное типу транзакции, которая осуществляется посредством передачи данного транспортного контейнера. Информация о кодах типов документооборота и транзакции может быть использована для определения приоритетных для обработки контейнеров.
Информация в имени файла носит исключительно справочный характер. Обработка транспортного контейнера должна осуществляться на основе транспортной информации, находящейся внутри контейнера.
При поступлении в ТОГС / Росстат от Респондента через Оператора транспортного контейнера в узле системаОтправителя транспортной информации контейнера указывается соответствующий Оператор. При отправке из ТОГС / Росстата Респонденту через Оператора транспортного контейнера в узле системаПолучателя транспортной информации контейнера указывается соответствующий Оператор.
Идентификаторы участников документооборота состоят из символов a-z, A-Z, 0-9, «@», «.» и «-«. Для сравнения на равенство необходимо всегда использовать регистронезависимое сравнение. В то же время для единообразия рекомендуется использовать только символы из верхнего регистра.
Для указания идентификатора структурного подразделения ТОГС (районного, городского и т.д.) следует использовать атрибут идентификаторПодразделения в узле получатель / отправитель. Идентификатор структурного подразделения ТОГС должен состоять из символов a-z, A-Z, 0-9, «@», «.» и «-«, быть уникальным в рамках ТОГС и определяться ТОГС по согласованию с Операторами.
В качестве идентификатора Оператора используется уникальная строка, выбираемая по согласованию с заинтересованными разработчиками систем электронного документооборота.
Идентификатор Респондента имеет формат
3.5 Спецификация используемых технологий
3.5.1 Универсальные уникальные идентификаторы
Для идентификации типов документооборота, документов и для генерации имен файлов в транспортном контейнере используются универсальные уникальные идентификаторы.
Используемые универсальные уникальные идентификаторы должны генерироваться согласно общим принципам формирования UUID, изложенным в документе RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt).
Везде в настоящем документе используется представление универсальных уникальных идентификаторов в виде шестнадцатеричного числа из 32 разрядов, записанного в нижнем регистре.
3.5.2 Объединение и сжатие файлов
Для объединения нескольких документов в один транспортный контейнер и для сжатия документов используется формат zip-архива.
Формат zip-архива описывается в открытой спецификации, доступной по адресу http://www.pkware.com/documents/casestudies/APPNOTE.TXT. Архивирование должно производится в соответствии с базовыми возможностями версии 2.0, без использования шифрования.
При сжатии документа этот документ помещается в архив, внутри которого имеет имя «file».
3.5.3 Криптография
Для шифрования используются алгоритмы ГОСТ 28147-89. Для формирования электронной подписи используются алгоритмы ГОСТ Р 34.10-2001 и ГОСТР 34.10.2012. 5
Зашифрованные данные и электронные подписи передаются при помощи контейнера PKCS #7 (RFC 2315, http://www.ietf.org/rfc/rfc2315.txt). Для сохранения в файл используется DER-кодировка.
Зашифрованные данные передаются в виде структуры ContentInfo со структурой EnvelopedData в качестве содержимого.
Электронные подписи передаются в виде структуры ContentInfo со структурой SignedData в качестве содержимого. Электронная подпись должна включать в себя сертификат и не должна включать подписанное содержимое.
Шифрование документов производится на открытых ключах получателя и отправителя документа.
3.5.4 Дата и время
В описании пакета и документах, участвующих в документообороте, дата и время указывается в формате xs:dateTime с указанием часового пояса либо маркера того, что дата и время указаны в UTC.
3.5.5 Удаленная проверка работоспособности
Для удаленной проверки работоспособности приемного комплекса ТОГС Оператор может отправить технологический документ запрос специального вида. Приемный комплекс ТОГС после обработки этого документа сформирует ответный технологический документ ответ, который будет отправлен Оператору.
Удаленная проверка работоспособности позволяет определить версию приемного комплекса, а также работоспособность криптографической подсистемы приемного комплекса.
Технологические документы запрос и ответ представляют собой XML-файл. Формат документов описан в приложении 7.5. Отправка данных документов производится не в составе транспортного контейнера, а в виде самостоятельных файлов.
Имя файла, содержащего документ запрос, должно иметь префикс «ping_». Пример имени файла документа запрос: ping_BEA6F7B6-9451-3F59-8233-D4D7DA55BF36.xml
Имя файла, содержащего документ ответ, должно иметь префикс «pong_». При этом имя файла документа ответ не должно отличаться от файла соответствующего ему документа запрос более чем значением префикса. Пример имени файла документа ответ: pong_BEA6F7B6-9451-3F59-8233-D4D7DA55BF36.xml
Для определения версии приемного комплекса в документ запрос помещается дочерний узел version без атрибутов. В таком случае в документ ответ приемный комплекс поместит дочерний узел version с атрибутом value и номером версии в качестве значения этого атрибута.
Для определения работоспособности криптографической составляющей приемного комплекса в документ запрос помещается узел cryptographySelfCheck без атрибутов. В таком случае в документ ответ приемный комплекс поместит узел cryptographySelfCheck со следующими дочерними узлами:
Узлы encrypt, sign, decrypt, verify имеют следующие атрибуты:
В случае, если атрибут result узла какой-либо криптографической операции принимает значение error, в качестве дочернего узла для него добавляется узел message, в который помещается сообщение о произошедшей при выполнении операции ошибке.
Приложение № 1
к Унифицированному формату
транспортного сообщения при обмене
электронными документами между
территориальными органами Росстата
и респондентами, утверждённого приказом
Росстата от 7 июля 2011 г. № 313
Приложение № 2
к Унифицированному формату
транспортного сообщения при обмене
электронными документами между
территориальными органами Росстата
и респондентами, утверждённого приказом
Росстата от 7 июля 2011 г. № 313
Пример описания контейнера при работе через ССО
Приложение № 3
к Унифицированному формату
транспортного сообщения при обмене
электронными документами между
территориальными органами Росстата
и респондентами, утверждённого приказом
Росстата от 7 июля 2011 г. № 313
Типы содержимого при работе через Оператора
| Условное обозначение | Описание |
|---|---|
| plain866 | простой текст в кодировке DOS-866 |
| plain1251 | простой тексте кодировке windows-1251 |
| xml | данные формате XML |
| html | документ в формате HTML |
| документ в формате PDF | |
| rtf | документ в формате RTF |
| tiff | документ в формате TIFF |
| jpeg | документ в формате JPEG |
| ms-word | документ в формате Microsoft Word |
| ms-excel | документ в формате Microsoft Excel |
| odf-text | документ в формате Open Document Text |
| odf-spreadsheet | документ в формате Open Document Spreadsheet |
| oxml-word | документ в формате Open XML Word |
| oxml-spreadsheet | документ в формате Open XML Spreadsheet |
| unknown* | произвольные (бинарные) данные |
* По мере необходимости список возможных типов содержимого может расширяться. Если программное обеспечение встречается с неизвестным для себя типом содержимого, то его следует трактовать как unknown.
Приложение № 4
к Унифицированному формату
транспортного сообщения при обмене
электронными документами между
территориальными органами Росстата
и респондентами, утвержденного приказом
Росстата от 7 июля 2011 г. № 313
Xsd-схема
и пример описания транспортного контейнера при работе через Оператора
Описание транспортного контейнера при работе без использования ЦЕМПОС должно удовлетворять следующей xsd-схеме:
Описание транспортного контейнера при работе через ЦЕМПОС должно удовлетворять следующей xsd-схеме:
Приложение № 5
к Унифицированному формату
транспортного сообщения при обмене
электронными документами между
территориальными органами Росстата
и респондентами, утверждённого приказом
Росстата от 7 июля 2011 г. № 313
Пример описания транспортного контейнера при работе через Оператора
Пример описания транспортного контейнера при работе без использования ЦЕМПОС:
Пример описания транспортного контейнера при работе через ЦЕМПОС:
Приложение № 6
к Унифицированному формату
транспортного сообщения при обмене
электронными документами между
территориальными органами Росстата
и респондентами, утверждённого приказом
Росстата от 7 июля 2011 г. № 313
Типы документооборота
6.1 Документооборот по осуществлению письменных обращений респондентов
Таблица 6.1.1. Тип документообооота.
| Код | Тип документооборота | Описание |
|---|---|---|
| письмоРеспондент | документооборот по осуществлению письменных обращений респондентов в орган ФСГС |
Таблица 6.1.2. Типы документов.
| Тип документа | Возможные типы содержимого | Описание |
|---|---|---|
| письмо | plainl251 | неформализованный текст письма |
| описаниеПисьма | xml | служебный документ, в котором передается описание письма (формат приведен в приложении 7.1). |
| приложениеПисьма | (любой) | неформализованное приложение к письму (произвольный формат) |
| подтверждениеОператора | xml | подтверждение даты отправки письма (формат приведен в приложении 7.4) |
| извещениеОПолучении | xml | извещение о получении письма его получателем (формат приведен в приложении 7.3) |
Таблица 6.1.3. Типы транзакций.
| Код | Тип транзакции | Отправитель | Получатель | Документы | Количество место | Шифрованно | Подписанты |
|---|---|---|---|---|---|---|---|
| 1 | письмо | респондент | органФСГС | письмо | 1 | есть | респондент |
| описаниеПисьма | 1 | нет | (отсутствуют) | ||||
| приложениеПисьма | 0 или более | есть | респондент | ||||
| подтверждениеОператора | 1 | нет | оператор | ||||
| 2 | извещение | органФСГС | респондент | извещениеОПолучении | 1 | нет | органФСГС |
6.2 Документооборот по осуществлению индивидуального информирования респондентов
Таблица 6.2.1. Тип документооборота.
| Код | Тип документооборота | Описание |
|---|---|---|
| 2 | письмоОрганФСГС | документооборот по осуществлению индивидуального информирования респондентов со стороны органов ФСГС |
Таблица 6.2.2. Типы документов.
| Тип документа | Возможные типы содержимого | Описание |
|---|---|---|
| письмо | plain 1251 | неформализованный текст письма |
| описаниеПисьма | xml | служебный документ, в котором передается описание письма (формат приведен в приложении 7.1). |
| приложениеПисьма | (любой) | неформализованное приложение к письму (произвольный формат) |
| подтверждениеОператора | xml | подтверждение даты отправки письма (формат приведен в приложении 7.4) |
| извещениеОПолучении | xml | извещение о получении документа его получателем (формат приведен в приложении 7.3) |
Таблица 6.2.3. Типы транзакций.
| Код | Тип транзакции | Отправитель | Получатель | Документы | Количество | Шифрование | Подписанты |
|---|---|---|---|---|---|---|---|
| 1 | письмо | органФСГС | респондент | письмо | 1 | есть | органФСГС |
| описаниеПисьма | 1 | нет | (отсутствуют) | ||||
| приложениеПисьма | 0 или более | есть | органФСГС | ||||
| 2 | подтверждение | оператор | органФСГС | подтверждениеОператора | 1 | нет | оператор |
| 3 | извещение | респондент | органФСГС | извещениеОПолучении | 1 | нет | респондент |
6.3 Документооборот по осуществлению информационной рассылки со стороны ТОГС
Таблица 6.3.1. Тип документооборота.
| Кол | Тим документооборота | Описание |
|---|---|---|
| 3 | рассылка | документооборот по осуществлению информационной рассылки со стороны органов ФСГС |
Таблица 6.3.2. Типы документов.
| Тип документа | Возможные типы содержимого | Описание |
|---|---|---|
| рассылка | plainl251 | неформализованный текст информационной рассылки органа ФСГС |
| описаниеПисьма | xml | служебный документ, в котором передается описание рассылки (формат приведен в приложении 7.1). |
| приложениеПисьма | (любой) | неформализованное приложение к рассылке (произвольный формат) |
| подтверждениеОператора | xml | подтверждение даты отправки рассылки (формат приведен в приложении 7.4) |
Таблица 6.3.3. Типы транзакций.
| Код | Тип транзакции | Отправитель | Получатель | Документы | Количество | Шифрование | Подписанты |
|---|---|---|---|---|---|---|---|
| 1 | рассылка | органФСГС | оператор | рассылка | 1 | нет | органФСГС |
| описаниеПисьма | 1 | нет | (отсутствуют) | ||||
| приложениеПисьма | 0 или более | нет | органФСГС | ||||
| 2 | подтверждение | оператор | органФСГС | подтверждениеОператора | 1 | нет | оператор |
6.4 Документооборот по предоставлению отчетности в ТОГС
Таблица 6.4.1. Тип документооборота.
| Код | Тип документооборота | Описании |
|---|---|---|
| 4 | отчетСтат | документооборот по предоставлению отчетности в органы ФСГС |
Таблица 6.4.2. Типы документов..
| Тип документа | Возможные типы содержимого | Описание |
|---|---|---|
| отчет | xml | документ установленного формата, передаваемый предприятием в орган ФСГС |
| описаниеОтчета | xml | служебный документ, в котором передается описание отчета (формат приведен в приложении 7.2) |
| извещениеОПолучении | xml | извещение о получении документа его получателем (формат приведен в приложении 7.3) |
| подтверждениеОператора | xml | подтверждение даты отправки документа (формат приведен в приложении 7.4) |
| уведомлениеОПриемеВОбработку | plain1251 или xml | электронный документ, формируемый ТОГС, подписанный электронной подписью Росстата и подтверждающий, что первичные статистические данные или бухгалтерская отчетность приняты в обработку органом ФСГС в соответствии с требованиями Росстата |
| уведомлениеОНесоответствииФормату | plain1251 или xml | электронный документ, формируемый ТОГС, подписанный электронной подписью Росстата, содержащий информацию о несоответствии представленных форм статистической или бухгалтерской отчетности установленному формату |
| уведомлениеОбУточнении | plain1251 или xml | электронный документ, формируемый ТОГС, подписанный электронной подписью Росстата, содержащий информацию о недостаточном количестве форм в составе пакета бухгалтерской отчетности и (или) о выявленных ошибках в формах отчетности и противоречиях и информирующий респондента о необходимости повторно представить данные в органы Росстата |
| уведомлениеОбОтклонении 7 | xml | электронный документ, формируемый ТОГС, подписанный электронной подписью Росстата и содержащий информацию о невозможности принять в обработку предоставленные респондентом через оператора первичные статистические данные, ввиду того, что первичные статистические данные этого же респондента за указанный отчетный период по указанной форме предоставлены посредством другого способа сдачи отчетности |
| приложениеПисьма 8 | (любой) | неформализованное приложение к рассылке (произвольный формат) |
Таблица 6.4.3. Типы транзакций.
| Код | Тип транзакции | Отравитель | Получатель | Документы | Количество | Шифрование | Подписанты |
|---|---|---|---|---|---|---|---|
| 1 | отчет | респондент | органФСГС | отчет | 1 | да | респондент |
| описаниеОтчета | 1 | нет | (отсутствуют) | ||||
| подтверждениеОператора | 1 | нет | оператор | ||||
| приложениеПисьма | 0 или более | да | респондент | ||||
| 2 | отчетИзвещение | органФСГС | респондент | извещениеОПолучении | 1 | нет | органФСГС |
| 3 | протокол | органФСГС | респондент | уведомлениеОбУточнении, уведомлениеОПриемеВОбработку, уведомлениеОНесоответствииФормату или уведомлениеОбОтклонении | Да | органФСГС | |
| 4 | протоколИзвещение | респондент | органФСГС | извещениеОПолучении | 1 | нет | респондент |
6.5 Документооборот по уведомлению об ошибке со стороны ТОГС
Таблица 6.5.1. Тип документооборота.
| Код | Тип документооборота | Описание |
|---|---|---|
| 5 | ошибкаОбработкиПакета | документооборот по уведомлению со стороны органа ФСГС системы электронного документооборота о возникновении ошибок и невозможности обработки входящего пакета |
Таблица 6.5.2. Типы документов.
Таблица 6.5.3. Типы транзакций.
| Код | Тип транзакции | Отправитель | Получатель | Документы | Количество | Шифрование | Подписанты |
|---|---|---|---|---|---|---|---|
| 1 | уведомлениеОбОшибке | органФСГС | оператор | описаниеОшибки | 1 | нет | (отсутствуют) |
| описаниеОшибочногоПакета | 1 | нет | (отсутствуют) |
6.6 Документооборот по регистрации сертификатов участников взаимодействия
Таблица 6.6.1. Тип документооборота.
| Код | Тип документооборота | Описание |
|---|---|---|
| 6 | регистрацияСертификатов | документооборот по автоматической регистрации сертификатов участника взаимодействия в программном обеспечении других участников |
Таблица 6.6.2. Типы документов.
| Тип документа | Возможные типы содержимого | Описание |
|---|---|---|
| регистрационнаяИнформация | xml | документ, содержащий информацию о сертификатах участника информационного взаимодействия (формат приведен в приложении 7.7) |
| извещениеОПолучении | xml | извещение о получении документа его получателем (формат приведен в приложении 7.3) |
Таблица 6.6.3. Типы транзакций.
| Код | Тип транзакции | Отправитель | Получатель | Документы | Количество | Шифрование | Подписанты |
|---|---|---|---|---|---|---|---|
| 1 | регистрация | оператор или органФСГС | органФСГС или оператор | регистрационнаяИнформация | 1 | нет | оператор или органФСГС |
| 2 | извещение | органФСГС или оператор | оператор или органФСГС | извещениеОПолучении | 1 | нет | органФСГС или оператор |
6.7 Документооборот по осуществлению рассылки XML-шаблонов со стороны ТОГС / Росстата 10
Таблица 6.7.1. Тип документооборота.
| Код | Тип документооборота | Описание |
|---|---|---|
| 7 | рассылкаШаблонов | документооборот по осуществлению рассылки XML-шаблонов со стороны ТОГС / Росстата |
Таблица 6.7.2. Типы документов.
| Тип документа | Возможные типы содержимого | Описание |
|---|---|---|
| шаблон | xml | XML-шаблон в формате УФ ЭВФ |
| описаниеРассылкиШаблонов | xml | служебный документ, в котором передается описание рассылки шаблонов (формат приведен в приложении 7.8) |
| приложениеПисьма | (любой) | неформализованное приложение к рассылке (произвольный формат) |
| подтверждениеОператора | xml | подтверждение даты отправки рассылки (формат приведен в приложении 7.4) |
Таблица 6.7.3. Типы транзакций.
| Код | Тип транзакции | Отправитель | Получатель | Документы | Количество | Шифрование | Подписанты |
|---|---|---|---|---|---|---|---|
| 1 | рассылкаШаблонов | органФСГС | оператор | шаблон | 1 или более | нет | органФСГС |
| описаниеРассылкиШаблонов | 1 | нет | органФСГС | ||||
| приложениеПисьма | 0 или более | нет | органФСГС | ||||
| 2 | подтверждение | оператор | органФСГС | подтверждениеОператора | 1 | нет | оператор |
Приложение № 7
к Унифицированному формату
транспортного сообщения при обмене
электронными документами между
территориальными органами Росстата
и респондентами, утверждённого приказом
Росстата от 7 июля 2011 г. № 313
Форматы служебных документов
Схема ОбщиеТипы.xsd, определяющая общие типы, используемые в других xsd-схемах:
Описание узлов типа посылка.
Дочерний узел документ узла документы имеет обязательные атрибуты идентификаторДокумента и типДокумента. Значения этих атрибутов должны совпадать со значениями соответствующих атрибутов из узла документ в описании транспортного контейнера, в котором был получен документ. Дочерний узел подпись узла документ имеет обязательный атрибут:
7.1 Схема и пример описания письма и рассылки
Документ описаниеПисьма должен соответствовать следующей схеме:
Таблица 7.1.1. Описание узлов документа описаниеПисьма.
| Имя узла | Количество | Описание |
|---|---|---|
| тема | 1 | тема письма или рассылки |
| категория | 0 или 1 | условное обозначение категории, к которой относится данное письмо или рассылка (справочник категорий формируется по мере необходимости по согласованию с заинтересованными разработчиками систем электронного документооборота) |
| ответНа | 0 или 1 | если письмо является ответом на другое письмо, то идентификатор документооборота (в формате UUID) исходного письма; если письмо не является ответом или является информационной рассылкой, то узел отсутствует |
Пример документа описаниеПисьма:
7.2 Схема и пример описания отчета
Документ описаниеОтчета должен соответствовать следующей схеме:
Таблица 7.2.1. Описание узлов документа описаниеОтчета.
| Имя узла | Количество | Описание |
|---|---|---|
| форма | 1 | описание формы |
| название | 1 | название формы |
| идентификатор | 1 | идентификатор формы |
| год | 1 | год периода, за который предоставляется отчет |
| типПериода | 1 | тип периода. Принимает значения «месяц», «квартал», «год». |
| номерПериода | 1 | порядковый номер периода в году |
| номерОтчета | 1 | порядковый номер отчета в указанном периоде |
| видОгчета | 1 | вид отчета. Принимает значения «статистический», «бухгалтерский» |
Пример документа описаниеОтчета:
7.3 Схема и пример извещения о получении файла
Документ извещениеОПолучении должен соответствовать следующей схеме:
Таблица 7.3.1. Описание узлов документа извещениеОПолучении.
| Имя узла | Количество | Описание |
|---|---|---|
| посылка | 1 | описание посылки, получение которой подтверждается извещением |
Пример документа извещениеОПолучении 11 :
7.4 Схема и пример подтверждения даты отправки
Документ подтверждениеОператора должен соответствовать следующей схеме:
Таблица 7.4.1. Описание узлов документа подтверждениеОператора.
| Имя узла | Количество | Описание |
|---|---|---|
| датаВремяОтправкн | 1 | дата и время отправки пакета |
| посылка | 1 | описание посылки, факт передачи которой подтверждается оператором |
Пример документа подтверждениеОператора 12 :
7.5 Схемы и примеры документов для удаленной проверки работоспособности приемного комплекса
Документ запрос должен соответствовать следующей схеме:
Значением атрибута pingSendDateTime является время формирования документа на сервере оператора. Пример документа запрос:
Документ ответ должен соответствовать следующей схеме:
Значением атрибута pingSendDateTime является время формирования документа на сервере оператора, взятое из документа запрос. Значением атрибута pongSendDateTime является время формирования документа приемным комплексом в органе ФСГС.
Пример документа ответ:
7.6 Схема и пример описания ошибки
Документ описаниеОшибки должен соответствовать следующей схеме:
Таблица 7.6.1. Описание узлов документа описаниеОшибки.
Пример документа описаниеОшибки:
7.7 Схема и пример документа «регистрационнаяИнформация»
Документ регистрационнаяИнформация должен соответствовать следующей схеме:
Таблица 7.6.1. Описание узлов документа регистрационнаяИнформация.
| Имя узла | Количество | Описание |
|---|---|---|
| датаВремяФормирова ния | 1 | дата и время формирования документа с регистрационной информацией |
| списокСубъектов | 1 | список субъектов, информация о сертификатах которых передается в ходе данного документооборота |
| субъект | 1 или более | описание сертификатов каждого субъекта из списка. Для каждого субъекта в документе описываются все известные отправителю действующие сертификаты. |
| сертификат | 1 или более | представление каждого сертификата субъекта в формате BASE64 |
Узел субъект имеет следующие обязательные атрибуты:
Пример документа регистрационнаяИнформация:
7.8 Схема и пример документа «описаниеРассылкиШаблонов» 14
Документ описаниеРассылкиШаблонов должен соответствовать следующей схеме:
Таблица 7.8.1. Описание узлов документа описаниеРассылкиШаблонов.
Пример документа описаниеРассылкиШаблонов:
2 Атрибут идентификаторПодразделения применяется только при работе через ЦЕМПОС.
3 Ограничение применяется только при работе через ЦЕМПОС.
4 Идентификатор в формате «rr» применяется только при работе через ЦЕМПОС.
5 Алгоритмы ГОСТ Р 34.10.2012 применяются только при работе через ЦЕМПОС.
6 Применяется только при работе через ЦЕМПОС
7 Документ используется только при работе через ЦЕМПОС.
8 Документ используется только при работе через ЦЕМПОС.
9 При работе через ЦЕМПОС описание ошибки определяется разработчиком ЦЕМПОС.
10 Пункт применяется только при работе через ЦЕМПОС.
11 При работе через ЦЕМПОС дочерние узлы идентификатор и натуральныйИдентификатор узла получатель имеют формат «rr»
12 При работе через ЦЕМПОС дочерние узлы идентификатор и натуральныйИдентификатор узла получатель имеют формат «rr»
13 При работе через ЦЕМПОС описание ошибки определяется разработчиком ЦЕМПОС.
14 Пункт применяется только при работе через ЦЕМПОС.»
Обзор документа
Обновлен унифицированный формат транспортного сообщения при обмене электронными документами между территориальными органами Росстата и респондентами.
Речь идет об информационном взаимодействии по телекоммуникационным каналам связи по обмену электронными документами с применением электронной подписи между территориальными органами Росстата либо Службы с одной стороны, и респондентами либо специализированным оператором связи с другой.
Отправитель передает по телекоммуникационным каналам связи пакет документов получателю. Получатель по результатам проверки документов, их электронных подписей и сертификатов направляет отправителю электронный документ фиксированного формата, содержащий положительный или отрицательный ответ на пакет документов отправителя.