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

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

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

Сокращения

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.1 Общие сведения

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

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

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

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

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

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

- передача уведомления организации финансового рынка о финансовых счетах из ОФР в ФНС России;

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

- передача квитанции о приеме информации и уведомления об отказе в приеме информации из ФНС России в ОФР.

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

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

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

Перечень сообщений приведен в Таблице 1. Описание электронных документов содержится в приложениях.

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 Прием и обработка тестовых сообщений

Прием и обработка тестовых Уведомлений ФС осуществляется в соответствии с требованиями форматов и Протокола обмена.

Наличие сертификата для тестовых Уведомлений ФС является обязательным. Тестовые Уведомления ФС в БД не сохраняются. В Квитанцию о приеме и Уведомление об отказе в приеме дополнительно включается текст: "ТЕСТОВОЕ".

Схемы и экземпляры документов разрабатываются в соответствии со следующими стандартами:

- "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.1.1 Общие сведения

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

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

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

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

- структурный контроль электронного документа;

- форматный контроль электронного документа;

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

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

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

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

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

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

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

- аутентификацию сообщений;

- обеспечение сетевой безопасности при информационном межсетевом взаимодействии.

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

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

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

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

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

- Авторизацию пользователей по паролю;

- Контроль целостности исполняемых файлов;

- Замкнутую программную среду.

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

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

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

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

7.2. Форматы и формы сообщений представлены в следующих документах:

Приложение 1

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

Приложение 2

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

Приложение 3

Форма квитанции о приеме информации.

Приложение 4

Форма уведомления об отказе в приеме информации.

Приложение 5

Протокол контроля уведомлений организации финансового рынка о финансовых счетах.

XML схемы документов прилагаются отдельными файлами.

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. Файлы с содержимым документов и ЭП именуются с использованием универсальных уникальных идентификаторов по формату "<UUID>.bin".

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

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

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

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

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

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

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

3.2.3. UUID в имени файла контейнера представляет собой универсальный уникальный идентификатор, обеспечивающий уникальность имени файла контейнера.

3.2.4. В случае присутствия в контейнере нескольких документов в имени файла транспортного контейнера указывается код основного документа.

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

3.3. Требования к типу документооборота приведены в Приложении 3 к настоящему документу.

4. Типы участников документооборота и их идентификация

4.1. Взаимодействие осуществляется между следующими участниками документооборота.

4.2. Идентификаторы участников документооборота состоят из цифр.

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.1. Назначение

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

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-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 файле. Признак обязательности элемента может принимать следующие значения: "О" - обязательное наличие элемента (наименование элемента и его значение должны присутствовать в файле обмена); "Н" - присутствие элемента необязательно (наименование элемента и его значение в файле обмена могут отсутствовать). Если элемент может принимать ограниченный перечень значений (по классификатору, кодовому словарю и т.п.), то признак обязательности элемента дополняется символом "К". Например: "ОК". В случае если количество реализаций элемента может быть более одной, то признак обязательности элемента дополняется символом "М". Например: "ОМ, ОКМ".

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

Общее описание

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

Уведомление поступает в ФНС России в виде файла - транспортного контейнера (далее именуется контейнер), структура и состав которого определяется приложением 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 и разрешен только авторизованным пользователям. Авторизация производится по сертификату ключа подписи, выданному удостоверяющим центром, аккредитованным в сети доверенных УЦ ФНС России.

Ресурсы и методы сервиса

Сервис предоставляет доступ к следующим ресурсам и методам:

Описание технологии работы

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

Типовая последовательность обработки контейнера с использованием сервиса: (пример сценария использования сервиса приведен в Приложении 1):

- подготовленный контейнер с уведомлением передается на сервер с использованием метода uploadFile();

- состояние обработки контейнера проверяется с использованием метода getFileInfo();

- список ответных документов получается с использованием метода getReplyList();

- файл с ответным документом скачивается с использованием метода downloadReply()

Описание методов

uploadFile() - Отправить новый контейнер

Загружает на сервер подготовленный ранее файл транспортного контейнера

Имя загружаемого файла проверяется на корректность. Это должен быть ZIP-архив с именем, соответствующим формату транспортного контейнера.

Успешный вызов метода

Сообщение об ошибке

getFileInfo() - Получить информацию о результатах обработки

{id} - идентификатор контейнера. Должен состоять из цифр.

Успешный вызов метода

Ответ при отсутствии контейнера по переданному идентификатору

Ответ при некорректном значении {id}

getReplyList() - Получить список ответов на заявку

{id} - идентификатор контейнера. Должен состоять из цифр.

Успешный вызов метода

Поле "STATE" (Описание ответа) может содержать следующие значения:

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

- Сообщение об ошибке

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

Ответ при некорректном значении {id}

downloadReply() - Загрузить с сервера файл с ответом

{id} - идентификатор контейнера. Должен состоять из цифр.

{replyId} - идентификатор ответа (значение ID, возвращаемое методом getReplyList()). Должен состоять из цифр.

Успешный вызов метода

Ответ при отсутствии контейнера по переданному идентификатору

Ответ при некорректном значении {id}/{replyId}

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

getFileList() - Получить список заявок

Возвращает список заявок, отправленных пользователем.

downloadFile() - Загрузить с сервера файл с заявкой

Успешный вызов метода

Ответ при отсутствии контейнера по переданному идентификатору

Ответ при некорректном значении {id}

Подготовленный файл контейнера отправляется с помощью метода 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

Контроль имени файла контейнера осуществляется при загрузке контейнера. Если имя файла не соответствует требованиям, его загрузка не производится.

10 - Заявка поставлена в очередь на обработку

15 - Заявка принята, сформирована квитанция о приеме

95 - Заявка не может быть выполнена

96 - Заявка не может быть выполнена, сформировано уведомление об отказе

98 - Некорректный транспортный контейнер, сформировано сообщение об ошибках;

99 - Некорректный транспортный контейнер

Возможные последовательности изменения состояний:

10 - 15

10 - 95 - 96

10 - 99 - 98