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

Согласно описанию сценария в пункте 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 вызова метода по передачи контейнера с документом, на который потом формируется СОШ. Ожидается что каждый новый вызов метода новый тикет.

Код документа-основания по справочнику документов: исходя из данных логично предполагать, что при обращении к документу-основанию обращение происходит через SPVDOC. Правильно ли мы понимаем, и не происходит ли обращение к некому иному справочнику?

Да, правильно - обращение происходит через SPVDOC.

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

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

Какой порядок действия, если в рамках сервиса №6 были запрошены документы, которые уже запрашивались ранее или уже размещены в системе налогоплательщика?

Повторный запрос не предусматривается.

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

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