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

Содержание полей <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, с помощью которого были зашифрованы данные - реквизит сертификата отправителя;


Страницы: 3 из 21  <-- предыдущая  cодержание   следующая -->