В параметрах запроса указывается значение из справочника SPVDOC.В справочнике SPVDOC есть следующие значения: KOD NAIM NAIMK
0180000001 Агентский договор Агентский договор
0180000003 Договор купли-продажи земельных участков Договор купли-продажи
0180000008 Договор аренды Договор аренды
0180000010 Договор аренды земельного участка Договор аренды
0180000011 Договор банковского счета Договор счета
0180000023 Договор купли-продажи объекта недвижимости Договор купли-продажи
0180000025 Договор найма жилого помещения Договор найма
0180000031 Договор перевозки груза Договор перевозки
0180000037 Договор поставки Договор поставки
0180000039 Договор складского хранения Договор хранения
0180000049 Договор транспортной экспедиции Договор экспедиции
0180000051 Договор финансовой аренды (лизинга) Договор аренды
0180000052 Договор финансовой субаренды (сублизинга) Договор субаренды
0180000053 Договор фрахтования Договор фрахтования
0180000054 Договор хранения Договор хранения
0180000064 Договор перевозки Договор перевозки
0180000065 Договор купли-продажи основного средства Договор купли-продажи
0180000067 Договор подряда на выполнение работ Договор подряда
0180000081 Договор возмездного оказания услуг Договор оказания услуг
Они относятся не к первичным документам, а к справочной информации – договорам с контрагентами. Также в параметрах указывается период предоставления данных: Дата начала отчетного периода, к которому относится документ «DateFrom», Дата окончания отчетного периода, к которому относится документ «DateTo». Возникает вопрос: по какому принципу отбирать договоры по значению периода: по сроку действия договора, по использованию в документах в периоде запроса, возможно, другой вариант? Поясните, пожалуйста, какие данные необходимо отправлять в ответ на запрос по договорам.
Договоры с контрагентами - это юридически значимые документы, которые являются документами-основаниями для дальнейших операций. Большинство сделок выполняются в рамках договорных отношений и невозможны без заключения договоров. Если в рамках одного договора осуществляется, например, несколько поставок по нескольким накладным (счетам-фактурам), то договор будет являться документом-основанием. Реквизиты документа-основания указываются в параметрах: DocumentBaseCode, DocumentBaseName, DocumentBaseNumber, DocumentBaseDate. В случае разовых сделок договор может отсутствовать, тогда параметры, относящиеся к документу-основанию могут не заполняться. Даты начала и окончания отчетного периода служат фильтром для отбора документов. Так, например, поставка в рамках определенного договора, который был заключен ранее, была осуществлена в отчетном периоде - тогда первичные документы по поставке (накладная, счет-фактура и т.п.) должны входить в реестр. Договор-основание также указывается уже независимо от даты, когда он был заключен.
Таблица 4.5 Сведения о передаваемом документе (СвПрдДок): • НаимДок - Указывается номер, дата и наименование документа – поясните суть элемента, какими данными его заполнять. Правильно понимаем, что заполняется в свободной форме?
Атрибут Файл/Документ/СвПрдДок/@НаимДок - наименование, реквизиты или иные индивидуализирующие признаки документа – указываются номер, дата и наименование (в таком предпочтительном порядке). Четких формализованных требований нет. Но есть ограничение на количество символов – до 1000 символов в строке.
Таблица 4.2. Состав и структура документа (Документ) - Код документа по КНД: • Код документа по КНД - Принимает значение согласно Приложению № 10 – Такого приложения не найдено, или поясните где это приложение, как заполнять поле?
В последующем планируются изменения в описании без изменений схемы. В настоящий момент Приложению №10 соответствует Приложение №4. Параметр КНД – это код документа по КНД.
Среди фильтров присутствует период, за который необходимо предоставить реестр. Какой код ответа необходимо вернуть, если документы по запрошенному периоду отсутствуют?
Если запрос по контрагенту, по которому нет документов за запрашиваемый период, то ответ должен содержать код 412 - документы по запрашиваемому контрагенту в системе отсутствуют. Если нет документов по указанному коду вида документов, то указывается код 413 - документы по запрашиваемому коду вида документа (категории документа) в системе отсутствуют. В случае, если запрос в рамках конкретной декларации, то ситуация, при которой документы за период отсутствуют, невозможна. В ответном реестре включаются все имеющиеся документы.
Сервис «registerRequestToPublishSourceDoc» - запрос на доразмещение документа в электронный архив. По результату ответа на данный сервис дополнительный документ должен быть дополнен / до размещён в реестре документов. После доразмещения ответ сервиса «getDocumentList» должен дополниться с учетом результатов дозапроса RegisterRequestToPublishSourceDoc?
В результате запроса дополнительный документ должен быть доразмещен в электронном архиве информационной системы НП. К предоставлению реестра документов данный сервис отношения не имеет - это два независимых сервиса. После получения запроса на доразмещение документа ИС НП направляет ответ в синхронном режиме в виде типовой структуры ServiceResponse. Данный ответ свидетельствует о том, что запрос получен. Далее после доразмещения документа (если такое возможно) налогоплательщик направляет запрос в структуре PublishDocResponse, что такой-то документ размещен. Сервис getDocumentList никак не связан с данным процессом.
Что содержит параметр запроса RequestId. Чем он отличается от Ticket_Id? Для чего в запросе передается параметр TaxInspectionCode (Код налогового органа)? Как влияет на запрос на доразмещение параметр KppNmOp (КПП обособленного подразделения)?
RequestId – это уникальный идентификатор запроса на доразмещение документов, в то время как TicketId – идентификатор запроса (он должен быть уникальным в числе всех поступаемых запросов, а не только в сервисе на доразмещение документов). Параметр TaxInspectionCode передается в составе элемента Body, для того, чтобы было понятно, от какого именно налогового органа исходит запрос, аналогично и параметр RequesterName (ФИО налогового инспектора, опубликовавшего запрос). Параметр KppNmOp (КПП обособленного подразделения или филиала) является необязательным и может указываться в случаях, когда запрос на доразмещение касается какой-либо декларации, поданной этим обособленным подразделением или филиалом.
Как влияет на отбор реквизит запроса KppNmOp? Как отличить первичные документы по обособленному подразделению? Если первичный документ не зависит от обособленного подразделения, должен ли он попадать в отбор по обособленному подразделению? Для чего в параметре запроса передается TaxInspectionCode? Как этот реквизит влияет на отбор первичных документов? В состав ответа по запросу входят поля, связанные с суммами налога:
a. DocumentSumNet (Сумма по документу без налога, всего (руб,коп) и
b. DocumentSumGross (Сумма налога по документу, всего (руб, коп))
c. Правильно ли мы понимаем, что речь тут идет о налоге НДС?
По какому правилу нужно определять документ основание?
a. Для бухгалтерских операций это может быть договор
b. Для Счетов-фактур это может быть договор и накладная
c. Для некоторых документов это не договор, и в базе 1С нет документа-основания
Параметр KppNmOp является необязательным. Может указываться, если запрашивается, например, информация по декларации, поданной данным обособленным подразделением либо в случае, если взаимоотношения с конкретным контрагентом осуществлялись только данным обособленным подразделением. В ответе на запрос данный параметр не указывается. Отбор первичных документов должен исходить из контекста запроса. TaxInspectionCode – код налогового органа, указывается код НО, от которого пришел запрос. На отбор первичных документов данный параметр не влияет.
Да, правильно. Параметр DocumentSumGross является необязательным и указывается в случае применимости данного параметра к конкретному документу. Данный показатель применим к тем документам, где выделен НДС. Это сумма НДС по документу. Параметр DocumentSumNet – это сумма по документу без налога. Документ-основание – это документ, который дает правовое основание для осуществления и отражения в учете операций. Если для первичного документа, например, счета-фактуры имеется документ-основание, например, договор, в рамках которого осуществляется поставка/реализация, то договор будет являться документом-основанием. Параметры, относящиеся к реквизитам документа основания, в настоящее время являются необязательными.
Параметры DateFrom и DateTo объявлены как даты начала и окончания квартала. Значит ли это что запросы от АИС "Налог-3" за меньший период невозможны?
Параметры DateFrom и DateTo - это границы отчетного периода, которым может быть как месяц, так и квартал, полугодие, год, определенные в запросе, в зависимости от того, к какому отчетному периоду относится документ. Для некоторых случаев отчетным периодом может являться месяц.
В Приложение № 4 к регламенту взаимодействия через информационную систему организации "Сервис предоставления реестра документов, размещенных в электронном архиве информационной системы налогоплательщика" появился новый (по сравнению с вариантом сервиса в 2021 году) параметр "Body", который содержит дополнительно реквизиты "DocumentCode", "DocumentCatCode". Данные реквизиты подразумевают возможность передачи массива "Видов и Категорий документов для предоставления. В связи с этим вопрос на конкретном примере. В декларации по налогу на прибыль расшифровка строки 011 приложения 1 к листу 02 - "Выручка от реализации товаров (работ, услуг) собственного производства" производится по первичным документам. Например, в расшифровку данной строки включается документ "Акт приема-передачи электроэнергии" на сумму 1000 руб. Может ли из АИС "Налог-3" прийти запрос, в котором в качестве фильтра будет указан «"DocumentCode" = "0180000057" Договор энергоснабжения»? То есть, если ставить вопрос шире: Должна ли ИС налогоплательщика "уметь" передавать по запросу Приложения № 4 информацию об объектах, не связанных напрямую с финансовыми показателями в декларации по налогу на прибыль (передавать информацию о приказах, служебных записках, договорах и т.п.)?
Элемент Body - тело запроса, является составным и содержит параметры самого запроса. Например, параметр RegNumber - регистрационный номер декларации, по которой осуществляется запрос соответствующих первичных документов, или парметры Inn и Kpp - ИНН и КПП контрагента, по которому запрашиваются документы, отражающие взаимоотношения налогоплательщика с данным контрагентом. Также запрос может быть ограничен параметрами: DocumentCatCode (Код категории документа по справочнику KDOC) и DocumentCode (Код вида документа по справочнику SPVDOC), которые являются необязательными и, следовательно, могут отсутствовать в запросе. Обращаем внимание, что данные справочники унифицируют виды и категории документов. Т.е. в запросе может быть требование представить конкретную категорию документов (договор, накладная, декларация и т.п.) по её коду и вид документа (акт выполненных работ по инжиниринговым услугам, договор купли-продажи, агентский договор и т.п.). И в случае наличия у налогоплательщика первичных документов, соответствующих требованиям запроса, их необходимо включить в реестр. Что касается конкретного примера, то в реестр должны попадать документы, соответствующие запросу либо по конкретной декларации (всё, что касается исчисления данного налога и за налоговый/отчетный период конкретной декларации), либо по взаимоотношениям с конкретным контрагентом. Таким образом, запрос может касаться любого другого налога, либо не иметь отношения к налогу. В рамках взаимоотношений с контрагентом могут участвовать любые документы, которые могут не влиять на формирование каких-либо финансовых показателей.
В Приложение № 4 к регламенту взаимодействия через информационную систему организации "Сервис предоставления реестра документов, размещенных в электронном архиве информационной системы налогоплательщика" имеется параметр "TicketId" длиной в 32 символа. В 1С это например "Передача ОС" который регистрирует реализацию ОС и формирует на уровне проводок доходную часть (Кт 91 счета) и расходную часть (Дт91 счета.) В этом случае у нас имеется один документ с одним уникальным GUID, который участвует в формировании строк дохода и расхода. Будет ли ошибкой передавать один документ (и один уникальный guid) и по расходу и по доходу? Если это будет являться ошибкой, то длины поля 32 символа будет недостаточно, так как к GUID документа надо будет прибавить размерность поля уникальности записи проводки (например 3-4 символа) и в этом случае необходимая размерность поля получится в 35-36 символов.
Параметр TicketId - это идентификатор запроса, который содержится в запросе реестра документов и который должен указываться налогоплательщиком в ответе на запрос, чтобы сохранялась связь (на какой запрос налогового органа направлен ответ). В ответе на запрос параметр TicketId копируется из параметра TicketId структуры GetDocumentListRequestType. К идентификаторам первичных документов, находящихся в информационной системе налогоплательщика данный параметр отношения не имеет.
Вашего вопроса нет в списке?
Напишите нам, и мы постараемся оперативно на него ответить.
