ПРИКАЗ
от 19 апреля 2012 года N ММВ-7-6/251@
О внесении изменений в приказ ФНС России от 09.11.2010 N ММВ-7-6/535@
В целях обеспечения унификации информационного взаимодействия в электронном виде между налогоплательщиками и налоговыми органами по телекоммуникационным каналам связи с использованием электронной подписи и в соответствии с приказом Министерства финансов Российской Федерации от 25 апреля 2011 года N 50н "Об утверждении Порядка выставления и получения счетов-фактур в электронном виде по телекоммуникационным каналам связи с применением электронной цифровой подписи" и приказом ФНС России от 30.01.2012 N ММВ-7-6/36@ "Об утверждении форматов представления документов, используемых при выставлении и получении счетов-фактур в электронном виде по телекоммуникационным каналам связи с применением электронной подписи"
приказываю:
1. Внести в Унифицированный формат транспортного контейнера при информационном взаимодействии с приемными комплексами налоговых органов по телекоммуникационным каналам связи с использованием электронной подписи, утвержденный приказом ФНС России от 09.11.2010 N ММВ-7-6/535@, изменения согласно приложению к настоящему приказу.
2. Контроль за исполнением настоящего приказа возложить на заместителя руководителя Федеральной налоговой службы А.С.Петрушина.
Руководитель
Федеральной налоговой службы
М.В.Мишустин
Унифицированный формат транспортного контейнера при информационном взаимодействии с приемными комплексами налоговых органов по телекоммуникационным каналам связи с использованием электронной подписи
1.1. Электронный документ (документ) - документ, представленный в электронном виде, в соответствии с требованиями формата для данного типа документа.
1.2. Транзакция - единичный шаг передачи контейнера с документами и электронными подписями требуемого вида (ЭП) в рамках документооборота определенного типа, который определяет набор передаваемых документов, ЭП, их отправителя и получателя.
1.3. Электронный документооборот (документооборот) - последовательность транзакций по обмену документами между участниками документооборота, обеспечивающая некоторый регламентированный процесс по обмену документами (например, документооборот по представлению налоговых деклараций (бухгалтерской отчетности)).
1.4. Транспортный контейнер - набор логически связанных документов и ЭП, а также сопутствующая транспортная информация, объединенные в один файл.
1.5. Абонент - зарегистрированный участник информационного взаимодействия, являющийся налогоплательщиком или уполномоченным представителем налогоплательщика.
1.6. НБО - налоговые декларации (расчеты), бухгалтерская отчетность и иные документы, служащие основанием для исчисления и уплаты налогов и сборов.
2.1. Данный документ описывает структуру транспортного контейнера, формируемого и обрабатываемого программными средствами налогового органа в ходе информационного взаимодействия со специализированными операторами связи и абонентами в электронном виде по телекоммуникационным каналам связи с использованием ЭП для обеспечения организации электронного документооборота при представлении налогоплательщиками налоговых деклараций (расчетов), бухгалтерской отчетности и иных документов, служащих основанием для исчисления и уплаты налогов и сборов. Перечень типов документооборота приведен в приложениях 4-11, 13-16 к настоящему документу.
2.2. Информационное взаимодействие происходит путем осуществления документооборота через проведение транзакций - передачи от одного участника документооборота другому транспортного контейнера с фиксированным для данной транзакции набором документов и ЭП, сделанными от имени уполномоченных лиц соответствующих участников документооборота.
2.3. В ходе осуществления документооборота документы передаются в сжатом и зашифрованном виде, если для конкретного типа документооборота не указано обратное. ЭП под документами передаются в открытом виде.
2.4. Для каждого типа документооборота используемые форматы служебно-технологических документов приводятся в справочнике Типов документооборота, размещаемом на сайте www.nalog.ru
3.1. Содержимое транспортного контейнера
Транспортный контейнер представляет собой zip-архив, содержащий:
- файл с транспортной информацией в формате xml;
- zip-архивы файлов с содержимым передаваемых документов;
- zip-архивы файлов с описаниями документов;
- файлы с содержимым передаваемых ЭП.
Схема транспортного контейнера приведена на рисунке 1.
Рисунок 1: Схема транспортного контейнера
3.1.1. Файлы с содержимым документов и ЭП именуются с использованием универсальных уникальных идентификаторов по формату "<UUID>.bin".
3.1.2. Транспортная информация и файлы с содержимым документов и ЭП объединяются в zip-архив в режиме STORE. Файл с транспортной информацией при передаче в транспортном контейнере не сжимается и не шифруется.
3.1.3. В одном транспортном контейнере передаются документы и ЭП, относящиеся к одной транзакции.
Транспортный контейнер может содержать не более 64 файлов. Размер транспортного контейнера не должен превышать 18 мегабайт, а размер любого файла в контейнере не должен превышать 15 мегабайт. Исходный объем файла, zip-архив которого содержится в контейнере, не должен превышать 256 мегабайт.
3.1.4. Описание документа присутствует в транспортном контейнере в виде отдельного zip-архива в случае, если описание документа определено типом передаваемого документа. Формат описания документов приведен в Приложении 1 к настоящему документу. Описание документа содержит дополнительную информацию о передаваемом файле и носит исключительно информативный характер. Документ может использоваться для более информативного диагностического сообщения при невозможности расшифровать файлы транспортного контейнера.
3.1.5. Формат описания транспортной информации приведен в Приложении 2 к настоящему документу.
3.2. Имя файла транспортного контейнера
3.2.1. Транспортный контейнер передается в виде файла с уникальным именем по формату
FNS_<идентификатор отправителя>_<идентификатор получателя>_<UUID>_<код типа документооборота>_<код типа транзакции>_<код типа документа>.zip |
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.1. Документооборот осуществляется между следующими участниками документооборота.
Условное обозначение | Описание |
абонент | Налогоплательщик (юридическое лицо или индивидуальный предприниматель) или его уполномоченный представитель |
налоговыйОрган | Налоговый орган ФНС России |
спецоператор | Специализированный оператор связи |
доверенныйУЦ | Удостоверяющий центр, входящий в Сеть Доверенных УЦ ФНС России |
4.2. Идентификаторы участников документооборота состоят из символов латинского алфавита a-z, 0-9, "@", "." и "-". Идентификаторы являются регистронезависимыми.
4.3. В качестве идентификатора налогового органа используется четырехзначный код налогового органа в кодировке классификатора СОУН.
4.4. В качестве идентификатора специализированного оператора связи и доверенного удостоверяющего центра используется уникальный трехсимвольный код, определяемый ФНС России.
4.5. Идентификатор абонента имеет формат
<префикс системы><код абонента> |
Где:
<префикс системы> - это идентификатор специализированного оператора связи или доверенного удостоверяющего центра; длина <префикса системы> равна 3 символам; <префикс системы> должен совпадать с идентификатором специализированного оператора связи, услугами которого пользуется абонент;
<код абонента> - это уникальный код абонента, используемый во внутренней системе специализированного оператора связи или доверенного удостоверяющего центра; длина <код абонента> не более 43 символов.
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. Шифрование документов, передаваемых в составе первичного транспортного контейнера, должно производиться в адрес открытых ключей сертификатов получателя, указанных для шифрования, и открытых ключей сертификатов отправителя. Шифрование документов, передаваемых в результате приема или обработки поступившего документа, производится в адрес открытых ключей сертификатов получателя, указанных для шифрования, открытых ключей сертификатов отправителя и открытых ключей сертификатов должностных лиц, подписавших поступивший документ.