Приказ Минтруда России от 19.10.2012 № 327

(ред. от 20.12.2012)

«Об утверждении требований к формату предоставления заключений о привлечении и об использовании иностранных работников в форме электронных документов»

МИНИСТЕРСТВО ТРУДА И СОЦИАЛЬНОЙ ЗАЩИТЫ РОССИЙСКОЙ ФЕДЕРАЦИИ

ПРИКАЗ

от 19 октября 2012 г. № 327

ОБ УТВЕРЖДЕНИИ ТРЕБОВАНИЙ К ФОРМАТУ ПРЕДОСТАВЛЕНИЯ ЗАКЛЮЧЕНИЙ О ПРИВЛЕЧЕНИИ И ОБ ИСПОЛЬЗОВАНИИ ИНОСТРАННЫХ РАБОТНИКОВ В ФОРМЕ

Утвердить требования к формату предоставления заключений о привлечении и об использовании иностранных работников в форме электронных документов согласно приложению.

Министр

Приложение

ТРЕБОВАНИЯ К ФОРМАТУ ПРЕДОСТАВЛЕНИЯ ЗАКЛЮЧЕНИЙ О ПРИВЛЕЧЕНИИ И ОБ ИСПОЛЬЗОВАНИИ ИНОСТРАННЫХ РАБОТНИКОВ В ФОРМЕ ЭЛЕКТРОННЫХ ДОКУМЕНТОВ

запрос ФМС России или ее территориального органа о выдаче заключения;

заключение.

2. Настоящий документ определяет требования к формату документов в электронной форме, указанных в пункте 1 требований к формату предоставления заключений о привлечении и об использовании иностранных работников в форме электронных документов (далее — Требования).

3. Электронные документы, указанные в пункте 1 настоящих Требований (далее — электронные документы), должны формироваться в виде файлов в формате XML (далее — XML-документ) в соответствии с описанием структуры XML-документов (далее — XSD-описание).

4. Электронные документы формируются в порядке, определенном Федеральным законом от 27 июля 2010 г. № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг» (Собрание законодательства Российской Федерации, 2010, № 31, ст. 4179; 2011, № 15, ст. 2038; № 27, ст. 3880; № 29, ст. 4291; № 30 (ч. I), ст. 4587; № 49 (ч. V), ст. 7061; 2012, № 31, ст. 4322).

5. Электронные документы могут содержать вложения. Вложения должны быть представлены в виде файлов следующих форматов:

файлов текстовых документов (.doc, .docx, .txt, .rtf);

файлов электронных таблиц (.xls, .xlsx);

файлов графических изображений (.jpeg, tiff, .jp2, .pdf).

Допускается использование специализированных форматов файлов вложений при условии наличия программного обеспечения, обеспечивающего обработку электронных документов в данных форматах на стороне получателя информации без необходимости заключения им дополнительных соглашений и осуществления дополнительных платежей за такое программное обеспечение.

Допускается использование в качестве вложений электронных документов приложений к запросу ФМС России или ее территориального органа о выдаче заключения в виде XML-документов.

При межведомственном информационном взаимодействии с использованием Единой системы межведомственного электронного взаимодействия (далее — СМЭВ) электронный документ передается в составе электронного сообщения СМЭВ.

При этом:

электронный документ, содержащий вложения, оформляется в виде архива в формате «.zip», содержащего тело файла электронного документа в формате XML и тела файлов вложений данного электронного документа;

электронный документ, не содержащий вложения, передается с использованием СМЭВ в виде файла в формате XML.

6. Структура электронных документов должна соответствовать общему XSD-описанию электронных документов.

7. XSD-описание, использующееся для формирования определенного вида электронного документа, считается введенным в действие с момента размещения на официальном сайте Минтруда России и на Едином портале.

8. При предоставлении государственных услуг, а также межведомственном информационном взаимодействии, осуществляемом при предоставлении государственных услуг, органы занятости населения используют электронные документы, соответствующие XSD-описанию электронного документа, содержащие в общем случае следующие блоки данных:

1. блок общих сведений об электронном документе. Содержит сведения о номерах электронного документа, присваиваемых ему в информационных системах, используемых при предоставлении государственной услуги, а также о дате и времени создания электронного документа, дате и времени его отправки и сроке ожидаемого ответа;

2. блок сведений об отправителе электронного документа. Содержит сведения, позволяющие идентифицировать отправителя либо однозначно идентифицировать его персональные данные;

3. блок сведений о получателе электронного документа. Содержит сведения, позволяющие идентифицировать получателя либо однозначно идентифицировать его персональные данные;

4. блок сведений о государственной услуге, для оказания которой необходим электронный документ. Содержит идентификатор и наименование государственной услуги, а при возможности — идентификатор и наименование конкретной административной процедуры (подуслуги), в соответствии со сведениями федеральной государственной информационной системы «Федеральный реестр государственных и муниципальных услуг (функций)»;

5. блок специфических сведений электронного документа. Содержит сведения, установленные административным регламентом предоставления государственной услуги и не относящиеся к другим перечисленным в данном пункте Требований блокам:

сведения, необходимые для предоставления запрашиваемого в рамках межведомственного информационного взаимодействия электронного документа и (или) сведений;

сведения, направляемые получателю в ответ на поступивший межведомственный запрос;

сведения, содержащиеся в заявлении на предоставление государственной услуги или в приложении к нему;

сведения о ходе подготовки заключения;

сведения результата подготовки заключения, если результат может быть представлен в электронной форме;

другие сведения, необходимые при оказании государственной услуги и установленные административным регламентом предоставления государственной услуги;

6. блок описания вложений электронного документа. Содержит описание файлов вложений и ссылки на тела файлов вложений внутри архива в формате «.zip», формируемого для передачи в электронном сообщении с использованием СМЭВ. Структура блока описания вложений, сведения в блоке вложений и архив, содержащий тела файлов вложений, формируются в соответствии с Техническими требованиями к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия, утвержденными приказом Минкомсвязи России от 27 декабря 2010 года № 190 (зарегистрирован Минюстом России 29 декабря 2010 года, № 19425);

7. блок служебных сведений электронного документа. Содержит сведения, формируемые информационными системами взаимодействующих сторон.

9. Каждый электронный документ и каждое вложение электронного документа должны быть подписаны электронной подписью.

При межведомственном информационном взаимодействии с использованием СМЭВ местоположение значения электронной подписи по отношению к подписанному электронному документу (вложению электронного документа) определяется в соответствии с Методическими рекомендациями.

10. Средства электронной подписи, применяемые при подписании электронных документов и вложений электронных документов, должны быть сертифицированы в соответствии с законодательством Российской Федерации.

В целях предоставления государственных услуг применяется электронная подпись, формируемая с использованием средств, выдаваемых удостоверяющими центрами, входящими в реестр доверенных удостоверяющих центров Минкомсвязи России.

11. При оформлении уполномоченными сотрудниками органов занятости населения результатов предоставления услуги, межведомственных запросов и ответов на межведомственные запросы, информационных сообщений о ходе предоставления государственной услуги в форме электронных документов применяется квалифицированная электронная подпись.

12. Обмен информации при подготовке заключения осуществляется в соответствии с форматом информационного взаимодействия при подготовке заключения согласно приложению к Требованиям.

Приложение к Требованиям к формату предоставления заключений

Термины/сокращения

1. Общие сведения

1.1 Руководящие документы

Основанием для разработки данного документа является требование п. 48 приказа Министерства связи и массовых коммуникаций Российской Федерации от 27 декабря 2010 г. N 190 "Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия", в соответствии с которым для подключения информационной системы к системе межведомственного электронного взаимодействия Поставщик предоставляет Оператору СМЭВ следующие документы:

паспорт электронного сервиса, регистрируемого в системе взаимодействия;

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

руководство пользователя электронного сервиса, регистрируемого в системе взаимодействия.

Основанием для создания и использования электронного сервиса являются следующие документы:

а) нормативные правовые документы:

постановление Правительства Российской Федерации от 8 сентября 2010 г. N 697 "О единой системе межведомственного электронного взаимодействия";

приказ Министерства связи и массовых коммуникаций Российской Федерации от 27 декабря 2010 г. N 190 "Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия";

б) технологические стандарты:

методические рекомендации по разработке электронных сервисов и применению технологии электронной подписи при межведомственном электронном взаимодействии, версия 2.4.5, одобренные Правительственной комиссией по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления (протокол заседания от 22 ноября 2012 г. N 10) (далее - Методические рекомендации).

1.2 Описание электронного сервиса

1.3 Операции (методы) электронного сервиса

1.4 Сценарии использования

Данный сценарий описывает ситуацию, когда Потребитель данных вызывает Поставщика данных с целью получения сведений о заключениях о привлечении и об использовании иностранных работников.

Запрос направляется на адрес маршрутизатора ФСМЭВ с указанием кода ОКТМО, посредством которого осуществляется динамическая маршрутизация вызова в целевой региональный орган исполнительной власти или муниципальное образование.

Сценарий предполагает асинхронный режим работы. Первый вызов осуществляет Потребитель данных. Последующие вызовы через определенные промежутки времени опрашивают Поставщика данных на предмет готовности ответных данных. В случае успешного получения данных работы по запросу прекращаются.

В случае каких-либо ошибок при обработке запроса ответ от ИС Поставщика данных будет содержать соответствующий код ошибки в поле errorCode, а также исчерпывающую текстовую информацию по ошибке в поле errorDescription.

1.5 Схема взаимодействия

Взаимодействие с СМЭВ осуществляется через интерфейсы web-сервисов подсистемы путем приема soap-запросов и выполнения запрашиваемой процедуры.

Потребитель данных должен вызвать метод processCanonicalService сервиса Поставщика данных, при этом поле BinaryData блока MessageData\AppDocument заполняется закодированной по Base64 строкой. Закодированная информация представляет собой zip-архив с XML-документом запроса в кодировке UTF-8, подготовленного по XSD-схемам запроса, приложенным в Приложении 2.

В унифицированном блоке СМЭВ в поле smev:Recipient/smev:Code Потребитель (федеральный) указывает мнемонику ИС маршрутизатора ФСМЭВ (ISMV01001), т.к. получателем сообщения является сервис-маршрутизатор, располагающийся на федеральном узле СМЭВ. В поле smev:Recipient/smev:Name Потребитель данных указывает значение "Маршрутизатор типовых сведений единой системы межведомственного электронного взаимодействия".

В блоке Message заполняется поле ОКТМО кодом целевого муниципального образования.

В ответ Поставщик данных, успешно зарегистрировав запрос, вернет уникальный номер заявки в блоке MessageData\AppData, в поле taskId.

После этого Потребитель данных должен периодически опрашивать Поставщика данных на предмет готовности сведений о заключениях о привлечении и об использовании иностранных работников (далее - Результат), заполняя унифицированное поле smev:Status значением "PING", и ранее полученным номером запроса в блоке MessageData\AppData, в поле taskId. Далее возможны два варианта:

в случае если Результат еще не сформирован, в ответе вернется блок smev:Status со значением "PROCESS", при этом блок MessageData\AppDocument\BinaryData заполнен не будет;

в случае готовности Результата в ответе вернет блок smev:Status со значением "RESULT", а в блоке MessageData\AppDocument поле BinaryData будет заполнено закодированной по Base64 строкой. Закодированная информация представляет собой zip-архив с XML-документом ответа в кодировке UTF-8, подготовленный по XSD-схемам ответа, приложенным в подразделе 4.2 "Приложение 2: Описание общих структур данных".

В случае каких-либо ошибок при обработке запроса ответ должен содержать соответствующий код ошибки в поле errorCode, а также исчерпывающую текстовую информацию по ошибке в поле errorDescription.

1.6 Связи с другими электронными сервисами

Данный сервис не имеет связей с другими сервисами.

2. Руководство пользователя

2.1 Операция "processCanonicalService"

2.1.1 Общие сведения

Здесь и далее пространства имен расшифровываются следующим образом:

smev - http://smev.gosuslugi.ru/rev111111

impl - http://impl.canonicalRequests.gov.ru

2.1.2 Описание входных параметров

Инициирующий запрос

Следует отметить, что ключевой сущностью является отдельный документ запроса, сформированный в соответствии с XSD-схемой запроса соответствующей услуги и переданный в разделе AppDocument.

При формировании инициирующего запроса необходимо указывать следующую информацию:

Периодический запрос результата

При формировании периодического запроса результата необходимо указывать следующую информацию:

2.1.3 Описание выходных параметров

Ответ на инициирующий запрос

Ответ на инициирующий запрос содержит следующую информацию:

Ответ на периодический запрос результата

Конечным ответом является отдельный документ, сформированный в соответствии с XSD-схемой ответа соответствующей услуги и переданный в разделе AppDocument.

2.1.4 Формирование вложения

Порядок формирования вложения следующий:

генерация GUID по маске xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, где x описывается регулярным выражением [a-z0-9];

формирование обращения в формате XML с именем req_GUID.xml. XSD-схема вложений запроса и ответа предлагается в подразделе 4.2 "Приложение 2: Описание общих структур данных";

подпись XML-запроса по стандарту PKCS#7 и получение файла подписи req_GUID.xml.sig;

XML-заявление, его подпись, а также все вложения и их подписи архивируются в zip-файл с наименованием req_GUID.zip;

код заявления req_GUID проставляется в элемент smev:RequestCode;

архив req_GUID.zip кодируется в Base64 и полученный код становится содержимым элемента smev:BinaryData в электронном сообщении СМЭВ.

Более подробная информация по формированию вложения содержится в Методических рекомендациях.

2.1.5 Коды возвратов

Приведены в подразделе 4.5 "Приложение 5: Коды возвратов".

2.1.6 Контрольные примеры

Приведены в подразделе 4.4 "Приложение 4: Контрольные примеры".

3. Методика испытаний

3.1 Общие условия

Проведение контрольных испытаний при регистрации электронного сервиса регламентировано приказом Министерства связи и массовых коммуникаций Российской Федерации от 27 декабря 2010 г. N 190 "Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия".

Порядок проведения типовых испытаний предполагает следующие этапы:

проверка комплектности предоставленной документации;

проверка сетевой связности между узлом СМЭВ и точкой размещения электронного сервиса;

регистрация сервиса и тестирование сервиса на контрольном примере.

3.2 Параметры испытаний на тестовой среде

Проведение испытаний на тестовой среде перед регистрацией электронного сервиса в продуктивной среде СМЭВ является необходимым действием, обеспечивающим повышение качества и эффективности процесса и позволяющим выявлять ошибки и несоответствия разработанного сервиса заранее, а не в продуктивном контуре.

Адрес тестового экземпляра: ________________________

Режим функционирования тестовой среды: _____________. Особых условий доступности не определено.

Для того чтоб протестировать сервис, необходимо протестировать все операции на основании контрольных примеров.

3.3 Особые условия

Особые условия и правила проведения контрольных испытаний не предусмотрены.

4. Приложения

4.1 Приложение 1: Описание сервиса (WSDL и XSD)

Ниже приведено WSDL-описание электронного сервиса

<xs:schema targetNamespace="http://canonicalRequests.gov.ru"> <xs:import namespace="http://smev.gosuslugi.ru/rev111111" schemaLocation="smevMessageData.xsd" /> <xs:element name="processCanonicalService" type="smev:processCanonicalServiceMessage"/> <xs:element name="processCanonicalServiceResponse" type="smev:processCanonicalServiceResponseMessage"/> </xs:schema>

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/> <soap:operation soapAction=""/> <soap:body use="literal"/>

<soap:body use="literal"/>

<soap:address location="${service.endpoint.url.here}"/>

4.1.1 Ссылки

Приведенный WSDL содержит ссылку (import) на файл форматов данных

smevMessageData.xsd

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:impl="http://impl.canonicalRequests.gov.ru" xmlns:smev="http://smev.gosuslugi.ru/rev111111" targetNamespace="http://smev.gosuslugi.ru/rev111111" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> <xs:import namespace="http://www.w3.org/2004/08/xop/include" schemaLocation="xopInclude.xsd"/> <xs:import namespace="http://impl.canonicalRequests.gov.ru" schemaLocation="customMessageTypes.xsd"/> <xs:element name="Header" type="smev:HeaderType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="BaseMessage" type="smev:BaseMessageType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="MessageData" type="smev:MessageDataType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="AppData" type="smev:AppDataType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="AppDocument" type="smev:AppDocumentType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="Sender" type="smev:orgExternalType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="Recipient" type="smev:orgExternalType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="Originator" type="smev:orgExternalType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="TypeCode" type="smev:TypeCodeType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="Date" type="xs:dateTime"> xs:annotation </xs:annotation> </xs:element> <xs:element name="RequestIdRef" type="smev:idType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="OriginRequestIdRef" type="smev:idType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="ServiceCode" type="xs:string"> xs:annotation </xs:annotation> </xs:element> <xs:element name="CaseNumber" type="xs:string"> xs:annotation </xs:annotation> </xs:element> <xs:element name="ОКТМО" type="xs:string"> xs:annotation </xs:annotation> </xs:element> <xs:element name="MessageId" type="smev:idType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="TimeStamp" type="xs:dateTime"> xs:annotation </xs:annotation> </xs:element> <xs:element name="NodeId" type="xs:string"> xs:annotation </xs:annotation> </xs:element> <xs:element name="MessageClass" type="smev:MessageClassType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="Status" type="smev:StatusType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="ExchangeType" type="xs:string"> xs:annotation </xs:annotation> </xs:element> <xs:element name="BinaryData" type="xs:base64Binary"> xs:annotation </xs:annotation> </xs:element> <xs:element name="Reference"type="smev:ReferenceType"> xs:annotation </xs:annotation> </xs:element> <xs:element name="DigestValue" type="xs:base64Binary"> xs:annotation </xs:annotation> </xs:element> <xs:element name="TestMsg" type="xs:string"> xs:annotation </xs:annotation> </xs:element> <xs:element name="ОКТМО" type="xs:string"> xs:annotation </xs:annotation> </xs:element> <xs:element name="RequestCode" type="xs:string"> xs:annotation </xs:annotation> </xs:element> <xs:complexType name="HeaderType"> xs:sequence <xs:element ref="smev:NodeId" minOccurs="0"/> <xs:element ref="smev:MessageId"/> <xs:element ref="smev:TimeStamp"/> <xs:element ref="smev:MessageClass" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="BaseMessageType"> xs:sequence <xs:element ref="smev:Message"/> <xs:element ref="smev:MessageData"/> </xs:sequence> </хs:complexType> <xs:complexType name="MessageType"> xs:sequence <xs:element ref="smev:Sender"/> <xs:element ref="smev:Recipient"/> <xs:element ref="smev:Originator" minOccurs="0"/> <xs:element ref="smev:TypeCode"/> <xs:element ref="smev:Status"/> <xs:element ref="smev:Date"/> <xs:element ref="smev:ExchangeType"/> <xs:element ref="smev:RequestIdRef" minOccurs="0"/> <xs:element ref="smev:OriginRequestIdRef" minOccurs="0"/> <xs:element ref="smev:ServiceCode" minOccurs="0"/> <xs:element ref="smev:CaseNumber" minOccurs="0"/> <xs:element ref="smev:TestMsg" minOccurs="0"/> <xs:element ref="smev:ОКТМО" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="MessageDataType"> xs:sequence <xs:element ref="smev:AppData" minOccurs="0"/> <xs:element ref="smev:AppDocument" minOccurs="0"/> </xs:sequence" </xs:complexType> <xs:complexType name="AppDataType"> <xs:sequence" <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType" <xs:complexType name="AppDocumentType"> <xs:sequence" <xs:element ref"smev:RequestCode"/> xs:choice <xs:element ref="smev:BinaryData"/> xs:sequence <xs:element ref="smev:Reference"/> <xs:element ref="smev:DigestValue"/> </xs:sequence> </xs:choice> </xs:sequence> </xs:complexType> <xs:complexType name="ReferenceType" mixed="true"> xs:sequence <xs:element ref="xop:Include" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="orgExternalType"> xs:annotation </xs:annotation> xs:sequence <xs:element name="Code" type="xs:string"> <xs:annotation" </xs:annotation> </xs:element> <xs:element name="Name" type="xs:string"> <xs:annotation" </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:simpleType name="TypeCodeType"> <xs:restriction base="xs:string"> <xs:enumeration value="GSRV"> xs:annotation </xs:annotation> </xs:enumeration> <xs:enumeration value="GFNC"> xs:annotation </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> <xs:simpleType name="StatusType"> <xs:restriction base="xs:string"> <xs:enumeration value="REQUEST"> xs:annotation </xs:annotation> </xs:enumeration> <xs:enumeration value="RESULT"> xs:annotation </xs:annotation> </xs:enumeration> <xs:enumeration value="REJECT"> xs:annotation </xs:annotation> </xs:enumeration> <xs:enumeration value="INVALID"> xs:annotation </xs:annotation> </xs:enumeration> <xs:enumeration value="ACCEPT"> xs:annotation </xs:annotation> </xs:enumeration> <xs:enumeration value="PING"> xs:annotation </xs:annotation> </xs:enumeration> <xs:enumeration value="PROCESS"> xs:annotation </xs:annotation> </xs:enumeration> <xs:enumeration value="NOTIFY"> xs:annotation </xs:annotation> </xs:enumeration> <xs:enumeration value="FAILURE"> xs:annotation </xs:annotation> </xs:enumeration> <xs:enumeration value="CANCEL"> xs:annotation </xs:annotation> </xs:enumeration> <xs:enumeration value="STATE"> xs:annotation </xs:annotation> </xs:enumeration> </xs:restriction> </xs:simpleType> <xs:simpleType name="idType"> <xs:restriction base="xs:string"/> </xs:simpleType>

<!-- processCanonicalService request/response wrappers -->
<xs:complexType name="processCanonicalServiceMessage">
    <xs:sequence>
        <xs:element ref="smev:Message" />
        <xs:element name="MessageData" type="smev:processCanonicalServiceMessageData" />
    </xs:sequence>
</xs:complexType>
<xs:complexTypename="processCanonicalServiceMessageData">
    <xs:sequence>
        <xs:element name="AppData" type="impl:processCanonicalServiceMessageType"

minOccurs=«0»/> <xs:element name=«AppDocument» type=«smev:AppDocumentType» minOccurs=«0»/> </xs:sequence> </xs:complexType> <xs:complexType name=«processCanonicalServiceResponseMessage»> xs:sequence <xs:element ref=«smev:Message»/> <xs:element name=«MessageData» type=«smev:processCanonicalServiceResponseMessageData»/> </xs:sequence> </xs:complexType> <xs:complexType name=«processCanonicalServiceResponseMessageData»> xs:sequence <xs:element name=«AppData» type=«impl:processCanonicalServiceMessageType» minOccurs=«0»/> <xs:element name=«AppDocument» type=«smev:AppDocumentType» minOccurs=«0»/> </xs:sequence> </xs:complexType> </xs:schema>

4.1.2 Ссылки

Приведенный XSD содержит ссылку (import) на следующие файлы форматов данных:

xopInclude.xsd

<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:tns='http://www.w3.org/2004/08/хор/include' targetNamespace='http://www.w3.org/2004/08/xop/include'> <xs:element name='Include' type='tns:Include' /> <xs:complexType name='Include' > xs:sequence <xs:any namespace='##other' minOccurs='0' maxOccurs='unbounded' /> </xs:sequence> <xs:attribute name='href' type='xs:anyURI' use='required' /> <xs:anyAttribute namespace='##other' /> </xs:complexType> </xs:schema»

customMessageTypes.xsd

<xs:schema xmlns:xs=«http://www.w3.org/2001/XMLSchema» xmlns:ds=«http://www.w3.org/2000/09/xmldsig#» xmlns:impl=«http://impl.canonicalRequests.gov.ru» targetNamespace=«http://impl.canonicalRequests.gov.ru» elementFormDefault=«qualified» attributeFormDefault=«unqualified»> <xs:import namespace=«http://www.w3.org/2000/09/xmldsig#» schemaLocation=«xmldsig-core- schema.xsd»/> <xs:complexType name=«baseMessageType» abstract=«true»> xs:sequence <xs:element ref=«ds:Signature» minOccurs=«0» /> <xs:element name=«taskId» type=«xs:string» minOccurs=«0» /> </xs:sequence> <xs:attribute name=«Id» type=«xs:string»/> </xs:complexType> <xs:complexType name=«processCanonicalServiceMessageType»> xs:complexContent <xs:extension base=«impl:baseMessageType» /> </xs:complexContent> </xs:complexType> <xs:complexType name=«processCanonicalServiceResponseMessageType»> xs:complexContent <xs:extension base=«impl:baseMessageType»> xs:sequence <xs:element name=«errorCode» type=«xs:int» /> <xs:element name=«errorDescription» type=«xs:string» minOccurs=«0» /> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema>

xmldsig-core-schema.xsd

Приведенный XSD содержит ссылку (import) на стандартизованный файл форматов данных ЭП xmldsig-core-schema.xsd

           <smev:Sender>
                <smev:Code>SIR-TEST</smev:Code>
                <smev:Name>Тестовый СИР</smev:Name>
            </smev:Sender>
            <smev:Recipient>
                <smev:Code>FOIV001001</smev:Code>
                <smev:Name>ФОИВ-001</smev:Name>
            </smev:Recipient>
            <smev:Originator>
                <smev:Code>FOIV001001</smev:Code>
                <smev:Name>ФОИВ-001</smev:Name>
            </smev:Originator>
            <smev:TypeCode>GSRV</smev:TypeCode>
            <smev:Status>ACCEPT</smev:Status>
            <smev:Date>2012-05-22T13:16:14.530+04:00</smev:Date>
            <smev: ExchangeType>3</smev: ExchangeType>
            <smev:ServiceCode>10000001022</smev:ServiceCode>
            <smev:CaseNumber>ABVDF-E678-912000</smev:CaseNumber>
            <smev:TestMsg>Контрольный пример</smev:TestMsg>
        </smev:Message>
        <smev:MessageData>
            <smev:AppData>
                <impl:taskid>04849441-a83e-4a90-8ca4-d25f4510bf07</impl:taskId>
                <impl:errorCode>0</impl:errorCode>
            </smev:AppData>
        </smev:MessageData>
    </tns:processCanonicalServiceResponse>
</soapenv:Body>