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

Максимальный срок ответа на требование?
1. Для расчета плановой даты предоставления ответа на истребование (Сценарий №3 «Файловый обмен» или 12 «Истребование документов») ориентируемся на атрибуты
• Дата формирования документа (Требования)
• Количество рабочих дней на исполнение требования после получения. Принимает числовое значение. В настоящий момент возможные значения: 5 или 10.
2. При поступлении Документов в электронной форме и отсутствии оснований для отказа в их приеме получатели не позднее трех рабочих дней со дня направления Документов формируют Протокол обработки
3. При этом датой получения считается не дата формирования Требования, а дата поступления, зафиксированная в Протоколе обработки полученного Требования (атрибут «Дата поступления документа»).
4. Таким образом, максимальное время обработки Требования Налогоплательщиком составляет 3+5 или 3+10 рабочих дней от даты формирования Требования, в зависимости от атрибута «Количество рабочих дней на исполнение»

Срок ответа на требование о представлении документов (информации), пояснений составляет 5 (10) дней от даты поступления такого требования, зафиксированной в протоколе обработки.

Просим разъяснить правила присвоения значения элементу IsContentAvailable. По ранее данным разъяснениям, данный элемент имеет признак обязательности и необходим для того, чтобы налоговый инспектор понимал, какой из сервисов в случае необходимости должен быть вызван: "Запрос на просмотр документов" (Сервис №5) или "Запрос на доразмещение документов" (Сервис №6).

Если документ является электронным, состоящим из двух xml-файлов ("титул поставщика" и "титул покупателя"), то есть если, документ является многотитульным (например, УПД), какое значение нужно присвоить элементу IsContentAvailable в следующих ситуациях:
- в электронном архиве есть xml-файлы электронного документа, но нет pdf-файла визуализации;
- в электронном архиве есть pdf-файл визуализации, но нет xml-файлов электронного документа.

Значение элемента IsContentAvailable:
- в электронном архиве есть xml-файлы электронного документа, но нет pdf-файла визуализации = 0;
- в электронном архиве есть pdf-файл визуализации, но нет xml-файлов электронного документа = 1.

Если в запросе по сервису 12 будет присутствовать элемент "DocumentId" в составе элемента "RequestedDoc", допустимо ли в запросе по сервису 16 заполнить два составных элемента ResponseInfo, в каждом из которых указать один и тот же DocumentId, который был получен в запросе по сервису 12?

Иными словами, если НО в запросе укажет "DocumentId" электронного документа, который содержит два xml-файла ("титул поставщика" и "титул покупателя"), то есть если, документ является многотитульным (например, УПД), справедливо ли будет заполнить два составных элемента ResponseInfo, продублировав в каждом одинаковые: "Номер документа", "Дата документа", "Сумму документа", "Сведения о контрагенте по документу" и "Информацию о представленном документе" (включая повторение "DocumentId").

Допустимо использовать два составных элемента ResponseInfo, в которых будет одинаковый DocumentId.

Какой HTTP код должен вернуть сервис НП, при отправке ответа с типовым элементом Status, который имеет поле Code со значением:
• 411        Структура XML документа не соответствует XSD схеме
• 412        Документы по запрашиваемым критериям поиска отсутствуют
• 435        Количество документов, соответствующих критериям поиска, превышает установленные ограничения
• 500        Непредвиденная ошибка

Для указанных кодов ошибки в XML документе должен использоваться HTTP код 200

Как должна реагировать ИС НП при получении запроса, который не соответствует критериям, описанным в Приложениях к регламенту взаимодействия через ИС организации при проведении НМ?

Например:
1. При получении запроса с некорректным или пустым значением TicketId
2. При получении запроса, не соответствующего критериям описанным в Приложении к регламенту, но соответствующего xsd схеме сценария.
(Длина значения для поля больше, чем указано в Приложении. Но, согласно xsd схеме, данное поле – корректно)

В обновленной версии документов будет либо добавлен код ошибки, либо добавлены проверки на длину в XSD схему.

Согласно политике информационной безопасности наши организации не могут предоставлять в рамках АИС «Налог-3» документы с грифом «Для служебного пользования (ДСП)». Такие документы будут предоставляться в рамках других средств информационного взаимодействия (ТКС). В таком случае, какой Код причины невозможности представления истребуемых документов нам указывать в соответствующем обязательном к заполнению поле (InabilityCode / «КодПричНеПред»)?

Истребуемые документы (информация), пояснения могут быть представлены в налоговый орган лично или через представителя, переданы в электронной форме по телекоммуникационным каналам связи или через информационные системы организации, к которым предоставлен доступ налоговому органу.
Если истребование было направлено через сервисы, не обязательно отвечать через сервисы, допускается использовать другой способ взаимодействия, к примеру ТКС. Соответственно указывать код причины невозможности предоставления документов нет необходимости.

Запросом по сервису 17 налоговый орган направляет в адрес налогоплательщика два файла:
- XML документ, содержащий результат обработки ответа на требование;
- открепленную электронную подпись XML документа, содержащего результат обработки ответа на требование.

В документации сервиса №17 предусмотрено 12 проверок электронной подписи (коды проверок 422-432).

НП возвращает ответ на запрос по сервису 17 в виде типовой структуры ServiceResponse с указанием кода ответа в элементе Status (Статус обработки запроса)
Среди прочих предусмотрен код ответа: "431 Неправильное указание сведений о подписанте в ЭП «Имя_ЭП».

Несоответствие ФИО из элемента Signer\FullName в запросе, ФИО из сертификата налогоплательщика."
При этом в запросе по сервису 17 нет элемента Signer\FullName.

В связи с этим, подскажите, пожалуйста, где взять информацию о "ФИО из сертификата" для осуществления проверки 431?

В обновленной версии документов неиспользуемые коды будут удалены.

В описании составного элемента ResponseDocumentInfo для элементов DocumentId и FilePath прописан признак обязательности "О". Иными словами, может быть приложен только один файл запрошенного документа.

Приказом ФНС России от 19.12.2023 N ЕД-7-26/970@ утверждены отдельные "описания файла обмена счета-фактуры (информации продавца)" и "файла обмена информации покупателя".

Разъясните, пожалуйста, порядок действий при подготовке ответа на требование в соответствии с описанием сервиса №16, в ситуации, когда ФНС запрашивает универсальный передаточный документ, включающий счет-фактуру и универсальный передаточный документ в электронной форме, состоящие из двух xml-файлов: "информация продавца" и "информация покупателя".

Элемент ResponseDocumentInfo входит в ResponseInfo, который является множественным. Соответственно, если надо приложить несколько документов к одному пункту истребования, то используется множественность ResponseInfo

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

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

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

В настоящий момент многие предприятия в своей хозяйственной деятельности, в частности, при формировании электронного УПД, используют ЭП формата sig, например, для подписания документов с КНД 1115131 и 1115132. Просьба подтвердить или опровергнуть допустимость приложения ЭП формата SIG к электронным документам XML при формировании ответа на истребование в рамках сценариев 3 и 12.

В 3 сценарии: Для основного документа используется bin, для приложения тоже используется bin, но еще может прикладываться подпись sgn (если документ отправлялся и был подписан в другой системе). В 12 сценарии: Если в ИС НП присутствуют файлы электронной подписи к представленным документам, которые использовались при обмене между субъектами экономической деятельности, то данные файлы должны быть представлены с расширением sgn. Для файлов электронной подписи, которой подписан документ для передачи в налоговый орган должно быть использовано расширение bin.

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

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