"Протокол обмена информацией о финансовых счетах между Федеральной налоговой службой и организациями финансового рынка (версия от 31.08.2018)"
Утверждаю
Заместитель руководителя
Федеральной налоговой службы
А.С.ПЕТРУШИН
"__" ________ 2018 года
ПРОТОКОЛ
ОБМЕНА ИНФОРМАЦИЕЙ О ФИНАНСОВЫХ СЧЕТАХ МЕЖДУ ФЕДЕРАЛЬНОЙ
НАЛОГОВОЙ СЛУЖБОЙ И ОРГАНИЗАЦИЯМИ ФИНАНСОВОГО РЫНКА
(ВЕРСИЯ ОТ 31.08.2018)
ТЕРМИНЫ, ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ
Термины и определения
Применительно к настоящему документу используются следующие термины и определения:
Термин
Определение
XML-схема (XML Schema)
Язык описания структуры документа. Предусматривает описание допустимой структуры документа и, возможно, типов данных в значениях атрибутов и содержимом элементов.
XML-документ
Электронный документ, представленный XML-схемой.
Событие (Event)
Спецификация существенного факта, который происходит во времени и пространстве.
Сообщение
Структурированная информационная единица, передаваемая между объектами с целью инициирования некоторой деятельности (прием сообщения обычно трактуется как возникновение события).
Электронный документ
Документ в электронном виде, подготовленный в соответствии с описанием форматов электронных форм документов, обеспечивающих передачу прикладной информации между участниками обмена.
Электронное сообщение
Управляющая информация, структурируемая и передаваемая в соответствии с порядком, определенном настоящим Протоколом. Может включать в себя один электронный документ.
Электронный документооборот
Последовательность транзакций по обмену документами между участниками документооборота, обеспечивающая некоторый регламентированный процесс по обмену документами.
Транспортный контейнер
Набор логически связанных документов и ЭП, а также сопутствующая транспортная информация, объединенные в один файл
Уведомление о финансовых счетах
Отчет организации финансового рынка о финансовых счетах клиентов резидентов иностранных государств (территорий) в электронной форме.
Сокращения
Сокращение
Расшифровка
БД
База данных
МЭ
Межсетевое экранирование
НСД
Несанкционированный доступ
НСИ
Нормативно-справочная информация
ОФР
Организация финансового рынка
СВТ
Средства вычислительной техники
СКЗИ
Средства криптографической защиты информации
ФКУ
Федеральное казенное учреждение
ФНС России
Федеральная налоговая служба
ЭД
Электронный документ
ЭП
Электронная подпись
ISO
International Organization for Standardization (Международная организация по стандартизации)
RPC
Remote procedure call (удаленный вызов процедур)
SOAP
Simple Object Access Protocol (Простой протокол доступа к объектам), протокол SOAP
UML
Unified Modeling Language (Унифицированный язык моделирования)
XML
eXtensible Markup Language (Расширяемый язык разметки)
XSD
XML Schema Definition (Определение схемы XML)
W3C
World Wide Web Consortium (Консорциум всемирной сети)
1 ОБЩИЕ СВЕДЕНИЯ
1.1 Наименование документа
Полное наименование настоящего документа - "Протокол обмена информацией о финансовых счетах между Федеральной налоговой службой и организациями финансового рынка" (далее - Протокол).
1.2 Цель документа
Настоящий Протокол разработан в целях описания технических аспектов информационного взаимодействия между ФНС России и ОФР.
1.3 Общие положения
Настоящий документ разработан на основании следующих документов:
1. Многостороннее Соглашение компетентных органов об автоматическом обмене финансовой информацией от 29 октября 2014 г. Подписано ФНС России 12 Мая 2016 года, согласно распоряжению Правительства Российской Федерации от 30 апреля 2016 г. N 834-р.
2. Федеральный закон от 27.11.2017 N 340 "О внесении изменений в часть первую налогового кодекса Российской Федерации в связи с внедрением международного автоматического обмена финансовой информацией в налоговых целях и совершенствованием правил международного налогообложения".
3. Постановление Правительства Российской Федерации от 16.06.2018 N 693 "О реализации международного автоматического обмена финансовой информацией с компетентными органами иностранных государств (территорий)".
4. Стандарт Автоматического обмена информацией о финансовых счетах. Приложение 3 - Руководство пользователя CRS. Версия 2.0
Протокол применяется для реализации электронного обмена данными между компонентами автоматизированных систем ФНС России и ОФР.
Протокол определяет порядок, форматы, способ и регламенты электронного обмена данными между компонентами автоматизированных систем ФНС России и ОФР, а также другие необходимые сведения на основе использования которых возможна реализация информационного взаимодействия.
Информационное взаимодействие осуществляется путем передачи и получения транспортных контейнеров и архивных файлов через сервис, размещенный на сайте ФНС России: https://service.nalog.ru/ofr/fs/index.do.
Взаимодействие осуществляется:
1) Ручным способом. В этом случае файлы транспортных контейнеров могут создаваться с помощью программного комплекса "Налогоплательщик-ЮЛ" или другого и с помощью интерактивного WEB-сервиса передаваться на сайт ФНС России.
2) Автоматизированным способом на основе программного интерфейса интеграции с автоматизированной системой ОФР.
2 ОПИСАНИЕ ПОРЯДКА И ПРАВИЛ ВЗАИМОДЕЙСТВИЯ УЧАСТНИКОВ
ИНФОРМАЦИОННОГО ОБМЕНА
2.1 Общие сведения
Настоящий документ устанавливает технические требования к организации информационного взаимодействия между ФНС России и ОФР.
Информационное взаимодействие осуществляется с использованием сервиса, размещенного на сайте ФНС России. Инициатором передачи и получения данных является ОФР.
Автоматизированные информационные системы ФНС России и ОФР, используемые в работе при обмене информацией, должны удовлетворять требованиям настоящего документа.
В качестве технологии удаленного вызова процедур используется с архитектурный стиль REST (Representational state transfer). Для передачи сообщений используется протокол HTTPS.
Каждый из участников взаимодействия (ФНС России и ОФР) самостоятельно разрабатывает клиентскую и серверную части программного обеспечения, реализующего требования настоящего Протокола.
В ходе информационного взаимодействия между ФНС России и ОФР реализуются следующие процессы:
- передача уведомления организации финансового рынка о финансовых счетах из ОФР в ФНС России;
- передача уведомления об использовании права не представлять информацию по ранее заключенным договорам с клиентами - юридическими лицами с остатком средств менее или равным 250 тысяч долларов США (далее - Уведомление-250);
- передача квитанции о приеме информации и уведомления об отказе в приеме информации из ФНС России в ОФР.
Уведомления-250 за 2017 г. заявитель направляет до 31.07.2018 г., за 2018 г. до 31.05.2019 г.
В качестве кода информационного обмена, позволяющего однозначно идентифицировать принадлежность сообщения к обмену в рамках настоящего Протокола, используется буквенный код CRS.
Перечень сообщений приведен в Таблице 1. Описание электронных документов содержится в приложениях.
Таблица 1
Перечень сообщений
Код документа
Название
Тип документа
Транспортный контейнер при передаче в уполномоченные органы уведомления организации финансового рынка
01
Уведомление о финансовых счетах
Уведомление (XML)
02
Уведомление-250
Уведомление (XML)
Архив при направлении в организацию финансового рынка сведений о приеме или об отказе в приеме информации (ZIP)
01
Квитанции о приеме информации
КвитФНС (PDF)
02
Уведомление об отказе в приеме информации
ОтказФНС (PDF)
03
Протокол контроля
ПротоколФНС (XML)
2.2 Информационное взаимодействие при передаче в ФНС России уведомления о финансовых счетах
ОФР формирует и направляет в ФНС России Транспортный контейнер, содержащий Уведомление о финансовых счетах. Описание Транспортного контейнера приведено в приложении 1.
ФНС России разархивирует Транспортный контейнер и выполняет проверку вложенных уведомлений. При положительном результате проверки формирует Квитанцию о приеме информации (Приложение 3). В случае выявления ошибок формирует Уведомление об отказе в приеме информации (Приложение 4). По результатам проверки формируется Протокол контроля (Приложение 5).
2.3 Информационное взаимодействие при передаче в ОФР сведений о приеме или об отказе в приеме информации
ФНС России подписывает ЭП Квитанцию о приеме или Уведомление об отказе в приеме информации помещает ее в ZIP-архив для передачи в ОФР.
ZIP-архив, содержит файл с Квитанцией о приеме или Уведомлением об отказе в приеме информации в формате PDF, а также Протокол контроля в формате XML, подписанные ЭП.
Коды ошибок формируются в соответствии с описанием сервиса (Приложение 2). Транспортная информация в архив не включается. Архив и входящие в него файлы не шифруются.
Описание Квитанции о приеме или Уведомления об отказе в приеме информации приведено в приложениях 3 и 4. Описание Протокола контроля в приложении 5.
ZIP-архив передается в виде файла с уникальным именем по формату
CRS_9965_<ИНН><КПП>_<UUID>_KV_01_01.zip,
где:
9965 - идентификатор отправителя - ФНС России;
<ИНН><КПП> - идентификатор получателя - ОФР;
UUID - универсальный уникальный идентификатор, обеспечивающий уникальность имени файла; формируется в соответствии с RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt). в виде шестнадцатеричного числа из 32 разрядов, записанного в нижнем регистре.
ОФР разархивирует ZIP-архив и выполняет проверку вложенных документов. При получении отрицательного результата следует обращаться в службу поддержки.
2.4 Прием и обработка тестовых сообщений
Прием и обработка тестовых Уведомлений ФС осуществляется в соответствии с требованиями форматов и Протокола обмена.
Наличие сертификата для тестовых Уведомлений ФС является обязательным. Тестовые Уведомления ФС в БД не сохраняются. В Квитанцию о приеме и Уведомление об отказе в приеме дополнительно включается текст: "ТЕСТОВОЕ".
3 ЭЛЕКТРОННЫЕ СООБЩЕНИЯ
Схемы и экземпляры документов разрабатываются в соответствии со следующими стандартами:
- "Extensible Markup Language (XML) 1.0 (Second Edition)" опубликованному в Интернет по адресу: http://www.w3.org/TR/REC-xml;
- "Namespaces in XML", опубликованному в Интернет по адресу: http://www.w3.org/TR/REC-xml-names;
- "XML Schema Part 1: Structures" и "XML Schema Part 2: Datatypes", опубликованным в Интернет по адресам http://www.w3.org/TR/xmlschema-1/ и http://www.w3.org/TR/xmlschema-2/.
Электронные документы передаются в кодировке UTF-8.
В XML-документе обязательно присутствие объявления документа:
<?xml version ="1.0" encoding ="UTF-8"?>.
4 ПОРЯДОК ОСУЩЕСТВЛЕНИЯ КОНТРОЛЯ ЭЛЕКТРОННЫХ ДОКУМЕНТОВ
4.1.1 Общие сведения
Целью проведения контроля передаваемых электронных документов является обеспечение соответствия содержащихся в них данных требованиям, установленным инструкциями по порядку заполнения документов, а также требованиям формата.
В случае отрицательного результата разархивирования сообщения или обнаружения ошибок вложенных документов одной из сторон по окончании процедуры контроля создается запись в системном журнале и формируется служебный электронный документ, содержащий результаты выполнения контроля, который передается разработчику. Форма служебного электронного документа определяется стороной - разработчиком.
4.1.2 Правила контроля электронных документов
Контроль электронного документа осуществляется в несколько этапов:
- структурный контроль электронного документа;
- форматный контроль электронного документа;
- логический контроль электронного документа.
На этапе структурного контроля выполняется проверка на соответствие электронного документа опубликованным XSD-схемам, регламентирующим синтаксические конструкции определенного электронного документа. Первоначально проверяется структура сообщения в целом, затем структура технологического заголовка сообщения.
На этапе форматного контроля выполняется проверка корректности заполнения полей электронного документа согласно форматам, установленным нормативными документами ФНС России и данным протоколом.
На этапе логического контроля выполняется проверка заполнения полей электронного документа на соответствие классификаторам, а также соответствия значений взаимосвязанных полей электронного документа.
Контроль документов в формате PDF не производится.
5 ПОРЯДОК ОБЕСПЕЧЕНИЯ ЦЕЛОСТНОСТИ И АУТЕНТИФИКАЦИИ
ПЕРЕДАВАЕМОЙ ИНФОРМАЦИИ
Информационный обмен электронными документами должен осуществляться с использованием средств, обеспечивающих целостность и аутентификацию информации, которые должны решать следующие основные задачи:
- защиту от несанкционированного доступа (далее - НСД) к средствам вычислительной техники (СВТ), задействованным при информационном взаимодействии;
- аутентификацию сообщений;
- обеспечение сетевой безопасности при информационном межсетевом взаимодействии;
Под аутентификацией понимается механизм проверки подлинности сообщения. Аутентификация осуществляется на основании проверки электронной подписи, содержащейся в сообщении.
Защита от несанкционированного доступа
Защита от несанкционированного доступа к средствам вычислительной техники выполняется как организационными, так и техническими средствами:
- СВТ, которые задействуются в процессе передачи информации, должны размещаться в отдельных помещениях, доступ в которые разрешен только обслуживающему персоналу.
- СВТ, которые задействуются в процессе передачи информации, могут дополнительно оснащаться сертифицированными средствами защиты информации (СЗИ) от НСД, обеспечивающими:
- Авторизацию пользователей по паролю;
- Контроль целостности исполняемых файлов;
- Замкнутую программную среду.
СВТ, участвующие в процессе передачи, размещаются в выделенных сегментах корпоративной сети передачи данных. Сетевой доступ в эти сегменты ограничивается и контролируется с помощью средств межсетевого экранирования (МЭ). Разрешается доступ только необходимых компьютеров (фильтрация по ip-адресам) и запрещаются все виды сетевого взаимодействия, не использующиеся для нормального функционирования системы (фильтрация по протоколам и TCP-портам).
6 ПОРЯДОК И ОСОБЕННОСТИ ДЕЙСТВИЯ СТОРОН
ВО ВНЕШТАТНЫХ СИТУАЦИЯХ
В ходе обмена информацией между ОФР и ФНС России возможны ситуации, когда обработка данных не может быть произведена в обычном режиме. В частности, это может произойти при возникновении технических сбоев, ошибок структурного и форматно-логического контроля и др.
Для разрешения исключительных ситуаций каждым из указанных ниже ведомств организуется служба поддержки.
Таблица 2
Контактная информация службы поддержки ФНС России
Телефон
Адрес электронной почты
8(495) 913-0000 (12-36)
Mns11343@nalog.ru
7 ПРИЛАГАЕМЫЕ ДОКУМЕНТЫ И СТАНДАРТЫ
7.1. Для разработки и функционирования системы согласно настоящему Протоколу использованы следующие стандарты.
Таблица 3
Стандарты обеспечивающие функционирование системы
Обозначение
Наименование
Примечания
XML 1.0
Extensible Markup Language (XML) 1.0 (Fourth Edition). W3C Recommendation 16 August 2006.
http://www.w3.org/TR/2006/REC-xml-20060816/
REC-xml-names-19990114
Namespaces in XML (Second Edition), W3C Recommendation, 16 August 2006.
http://www.w3.org/TR/2006/REC-xml-names-20060816/
XML Schema
XML Schema Part 1: Structures Second Edition. W3C Recommendation 28 October 2004.
XML Schema Part 2: Datatypes Second Edition. W3C Recommendation 28 October 2004.
http://www.w3.org/TR/xmlschema-1/
http://www.w3.org/TR/xmlschema-2/
7.2. Форматы и формы сообщений представлены в следующих документах:
Приложение 1
Формат транспортного контейнера для электронного обмена информацией о финансовых счетах между организациями финансового рынка и уполномоченными органами.
Приложение 2
Описание технологии сервиса при обмене информацией о финансовых счетах между организацией финансового рынка и ФНС России.
Приложение 3
Форма квитанции о приеме информации.
Приложение 4
Форма уведомления об отказе в приеме информации.
Приложение 5
Протокол контроля уведомлений организации финансового рынка о финансовых счетах.
XML-схемы документов прилагаются отдельными файлами.
Приложение 1
ФОРМАТ
ТРАНСПОРТНОГО КОНТЕЙНЕРА ДЛЯ ЭЛЕКТРОННОГО ОБМЕНА
ИНФОРМАЦИЕЙ О ФИНАНСОВЫХ СЧЕТАХ МЕЖДУ ОРГАНИЗАЦИЯМИ
ФИНАНСОВОГО РЫНКА И УПОЛНОМОЧЕННЫМИ ОРГАНАМИ
1. Термины и определения
1.1. Электронная подпись (ЭП) - реквизит электронного документа, предназначенный для защиты данного электронного документа от подделки, полученный в результате криптографического преобразования информации и позволяющий идентифицировать владельца сертификата ключа подписи, а также установить отсутствие искажения информации в электронном документе.
1.2. Сертификат ключа подписи (сертификат) - документ на бумажном носителе или электронный документ с ЭП уполномоченного лица Удостоверяющего центра (далее - УЦ), который включает в себя открытый ключ, и выдается УЦ для подтверждения подлинности ЭП, идентификации владельца сертификата и обеспечения конфиденциальности передаваемой информации.
1.3. Электронный документ (документ) - документ, представленный в электронном виде, в соответствии с требованиями формата для данного типа документа.
1.4. Транзакция - единичный шаг передачи контейнера с документами и ЭП в рамках взаимодействия, который определяет набор передаваемых документов, ЭП, их отправителя и получателя.
1.5. Электронный документооборот (документооборот) - последовательность транзакций по обмену документами между участниками документооборота, обеспечивающая регламентированный процесс по обмену документами.
1.6. Транспортный контейнер - набор логически связанных документов и ЭП, а также сопутствующая транспортная информация, объединенные в один файл.
2. Общие сведения
2.1. Данный документ описывает структуру транспортного контейнера, формируемого и обрабатываемого программными средствами в ходе информационного взаимодействия между организациями финансового рынка и уполномоченными органами при направлении уведомления о финансовых счетах российских ОФР - нерезидентах Российской Федерации (далее - Уведомление ФС), а также уведомления об использовании права не представлять информацию по ранее заключенным договорам с клиентами - юридическими лицами с остатком средств менее или равным 250 тысяч долларов США (далее - Уведомление-250).
3. Требования к составу контейнера
3.1. Содержимое транспортного контейнера
Транспортный контейнер с данными уведомления организации финансового рынка представляет собой zip-архив, содержащий:
- файл с транспортной информацией в формате xml;
- файл с содержимым Уведомления ФС или Уведомления-250 в формате xml;
- файлы с содержимым передаваемых ЭП.
Рисунок 1: Схема транспортного контейнера (не приводится)
3.1.1. Файлы с содержимым документов и ЭП именуются с использованием универсальных уникальных идентификаторов по формату "<UUID>.bin".
3.1.2. Формат описания транспортной информации приведен в Приложении 1 к настоящему документу.
3.1.3. Файл с транспортной информацией и файлы с содержимым документов и ЭП объединяются в ZIP-архив в режиме STORE. Файл с транспортной информацией при передаче в транспортном контейнере не сжимается и не шифруется.
3.1.4. В одном транспортном контейнере передаются документы и ЭП, относящиеся к одной транзакции.
Транспортный контейнер может содержать не более 2500 файлов. Размер транспортного контейнера не должен превышать 72 мегабайт, а размер любого файла в контейнере не должен превышать 60 мегабайт. Исходный объем файла, zip-архив которого содержится в контейнере, не должен превышать 1024 мегабайт.
3.2. Имя файла транспортного контейнера
3.2.1. Транспортный контейнер передается в виде файла с уникальным именем по формату
CRS_<идентификатор отправителя>_<идентификатор получателя>_<UUID>_<код типа документооборота>_<код типа транзакции>_<код типа документа>.zip
3.2.2. Идентификаторы отправителя и получателя в имени файла должны совпадать с соответствующей информацией в транспортной информации контейнера.
3.2.3. UUID в имени файла контейнера представляет собой универсальный уникальный идентификатор, обеспечивающий уникальность имени файла контейнера.
3.2.4. В случае присутствия в контейнере нескольких документов в имени файла транспортного контейнера указывается код основного документа.
3.2.5. Информация в имени файла должна совпадать с соответствующей информацией в транспортной информации контейнера.
3.3. Требования к типу документооборота приведены в Приложении 3 к настоящему документу.
4. Типы участников документооборота и их идентификация
4.1. Взаимодействие осуществляется между следующими участниками документооборота.
Условное обозначение
Описание
ОФР
Организация финансового рынка в соответствии с частью 1 статьи 2, а также частями 1, 2, 3 и 4 статьи 3 Федерального закона от 28.06.2014 N 173-ФЗ "Об особенностях осуществления финансовых операций с иностранными гражданами и юридическими лицами, о внесении изменений в Кодекс Российской Федерации об административных правонарушениях и признании утратившими силу отдельных положений законодательных актов Российской Федерации" имеющая ЭП, выданную в одном из удостоверяющих центров, входящих в сеть доверия ФНС России
ФНС
ФНС России
4.2. Идентификаторы участников документооборота состоят из цифр.
Условное обозначение
Описание
ОФР
<ИНН><КПП>
ФНС
9965
5. Спецификация используемых технологий
5.1. Универсальные уникальные идентификаторы
5.1.1. Для идентификации документооборотов, документов и для генерации имен файлов в транспортном контейнере используются универсальные уникальные идентификаторы (UUID).
5.1.2. Используемые универсальные уникальные идентификаторы должны генерироваться согласно общим принципам формирования UUID, изложенным в документе RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt). Универсальные уникальные идентификаторы представляются в виде шестнадцатеричного числа из 32 разрядов, записанного в нижнем регистре.
5.2. Объединение и сжатие файлов
5.2.1. Для объединения нескольких документов в один транспортный контейнер и для сжатия документов используется формат ZIP-архива.
5.2.2. Формат ZIP-архива описывается в открытой спецификации, доступной по адресу http://www.pkware.com/documents/casestudies/APPNOTE.TXT. Архивирование должно производиться в соответствии с базовыми возможностями версии 2.0, без использования шифрования.
5.2.3. Документу перед сжатием присваивается имя "file", а его исходное имя записывается в Сведениях о передаваемом документе. После чего он сохраняется в архиве. Имя архива формируется в соответствии с пунктом 3.1.1. При извлечении документа из архива, для восстановления исходного имени файла используется информация из файла описания транспортной информации.
5.3. Криптография
5.3.1. Для шифрования используются алгоритмы ГОСТ 28147-89. Для формирования ЭП используются алгоритмы ГОСТ Р 34.10-2001.
5.3.2. Зашифрованные данные и ЭП передаются при помощи контейнера PKCS #7 (RFC 2315, http://www.ietf.org/rfc/rfc2315.txt). Для сохранения в файл используется DER-кодировка.
5.3.3. Зашифрованные данные передаются в виде структуры ContentInfo со структурой EnvelopedData в качестве содержимого.
5.3.4. ЭП передаются в виде структуры ContentInfo со структурой SignedData в качестве содержимого. ЭП может включать в себя сертификат и не должна включать подписанное содержимое.
5.3.5. Шифрование документов, передаваемых в составе первичного транспортного контейнера, должно производиться в адрес открытых ключей сертификатов получателя, указанных для шифрования, и открытых ключей сертификатов отправителя. Шифрование документов, передаваемых в результате приема или обработки поступившего документа, производится в адрес открытых ключей сертификатов получателя, указанных для шифрования, открытых ключей сертификатов отправителя и открытых ключей сертификатов должностных лиц, подписавших поступивший документ.
Приложение N 1
ФОРМАТ
ПЕРЕДАЧИ СВЕДЕНИЙ ОПИСАНИЯ ТРАНСПОРТНОЙ ИНФОРМАЦИИ
(ВЕРСИЯ 01)
1. ОБЩИЕ СВЕДЕНИЯ
1.1. Назначение
Настоящий документ описывает требования к XML-файлам передачи в электронном виде сведений транспортной информации.
2. ОПИСАНИЕ ФАЙЛА ОБМЕНА
2.1. Общие сведения по файлу обмена
Имя файла обмена должно иметь следующий вид:
packageDescription
Расширение имени файла - xml. Расширение имени файла может указываться как строчными, так и прописными буквами.
Параметры первой строки файла обмена
Первая строка XML-файла должна иметь следующий вид:
<?xml version="1.0" encoding = "windows-1251"?>
Имя файла, содержащего схему файла обмена
Имя файла, содержащего XSD-схему файла обмена, должно иметь следующий вид:
CRS_TK_xx, где xx - текущая версия схемы.
Расширение имени файла - xsd.
2.2. Логическая модель файла обмена
Логическая модель файла представлена в графическом виде в Разделе 3 на рис. 1. Элементами логической модели файла обмена являются элементы и атрибуты XML-файла. Полный перечень структурных элементов логической модели файла и сведения о них приведены в Разделе 4.
Для каждого структурного элемента логической модели файла в Разделе 4 приводятся следующие сведения:
- Наименование элемента. Приводится полное наименование элемента.
- Сокращенное наименование элемента. Приводится сокращенное наименование элемента. Сокращенные наименования могут записываться буквами и цифрами.
- Признак типа элемента. Может принимать следующие значения: "С" - сложный элемент (имеющий вложенные), "П" - простой элемент (не имеющий вложенных); А - атрибут. Если для определения элемента используется пользовательский тип данных, наименование типа данных (типового элемента) указывается в графе "Дополнительные сведения".
- Формат элемента. Формат <1> представляется в условных обозначениях, которым соответствуют следующие значения: T - символьная строка; N - числовое значение (целое или дробное).
--------------------------------
<1> При описании структуры формата файла обмена используются следующие металингвистические конструкции:
<> - метасимволы, используемые для выделения элементов структуры сообщения (логической модели);
| - метасимвол, означающий возможность выбора среди нескольких вариантов значений элемента металингвистической структуры.
Формат символьной строки указывается в виде T(n-к) или T(=к), где n - минимальное количество знаков в строке, к - максимальное количество знаков, символ "-" - разделитель, символ "=" означает фиксированное количество знаков в строке. В случае, если минимальное количество знаков равно 0, формат имеет вид T(0-к). В случае, если максимальное количество знаков неограниченно, формат имеет вид T(n-). В случае, если элемент неопределенной длины, формат имеет вид T.
Формат числового значения указывается в виде N(m.к), где m - максимальное количество знаков в числе, включая знак (для отрицательного числа), целую и дробную часть числа без разделяющей десятичной точки, а k - максимальное число знаков дробной части числа. Если число знаков дробной части числа равно 0 (т.е. число целое), то формат числового значения имеет вид N(m).
Для простых элементов, являющихся базовыми в XML (определенными в http://www.w3.org/TR/xmlschema-0), например, элемент с типом "date", поле "Формат элемента" не заполняется. Для таких элементов в поле "Дополнительная информация" указывается тип базового элемента.
- Признак обязательности элемента определяет обязательность наличия элемента в XML-файле. Признак обязательности элемента может принимать следующие значения: "О" - обязательное наличие элемента (наименование элемента и его значение должны присутствовать в файле обмена); "Н" - присутствие элемента необязательно (наименование элемента и его значение в файле обмена могут отсутствовать). Если элемент может принимать ограниченный перечень значений (по классификатору, кодовому словарю и т.п.), то признак обязательности элемента дополняется символом "К". Например: "ОК". В случае если количество реализаций элемента может быть более одной, то признак обязательности элемента дополняется символом "М". Например: "ОМ, ОКМ".
- Дополнительная информация. Для сложных элементов указывается ссылка на таблицу, в которой описывается состав данного элемента. Для элементов, принимающих ограниченный перечень значений из классификатора (кодового словаря и т.п.), указывается соответствующее наименование классификатора (кодового словаря и т.п.) или приводится перечень возможных значений. Для классификатора (кодового словаря и т.п.) может указываться ссылка на его местонахождение. Для элементов, использующих пользовательский тип данных, указывается наименование типового элемента.
3. ДИАГРАММА ФАЙЛА ОБМЕНА
Рис. 1. Диаграмма структуры файла обмена (не приводится)
4. ПЕРЕЧЕНЬ СТРУКТУРНЫХ ЭЛЕМЕНТОВ ЛОГИЧЕСКОЙ МОДЕЛИ
ФАЙЛА ОБМЕНА
Таблица 4.1
Сведения описания транспортной информации (ТрансИнф)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязат. элемента
Дополнительная информация
Версия формата
версияФормата
А
T(1-10)
О
Версия формата описания транспортного контейнера. В настоящем документе принимает значение "CRS:1.0"
Код типа документооборота
кодТипаДокументооборота
А
T(=2)
ОК
Код типа осуществляемого документооборота. В настоящем документе принимает значение "US"
Тип документооборота
типДокументооборота
А
T(1-50)
О
Тип осуществляемого документооборота. В настоящем документе принимает значение: "УведомлениеФС"
Код типа транзакции
кодТипаТранзакции
А
T(=2)
О
Код типа осуществляемой транзакции, определенной для данного типа документооборота (согласно графы "Код" Таблицы 3 Приложения 3). В настоящем документе принимает значение "01"
Тип транзакции
типТранзакции
А
T(1-50)
О
Тип осуществляемой транзакции, определенной для данного типа документооборота (согласно графы "Тип транзакции" Таблицы 3 Приложения 3)
Идентификатор документооборота
идентификаторДокументооборота
А
T(=32)
О
Универсальный уникальный идентификатор документооборота, который сохраняется в рамках данного цикла обмена документами (UUID)
Версия передающей программы
ВерсПрог
A
T(1-40)
О
Отправитель
отправитель
С
О
Состав элемента представлен в табл. 4.2
В элементе отправитель описывается отправитель (участник электронного документооборота), первично сформировавший транспортный контейнер
Получатель
получатель
С
О
Состав элемента представлен в табл. 4.3
В элементе получатель описывается получатель (участник электронного документооборота), для которого предназначен транспортный контейнер
Сведения о передаваемом документе
документ
С
О
Состав элемента представлен в табл. 4.4
Таблица 4.2
Отправитель (отправитель)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязат. элемента
Дополнительная информация
Идентификатор отправителя
идентификаторСубъекта
А
T(1-46)
О
В соответствии с требованиями, определенными в п. 4.2 раздела 4 "Типы участников документооборота и их идентификации" настоящего документа
Тип субъекта
типСубъекта
А
T(1-50)
О
Указывается условное обозначение типа участника, приведенное в п. 4.1 раздела 4 "Типы участников документооборота и их идентификация" настоящего документа
Таблица 4.3
Получатель (получатель)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязат. элемента
Дополнительная информация
Идентификатор получателя
идентификаторСубъекта
А
T(1-46)
О
В соответствии с требованиями, определенными в п. 4.2 раздела 4 "Типы участников документооборота и их идентификации" настоящего документа
Тип субъекта
типСубъекта
А
T(1-50)
О
Указывается условное обозначение типа участника, приведенное в п. 4.1 раздела 4 "Типы участников документооборота и их идентификация" настоящего документа
Таблица 4.4
Сведения о передаваемом документе (документ)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязат. элемента
Дополнительная информация
Код типа документа
кодТипаДокумента
А
T(=2)
О
Код типа документа, передаваемого в составе контейнера, определенный для осуществляемой транзакции.
Указывается код в соответствии с определенным списком типов документов по передаваемым сведениям (согласно графе "Код" Таблицы 2 Приложения 3).
Тип документа
типДокумента
А
T(1-50)
О
В соответствии с определенным списком типов документов по передаваемым сведениям (согласно графе "Тип документа" Таблицы 2 Приложения 3).
Тип содержимого документа
типСодержимого
А
T(1-50)
О
Тип содержимого документа в соответствии с определенным в Приложении 2 настоящего документа
Признак сжатия документа
сжат
А
О
Типовой элемент <xs:boolean> - значение true или false, в зависимости от того, сжато или нет содержимое документа в контейнере (сжатие документа выполняется перед шифрованием)
Признак шифрования
зашифрован
А
О
Типовой элемент <xs:boolean> значение true или false, в зависимости от того, зашифровано или нет содержимое документа в контейнере
Идентификатор документа
идентификаторДокумента
А
T(=32)
О
Универсальный уникальный идентификатор документа (UUID)
Исходное имя файла документа
исходноеИмяФайла
А
T(1-150)
О
Элемент обязателен, в случае, если исходное имя файла определено
Имя файла указывается с расширением
Содержимое документа
содержимое
С
О
Состав элемента представлен в табл. 4.5
Сведения ЭЦП
подпись
С
О
Состав элемента представлен в табл. 4.6.
Таблица 4.5
Содержимое документа (содержимое)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязат. элемента
Дополнительная информация
Имя файла в контейнере
имяФайла
А
T(1-150)
О
Имя файла (из набора файлов транспортного контейнера) с содержимым описываемого документа с расширением. Имя файла присваивается в соответствии с п. 3.1.1 настоящего документа.
Таблица 4.6
Сведения ЭЦП (подпись)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязат. элемента
Дополнительная информация
Имя файла ЭЦП в контейнере для данного документа
имяФайла
А
T(1-150)
О
Имя файла (из набора файлов транспортного контейнера) с содержимым описываемой ЭЦП с расширением
Приложение N 2
ТИПЫ СОДЕРЖИМОГО
Условное обозначение
Описание
xml
документ в формате XML
Приложение N 3
ДОКУМЕНТООБОРОТ
ПРИ ПРЕДСТАВЛЕНИИ В УПОЛНОМОЧЕННЫЕ ОРГАНЫ УВЕДОМЛЕНИЯ
ОРГАНИЗАЦИИ ФИНАНСОВОГО РЫНКА
Таблица 1. Тип документооборота
Код
Тип документооборота
Описание
US
УведомлениеФС
Документооборот при представлении в уполномоченные органы Уведомления ФС
Таблица 2. Типы документов
Код
Тип документа
Аббревиатура типа документа
Типы содержимого
Описание
01
Уведомление
Uvedom
xml
Уведомление ФС
01
Уведомление
Uvedom-250
xml
Уведомление-250
Таблица 3. Документы, представляемые
в рамках транзакций
Код
Тип транзакции
Отправитель
Получатель
Тип документа
Количество
Шифрование
Подписанты
01
ДокумУведомление
ОФР
ФНС
Уведомление
1
нет
ОФР
Приложение 2
ОПИСАНИЕ
ТЕХНОЛОГИИ СЕРВИСА ПРИ ОБМЕНЕ ИНФОРМАЦИЕЙ О ФИНАНСОВЫХ
СЧЕТАХ МЕЖДУ ОРГАНИЗАЦИЕЙ ФИНАНСОВОГО РЫНКА И ФНС РОССИИ
Общее описание
Сервис предназначен для обеспечения взаимодействия между клиентскими приложениями и сервером ФНС России, предоставляющим функционал для подачи уведомлений организации финансового рынка о финансовых счетах в электронном виде.
Уведомление поступает в ФНС России в виде файла - транспортного контейнера (далее именуется контейнер), структура и состав которого определяется приложением 1 к "Протоколу обмена информацией о финансовых счетах между Федеральной налоговой службой и организациями финансового рынка".
Данный сервис реализован с помощью архитектурного стиля RESTful.
Адрес сервиса (промышленный контур): https://gs.service.nalog.ru/ofr/rs
Адрес описания (промышленный контур): http://service.nalog.ru/ofr/rs/application.wadl
Адрес сервиса (тестовый контур): https://94.125.90.50:8445/ofr/rs
Адрес описания (тестовый контур): http://94.125.90.50:6336/ofr/rs/application.wadl
Доступ к сервису возможен только через защищенное соединение с сервером с использованием алгоритмов ГОСТ 28147-89 и ГОСТ Р 34.10-2001 и разрешен только авторизованным пользователям. Авторизация производится по сертификату ключа подписи, выданному удостоверяющим центром, аккредитованным в сети доверенных УЦ ФНС России.
Ресурсы и методы сервиса
Сервис предоставляет доступ к следующим ресурсам и методам:
/main - Файлы с контейнерами:
uploadFile() - Отправить новый контейнер
getFileInfo() - Получить информацию о результатах обработки контейнера
getReplyList() - Получить список ответов на контейнер
downloadReply() - Загрузить с сервера файл с ответом на контейнер
getFileList() - Получить список контейнеров
downloadFile() - Загрузить с сервера переданный ранее контейнер
Описание технологии работы
Сервис предназначен для обеспечения взаимодействия между клиентскими приложениями и сервером ФНС, в части передачи контейнеров, получения информации о состоянии обработки контейнера и ответных документов.
Типовая последовательность обработки контейнера с использованием сервиса: (пример сценария использования сервиса приведен в Приложении 1):
- подготовленный контейнер с уведомлением передается на сервер с использованием метода uploadFile();
- состояние обработки контейнера проверяется с использованием метода getFileInfo();
- список ответных документов получается с использованием метода getReplyList();
- файл с ответным документом скачивается с использованием метода downloadReply()
Описание методов
uploadFile() - Отправить новый контейнер
Загружает на сервер подготовленный ранее файл транспортного контейнера
Ресурс:
/rs/main
HTTP-Метод:
POST
Параметры:
Тип передаваемых данных:
multipart/form-data
Параметры формы:
file = <Файл транспортного контейнера>
Имя загружаемого файла проверяется на корректность. Это должен быть ZIP-архив с именем, соответствующим формату транспортного контейнера.
Успешный вызов метода
Результат (код)
201 Created
Результат (тип)
Application/json
Результат (описание):
{
"STATUS": "OK",
"ID": <Идентификатор загруженного файла>
}
Дополнительно возвращается HTTP-заголовок location, в котором указывается ссылка на созданный ресурс - файл транспортного контейнера.
Сообщение об ошибке
Результат (код)
400 - BadRequest
Результат (тип)
application/json
Результат (описание):
// JSON-объект.
// Поле errors содержит коды ошибок
{
"STATUS": "Bad Request",
"ERRORS": {"file":
[<Код ошибки>]
}
}
Перечень кодов ошибок приведен в Приложении 2.
getFileInfo() - Получить информацию о результатах обработки
{id} - идентификатор контейнера. Должен состоять из цифр.
Успешный вызов метода
Ресурс:
/rs/main/{id}/info
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
200 OK
Результат (тип)
application/json
Результат (описание):
// JSON-объект.
// Поле INFO содержит объект - транспортный контейнер
{
"STATUS": "OK",
"INFO": {
"ID": <Идентификатор файла>,
"FILE_NAME": <Имя файла транспортного контейнера>,
"DT": <Дата/время приема файла>,
"STATE_CODE": <Код состояния>,
"STATE": <Описание состояния>,
"MSG": <Сообщение об ошибке>,
"ERR_CODE": <Код ошибки>
}
}
Перечень состояний приведен в Приложении 3
Перечень кодов и сообщений об ошибке приведен в Приложении 4.
Ответ при отсутствии контейнера по переданному идентификатору
Ресурс:
/rs/main/{id}/info
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
404 - не найдено
Результат (тип)
application/json
Результат (описание):
{"STATUS":"NotFound","ERROR":"Заявка с уникальным номером {id} не найдена"}
Ответ при некорректном значении {id}
Ресурс:
/rs/main/{id}/info
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
400 - BadRequest
Результат (тип)
application/json
Результат (описание):
{"STATUS":"Bad Request","ERROR":"Некорректное значение параметра id"}
getReplyList() - Получить список ответов на заявку
{id} - идентификатор контейнера. Должен состоять из цифр.
Успешный вызов метода
Ресурс:
/rs/main/{id}/reply
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
200 OK
Результат (тип)
application/json
Результат (описание):
// JSON-объект.
// Поле REPLY_LIST содержит список объектов - транспортных контейнеров
{
"STATUS": "OK",
"REPLY_LIST": [
{
"ID": <Идентификатор файла - ответа>,
"FILE_NAME": <Имя файла>,
"FILE_SIZE": <Размер файла в байтах>,
"STATE": <Описание ответа>,
"TYPE": <Тип файла - zip или pdf>
},
...
]
}
Если по переданному идентификатору контейнера ответных файлов нет, REPLY_LIST будет пуст
Поле "STATE" (Описание ответа) может содержать следующие значения:
- Квитанция о приеме
- Сообщение об ошибке
- Уведомление об отказе
Ответ при некорректном значении {id}
Ресурс:
/rs/main/{id}/reply
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
400 - BadRequest
Результат (тип)
application/json
Результат (описание):
{"STATUS":"Bad Request","ERROR":"Некорректное значение параметра id"}
downloadReply() - Загрузить с сервера файл с ответом
{id} - идентификатор контейнера. Должен состоять из цифр.
{replyId} - идентификатор ответа (значение ID, возвращаемое методом getReplyList()). Должен состоять из цифр.
Успешный вызов метода
Ресурс:
/rs/main/{id}/reply/{replyId}
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
200 OK
Результат (тип)
application/x-zip-compressed
Результат (описание):
Файл ответа
Ответ при отсутствии контейнера по переданному идентификатору
Ресурс:
/rs/main/{id}/reply/{replyId}
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
404 - не найдено
Результат (тип)
application/json
Результат (описание):
(отсутствует)
Ответ при некорректном значении {id}/{replyId}
Ресурс:
/rs/main/{id}/reply/{replyId}
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
400 - BadRequest
Результат (тип)
application/json
Результат (описание):
(отсутствует)
Дополнительные методы позволяют работать с контейнерами в случае, когда на стороне пользователя не обеспечивается хранение файлов контейнеров и их перечня:
getFileList() - Получить список заявок
Возвращает список заявок, отправленных пользователем.
Ресурс:
/rs/main
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
200 OK
Результат (тип)
application/json
Результат (описание):
// JSON-объект.
// Поле FILE_LIST содержит список объектов - транспортных контейнеров
{
"STATUS": "OK",
"FILE_LIST": [
{
"ID": <Идентификатор файла>,
"FILE_NAME": <Имя файла транспортного контейнера>,
"DT": <Дата/время приема файла>,
"STATE_CODE": <Код состояния>,
"STATE": <Описание состояния>
},
...
]
}
Перечень состояний приведен в Приложении 3
downloadFile() - Загрузить с сервера файл с заявкой
Успешный вызов метода
Ресурс:
/rs/main/{id}
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
200 OK
Результат (тип)
application/x-zip-compressed
Результат (описание):
Файл транспортного контейнера в формате ZIP-архива.
Ответ при отсутствии контейнера по переданному идентификатору
Ресурс:
/rs/main/{id}
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
404 - не найдено
Результат (тип)
application/json
Результат (описание):
(отсутствует)
Ответ при некорректном значении {id}
Ресурс:
/rs/main/{id}
HTTP-Метод:
GET
Параметры:
(отсутствуют)
Результат (код)
400 - BadRequest
Результат (тип)
application/json
Результат (описание):
(отсутствует)
Приложение 1
ТИПОВОЙ СЦЕНАРИЙ ИСПОЛЬЗОВАНИЯ СЕРВИСА
Подготовленный файл контейнера отправляется с помощью метода uploadFile(). Для тестирования метода можно воспользоваться простой HTML-формой:
<html><body>
<form method="post" action="https://94.125.90.50:8445/ofr/rs/main" enctype="multipart/form-data">
<input type="file" name="file"/>
<button id="btn_btnSave" type="submit" >Send</button>
</form>
</body></html>
Метод в случае успешного завершения возвращает:
{"STATUS":"OK","ID":90057}
Если происходит ошибка, например, повтор файла, метод вернет:
{"STATUS":"BadRequest","ERRORS":{"file":["115"]}}
Через некоторое время после отправки файла контейнера обращаемся к методу getFileInfo() для того, чтобы получить сведения о результате обработки файла, построив URL-метода с использованием ID, возвращенного предыдущим методом (90057):
URL https://94.125.90.50:8445/ofr/rs/main/90057/info
Ответ сервера:
{"STATUS":"OK","INFO":{"FILE_NAME":"FR_7707083893775001001_9965_DBBFD9D5D7504E4C9D6F768FB007C28A_UF_01_01.ZIP","STATE":"Заявка принята, сформирована квитанция о приеме", "DT":"19.01.2016 17:37:41", "ID":90057, "STATE_CODE":"15"}}
Далее используем метод getReplyList() для получения списка ответных файлов:
URL https://94.125.90.50:8445/ofr/rs/main/90057/reply
Ответ сервера:
{"STATUS":"OK","REPLY_LIST":[{"FILE_NAME":"KV_FR_7707083893775001001_9965_DBBFD9D5D7504E4C9D6F768FB007C28A_UF_01_01_20160119.pdf", "STATE":"Квитанция о приеме", "ID":4002, "FILE_SIZE":65188, "TYPE":"pdf"}]}
Вызываем метод downloadReply() для получения ответного файла, построив URL метода с использованием ID контейнера (90057), и ID ответа, возвращенного предыдущим методом (4002):
URL https://94.125.90.50:8445/ofr/rs/main/90057/reply/4002
Вернется файл KV_FR_7707083893775001001_9965_DBBFD9D5D7504E4C9D6F768FB007C28A_UF_01_01_20160119.pdf
Приложение 2
СПИСОК СООБЩЕНИЙ ПРИ КОНТРОЛЕ ИМЕНИ ФАЙЛА КОНТЕЙНЕРА
Контроль имени файла контейнера осуществляется при загрузке контейнера. Если имя файла не соответствует требованиям, его загрузка не производится.
Код ошибки
Ошибка
Диагностическое сообщение
100
Указан неверный путь, либо ошибочное имя файла
Пустой файл
101
Имя файла не начинается на CRS_
Имя файла не начинается на CRS_
102
Расширение файла не ZIP
Расширение файла не ZIP
103
Имя файла без путей и расширения пустое
Пустое имя файла
104
При разбиении имени файла по символу "_" число частей отлично от 7
Некорректная структура имени файла
105
Идентификатор получателя, отличный от 9965
Некорректный идентификатор получателя
106
код типа документооборота, отличный от US
Некорректный код типа документооборота
107
код типа транзакции, отличный от 01
Некорректный код типа транзакции
108
код типа документа, отличный от 01
Некорректный код типа документа
109
длина ИНН + КПП в имени файла отлична от 19
Некорректный ИНН + КПП
110
Некорректный ИНН в идентификаторе отправителя. Не совпадает контрольный разряд.
Некорректный ИНН в идентификаторе отправителя.
111
Некорректный КПП в идентификаторе отправителя
Некорректный КПП в идентификаторе отправителя
112
Отсутствует GUID
Некорректная структура имени файла
113
Структура GUID не соответствует [\da-fA-F]{8}-[\da-fA-F]{4}-[\da-fA-F]{4}-[\da-fA-F]{4}-[\da-fA-F]{12}
Некорректный GUID
114
ИНН в идентификаторе отправителя не совпадает с ИНН абонента, определенным при авторизации на сайте
Выбранный файл не принадлежит данному абоненту
115
Контейнер с таким именем уже отправлялся ранее, загрузка не производится
Имя файла контейнера не уникально
Приложение 3
СПИСОК СОСТОЯНИЙ КОНТЕЙНЕРА
10 - Заявка поставлена в очередь на обработку
15 - Заявка принята, сформирована квитанция о приеме
95 - Заявка не может быть выполнена
96 - Заявка не может быть выполнена, сформировано уведомление об отказе
98 - Некорректный транспортный контейнер, сформировано сообщение об ошибках;
99 - Некорректный транспортный контейнер
Возможные последовательности изменения состояний:
10 - 15
10 - 95 - 96
10 - 99 - 98
Приложение 4
СПИСОК СООБЩЕНИЙ ПРИ КОНТРОЛЕ СОДЕРЖИМОГО КОНТЕЙНЕРА
Действие
Код ошибки
Ошибка
Диагностическое сообщение
Распаковка контейнера
201
Любая ошибка распаковки ZIP
Контейнер пуст или не является ZIP-архивом.
Разбор файла packageDescription.xml
202
В контейнере отсутствует файл packageDescription.xml
Не найден описатель транспортной информации
203
Файл packageDescription.xml не является корректным XML
Некорректный XML (packageDescription.xml):<сообщение парсера>
204
Файл packageDescription.xml не соответствует схеме
XML (packageDescription.xml) не соответствует схеме CRS_UVCRS_05_01_01.XSD: <сообщение парсера>
205
кодТипаТранзакции в packageDescription.xml не соответствует имени файла
не соответствует кодТипаТранзакции в имени файла и в packageDescription.xml
206
кодТипаДокументооборота в packageDescription.xml не соответствует имени файла
не соответствует кодТипаДокументооборота в имени файла и в packageDescription.xml
207
Документ, упомянутый в packageDescription.xml, не найден в контейнере
В контейнере отсутствует файл<ИмяФайла>
208
Файл подписи, упомянутый в packageDescription.xml, не найден в контейнере
В контейнере отсутствует файл подписи<ИмяФайла>
Проверка реквизитов отправителя в packageDescription.xml
209
идентификатор Субъекта отличается от указанного в имени файла
Описание транспортной информации: узел отправитель: некорректный идентификатор Субъекта
210
тип Субъекта отличается от "ОФР"
Описание транспортной информации: узел отправитель: некорректный тип Субъекта
Проверка реквизитов получателя в packageDescription.xml
211
идентификатор Субъекта отличается от 9965
Описание транспортной информации: узел получатель: некорректный идентификатор Субъекта
212
тип Субъекта отличается от "ФНС"
Описание транспортной информации: узел получатель: некорректный тип Субъекта
Проверка файлов в контейнере
213
В контейнере есть файлы, отличные от packageDescription.xml и перечисленных в нем
Контейнер содержит неопознанные файлы:<количество>
Распаковка документов в контейнере
214
Не удается распаковать сжатый файл
Файл<ИмяФайла> пуст или не является ZIP-архивом
215
Сжатый файл содержит более одного элемента
Архив <ИмяФайла> содержит более одного элемента
Проверка подписей
216
Нарушение структуры либо некорректность хотя бы одной из подписей
Найдены несоответствия ЭЦП<Список документ - несоответствие>
Поиск документа
217
Документ с требуемым типом не найден
В контейнере не найдено документа
218
Документов с требуемым типом более одного
В контейнере найдено более одного документа
Проверка имени файла уведомления
219
Дата в имени файла уведомления не равна текущей
Дата в имени файла уведомления не равна текущей
220
Идентификатор отправителя не соответствует указанному в описателе транспортной информации
Неверный идентификатор отправителя в имени файла
221
Файл с таким именем уже имеется
Файл <ИмяФайла> зарегистрирован ранее
Разбор файла уведомления
222
Файл не является корректным XML
Некорректный XML (<ИмяФайла>): <сообщение парсера>
223
Файл уведомления не соответствует схеме
XML (<ИмяФайла>) не соответствует схеме <ИмяСхемы>: <сообщение парсера>
224
225
Проверка соответствия реквизитов сертификата подписи реквизитам узла Подписант уведомления
226
ФИО владельца сертификата не соответствует ФИО подписанта
В контейнере найдены ЭЦП посторонних лиц
Проверка соответствия ИНН ОФР в уведомлении и ИНН абонента
227
ИНН ОФР в имени файла уведомления не соответствует ИНН абонента (ИНН в сертификате, которым произведена авторизация)
ИНН ОФР в имени файла уведомления не соответствует ИНН абонента
Приложение 5
СПИСОК СООБЩЕНИЙ ПРИ КОНТРОЛЕ УВЕДОМЛЕНИЯ ФС
Код ошибки
Ошибка
Диагностическое сообщение
50009 <*>
Идентификатор сообщения MessageRefId не является уникальным в отношении всех ранее направленных уведомлений
Идентификатор сообщения MessageRefId уже использован
60000
Если счет имеет Тип (AcctNumberType) "OECD601" - IBAN, то он должен соответствовать структуре: первые два символа - латинские буквы, определяющие код страны эмитента согласно стандарту ISO 3166-1 alpha-2. Далее, не более 32 цифр или латинских букв
Некорректный номер счета IBAN
60001
Если счет имеет Тип (AcctNumberType) "OECD603" - ISIN, то он должен соответствовать структуре: первые два символа - латинские буквы, определяющие код страны эмитента согласно стандарту ISO 3166-1 alpha-2. Далее 10 цифр или латинских букв
Некорректный номер счета ISIN
60002
Баланс счета (AccountBalance) меньше, чем ноль. Эта сумма должна быть больше или равна нулю
Некорректный Баланс счета (AccountBalance)
60003
Присутствует остаток на счете при закрытом счете
Присутствует остаток на счете при закрытом счете
60005
Если владельцем счета является организация, а "Тип владельца счета" - CRS102 или CRS103, то "Тип контролирующего лица" должен быть опущен. (CRS102 = подотчетное лицо; CRS103 = Пассивная нефинансовая организация, являющаяся отчетным лицом)
Тип контролирующего лица должен быть опущен
60006
При наличии заполнения Organisation (владельцем счета является организация), и "Тип владельца счета" - CRS101 элемент ControllingPerson должен присутствовать.
Отсутствует контролирующее лицо
60014
Дата (BirthDate) рождения ранее 1900 г. или позднее текущей
Дата (BirthDate) рождения ранее 1900 г. или позднее текущей
98000
Структура имени файла не соответствует требованиям формата
Некорректное имя файла
98001
Идентификационный номер (N) в имени файла не содержит 36 знаков и не соответствует структуре GUID
Идентификационный номер (N) в имени файла не соответствует структуре GUID
98002
Дата имени файла уведомления не является датой в формате GGGGMMDD
Дата имени файла уведомления не является датой в формате GGGGMMDD
98003
Дата в имени файла уведомления (GGGGMMDD) больше текущей даты
Дата в имени файла (GGGGMMDD) больше текущей даты
98004
Дата формирования уведомления в Timestamp не соответствует дате в имени файла
Дата формирования уведомления в Timestamp не соответствует дате в имени файла
98005
ИНН в имени файла не соответствует ИНН в SendingCompanyIN
ИНН в имени файла не соответствует ИНН в SendingCompanyIN
98006
ИНН в имени файла не соответствует ИНН в MessageRefId
ИНН в имени файла не соответствует ИНН в MessageRefId
98007
ИНН в имени файла не соответствует ИНН в ReportingFI/INN
ИНН в имени файла не соответствует ИНН в ReportingFI/INN
98008
ИНН в имени файла не соответствует ИНН в структуре ReportingFI/DocSpec/DocRefID.
ИНН в имени файла не соответствует ИНН в структуре ReportingFI/DocSpec/DocRefID.
98009
Неверный контрольный разряд ОГРН в SendingCompanyIN
Неверный контрольный разряд ОГРН
98010
GGGG в MessageRefId не соответствует отчетному году в ReportingPeriod
Неверный отчетный год в MessageRefId
98011
GGGG в DocRefID не соответствует отчетному году в ReportingPeriod
Неверный отчетный год в DocRefID
98012
Нарушено условие: BirthDate является обязательным при заполнении раздела AccountHolder/Inpidual/BirthInfo.
BirthDate является обязательным при заполнении раздела AccountHolder
98015
В элементе ReportingFI/ResCountryCode отсутствует значение "RU"
В элементе ReportingFI/ResCountryCode отсутствует значение "RU"
98016
В элементе ReportingFI/Address/CountryCode отсутствует значение "RU"
В элементе ReportingFI/Address/CountryCode отсутствует значение "RU"
98017
ИНН в имени файла не соответствует ИНН в структуре AccountReport/DocSpec/DocRefID.
ИНН в имени файла не соответствует ИНН в структуре AccountReport/DocSpec/DocRefID.
98018
Идентификационный номер IN типа GIIN имеет неверную структуру. Формат не: XXXXXX.XXXXX.XX.XXX. Допускаются цифры и латинские буквы, разделенные точками.
Неверная структура GIIN
98019
Нарушено условие: если DocSpec = (OECD2 | OECD3 | OECD12 | OECD13), то CorrDocRefId обязательно должен быть заполнен
CorrDocRefId обязательно должен быть заполнен
98020
Идентификатор DocRefID не может быть равен CorrDocRefID внутри одного файла
Идентификатор DocRefID не может быть равен CorrDocRefID внутри одного файла
98021
Нарушено условие: если MessageTypeIndic >< CRS703 и ReportingFI/DocSpec = (OECD1 | OECD11), то AccountReport должен присутствовать
AccountReport должен присутствовать
98022
Нарушено условие: если MessageTypeIndic = CRS701, то DocSpec = (OECD1 | OECD11)
DocSpec не равен (OECD1 | OECD11)
98023
Нарушено условие: если MessageTypeIndic = CRS702, то DocSpec >< (OECD1 | OECD11) в AccountReport
В корректирующем уведомлении MessageTypeIndic = CRS702 не допускается новых документов: DocSpec = (OECD1 | OECD11)
98024
Нарушено условие: если MessageTypeIndic = CRS703, то разделы AccountReport должны отсутствовать
Разделы AccountReport должны отсутствовать
98025
Нарушено условие: если DocSpec = (OECD1 | OECD2 | OECD3), то не допускается DocSpec = (OECD11 | OECD12 | OECD13)
Не допускается сочетание тестовых и промышленных документов
98026
Нарушено условие: если DocSpec = (OECD11 | OECD12 | OECD13), то не допускается DocSpec = (OECD1 | OECD2 | OECD3)
Не допускается сочетание тестовых и промышленных документов
98027
Есть реквизиты в содержании которых имеются буквы на русском регистре
Не допускается использование русских букв <наименование реквизита> <значение реквизита>
98031
Ошибка проверки по схеме
FC0001 - Ошибка проверки по схеме
98032
Реквизит не прописан в схеме
FC0002 - Реквизит не прописан в схеме
98033
Отсутствует обязательный реквизит
FK1005 - Отсутствует обязательный реквизит
98034
Реквизит не может принимать множественные значения
FC0007 - Реквизит не может принимать множественные значения
98035
Ошибка длины реквизита
FK1102 - Ошибка длины реквизита
98036
В уведомлении CRS_UV250 Timestamp<=31.08.2019 включительно, если год из ReportingPeriod равен 2017, или Timestamp<=31.08.2019 включительно, если год из ReportingPeriod равен 2018
Нарушен срок подачи уведомления
80000 <*>
Идентификатор документа DocRefID не является уникальным в отношении всех ранее направленных уведомлений
DocRefID уже используется для другой записи
80001
Формат DocRefID не соответствует требованиям
Некорректный формат DocRefID
80002 <*>
Отсутствует первичный или последний корректирующий документ. CorrDocRefId ссылается на неизвестную запись
CorrDocRefId ссылается на неизвестную запись
80003 <*>
CorrDocRefId ссылается на неактуальную (не последнюю) запись
Недействительный CorrDocRefId
80004
В первичном документе не должно быть корректировок. CorrDocRefId присутствует в первичном документе
CorrDocRefId присутствует в первичном документе
80005
DocTypeIndic равен OECD2 (скорректированные данные) или OECD3 (удаление), но CorrDocRefId не указан
Отсутствует CorrDocRefId
80009
В ReportingFI/DocSpec указан DocTypeIndic = (OECD3 | OECD13)
ReportingFI не может быть удален
80010
Сообщение не может содержать смесь новых записей (OECD1) и записей исправления/удаления (OECD2, OECD3) в AccountReport
Некорректный DocTypeIndic. Сообщение не может содержать смесь новых записей (OECD1) и записей исправления/удаления (OECD2, OECD3)
80011
Один и тот же идентификатор DocRefID не может быть исправлен или удален дважды в одном сообщении
Повтор CorrDocRefID в одном сообщении
98020
DocRefID не может быть равен CorrDocRefID внутри одного файла
DocRefID cannot be equal CorrDocRefID in the same file
98021
При наличии у ОФР актуальных счетов за указанный период, отчет об отсутствии сведений (MessageTypeIndic = CRS703) не принимается
The message about absence of the reporting, is not accepted. The organization has current accounts
(Сообщение об отсутствии отчетности не принято. У организации есть актуальные счета)
99999
Полученное сообщение содержит ошибку для которой отсутствует определенный код.
Неустановленная ошибка. Детализация должна указать содержание ошибки
--------------------------------
ПРИМЕЧАНИЯ:
<*> Не выполняются при проверке тестовых сообщений. Тестовые сообщения на корректировку и удаление тестовых данных на наличие первичного тестового Уведомления не проверяются.
Коды ошибок приняты в соответствии с "Common Reporting Standard status Message XML Schema: User Guide for Tax Administrations. Part B. CRS Status Message Error Codes". OECD 2017.
Приложение 3
Приложение 4
Приложение 5
ФОРМАТ
ПРОТОКОЛА КОНТРОЛЯ УВЕДОМЛЕНИЙ ОРГАНИЗАЦИИ ФИНАНСОВОГО
РЫНКА О ФИНАНСОВЫХ СЧЕТАХ
I. ОБЩИЕ СВЕДЕНИЯ
1. Настоящий формат описывает требования к структуре и содержанию протокола контроля уведомлений организации финансового рынка о финансовых счетах в электронной форме (далее - Протокол).
Настоящий формат разработан в соответствии с документом "Common Reporting Standard status Message XML Schema. User Guide for Tax Administrations". OECD 2017.
Номер версии настоящего формата RU.1.0.
2. Элементами логической модели файла обмена являются элементы и атрибуты XML-файла. Для каждого структурного элемента логической модели файла обмена приводятся следующие сведения:
наименование элемента. Приводится полное наименование элемента <1>;
--------------------------------
<1> В строке таблицы могут быть описаны несколько элементов, наименования которых разделены символом "|". Такая форма записи применяется в случае возможного наличия в файле обмена только одного элемента из описанных в этой строке.
сокращенное наименование (код) элемента. Приводится сокращенное наименование элемента. Синтаксис сокращенного наименования должен удовлетворять спецификации XML;
признак типа элемента. Может принимать следующие значения: "С" - сложный элемент логической модели (содержит вложенные элементы), "П" - простой элемент логической модели, реализованный в виде элемента XML-файла, "А" - простой элемент логической модели, реализованный в виде атрибута элемента XML-файла. Простой элемент логической модели не содержит вложенные элементы;
формат элемента. Формат элемента представляется следующими условными обозначениями: T - символьная строка; N - числовое значение (целое или дробное).
Формат символьной строки указывается в виде T(n-к) или T(=к), где: n - минимальное количество знаков, к - максимальное количество знаков, символ "-" - разделитель, символ "=" означает фиксированное количество знаков в строке. В случае, если минимальное количество знаков равно 0, формат имеет вид T(0-к). В случае, если максимальное количество знаков неограниченно, формат имеет вид T(n-).
Формат числового значения указывается в виде N(m.к), где: m - максимальное количество знаков в числе, включая знак (для отрицательного числа), целую и дробную часть числа без разделяющей десятичной точки, k - максимальное число знаков дробной части числа. Если число знаков дробной части числа равно 0 (т.е. число целое), то формат числового значения имеет вид N(m).
Для простых элементов, являющихся базовыми в XML (определенными в http://www.w3.org/TR/xmlschema-0), например, элемент с типом "date", поле "Формат элемента" не заполняется. Для таких элементов в поле "Дополнительная информация" указывается тип базового элемента;
признак обязательности элемента определяет обязательность присутствия элемента (совокупности наименования элемента и его значения) в файле обмена. Признак обязательности элемента может принимать следующие значения: "О" - наличие элемента в файле обмена обязательно; "Н" - присутствие элемента в файле обмена необязательно, т.е. элемент может отсутствовать. Если элемент принимает ограниченный перечень значений (по классификатору, кодовому словарю и т.п.), то признак обязательности элемента дополняется символом "К". Например: "ОК". В случае, если количество реализаций элемента может быть более одной, то признак обязательности элемента дополняется символом "М". Например: "НМ", "ОКМ".
К вышеперечисленным признакам обязательности элемента может добавляться значение "У" в случае описания в XML-схеме условий, предъявляемых к элементу в файле обмена, описанных в графе "Дополнительная информация". Например: "НУ", "ОКУ";
дополнительная информация содержит, при необходимости, требования к элементу файла обмена, не указанные ранее. Для сложных элементов указывается ссылка на таблицу, в которой описывается состав данного элемента. Для элементов, принимающих ограниченный перечень значений из классификатора (кодового словаря и т.п.), указывается соответствующее наименование классификатора (кодового словаря и т.п.) или приводится перечень возможных значений. Для классификатора (кодового словаря и т.п.) может указываться ссылка на его местонахождение. Для элементов, использующих пользовательский тип данных, указывается наименование типового элемента.
Для всех реквизитов недопустимы пустое значение и пустое пространство. Если значение не указано, элемент должен быть опущен.
3. Имя файла протокола должно иметь следующий вид:
Имя файла протокола формируется на основе имени файла Уведомления ФС и должно иметь следующий вид: RR<P>.xml, где:
RR - префикс, принимающий значения: KV - для Квитанции о приеме; UV - для Уведомления об отказе в приеме;
P - имя файла поступившего Уведомления ФС без расширения.
Первая строка XML-файла должна иметь следующий вид: <?xml version="1.0" encoding="UTF-8"?>.
Схема файла протокола включена в ZIP-архив. Имя архива, содержащего XML-схему, имеет следующий вид: CrsStatusMessageXML_v.RU1.0.zip.
XML-схема протокола включает следующие файлы:
CrsStatusMessageXML_v.RU.1.0.xsd;
isocsmtypes_v1.0.xsd,
где RU.1.0 - номер версии схемы.
Расширение имени файла - xsd.
Все шаблоны XML-документов приведены в кодировке UTF-8.
II. ОПИСАНИЕ ФАЙЛА ОБМЕНА
4. Протокол контроля уведомлений организации финансового рынка о финансовых счетах
Таблица 4.1
CRSStatusMessage_OECD (Протокол контроля OECD)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязательности элемента
Дополнительная информация
Версия
version
А
T(n-)
О
Принимает значение: RU.1.0
Служебная часть
MessageSpec
С
csm:MessageSpec_Type
О
Таблица 4.2
Протокол контроля
CrsStatusMessage
С
csm:CrsStatusMessage
О
Таблица 4.3
Таблица 4.2
MessageSpec (Служебная часть)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязательности элемента
Дополнительная информация
Идентификационный номер финансового учреждения-отправителя
SendingCompanyIN
А
T(=10)
О
ИНН отчитывавшейся организации финансового рынка, которая направила первоначальное Уведомление
Код страны финансового учреждения-отправителя
TransmittingCountry
А
T(=2)
О
ISO 3166-1 Alpha 2 standard.
Принимает значение: RU
Код страны получателя информации
ReceivingCountry
А
T(=2)
О
ISO 3166-1 Alpha 2 standard.
Принимает значение: RU
Тип сообщения
MessageType
А
О
Принимает значение: CRSMessageStatus
Пояснения
Warning
А
xsd:string
Н
Свободный текст, выражающий ограничения на использование информации, содержащейся в сообщении и юридический документ, который это установил
Контактное лицо организации финансового рынка
Contact
А
xsd:string
Н
Вся контактная информация о персонах, ответственных и включенных в процесс передачи данных в этом сообщении, как юридически, так и технически.
Свободный текст, не предназначен для автоматической обработки (заполняется для целей внутренней отчетности, не используется при трансграничной передаче информации)
Уникальный идентификатор сообщения (протокола)
MessageRefId
А
MessageRefIdType
О
Таблица 4.10
Признак сообщения (новое или измененное)
MessageTypeIndic
А
csm:CrsMessageTypeIndic_EnumType
О
Принимает значения: CRSMessageStatus - для рабочего протокола;
Test - для тестового протокола
Отчетный год
ReportingPeriod
А
xsd:date
Н
Дата и время формирования
Timestamp
А
xsd:dateTime
О
Указывается дата и время формирования сообщения
Таблица 4.3
CrsStatusMessage (Протокол контроля)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязательности элемента
Дополнительная информация
Исходное сообщение
OriginalMessage
С
О
Таблица 4.4
Перечень ошибок
ValidationErrors
С
О
Таблица 4.6
Результат контроля
ValidationResult
С
О
Таблица 4.9
Таблица 4.4
OriginalMessage (Исходное сообщение)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязательности элемента
Дополнительная информация
Идентификатор исходного сообщения
OriginalMessageRefID
А
T(0-200)
О
В случае невозможности указания идентификатора исходного сообщения указывается имя файла исходного сообщения
Метаданные
FileMetaData
С
Н
Таблица 4.5
Таблица 4.5
FileMetaData (Метаданные)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязательности элемента
Дополнительная информация
Идентификатор, присвоенный при контроле
CTSTransmissionID
А
T(0-200)
Н
Присваивается при получении уведомления
Дата и время исходного сообщения
SendingTimeStamp
А
xsd:dateTime
Н
По данным Timestamp исходного сообщения
Размер файла исходного сообщения
UncompressedFileSizeKBQty
А
xsd:integer
Н
Не указывается
Таблица 4.6
ValidationErrors (Перечень ошибок)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязательности элемента
Дополнительная информация
Ошибки файла
FileError
С
НМ
Приводятся ошибки, относящиеся к файлу в целом.
Таблица 4.7
Ошибки реквизитов
RecordError
С
НМ
Приводятся ошибки, относящиеся к реквизитам сообщения
Таблица 4.8
ПРИМЕЧАНИЕ. При отсутствии ошибок элементы отсутствуют.
Таблица 4.7
FileError (Ошибки файла)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязательности элемента
Дополнительная информация
Код ошибки
Code
А
T(0-10)
О
В соответствии с Приложением 2 к Протоколу обмена [5] (Прил. 5)
Описание ошибки/
Details/
П
T(0-4000)
Н
Указываются дополнительные пояснения причины ошибки
Язык
Language
А
T(=2)
Н
Принимает значение RU
Таблица 4.8
Ошибки реквизитов (Ошибки файла)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязательности элемента
Дополнительная информация
Код ошибки
Code
А
T(0-10)
О
В соответствии с Приложением 2 к Протоколу обмена [5] (Прил. 5)
Описание ошибки/
Details/
П
T(0-4000)
Н
Указываются дополнительные пояснения причины ошибки
Язык
Language
А
T(=2)
Н
Принимает значение RU
Идентификатор документа
DocRefIDInError
П
T(0-200)
НМ
Идентификатор документа в котором найдена ошибка
Элемент или атрибут
FieldsInError
С
НМ
Элементы или атрибуты, содержащие ошибку
Путь к элементу
FieldPath
А
T(0-400)
О
Путь к элементу, вызывающему ошибку
Таблица 4.9
ValidationResult (Результат контроля)
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Признак обязательности элемента
Дополнительная информация
Результат приема
Status
П
xsd:string
О
Принимает значения:
Accepted - принято;
Rejected - не принято
Версия программы контроля
ValidatedBy
П
T(0-400)
ОМ
Указывается цифрами, разделенными точками
Таблица 4.10
Описание простых типов данных
Наименование элемента
Сокращенное наименование (код) элемента
Признак типа элемента
Формат элемента
Дополнительная информация
Глобально уникальный идентификатор
GUIDType
А
xsd:string
Глобально-уникальный идентификатор (Globally Unique Identifier) - 128-битное число в виде строки из 32 шестнадцатеричных цифр, разделенных дефисами. Например 6F9619FF-8B86-D011-B42D-00CF4FC994FF.
<xs:pattern value="[\da-fA-F]{8}-[\da-fA-F]{4}-[\da-fA-F]{4}-[\da-fA-F]{4}-[\da-fA-F]{12}"/>
Уникальный идентификатор сообщения
MessageRefIdType
А
T(=54)
Имеет структуру MSGGGG-ID-GUID, где: MS префикс протокола контроля;
GGGG - год, к которому относятся данные;
ID - 9965000000 - идентификатор отправителя - ФНС России (10 цифр);
GUID - глобально уникальный идентификатор:
<xsd:pattern value="RU20[0-9]{2}-[0-9]{10}-[\da-fA-F]{8}-[\da-fA-F]{4}-[\da-fA-F]{4}-[\da-fA-F]{4}-[\da-fA-F]{12}"/>
Дата и время
А
xs:dateTime
YYYY-MM-DDTHH:MM:SS