Протокол обмена информацией о финансовых счетах между Федеральной налоговой службой и организациями финансового рынка (версия от 15.02.2022)

Федеральная налоговая служба · № 1167101 от 15.02.2022Действующий акт

Примечание

Текст документа приведен в соответствии с публикацией на сайте https://340fzreport.nalog.ru по состоянию на 14.06.2022.

ПРОТОКОЛ

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

(ВЕРСИЯ ОТ 15.02.2022)

Лист регистрации изменений

Дата выпуска версии	Версия	Описание изменений
23.04.2018	1.0	Создание первой версии документа
31.08.2018	1.1	Доработано Приложение 5 к приложению 2 Протокола обмена в части сообщений при контроле Уведомления ФС
25.03.2019	1.2	Подготовлена версия формата 5.02. Внесены изменения в Приложение 2. Описание технологии сервиса.
15.02.2022	1.3	Внесено изменение в Таблицу 2 «Контактная информация службы поддержки ФНС России»

ТЕРМИНЫ, ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ

Термины и определения

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

Термин	Определение
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 г. № 834-р.

2. Федеральный закон от 27.11.2017 № 340 «О внесении изменений в часть первую Налогового кодекса Российской Федерации в связи с внедрением международного автоматического обмена финансовой информацией в налоговых целях и совершенствованием правил международного налогообложения».

3. Постановление Правительства Российской Федерации от 16.06.2018 № 693 «О реализации международного автоматического обмена финансовой информацией с компетентными органами иностранных государств (территорий)».

4. Стандарт Автоматического обмена информацией о финансовых счетах. Приложение 3 — Руководство пользователя CRS. Версия 2.0

Протокол применяется для реализации электронного обмена данными между компонентами автоматизированных систем ФНС России и ОФР.

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

Информационное взаимодействие осуществляется путем передачи и получения транспортных контейнеров и архивных файлов через сервис, размещенный на сайте ФНС России: https://service.nalog.ru/ofr/fs/index.do.

Взаимодействие осуществляется:

Ручным способом. В этом случае файлы транспортных контейнеров могут создаваться с помощью программного комплекса «Налогоплательщик-ЮЛ» или другого и с помощью интерактивного WEB-сервиса передаваться на сайт ФНС России.
Автоматизированным способом на основе программного интерфейса интеграции с автоматизированной системой ОФР.

2 ОПИСАНИЕ ПОРЯДКА И ПРАВИЛ ВЗАИМОДЕЙСТВИЯ УЧАСТНИКОВ ИНФОРМАЦИОННОГО ОБМЕНА

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

Настоящий документ устанавливает технические требования к организации информационного взаимодействия между ФНС России и ОФР.

Информационное взаимодействие осуществляется с использованием сервиса, размещенного на сайте ФНС России. Инициатором передачи и получения данных является ОФР.

Автоматизированные информационные системы ФНС России и ОФР, используемые в работе при обмене информацией, должны удовлетворять требованиям настоящего документа.

В качестве технологии удаленного вызова процедур используется архитектурный стиль REST (Representational state transfer). Для передачи сообщений используется протокол HTTPS.

Каждый из участников взаимодействия (ФНС России и ОФР) самостоятельно разрабатывает клиентскую и серверную части программного обеспечения, реализующего требования настоящего Протокола.

В ходе информационного взаимодействия между ФНС России и ОФР реализуются следующие процессы:

передача уведомления организации финансового рынка о финансовых счетах из ОФР в ФНС России;
передача уведомления об использовании права не представлять информацию по ранее заключенным договорам с клиентами — юридическими лицами с остатком средств менее или равным 250 тысяч долларов США (далее — Уведомление-250);
передача квитанции о приеме информации и уведомления об отказе в приеме информации из ФНС России в ОФР.

Срок представления Уведомления-250 за 2017 отчетный период — 31.12.2020.

Срок представления Уведомления-250 за 2018 отчетный период — 31.12.2021.

В качестве кода информационного обмена, позволяющего однозначно идентифицировать принадлежность сообщения к обмену в рамках настоящего Протокола, используется буквенный код 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_<ИНН><КПП>__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-документе обязательно присутствие объявления документа:

4 ПОРЯДОК ОСУЩЕСТВЛЕНИЯ КОНТРОЛЯ ЭЛЕКТРОННЫХ ДОКУМЕНТОВ

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

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

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

4.1.2 Правила контроля электронных документов

Контроль электронного документа осуществляется в несколько этапов:

структурный контроль электронного документа;
форматный контроль электронного документа;
логический контроль электронного документа.

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

На этапе форматного контроля выполняется проверка корректности заполнения полей электронного документа согласно форматам, установленным нормативными документами ФНС России и данным протоколом.

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

Контроль документов в формате PDF не производится.

5 ПОРЯДОК ОБЕСПЕЧЕНИЯ ЦЕЛОСТНОСТИ И АУТЕНТИФИКАЦИИ ПЕРЕДАВАЕМОЙ ИНФОРМАЦИИ

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

защиту от несанкционированного доступа (далее — НСД) к средствам вычислительной техники (СВТ), задействованным при информационном взаимодействии;
аутентификацию сообщений;
обеспечение сетевой безопасности при информационном межсетевом взаимодействии.

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

Защита от несанкционированного доступа

Защита от несанкционированного доступа к средствам вычислительной техники выполняется как организационными, так и техническими средствами:

СВТ, которые задействуются в процессе передачи информации, должны размещаться в отдельных помещениях, доступ в которые разрешен только обслуживающему персоналу.
СВТ, которые задействуются в процессе передачи информации, могут дополнительно оснащаться сертифицированными средствами защиты информации (СЗИ) от НСД, обеспечивающими:
Авторизацию пользователей по паролю;
Контроль целостности исполняемых файлов;
Замкнутую программную среду.

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

6 ПОРЯДОК И ОСОБЕННОСТИ ДЕЙСТВИЯ СТОРОН ВО ВНЕШТАТНЫХ СИТУАЦИЯХ

В ходе обмена информацией между ОФР и ФНС России возможны ситуации, когда обработка данных не может быть произведена в обычном режиме. В частности, это может произойти при возникновении технических сбоев, ошибок структурного и форматно-логического контроля и др.

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

Таблица 2

Контактная информация службы поддержки ФНС России

Телефон	Адрес электронной почты
8(495) 913-0000 (29-49)	aeoi@tax.gov.ru g.glehyan@tax.gov.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;

- файлы с содержимым передаваемых ЭП.

3.1. Содержимое транспортного контейнера

Рисунок 1: Схема транспортного контейнера

3.1.1. Файлы с содержимым документов и ЭП именуются с использованием универсальных уникальных идентификаторов по формату «.bin».

3.1.2. Формат описания транспортной информации приведен в Приложении 1 к настоящему документу.

3.1.3. Файл с транспортной информацией и файлы с содержимым документов и ЭП объединяются в ZIP-архив в режиме STORE. Файл с транспортной информацией при передаче в транспортном контейнере не сжимается и не шифруется.

3.1.4. В одном транспортном контейнере передаются документы и ЭП, относящиеся к одной транзакции.

Транспортный контейнер может содержать не более 2500 файлов. Размер транспортного контейнера не должен превышать 72 мегабайт, а размер любого файла в контейнере не должен превышать 60 мегабайт. Исходный объем файла, zip-архив которого содержится в контейнере, не должен превышать 1024 мегабайт.

3.2. Имя файла транспортного контейнера

3.2.1 Транспортный контейнер передается в виде файла с уникальным именем по формату

CRS_<идентификатор отправителя><идентификатор получателя><код типа документооборота><код типа транзакции>_<код типа документа>.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 № 173-ФЗ «Об особенностях осуществления финансовых операций с иностранными гражданами и юридическими лицами, о внесении изменений в Кодекс Российской Федерации об административных правонарушениях и признании утратившими силу отдельных положений законодательных актов Российской Федерации», имеющая ЭП, выданную в одном из удостоверяющих центров, входящих в сеть доверия ФНС России
ФНС	ФНС России

Условное обозначение

Описание

ОФР

Организация финансового рынка в соответствии с частью 1 статьи 2, а также частями 1, 2, 3 и 4 статьи 3 Федерального закона от 28.06.2014 № 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. Шифрование документов, передаваемых в составе первичного транспортного контейнера, должно производиться в адрес открытых ключей сертификатов получателя, указанных для шифрования, и открытых ключей сертификатов отправителя. Шифрование документов, передаваемых в результате приема или обработки поступившего документа, производится в адрес открытых ключей сертификатов получателя, указанных для шифрования, открытых ключей сертификатов отправителя и открытых ключей сертификатов должностных лиц, подписавших поступивший документ.

Приложение № 1

ФОРМАТ
ПЕРЕДАЧИ СВЕДЕНИЙ ОПИСАНИЯ ТРАНСПОРТНОЙ ИНФОРМАЦИИ
(ВЕРСИЯ 01)

1. ОБЩИЕ СВЕДЕНИЯ

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

Настоящий документ описывает требования к XML файлам передачи в электронном виде сведений транспортной информации.

2. ОПИСАНИЕ ФАЙЛА ОБМЕНА

2.1. Общие сведения по файлу обмена

Имя файла обмена должно иметь следующий вид:

packageDescription

Расширение имени файла — xml. Расширение имени файла может указываться как строчными, так и прописными буквами.

Параметры первой строки файла обмена

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

Имя файла, содержащего схему файла обмена

Имя файла, содержащего XSD схему файла обмена, должно иметь следующий вид:

CRS_TK_xx, где xx — текущая версия схемы.

Расширение имени файла — xsd.

2.2. Логическая модель файла обмена

Логическая модель файла представлена в графическом виде в Разделе 3 на рис. 1. Элементами логической модели файла обмена являются элементы и атрибуты XML файла. Полный перечень структурных элементов логической модели файла и сведения о них приведены в Разделе 4.

Для каждого структурного элемента логической модели файла в Разделе 4 приводятся следующие сведения:

Наименование элемента. Приводится полное наименование элемента.
Сокращенное наименование элемента. Приводится сокращенное наименование элемента. Сокращенные наименования могут записываться буквами и цифрами.
Признак типа элемента. Может принимать следующие значения: «С» — сложный элемент (имеющий вложенные), «П» — простой элемент (не имеющий вложенных); А — атрибут. Если для определения элемента используется пользовательский тип данных, наименование типа данных (типового элемента) указывается в графе «Дополнительные сведения».
Формат элемента. Формат <1> представляется в условных обозначениях, которым соответствуют следующие значения: T — символьная строка; N — числовое значение (целое или дробное).

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

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

| — метасимвол, означающий возможность выбора среди нескольких вариантов значений элемента металингвистической структуры.

Формат символьной строки указывается в виде T(n-k) или T(=k), где n — минимальное количество знаков в строке, k — максимальное количество знаков, символ «-» — разделитель, символ «=» означает фиксированное количество знаков в строке. В случае, если минимальное количество знаков равно 0, формат имеет вид T(0-k). В случае, если максимальное количество знаков неограниченно, формат имеет вид T(n-). В случае, если элемент неопределенной длины, формат имеет вид T.

Формат числового значения указывается в виде N(m.k), где m — максимальное количество знаков в числе, включая знак (для отрицательного числа), целую и дробную часть числа без разделяющей десятичной точки, а k — максимальное число знаков дробной части числа. Если число знаков дробной части числа равно 0 (т.е. число целое), то формат числового значения имеет вид N(m).

Для простых элементов, являющихся базовыми в XML (определенными в http://www.w3.org/TR/xmlschema-0), например, элемент с типом «date», поле «Формат элемента» не заполняется. Для таких элементов в поле «Дополнительная информация» указывается тип базового элемента.

Признак обязательности элемента определяет обязательность наличия элемента в XML файле. Признак обязательности элемента может принимать следующие значения: «О» — обязательное наличие элемента (наименование элемента и его значение должны присутствовать в файле обмена); «Н» — присутствие элемента необязательно (наименование элемента и его значение в файле обмена могут отсутствовать). Если элемент может принимать ограниченный перечень значений (по классификатору, кодовому словарю и т.п.), то признак обязательности элемента дополняется символом «К». Например: «ОК». В случае если количество реализаций элемента может быть более одной, то признак обязательности элемента дополняется символом «М». Например: «ОМ, ОКМ».
Дополнительная информация. Для сложных элементов указывается ссылка на таблицу, в которой описывается состав данного элемента. Для элементов, принимающих ограниченный перечень значений из классификатора (кодового словаря и т.п.), указывается соответствующее наименование классификатора (кодового словаря и т.п.) или приводится перечень возможных значений. Для классификатора (кодового словаря и т.п.) может указываться ссылка на его местонахождение. Для элементов, использующих пользовательский тип данных, указывается наименование типового элемента.

3. ДИАГРАММА ФАЙЛА ОБМЕНА

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)
	Версия передающей программы	ВерсПрог	А	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, в зависимости от того, зашифровано или нет содержимое документа в контейнере
Идентификатор документа	идентификаторДокумента	А	T(=32)	О	Универсальный уникальный идентификатор документа (UUID)
Исходное имя файла документа	исходноеИмяФайла	А	T(1-150)	О	Элемент обязателен, в случае, если исходное имя файла определено Имя файла указывается с расширением
	Содержимое документа	содержимое	С		О
Сведения ЭЦП	подпись	С		О	Состав элемента представлен в табл. 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 формой:

Метод в случае успешного завершения возвращает:

{"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	идентификаторСубъекта отличается от указанного в имени файла	Описание транспортной информации: узел отправитель: некорректный идентификаторСубъекта
Проверка реквизитов отправителя в packageDescription.xml	210	типСубъекта отличается от "ОФР"	Описание транспортной информации: узел отправитель: некорректный типСубъекта
Проверка реквизитов получателя в packageDescription.xml	211	идентификаторСубъекта отличается от 9965	Описание транспортной информации: узел получатель: некорректный идентификаторСубъекта
Проверка реквизитов получателя в packageDescription.xml	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	Присутствует остаток на счете (AccountBalance) при закрытом счете	Присутствует остаток на счете (AccountBalance) при закрытом счете
60005	Если владельцем счета является организация, а "Тип владельца счета" (AccountHolder Type) - CRS102 или CRS103, то "Тип контролирующего лица" (Controlling Person Type) должен отсутствовать. (CRS102 = подотчетное лицо; CRS103 = Пассивная нефинансовая организация, являющаяся подотчетным лицом)	Тип контролирующего лица (Controlling Person Type) должен отсутствовать
60006	При наличии заполнения Organisation (владельцем счета является организация), и "Тип владельца счета" (Account Holder Type) - CRS101, элемент ControllingPerson должен присутствовать.	Отсутствует контролирующее лицо ControllingPerson
60014	Дата рождения (BirthDate) не должна быть ранее 1900 г. или позднее даты, указанной в элементе <Отчетный год>	Дата рождения (BirthDate) не должна быть ранее 1900 г. или позднее даты, указанной в элементе <Отчетный год>
60015	Блок данных AccountReport может быть не заполнен, только если осуществляется корректировка или удаление группы данных ReportingFI. Если ReportingFI содержит новые данные или является повторной отправкой, то блок данных AccountReport должен быть заполнен.	Некорректный AccountReport
60016	В случае если в блоке данных по владельцу счета указано физическое лицо, блок данных по контролирующему лицу не должен быть заполнен и присутствовать в схеме отчета	Заполнен Блок данных "Контролирующее лицо" (ControllingPerson)
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 в одном сообщении
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
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)	При MessageTypeIndic = CRS701, 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	Есть реквизиты, в содержании которых имеются буквы на русском регистре	Не допускается использование русских букв <наименование реквизита> <значение реквизита>
98028	При наличии у ОФР актуальных счетов за указанный период, отчет об отсутствии сведений (MessageTypeIndic = CRS703) не принимается	The message about absence of the reporting, is not accepted. The organization has current accounts
98028		(Сообщение об отсутствии отчетности не принято. У организации есть актуальные счета)
98031	Ошибка проверки по схеме	Ошибка проверки по схеме
98032	Реквизит не прописан в схеме	Реквизит не прописан в схеме
98033	Отсутствует обязательный реквизит	Отсутствует обязательный реквизит
98034	Реквизит не может принимать множественные значения	Реквизит не может принимать множественные значения
98035	Ошибка длины реквизита	Ошибка длины реквизита
98036	В уведомлении CRS_UV250 если отчетный период ReportingPeriod = 2017, то срок предоставления до 31.12.2020. Если отчетный период ReportingPeriod = 2018, то срок предоставления до 31.12.2021 Для других отчетных периодов данное уведомление не предусмотрено.	Нарушен срок представления уведомления
98037	Если / = 1.1 \| 1.2, то <Individual/TIN/ReasonCodeInd> = (02 \| 03 \| 04 \| 05 \| 06\| 10\| 22).	Некорректное значение ReasonCodeInd (TIN)
98037	Если / = 2.0, то <Individual/TIN/ReasonCodeInd> = (02 \| 03 \| 04 \| 05 \| 06\| 10)	Некорректное значение ReasonCodeInd (TIN)
98038	Информация о рождении физического лица (BirthInfo).	Информация о рождении физического лица должна присутствовать
	Элемент обязателен при = 1.1 \| 1.2 и если <Individual/ReasonCodeInd> \neq 21 \| 23
	Элемент обязателен, если = 2.0
98039	ИНН (TINRus). Элемент обязателен, если <Individual/ReasonCodeInd> \neq 11 \| 12 \| 13	ИНН (TINRus) должен присутствовать
98040	Подтверждение достоверности расхождения (ConfirmCountryCode) обязательно, если ни одно из значений <ResCountryCode> не равно значению <CountryCode> в Address (Адрес)	Подтверждение достоверности расхождения должно присутствовать, если код страны адреса не совпадает с кодом страны резиденства
98041	Код причины непредставления налогового идентификационного номера и даты рождения клиента физического лица (Individual/ReasonCodeInd). Элемент обязателен при отсутствии хотя бы одного из элементов <TINRus> \| <BirthInfo>	Код причины непредставления ИНН и даты рождения клиента ФЛ должен присутствовать
98042	Описание причины непредставления налогового идентификационного номера клиента (ReasonDescription). Элемент обязателен:	Описание причины непредставления налогового идентификационного номера клиента должно присутствовать
	- для ФЛ, если <ReasonCodeInd> = 10;
	- для ЮЛ, если <ReasonCodeEnt> = 09
98044	Если = 1.1 \| 1.2, то <Organisation/IN/ReasonCodeEnt> = (\| 02 \| 03 \| 04\| 05\| 09\| 13).	Некорректное значение <ReasonCodeEnt> (IN)
98044	Если = 2.0, то <Organisation/IN/ReasonCodeEnt> = (02 \| 03 \| 04\| 05\| 09)	Некорректное значение <ReasonCodeEnt> (IN)
98045	ИНН (Organisation/TINRus). Элемент обязателен, если <Organisation/ReasonCodeEnt> \neq 10\| 11\| 12	ИНН (TINRus) должен присутствовать
98046	Если TIN отсутствует, то принимает значение "XX", при условии, что элемент <ReasonCodeInd> (Таблица 4.12) = 02 \| 03 \| 04 \| 05 \| 06 \| 10 \| 22	TIN должен иметь значение "XX" при условии, что элемент <ReasonCodeInd> = 02 \| 03 \| 04 \| 05 \| 06 \| 10 \| 22
98047	Если IN отсутствует, то принимает значение "XX", при условии, что элемент <ReasonCodeEnt> (Таблица 4.17) = 02 \| 03 \| 04 \| 05 \| 09 \| 13	IN должен иметь значение "XX" при условии, что элемент <ReasonCodeEnt> = 02 \| 03 \| 04 \| 05 \| 09 \| 13
98048	Элемент <ReasonCodeEnt> (Organisation/ReasonCodeEnt) заполняется в случае, если <TINRus> отсутствует, и может принимать только значения = 10 \|11 \| 12	Некорректное значение <ReasonCodeEnt> (Organisation)
98049	Элемент <ReasonCodeInd> (Individual/ReasonCodeInd) заполняется в случае, если отсутствует хотя бы один из элементов: TINRus или BirthInfo, и может принимать только значения = 11 \| 12 \| 13 \| 21 \| 23 \|	Некорректное значение <ReasonCodeInd> (Individual)
98050	Повторное предоставление файла с одинаковым именем	Повторное предоставление файла <Имя файла>
98051	Дата ранее 01.01.1900 или больше текущей	Ошибка даты <Имя реквизита> <Значение реквизита>
98052	Элемент Код страны ResCountryCode (Individual) отсутствует в справочнике ОКСМ или равен "XX" при <UndocumentedAccount> = <false>. Для ResCountryCode (Organisation) отсутствует в справочнике ОКСМ или равен "XX" при <UndocumentedAccount> = <false>.	ResCountryCode отсутствует в справочнике ОКСМ или код "XX" применен для счета, который не является незадокументированным
98053	Если TIN \neq "XX", то TypeIdn (Таблица 4.12) должен быть заполнен	TypeIdn должен присутствовать
98054	Если IN \neq "XX", то TypeIdn (Таблица 4.17) должен быть заполнен	TypeIdn должен присутствовать
98055	Если TypeIdn = 1 и issuedBy (Код страны) (таблица 4.12) присутствует в справочнике "Структура TIN физических лиц для отдельных юрисдикций" (StructureTIN), то TIN должен соответствовать шаблону этого справочника.	TIN должен соответствовать Справочнику "Структура TIN физических лиц для отдельных юрисдикций" (StructureTIN)
98056	Если TypeIdn = 3 и issuedBy (Код страны) (таблица 4.12) присутствует в справочнике "Структура иного идентификатора физических лиц для отдельных юрисдикций" (StructureOtherIN), то TIN должен соответствовать шаблону этого справочника.	TIN должен соответствовать Справочнику "Структура иного идентификатора физических лиц для отдельных юрисдикций" (StructureOtherIN)
98057	Если TypeIdn = 1 и INType < > "GIIN" и issuedBy (Код страны) (таблица 4.17) присутствует в справочнике "Структура IN юридических лиц для отдельных юрисдикций" (StructureIN), то IN должен соответствовать шаблону этого справочника.	IN должен соответствовать Справочнику "Структура IN юридических лиц для отдельных юрисдикций" (StructureIN)
98058	Указание значения XX не допускается в элементе Код страны (CountryCode), (CountryInfo (Информация о стране рождения физического лица) Таблица 4.15 и Address (Адрес) Таблица 4.19).	Указание значения "ХХ" не допускается в элементе <CountryCode> блока элементов <CountryInfo>
98059	Если = "1.2" \| "2.0", то <UndocumentedAccount> = <false> Важно! Применяется начиная с Отчетного периода 2022 года и далее (ReportingPeriod = 2022 и более)	Некорректное значение UndocumentedAccount для новых договоров (= 1.2 \| 2.0)
98060	Если счет закрыт (атрибут <ClosedAccount>= <True>), то признак принудительно закрытого договора (счета или его аналога) (<ClosedAccountEnforced>) должен быть заполнен	При наличии атрибута <ClosedAccount> атрибут <ClosedAccountEnforced> должен быть заполнен
98061	Если = "1.2" \| "2.0", то <DormantAccount> = <false>	Некорректное значение DormantAccount для новых договоров (= 1.2 \| 2.0)
98062	Только для счетов ФЛ (AccountHolder/Individual) и при AcctNumberType/AccountNumber \neq OECD603\|OECD604 (Таблица 4.9). Если (кроме значения "NANUM") и <DateOpen> встречается в файле CRS (за один и тот же отчетный период) ДВА И БОЛЕЕ РАЗА, то атрибут <JointAccount> должен быть = <True>	Некорректное значение JointAccount или дублирование счета клиента в одном файле
98063	Элемент может принимать значение 1.2 \| 2.0 только при условии, если значение в элементе <DateOpen> равно или больше (позднее) "20.07.2018"	Некорректное значение в элементе <DateOpen> для новых договоров (= 1.2 \| 2.0)
98064	Вид договора (счета или его аналога) (AcctContractType) принимает значение согласно Справочнику "Вид договора об оказании финансовых услуг"	должен соответствовать Справочнику "Вид договора об оказании финансовых услуг"
98064	Важно! элемент является обязательным начиная с Отчетного период 2022 и далее (ReportingPeriod = 2022 и более)
98065	Элемент <DueDilThirdPartyInfo> обязателен, если элемент <DueDilThirdParty> (Таблица 4.10) = "1"	Элемент <DueDilThirdPartyInfo> обязателен, если элемент <DueDilThirdParty> = "1"
98066	Элемент <ResCountryCode> не может быть равен только "RU"	Элемент <ResCountryCode> не может быть равен только "RU"
98067	Элемент <ResCountryCode> может принимать значение "XX" только в случае, если счет является незадокументированным (<UndocumentedAccount> = <True>).	Элемент <ResCountryCode> может быть равен "XX" только если счет является незадокументированным
98068	Если элемент <RequestOffshoreResult> = 01 \| 02 \| 03 \| 04, то в элементе <ResCountryCode> в дополнение к коду AE \| AG \| BS \| BB \| BH \| CY \| DM \| GD \| ME \| MT \| KN \| LC \| PA \| SC \| TC \| VU должен быть указан также код какой-либо иной страны (кроме XX \| ZZ)	Некорректное значение <ResCountryCode> при <RequestOffshoreResult> = 01 \| 02 \| 03 \| 04
98069	Элемент <DUL> обязателен, если <TIN> = "XX" и элемент <TINRus> не заполнен Важно! Применяется начиная с Отчетного период 2022 года и далее (ReportingPeriod = 2022 и более)	Иностранный документ, удостоверяющий личность, обязателен, если <TIN> = "XX" и элемент <TINRus> не заполнен
98071	Элемент <ResCountryCode> (Organisation) может принимать значение "XX" только в случае, если счет является незадокументированным UndocumentedAccount = <True>.	Элемент <ResCountryCode> равен "XX", только если счет незадокументированный
98073	Если TIN \neq "XX", то Код страны <issuedBy> указывается обязательно. Значение атрибута Код страны <issuedBy> должно совпадать со значением хотя бы одного из кодов, указанных в элементе "ResCountryCode" (кроме RU \| XX \| ZZ)	Некорректное значение Кода страны <issuedBy> для элемента <TIN>
98074	Атрибут <ReasonCodeInd> обязателен, если элемент <TIN> (Таблица 4.12) = "XX".	Атрибут <ReasonCodeInd> обязателен, если элемент <TIN> = XX.
98075	Элемент <RequestResult> (Таблица 4.12) обязателен при выполнении хотя бы одного из следующих условий: - элемент <ReasonCodeInd> (Таблица 4.12) = "10"; - элемент <TIN> (Таблица 4.12) = "XX"; - атрибут "Undocumented Account" (Таблица 4.9) = <true>.	Элемент <RequestResult> обязателен, если <ReasonCodeInd> = "10"\| <TIN> = "XX"\| атрибут "Undocumented Account" = <true>
98076	Элемент <RequestOffshoreResult> обязателен, если <ResCountryCode> (Таблица 4.11) = AE \| AG \| BS \| BB \| BH \| CY \| DM \| GD \| ME \| MT \| KN \| LC \| PA \| SC \| TC \| VU	Элемент <RequestOffshoreResult> обязателен, если <ResCountryCode> = AE \| AG \| BS \| BB \| BH \| CY \| DM \| GD \| ME \| MT \| KN \| LC \| PA \| SC \| TC \| VU
98076	Важно! Если элемент <RequestOffshoreResult> (Таблица 4.12) заполнен хотя бы для одного из элементов <TIN/issuedBy> (Таблица 4.12) = AE \| AG \| BS \| BB \| BH \| CY \| DM \| GD \| ME \| MT \| KN \| LC \| PA \| SC \| TC \| VU, то ошибка по коду 98076 не выдается.
98077	Элемент <TranslitType> (Таблица 4.13) может принимать значение "4" только в случае, если = 1.1 \| 1.2 Элемент <TranslitType> (Таблица 4.18) может принимать значение "4" только в случае, если = 1.1 \| 1.2	Некорректное значение <TranslitType>
98078	Элемент <TranslitType> является обязательным для новых договоров (= "2.0"). Важно! Применяется начиная с отчетного периода 2022 года и далее (ReportingPeriod = 2022 и более)	Элемент <TranslitType> является обязательным для применения в отношении счетов с признаком = "2.0" начиная с отчетного периода 2022 года
98079	При наличии у ОФР актуальных счетов за указанный период (т.е. в предыдущем периоде были счета без признака <ClosedAccount>), отчет об отсутствии сведений (MessageTypeIndic = CRS703) не принимается	Сообщение об отсутствии отчетности не принято. У организации есть актуальные (незакрытые) счета
98081	Элемент <ReasonCodeEnt> обязателен, если отсутствует элемент <TINRus>	Элемент <ReasonCodeEnt> обязателен, если отсутствует элемент <TINRus>
98082	Элемент <RequestResult> (Таблица 4.17) обязателен при выполнении хотя бы одного из следующих условий: - элемент <ReasonCodeEnt> = "09" (Таблица 4.17) - элемент <IN> = "XX" (Таблица 4.17) - атрибут "Undocumented Account" (Таблица 4.9) = <true>	Элемент RequestResult обязателен, если <ReasonCodeEnt> = "09", <IN> = "XX", "Undocumented Account" = <true>
98083	Элемент <NameEntEng> (NameOrg Таблица 4.18) обязателен, если элемент <TranslitType> = "1" \| "2".	Наименование организации на английском языке (<NameEntEng>) обязательно, если элемент <TranslitType> = "1" \| "2".
98084	Элемент <NameEntTranslit> (NameOrg Таблица 4.18) обязателен, если элемент <TranslitType> = "3" \| "4".	Наименование организации на латинице (<NameEntTranslit>) обязательно, если элемент <TranslitType> = "3" \| "4".
98085	Хотя бы один из элементов <NameEntEng>, <NameEntTranslit> должен быть заполнен	Хотя бы один из элементов <NameEntEng>, <NameEntTranslit> должен быть заполнен
98086	При элементе <ResCountryCode>, равном одному значению, элемент <ReasonCodeInd> (Таблица 4.12 TIN) не может принимать значение "02", если элемент <ResCountryCode> = AD \| AI \| AL \|AR \| AT \| AU \| AZ \| BB \| BE \| BG \| BR \| BZ \| CA \| CH \| CK \| CL \| CN \| CO \| CR \| CW \| CY \| CZ \| DE \| DK \| DM \| EC \| EE \| ES \| FI \| FO \| FR \| GB \| GG \| GH \| GI \| GL \| GN \| GR \| HK \| HR \| HU \| ID \| IE \| IL \| IM \| IN \| IS \| IT \| JE \| JP \| KN \| KR \| KW \| KZ \| LB \| LC \| LI \| LT \| LU \| LV \| MO \| MT \| MU \| MV \| MX \| MY \| NL \| NO \| NR \| NZ \| PA \| PE \| PK \| PL \| PT \| QA \| RO \| SA \| SC \| SE \| SG \| SI \| SK \| SM \| TR \| UY \| VC \| VU \| WS \| ZA	Некорректное заполнение <ReasonCodeInd> Законодательство/административная практика страны, код которой указан в <ResCountryCode>, предусматривает выдачу TIN или его функционального аналога физическим лицам
98087	При элементе <ResCountryCode>, равном одному значению, элемент <ReasonCodeInd> (Таблица 4.12 TIN) не может принимать значение "03", если элемент <ResCountryCode> = BE \| BG \| BR \| CH \| \| CZ \| DE \| FI \| FO \| GG \| HK \| HR \| HU \| IE \| IL \| IM \| JE \| JP \| KW \| LI \| LT \| LU \| LV \| MT \| NO \| NL \| NO \| PA \| PL \| SE \| SG \| SM \| TR \| UY \| VU	Некорректное заполнение <ReasonCodeInd>. Компетентный орган страны, код которой указан в <ResCountryCode>, автоматически присваивает TIN или его функциональный аналог физическим лицам
98088	При элементе <ResCountryCode>, равном одному значению, элемент <ReasonCodeEnt> (Таблица 4.17, IN) не может принимать значение "02" \| "04", если элемент <ResCountryCode> = AU \| AT \| AZ \| BR \| CH \| CN \| CZ \| DE \| EE \| ES \| FI \| FR \| GB \| ID \| IE \| IL \| IN \| IT \| JP \| KR \| LV \| MT \| NL \| PL \| SE \| SG \| ZA	Некорректное заполнение <ReasonCodeEnt>. Законодательство/административная практика страны, код которой указан в <ResCountryCode>, предусматривает выдачу IN/TIN организациям, в т.ч. номер регистрации (инкорпорации)
98089	При элементе <ResCountryCode>, равном одному значению, элемент <ReasonCodeEnt> (Таблица 4.17, IN) не может принимать значение "03" \| "05", если элемент <ResCountryCode> = AU \| AT \| AZ \| BR \| CH \| \| CZ \| DE \| EE \| ES \| FI \| FR \| GB \| ID \| IE \| IL \| IN \| IT \| JP \| KR \| LV \| MT \| NL \| PL \| SE \| SG \| ZA	Некорректное заполнение <ReasonCodeEnt>. Компетентный орган страны, код которой указан в <ResCountryCode>, автоматически присваивает IN/TIN организациям, в т.ч. номер регистрации (инкорпорации)
98090	Если <TINRus> заполнен, то <ReasonCodeEnt> (Organisation/ReasonCodeEnt) должен отсутствовать	<ReasonCodeEnt> должен отсутствовать
98091	Если TINRus и BirthInfo заполнены, то элемент <ReasonCodeInd> (Individual/ReasonCodeInd) должен отсутствовать	<ReasonCodeInd> должен отсутствовать
98092	Хотя бы один из элементов <CountryInfo>, <City> должен быть заполнен, если = 1.1 \| 1.2 и <ReasonCodeInd> \neq 21\| 23 или	Хотя бы один из элементов <CountryInfo>, <City> должен быть заполнен
	если = 2.0
	Контроль перестает действовать начиная с отчетного периода 2022 года, т.е. со сроком сдачи отчетности до 31.05.2023 года
98093	Если реквизиты, в содержании которых имеются буквы на русском регистре	Не допускается использование русских букв <наименование реквизита> <значение реквизита>
99999	Полученное сообщение содержит ошибку, для которой отсутствует определенный код.	Неустановленная ошибка. Детализация должна указать содержание ошибки

ПРИМЕЧАНИЯ:

<*> Не выполняются при проверке тестовых сообщений. Тестовые сообщения на корректировку и удаление тестовых данных на наличие первичного тестового Уведомления не проверяются.

Коды ошибок приняты в соответствии с "Common Reporting Standard status Message XML Schema: User Guide for Tax Administrations. Part B. CRS Status Message Error Codes". OECD 2017.

Приложение 3

Код по КНД 1167101

Квитанция о приеме

Получатель документа: ФНС России

Подтверждает, что принял дд.мм.гггг

Документ в электронном виде

                     (наименование документа)

наименование файла

направленный дд.мм.гггг в чч.мм.сс

Отправитель документа:

                (наименование организации, ИНН/КПП)

Уполномоченный представитель
организации /___________________/
Ф.И.О.

Приложение 4

Код по КНД 1167102

Уведомление об отказе в приеме

Получатель документа: ФНС России

Уведомляет, что отправитель документа:

                (наименование организации, ИНН/КПП)

дд.мм.гггг в чч.мм.сс направил документ (транспортный контейнер)

                       (наименование файла)

Данный документ (транспортный контейнер) не принят.

Причины отказа:

                     (описание причин отказа)

Уполномоченный представитель
организации /___________________/
Ф.И.О.

Приложение 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-k) или T(=k), где: n — минимальное количество знаков, k — максимальное количество знаков, символ «-» — разделитель, символ «=» означает фиксированное количество знаков в строке. В случае, если минимальное количество знаков равно 0, формат имеет вид T(0-k). В случае, если максимальное количество знаков неограниченно, формат имеет вид T(n-).

Формат числового значения указывается в виде N(m.k), где: m — максимальное количество знаков в числе, включая знак (для отрицательного числа), целую и дробную часть числа без разделяющей десятичной точки, k — максимальное число знаков дробной части числа. Если число знаков дробной части числа равно 0 (т.е. число целое), то формат числового значения имеет вид N(m).

признак обязательности элемента определяет обязательность присутствия элемента (совокупности наименования элемента и его значения) в файле обмена. Признак обязательности элемента может принимать следующие значения: «О» — наличие элемента в файле обмена обязательно; «Н» — присутствие элемента в файле обмена необязательно, т.е. элемент может отсутствовать. Если элемент принимает ограниченный перечень значений (по классификатору, кодовому словарю и т.п.), то признак обязательности элемента дополняется символом «К». Например: «ОК». В случае, если количество реализаций элемента может быть более одной, то признак обязательности элемента дополняется символом «М». Например: «НМ», «ОКМ».

К вышеперечисленным признакам обязательности элемента может добавляться значение «У» в случае описания в XML схеме условий, предъявляемых к элементу в файле обмена, описанных в графе «Дополнительная информация». Например: «НУ», «ОКУ»;

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

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

3. Имя файла протокола должно иметь следующий вид:

Имя файла протокола формируется на основе имени файла Уведомления ФС и должно иметь следующий вид: RR

.xml, где:

RR — префикс, принимающий значения: KV — для Квитанции о приеме; UV — для Уведомления об отказе в приеме;

P — имя файла поступившего Уведомления ФС без расширения.

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

Схема файла протокола включена в 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	С		О
Перечень ошибок	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	С		НМ
Ошибки реквизитов	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