Присоединяйтесь!
Зарегистрированных пользователей портала: 505 926. Присоединяйтесь к нам, зарегистрироваться очень просто →
Законодательство
Законодательство

ПРИКАЗ ФНС РФ от 26.03.2009 N ММ-7-6/141@ "ОБ УТВЕРЖДЕНИИ УНИФИЦИРОВАННОГО ФОРМАТА ТРАНСПОРТНОГО СООБЩЕНИЯ ПРИ ИНФОРМАЦИОННОМ ВЗАИМОДЕЙСТВИИ НАЛОГОПЛАТЕЛЬЩИКОВ И НАЛОГОВЫХ ОРГАНОВ В ЭЛЕКТРОННОМ ВИДЕ ПО ТЕЛЕКОММУНИКАЦИОННЫМ КАНАЛАМ СВЯЗИ"

Дата документа26.03.2009
Статус документаОтменен/утратил силу
МеткиПриказ
x
Документ отменен / утратил силу
Документ отменен или утратил силу. Подробная информация приводится в примечаниях к документу.

    

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

 

ПРИКАЗ
от 26 марта 2009 г. N ММ-7-6/141@

 

ОБ УТВЕРЖДЕНИИ УНИФИЦИРОВАННОГО ФОРМАТА ТРАНСПОРТНОГО СООБЩЕНИЯ ПРИ ИНФОРМАЦИОННОМ ВЗАИМОДЕЙСТВИИ НАЛОГОПЛАТЕЛЬЩИКОВ И НАЛОГОВЫХ ОРГАНОВ В ЭЛЕКТРОННОМ ВИДЕ ПО ТЕЛЕКОММУНИКАЦИОННЫМ КАНАЛАМ СВЯЗИ

 
    В целях обеспечения унификации информационного взаимодействия в электронном виде между налогоплательщиками и налоговыми органами по телекоммуникационным каналам связи с использованием электронной цифровой подписи приказываю:
    1. Утвердить Унифицированный формат транспортного сообщения при информационном взаимодействии налогоплательщиков и налоговых органов в электронном виде по телекоммуникационным каналам связи с использованием электронной цифровой подписи согласно приложению к настоящему Приказу (далее - унифицированный формат транспортного сообщения).
    2. Ввести в действие унифицированный формат транспортного сообщения с 06.04.2009.
    3. Управлению информатизации (В.Г. Колесников) обеспечить доведение до всех участников информационного взаимодействия в электронном виде по телекоммуникационным каналам связи информацию о вводе в действие унифицированного формата транспортного сообщения.
    4. Управлению информатизации (В.Г. Колесников), ФГУП ГНИВЦ ФНС России (И.Н. Задворнов) установленным порядком доработать программные средства, обеспечивающие прием, хранение и первичную обработку налоговых деклараций (расчетов) и документов в электронном виде по телекоммуникационным каналам связи в соответствии с утвержденным унифицированным форматом транспортного сообщения.
    5. Считать утратившим силу Приказ Федеральной налоговой службы от 08.08.2007 N ММ-3-13/469@ "Об утверждении унифицированного формата транспортного сообщения при информационном взаимодействии налогоплательщиков и налоговых органов в электронном виде по телекоммуникационным каналам связи".
    6. Контроль исполнения настоящего Приказа возложить на заместителя руководителя Федеральной налоговой службы Н.Е. Мельникова.
 

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

 
 
 

Приложение
к Приказу ФНС России
от "__" _______ 2009 г.
N ________________

 

УНИФИЦИРОВАННЫЙ ФОРМАТ
ТРАНСПОРТНОГО СООБЩЕНИЯ ПРИ ИНФОРМАЦИОННОМ ВЗАИМОДЕЙСТВИИ НАЛОГОПЛАТЕЛЬЩИКОВ И НАЛОГОВЫХ ОРГАНОВ В ЭЛЕКТРОННОМ ВИДЕ ПО ТЕЛЕКОММУНИКАЦИОННЫМ КАНАЛАМ СВЯЗИ С ИСПОЛЬЗОВАНИЕМ ЭЛЕКТРОННОЙ ЦИФРОВОЙ ПОДПИСИ

 

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

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

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

Рисунок 1

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

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

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

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

 

N п/п Идентификатор реквизита Содержание реквизита
1 From: Имя отправителя почтового сообщения
2 Reply-To: Имя отправителя почтового сообщения, должно совпадать с полем From
3 To: Имя получателя почтового сообщения
4 Message-ID: Идентификатор почтового сообщения - уникальная для данного отправителя сообщений последовательность символов
5 Content-TransferEncoding: Механизм конвертирования почтового сообщения
6 Content-Type: Описание типа вложения
7 Content-Disposition: Описание расположения вложения
8 Content-Length: Описание длины вложения
9 Subject: Тема сообщения, определяемая типом сообщения и наименованием вложения
10 X-Tax-Sender: Идентификатор отправителя сообщения
11 X-Tax-Reciever: Идентификатор получателя сообщения
12 X-Tax-Type: Тип передаваемой информации
13 X-Tax-System: Наименование передающей системы
14 X-Message-ID: Для первичного сообщения, с которого начинается документооборот - значение поля Message-ID. Для сформированных в ответ на поступившие или в ходе их обработки - значение поля X-Message-ID входящего сообщения

 
    Поля <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;
    - соответствовать стандарту RFC 4357 "Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms", January 2006 (http://www.ietf.org/rfc/rfc4357.txt);
    - поддерживать криптографический интерфейс компании Microsoft - Microsoft Cryptographic Service Provider (CSP);
    - быть сертифицированными в соответствии с законодательством Российской Федерации.
    Реквизиты шифрования данных:
    - Версия - реквизит формата файла транспортного контейнера;
    - Длина отпечатка сертификата ключа ЭЦП, с помощью которого были зашифрованы данные - реквизит сертификата отправителя;
    - Отпечаток сертификата ключа ЭЦП, с помощью которого были зашифрованы данные - реквизит сертификата отправителя;
    - Длина имени владельца сертификата ключа ЭЦП, с помощью которого были зашифрованы данные - реквизит сертификата отправителя;
    - Имя владельца сертификата ключа ЭЦП в кодировке Windows 1251, с помощью которого были зашифрованы данные - реквизит сертификата отправителя;
    - Длина отпечатка сертификата ключа ЭЦП, с помощью которого можно расшифровать данные - реквизит сертификата получателя;
    - Отпечаток сертификата ключа ЭЦП, с помощью которого можно расшифровать данные - реквизит сертификата получателя;
    - Длина имени владельца сертификата ключа ЭЦП, с помощью которого можно расшифровать данные - реквизит сертификата получателя;
    - Имя владельца сертификата ключа ЭЦП в кодировке Windows 1251, с помощью которого можно расшифровать данные - реквизит сертификата получателя;
    - Длина зашифрованного сессионного ключа - вырабатывается СКЗИ;
    - Зашифрованный сессионный ключ - вырабатывается СКЗИ;
    - Длина вектора инициализации - вырабатывается СКЗИ;
    - Вектор инициализации - вырабатывается СКЗИ;
    - Длина зашифрованных данных - вырабатывается СКЗИ.
    Зашифрованные данные представляют собой файл архива, содержащий в себе:
    - файл документа информационного взаимодействия (налоговая декларация, квитанция, протокол и т.п.) - ДИВ;
    - один или несколько файлов ЭЦП, которыми заверен документ - {ЭЦП};
    - один или несколько файлов с сертификатами ключей ЭЦП, которыми заверен документ - {С} (данный файл (файлы) могут отсутствовать);
    - файл описания документа информационного взаимодействия - ОДИВ;
    - файл информации об отправителе и получателе - ИОП.
    Шифрование данных транспортного контейнера выполняется единым блоком, при этом используется шифрование гаммированием с обратной связью ГОСТ 28147-89.
    Для архивирования данных применяется формат, соответствующий спецификации файлового формата ZIP <*>. Структура транспортного контейнера приведена в приложении N 2.
    


    <*> Описание формата ZIP доступно на сайте компании разработчика Pk Ware www.pkware.com/company/standards/appnote/appnote.txt).
 
    Имя файла транспортного контейнера совпадает с именем документа информационного взаимодействия (filename.ext), который он содержит. Требования к наименованию исходного файла документа информационного взаимодействия, его формату и правилам заполнения определяются соответствующими нормативными документами ФНС России и Минфина России. Пример файла документа информационного взаимодействия приведен в приложении N 3.
    Файлы ЭЦП ({ЭЦП}) содержат электронные цифровые подписи документа информационного взаимодействия, сформированные лицами, имеющими полномочия на право подписи таких документов или подтверждающих получение данного документа. Структура файла ЭЦП приведена в приложении N 4.
    Файлы сертификатов ЭЦП ({С}) содержат сертификаты электронных цифровых подписей, владельцами которых подписан документ информационного взаимодействия. Данный файл является необязательным.
    При необходимости для каждого файла ЭЦП в транспортном контейнере может содержаться соответствующий ему файл сертификата. При передаче сообщений, являющихся ответом на первичное сообщение, файлы сертификатов в состав зашифрованных данных транспортного контейнера не включаются. Структура файла сертификата приведена в приложении N 5.
    Файл описания документа информационного взаимодействия (ОДИВ) используется для передачи оригинального наименования документа информационного взаимодействия в случае, когда такое наименование не может быть передано в наименовании файла транспортного контейнера. Структура и пример файла описания документа информационного взаимодействия приведены в приложении N 6.
    Файл информации об отправителе и получателе транспортного сообщения (ИОП) содержит идентификатор отправителя контейнера, идентификатор получателя контейнера, тип передаваемой информации, версию транспортной программы, дополнительную информацию, если она необходима. Структура и пример файла информации приведены в приложении N 7.
    Транспортный контейнер должен содержать все обязательные файлы, согласно описанию в разделе 6, соответствующие типу документа, передаваемого в транспортном контейнере. Допускается расширение состава транспортного контейнера, поступающего из налогового органа, файлами, содержащими дополнительную технологическую информацию. Файлы, расширяющие состав транспортного контейнера, не должны совпадать по структуре именования с файлами, требуемыми настоящим форматом.
    Имя файла транспортного контейнера является регистрозависимым за исключением случаев, указанных непосредственно в требованиях к именованию транспортного контейнера.