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

ПРИКАЗ

 от 26 марта 2009 года N ММ-7-6/141@

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

____________________________________________________________________
Утратил силу с 17 ноября 2010 года на основании
приказа ФНС России от 18 декабря 2009 года N ММ-7-6/693@
____________________________________________________________________

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

приказываю:

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

2. Ввести в действие унифицированный формат транспортного сообщения с 06.04.2009.

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

4. Управлению информатизации (В.Г.Колесников), ФГУП ГНИВЦ ФНС России (И.Н.Задворнов) установленным порядком доработать программные средства, обеспечивающие прием, хранение и первичную обработку налоговых деклараций (расчетов) и документов в электронном виде по телекоммуникационным каналам связи в соответствии с утвержденным унифицированным форматом транспортного сообщения.

5. Считать утратившим силу приказ Федеральной налоговой службы от 08.08.2007 N ММ-3-13/469@ "Об утверждении унифицированного формата транспортного сообщения при информационном взаимодействии налогоплательщиков и налоговых органов в электронном виде по телекоммуникационным каналам связи".

6. Контроль исполнения настоящего приказа возложить на заместителя руководителя Федеральной налоговой службы Н.Е.Мельникова.

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

Приложение
к приказу ФНС России
 от 26 марта  2009 года N ММ-7-6/141@

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

1. Общие положения

Унифицированный формат транспортного сообщения применяется для организации обмена электронными документами (далее - ЭД) между налоговыми органами и хозяйствующими субъектами по телекоммуникационным каналам связи с использованием электронной цифровой подписи (далее - ЭЦП). Обмен ЭД осуществляется посредством транспортного сообщения (далее - ТС) (рис. 1) с прикрепленным к нему транспортным контейнером, который содержит зашифрованные данные, передаваемые получателю.

ДИВ - файл электронного документа информационного взаимодействия;

{ЭЦП} - один или несколько файлов ЭЦП, которыми заверен документ;

{С} - один или несколько файлов с сертификатами ключей ЭЦП, которыми заверен документ. Данный файл является не обязательным и может отсутствовать;

ОДИВ - файл описания документа информационного взаимодействия;

ИОП - файл информации об отправителе и получателе.

Рисунок 1

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

2. Требования к структуре транспортного сообщения, передаваемого по телекоммуникационным каналам связи

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

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

Поля <From:>, <Reply-To:>, <To:> содержат наименование организации (индивидуального предпринимателя) отправителя/получателя в кодировке Quoted-Printable/Windows-1251 или Base64/Windows-1251 и следующий за наименованием электронный адрес, заключенный в угловые скобки (символы "<" и ">").

Наименование не может превышать 80 символов.

Содержащийся в угловых скобках электронный адрес не может превышать 40 символов.

Поля <Message-ID:> и <X-Message-ID:> содержат уникальную последовательность длиной до 40 символов. Разрешается использование символов из следующих диапазонов: от [A-Z], [a-z], [0-9], а также символов "@", "." и "-". Уникальная последовательность может быть заключена в угловые скобки (символы "<" и ">").

Поле <Content-Transfer-Encoding:> содержит тип кодировки почтового сообщения.

Значением поля должна быть строка без пробелов: quoted-printable или base64.

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

В случае, если имя файла вложения содержит русские буквы, оно должно быть указано в кодировке Quoted-Printable/Windows-1251 или Base64/Windows-1251.

Поле <Content-Disposition:> содержит ключевое слово: attachment и через символ ";" с пробелом после него параметр: filename=. Параметр filename= содержит имя файла вложения, заключенное в кавычки (символы " (код 34)).

В случае, если имя файла вложения содержит русские буквы, оно должно быть указано в кодировке Quoted-Printable/Windows-1251 или Base64/Windows-1251.

В поле <Content-Length:> указывается количество байт (кратное четырем) файла вложения.

Содержание полей <Subject:>, <X-Tax-Type:>, <X-Tax-System:> указывается в кодировке Quoted-Printable/Windows-1251 или Base64/Windows-1251 и не может превышать 256, 40, 40 символов соответственно.

При использовании кодировки Quoted-Printable/Windows-1251 обязательно кодирование следующих символов:

! (код 33), " (код 34), # (код 35), $ (код 36), @ (код 64), [ (код 91), \

(код 32), ] (код 93), ^ (код 94), ` (код 96), { (код 123), | (код 124), } (код 125), ~ (код 126).

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

Транспортное сообщение может иметь только одного получателя.

Транспортный контейнер вложен (ключевое слово attachment) в транспортное сообщение, передаваемое по телекоммуникационным каналам связи. Имя вложения указано в поле <Content-Disposition:> (параметр filename=). Размер файла транспортного контейнера не может быть нулевым и сам транспортный контейнер не может содержать файлы нулевой длины. Транспортное сообщение должно содержать только один вложенный в него файл транспортного контейнера.

Размер транспортного сообщения, передаваемого по телекоммуникационным каналам связи не должен превышать 512 Мбайт. Контейнер с одним и тем же именем от одного и того же отправителя не может быть вторично принят налоговым органом к обработке.

Пример транспортного сообщения, содержащего документ налоговой декларации (расчета), приведен в приложении N 1.

3. Особенности работы с транспортными сообщениями

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

Ошибочное заполнение полей транспортного сообщения может привести к ошибкам его обработки, даже в том случае, если транспортный контейнер не содержит ошибок.

При отправке транспортных сообщений в налоговый орган (на сервер обмена электронными документами) следует учитывать следующие особенности:

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

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

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

При приеме транспортных сообщений из налогового органа (с сервера обмена электронными документами) следует учитывать следующие особенности:

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

3.1. Сообщения о критических ошибках

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

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

Поле <Subject:> содержит строку вида: Ошибка в файле: <Имя файла контейнера> или Re: <Тема сообщения>.

Вложения для данного типа сообщений не предусмотрены.

Поле <X-Message-ID:> содержит значение поля <Message-ID:> сообщения, при обработке которого была обнаружена критическая ошибка.

4. Требования к содержанию и структуре транспортного контейнера

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

- реализовывать процедуры формирования и проверки ЭЦП в соответствии с отечественными стандартами ГОСТ Р 34.11-94,  ГОСТ Р 34.10-2001;

- реализовывать процедуры шифрования и имитозащиты в соответствии с ГОСТ 28147-89;