| Будет ли использоваться сценарий 4 для запроса реестров документов для уточненных налоговых деклараций (УНД)? |
| Данный сценарий может использоваться для любых деклараций, в т.ч. уточненных налоговых деклараций. |
| В сценарии сказано: Датой отправки считается дата, указанная в параметре Date, структуры RegisterAvailableFileResponse, возвращаемой на вызов registerAvailableFile, при возврате кода ответа равного 200-операция успешна. Какой часовой пояс должен быть указан при отправке запроса? |
| Время направления документа в электронной форме определяется в соответствии со временем часовой зоны, в которой расположен отправитель. |
| Планируется, что подписание контейнеров по сценарию 3 возможно только с помощью усиленной квалифицированной электронной подписи? Будет ли возможность подписания контейнеров по сценарию 3 неквалифицированной электронной подписью, к примеру? |
| Каждый файл, размещенный в транспортном контейнере, должен быть только с усиленной квалифицированной электронной подпись (ЭП) |
| Должен ли налогоплательщик вернуть ответ автоматически после завершения планового срока исполнения запроса? Должен ли налогоплательщик иметь возможность исполнить запрос после истечения планового срока ответа? |
|
ИС НП передает в ИС НО запрос в структуре PublishDocResponse со статусом: 1- Запрос исполнен | 2- Запрос не исполнен | 3- Запрос исполнен частично. А также указывается причина неисполнения (частичного исполнения) запроса. |
| В ответ на обработку входящего запроса, ИС НП может отправить ответ: 413 - Документы по запрашиваемому коду вида документа (категории документа) в системе отсутствуют. В каких сценариях необходимо вернуть такой код? |
| Код ошибки 413 - "Указывается если передан неверный или неизвестный идентификатор требования DocRequestId. Запрос считается неисполненным. Необходимо повторить вызов сервиса с указанием корректного идентификатора требования". Данный код ИС НП может вызвать только при реализации Сервиса № 16 - Сервис направления ответа на требование о представлении документов (информации) |
| Если взаимодействие по ответам на требования осуществляется не в рамках сценария "файловый обмен", то каким образом налогоплательщик должен будет ответить на требование. |
|
При отсутствии в информационной системе налогоплательщика реализованного Сервиса №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. |
| В каких случаях формируется СОШ и в каких протокол ошибок? |
| Проверки для формирования СОШ описаны в разделе «Проверки, выполняемые НП после получения транспортного контейнера от НО» в документе УФТК. СОШ - это критичные ошибки, связанные с распаковкой и проверкой ТК. Протокол ошибок формируется при ошибках, несвязанных с распаковкой и проверкой содержимого ТК. |