Сервис 3

Просьба указать, какой из приведенных ниже вариантов заполнения поля ""Наименование и реквизиты документа, подтверждающего полномочия представителя организации (НаимДоК)"" верен для сценария № 3 (Файловый обмен):
- Полное наименование XML-файла доверенности с расширением
- Идентификационный номер доверенности (GUID)

Можно просто текстом написать номер доверенности и дата выдачи.
В 3 сценарии можно использовать только ИСОП, информация об этом указана в таблице «ТИПЫ ДОКУМЕНТОВ, входящих в состав транспортного контейнера»

- Идентификационный номер доверенности (GUID)

При формировании ответа в рамках 3-го сценария (файловый обмен), когда подписантом является уполномоченный представитель организации, требуется ли прикладывать файл ЭП к приложенной доверенности и заполнять его в файле транспортной информации (элемент «Сведения ЭП (Подпись)")?

При подписании УП, формируется ИСОП (КНД 1167005), которая подписывается той же подписью, что и основной документ. Все файлы, которые передаются, описываются в файле транспортной информации.

В случае, если передаваемый файл PDF уже был подписан присоединённой подписью, то файл необходимо подписывать повторно открепленной подписью, и прикладывать подпись в zip архив ?

Да, отдельный файл открепленной подписи является обязательным при представлении ответа.

Просьба пояснить какая дата будет являться датой получения требования, которое было направлено через информационную систему налогоплательщика по сервису №3 «Файловый обмен» и сервисам по сценарию 12?
Порядок определения даты получения требований, отправленных по ТКС, почтой, через МФЦ, лично - регулируются статьей 31 НК РФ.
Но в данной статье не говорится о требованиях, направленных через информационную систему налогоплательщика.

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

На официальной странице налогового мониторинга https://www.nalog.gov.ru/rn77/taxation/reference_work/taxmonit/#t9 имеются разница между:
1. Информация о технологии взаимодействия через информационную систему организации (https://data.nalog.ru/html/sites/www.new.nalog.ru/2023/taxation/reference_work/taxmonit/serv_format2...)
2. И Приказ ФНС России от 18.10.2023 № ЕД-7-23/757@ Об утверждении Порядка направления требования о представлении документов (информации)… (https://www.nalog.gov.ru/rn77/taxation/reference_work/taxmonit/13940115/)
В частности, есть существенные различия в описываемых форматах требования. Во втором документе появляется дополнительный КНД 1165050 (требование о представлении пояснений) со специфичным набором полей. Как следствие, изменен и формат ответа на требование.
Мы протестировали и реализовали работу с сервисами и форматами из п.1, оттуда же брали XSD-схемы. К п.2 XSD-схемы не приложены.
Нам теперь необходимо до 02.06 переделать весь реализованный функционал под форматы приказа № ЕД-7-23/757@? Или эти форматы будут актуальны только с 01.01.2026?

Форматы, утвержденные приказом ФНС России от 18.10.2023 № ЕД-7-23/757@, станут обязательны для реализации налогоплательщиками начиная с 01.01.2026.
Форматы, размещенные на сайте www.nalog.gov.ru → «Расширенное информационное взаимодействие» → «Информация о технологии взаимодействия через информационную систему организации», будут приведены в соответствие с форматами, утвержденными приказом ЕД-7-23/757@ и размещены на сайте в установленном порядке (03.06.2024, срок реализации для налогоплательщиков – 03.06.2025).

Что относиться к КНД 1121120, 1121119, которые прописаны в Приложении 4 к Сценарию 3.
До настоящего времени, у нас отсутствует информация, по указанным КНД, так же данная информация отсутствует в общедоступных источниках.

1121120 - План проведения налогового мониторинга (документ находится на стадии проекта);
1121119 - Протокол результатов закрытия периода налогового мониторинга (документ находится на стадии проекта).

Просьба дать пояснения: в каких случаях использовать подпись в формате "<UUID>.bin", а в каких .SGN.
Пока однозначно понятно, что все документы в формате XML требуется подписывать .bin.
УКЭП в формате "<UUID>.bin", или *.SGN нужно использовать, если в ответ на требование приложены, например:
- счет-фактура в формате PDF?
- счет-фактура в формате JPG?
- акт-выполненных работ в формате PDF?
- договор в формате PDF?

Подпись с расширением bin всегда должна быть под каждым документом в ТК. Подпись с расширением sgn может быть только у приложения, она добавляется в ТК если документ ранее отправлялся через другую систему и там был подписан ЭП.

ЭП участников информационного обмена, которой заверяются документы, именуется с использованием универсальных уникальных идентификаторов по формату "<UUID>.bin"». Просьба пояснить, значение UUID в файле подписи должно быть связано с подписанным файлом или нет?

Значение UUID не связано с подписанным файлом. Имя файла подписи формируется: Используемые универсальные уникальные идентификаторы должны генерироваться согласно общим принципам формирования UUID version 1, изложенным в документе RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt). Универсальные уникальные идентификаторы представляются в виде шестнадцатеричного числа из 32 разрядов, записанного в нижнем регистре.

Параметр «TicketId» при ответе на входящий запрос (отправка протоколов, сообщений об ошибке и др.) всегда должен повторяться или где-то мы должны генерировать свой код?

Если ответ на направленный документ (протокол, СОШ), то это новый вызов. В самом протоколе будет содержаться идентификатор документооборота, на который отправляется протокол, в имени СОШ так же имеется ключ в виде TicketId, повторяющий TicketId вызова метода по передачи контейнера с документом, на который потом формируется СОШ. Ожидается что каждый новый вызов метода новый тикет.

Какое значение должно быть заполено в поле НаимДок в случае отказа в предоставлении документов?

Поле НаимДок в случае невозможности представления документа заполняется из пункта требования.

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

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