"Государственная информационная система о государственных и муниципальных платежах. Форматы взаимодействия Государственной информационной системы о государственных и муниципальных платежах с информационными системами участников. Версия 1.16.3." (утв. Казначейством России 21.10.2016)

Утверждаю
Заместитель руководителя
Федерального казначейства
С.Б.ГУРАЛЬНИКОВ
21 октября 2016 года

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

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

ВЕРСИЯ 1.16.3

Код документа:
17711538.26.99,99.15.008-1.0 1(2, 3, 5, 6)

Краткое содержание изменений

Введение

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

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

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

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

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

Версия форматов - 1.16.3.

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

- извещение о начислении, извещение об уточнении начисления (при уточнении информации, необходимой для уплаты денежных средств), извещение об аннулировании начисления (при аннулировании информации, необходимой для уплаты денежных средств), извещение о деаннулировании начисления (при восстановлении ранее аннулированной информации, необходимой для уплаты денежных средств). Далее при совместном упоминании - начисление;

- извещение о приеме к исполнению распоряжения, извещение об уточнении распоряжения (при уточнении информации об уплате денежных средств), извещение об аннулировании распоряжения (при аннулировании информации об уплате денежных средств). Далее при совместном упоминании - платеж.

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

Далее в настоящей главе описываются назначения сущностей и состав параметров сущностей. Перемещение сущностей между ГИС ГМП и участниками взаимодействия схематически показано на Рисунке ниже (см. Рисунок N 1 "Потоки данных между ГИС ГМП и участниками взаимодействия").

Рисунок N 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. Логический тип (Истина/Ложь). Принимает значения "true" или "false".

- 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), описание параметров приведено в таблице ниже (Таблица N 1 "Тип ChargeType"). Описание контролей параметров приведено в разделе 2.2.1.

Таблица N 1

ТИП CHARGETYPE

2.2.1. Описание контролей параметров начисления

В процессе загрузки начисления осуществляются следующие проверки значений параметров:

1. Идентификатор документа - обязательный атрибут "Id"

Проверяется формат атрибута:

- длина не более 50 символов;

- первый символ должен быть буквой (A - Z).

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

2. Уникальный идентификатор начисления (УИН) - обязательный атрибут "SupplierBillID"

Проверяется формат атрибута: строка длиной 20 букв или цифр или 25 цифр.

Маска ввода:

\w{20}

\d{25}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Дополнительно проверяется:

А) Если длина поля 20 символов, то проверяется (согласно требованиям раздела 6):

- отсутствие букв в УИН при значении 1 в поле "Статус изменения";

- значение в тэге ChangeStatus - если в УИНе нового начисления есть буквы, то возвращается код ошибки "238" - "Наличие букв в УИН недопустимо";

- невырожденность уникального номера начисления: 16 цифр, указанных в разрядах с 4 по 19, не могут все одновременно быть = 0. Если все 16 цифр = 0, то возвращается код ошибки "237" - "Некорректный формат УИН";

- контрольный разряд УИН - значение 20-го разряда УИН (алгоритм расчета контрольного разряда приведен в разделе 3.1.3) - если значение в 20-м разряде не соответствует рассчитанному значению, то возвращается код ошибки "234" - "Контрольный разряд УИН имеет некорректное значение";

- соответствие длины УИН требованиям к порядку его формирования - если отправитель начисления не входит в перечень участников, которые должны формировать УИН в соответствие с п. 3.1.1 настоящего документа, то возвращается код ошибки "51" - "Длина УИН не соответствует требованиям к порядку его формирования".

Б) Если длина поля 25 цифр, то проверяется (согласно требованиям раздела 6):

- невырожденность уникального номера начисления: 16 цифр, указанных в разрядах с 9 по 24 УИН, не могут все одновременно быть = 0. Если все 16 цифр = "0", то возвращается код ошибки "237" - "Некорректный формат УИН";

- равенство первых 8 цифр УИН (после перевода из десятичного представления в шестнадцатеричное) значению уникального регистрационного номера (УРН) Участника. В случае неуспешной проверки возвращается код "10" - "Некорректный УРН в УИН";

- контрольный разряд УИН - значение 25-го разряда УИН (алгоритм расчета контрольного разряда приведен в разделе 3.1.3) - если значение в 25-м разряде не соответствует рассчитанному значению, возвращается код ошибки "234" - "Контрольный разряд УИН имеет некорректное значение";

- соответствие длины УИН требованиям к порядку его формирования - если отправитель начисления не входит в перечень участников, которые должны формировать УИН в соответствие с п. 3.1.2 настоящего документа, то возвращается код ошибки "51" - "Длина УИН не соответствует требованиям к порядку его формирования".

3. Дата и время начисления суммы, подлежащей уплате плательщиком - обязательный атрибут "BillDate"

Проверяется формат поля: должно содержать значение даты/времени (формат определен стандартом XML/XSD, опубликованным по адресу http://www.w3.org/TR/xmlschema-2/#date). В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется, что дата начисления не ранее 1 января 2013 года - если дата начисления ранее, чем 1 января 2013 года, то возвращается код ошибки "52" - "Начисление от даты ранее 2013 года не подлежит передаче в ГИС ГМП" (см. раздел 6).

Проверяется, что дата начисления не может превышать дату загрузки более чем на одни сутки. Если условие не выполняется, то возвращается код ошибки "56" - "Дата сущности не может превышать дату загрузки более чем на одни сутки" (см. раздел 6).

4. Дата, до которой включительно актуально выставленное начисление, - необязательное поле "ValidUntil"

(если дата не указана - начисление в Системе не имеет срока давности)

Проверяется формат поля: должно содержать значение даты (формат определен стандартом XML/XSD, опубликованным по адресу http://www.w3.org/TR/xmlschema-2/#date). В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

5. Дата отсылки плательщику документа с начислением - необязательное поле "DocDispatchDate"

(заполняется в случае, если документ был вручен плательщику получателем средств)

Проверяется формат поля: должно содержать значение даты (формат определен стандартом XML/XSD, опубликованным по адресу http://www.w3.org/TR/xmlschema-2/#date). В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

6. Уникальные идентификаторы (УИН) начислений, на основании которых выставлено данное начисление, - необязательное поле MainSupplierBillIDList/MainSupplierBillID

Проверяется:

- количество связанных начислений в списке - разрешается указать не более 9 идентификаторов связанных начислений;

- формат каждого идентификатора в списке, согласно формату УИН (п. 2 настоящего раздела).

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7. Данные организации, являющейся получателем средств, - обязательный блок данных "SupplierOrgInfo"

Выполняются форматные проверки полей блока (описаны ниже). В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.1. Наименование организации - обязательное поле "Name"

Проверяется формат поля: длина поля от 1 до 160 символов. В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.2. ИНН организации - обязательное поле "INN"

Проверяется формат поля: 10 цифр, и при этом первый и второй знаки (цифры) не могут одновременно принимать значение ноль ("0").

Маска ввода:

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется, что значение поля ИНН организации совпадает с ИНН организации, загружающей начисление (в перечне Участников осуществляется поиск организации с УРН=SenderIdentifier), или с ИНН организации, создавшей начисление (в перечне Участников осуществляется поиск организации с УРН=OriginatorID), и эта организация является подведомственной для организации, загружающей начисление. В случае неуспешных проверок возвращается код "302" - "Попытка загрузки в систему информации другого участника" (см. раздел 6).

7.3. КПП организации - обязательное поле "KPP"

Проверяется формат поля: длина поля 9 символов, пятый и шестой из которых могут быть прописными (заглавными) латинскими буквами или цифрами, а все остальные только цифрами, и при этом первый и второй знаки (цифры) не могут одновременно принимать значение ноль ("0").

Маска ввода:

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется, что значение поля КПП организации совпадает с КПП организации, загружающей начисление (в перечне Участников осуществляется поиск организации с УРН=SenderIdentifier), или с КПП организации, создавшей начисление (в перечне участников осуществляется поиск организации с УРН=OriginatorID), и эта организация является подведомственной для организации, загружающей начисление. В случае неуспешных проверок возвращается код "302" - "Попытка загрузки в систему информации другого участника" (см. раздел 6).

7.4. ОГРН организации - необязательное поле "OGRN"

Если значение указано, проверяется формат поля: 13 цифр.

Маска ввода: \d{13}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.5. Реквизиты счета организации - обязательный блок данных "Account":

7.5.1. Номер банковского счета - обязательное поле "AccountNumber"

Проверяется формат поля: 20 цифр.

Маска ввода: \d{20}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.5.2. Данные банка, в котором открыт счет - обязательный блок данных "Bank"

7.5.2.1. Наименование структурного подразделения кредитной организации или подразделения Банка России, в котором открыт счет - необязательное поле "Name"

Если значение указано, то проверяется длина поля: разрешается указать от 1 до 200 символов. В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.5.2.2. БИК структурного подразделения кредитной организации или подразделения Банка России, в котором открыт счет, - обязательное поле "BIK", альтернативное к полю "SWIFT" (п. 7.5.2.3 настоящего раздела)

Если значение указано, то проверяется формат поля: 9 цифр.

Маска ввода: \d{9}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.5.2.3. Код SWIFT иностранного банка, в котором открыт счет, - обязательное поле "SWIFT", альтернативное к полю "BIK" (п. 7.5.2.2 настоящего раздела)

Если значение указано, то проверяется формат поля: длина поля либо 11, либо 8 символов, среди которых допускаются прописные (заглавные) латинские буквы и цифры.

11 символов - маска ввода: [A-Z0-9]{11};

8 символов - маска ввода: [A-Z0-9]{8}.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.5.2.4. Номер корреспондентского счета кредитной организации, открытый в подразделении Банка России, - необязательное поле "CorrespondentBankAccount"

Проверяется формат поля: 20 цифр.

Маска ввода: \d{20}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

8. Назначение платежа - обязательное поле "BillFor"

Проверяется формат поля: разрешается указать от 1 до 210 символов в назначении платежа. В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

9. Сумма начисления в копейках - обязательное поле "TotalAmount"

Проверяется формат поля: тип "unsignedLong" - целое неотрицательное число от 0 до 18446744073709551615. В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется отсутствие нулевого значения в данном поле при условии, что начисление не является предварительным (поле "Origin" не заполнено). В случае нулевой суммы - возвращается код ошибки "40" - "Извещение о начислении имеет нулевую сумму".

10. Сведения о статусе начисления и основаниях его изменения - обязательный блок данных "ChangeStatus"

10.1. Статус, отражающий изменение данных начисления, - обязательный атрибут "meaning"

Проверяются допустимые значения атрибута (1 символ): "1", "2", "3" или "4". В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Если значение "1" (новое начисление) - проверяется отсутствие ранее загруженного начисления с таким же УИН. При попытке загрузить неуникальное начисление возвращается код ошибки "5" - "Импортируемые данные уже присутствуют в системе" (см. раздел 6).

Если значение "2" (уточнение) или "3" (аннулирование) - проверяется, что начисление с таким УИН не было ранее аннулировано. При попытке уточнить или аннулировать аннулированное ранее начисление возвращается код ошибки "7" - "Не найден исходный документ (файл)" (см. раздел 6).

Если значении "4" (деаннулирование) - проверяется, что начисление с таким УИН ранее было аннулировано. При попытке деаннулировать не аннулированное начисление возвращается код ошибки "7" - "Не найден исходный документ (файл)" (см. раздел 6).

10.2. Основание изменения начисления - необязательное поле "Reason"

Если атрибут "meaning" (см. п. 10.1 настоящего раздела) принимает значение "3", то проверяется обязательность заполнения. Если загружается изменение начисления, но при этом значение в поле "Reason" не указано, то возвращается код ошибки "39" - "Не указано основание аннулирования" (см. раздел 6).

Если значение в поле "Reason" указано, то проверяется длина поля: допускается от 1 до 512 символов. В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

11. КБК - обязательное поле "KBK"

Проверяется формат поля: значение "0" или 20 символов, среди которых допускаются русские и латинские буквы и цифры.

Маска ввода [0-9a-zA-Zа-яА-Я]{20}

Проверяется, что все символы одновременно не принимают значение ноль ("0").

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Если по данному начислению предполагается поступление средств на счет, первые цифры которого - "40101" (значение в поле "AccountNumber", требования к заполнению поля приведены в п. 7.5.1 настоящего раздела), то значение поля "KBK" не может быть равно "0". Если условие не выполнено, то возвращается код ошибки "233" - "Некорректное значение КБК" (см. раздел 6).

Если в поле "KBK" значение не равно "0", то проверяется, что значение поля "KBK" не совпадает со значением поля УИН (значение в поле "SupplierBillID"). Если это условие не выполнено, то возвращается код ошибки "53" - "КБК не может совпадать с УИН" (см. раздел 6).

12. Код ОКТМО - обязательное поле "ОКТМО"

Проверяется формат поля: значение "0" или 8 или 11 цифр; при этом три нуля не могут быть впереди.

Маски ввода:

\d{8}

или значение "0".

Проверяется отсутствие нулей во всех 8 или 11 разрядах данного поля.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Если по данному начислению предполагается поступление средств на счет, первые цифры которого - "40101" (значение в поле "AccountNumber", требования к которому приведены в п. 7.5.1 настоящего раздела), то значение поля "ОКТМО" не может быть равно "0". Если это условие не выполнено, то возвращается код ошибки "232" - "Некорректное значение кода по ОКТМО" (см. раздел 6).

13. Реквизиты платежа 101, 106 - 110 - обязательный блок данных "BudgetIndex"

13.1. Статус плательщика (реквизит 101) - обязательное поле "Status"

Проверяется формат поля: строка длиной 2 символа, допустимые значения - 01, 02, ..., 26. В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

13.2. Показатель основания платежа (реквизит 106) - обязательное поле "Purpose"

Проверяется формат поля: строка длиной 2 символа, допустимые значения - ТП, ЗД, БФ, ТР, РС, ОТ, РТ, ПБ, ПР, АП, АР, ИН, ТЛ, ЗТ, ДЕ, ПО, КТ, ИД, ИП, ТУ, БД, КП, ВУ, ДК, ПК, КК, ТК, 00, 0.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

13.3. Налоговый период или код таможенного органа (реквизит 107) - обязательное поле "TaxPeriod"

Проверяется формат поля: значение "0" или строка длиной 10 или 8 символов.

Если длина значения в поле 10 символов, то:

- символы 1-й и 2-й могут принимать значение: МС, КВ, ПЛ, ГД;

- символы 4-й и 5-й могут принимать значение: для месячных платежей - номер месяца текущего отчетного года, для квартальных платежей - номер квартала, для полугодовых - номер полугодия;

- символы с 7-го по 10-й могут принимать значение: год, за который производится уплата налога;

- символы 3-й и 6-й используются в качестве разделительных знаков, в них проставляется точка (".").

Маски ввода:

МС\.(0[0-9]|1[012])\.\d{4}

КВ\.(0[1-4])\.\d{4}

ПЛ\.(0[1-2])\.\d{4}

ГД\.00\.\d{4}

Допускается указывать дату в формате "день.месяц.год".

Маска ввода:

(0[1-9]|[12][0-9]|3[01])\.(0[1-9]|1[012])\.\d{4}

Если длина поля 8 символов, то все они должны быть цифрами.

Маска ввода:

\d{8}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

13.4. Показатель номера документа (реквизит 108) - обязательное поле "TaxDocNumber"

Проверяется формат поля: длина строки от 1 до 15 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

13.5. Показатель даты документа (реквизит 109) - обязательное поле "TaxDocDate":

Проверяется формат поля: значение "0" или строка длиной 10 символов.

Если длина значения в поле 10 символов, то:

- 1-й и 2-й символы обозначают календарный день (могут принимать значения от 01 до 31);

- 4-й и 5-й символы обозначают месяц (значения от 01 до 12);

- символы с 7-го по 10-й обозначают год;

- символы 3-й и 6-й используются в качестве разделительных знаков (значение "." (точка)).

Маска ввода:

(0[1-9]|[12][0-9]|3[01])\.(0[1-9]|1[012])\.\d{4}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

13.6. Показатель типа платежа (реквизит 110) - необязательное поле "PaymentType"

Если значение указано, то проверяется формат поля: значение "0" или строка длиной 2 символа (прописные (заглавные) русские буквы).

Маска ввода:

[А-Я]{2}

или значение "0".

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

14. Идентификатор плательщика для ЮЛ или ИП - обязательное поле "UnifiedPayerIdentifier" (альтернативное к полю "AltPayerIdentifier" - п. 15)

Проверяется формат поля, согласно требованиям раздела 3.2.1.

Маски ввода:

2\d{14}[A-Z0-9]{2}\d{3}

3\d{14}[A-Z0-9]{2}\d{3}|3\d{9}[A-Z0-9]{2}\d{3}

4\d{12}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется невырожденность идентификатора согласно правилам (см. раздел 3.2.1) при длине идентификатора 13, 15 или 20 символов, а именно: если, начиная со второго все последующие символы "0", то возвращается код ошибки "236" - "Некорректное значение идентификатора плательщика" (см. раздел 6).

15. Идентификатор плательщика для ФЛ - обязательное поле "AltPayerIdentifier" (альтернативное к полю "UnifiedPayerIdentifier" - п. 14 настоящего раздела):

Проверяется формат поля на соответствие правилам формирования идентификатора плательщика (см. раздел 3.2.2.).

Маска ввода:

((0[1-9])|(1[0-5])|(2[124567]))[0-9а-zA-Zа-яА-Я]{20}\d{3}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется невырожденность идентификатора плательщика (см. раздел 3.2.2.), при длине идентификатора 25 символов, а именно: если позиции начиная с 3 по 22 заполнены "0", то возвращается код ошибки "236" - "Некорректное значение идентификатора плательщика" (см. раздел 6).

16. Сокращенное наименование ТОФК - необязательное поле "TreasureBranch"

При наличии значения контролируется длина строки: от 1 до 255 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

17. Код ТОФК - необязательное поле "TOFK"

При наличии значения контролируется длина строки: 4 символа.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

18. Сокращенное наименование финансового органа - необязательное поле "FOName"

При наличии значения контролируется длина строки: от 1 до 512 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

19. Номер лицевого счета получателя или финансового органа в ТОФК - необязательное поле

При наличии значения в поле контролируется длина строки: 11 символов, среди которых допускаются латинские буквы и цифры.

Маска ввода: \w{11}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

20. Номер лицевого счета получателя в финансовом органе - необязательное поле

При наличии значения контролируется длина строки: от 1 до 20 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

21. Количество дней для получения акцепта плательщика - необязательное поле "AcptTerm"

Любое целое положительное число (тип integer).

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

22. Условие оплаты - необязательное поле "PaytCondition"

Целое положительное число (тип integer) с допустимыми значениями:

- "1" - заранее данный акцепт плательщика;

- "2" - требуется получение акцепта плательщика.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

23. Признак начисления: "Предварительное начисление" - необязательное поле "Origin"

При наличии значения контролируются допустимые значения:

- "PRIOR" - предварительные начисления, загруженные в ГИС ГМП Участником;

- "TEMP" - предварительные начисления, сформированные ГИС ГМП по запросу участника (со сроком действия).

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

24. Дополнительные поля начисления - необязательный блок данных "AdditionalData":

24.1. Наименование поля - обязательное поле "Name"

При наличии значения контролируется длина строки: от 1 до 100 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

24.1 Значение поля - обязательное поле "Value"

При наличии значения контролируется длина строки: от 1 до 255 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

25. Электронная подпись xml-документа - обязательный блок данных "Signature":

Проверяется формат данных ЭП, в случае ошибки возвращается код "13" - "ЭП под сущностью (запросом) не верна" (см. раздел 6).

Проверяется корректность ЭП, в случае ошибки возвращаются код ошибки "33" - "Неверный сертификат ключа проверки ЭП под сущностью (запросом)" (см. раздел 6).

2.3. Платеж

Данные о платежах приведены в файле Payment.xsd (глава 0. "XSD-схемы сущностей и сообщений ГИС ГМП"), описание параметров приведено в таблице ниже (см. Таблица N 2 "Тип PaymentType"). Описание контролей параметров приведено в разделе 2.3.1)

Таблица N 2

ТИП PAYMENTTYPE

2.3.1. Описание контролей параметров платежа

В процессе загрузки извещения о приеме к исполнению распоряжения плательщика (далее - платеж) осуществляются следующие проверки значений параметров:

1. Идентификатор документа - обязательный атрибут "Id":

Проверяется формат поля:

- длина не более 50 символов;

- первый символ должен быть буквой (A - Z).

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

2. Уникальный идентификатор начисления (УИН) - необязательное поле "SupplierBillID":

Проверяется обязательность заполнения тэга. Если первые цифры номера банковского счета получателя средств (значение в поле "AccountNumber", требования к заполнению поля приведены в разделе 2.5.2 настоящего документа) не равны "40302", то возвращается код ошибки "305" - "В извещении о приеме к исполнению распоряжения не указан УИН".

Проверяется формат поля: значение "0" или строка длиной 20 букв или цифр или 25 цифр.

Маска ввода:

\w{20}

\d{25}

или значение "0"

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Дополнительно проверяется:

А) Если длина поля 20 символов, то проверяется (согласно требованиям раздела 6):

- невырожденность уникального номера начисления: 16 цифр, указанных в разрядах с 4 по 19, не могут все одновременно быть равными "0". Если все 16 цифр равны "0", то возвращается код ошибки "237" - "Некорректный формат УИН";

- контрольный разряд УИН: если значение в 20-м разряде не соответствует рассчитанному значению (алгоритм расчета контрольного разряда приведен в разделе 3.1.3), то возвращается код ошибки "234" - "Контрольный разряд УИН имеет некорректное значение";

- несовпадение значения УИН (значение в поле "SupplierBillID") со значением КБК (значение в поле "KBK"). Если это условие не выполнено, то возвращается код ошибки "53" - "КБК не может совпадать с УИН" - (см. раздел 6).

Б) Если длина поля 25 символов, то проверяется (согласно требованиям раздела 6):

- невырожденность уникального номера начисления: 16 цифр, указанных в разрядах с 9 по 24 УИН, не могут все одновременно быть равными "0". Если все 16 цифр равны "0", то возвращается код ошибки "237" - "Некорректный формат УИН";

- контрольный разряд УИН: если значение в 25-м разряде не соответствует рассчитанному значению (алгоритм расчета контрольного разряда приведен в разделе 3.1.3), то возвращается код ошибки "234" - "Контрольный разряд УИН имеет некорректное значение";

В) Если значение поля "0" (и при этом дата в поле "AccDocDate" больше или равно 28.03.2016, и по данному начислению не предполагается поступление средств на счет, первые цифры которого "40302" (поле "AccountNumber", требования к которому приведены в п. 11.4.1 настоящего раздела), то проверяется, что значение идентификатора плательщика (значение в поле "PayerIdentifier") не равно "0". Если оба поля имеют значение "0", то возвращается код ошибки "54" - "УИН и Идентификатор плательщика не могут одновременно быть равны 0";

3. Назначение платежа - обязательное поле "Narrative":

Проверяется формат поля: разрешается указать от 1 до 210 символов в назначении платежа.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

4. Сумма платежа в копейках - обязательное поле "Amount":

Проверяется формат поля: тип "unsignedLong" - целое неотрицательное число от 0 до 18446744073709551615. В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется отсутствие нулевого значения в данном поле, в случае ошибки возвращается код "32" - "Извещение о приеме к исполнению распоряжения имеет нулевую сумму платежа".

5. Дата и время приема к исполнению распоряжения плательщика - обязательное поле "PaymentDate":

Проверяется формат поля: должно содержать значение даты/времени (формат определен стандартом XML/XSD, опубликованным по адресу http://www.w3.org/TR/xmlschema-2/#date). В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется, что дата приема к исполнению распоряжения плательщика не может превышать дату загрузки платежа в ГИС ГМП более чем на одни сутки. Если условие не выполняется, то возвращается код ошибки "56" - "Дата сущности не может превышать дату загрузки более чем на одни сутки" (см. раздел 6).

Проверяется, что дата приема к исполнению распоряжения плательщика больше или равна "01.01.1993". Если условие не выполняется, то возвращается код ошибки "304" - "Попытка загрузки платежа с датой приема к исполнению распоряжения плательщика ранее "01.01.1993" (см. раздел 6).

6. Дата поступления распоряжения в банк плательщика - необязательное поле "ReceiptDate":

При наличии проверяется формат поля: должно содержать значение даты (формат определен стандартом XML/XSD, опубликованным по адресу http://www.w3.org/TR/xmlschema-2/#date). В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Если заполнен блок данных "Bank" (в составе данных, необходимых для идентификации платежа "PaymentIdentificationData"), то дополнительно проверяется заполнение поля "ReceiptDate". Если поле не заполнено, то возвращается код ошибки "38" - "Не указана дата поступления распоряжения в банк плательщика" - (см. раздел 6).

7. Реквизиты платежа 101, 106 - 110 - необязательный блок данных "BudgetIndex":

Проверяется обязательность заполнения. Если первые цифры номера банковского счета получателя средств (значение в поле "AccountNumber", требования к заполнению поля приведены в разделе 2.5.2 настоящего документа) не равны "40302", то возвращается код ошибки "306" - "В извещении о приеме к исполнению распоряжения не указаны реквизиты платежа 101, 106 - 110".

7.1 Статус плательщика (реквизит 101) - обязательное поле "Status":

Проверяется формат поля: строка длиной 2 символа с допустимыми значениями 01, 02, ..., 26. В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.2 Показатель основания платежа (реквизит 106) - обязательное поле "Purpose":

Проверяется формат поля: длина строки "2", допустимые значения: ТП, ЗД, БФ, ТР, РС, ОТ, РТ, ПБ, ПР, АП, АР, ИН, ТЛ, ЗТ, ДЕ, ПО, КТ, ИД, ИП, ТУ, БД, КП, ВУ, ДК, ПК, КК, ТК, 00, 0.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.3 Налоговый период или код таможенного органа (реквизит 107) - обязательное поле "TaxPeriod":

Проверяется формат поля: значение "0" или строка длиной 10 или 8 символов.

Если длина поля 10 символов, то:

- 1-й, 2 символы могут принимать значение: МС, КВ, ПЛ, ГД;

- 4-й, 5-й символы могут принимать значение: для месячных платежей - номер месяца текущего отчетного года, для квартальных платежей - номер квартала, для полугодовых - номер полугодия;

- символы с 7-го по 10-й могут принимать значение: год, за который производится уплата налога;

- символы 3-й, 6-й используются в качестве разделительных знаков, в них проставляется точка (".").

Маски ввода:

МС\.(0[0-9]|1[012])\.\d{4}

КВ\.(0[1-4])\.\d{4}

ПЛ\.(0[1-2])\.\d{4}

ГД\.00\.\d{4}

Также может указываться дата в формате "день.месяц.год".

Маска ввода:

(0[1-9]|[12][0-9]|3[01])\.(0[1-9]|1[012])\.\d{4}

Если длина поля 8 символов, то все они должны быть цифрами.

Маска ввода:

\d{8}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.4 Показатель номера документа (реквизит 108) - обязательное поле "TaxDocNumber":

Проверяется формат поля: длина строки от 1 до 15 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.5 Показатель даты документа (реквизит 109) - обязательное поле "TaxDocDate":

Проверяется формат поля: значение "0" или строка длиной 10 символов, при этом:

- первые два символа обозначают календарный день (могут принимать значения от 01 до 31);

- 4-й и 5-й символы - месяц (значения от 01 до 12);

- с 7-го по 10-й - год;

- в 3-м и 6-м символах в качестве разделительных знаков проставляется точка (".").

Маска ввода:

(0[1-9]|[12][0-9]|3[01])\.(0[1-9]|1[012])\.\d{4}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

7.6 Тип платежа (реквизит 110) - необязательное поле "PaymentType":

Если значение указано, то проверяется формат поля: значение "0" или строка длиной 2 символа (прописные (заглавные) русские буквы).

Маска ввода:

[А-Я]{2}

или значение "0".

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

8. Данные, необходимые для идентификации распоряжения, - обязательный блок данных "PaymentIdentificationData":

8.1 альтернативный выбор из трех обязательных полей:

- или реквизиты структурного подразделения кредитной организации, принявшего платеж, - поле "Bank":

- или признак иного способа проведения платежа - поле "Other":

- или УРН участника, принявшего платеж - поле "UFK":

8.1.1 Данные банка плательщика - обязательный блок данных "Bank":

8.1.1.1 Наименование структурного подразделения банка, в котором открыт счет плательщика, - необязательное поле "Name":

Проверяется формат поля: разрешается указать от 1 до 200 символов в наименовании организации - получателя средств.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

8.1.1.2 БИК структурного подразделения банка, в котором открыт счет, - обязательное поле "BIK": (альтернативное к полю "SWIFT" - п. 8.1.1.3)

Если значение указано, то проверяется формат поля: 9 цифр.

Маска ввода: \d{9}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

8.1.1.3 Код SWIFT иностранного банка, в котором открыт счет, - обязательное поле "SWIFT": (альтернативное к полю "BIK" - п. 8.1.1.2)

Если значение указано, то проверяется формат поля: длина строки либо 11, либо 8 символов, среди которых допускаются прописные (заглавные) латинские буквы и цифры.

Маска ввода 11 символов: [A-Z0-9]{11};

Маска ввода 8 символов: [A-Z0-9]{8}.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

8.1.1.4 Номер корреспондентского счета банка, открытый в подразделении Банка России - необязательное поле "CorrespondentBankAccount":

Проверяется формат поля: 20 цифр.

Маска ввода: \d{20}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

8.1.2 Признак иного способа проведения платежа - обязательное поле "Other":

Если в составе данных для идентификации платежа заполнено данное поле, проверяется, что значение поля равно "CASH".

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

8.1.3 УРН Участника, принявшего платеж, - поле "UFK":

Проверяется формат поля: 4 цифр или 6 букв и цифр.

Маска ввода:

\d{4}

[a-zA-Z0-9]{6}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

8.2 УИП, присвоенный платежу загрузившей организацией, - обязательное поле "SystemIdentifier":

Проверяется формат поля - только цифры или латинские буквы (буквы допускаются в позициях 2 - 7, если первая цифра "3"), маска ввода: \w{32}.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется структура идентификатора, в зависимости от вида организации, передающей платеж: КО, ТОФК, иной Участник (требования к структуре описаны в разделе 3.3):

- если первая цифра "2", то со 2-го по 5-й символы должно быть указано значение поля "UFK";

- если первая цифра "3", то со 2-го по 7-й символы должно быть указано значение поля "OriginatorID" (УРН получателя платежа). Описание поля "OriginatorID" приведено в разделе 5.2.2).

При нарушении структуры возвращается код ошибки "235" - "УИП имеет некорректный формат" (см. раздел 6).

Проверка структуры даты и сопоставление ее со значением в поле "PaymentDate" (требования к структуре описаны в разделе 3.3):

- если первая цифра "1" или "2", то дата в позициях с 17-й по 24-ю должна быть равна дате, указанной в поле "PaymentDate";

- если первая цифра "3", то дата в позициях с 8-й по 15-ю должна быть равна дате из поля "PaymentDate".

При нарушении структуры возвращается код ошибки "55" - "Дата в УИП не равна дате приема к исполнению распоряжения плательщика" (см. раздел 6).

9. Реквизит платежного документа - необязательный блок данных "AccDoc":

9.1 Номер платежного документа необязательное поле "AccDocNo":

Проверяется формат поля: от 1 до 6 цифр.

Маска ввода: \d{1,6}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

9.2 Дата платежного документа - обязательное поле "AccDocDate":

Проверяется формат поля: должно содержать значение даты (формат определен стандартом XML/XSD, опубликованным по адресу http://www.w3.org/TR/xmlschema-2/#date). В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

10. Сведения о плательщике - необязательный блок данных "Payer"

Проверяется обязательность заполнения. Если первые цифры номера банковского счета получателя средств (значение в поле "AccountNumber", требования к заполнению поля приведены в разделе 2.5.2 настоящего документа) не равны "40302", то возвращается код ошибки

"307" - "В извещении о приеме к исполнению распоряжения не указаны сведения о плательщике (идентификатор плательщика)".

10.1 Идентификатор плательщика ФЛ/ЮЛ (ИП) - необязательное поле "PayerIdentifier":

Проверяется обязательность заполнения. Если первые цифры номера банковского счета получателя средств (значение в поле "AccountNumber", требования к заполнению поля приведены в приведены в разделе 2.5.2 настоящего документа) не равны "40302", то возвращается код ошибки "307" - "В извещении о приеме к исполнению распоряжения не указаны сведения о плательщике (идентификатор плательщика)".

Проверяется формат поля согласно требованиям раздела 3.2.

Маски ввода:

2\d{14}[A-Z0-9]{2}\d{3}

3\d{14}[A-Z0-9]{2}\d{3}|3\d{9}[A-Z0-9]{2}\d{3}

4\d{12}

((0[1-9])|(1[0-5])|(2[124567]))[0-9a-zA-Zа-яА-Я]{23}

"0"

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется невырожденность идентификатора:

- при длине в 13, 15 и 20 символов: со второго все последующие символы не могут одновременно быть = "0";

- при длине в 25 символов: символы с 3 по 22 не могут одновременно быть = "0";

В этих случаях возвращается код ошибки "236" - "Некорректное значение идентификатора плательщика" (см. раздел 6).

Если значение поля "0" (и при этом дата в поле AccDocDate больше или равна даты "28.03.2016" и первые цифры номера банковского счета получателя средств (значение в поле "AccountNumber", требования к заполнению поля приведены в разделе 2.5.2 настоящего документа) не равны "40302"), то проверяется, что УИН (значение в поле "SupplierBillID") имеет не нулевое значение. Если оба поля имеют значение "0", то возвращается код ошибки "54" - "УИН и Идентификатор плательщика не могут одновременно быть равны 0" (см. раздел 6).

10.2 Наименование плательщика - необязательное поле "PayerName":

При наличии значения контролируется длина строки: не более 160 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

10.3 Номер счета плательщика - необязательное поле "PayerAccount":

При наличии значения контролируется длина строки: не более 20 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

11. Сведения о получателе средств - обязательный блок данных "Payee"

Выполняются форматные проверки полей блока (описаны ниже).

11.1 Сокращенное наименование получателя средств и данные реквизита "Получатель" распоряжения - обязательное поле "PayeeName":

Проверяется формат поля: длина строки от 1 до 500 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

11.2 ИНН получателя средств - обязательное поле "payeeINN"

Проверяется формат поля: 10 цифр, и при этом первый и второй знаки (цифры) не могут одновременно принимать значение ноль ("0").

Маска ввода:

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

11.3 КПП получателя средств - обязательное поле "payeeKPP"

Проверяется формат поля: строка длиной 9 символов, пятый и шестой из которых могут быть прописными (заглавными) латинскими буквами или цифрами, а все остальные только цифрами, и при этом первый и второй символы (цифры) не могут одновременно принимать значение ноль ("0").

Маска ввода:

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

11.4 Реквизиты расчетного счета получателя средств - обязательный блок данных "PayeeBankAcc"

11.4.1 Номер банковского счета - обязательное поле "AccountNumber":

Проверяется формат поля: 20 цифр.

Маска ввода: \d{20}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

11.4.2 Данные банка, в котором открыт счет, - обязательный блок данных "Bank"

11.4.2.1 Наименование структурного подразделения банка, в котором открыт счет, - необязательное поле "Name"

Если значение указано, то проверяется длина поля: разрешается указать от 1 до 200 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

11.4.2.2 БИК структурного подразделения банка, в котором открыт счет - обязательное поле "BIK", альтернативное к полю "SWIFT" (п. 11.4.2.3 настоящего раздела)

Если значение указано, то проверяется формат поля: 9 цифр.

Маска ввода: \d{9}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

11.4.2.3 Код SWIFT иностранного банка, в котором открыт счет, - обязательное поле "SWIFT", альтернативное к полю "BIK" (п. 11.4.2.2. настоящего раздела)

Если значение указано, то проверяется формат поля: строка с длиной либо 11, либо 8 символов, среди которых допускаются прописные (заглавные) латинские буквы и цифры.

Маска ввода 11 символов: [A-Z0-9]{11};

Маска ввода 8 символов: [A-Z0-9]{8}.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

11.4.2.4 Номер корреспондентского счета банка, открытый в подразделении Банка России, - необязательное поле "CorrespondentBankAccount"

Проверяется формат поля: 20 цифр.

Маска ввода: \d{20}

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

12. Идентификатор получателя услуги - необязательное поле "RecipientServicesIdentifier" (Заполняется в случае, если плательщик не является получателем услуги)

Если поле заполнено, применяются все проверки, описанные в пункте 10.1 текущего раздела.

13. Дополнительный идентификатор получателя услуги в учетной системе получателя средств - необязательное поле "PayerPA":

Если поле заполнено, то проверяется длина строки - от 1 до 50 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

14. Сведения о статусе платежа - обязательный блок данных "ChangeStatus":

14.1 Статус платежа - обязательный атрибут "meaning":

Проверяются допустимые значения атрибута (1 символ): "1", "2", "3". В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Если значение равно "1" (новый платеж), то проверяется отсутствие ранее загруженного платежа с таким же УИП. При попытке загрузить неуникальный платеж возвращается код ошибки "5" - "Импортируемые данные уже присутствуют в системе" (см. раздел 6).

Если значение равно "2" (уточнение) или "3" (аннулирование), то проверяется, что платеж с таким УИП не был аннулирован ранее. При попытке уточнить или аннулировать аннулированный ранее платеж возвращается код ошибки "7" - "Не найден исходный документ (файл)" (см. раздел 6).

14.2 Основание изменения платежа - необязательное поле "Reason"

Если атрибут "meaning" (см. п. 14.1 настоящего раздела) принимает значение "3" (аннулирование), то поле "Reason" обязательно для заполнения. В случае неуспешной проверки возвращается код ошибки "39" - "Не указано основание аннулирования" (см. раздел 6).

Если значение в поле "Reason" указано, то проверяется длина поля: разрешается указать от 1 до 512 символов. В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

15. Код КБК - необязательное поле "KBK"

Проверяется обязательность заполнения. Если первые цифры номера банковского счета получателя средств (значение в поле "AccountNumber", требования к заполнению поля приведены в разделе 2.5.2 настоящего документа) не равны "40302", то возвращается код ошибки "308" - "В извещении о приеме к исполнению распоряжения не указан КБК".

Проверяется формат поля: значение "0" или строка длиной 20 символов, среди которых допускаются русские и латинские буквы и цифры.

Маски ввода:

[0-9a-zA-Zа-яА-Я]{20};

или значение "0".

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется, что все знаки одновременно не принимают значение ноль ("0"). В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Проверяется ненулевое значение в поле "KBK" при условии, что по данному начислению предполагается поступление средств на счет, первые цифры которого "40101" (поле "AccountNumber", требования к значению которого приведены в п. 11.4.1 настоящего раздела). Если это условие не выполнено, то возвращается код ошибки "233" - "Некорректное значение КБК" - (см. раздел 6).

Если значение в поле "KBK" не равно "0", то проверяется, что значение в поле "KBK" не совпадает со значением УИН (значением в поле "SupplierBillID"). Если это условие не выполнено, то возвращается код ошибки "53" - "КБК не может совпадать с УИН" - (см. раздел 6).

16. Вид операции (шифр платежного документа) - необязательное поле "TransKind"

Если поле заполнено, то проверяется формат: строка длиной 2 символа, допустимые значения: "01", "02", "06", "16", "ПД".

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Если поле "TransKind" имеет значение "02" или "16", то статус плательщика (значение в поле "BudgetIndex/Status"), КПП получателя средств (значение в поле "Payee/PayeeKPP") могут иметь значение "0", и допускается значение "0" одновременно в УИН (значение поля "SupplierBillID") и в идентификаторе плательщика (значение поля "PayerIdentifier").

17. Содержание операции - необязательное поле "TransContent"

Указывается при частичном исполнении распоряжения: строка длиной не более 16 символов. В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

18. Условие оплаты (акцепт плательщика) - необязательное поле "PaytCondition"

Допускается одна цифра, значение "1" или "2".

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

19. Количество дней для получения акцепта плательщика - необязательное поле "AcptTerm"

Проверяется формат поля: целое число (Integer). В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

20. Дата окончания срока акцепта - необязательное поле "MaturityDate"

Проверяется формат поля: должно содержать значение даты (формат определен стандартом XML/XSD - опубликован по адресу http://www.w3.org/TR/xmlschema-2/#date). В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

- Дата отсылки (вручения) плательщику платежных документов - необязательное поле "DocDispatchDate"

Проверки аналогичны п. 20 настоящего раздела.

21. Информация о частичном платеже - необязательный блок данных "PartialPayt":

21.1 Номер частичного платежа - необязательное поле "PaytNo":

Проверяется формат поля: строка длиной 3 символа.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

21.2 Вид операции - обязательное поле "TransKind"

Проверки аналогичны п. 16 настоящего раздела.

21.3 Сумма остатка платежа - необязательное поле "SumResidualPayt"

Проверяется формат поля: целое число (integer).

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

21.4 Реквизиты платежного документа, по которому осуществляется частичное исполнение - обязательный блок данных "AccDoc"

21.4.1 Номер платежного документа - необязательное поле "AccDocNo"

Проверяется формат поля: от 1 до 6 цифр.

Маска ввода: \d{1,6}.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

21.4.2 Дата платежного документа - обязательное поле "AccDocDate"

Проверки аналогичны п. 20 настоящего раздела.

22. Очередность платежа - необязательное поле "Priority":

Проверяется формат поля: длина строки не более 1 символа с допустимыми значениями "0", "1" - "6".

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

23. Код ОКТМО, указанный в распоряжении о переводе денежных средств - необязательное поле "ОКТМО"

Проверяется обязательность заполнения. Если первые цифры номера банковского счета получателя средств (значение в поле "AccountNumber", требования к заполнению поля приведены в приведены в разделе 2.5.2 настоящего документа) не равны "40302", то возвращается код ошибки "309" - "В извещении о приеме к исполнению распоряжения не указан ОКТМО".

Проверяется формат поля: значение "0" или 8 или 11 цифр (при этом три нуля не могут быть впереди).

Проверяется отсутствие нулей во всех 8 или 11 разрядах данного поля.

Маски ввода:

\d{8};

или значение "0".

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

Если по данному начислению предполагается поступление средств на счет, первые цифры которого - "40101" (см. требования к значению в поле "AccountNumber" в п. 11.4.1 настоящего раздела), то значение в поле "OKTMO" не может быть равным "0". Если это условие не выполнено, то возвращается код ошибки "232" - "Некорректное значение кода по ОКТМО" - (см. раздел 6).

24. Дополнительные поля платежа - необязательный блок данных "AdditionalData"

24.1 Наименование поля - обязательное поле "Name"

Проверяется формат поля: строка длиной от 1 до 100 символов.

В случае неуспешной проверки возвращается код ошибки "11" -"Формат запроса (файла) не соответствует xsd-схеме" (см. - раздел 6).

24.1 Значение поля - обязательное поле "Value"

Проверяется формат поля: строка длиной от 1 до 255 символов.

В случае неуспешной проверки возвращается код ошибки "11" - "Формат запроса (файла) не соответствует xsd-схеме" (см. раздел 6).

25. Электронная подпись xml-документа - обязательный блок данных "Signature"

Проверяется формат данных ЭП, в случае ошибки возвращается код ошибки "13" - "ЭП под сущностью (запросом) не верна" (см. раздел 6).

Проверяется корректность ЭП, в случае ошибки возвращаются код ошибки "33" - "Неверный сертификат ключа проверки ЭП под сущностью (запросом)" (см. раздел 6).

2.4. Квитанция

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

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

Если в начислении (в контейнере "AdditionalData") присутствует информация о возможности частичной оплаты суммы начисления (скидка), а также срок, в течение которого данная частичная оплата может быть произведена (подробное описание см. раздел 2.2), то данная информация учитывается при автоматическом квитировании.

Данные квитанций приведены в файле Quittance.xsd (см. раздел 7), описание параметров приведено в таблице ниже (см. Таблица N 3 "Тип QuittanceType").

Таблица N 3

ТИП QUITTANCETYPE

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

2.5.1. Тип OrganizationType

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

Описание типа приведено в файле Organization.xsd (см. раздел 7), описание параметров приведено в таблице ниже (см. Таблица 4 "Тип OrganizationType").

Таблица N 4

ТИП ORGANIZATIONTYPE

2.5.2. Тип AccountType

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

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

- финансовым органам (для учета средств соответствующих государственных (муниципальных) учреждений);

- государственным (муниципальным) учреждениям (для учета средств государственных (муниципальных) автономных учреждений).

Описание типа приведено в файле Organization.xsd (см. раздел 7), описание параметров приведено в таблице ниже (см. Таблица 5 "Параметры типа AccountType").

Таблица N 5

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

2.5.3. Тип BankType

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

Описание типа приведено в файле Organization.xsd (см. раздел 7), описание параметров приведено в таблице ниже (см. Таблица N 6 "Тип BankType").

Таблица N 6

ТИП BANKTYPE"

2.5.4. Тип PaymentIdentificationDataType

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

Описание типа приведено в файле Payment.xsd (см. раздел 7), описание параметров приведено в таблице ниже (см. Таблица N 7 "PaymentIdentificationDataType").

Таблица N 7

PAYMENTIDENTIFICATIONDATATYPE

2.5.5. Тип BudgetIndexType

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

Описание типа приведено в файле BudgetIndex.xsd (см. раздел 7), описание параметров приведено в таблице ниже (см. Таблица 8 "Тип BudgetIndexType").

Таблица N 8

ТИП BUDGETINDEXTYPE

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

2.5.6.1. AccountNumType

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

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

2.5.6.2. INNType

Тип предназначен для указания ИНН юридического лица.

Основан на типе String, 10 цифр [0-9], при этом первый и второй знаки (цифры) не могут одновременно принимать значение ноль ("0").

2.5.6.3. KPPType

Тип предназначен для указания КПП юридического лица.

Основан на типе String, 9 символов, пятый и шестой из которых могут быть прописными (заглавными) латинскими буквами или цифрами [A-Z, 0-9], а все остальные только цифрами [0-9], и при этом первый и второй знаки (цифры) не могут одновременно принимать значение ноль ("0").

2.5.6.4. OKTMOType

Тип предназначен для указания кода по ОКТМО.

Основан на типе String, значение "0", или 8 цифр [0-9], или 11 цифр [0-9], при этом три нуля не могут быть впереди.

2.5.6.5. KBKType

Тип предназначен для указания КБК.

Основан на типе String, значение "0" или 20 символов, среди которых допускаются русские и латинские буквы и цифры [0-9, a-z, A-Z, а-я, А-Я].

2.5.6.6. OGRNType

Тип предназначен для указания ОГРН юридического лица.

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

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 символов [A-Z, 0-9] или 25 цифр [0-9].

Структура УИН описана в пункте 3.1.

2.5.6.10. URN Type

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

Основан на типе String, 6 символов [0-9, a-f, A-F].

2.5.6.11. personINNType

Тип предназначен для указания ИНН физического лица/ индивидуального предпринимателя.

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

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

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

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

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

- каждому разряду УИН, начиная со старшего разряда, присваивается набор весов, соответствующий натуральному ряду чисел от 1 до 10, далее набор весов повторяется;

- каждая цифра УИН умножается на присвоенный вес разряда и вычисляется сумма полученных произведений;

- контрольный разряд для УИН представляет собой остаток от деления полученной суммы на модуль "11". Контрольный разряд должен иметь значение от 0 до 9;

- если получается остаток, равный 10, то для обеспечения одноразрядного контрольного разряда необходимо провести повторный расчет, применяя вторую последовательность весов, являющуюся результатом циклического сдвига исходной последовательности на два разряда влево (3, 4, 5, 6, 7, 8, 9, 10, 1, 2). Если, в случае повторного расчета, остаток от деления вновь сохраняется равным 10, то значение контрольного разряда проставляется равным "0".

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

3.2.1. Идентификатор плательщика ЮЛ (ИП)

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

- 1 разряд - значение "2" (признак ЮЛ - резидента РФ);

- 2 - 11 разряды - ИНН ЮЛ (10 цифр);

- 12 - 20 разряды - КПП ЮЛ (9 цифр).

Правила формирования идентификатора плательщика для ЮЛ - нерезидентов РФ (при наличии ИНН) следующие:

- 1 разряд - значение "3" (признак ЮЛ - нерезидента РФ);

- 2 - 11 разряды - ИНН ЮЛ (10 цифр);

- 12 - 20 разряды - КПП ЮЛ (9 цифр).

Правила формирования идентификатора плательщика для ЮЛ - нерезидентов РФ (при наличии КИО) следующие:

- 1 разряд - значение "3" (признак ЮЛ - нерезидента РФ);

- 2 - 6 разряды - КИО ЮЛ (5 цифр);

- 7 - 15 разряды - КПП ЮЛ (9 цифр).

Правила формирования идентификатора плательщика для ИП следующие:

- 1 разряд - значение "4" (признак ИП);

- 2 - 13 разряды - ИНН ИП (12 цифр).

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

Правила формирования идентификатора плательщика для ФЛ приведены в таблице ниже.

Таблица N 9

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

С 1-й по 2-й символы - код типа документа (список допустимых кодов приведен в таблице ниже).

Таблица N 10

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

С 3-го по 22-й символы - серия и номер документа, код которого указан с 1-го по 2-й символы. Серия и номер документа указываются в одну строку, без разделителей; знаки "N" и "-" не указываются; при наличии букв они должны указываться как заглавные. Если номер документа содержит менее 20 символов, он дополняется слева нулями до 20 символов. Номер мобильного телефона указывается в формате "код страны" - "код оператора (код города)" - "номер телефона" без знаков "-" и "+". Если номер мобильного телефона содержит менее 20 символов, он дополняется слева нулями до 20 символов.

С 23-го по 25-й символы - цифровой код страны, гражданином которой является плательщик, в соответствии с документом, удостоверяющим личность (в соответствии с Общероссийским классификатором стран мира). Для плательщиков граждан РФ - указывается значение "643" (код РФ); для лиц без гражданства используется код "999".

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

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

УИП для кредитных организаций должен соответствовать структуре, приведенной в таблице ниже.

Таблица N 11

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

Структура УИП для кредитных организаций:

- 1-й символ - значение "1".

- со 2-го по 10-й символы - БИК кредитной организации, структурного подразделения кредитной организации, принявшей платеж.

- с 11-й по 16-й символы - номер внутреннего структурного подразделения кредитной организации (филиала, дополнительного офиса, кредитно-кассового офиса, операционного офиса, операционной кассы вне кассового узла), принявшего платеж. Номер слева дополняется нулями до 6 символов.

- с 17-й по 24-й символы - дата платежа в формате "ДДММГГГГ".

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

УИП для ТОФК должен соответствовать структуре, приведенной в таблице ниже.

Таблица N 12

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

Структура УИП для ТОФК:

- 1-й символ - значение "2".;

- со 2-й по 5-й символ - код ТОФК;

- с 6-го по 16-й символ - резерв, заполняется нулями;

- с 17-й по 24-й символы - дата платежа в формате "ДДММГГГГ";

- с 25-й по 32-й символы - уникальный номер платежа в течение дня для данного ТОФК. Номер слева дополняется нулями до 8 символов.

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

Таблица N 13

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

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

- 1-й символ - значение "3".

- со 2-й по 7-й символы - УРН участника, принявшего платеж;

- с 8-го по 15-й символы - дата платежа в формате "ДДММГГГГ";

- с 16-й по 32-й символы - уникальный номер платежа в учетной системе участника. Номер слева дополняется нулями до 17 символов.

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

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

Описание веб-сервиса SmevGISGMPService приведено в файле SmevGISGMPService.wsdl (см. раздел 8).

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

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

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

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

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

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

В формате каждой импортируемой в ГИС ГМП сущности (в тегах Charge и FinalPayment) присутствует тег Signature, предназначенный для передачи ЭП участника, сформировавшего сущность (далее - подпись под сущностью). Наличие подписи под сущностью является обязательным. Если участник, сформировавший сущность, самостоятельно передал ее в ГИС ГМП, допустимо для создания подписи под сущностью и ЭП-ОВ, которая находится в заголовке SOAP-пакета сообщения-запроса, использовать одну и ту же ключевую пару. Если же сущность была сформирована участником косвенного взаимодействия, то указание в качестве подписи под сущностью ЭП участника прямого взаимодействия, который передает сущность в ГИС ГМП, недопустимо.

В формате запроса веб-сервиса теги ExportRequest, DoAcknowledgmentRequest, ChargeCreationRequest содержат вложенный тег Signature, предназначенный для указания ЭП (далее - подпись под запросом) сформировавшего запрос участника (участника, от имени которого направлен запрос в ГИС ГМП). Наличие подписи под запросом обязательно для тех случаев, когда запрос сформирован участником косвенного взаимодействия.

Подпись под сущностью и подпись под запросом должны накладываться в соответствии с алгоритмом, описанным в разделе 4.3.

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

Значение ЭП должно рассчитываться для элемента сущности, запроса и его составных элементов.

В процессе создания электронной подписи информационной системы должны использоваться алгоритмы для расчета хеш-сумм, формирования подписи и каноникализации, приведенные в таблице ниже (см. N 14 "Алгоритмы формирования подписи").

Таблица N 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.1. Общий формат веб-сервиса

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

Таблица N 15

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

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

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

Таблица N 16

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

Описание формата элемента RequestMessage приведено в таблице ниже (см. N 17 "Структура RequestMessage").

Таблица N 17

СТРУКТУРА REQUESTMESSAGE

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

Сообщения ответов ГИС ГМП передаются в структуре сообщения СМЭВ (согласно Методическим рекомендациям версии 2.5.6) в элементе AppData. В данный элемент должен быть подставлен элемент ResponseMessage, описанный в файле Message.xsd. Заполнение полей базового сообщения СМЭВ для ответа ГИС ГМП указано в таблице ниже (см. N 18 "Структура сообщения ответа к веб-сервису").

Таблица N 18

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

Формат элемента ResponseMessage приведен в таблице ниже (см. N 19) "Структура ResponseMessage".

Таблица N 19

СТРУКТУРА RESPONSEMESSAGE

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

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

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

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

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

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

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

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

- пакет принят в обработку (ResultCode="0");

- установлено несоответствие Xsd-схеме (ResultCode="11");

- установлена ошибка в ЭП-ОВ (ResultCode="27").

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

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

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

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

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

- пакет принят в обработку (ResultCode="0");

- установлено несоответствие Xsd-схеме (ResultCode="11");

- установлена ошибка в ЭП-ОВ (ResultCode="27").

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

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

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

В сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/Ticket/RequestProcessResult с типом ResultInfo, структура которого приведена в файле ErrInfo.xsd (см. раздел 7). Описание параметров приведено в таблице ниже (N 20 "Структура ответа на запрос импорта").

Таблица N 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/Ticket/PackageProcessResult.

По истечении срока хранения статуса обработки пакета в ГИС ГМП и в случае, если в запросе передан ошибочный идентификатор пакета, в сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/Ticket/RequestProcessResult с типом ResultInfo (см. описание типа ResultInfo в разделе 5.2.3). При этом ResultCode будет равен значению "60".

Описание параметров приведено в таблице ниже (Таблица N 21 "Структура ответа на запрос статуса обработки импортируемого пакета (если обработка пакета завершена)").

Таблица N 21

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

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

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

В сообщении запроса в теге RequestMessage должен передаваться тег ExportRequest, структура которого приведена в файле MessageData.xsd (см. раздел 7). Описание параметров приведено в таблице ниже (Таблица N 22 "Структура запроса на экспорт").

Таблица N 22

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

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

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

- CHARGE - используется для запроса неоплаченных начислений;

- CHARGENOTFULLMATCHED - используется для запроса начислений, не полностью сквитированных с платежами (в т.ч. таких, по которым оставшаяся сумма к оплате равна "0", но при этом в начислении и соответствующем ему платеже попарно могут не совпадать какой-либо или несколько атрибутов из следующего набора: КБК, ОКТМО, ИНН, КПП, номер счета, БИК, идентификатор плательщика);

- CHARGESTATUS - используется для запроса начислений и статусов их квитирования;

- CHARGE-PRIOR - используется для запроса неоплаченных предварительных начислений;

- CHARGE-PRIOR-NOTFULLMATCHED - используется для запроса предварительных начислений, не полностью сквитированных с платежами;

- CHARGE-PRIOR-STATUS - используется для запроса предварительных начислений и статусов их квитирования;

- TEMP-CHARGING - используется для запроса неоплаченных предварительных начислений, сформированных ГИС ГМП;

- TEMP-CHARGING-NOTFULLMATCHED - используется для запроса предварительных начислений, сформированных ГИС ГМП, не полностью сквитированных с платежами;

- TEMP-CHARGING-STATUS - используется для запроса предварительных начислений, сформированных ГИС ГМП, и статусов их квитирования.

Запросы CHARGE, CHARGEN OTFULLMATCHED, CHARGE-PRIOR, CHARGE-PRIOR-NOTFULLMATCHED, TEMP-CHARGING, TEMP-CHARGING-NOTFULLMATCHED доступны для АП/ГАП.

Запросы CHARGE, CHARGENOTFULLMATCHED, TEMP-CHARGING, TEMP-CHARGING-NOTFULLMATCHED доступны для АЗ/ГАЗ.

Запросы CHARGESTATUS, TEMP-CHARGING-STATUS доступен для АН/ГАН, АП/ГАП и АЗ/ГАЗ.

Запрос CHARGE-PRIOR-STATUS доступен для АН/ГАН.

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

5.4.2.1. Особенности формирования запроса на экспорт извещений о начислениях, администрируемых налоговыми органами Российской Федерации

В ответе на запрос экспорта извещений о начислениях (CHARGE, CHARGESTATUS, CHARGENOTFULLMATCHED) вернутся в том числе и начисления, администрируемые налоговыми органами Российской Федерации, при выполнении хотя бы одного из следующих условий:

- запрос начисления по УИН;

- запрос начислений по идентификатору плательщика.

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

1. Условие, при котором в ответе на экспорт начислений по УИН из ГИС ГМП возвращаются начисления, администрируемые налоговыми органами Российской Федерации:

Значение (значения) УИН в контейнере с условиями для получения сущностей из ГИС ГМП (атрибута (ов) "SupplierBillID" элемента "Filter"/"Conditions"/"ChargesIdentifiers") соответствует маске: "/\182\w{17}$|/\182\d{22}$".

2. Условия, при которых в ответе на экспорт начислений по идентификатору плательщика из ГИС ГМП возвращаются начисления, администрируемые налоговыми органами Российской Федерации:

- значение идентификатора плательщика в контейнере с условиями для получения сущностей из ГИС ГМП (атрибута (ов) "PayerIdentifier" элемента "Filter"/"Conditions"/"Payers") соответствует маске: "/\2[0-9]{14}[A-Z0-9]{2}[0-9]{3}$|/\4[0-9]{12}$|}$|/\21[0-9]{23}$";

- наличие блока с информацией, подтверждающей аутентификацию плательщика в системе ЕСИА ("EsiaUserInfo"). Также должны быть выполнены проверки соответствия значений идентификатора плательщика ("PayerIdentifier") данным из блока информации, подтверждающей аутентификацию плательщика (физического лица/индивидуального предпринимателя) в ЕСИА (EsiaUserInfo) описание которых приведено в п. 2.1.1 настоящего раздела.

2.1.1. Проверки соответствия значений идентификатора плательщика ("PayerIdentifier") данным из блока информации, подтверждающей аутентификацию плательщика (пользователя) в ЕСИА ("EsiaUserInfo"):

2.1.1.1. Атрибут "PayerIdentifier" соответствует маске "/\21[0-9]{23}" (ИНН физического лица):

Осуществляется проверка соответствия значения, указанного в 11 - 22 разрядах атрибута "PayerIdentifier", значению атрибута "personINN" (блок данных "EsiaUserInfo"/"Person").

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

2.1.1.2. Атрибут "PayerIdentifier" соответствует маске "/\4[0-9]{12}" (ИНН индивидуального предпринимателя):

Осуществляется проверка соответствия значения, указанного в 2 - 13 разрядах атрибута "PayerIdentifier", значению атрибута "personINN" (блок данных "EsiaUserInfo"/"IndividualBussnes").

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

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

В сообщении ответа в теге AppData будет присутствовать тег ResponseMessage/ExportChargesResponse, структура которого приведена в файле MessageData.xsd (см. раздел 7). Описание параметров приведено в таблице ниже (N 23 "Структура ответа на запрос экспорта начислений").

Таблица N 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. "XSD-схемы сущностей и сообщений ГИС ГМП"), описание параметров приведено в таблице ниже (N 24 "Структура ответа на запрос экспорта платежей").

Таблица N 24

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

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

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

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

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

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

- ALLQUITTANCE - для запросов всех результатов квитирования.

Запрос QUITTANCE доступен для АН/ГАН, АП/ГАП и АЗ/ГАЗ.

Запрос ALLQUITTANCE доступен для АН/ГАН и АП/ГАП.

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

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

Таблица N 25

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

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

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

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

Право на принудительное квитирование начисления с платежами имеет АН или ГАН, сформировавший соответствующее начисление.

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

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

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

Таблица N 26

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

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

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

Таблица N 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. "XSD-схемы сущностей и сообщений ГИС ГМП"), описание элементов приведено в таблице ниже (N 28 "Структура запроса на формирование предварительного начисления").

Таблица N 28

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

Таблица N 29

ТИП ChargeTemplateType

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

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

Таблица N 30

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

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

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

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

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

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

Таблица N 31

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

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

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

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

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

Таблица N 32

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

7. XSD-схемы сущностей и сообщений ГИС ГМП

Файлы с XSD-схемами находятся в прикрепленном архиве:

8. WSDL веб-сервиса, размещенного в СМЭВ

URL веб-сервиса ГИС ГМП для взаимодействия через СМЭВ может отличаться от URL, указанного в файле SmevGISGMPService.wsdl.