Приказ ФНС России от 23.01.2015 № ММВ-7-6/23@

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

МИНИСТЕРСТВО ФИНАНСОВ РОССИЙСКОЙ ФЕДЕРАЦИИ

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

ПРИКАЗ от 23 января 2015 г. № ММВ-7-6/23@

О ВНЕСЕНИИ ИЗМЕНЕНИЙ В ПРИКАЗ ФНС РОССИИ ОТ 09.11.2010 № ММВ-7-6/535@

В целях обеспечения унификации информационного взаимодействия в электронном виде между налогоплательщиками и налоговыми органами по телекоммуникационным каналам связи с использованием электронной подписи и обеспечения приема налоговых деклараций по налогу на добавленную стоимость в соответствии с изменениями в ст. 174 Налогового кодекса Российской Федерации, внесенными Федеральным законом от 28.06.2013 № 134-ФЗ, к 01.04.2015 и в соответствии с приказом ФНС России от 28.10.2014 № ММВ-7-14/556@ «О внесении изменений в приказ ФНС России от 09.06.2011 № ММВ-7-6/362@» приказываю:

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

1.1. Пункт 3.1.3 Унифицированного формата дополнить строкой следующего содержания:

«3.1.3.1. Для КНД=1151001 v.5.04 и приложений КНД=Индекс=0000080, 0000081, 0000090, 0000091, 0000100, 0000110, 0000120) к основному файлу (КНД=1151001 v.5.04), размер транспортного контейнера не должен превышать 1 гигабайт, а размер любого файла в контейнере не должен превышать 840 мегабайт. Исходный объем файла, zip-архив которого содержится в контейнере, не должен превышать 10 гигабайт. Транспортный контейнер передается в составе почтового сообщения, размер которого не превышает 1 гигабайт»;

1.2. Пункт 5.2.2 Унифицированного формата изложить в следующей редакции:

«5.2.2. Формат zip-архива описывается в открытой спецификации, доступной по адресу http://www.pkware.com/documents/casestudies/APPNOTE.TXT. Архивирование содержимого больше 4 ГБ должно производиться в соответствии с базовыми возможностями версии 4.5 (ZIP64) без использования шифрования, размеры менее 4 ГБ могут архивироваться в соответствии с базовыми возможностями версии 2.0 без использования шифрования»;

1.3. Пункт 5.3.2 Унифицированного формата изложить в следующей редакции:

«5.3.2. Зашифрованные данные и ЭП передаются при помощи контейнера PKCS #7 (RFC 2315, http://www.ietf.org/rfc/rfc2315.txt). Для сохранения содержимого используется DER или BER-кодирование.»;

1.4. Пункт 6 Унифицированного формата изложить в следующей редакции:

«6. Общие требования к протоколу взаимодействия и составу почтового сообщения при взаимодействии с унифицированной системой представления налоговых деклараций и бухгалтерской отчетности в электронном виде по телекоммуникационным каналам связи.»

Требования к протоколу взаимодействия и структуре почтового сообщения устанавливаются в приложении № 12 к настоящему документу.»;

1.5. Приложение № 3 к Унифицированному формату изложить в редакции согласно приложению № 1 к настоящему приказу;

1.6. Приложение № 12 к Унифицированному формату изложить в редакции согласно приложению № 2 к настоящему приказу;

1.7. Раздел IX приложения № 1 к Унифицированному формату изложить в редакции согласно приложению № 3 к настоящему приказу;

1.8. Таблицу 16.5 приложения № 16 к Унифицированному формату изложить в редакции согласно приложению № 4 к настоящему приказу.

2. Настоящий приказ вступает в силу с даты его подписания.

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

Приложение № 1 к приказу ФНС России от «__» ________ 2015 г. N _______

Приложение № 4 к Унифицированному формату транспортного контейнера

Таблица 4.1. Тип документооборота.

2.1 Требования к SMTP протоколу взаимодействия

• SIZE (в соответствии с документом RFC 1870: http://www.ietf.org/rfc/rfc1870.txt);
• CHECKPOINT (в соответствии с документом RFC 1845: http://www.ietf.org/rfc/rfc1845.txt);
• CHUNKING (в соответствии с документом RFC 3030: http://www.ietf.org/rfc/rfc3030.txt);
• BINARYMIME (в соответствии с документом RFC 3030: http://www.ietf.org/rfc/rfc3030.txt).

Пример команды с использованием указанных расширений

MAIL FROM:sos@gpk.nalog.ru BODY=BINARYMIME TRANSID=<362438-c6292fa8b96f44349a01c4a67fc> SIZE=999999999

При передаче транспортных контейнеров, размер которых не превышает 72 мегабайт, допускается отсутствие расширений CHUNKING и BINARYMIME.

3. Требования к структуре сообщения электронной почты

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

Список служебных полей транспортного сообщения

Где: О — наличие поля обязательно

Н — наличие поля необязательно

3.2. Поля From:, To: содержат электронный адрес, заключенный в угловые скобки (символы «<» и «>»). В данных полях может присутствовать наименование отправителя или получателя, не превышающее 80 символов. Содержащийся в угловых скобках электронный адрес не может превышать 40 символов.

3.3. При отправке транспортного контейнера с документами налогоплательщика через специализированного оператора связи в поле From: указывается адрес специализированного оператора связи. Для транспортного контейнера с документами для налогоплательщика, направляемого через специализированного оператора связи, в поле To: указывается адрес специализированного оператора связи.

3.4. Поле Content-Transfer-Encoding: содержит тип кодировки почтового сообщения. Значением поля должна быть строка без пробелов: binary или base64. Для содержимого транспортных контейнеров размером более 72 мегабайт допускается использование только типа кодировки почтового сообщения binary.

3.5. Поле Content-Type: содержит ключевое слово: application/octet-stream и через символ «;» с пробелом после него параметр: name=. Параметр name= указывает имя файла транспортного контейнера, которое может быть заключено в кавычки (символы « (код 34)).»

3.6. Поле Content-Disposition: содержит ключевое слово: attachment и через символ «;» с пробелом после него параметр: filename=. Транспортный контейнер вложен (ключевое слово attachment) в сообщение электронной почты, передаваемое по телекоммуникационным каналам связи. Параметр filename= содержит имя файла вложения, которое может быть заключено в кавычки (символы « (код 34)).»

3.7. В поле Content-Length: указывается количество байт файла вложения. Размер файла транспортного контейнера не может быть нулевым и сам транспортный контейнер не может содержать файлы нулевой длины.

3.8. Содержание поля Subject: указывается в кодировке Base64/Windows-1251 и не может превышать 256 символов.

3.9. При направлении сообщения об ошибке поле X-Message-ID: может содержать значение поля первичного почтового сообщения, если невозможно идентифицировать <идентификатор Документооборота> из транспортного контейнера.

3.10. Требования к обязательным реквизитам не исключают применение иных служебных полей сообщения электронной почты на усмотрение разработчика программного обеспечения.

3.11. Сообщение электронной почты может иметь только одного получателя.

3.12. Сообщение электронной почты должно содержать только один вложенный в него файл транспортного контейнера.

IX. Формат описания представления отдельных документов в налоговые органы (Версия 06)

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

1.1 Назначение

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

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

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

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

TR_PROTDOC

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

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

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

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

TR_PROTDOC_2_700_12_09_06_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. ДИАГРАММА ФАЙЛА ОБМЕНА

                                    ┌────────────┐
<pre class="legal-pre">                                    │----        │
                                    │---         │
                                 ┌──┤--          │
                                 │  │  КНД       │
                                 │  └────────────┘
                                 │   Код формы передаваемого
                                 │   основного документа
                                 │   по КНД
                                 │  ┌────────────┐
                                 │  │----        │
                                 │  │---         │
                                 ├──┤--          │
                                 │  │  КодНО     │
                                 │  └────────────┘
                                 │   Код налогового
                                 │   органа
                                 │  ┌ ─ ─ ─ ─ ─ ─┐
┌───────────────┐    /───────\   │   ----
│              ┌┴┐   │       ├─┐ │  │---         │
│   описание   │-├───┤-.-.-.-│-├─┼ ─┤--
│              └┬┘   │       ├─┘       КолФайл   │
└───────────────┘    \───────/   │  └ ─ ─ ─ ─ ─ ─┘</pre>

 документа                           результате деления

                                 │   исходного файла

                               сведения                                 \/