Государственная информационная система о государственных и муниципальных платежах. Форматы взаимодействия Государственной информационной системы о государственных и муниципальных платежах с информационными системами участников. Версия 1.16.0

(утв. Казначейством России 25.09.2014)

Утверждаю Заместитель руководителя Федерального казначейства С. Б. Гуральников 25 сентября 2014 года

ГОСУДАРСТВЕННАЯ ИНФОРМАЦИОННАЯ СИСТЕМА О ГОСУДАРСТВЕННЫХ И МУНИЦИПАЛЬНЫХ ПЛАТЕЖАХ

ФОРМАТЫ ВЗАИМОДЕЙСТВИЯ ГОСУДАРСТВЕННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ О ГОСУДАРСТВЕННЫХ И МУНИЦИПАЛЬНЫХ ПЛАТЕЖАХ С ИНФОРМАЦИОННЫМИ СИСТЕМАМИ УЧАСТНИКОВ

ВЕРСИЯ 1.16.0

КРАТКОЕ СОДЕРЖАНИЕ ИЗМЕНЕНИЙ

Введение

В настоящем документе описываются форматы взаимодействия Государственной информационной системы о государственных и муниципальных платежах (ГИС ГМП) с информационными системами участников.

1. Общие положения

1.1. Термины и обозначения

1.2. Наименование системы

Полное наименование системы: Государственная информационная система о государственных и муниципальных платежах.

Сокращенное наименование системы: ГИС ГМП, Система.

1.3. Информация о версии форматов взаимодействия

Версия форматов — 1.16.0.

2. Сущности ГИС ГМП

ГИС ГМП принимает, хранит и выдает по запросам участников следующие сущности:

• Извещение о начислении, извещение об уточнении начисления, извещение об аннулировании начисления (далее при совместном упоминании — начисление);
• Извещение о приеме к исполнению распоряжения, извещение об уточнении распоряжения, извещение об аннулировании распоряжения (далее при совместном упоминании — платеж).

ГИС ГМП в результате сопоставления данных начисления и платежей создает новые сущности — квитанции, которые могут быть предоставлены по запросу участника.

Далее в настоящей главе описываются назначения сущностей и состав параметров сущностей. Перемещение сущностей между ГИС ГМП и участниками взаимодействия схематически показано на рисунке № 1 «Потоки данных между ГИС ГМП и участниками взаимодействия» и фактически осуществляется с учетом полномочий участника.

                     \/         \/        \/

Рисунок № 1 «Потоки данных между ГИС ГМП и участниками взаимодействия»

2.1. Описание параметров сущностей ГИС ГМП и запросов участников

Сущности ГИС ГМП и запросы участников описаны в формате XSD как XML-типы. Каждый параметр является тегом или атрибутом XML-типа.

Параметры сведены в таблицу со следующими полями:

• Наименование. Наименование тега или атрибута XML-типа.
• Кол-во тегов, обязательность тега или атрибута. Указывает на количество тегов формируемого XML. Формат поля: .., где - минимальное количество тегов, - максимальное количество тегов («n» указывает на неограниченное количество тегов).
• Тип данных. Возможные значения:

String. Строка произвольной длины.

unsignedLong. Целое неотрицательное число от 0 до 18446744073709551615.

Long. Целое число от -9223372036854775808 до 9223372036854775807.

Integer. Целое число от -2147483648 до 147483647.

dateTime. Дата и время, формат определен стандартом XML/XSD, опубликованным по адресу: http://www.w3.org/TR/xmlschema-2/#dateTime.

Date. Дата, формат определен стандартом XML/XSD, опубликованным по адресу: http://www.w3.org/TR/xmlschema-2/#date.

Boolean. Логический тип (Истина/Ложь).

base64Binary. Данные в кодировке Base64, формат определен стандартом XML/XSD, опубликованным по адресу http://www.w3.org/TR/xmlschema-2/#base64Binary.

Контейнер. Указывает на присутствие вложенных тегов. Наименования тегов и атрибутов, вложенных в контейнер, включаются в поле «Наименование» таблицы параметров со смещением вправо.

ID. Уникальный в рамках XML-документа идентификатор, начинающийся с латинской буквы.

Token. Формат определен стандартом XML/XSD, опубликованным по адресу http://www.w3.org/TR/xmlschema-2/#token.

Другой тип. В поле «Тип данных» таблицы присутствует ссылка на соответствующий пункт, в котором описан тип.

• Комментарий. Объясняет назначение тега.

2.2. Начисление

Данные начисления описываются типом ChargeType, приведенным в файле Charge.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 1 «Тип ChargeType».

Таблица № 1

ТИП CHARGETYPE

2.3. Платеж

Данные о платежах приведены в файле Payment.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 2 «Тип PaymentType».

Таблица № 2

ТИП PAYMENTTYPE

2.4. Квитанция

В ГИС ГМП выполняется автоматическое квитирование (сопоставление данных начисления и платежей). Квитирование может осуществляться по следующим параметрам (параметрам квитирования): УИН, сумма, КБК, код ОКТМО, ИНН получателя, КПП получателя, номер банковского счета, БИК банка получателя, идентификатор плательщика. Перечислен полный перечень параметров, которые могут участвовать в квитировании. В зависимости от внутренних настроек ГИС ГМП может быть исключен из процедуры квитирования любой из перечисленных параметров квитирования, кроме УИН и суммы.

Данные квитанций приведены в файле Quittance.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 3 «Тип QuittanceType».

Таблица № 3

ТИП QUITTANCETYPE

2.5. Вспомогательные типы

2.5.1. Тип OrganizationType

Описание типа приведено в файле Organization.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 4 «Тип OrganizationType».

Таблица № 4

ТИП ORGANIZATIONTYPE

2.5.2. Тип AccountType

Тип предназначен для описания реквизитов банковских счетов, открытых следующим организациям:

• ТОФК (для учета поступлений в бюджеты бюджетной системы РФ);
• финансовым органам (для учета средств соответствующих государственных (муниципальных) учреждений);
• государственным (муниципальным) учреждениям (для учета средств государственных (муниципальных) автономных учреждений).

Описание типа приведено в файле Organization.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 5 «Параметры типа AccountType».

Таблица № 5

ПАРАМЕТРЫ ТИПА ACCOUNTTYPE

2.5.3. Тип BankType

Тип предназначен для указания реквизитов структурных подразделений кредитных организаций или подразделений Банка России, являющихся банками получателя, банками плательщика.

Описание типа приведено в файле Organization.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП») и описание параметров приведено в таблице № 6 «Тип BankType».

Таблица № 6

ТИП BANKTYPE

2.5.4. Тип PaymentIdentificationDataType

Тип описывает данные, необходимые и достаточные для идентификации платежа.

Описание типа приведено в файле Payment.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 7 «PaymentIdentificationDataType».

Таблица № 7

PAYMENTIDENTIFICATIONDATATYPE

2.5.5. Тип BudgetIndexType

Тип описывает реквизиты платежа 101, 106 — 110, предусмотренные Приказом Минфина России от 12 ноября 2013 г. № 107н и Положением Банка России от 19 июня 2012 г. № 383-П «О правилах осуществления перевода денежных средств».

Описание типа приведено в файле BudgetIndex.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 8 «Тип BudgetIndexType».

Таблица № 8

ТИП BUDGETINDEXTYPE

2.5.6. Простые типы

2.5.6.1 AccountNumType

2.5.6.2 INNType

2.5.6.3 KPPType

2.5.6.4 OKTMOType

2.5.6.5 KBKType

2.5.6.6 OGRNType

2.5.6.7 BIKType

Тип предназначен для указания банковского идентификационного кода.

Основан на типе String, 9 цифр [0 — 9].

2.5.6.8 SWIFTType

Тип предназначен для указания SWIFT кода банка.

Основан на типе String, 11 или 8 символов [A — Z, 0 — 9].

2.5.6.9 SupplierBillIDType

Тип предназначен для указания УИН.

Основан на типе String, 20 или 25 цифр [0 — 9].

2.5.6.10 URNType

Тип предназначен для указания УРН участника.

Основан на типе String, 6 символов.

3. Порядок формирования идентификаторов в Системе

3.1. Идентификатор начисления

3.1.1 Структура УИН для АН и ГАН, являющихся федеральными органами государственной власти

3.1.2. Структура УИН для АН и ГАН, являющихся органами государственной власти субъектов Российской Федерации, органами местного самоуправления, государственными (муниципальными) учреждениями

3.1.3 Правила расчета контрольного разряда УИН

Контрольный разряд УИН формируется по следующим правилам:

• каждому разряду УИН, начиная со старшего разряда, присваивается набор весов, соответствующий натуральному ряду чисел от 1 до 10, далее набор весов повторяется;
• каждая цифра УИН умножается на присвоенный вес разряда и вычисляется сумма полученных произведений;
• контрольный разряд для УИН представляет собой остаток от деления полученной суммы на модуль «11». Контрольный разряд должен иметь значение от 0 до 9;
• если получается остаток, равный 10, то для обеспечения одноразрядного контрольного разряда необходимо провести повторный расчет, применяя вторую последовательность весов, сдвинутую на два разряда влево (3, 4, 5, 6, 7, 8, 9, 10, 1, 2). Если, в случае повторного расчета, остаток от деления вновь сохраняется равным 10, то значение контрольного разряда проставляется равным «0».

3.2. Идентификатор плательщика

Правила формирования идентификатора плательщика для ЮЛ — резидентов РФ следующие:

• 1 разряд — значение «2» (признак ЮЛ — резидента РФ);
• 2 — 11 разряды — ИНН ЮЛ (10 цифр);
• 12 — 20 разряды — КПП ЮЛ (9 цифр).

Правила формирования идентификатора плательщика для ЮЛ — нерезидентов РФ следующие:

• 1 разряд — значение «3» (признак ЮЛ — нерезидента РФ);
• 2 — 11 разряды — ИНН ЮЛ (10 цифр);
• 12 — 20 разряды — КПП ЮЛ (9 цифр).

Таблица № 9

ПРАВИЛА ФОРМИРОВАНИЯ ИДЕНТИФИКАТОРА ПЛАТЕЛЬЩИКА ДЛЯ ФЛ

где:

• 1 — 2 разряды — код типа документа. Применяются следующие коды типов документов:

Таблица № 10

КОДЫ ТИПОВ ДОКУМЕНТОВ

• 3 — 22 разряды — серия и номер документа (в одну строку, без разделителей; знаки «N» и «-» не указываются; при наличии букв, они должны указываться как заглавные), ссылка на который дана в коде типа документа (1 — 2 разряды). Если номер документ содержит менее 20 символов, он дополняется слева нулями до 20 символов.
• 23 — 25 разряды — цифровой код страны, гражданином которой является плательщик, в соответствии с документом, удостоверяющим личность (в соответствии с Общероссийским классификатором стран мира). Для плательщиков — граждан РФ — указывается значение «643» (код РФ); для лиц без гражданства используется код «999».

3.3. Идентификатор платежа

Каждый платеж должен иметь УИП.

УИП для кредитных организаций должен иметь следующую структуру:

Таблица № 11

СТРУКТУРА УИП ДЛЯ КРЕДИТНЫХ ОРГАНИЗАЦИЙ

где:

• 1 разряд — значение «1».
• 2 — 10 разряды — БИК кредитной организации, структурного подразделения кредитной организации, принявшей платеж.
• 11 — 16 разряды — номер внутреннего структурного подразделения кредитной организации (филиала, дополнительного офиса, кредитно-кассового офиса, операционного офиса, операционной кассы вне кассового узла), принявшего платеж. Номер слева дополняется нулями до 6 символов.
• 17 — 22 разряды — дата платежа в формате «ДДММГГ».
• 23 — 32 разряды — уникальный номер платежа в течение дня для структурного подразделения кредитной организации. Номер слева дополняется нулями до 10 символов.

УИП для ТОФК должен иметь следующую структуру:

Таблица № 12

СТРУКТУРА УИП ДЛЯ ТОФК

где:

• 1 разряд — значение «2».
• 2 — 5 разряды — код ТОФК.
• 6 — 16 разряды — резерв, заполняется нулями.
• 17 — 22 разряды — дата платежа в формате «ДДММГГ».
• 23 — 32 разряды — уникальный номер платежа в течение дня для данного ТОФК. Номер слева дополняется нулями до 10 символов.

УИП для остальных участников, принимающих платежи, должен иметь следующую структуру:

Таблица № 13

СТРУКТУРА УИП ДЛЯ ОСТАЛЬНЫХ УЧАСТНИКОВ

• 8 — 32 разряды — уникальный номер платежа в учетной системе участника. Номер слева дополняется нулями до 25 символов.

4. Порядок взаимодействия ГИС ГМП с информационными системами участников

ГИС ГМП взаимодействует с ИС участников посредством веб-сервиса ГИС ГМП SmevGISGMPService, размещенного в СМЭВ.

4.1. Порядок формирования ответов веб-сервиса на запросы участников

Для обслуживания входящих запросов веб-сервис предоставляет один метод GISGMPTransferMsg, который обрабатывает все запросы от ИС участников. По результатам обработки запроса к веб-сервису, вне зависимости от результата его обработки, формируется ответ веб-сервиса и возвращается ИС участника, направившего запрос. Форматы сообщений запросов и ответов веб-сервиса описаны в главе 5 «Форматы сообщений веб-сервиса, размещенного в СМЭВ».

В случае несоответствия формата запроса настоящим форматам, отсутствия или невалидности ЭП и прочих ошибок в запросе, участник получит уведомление об отказе в приеме к обработке запроса с информацией о выявленной в запросе ошибке. Информация об ошибках, возникающих в процессе обработки запросов, представлена в главе 6 «Перечень контролей».

4.2. Электронные подписи запросов и ответов

Все сообщения от ИС участников должны содержать ЭП-ОВ (ЭП информационной системы, передающей запрос). ЭП должна находиться в заголовке SOAP-пакета сообщения-запроса и соответствовать Методическим рекомендациям версии 2.5.6 (глава 5 «Электронные подписи субъектов взаимодействия — информационных систем»).

При отправке ответа на запрос ИС участника ГИС ГМП накладывает ЭП-ОВ. Подпись располагается в заголовке SOAP-пакета сообщения-ответа и соответствует Методическим рекомендациям версии 2.5.6 (глава 5 «Электронные подписи субъектов взаимодействия — информационных систем»).

4.3. Подпись под сущностью, запросом

Таблица № 14

АЛГОРИТМЫ ФОРМИРОВАНИЯ ПОДПИСИ

Формирование блока ЭП осуществляется в следующем порядке:

1 Формирование шаблона документа:

1.1 Создается элемент Signature;

1.2 К элементу Signature добавляется дочерний элемент SignedInfo;

1.3 К элементу SignedInfo добавляется дочерний элемент CanonicalizationMethod;

1.4 К элементу SignedInfo добавляется дочерний элемент SignatureMethod;

1.5 К элементу SignedInfo добавляется первый дочерний элемент Reference;

1.6 К элементу Reference добавляется дочерний элемент Transforms;

1.7 К элементу Transforms элемента Reference добавляется дочерний элемент Transform (два элемента);

1.8 К элементу Reference добавляется элемент DigestMethod;

1.9 К элементу Reference добавляется элемент DigestValue;

1.10 К элементу Signature добавляется дочерний элемент SignatureValue;

1.11 К элементу Signature добавляется дочерний элемент KeyInfo;

1.12 К элементу KeyInfo добавляется дочерний элемент X509Data;

1.13 К элементу X509Data добавляется дочерний элемент X509Certificate;

1.14 К элементу Signature добавляется дочерний элемент Object;

1.15 К элементу Object добавляется дочерний элемент QualifyingProperties;

1.16 К элементу QualifyingProperties добавляется дочерний элемент SignedProperties;

1.17 К элементу SignedProperties добавляется дочерний элемент SignedSignatureProperties;

1.18 К элементу SignedProperties добавляется дочерний элемент SignedDataObjectProperties;

1.19 К элементу QualifyingProperties добавляется дочерний элемент UnSignedProperties;

1.20 К элементу UnSignedProperties добавляется дочерний элемент UnsignedSignatureProperties;

2 Установка предопределенных значений

2.1 Для элемента CanonicalizationMethod и для второго элемента Transform элемента Reference значения атрибута Algorithm устанавливаются в «http://www.w3.org/2001/10/xml-exc-c14n#».

2.2 Для первого элемента Transform алгоритм выставляется значение «http://www.w3.org/2000/09/xmldsig#enveloped-signature».

2.3 Для элементов DigestMethod первого значения атрибута Algorithm устанавливается в «http://www.w3.org/2001/04/xmldsig-more#gostr3411».

2.4 Для элемента SignatureMethod значение атрибута Algorithm устанавливается в «http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411».

2.5 Атрибут URI элемента Reference должен быть заполнен значением атрибута Id подписываемой сущности.

3 Установка подписи

3.1 Открытый ключ подписи, закодированный по алгоритму «http://www.w3.org/2000/09/xmldsig#base64», добавляется к элементу X509Certificate как дочерний текстовый узел.

3.2 Подписываются элементы документа, выбранные посредством XPATH выражения на основе значения атрибута URI элемента Reference (если элемент URI имеет пустое значение, то подписывается полностью весь тег сущности). Полученное значение кодируется по алгоритму «http://www.w3.org/2000/09/xmldsig#base64» и добавляется как дочерний текстовый узел к элементу DigestValue первого элемента Reference.

3.3 Элемент SignedInfo трансформируется в соответствии с алгоритмом «http://www.w3.org/2001/10/xml-exc-c14n#». Затем на основании полученной строки и ключа подписи формируется значение ЭП в соответствии с алгоритмом «http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411». Полученное значение ЭП кодируется в соответствии с алгоритмом «http://www.w3.org/2000/09/xmldsig#base64», и значение добавляется как дочерний текстовый узел к элементу SignatureValue.

3.4 Элемент QualifyingProperties заполняется в соответствии с описанием, расположенным по адресу: http://www.w3.org/TR/XAdES/#Syntax_overview_The_QualifyingProperties, — для соответствия ЭП формату XadES-T.

5. Форматы сообщений веб-сервиса, размещенного в СМЭВ

5.1. Общий формат веб-сервиса

Права участников на выполнение различных типов запросов определены Порядком ведения ГИС ГМП и приведены в таблице № 15 «Права участников на выполнение различных типов запросов».

Таблица № 15

ПРАВА УЧАСТНИКОВ НА ВЫПОЛНЕНИЕ РАЗЛИЧНЫХ ТИПОВ ЗАПРОСОВ

5.1.1. Сообщение запроса к веб-сервису

Описание сообщения запроса к веб-сервису приведено в таблице № 16 «Структура сообщения запроса к веб-сервису». Сообщения запросов к ГИС ГМП передаются в структуре сообщения СМЭВ (см. Методические рекомендации версии 2.5.6) в элементе AppData. В данный элемент должен быть подставлен элемент RequestMessage, описанный в файле Message.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»).

Таблица № 16

СТРУКТУРА СООБЩЕНИЯ ЗАПРОСА К ВЕБ-СЕРВИСУ

Описание формата элемента RequestMessage приведено в таблице № 17 «Структура RequestMessage».

Таблица № 17

СТРУКТУРА REQUESTMESSAGE

5.1.2. Сообщение ответа от веб-сервиса

Таблица № 18

СТРУКТУРА СООБЩЕНИЯ ОТВЕТА К ВЕБ-СЕРВИСУ

Формат элемента ResponseMessage приведен в таблице № 19 «Структура ResponseMessage».

Таблица № 19

СТРУКТУРА RESPONSEMESSAGE

5.2. Порядок импорта новых сущностей, уточнения или аннулирования ранее загруженных сущностей в ГИС ГМП

Направление извещения о начислении/приеме к исполнению распоряжения в ГИС ГМП участником осуществляется путем выполнения запроса к Системе на импорт начисления/платежа, с указанием в теге ChangeStatus@meaning значения «1».

Направление извещения об уточнении начисления/распоряжения в ГИС ГМП осуществляется путем выполнения запроса к Системе на импорт начисления/платежа, с указанием в теге ChangeStatus@meaning значения «2». При этом должен быть использован тот же УИН/УИП, что и в уточняемом начислении/платеже. Извещением об уточнении начисления, таким образом, является извещение о начислении, аналогичное уточняемому извещению во всех полях, кроме уточняемых, и содержащее в теге ChangeStatus@meaning значение «2». Аналогично, извещением об уточнении распоряжения является извещение о приеме к исполнению распоряжения, аналогичное уточняемому извещению во всех полях, кроме уточняемых, и содержащее в теге ChangeStatus@meaning значение «2».

Направление извещения об аннулировании начисления/распоряжения в ГИС ГМП осуществляется путем выполнения запроса к системе на импорт начисления/платежа, с указанием в теге ChangeStatus@meaning значения «3» и основания аннулирования. При этом должен быть указан тот же УИН/УИП, что и в аннулируемом начислении/платеже соответственно.

5.2.1. Формат запроса на импорт начисления

В сообщении запроса в теге RequestMessage должен передаваться тег ImportRequest. Данные импортируемых начислений должны передаваться в тегах Package/Document/Charge (см. описание в пункте 2.2). Одновременно в составе одного пакета (контейнер Package) в ГИС ГМП может быть передано несколько начислений. В атрибуте originatorID для каждого начисления должен передаваться УРН участника, сформировавшего начисление. Если УРН участника, сформировавшего начисление, совпадает с УРН участника, передающего начисление в ГИС ГМП, то допустимо тег OriginatorID не заполнять.

Запрос на импорт начислений обрабатывается в асинхронном режиме. При этом ответ на запрос будет содержать код одного из трех возможных результатов:

Принятому пакету на стороне ГИС ГМП присваивается идентификатор, возвращаемый в теге ResponseMessage/Ticket/RequestProcessResult/ResultData.

Участник для проверки окончательного статуса приема пакета на стороне ГИС ГМП должен осуществить отдельный запрос статуса обработки импортируемого пакета, описанный в пункте 5.3.

5.2.2. Формат запроса на импорт платежа

В сообщении запроса в теге RequestMessage должен передаваться тег ImportRequest. Данные импортируемых платежей должны передаваться в тегах Package/Document/FinalPayment (см. описание в пункте 2.3). Одновременно в составе одного пакета (контейнер Package) в ГИС ГМП может быть передано несколько платежей. В тегах OriginatorID для каждого платежа должен передаваться УРН участника, сформировавшего платеж. Если УРН участника, сформировавшего платеж, совпадает с УРН участника, передающего платеж в ГИС ГМП, то допустимо тег OriginatorID не заполнять.

Пакету на стороне ГИС ГМП присваивается идентификатор, возвращаемый в теге ResponseMessage/Ticket/RequestProcessResult/ResultData.

Участник взаимодействия для проверки окончательного статуса приема пакета на стороне ГИС ГМП должен осуществить отдельный запрос статуса обработки импортируемого пакета, описанный в пункте 5.3.

5.2.3. Формат ответа

В сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/Ticket/RequestProcessResult с типом ResultInfo, структура которого приведена в файле ErrInfo.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»). Описание параметров приведено в таблице № 20 «Структура ответа на запрос импорта».

Таблица № 20

СТРУКТУРА ОТВЕТА НА ЗАПРОС ИМПОРТА

5.3. Запрос статуса обработки импортируемого пакета

В результате выполнения запросов импорта обеспечивается предварительный прием в ГИС ГМП пакета сущностей. Полный форматно-логический контроль осуществляется после отправки системой участнику сообщения ResponseMessage. Для того, чтобы получить информацию о статусе обработки пакета и о принятии/отклонении извещений на стороне ГИС ГМП, необходимо отправить запрос на получение протокола обработки пакета.

5.3.1. Формат запроса

В сообщении запроса в теге RequestMessage должен передаваться тег PackageStatusRequest, содержащий идентификатор пакета, статус которого необходимо проверить, — PackageID. В качестве идентификатора пакета используется идентификатор, возвращенный участнику в теге ResponseMessage/Ticket/RequestProcessResult/ResultData.

5.3.2. Формат ответа

В случае если обработка пакета на стороне ГИС ГМП еще не завершена, в сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/Ticket/RequestProcessResult с типом ResultInfo (см. описание типа ResultInfo в пункте 5.2.3); при этом ResultCode будет равен значению «50».

В случае если обработка пакета на стороне ГИС ГМП завершена, в сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/TicketPackageProcessResult.

Описание параметров приведено в таблице № 20 «Структура ответа на запрос импорта».

Таблица № 21

СТРУКТУРА ОТВЕТА ЗАПРОС СТАТУСА ОБРАБОТКИ ИМПОРТИРУЕМОГО ПАКЕТА (ЕСЛИ ОБРАБОТКА ПАКЕТА ЗАВЕРШЕНА)

5.4. Экспорт сущностей из ГИС ГМП

5.4.1. Общий формат запроса

В сообщении запроса в теге RequestMessage должен передаваться тег ExportRequest, структура которого приведена в файле MessageData.xsd (глава 7 XML-схемы сущностей и сообщений ГИС ГМП). <...> приведено в таблице № 22 «Структура запроса на экспорт».

Таблица № 22

СТРУКТУРА ЗАПРОСА НА ЭКСПОРТ

5.4.2. Передача ГИС ГМП извещений о начислениях

Атрибут kind запроса ExportRequest может принимать одно из следующих значений:

• CHARGE — используется для запроса неоплаченных начислений;
• CHARGENOTFULLMATCHED — используется для запроса начислений, не полностью сквитированных с платежами (в т.ч. таких, по которым оставшаяся сумма к оплате равна «0», но при этом в начислении и соответствующем ему платеже попарно могут не совпадать какой-либо или несколько атрибутов из следующего набора: КБК, ОКТМО, ИНН, КПП, номер счета, БИК, идентификатор плательщика);
• CHARGESTATUS — используется для запроса начислений и статусов их квитирования;
• CHARGEPRIOR — используется для запроса неоплаченных предварительных начислений;
• CHARGEPRIORNOTFULLMATCHED — используется для запроса предварительных начислений, не полностью сквитированных с платежами;
• CHARGEPRIORSTATUS — используется для запроса предварительных начислений и статусов их квитирования;
• CHARGETEMP — используется для запроса неоплаченных предварительных начислений, сформированных ГИС ГМП;
• CHARGETEMPNOTFULLMATCHED — используется для запроса предварительных начислений, сформированных ГИС ГМП, не полностью сквитированных с платежами;
• CHARGETEMPSTATUS — используется для запроса предварительных начислений, сформированных ГИС ГМП, и статусов их квитирования.

Запросы CHARGE, CHARGENOTFULLMATCHED, CHARGEPRIOR, CHARGEPRIORNOTFULLMATCHED, CHARGETEMP, CHARGETEMPNOTFULLMATCHED доступны для АП/ГАП и АЗ/ГАЗ. Запрос CHARGESTATUS доступен АН/ГАН, АП/ГАП и АЗ/ГАЗ. Запросы CHARGEPRIORSTATUS, CHARGETEMPSTATUS доступны АН/ГАН.

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

5.4.3. Формат ответа на запрос начислений

В сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/ExportChargesResponse, структура которого приведена в файле MessageData.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 23 «Структура ответа на запрос экспорта начислений».

Таблица № 23

СТРУКТУРА ОТВЕТА НА ЗАПРОС ЭКСПОРТА НАЧИСЛЕНИЙ

В случае возникновения ошибки при обработке запроса на экспорт начислений код ошибки возвращается в сообщении ответа в теге AppData/ResponseMessage/Ticket/RequestProcessResult, имеющем тип ResultInfo, который описан в пункте 5.2.3.

5.4.4. Передача ГИС ГМП извещений о приеме к исполнению распоряжений

Атрибут kind запроса ExportRequest может принимать одно из следующих значений:

• PAYMENT — все активные (неаннулированные) платежи;
• PAYMENTMODIFIED — все платежи, имеющие статус уточнения (ChangeStatus@meaning имеет значение «2») или статус аннулирования (ChangeStatus@meaning имеет значение «3»);
• PAYMENTUNMATCHED — все активные (неаннулированные) платежи, для которых в системе отсутствуют соответствующие начисления (не создана ни одна квитанция);
• PAYMENTCANCELLED — аннулированные платежи (ChangeStatus@meaning имеет значение «3»);
• PAYMENTMAINCHARGE — запрос платежей по связанным начислениям (используется только ФССП).

5.4.5. Формат ответа на запрос платежей

В сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/ExportPaymentsResponse, структура которого приведена в файле MessageData.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 24 «Структура ответа на запрос экспорта платежей».

Таблица № 24

СТРУКТУРА ОТВЕТА НА ЗАПРОС ЭКСПОРТА ПЛАТЕЖЕЙ

В случае возникновения ошибки при обработке запроса на экспорт начислений код ошибки возвращается в сообщении ответа в теге AppData/ResponseMessage/Ticket/RequestProcessResult, имеющем тип ResultInfo, который описан в главе 5.2.3.

5.4.6. Экспорт квитанций из ГИС ГМП

В квитанции передается статус квитирования начисления со всеми платежами, но отражается результат квитирования только с последним полученным платежом.

Атрибут kind запроса ExportRequest может принимать одно из следующих значений:

• QUITTANCE — для запросов результатов квитирования, за исключением неактивных (возвращается результат квитирования с последним полученным платежом);
• ALLQUITTANCE — для запросов всех результатов квитирования.

5.4.7. Формат ответа на запрос квитанций

В сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/ExportQuittanceResponse, структура которого приведена в файле MessageData.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 25 «Структура ответа на запрос квитанций».

Таблица № 25

СТРУКТУРА ОТВЕТА НА ЗАПРОС КВИТАНЦИЙ

В случае возникновения ошибки при обработке запроса на экспорт квитанций код ошибки возвращается в сообщении ответа в теге AppData/ResponseMessage/Ticket/RequestProcessResult, имеющем тип ResultInfo, который описан в пункте 5.2.3.

5.5. Квитирование начисления с платежами по инициативе АН/ГАН

Сервис предназначен для проведения принудительного квитирования начисления с платежами по запросу АН/ГАН в тех случаях, когда начисление и платеж не могут быть сквитированы ГИС ГМП автоматически (УИН в начислении и платеже не совпадают, либо УИН отсутствует в платеже). С помощью данного сервиса нельзя изменить уже имеющиеся в ГИС ГМП результаты квитирования. Право на принудительное квитирование начисления с платежами имеет АН или ГАН, сформировавший соответствующее начисление.

5.5.1. Формат запроса

В сообщении ответа в теге AppData присутствует тег RequestMessage/DoAcknowledgmentRequest, структура которого приведена в файле MessageData.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 26 «Структура запроса на проведение квитирования начисления с платежами по инициативе АН/ГАН».

Таблица № 26

СТРУКТУРА ЗАПРОСА НА ПРОВЕДЕНИЕ КВИТИРОВАНИЯ НАЧИСЛЕНИЯ С ПЛАТЕЖАМИ ПО ИНИЦИАТИВЕ АН/ГАН

5.5.2. Формат ответа

В случае успешной обработки запроса в сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/DoAcknowledgmentResponse, структура которого приведена в файле MessageData.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание параметров приведено в таблице № 27 «Структура ответа на запрос проведения квитирования начисления с платежами по инициативе АН».

Таблица № 27

СТРУКТУРА ОТВЕТА НА ЗАПРОС ПРОВЕДЕНИЯ КВИТИРОВАНИЯ НАЧИСЛЕНИЯ С ПЛАТЕЖАМИ ПО ИНИЦИАТИВЕ АН

В случае возникновения ошибки при обработке запроса код ошибки возвращается в сообщении ответа в теге AppData/ResponseMessage/Ticket/RequestProcessResult, имеющем тип ResultInfo, который описан в пункте 5.2.3.

5.6. Квитирование начисления с отсутствующим в ГИС ГМП платежом

Сервис предназначен для проведения принудительного квитирования начисления при отсутствии в ГИС ГМП платежей, соответствующих данному начислению. Право на принудительное квитирование такого начисления имеют АН и ГАН, сформировавшие это начисление и получившие информацию о его оплате иным способом (не из ГИС ГМП).

5.6.1. Формат запроса

Запрос на принудительное квитирование начисления с отсутствующим в ГИС ГМП платежом осуществляется посредством того же сообщения, что и запрос на принудительное квитирование начисления с платежами по инициативе АН/ГАН, описанного в пункте 5.5.1. Для указания необходимости принудительного квитирования с отсутствующим в ГИС ГМП платежом в контейнере Payments должен содержаться единственный элемент PaymentSystemIdentifier, заполненный значением «PaymentNotLoaded».

5.6.2. Формат ответа

Ответ на запрос на принудительное квитирование начисления с отсутствующим в ГИС ГМП платежом возвращается посредством того же сообщения, что и ответ на запрос на принудительное квитирование начисления с платежами по инициативе АН/ГАН, описанного в пункте 5.5.2.

В случае появления ошибки при обработке запроса в сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/Ticket/RequestProcessResult типа ResultInfo, который описан в пункте 5.2.3.

5.7. Установление платежу статуса «Услуга предоставлена»

Сервис предназначен для установления платежам, переданным в ГИС ГМП, статуса «Услуга предоставлена». Права на проставление платежу статуса «Услуга предоставлена» имеют:

• АЗ с полномочиями органа ЗАГС;
• ГАЗ, участником косвенного взаимодействия которого является АЗ с полномочиями органа ЗАГС.

5.7.1. Формат запроса

Запрос на установление платежам, загруженным в ГИС ГМП, статуса «Услуга предоставлена» осуществляется посредством того же сообщения, что и запрос на принудительное квитирование начисления с платежами, загруженными в ГИС ГМП, описанного в главе 5.5.1.

Тег SupplierBillID должен быть заполнен значением «ChargeNotLoaded».

Контейнер Payments должен содержать уникальные идентификаторы платежей, которым необходимо проставить статус «Услуга предоставлена».

5.7.2. Формат ответа

В случае если установление статуса «Услуга предоставлена» прошло успешно для всех указанных в запросе платежей, сообщение ответа в теге AppData будет содержать тег AppData/ResponseMessage/Ticket/RequestProcessResult типа ResultInfo, который описан в главе 5.2.3. В теге ResultCode будет передаваться значение «0».

В случае появления ошибки (платежи отсутствуют в ГИС ГМП) сообщение ответа в теге AppData будет содержать тег ResponseMessage/DoAcknowledgmentResponse, описанный в главе 5.5.2. Тег будет содержать контейнер PaymentsNotFound, в котором будут перечислены те УИП из запроса, по которым не были найдены платежи. Если какой-либо УИП из запроса не был возвращен в контейнере PaymentsNotFound, это значит, что платеж с таким УИП был найден и ему был успешно проставлен статус «Услуга предоставлена».

5.8. Формирование ГИС ГМП начисления с признаком «Предварительное начисление»

Сервис предназначен для формирования ГИС ГМП начисления с признаком «Предварительное начисление». Права на отправку запроса на формирование начисления с признаком «Предварительное начисление» имеют АЗ и ГАЗ.

5.8.1. Формат запроса

В сообщении запроса в теге AppData должен присутствовать тег RequestMessage/ChargeCreationRequest, структура которого приведена в файле MessageData.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание элементов приведено в таблице № 28 «Структура запроса на формирование предварительного начисления».

Таблица № 28

СТРУКТУРА ЗАПРОСА НА ФОРМИРОВАНИЕ ПРЕДВАРИТЕЛЬНОГО НАЧИСЛЕНИЯ

Таблица № 29

ТИП CHARGETEMPLATETYPE

5.8.2. Формат ответа

В сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/ChargeCreationResponse, структура которого приведена в файле MessageData.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание элементов приведено в таблице № 30 «Структура ответа на запрос формирования предварительного начисления».

Таблица № 30

СТРУКТУРА ОТВЕТА НА ЗАПРОС ФОРМИРОВАНИЯ ПРЕДВАРИТЕЛЬНОГО НАЧИСЛЕНИЯ

В случае возникновения ошибки при обработке запроса формирования предварительного начисления код ошибки возвращается в сообщении ответа в теге AppData/ResponseMessage/Ticket/RequestProcessResult, имеющем тип ResultInfo, который описан в пункте 5.2.3.

5.9. Загрузка и обновление сертификатов ключа проверки ЭП участников

Сервис предназначен для централизованного сбора и обновления сертификатов ключа проверки ЭП участников прямого взаимодействия.

5.9.1. Формат запроса

В сообщении запроса в теге AppData должен присутствовать тег RequestMessage/ImportCertificateRequest, структура которого приведена в файле MessageData.xsd (глава 7 «XML-схемы сущностей и сообщений ГИС ГМП»), описание элементов приведено в таблице № 31 «Структура запроса на загрузку или обновление сертификата ключа проверки ЭП участников».

Таблица № 31

СТРУКТУРА ЗАПРОСА НА ЗАГРУЗКУ ИЛИ ОБНОВЛЕНИЕ СЕРТИФИКАТА КЛЮЧА ПРОВЕРКИ ЭП УЧАСТНИКОВ

5.9.2. Формат ответа

В сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/TicketPackageProcessResult, состоящий из набора элементов EntityProcessResult, каждый из которых описывает статус обработки одного из загружаемых сертификатов ключа проверки ЭП. Атрибут entityId элемента EntityProcessResult соответствует атрибуту ownership обработанного сертификата. В случае успешной обработки сертификата участника в теге EntityProcessResult/ResultCode передается значение «0»; в случае неуспешной — код соответствующей ошибки. Перечень кодов ошибок приведен в главе 5.9.

6. Перечень контролей

В процессе обработки запросов ГИС ГМП осуществляет контроли и результаты обработки доводит до инициатора запросов с описанием выявленных ошибок.

В таблице ниже приводится перечень проводимых контролей и возможных ошибок.

Таблица № 32

ПЕРЕЧЕНЬ КОНТРОЛЕЙ

7. XML-схемы сущностей и сообщений ГИС ГМП (не приводится)

8. WSDL веб-сервиса, размещенного в СМЭВ (не приводится)