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

В Приложение № 4 к регламенту взаимодействия через информационную систему организации "Сервис предоставления реестра документов, размещенных в электронном архиве информационной системы налогоплательщика" имеется параметр "TicketId" длиной в 32 символа. В 1С это например "Передача ОС" который регистрирует реализацию ОС и формирует на уровне проводок доходную часть (Кт 91 счета) и расходную часть (Дт91 счета.) В этом случае у нас имеется один документ с одним уникальным GUID, который участвует в формировании строк дохода и расхода. Будет ли ошибкой передавать один документ (и один уникальный guid) и по расходу и по доходу? Если это будет являться ошибкой, то длины поля 32 символа будет недостаточно, так как к GUID документа надо будет прибавить размерность поля уникальности записи проводки (например 3-4 символа) и в этом случае необходимая размерность поля получится в 35-36 символов.

Параметр TicketId - это идентификатор запроса, который содержится в запросе реестра документов и который должен указываться налогоплательщиком в ответе на запрос, чтобы сохранялась связь (на какой запрос налогового органа направлен ответ). В ответе на запрос параметр TicketId копируется из параметра TicketId структуры GetDocumentListRequestType. К идентификаторам первичных документов, находящихся в информационной системе налогоплательщика данный параметр отношения не имеет.

При выполнении отбора данных для сервиса «Предоставление реестра документов» должны ли мы ограничиваться только теми документами, которые участвуют в формировании налоговой базы по налогу на прибыль?

Нет. Предоставление реестра документов осуществляется по запросу налогового органа. Условия отбора документов указываются в запросе. Например, параметр RegNumber - регистрационный номер декларации, в таком случае реестр документов должен содержать все документы, которые послужили основанием для расчета налога по конкретной декларации. Или запрос может касаться всех документов по взаимоотношениям с контрагентам, тогда в запросе указываются парампетры Inn, Kpp - ИНН и КПП контрагента. Данный перечень может быть ограничен конкретным видом документа по справочнику.

Предоставления реестра документов. Атрибут DocumentDate «Дата документа». Имеется в виду дата первичного документа хоз.операции или дата принятия ее к учету у налогоплательщика? Например, дата счета-фактуры на бумажном носителе или дата получения и принятия к учету оригинала счета-фактуры? Есть ли разная трактовка этой даты в зависимости от сценария?

DocumentDate - это дата конкретного первичного документа, на основании которого фиксируется хозяйственная операция. Аналогично и другие реквизиты: номер (DocumentNumber) и наименование (DocumentName).

В состав элемента Document добавлены новые атрибуты: О каком налоге идет речь? НДС? Для каких налоговых деклараций и хозяйственных операций релевантны данные поля?

Предоставление реестра документов осуществляется по запросу налогового органа. Условия отбора документов указываются в запросе. Если условием является параметр RegNumber - регистрационный номер декларации, то реестр документов должен содержать все документы, которые послужили основанием для расчета налога по указанной декларации. Если условием является Inn, Kpp - ИНН и КПП контрагента, то реестр документов содержит все документы по взаимоотношениям с указанным контрагентам.

Прошу пояснить, как должны отрабатывать сервисы «Получение документа для просмотра» и «Получение реестра документа» в случае, если к одной хозяйственной операции привязаны несколько документов. Например, отражение в учете операции «входящая услуга» по следующим документам: «Акт выполненных работ» (основной документ) и «Реестр» (приложение к основному документу). Учитывая, что сервис «Получение документа для просмотра» не предполагает передачу архива (допустимые форматы: ms-excel, ms-word, pdf, rtf, jpeg, tiff, xml, oxml-word, oxml-spreadsheet), то мы сможем предоставить для просмотра не более одного документа по одной хозяйственной операции. Следовательно, представляем доступ только к одному основному документу - «Акту выполненных работ». Прошу подтвердить правильно ли мы понимаем логику работы сервиса. То же самое касается сервиса «Получение реестра документа». В соответствии с описанием реестр документов предполагает, что хозяйственные операции (бухгалтерские проводки) должны быть расшифрованы, в том числе в разрезе идентификационных номеров первичного документа с указанием параметра «Сумма» по документу. В случае, если к одной хозяйственной операции привязаны несколько документов, то каким образом нам следует заполнять реестр документов: - одной строкой, с указанием реквизитов только основного документа? - несколькими строчками по всем привязанным документам? Но в таком случае будет дублироваться показатель «Сумма» и итог не сойдется с суммой по строке декларации.

Для сервисов «Получение документа для просмотра» и «Получение реестра документа» не используется связка операция – документ. В рамках Сервиса 4 "Представление реестра документов.." должны отражаться только документы, имеющие скан-образы. Каждому скан-образу первичного учетного документа должен соответствовать свой уникальный идентификатор, по которому налоговый орган может запросить документ на просмотр в рамках Сервиса 5 .

При отправке реестра документов необходимо заполнять параметр "Регистрационный номер декларации". Правильно ли мы понимаем, что регистрационный номер декларации – это номер, который присваивает налоговый орган при приемке декларации?

Регистрационный номер декларации (RegNumber) – это номер, который присваивает налоговый орган при приеме декларации. В случае подачи декларации в электронном виде посредством ТКС регистрационный номер указывается в квитанции о приеме.

Согласно Приложению №4, следует включать в реестр только документы, раскрытые в виде электронных сканов или идентифицировать документы по всем хозяйственным операциям, которые могут входить в запрос? Не каждый документ, отражающий хозяйственную операцию, может быть раскрыт электронным сканом. Должен ли такой документ иметь уникальный идентификатор для АИС "Налог-3"?

В реестр должны содержаться только документы, имеющие скан-образы. Каждому скан-образу первичного учетного документа должен соответствовать свой уникальный идентификатор.

Согласно Приложению №4 реестр документов помимо самого документа должен содержать его документ-основание. Есть ли какие-то формальные правила по соответствию документа и документа-основания (например: счет-фактура – договор; товарная накладная – счет-фактура)? Или предприятие может указывать документы-основания по своему усмотрению?

Документ-основание - это всегда договор.

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

Доразмещение документа - это сохранение скан-образа документа в электронный архив, который ранее не был там размещен. Доразмещение документа не влечет за собой обновление связей «документ-операция-декларация», т.к. метаданные о документе уже есть в списке операций.

Согласно имеющейся документации текущий функционал сервиса «Получение документов из ИС НП для просмотра» не предполагает передачу нескольких файлов в рамках одного запроса. Как поступить в случае, если к одному идентификатору документа (проводки) относится несколько документов-оснований (ПУД)?

Каждому скан-образу первичного учетного документа должен соответствовать свой уникальный идентификатор, который присваивает информационная система налогоплательщика.

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

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