ФЕДЕРАЛЬНАЯ НАЛОГОВАЯ СЛУЖБА

ПРИКАЗ

от 23 января 2012 года N ММВ-7-6/17@

     
О внесении изменений в приказ ФНС России от 09.11.2010 N ММВ-7-6/535@

В целях обеспечения унификации информационного взаимодействия в электронном виде между налогоплательщиками и налоговыми органами по телекоммуникационным каналам связи с использованием электронной подписи и в соответствии с приказом ФНС России от 05.04.2010* N ММВ-7-6/773@ "Об утверждении Формата документов, используемых налоговыми органами при реализации своих полномочий в отношениях, регулируемых законодательством о налогах и сборах", приказом ФНС России от 25.10.2010 N ММВ-7-3/515@ "Об утверждении Порядка уведомления банком налогового органа о факте выдачи банковской гарантии" и приказом ФНС России от 09.06.2011 N ММВ-7-6/362@ "Об утверждении форм и форматов сообщений, предусмотренных пунктами 2 и 3 статьи 23 Налогового кодекса Российской Федерации, а также порядка заполнения форм сообщений и порядка представления сообщений в электронном виде по телекоммуникационным каналам связи"

________________

* Вероятно, ошибка оригинала. Следует читать "от 28.12.2010". - Примечание изготовителя базы данных.

приказываю:

1. Внести в Унифицированный формат транспортного контейнера при информационном взаимодействии с приемными комплексами налоговых органов по телекоммуникационным каналам связи с использованием электронной подписи, утвержденный приказом ФНС России от 09.11.2010 N ММВ-7-6/535@, изменения согласно приложению к настоящему приказу.

2. Контроль за исполнением настоящего приказа возложить на заместителя руководителя Федеральной налоговой службы А.С.Петрушина.

Руководитель
Федеральной налоговой службы
М.В.Мишустин

УТВЕРЖДЕН
приказом ФНС России
от 23 января 2012 года
N ММВ-7-6/17@

     

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

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

1.1. Электронный документ (документ) - документ, представленный в электронном виде, в соответствии с требованиями формата для данного типа документа.

1.2. Транзакция - единичный шаг передачи контейнера с документами и ЭП в рамках документооборота определенного типа, который определяет набор передаваемых документов, ЭП, их отправителя и получателя.

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

1.4. Транспортный контейнер - набор логически связанных документов и ЭП, а также сопутствующая транспортная информация, объединенные в один файл.

1.5. Абонент - зарегистрированный участник информационного взаимодействия, являющийся налогоплательщиком или уполномоченным представителем налогоплательщика.

1.6. НБО - налоговые декларации (расчеты), бухгалтерская отчетность и иные документы, служащие основанием для исчисления и уплаты налогов и сборов.

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

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

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

2.3. В ходе осуществления документооборота документы передаются в сжатом и зашифрованном виде, если для конкретного типа документооборота не указано обратное. ЭП под документами передаются в открытом виде.

2.4. Для каждого типа документооборота используемые форматы служебно-технологических документов приводятся в справочнике Типов документооборота, размещаемом на сайте www.nalog.ru

3. Общие требования к составу контейнера

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

Транспортный контейнер представляет собой zip-архив, содержащий:

- файл с транспортной информацией в формате xml;

- zip-архивы файлов с содержимым передаваемых документов;

- zip-архивы файлов с описаниями документов;

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

Схема транспортного контейнера приведена на рисунке 1.

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

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

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

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

Документ может содержать не более 64 файлов приложений и иметь размер не более 25 Мбайт.

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

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

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

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

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

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

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

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

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

Для неформализованных документов в форматах JPEG, TIFF, а также изображений, вложенных в документы формата PDF, RTF, Microsoft Word, Microsoft Excel, Open Document Text, Document Spreadsheet, Open XML Word и Open XML Spreadsheet, содержащих отсканированные изображения, предъявляются следующие требования: черно-белое изображение с разрешением отсканированного документа не менее 150 и не более 300 точек на дюйм с использованием 256 градаций серого цвета.

3.4. Требования к типам документооборота приведены в Приложениях 4-11, 13-16 к настоящему документу.

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

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

4.2. Идентификаторы участников документооборота состоят из символов латинского алфавита a-z, 0-9, "@", "." и "-". Идентификаторы являются регистронезависимыми.

4.3. В качестве идентификатора налогового органа используется четырехзначный код налогового органа в кодировке классификатора СОУН.

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

4.5. Идентификатор абонента имеет формат

Где:

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

<код абонента> - это уникальный код абонента, используемый во внутренней системе специализированного оператора связи или доверенного удостоверяющего центра; длина <код абонента> не более 43 символов.

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