Сервис 3

Реализация базовых сценариев до 02.06.2024г касается всех действующих участников налогового мониторинга? Если действующий участник не успеет реализовать, какие его ждут последствия?

Реализация сценариев по версии размещенной на сайте nalog.gov.ru касается всех действующих участников НМ (срок до 02.06.2024). После указанной даты возможно измененение версии. До 01.01.2026 у налогоплательщиков должны быть реализованы сервисы взаимодействия через ИС НП в рамках обмена на основании п.6 ст. 105.26 НК РФ. Отсутствие реализации в установленные сроки может служить основанием для досрочного прекращения НМ на основании ст. 105.28 НК РФ.

В приложениях по организации работы в Налоговом мониторинге (Сервис направление ответа на требование о предоставление документа – Файловый обмен и доразмещение документов) указано:

«Если в ИС НП присутствуют файлы электронной подписи к представленным документам, которые использовались при обмене между субъектами экономической деятельности, то данные файлы должны быть представлены с расширением sgn.»

Если в организации для ЭЦП используется расширение «.sig». Означает ли это , что такие файлы подписи не будут приниматься в рамках сервисов АИС "Налог-3" по предоставлению первичных документов и необходимо переводить подпись в формат sgn?

Содержимое ТК указано в п.5.1. Унифицированного формата ТК, согласно которому ТК должен обязательно содержать файлы с содержимым передаваемых ЭП. При этом, в случае, если в ТК передается только основной документ (без приложений юридически значимых документов), то включается только ЭП участников информационного обмена формата .bin. В случае, если в ТК к основному документу прилагаются юридически значимые электронные документы, которыми между собой обмениваются субъекты экономической деятельности, то к таким документам обязательно прилагается ЭП с расширением sgn (такая ЭП может быть только у приложений к основному документу). Таким образом, в рамках работы сервиса 3 "Файловый обмен" к ПУД должна быть приложена ЭП только с расширением sgn (указанное требование является обязательным).

Если получен протокол с ошибкой, то требуется формирование нового ТК, т.е. обработка аналогично СОШ?

После исправления ошибок необходимо переотправить ТК.

Если в качестве приложения прикрепляется документ с ЭП, то его требуется повторно подписать УКЭП прикладывая в ТК?

В таком случае у документа будет 2 подписи (sgn и bin).

В сценарии сказано: Датой отправки считается дата, указанная в параметре Date, структуры RegisterAvailableFileResponse, возвращаемой на вызов registerAvailableFile, при возврате кода ответа равного 200-операция успешна. Какой часовой пояс должен быть указан при отправке запроса?

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

Планируется, что подписание контейнеров по сценарию 3 возможно только с помощью усиленной квалифицированной электронной подписи? Будет ли возможность подписания контейнеров по сценарию 3 неквалифицированной электронной подписью, к примеру?

Каждый файл, размещенный в транспортном контейнере, должен быть только с усиленной квалифицированной электронной подпись (ЭП)

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

При отсутствии в информационной системе налогоплательщика реализованного Сервиса №3, налоговый орган может запросить документы, пояснения используя Сервисы №№4,5,6 и №№12-17.
В случае, если и данные сервисы не реализованы в системе налогоплательщика, то процедура истребования документов, пояснений осуществляется по ТКС.

При ответе на требование по сценарию "файловый обмен" налогоплательщик формирует архив в формате ZIP, в котором объединяет запрошенные документы разного формата в общем размере, не превышающем предельно допустимый. Сформированный архив подписывается электронной подписью представителя налогоплательщика, и именно эта ЭП направляется в налоговый орган в составе ответа в "АИС налог-3". При этом не требуется отдельно подписывать электронной подписью каждый документ, включенный в состав ZIP архива.

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

Для ЭП, приложенных к документам, при направлении юридически значимых электронных документов, которыми между собой обмениваются субъекты экономической деятельности, повторяют имена файлов приложений без расширения, к которым они прилагаются, с расширением sgn.

Для ЭП участников информационного обмена, которой заверяются документы, именуются с использованием универсальных уникальных идентификаторов по формату "<UUID>.bin"
Транспортная информация и файлы с содержимым документов и ЭП объединяются в zip-архив.
В одном транспортном контейнере передаются документы и ЭП, относящиеся к одной транзакции.
Для формирования ЭП (участников информационного обмена) используются алгоритмы ГОСТ Р 34.10-2012.
ЭП передаются при помощи контейнера PKCS #7 (RFC 2315, http://www.ietf.org/rfc/rfc2315.txt). Для сохранения содержимого используется DER или BER-кодирование.

ЭП передаются в виде структуры ContentInfo со структурой SignedData в качестве содержимого. ЭП должна включать относящийся к ней сертификат и не должна включать подписанный ею документ.

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

Электронных архив документов является обязательная составляющей работоспособности всех интеграционных сервисов по истребованию документов, пояснений.
При отсутствии в информационной системе налогоплательщика реализованного Сервиса №3, налоговый орган может запросить документы, пояснения используя Сервисы №№4,5,6 и №№12-17.
В случае, если и данные сервисы не реализованы в системе налогоплательщика, то процедура истребования документов, пояснений осуществляется по ТКС.

"Транспортный контейнер размещается на файловом ресурсе отправителя. Путь к файлу указывается в параметре FilePath элемента FileMetadata при вызове сервиса registerAvailableFile.» Что именно подразумевается под «файловым ресурсом» отправителя? Какой предполагается протокол обмена файлам? Какой предполагается формат пути к файлу?

Параметр FilePath содержит полный путь к файлу в системе организации в формате https://<доменное имя сервера сервисов налогового мониторинга>:<порт (указывается, если используется не 443 порт)/<путь к файлу (указывается при наличии)>/<имя файла>. Например: https://taxmon.mycompany.ru:8443/storage/my_document.zip

В качестве альтернативы может использоваться программный обработчик запросов, возвращающий файлы из информационной системы организации https://<доменное имя сервера сервисов налогового мониторинга>:<порт (указывается если используется не 443 порт)/<путь к к обработчику запросов (указывается при наличии)>/< имя обработчика запросов>?<идентификатор запрашиваемого файла>.

Например: https://taxmon.mycompany.ru/services/getFile.do?fileId=1234. В этом случае должны быть корректно указаны content-type и content-disposition Обращение к файловому ресурсу будет осуществляться с помощью HTTP метода GET. Возможно реализовать файловое хранилище с использованием сервера Apache или Nginx.

Напишите нам, и мы постараемся оперативно на него ответить.

Задать вопрос