Вопросы и ответы

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

Сервисы истребования №№ 12-17 по срокам направления технологических документов соотвествуют срокам указанным в приказе ФНС России от 18.10.2023 N ЕД-7-23/757@. Таким образом срок направления в налоговый орган протокола в ответ на требование о представлении документов (информации) будет не позднее трех рабочих дней со дня получения требования.

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

Срок реализации базовых сервисов для организаций, являющихся участников налогового мониторинга, - 02.06.2024 года. Информация размещена на сайте nalog.gov.ru в разделе Контрольная работа/Налоговый мониторинг/Сроки реализации сервисов по налоговому мониторингу. Данные сервисы опубликованы 02.06.2023 и уже с данной даты доступны для реализации в ИС. В случае отсутствия реализации базовых сервисов в срок до 02.06.2024 информационное взаимодействие с помощью базовых сервисов будет осуществляться по мере наступления технологической готовности.

Имеется расхождение между 6 и 7 сценариями.
Из 6 сценария убрали RequesterName, но в ответе на запрос из 7 сценария этот элемент есть, и он обязательный.

Сервис №6 и Сервис №7 имеют разные задачи.
Сервис №7 разработан для получения отчета о работе пользователей с запросной системой, поэтому и собирается информация персонализировано по пользователю - инспектору (Ф.И.О.), опубликовавшего запрос в ИС. Для этого в состав элементов Сервиса №7 и включено значение «RequesterName» (Ф.И.О. инспектора, опубликовавшего запрос).
Сервис №6 направлен на направление запроса на доразмещение документа в ИС. При исполнении данного сервиса основной задачей является доразмещение документа, в независимости от того какой инспектор осуществил данный запрос, в связи с этим элемент «RequesterName» не является необходимых в составе данного сервиса.

Согласно описанию сценария в пункте 6.7 Ответ на запрос на доразмещение документа в информационной системе налогоплательщика в структуре PublishDocResponse элемент RejectReason может принимать значение 10 – продление срока по причине: существенные объемы истребованных документов (информации), а в элементе ResultStatus соответственно будет указано значение 2 – запрос не исполнен. При этом ответ с такими параметрами на запрос налогового органа (информирование о результатах выполнения запроса) будет направлено НП в течение десяти рабочих дней со дня получения запроса.
Имеется ли в этом случае ограничение по сроку на фактическое доразмещение документов и позволяет ли сервис при фактическом доразмещении документов направлять ответ или ответы (если доразмещение было частичное) еще раз на ранее полученный запрос от налогового органа и направленный ответ с указанными выше параметрами, иными словами предусматривает ли данный сервис возможность на 1 запрос НО направлять несколько ответов НП?

Ограничения на срок доразмещения документа отсутствует. В случае неудовлетворенности сроком продления НО направит требование о предоставлении документов (информации). В данном случае на 1 запрос НО НП может направить несколько ответов.

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

Для целей сценария №5 размещение допускает размещение ПУД без подписи. При этом печатная форма должна быть доступна для просмотра.

Нужно ли в реестр документов (сценарий 4) включать документы, не удовлетворяющие ограничениям к типу файла по 5-му сценарию (например, с типом png или архив)?

В данном случае в реестр могут быть включены указанные документы. При размещении в реестре документов, документов, имеющихся в электронном архиве в форматах, отличных от форматов, описанных в сценарии №5 признак наличие электронного образа документа в ИС НП примет значение «0».

В рамках сервиса 4 в ИС НП должен храниться реестр документов, сопоставленный с элементами справочника SPVDOC.
Справочник SPVDOC неоднократно обновлялся налоговым органом в течение 2023 года путем дополнения новых элементов и исключения имеющихся элементов с определенного периода (DATAN и DATAK).
Так как фактически запросы налогового органа по сервису 4 в адрес налогоплательщиков начнут поступать с 2024 года, а запрашиваемый налоговым органом массив данных может охватывать период с 01.01.2023, возник следующий вопрос.
Каким образом налогоплательщик обязан будет формировать реестр по электронному сервису 4 по запросам налогового органа за период до 2024 года:
Вариант 1: по актуальному (итоговому) на 01.01.2024 справочнику СПВДОК
Вариант 2: по справочнику СПВДОК с учетом изменений элементного состава справочника СПВДОК по периодам в течение 2023 года?
Например, справочник СПВДОК до 01.06.2023 содержал элемент 0530000085 «Авансовый отчет по хозяйственным расходам», который прекратил свое действие без правопреемства.

Обязанность в части представления документов (информации) по ТКС не применяется при проведении НМ за периоды начиная с 2026 г. При формировании реестра документов необходимо ориентироваться на справочники размещенные на сайте ФНС России.

Просьба дать пояснения: в каких случаях использовать подпись в формате "<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 вызова метода по передачи контейнера с документом, на который потом формируется СОШ. Ожидается что каждый новый вызов метода новый тикет.

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

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

Имеется расхождение между 6 и 7 сценариями. Из 6 сценария убрали RequesterName, но в ответе на запрос из 7 сценария этот элемент есть, и он обязательный.

Нужно ли в реестр документов (сценарий 4) включать документы, не удовлетворяющие ограничениям к типу файла по 5-му сценарию (например, с типом png или архив)?

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

Имеется расхождение между 6 и 7 сценариями.
Из 6 сценария убрали RequesterName, но в ответе на запрос из 7 сценария этот элемент есть, и он обязательный.