Идентификатор документа для запроса через гис гмп что это

Что такое код УИН в платёжном поручении и где его взять

Заполняющий платёжное поручение нередко наталкивается на поле №22, и сразу возникает вопрос: что это за «код УИН» и откуда его взять? Сразу хотим успокоить — нужен он далеко не всегда (вернее, во многих случаях там ставится ноль). Итак, УИН – это уникальный идентификатор начисления. Его нужно прописывать при совершении платежей через банк.

Что такое УИН

УИН — цифровой код, который нужен для контроля над платежами в бюджет государства от ФЛ и ЮЛ. Это значение, в которое входит 20 цифр. От других сведений цифры отделяются символом «///».

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

Идентификатор заносится в поле «Код». Это поле обозначается цифрами 22. Указывать код УИН в платежных документах нужно обязательно. Без этого невозможно направить средства в бюджет страны. Т.е. даже если УИНа нет, нужно ставить ноль. Пустым поле оставлять нельзя. К примеру, это могут быть платежи:

• Налоги.
• Государственные пошлины.
• Штрафы.
• Пени.
• Различные задолженности.

Сотрудники банка не примут платежки без указания кода. Его также нужно прописывать при переводе средств через терминалы.

К СВЕДЕНИЮ! Для каждого типа платежа код УИН будет различным. А потому очень часто возникает путаница. Плательщики не знают, какие именно цифры указывать в платежках.

Значение составляющих идентификатора

Каждое число, включенное в идентификатор, имеет свой смысл:

• Первые три числа. Присваиваются казначейством.
• Четвертое число. Обозначает ведомство, от которого пришел запрос на перечисление средств.
• Пятое число. Представляет собой код платежа.
• Шестое и седьмое число. Дата проведения платежа.
• Числа с 8-го по 12-е. Серия и номер.
• Двадцатое число. Нужно для повышения уникальности идентификатора. Присваивается конкретной платежке.

Какой УИН указать в платежном поручении на уплату госпошлины?

Идентификатор утверждается получателем средств. Формирование его – это автоматический процесс. Код должен быть уникальным для каждого платежного документа.

ВАЖНО! Плательщику нельзя формировать код самостоятельно, используя произвольные числа. Если код УИН будет просто придуман, средства не дойдут до их получателя.

ВНИМАНИЕ! Иногда, если лицо не знает свой идентификатор, можно проставить «0». В некоторых случаях код УИН дополняется буквенными обозначениями. Это могут быть русские или латинские буквы.

Что обозначает идентификатор в квитанции

Код служит идентификации платежа. В нем содержится эта информация:

• Кем выставляется платеж.
• Адресат платежа.
• За что именно уплачиваются средства.

Сотрудник банка может расшифровать код, после чего он направляет платеж его адресату. Все начисления в бюджет фиксируются в системе ГТС ГМП. Наличие кода позволяет безотлагательно зафиксировать платеж.

Правовая база

Использование идентификатора было установлено Приказом Минфина №106н от 24 ноября 2004 года. Это был первый документ, который утвердил использование УИН в качестве реквизитов. Однако когда действовал только этот документ, код использовался в рекомендательном порядке. Необходимость его применения появилась после выхода Приказа Минфина №107 от 12 ноября 2013 года. Соответствующее обязательство связано с формированием системы ГИС ГМП.

До 31 марта 2014 года идентификатор указывался в поле «Назначение средств». После этой даты код стал вноситься в поле «22».

Еще один регулирующий документ – ФЗ №210 «О предоставлении госуслуг» от 27 июля 2010 года. Он утвердил идентификатор платежей, который нужен для быстрой доставки средств по назначению.

Для чего нужен УИН

УИН требуется для быстрого и эффективного распределения средств. Представители банков и бюджетных структур на основании этого кода определяют, кому предназначаются средства. Так как код служит идентификации, он будет уникальным для каждого платежного документа.

Система УИН служит упрощению системы бюджетных платежей и сборов. Она позволяет исключить появление платежей с неопределенным назначением. Указание идентификатора позволяет быть уверенными в том, что средства точно дойдут до своего адресата.

Как получить идентификатор

Для получения УИН нужно проделать следующие действия:

1. Получение от бюджетных структур требования об уплате средств (пени, штрафов, налогов).
2. Именно в этом требовании можно найти нужный идентификатор.
3. В платежный документ вносятся все цифры, содержащиеся в требовании. Вносить их нужно в код «22». Это поле находится в нижнем блоке платежки.

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

ВАЖНО! Код УИН актуален только для платежей, адресатом которых являются государственные и бюджетные структуры.

Когда в коде УИН нет необходимости

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

Рассмотрим пример. ЮЛ оплачивает НДС. Реквизитом в этом случае может являться КБК. Он указывается в поле 104. ИП и ФЛ в качестве кода может использовать ИНН. Однако если в строке 22 не будет указано ничего, платежка не принимается. А потому в этой строке нужно прописать «0».

Особенности указания кода при различных типах платежей

Нюансы указания УИН зависят от конкретного вида платежа.

Налоги

Нужный УИН содержится в индексе требования. Это актуально в том случае, если плательщику выставляется платежка. Если же он уплачивает текущий налог самостоятельно, идентификатор указывать не требуется. В поле 22 проставляется код «0». Основание – Письмо ФСС №17-03-11/14-2337 от 21 февраля 2014 года. Также заменить реквизит можно ИНН (письмо ФНС №3Н-4-1/6133 от 8 апреля 2016 года). Однако в платежных документах можно указать и УИН, и ИНН.

Госпошлина

Госпошлина уплачивается на основании поступившей квитанции. Если она получена по месту обращения, нужный идентификатор – это индекс квитанции. Однако обычно плательщик не обращается в органы за документом. То есть код ему узнать не от куда. В этом случае в строке 22 указывается «0».

Уплата услуг детского сада

При уплате услуг детского сада также нужно указывать идентификатор. Нюанс получения кода заключается в том, что обычно детские сады не выставляют никаких письменных требований родителям. Где получить УИН? За ним можно обратиться в бухгалтерию сада. Код включает в себя обозначение ребенка. За УИН достаточно обратиться один раз. В дальнейшем платежи будут совершаться по ранее полученному коду. Так же выполняется оплата обучения в платных школах.

Штрафы ГИБДД

Штрафы ГИБДД оплачиваются по документу, являющемуся основанием для назначения платежа. В этом же документе и указывается УИН. В коде содержится эта информация:

• Номер протокола.
• Дата составления этой бумаги.

Рассмотрим расшифровку идентификатора:

• Первые три числа. Номер распорядителя. Номер для ГИБДД – 188.
• Четвертый символ. Адресат – 1.
• Пятый символ. Назначение средств. Если выплачивается штраф, проставляется цифра 1.
• Шестой и седьмой символ. Дата оформления бумаги, на основании которой совершается платеж.
• Остальные числа. Серийный номер.

Если присутствует постановление, на основании которого выплачивается штраф, плательщику не обязательно указывать УИН. Сделать это за него может банковский работник.

Идентификатор документа для запроса через гис гмп что это

Об актуальных изменениях в КС узнаете, став участником программы, разработанной совместно с АО »СБЕР А». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

Программа разработана совместно с АО »СБЕР А». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

Обзор документа

Государственная информационная система о государственных и муниципальных платежах “Форматы взаимодействия Государственной информационной системы о государственных и муниципальных платежах с информационными системами участников” версия 1.16.0 (утв. Федеральным казначейством 25 сентября 2014 г.)

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

Глава	Предмет изменения
2.2 Начисление	Внесены теги из отмененного типа Bill. Добавлен тег Origin (для начислений с признаком «предварительное начисление»). Удален атрибут version. Удален атрибут mainSupplierBillID; добавлен контейнер MainSupplierBillIDList. Внесены изменения в структуру элемента ChangeStatus. Возможные значения атрибута ChangeStatus@meaning расширены значением «4» — деаннулирование начисления. Добавлен элемент ChangeStatus/Reason для указания основания аннулирования. Изменена обязательность указания атрибута billDate для возможности импорта предварительных начислений без указания даты и времени начисления суммы, подлежущей уплате. Элемент Signature, в котором должна содержаться подпись под сущностью, стал обязательным. Добавлены элементы DocDispatchDate, AcptTerm, PaytCondition.
2.3 Платеж	Внесены теги типа PaymentType. Изменен порядок следования тегов. Добавлен атрибут Id, удален элемент ApplicationID, тип элемента PaymentDate изменен на dateTime. Убран атрибут version. Внесены изменения в структуру элемента ChangeStatus. Возможные значения атрибута ChangeStatus@meaning расширены значением «3» — аннулирование платежа. Добавлен элемент ChangeStatus/Reason для указания основания аннулирования. Элемент Signature, в котором должна содержаться подпись под сущностью, стал обязательным. Существенно расширен перечень элементов для передачи полей распоряжения, принятого в банке.
2.4 Квитанция	Добавлен атрибут Id, удален элемент ApplicationID, добавлены элементы AccountNumber и BIK, добавлено значение «4» для элемента BillStatus, элемент PaymentIdentificationData стал необязательным для заполнения (только в случае, если элемент BillStatus имеет значение «4»). Изменен порядок следования тегов.
2.5 Вспомогательные типы	Удалено описание типа Bill в связи с переносом его элементов в тип Charge.
2.5.1 Тип OrganizationType	Удалены теги Contacts и Addresses.
2.5.2 Тип AccountType	Удалены тег SubAccount и атрибут kind.
2.5.3 Тип BankType	Изменена маска тега SWIFT.
2.5.4 PaymentIdentificationDataType	Добавлен тег Other.
2.5.5 Тип BudgetIndexType	Добавлены ограничения на возможные значения тегов, изменен порядок следования тегов.
2.5.6 «Простые типы»	Добавлены описания типов INNType, KPPType, OKTMOType, KBKType, OGRNType, BIKType, SWIFTType, SupplierBillIDType, URNType для обозначения, соответственно, ИНН юридических лиц, КПП, кода ОКТМО, КБК, ОГРН, номера банковского счета, БИК, кода SWIFT, УИН, УРН.
3.1 Идентификация начисления	Изменены алгоритмы формирования УИН. Размер УИН для АН и ГАН, являющихся органами государственной власти субъектов Российской Федерации, органами местного самоуправления, государственными (муниципальными) учреждениями, увеличен до 25 символов.
3.2 Идентификация плательщика	Внесены изменения в алгоритм формирования идентификатора плательщика для ЮЛ-нерезидента РФ, а добавлен алгоритм формирования идентификатора плательщика для ИП. Изменен алгоритм формирования идентификатора плательщика с использованием СНИЛС. Изменен перечень кодов документов, которые могут использоваться для идентификации плательщика.
4. Порядок взаимодействия ГИС ГМП с информационными системами участников	Наличие подписи под сущностью стало обязательным. Добавлена ЭП под запросом.
5 Форматы сообщений веб-сервиса, размещенного в СМЭВ	Изменены форматы сообщений. Описание элемента AppData приведено в соответствии с методическими рекомендациями СМЭВ версии 2.5.6. Добавлен атрибут senderRole для указания полномочия, с которым участник обращается к ГИС ГМП.
5.2 Порядок импорта новых сущностей, уточнения или аннулирования ранее загруженных сущностей в ГИС ГМП	Реализован пакетный режим импорта, допускающий передачу в ГИС ГМП нескольких сущностей в составе одного сообщения. Метод запроса окончательного статуса обработки пакета описан в главе . Добавлен атрибут originatorID для указания УРН участника, сформировавшего начисление (платеж).
5.4 Экспорт сущностей из ГИС ГМП	Реализован постраничный режим выгрузки данных, расширены параметры поиска данных.
5.4.1 Общий формат запроса	Общий формат изменен значительно. В частности, для ГАН добавлена возможность ограничения выборки (фильтр) по ИНН и КПП или УРН участника косвенного взаимодействия. Добавлен фильтр по ОКТМО, КБК; добавлена возможность выборки платежей с УИН, не равным значению «0». Для реализации постраничной выгрузки добавлены атрибуты, показывающие номер страницы выгрузки и число элементов на странице. Добавлены необязательные атрибут originatorID и Signature для передачи УРН и ЭП участника, от имени которого производится запрос.
5.4.2 Передача ГИС ГМП извещений о начислениях	Добавлены типы запросов PRIORCHARGE, PRIORCHARGENOTFULLMATCHED, PRIORCHARGESTATUS, TEMPCHARGE, TEMPCHARGENOTFULLMATCHED, TEMP CHARGESTATUS для запроса неоплаченных, неполностью сквитированных и предварительных начислений со статусом квитирования соответственно. Определены права участников для выполнение новых запросов.
5.4.4 Передача ГИС ГМП извещений о приеме к исполнению распоряжений	Изменена логика формирования ответов на запросы платежей, в связи с возможностью аннулирования платежа. Добавлен тип запроса PAYMENTCANCELLED для выгрузки только аннулированных платежей.
5.5 Квитирование начисления с платежами по инициативе АН/ГАН	Добавлены возможности квитирования начисления с отсутствующим в системе платежом.
5.6 Квитирование начисления с отсутствующим в ГИС ГМП	Новый раздел.
5.7 Установление платежу статуса «Услуга предоставлена»	Новый раздел.
5.8 Формирование начисления с признаком «Предварительное начисление»	Новый раздел.
5.9 Загрузка и обновление сертификатов ключа проверки ЭП участников	Новый раздел.
6. Перечень контролей	Значительно расширен перечень контролей.

Введение

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

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

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

№	Термин	Содержание
1.	Base64	Алгоритм кодирования. Идентификатор алгоритма, описывающего преобразования: http://www.ietf.org/rfc/rfc2045#base64.
2.	GUID	Globally Unique Identifier — статистически уникальный 128-битный идентификатор.
3.	SOAP	Simple Object Access Protocol — простой протокол обмена структурированными сообщениями.
4.	SWIFT	Society for Worldwide Interbank Financial Telecommunications — Сообщество всемирных межбанковских финансовых телекоммуникаций.
5.	URL	Uniform Resource Locator — единообразный локатор (определитель местонахождения) ресурса.
6.	W3C	World Wide Web Consortium — консорциум Всемирной паутины.
7.	WSDL	Web Services Description Language — язык описания веб-сервисов.
8.	XAdES-T	XML Advanced Electronic Signatures (timestamp) — формат улучшенной электронной подписи, накладываемой на XML-структуры, позволяющий запись метки времени.
9.	XML	Extensible Markup Language — расширяемый язык разметки.
10.	XSD	XML Schema definition — язык описания структуры XML-документа. Спецификация XML Schema является рекомендацией W3C.
11.	АЗ	Администратор запросов.
12.	АН	Администратор начислений.
13.	АП	Администратор платежей.
14.	БД	База данных.
15.	БИК	Банковский идентификационный код.
16.	Веб-сервис	Программная система, идентифицируемая URI и предназначенная для поддержки интероперабельных межмашинных взаимодействий в сетевой среде.
17.	ГАЗ	Главный администратор запросов.
18.	ГАН	Главный администратор начислений.
19.	ГАП	Главный администратор платежей.
20.	ГИС ГМП, Система	Государственная информационная система о государственных и муниципальных платежах.
21.	Извещение о начислении, начисление	Электронный документ, содержащий информацию, необходимую для осуществления перевода денежных средств.
22.	Извещение об аннулировании начисления, аннулирование начисления	Электронный документ, содержащий информацию об аннулировании ранее направленного в ГИС ГМП извещения о начислении и основание аннулирования.
23.	Извещение об уточнении начисления, уточнение начисления	Электронный документ, содержащий информацию, уточняющую ранее направленную в извещении о начислении.
24.	Извещение о приеме к исполнению распоряжений, платеж	Электронный документ, содержащий информацию о приеме к исполнению распоряжения о переводе денежных средств либо наличных денежных средств плательщика при условии достаточности денежных средств для исполнения обязательств.
25.	Извещение об аннулировании распоряжения, аннулирование платежа	Электронный документ, содержащий информацию об аннулировании ранее направленного в ГИС ГМП извещения о приеме к исполнению распоряжения и основание аннулирования.
26.	Извещение об уточнении распоряжения, уточнение платежа	Электронный документ, содержащий информацию, уточняющую ранее направленную в извещении о приеме к исполнению распоряжения.
27.	ИНН	Индивидуальный номер налогоплательщика.
28.	ИП	Индивидуальный предприниматель.
29.	ИС	Информационная система.
30.	КБК	Код бюджетной классификации Российской Федерации.
31.	КПП	Код причины постановки на учет.
32.	Начисление с признаком «Предварительное начисление», предварительное начисление	Извещение о начислении, передаваемое АН (ГАН) в ГИС ГМП до факта осуществления АН (ГАН) начисления суммы, подлежащей уплате.
33.	НПА	Нормативные правовые акты.
34.	ОГРН	Основной государственный регистрационный номер.
35.	ОКТМО	Общероссийский классификатор территорий муниципальных образований.
36.	Орган ЗАГС	Орган записи актов гражданского состояния.
37.	Параметры квитирования	Параметры, по которым осуществляется сопоставление данных начисления и платежей: УИН, сумма, КБК, код ОКТМО, ИНН, КПП, номер счета, БИК, идентификатор плательщика.
38.	Подпись под запросом	ЭП, накладываемая на теги ExportRequest, DoAcknowledgmentRequest и их содержимое.
39.	Подпись под сущностью	ЭП, накладываемая на теги Charge или FinalPayment и их содержимое.
40.	РФ	Российская Федерация.
41.	Сертификат ключа проверки ЭП, сертификат	Квалифицированный сертификат ключа проверки электронной подписи.
42.	СМЭВ	Система межведомственного электронного взаимодействия.
43.	СНИЛС	Страховой номер индивидуального лицевого счета.
44.	Сущность	Начисление, платеж (в т.ч. уточнения и аннулирования начислений и платежей), квитанция.
45.	ТОФК	Территориальный орган Федерального казначейства.
46.	УИН	Уникальный идентификатор начисления.
47.	УИП	Уникальный идентификатор платежа.
48.	УРН	Уникальный регистрационный номер.
49.	Участник	Участник ГИС ГМП, осуществляющий информационное взаимодействие с ГИС ГМП (администратор начислений, главный администратор начислений, администратор платежей, главный администратор платежей, администратор запросов, главный администратор запросов).
50.	Участник косвенного взаимодействия	Администратор начислений, администратор платежей и администратор запросов, осуществляющие информационное взаимодействие с ГИС ГМП через главного администратора начислений, главного администратора платежей и главного администратора запросов соответственно.
51.	Участник прямого взаимодействия	Администратор начислений, администратор платежей и администратор запросов, осуществляющие самостоятельное информационное взаимодействие с ГИС ГМП, а также главный администратор начислений, главный администратор платежей и главный администратор запросов.
52.	Финансовый орган	Орган, осуществляющий открытие и ведение лицевых счетов в соответствии с бюджетным законодательством Российской Федерации.
53.	ФК	Федеральное казначейство.
54.	ФЛ	Физическое лицо.
55.	ФССП	Федеральная служба судебных приставов.
56.	ЭП	Электронная подпись.
57.	ЭП-ОВ	Электронная подпись органа власти, определенная в документе «Методические рекомендации по разработке электронных сервисов и применению технологии электронной подписи при межведомственном электронном взаимодействии» версии 2.5.6.
58.	ЮЛ	Юридическое лицо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наименование. Наименование тега или атрибута XML-типа.

Кол-во тегов, обязательность тега или атрибута. Указывает на количество тегов формируемого XML. Формат поля: <min>..<max>, где <min> — минимальное количество тегов, <max> — максимальное количество тегов («n» указывает на неограниченное количество тегов).

Тип данных. Возможные значения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица № 1. «Тип ChargeType»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
Id (атрибут)	1, обязателен	ID	Необходим для наложения ЭП в формате XadES. Должен иметь структуру <буква [A-Z]>_<GUID>.
SupplierBillID (атрибут)	1, обязательно	SupplierBillIDType (описание см. в п. 2.5.6.9)	УИН. Алгоритм формирования УИН описан в главе 3.1.
BillDate (атрибут)	1, обязательно	dateTime	Дата и время начисления суммы, подлежащей уплате плательщиком. Заполнение атрибута является обязательным для всех начислений, в том числе для начислений с признаком «Предварительное начисление».
ValidUntil	0..1, необязательно	Date	Дата, вплоть до которой актуально выставленное начисление.
DocDispatchDate	0..1, необязательно	Date	Дата отсылки (вручения) плательщику документов в случае, если эти документы были отосланы (вручены) получателем средств плательщику.
MainSupplierBillIDList	0..1, необязательно	Контейнер	Уникальные идентификаторы начислений, на основании которых выставлено данное начисление (до 9 штук). Заполняется только в начислениях, выставляемых ФССП.
MainSupplierBillID	1..9, обязательно	String	УИН, на основании которого выставлено данное начисление (связанное начисление).
SupplierOrgInfo	1, обязательно	OrganizationType (см. описание в пункте 2.5.1)	Данные организации, являющейся получателем средств.
BillFor	1, обязательно	String	Назначение платежа.
TotalAmount	1, обязательно	unsignedLong	Сумма начисления. Целое число, показывающее сумму в копейках.
ChangeStatus	1, обязательно	Контейнер	Сведения о статусе начисления и основаниях его изменения.
meaning (атрибут)	1, обязательно	String	Статус, отражающий изменение данных начисления. Возможные значения: 1 — новое; 2 — уточнение; 3 — аннулирование; 4 — деаннулирование (отмена аннулирования).
Reason	0..1, необязательно	String	Основание изменения начисления. Указание основания является обязательным, если meaning= «3».
KBK	1, обязательно	KBKType (см. описание в п. 2.5.6.5)	КБК или двадцатизначный код, содержащий в 1 — 17 разрядах нули, в 18 — 20 разрядах — код классификации операций сектора государственного управления бюджетной классификации Российской Федерации. В случае отсутствия следует указывать значение «0».
OKTMO	1, обязательно	OKTMOType (см. описание в п. 2.5.6.4)	Код ОКТМО, указываемый АН или ГАН в соответствии с НПА. В случае отсутствия следует указывать значение «0».
BudgetIndex	1, обязательно	BudgetIndexType (см. описание в п. 2.5.5)	Реквизиты платежа 101, 106 — 110, предусмотренные приказом Министерства финансов Российской Федерации от 12 ноября 2013 г. №107н «Об утверждении Правил указания информации в реквизитах распоряжений о переводе денежных средств в уплату платежей в бюджетную систему Российской Федерации» (далее — приказ Минфина России от 12 ноября 2013 г. №107н).
UnifiedPayerIdentifier	1, обязательно	String	Идентификатор плательщика для ЮЛ или ИП. Алгоритм формирования идентификатора плательщика для ЮЛ или ИП описан в пункте 3.2. Наличие данного тега исключает наличие тега AltPayerIdentifier.
AltPayerIdentifier	1, обязательно	String	Идентификатор плательщика для ФЛ. Алгоритм формирования идентификатора плательщика для ФЛ описан в пункте 3.2. Наличие данного тега исключает наличие тега UnifiedPayerIdentifier.
TreasureBranch	1, обязательно	String	Сокращенное наименование ТОФК.
TOFK	0..1, необязательно	String	Код ТОФК, в котором открыт лицевой счет получателю или финансовому органу.
FOName	0..1, необязательно	String	Наименование финансового органа.
LSvUFK	0..1, необязательно	String	Номер лицевого счета получателя или финансового органа в ТОФК.
LsvFO	0..1, необязательно	String	Номер лицевого счета получателя в финансовом органе.
AcptTerm	0..1, необязательно	Integer	Количество дней для получения акцепта плательщика.
PaytCondition	0..1, необязательно	Integer	Условие оплаты. Возможные значения: 1 — заранее данный акцепт плательщика; 2 — требуется получение акцепта плательщика.
Origin	0..1, необязательно	String	Признак начисления с признаком «Предварительное начисление» (предварительное начисление): PRIOR — для предварительных начислений, загруженных в ГИС ГМП участником (например, при направлении дела на рассмотрение в суд); TEMP — для предварительных начислений, сформированных ГИС ГМП по запросу участника и имеющих срок действия.
AdditionalData	0..n, необязательно	Контейнер	Дополнительные поля начисления.
Name	1, обязательно	String	Наименование поля.
Value	1, обязательно	String	Значение поля.
Signature	1, обязательно	SignatureType	ЭП xml-документа. В теге содержатся реквизиты ЭП, соответствующие стандарту XML Advanced Electronic Signatures with Time-Stamp (описание стандарта находится в сети Интернет по адресу http://www.w3.org/TR/XAdES/).

2.3. Платеж

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

Таблица № 2. «Тип PaymentType»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
Id (атрибут)	1, обязателен	ID	Необходим для наложения ЭП в формате XadES. Должен иметь структуру <буква [A-Z]>_<GUID>.
SupplierBillID	1, обязательно	SupplierBillIDType (описание см. в п. 2.5.6.9) или значение «0»	УИН. В случае отсутствия УИН указывается значение «0».
Narrative	1, обязательно	String	Назначение платежа.
Amount	1, обязательно	unsignedLong	Сумма платежа. Целое число, показывающее сумму в копейках.
ReceiptDate	0..1, необязательно	date	Дата поступления распоряжения в банк плательщика. Обязательно для заполнения в случае поступления распоряжения в кредитную организацию.
PaymentDate	1, обязательно	dateTime	Дата и время приема к исполнению распоряжения плательщика.
BudgetIndex	1, обязательно	BudgetIndexType (см. описание в пункте 2.5.5)	Реквизиты платежа 101, 106-110, предусмотренные приказом Минфина России от 12 ноября 2013 г. №107н.
PaymentIdentificationData	1, обязательно	PaymentIdentificationDataType (см. Описание в пункте 2.5.4)	Данные, необходимые для идентификации распоряжения о переводе денежных средств.
AccDoc	0..1, необязательно	Контейнер	Реквизиты платежного документа.
AccDocNo	0..1, необязательно	string	Номер платежного документа.
AccDocDate	1, обязательно	date	Дата платежного документа.
Payer	1, обязательно	Контейнер	Cведения о плательщике.
PayerIdentifier	1, обязательно	String	Идентификатор плательщика. Алгоритм формирования идентификатора плательщика описан в пункте 3.1.3.
PayerName	0..1, необязательно	String	Наименование плательщика. Указывается только для плательщиков — ЮЛ.
PayerAccount	0..1, необязательно	String	Номер счета плательщика (при наличии) в организации, принявшей платеж.
Payee	1, обязательно	Контейнер	Сведения о получателе средств.
PayeeName	1, обязательно	String	Наименование получателя средств и иная информация, содержащаяся в реквизите «Получатель» распоряжения о переводе денежных средств, за исключением ИНН, КПП.
PayeeINN	1, обязательно	INNType (см. описание в пункте 2.5.6.2)	ИНН получателя средств.
PayeeKPP	1, обязательно	KPPType (см. описание в пункте 2.5.6.3)	КПП получателя средств.
PayeeBankAcc	1, обязательно	AccountType (см. описание в пункте 2.5.2)	Реквизиты счета получателя средств.
AdditionalData	0..n, необязательно	Контейнер	Дополнительные поля платежа.
Name	1, обязательно	String	Наименование поля.
Value	1, обязательно	String	Значение поля.
RecipientServicesIdentifier	0..1, необязательно	String	Идентификатор получателя услуги / плательщика. Алгоритм формирования идентификатора получателя услуги совпадает с алгоритмом формирования идентификатора плательщика, описанного в пункте 3.2. Заполняется в случае, если плательщик не является получателем услуги.
PayerPA	0..1, необязательно	String	Дополнительный идентификатор получателя услуги в учетной системе получателя средств.
ChangeStatus	1, обязательно	Контейнер	Сведения о статусе платежа и основаниях его изменения.
meaning (атрибут)	1, обязательно	String	Статус, отражающий изменение данных платежа. Возможные значения: 1 — новое; 2 — уточнение; 3 — аннулирование.
Reason	0..1, необязательно	String	Основание изменения. Указание является обязательным, если meaning= «3».
KBK	1, обязательно	KBKType (см. описание в п. 2.5.6.5)	КБК или двадцатизначный код, содержащий в 1 — 17 разрядах нули, в 18 — 20 разрядах — код классификации операций сектора государственного управления бюджетной классификации Российской Федерации. В случае отсутствия следует указывать значение «0».
TransKind	0..1, необязательно	String	Вид операции. Указывается шифр платежного документа. Возможные значения: 01 — платежное поручение; 06 — инкассовое поручение; 02 — платежное требование; 16 — платежный ордер; ПД — платежный документ ФЛ
TransContent	0..1, необязательно	String	Содержание операции. Указывается при частичном исполнении.
PaytCondition	0..1, необязательно	Integer	Условие оплаты. Возможные значения: 1 — заранее данный акцепт плательщика; 2 — требуется получение акцепта плательщика.
AcptTerm	0..1, необязательно	Integer	Количество дней для получения акцепта плательщика.
MaturityDate	0..1, необязательно	Date	Окончание срока акцепта.
DocDispatchDate	0..1, необязательно	Date	Дата отсылки (вручения) плательщику документов в случае, если эти документы были отосланы (вручены) получателем средств плательщику.
PartialPayt	0..1, необязательно	Контейнер	Информация о частичном платеже.
PaytNo	0..1, необязательно	String	Номер частичного платежа. Соответствует значению соответствующего реквизита распоряжения, по которому осуществляется частичное исполнение.
TransKind	1, обязательно	String	Вид операции. Проставляется шифр исполняемого распоряжения.
SumResidualPayt	0..1, необязательно	Integer	Сумма остатка платежа.
AccDoc	1, обязательно	Контейнер	Реквизиты платежного документа по которому осуществляется частичное исполнение.
AccDocNo	1, обязательно	String	Номер платежного документа, по которому осуществляется частичное исполнение.
AccDocDate	1, обязательно	date	Дата платежного документа, по которому осуществляется частичное исполнение.
Priority	0..1, необязательно	String	Очередность платежа. Возможные значения: 0, 1-6.
OKTMO	1, обязательно	OKTMOType (см. описание в п. 2.5.6.4)	Код ОКТМО, указанный в распоряжении о переводе денежных средств. В случае отсутствия следует указывать значение «0», а также в случае формирования извещения при приеме наличных денежных средств в кассу получателя платежа, следует указывать значение «0».
Signature	1, обязательно	SignatureType	ЭП xml-документа. В теге содержатся реквизиты ЭП, соответствующие стандарту XML Advanced Electronic Signatures with Time-Stamp (описание стандарта находится в сети Интернет по адресу http://www.w3.org/TR/XAdES/).

2.4. Квитанция

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

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

Таблица № 3. «Тип QuittanceType»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
SupplierBillID	1, обязательно	Token	УИН. Значение совпадает со значением одноименного тега начисления.
CreationDate	1, обязательно	Date	Дата квитирования (создания квитанции).
BillStatus	1, обязательно	String	Статус, присвоенный начислению при создании квитанции. Возможные значения: 1 — сквитировано (полностью совпали все параметры квитирования); 2 — предварительно сквитировано (не совпал хотя бы один из параметров квитирования, за исключением УИН); 3 — не сквитировано (не был получен ни один платеж, соответствующий начислению); 4 — сквитировано с отсутствующим платежом (устанавливается при получении запроса на квитирование начисления с отсутствующим в ГИС ГМП платежом, см. п. 5.6).
payeeINN	0..1, необязательно	INNType (см. описание в п. 2.5.6.2)	ИНН получателя средств из начисления. Присутствует в квитанции в случае несовпадения значения этого реквизита в платеже и начислении.
payeeKPP	0..1, необязательно	KPPType (см. описание в п. 2.5.6.3)	КПП получателя средств из начисления. Присутствует в квитанции в случае несовпадения значения этого реквизита в платеже и начислении.
KBK	0..1, необязательно	KBKType (см. описание в п. 2.5.6.5)	КБК из начисления. Заполняется в случае несовпадения этого реквизита в данных платежа с данными начисления.
OKTMO	0..1, необязательно	OKTMOType (см. описание в п. 2.5.6.4)	Код ОКТМО из начисления. Присутствует в квитанции в случае несовпадения значения этого реквизита в платеже и начислении.
PayerIdentifier	0..1, необязательно	Token	Идентификатор плательщика из начисления. Присутствует в квитанции в случае несовпадения значения этого реквизита в платеже и начислении.
AccountNumber	0..1, необязательно	AccountNumType (см. описание в п. 2.5.6.1)	Номер счета получателя средств из начисления. Присутствует в квитанции в случае несовпадения значения этого реквизита в платеже и начислении.
BIK	0..1, необязательно	BIKType (см. описание в п. 2.5.6.7)	БИК банка получателя средств из начисления. Присутствует в квитанции в случае несовпадения значения этого реквизита в платеже и начислении.
Balance	0..1, необязательно	Long	Разность между суммой, указанной в начислении и суммой платежей. Целое число, показывающее сумму в копейках. Отрицательное значение информирует о переплате.
PaymentIdentificationData	0..1, необязательно	PaymentIdentificationDataType (см. описание в п. 2.5.4)	Данные, необходимые для идентификации платежа, сквитированного с начислением. Наличие данного тега обязательно, если в теге BillStatus указано значение, не равное «4».

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

2.5.1. Тип OrganizationType

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

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

Таблица № 4. «Тип OrganizationType»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
Name	1, обязательно	String	Наименование организации.
INN	1, обязательно	INNType (см. описание в п. 2.5.6.2)	ИНН организации.
KPP	1, обязательно	KPPType (см. описание в п. 2.5.6.3)	КПП организации.
OGRN	0..1, необязательно	OGRNType (см. описание в п. 2.5.6.6)	ОГРН организации.
Account	1, обязательно	AccountType (см. описание в п. 2.5.2)	Реквизиты счета организации.

2.5.2. Тип AccountType

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

— ТОФК (для учета поступлений в бюджеты бюджетной системы РФ);

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

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

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

Таблица № 5. «Параметры типа AccountType»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
Account	1, обязательно	AccountNumType (см. описание в пункте 2.5.6.1)	Номер банковского счета.
Bank	1, обязательно	BankType (см. описание в пункте 2.5.3)	Данные банка, в котором открыт счет.

2.5.3. Тип BankType

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

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

Таблица № 6. «Тип BankType»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
Name	0..1, необязательно	String	Наименование структурного подразделения кредитной организации или подразделения Банка России, в котором открыт счет.
BIK	1, обязательно	BIKType (описание см. в п. 2.5.6.7)	БИК структурного подразделения кредитной организации или подразделения Банка России, в котором открыт счет. Наличие этого тега исключает тег SWIFT.
SWIFT	1, обязательно	SWIFTType (описание см. в п. 2.5.6.8)	Код SWIFT иностранного банка, в котором открыт счет. Наличие этого тега исключает тег BIK.

2.5.4. Тип PaymentIdentificationDataType

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

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

Таблица № 7. «PaymentIdentificationDataType»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
Bank	1, обязательно	BankType (см. описание в пункте 2.5.3)	Реквизиты структурного подразделения кредитной организации, принявшего платеж. Наличие данного тега исключает появление тегов UFK и Other.
Other	1, обязательно	String	В случае приема в кассу получателя платежа наличных денежных средств от плательщика, тег должен быть заполнен значением «CASH». Наличие данного тега исключает появление тегов Bank и UFK.
UFK	1, обязательно	String	Если платеж принят ТОФК, то тег должен быть заполнен значением четырехсимвольного кода ТОФК. Если платеж принят организацией, не являющейся кредитной организацией или не являющейся ТОФК, указывается УРН организации. Наличие данного тега исключает появление тегов Bank и Other.
SystemIdentifier	1, обязательно	String	УИП, присвоенный участником, принявшим платеж. Алгоритм формирования УИП описан в пункте 3.3.

2.5.5. Тип BudgetIndexType

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

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

Таблица № 8. «Тип BudgetIndexType»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
Status	1, обязательно	String	Статус плательщика — реквизит 101 Распоряжения.
Purpose	1, обязательно	String	Показатель основания платежа — реквизит 106 Распоряжения.
TaxPeriod	1, обязательно	String	Налоговый период или код таможенного органа — реквизит 107 Распоряжения.
TaxDocNumber	1, обязательно	Token	Показатель номера документа — реквизит 108 Распоряжения.
TaxDocDate	1, обязательно	String	Показатель даты документа — реквизит 109 Распоряжения.
PaymentType	1, обязательно	String	Показатель типа платежа — реквизит 110 Распоряжения.

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

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

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

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

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

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

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

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

Основан на типе String, 11 цифр [0-9] или 8 цифр [0-9] или значение «0».

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

Основан на типе String, 20 цифр или значение «0».

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

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

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

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

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

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

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

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

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

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

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

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

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

1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20
A			B																C

А	Код главы КБК.
В	Уникальный номер начисления — 16 цифр. Алгоритм формирования, обеспечивающий уникальность номера, определяется участником самостоятельно.
С	Контрольный разряд. Алгоритм расчета представлен в п. 3.1.3.

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

1	2	3	4	5	6	7	8	9	10	11	12	13	14	…	24	25
A								B								C

A	УРН участника, сформировавшего начисление. УРН указывается в десятичном представлении. Например, УРН участника равен значению «AA11B4»; после перевода в десятичное представление получается «11145652». Если при переводе УРН участника в десятичное представление получается менее восьми символов, то значение дополняется нулями слева до 8 цифр.
B	Уникальный номер начисления — 16 цифр. Алгоритм формирования, обеспечивающий уникальность номера, определяется участником самостоятельно.
C	Контрольный разряд. Алгоритм расчета описан в п. 3.1.3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 разряд — значение «4» (признак ИП);

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

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

Таблица № 9. «Правила формирования идентификатора плательщика для ФЛ»

1	2	3	4	5	6	7	8	9	10	…	22	23	24	25
Тип документа		Серия и номер документа (в одну строку, без разделителей)										Гражданство

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

Таблица № 10. «Коды типов документов»

Значение	Описание
01	Паспорт гражданина Российской Федерации
02	Свидетельство органов ЗАГС, органа исполнительной власти или органа местного самоуправления о рождении гражданина
03	Паспорт моряка (удостоверение личности моряка)
04	Удостоверение личности военнослужащего
05	Военный билет военнослужащего
06	Временное удостоверение личности гражданина Российской Федерации
07	Справка об освобождении из мест лишения свободы
08	Паспорт иностранного гражданина либо иной документ, установленный федеральным законом или признаваемый в соответствии с международным договором Российской Федерации в качестве документа, удостоверяющего личность иностранного гражданина
09	Вид на жительство
10	Разрешение на временное проживание (для лиц без гражданства)
11	Удостоверение беженца
12	Миграционная карта
13	Паспорт гражданина СССР
14	CНИЛС
15	Удостоверение личности гражданина Российской Федерации
16 — 20	Зарезервировано
21	ИНН
22	Водительское удостоверение
23	Зарезервировано
24	Свидетельство о регистрации транспортного средства в органах Министерства внутренних дел Российской Федерации
25..99	Зарезервировано

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

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

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

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

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

Таблица № 11. «Структура УИП для кредитных организаций»

1	2	…	10	11	12	…	16	17	18	…	22	23	…	31	32
1	БИК			Номер подразделения				Дата платежа				Уникальный номер платежа в течение дня для данного подразделения

1 разряд — значение «1».

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

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

17 — 22 разряды — дата платежа в формате «ДДММГГ».

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

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

Таблица № 12. «Структура УИП для ТОФК»

1	2	3	4	5	6	7	…	16	17	18	…	22	23	…	31	32
2	ТОФК				Резерв				Дата платежа				Уникальный номер платежа в течение дня для данного ТОФК

­ 1 разряд — значение «2».

­ 2-5 разряды — код ТОФК.

­ 6-16 разряды — резерв, заполнется нулями.

­ 17-22 разряды — дата платежа в формате «ДДММГГ».

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

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

Таблица № 13. «Структура УИП для остальных участников»

1	2	…	7	8	9	…	13	14	15	…	19	20	…	28	32
3	УРН			Уникальный номер платежа в учетной системе участника

­ 1 разряд — значение «3».

­ 2-7 разряды — УРН участника, принявшего платеж.

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

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

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

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

Описание веб-сервиса SmevGISGMPService приведено в файле SmevGISGMPService.wsdl (глава 8. «WSDL веб-сервиса, размещенного в СМЭВ»).

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. Подпись под сущностью, запросом

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

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

Таблица № 14. «Алгоритмы формирования подписи»

Наименование	URI
Расчет хэш-сумм	ГОСТ Р 34.11-94	http://www.w3.org/2001/04/xmldsig-more#gostr3411
Формирования подписи	ГОСТ Р 34.10-2001	http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411, http://www.w3.org/TR/XAdES/
Каноникализация	Exclusive XML Canonicalization от 18 July 2002	http://www.w3.org/2001/10/xml-exc-c14n#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица № 15. «Права участников на выполнение различных типов запросов»

Типы запросов	ГАН/АН	ГАП/АП	ГАЗ/АЗ
Импорт начислений	+
Импорт платежей	+
Запрос статуса обработки импортируемого пакета	+	+
Экспорт начислений	+	+	+
Экспорт платежей	+	+	+
Экспорт квитанций	+	+
Квитирование начисления с платежами по инициативе АН/ГАН	+
Квитирование начисления с отсутствующим в ГИС ГМП платежом	+
Формирование начисления с признаком «Предварительное начисление»	+
Загрузка и обновление сертификатов ключа проверки ЭП участников	+	+	+

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

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

Таблица № 16. «Структура сообщения запроса к веб-сервису»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
GISGMPTransferMsg	1, обязательно	Контейнер	Корневой тег запроса.
Message	0..1, необязательно	Контейнер	Служебный блок атрибутов СМЭВ.
Sender	1, обязательно	orgExternalType	Данные о системе-инициаторе взаимодействия. Указывается информация об ИС участника, обращающегося в ГИС ГМП.
Code	1, обязательно	String	Идентификатор системы. Заполняется в соответствии с Методическими рекомендациями версии 2.5.6.
Name	1, обязательно	String	Наименование системы. Заполняется в соответствии с Методическими рекомендациями версии 2.5.6.
Recipient	1, обязательно	orgExternalType	Данные о системе-получателе сообщения. Указывается идентификатор и наименование ГИС ГМП.
Code	1, обязательно	String	Идентификатор системы. Будет уточнен после публикации электронного сервиса в промышленном контуре СМЭВ. Заполняется в соответствии с Методическими рекомендациями версии 2.5.6.
Name	1, обязательно	String	Наименование системы. Будет уточнено после публикации электронного сервиса в промышленном контуре СМЭВ. Заполняется в соответствии с Методическими рекомендациями версии 2.5.6.
Originator	0..1, необязательно	orgExternalType	Данные о системе, инициировавшей цепочку из нескольких запросов-ответов, объединенных единым процессом в рамках взаимодействия. Заполняется в соответствии с Методическими рекомендациями версии 2.5.6. ГИС ГМП не регламентируется порядок заполнения данного тега.
Code	1, обязательно	String	Идентификатор системы. Заполняется в соответствии с Методическими рекомендациями версии 2.5.6.
Name	1, обязательно	String	Наименование системы. Заполняется в соответствии с Методическими рекомендациями версии 2.5.6.
ServiceName	1, обязательно	String	Мнемоника электронного сервиса ГИС ГМП. Будет уточнена после публикации электронного сервиса в промышленном контуре СМЭВ. Наличие этого тега исключает тег Service.
Service	1, обязательно	ServiceType	Данные об электронном сервисе ГИС ГМП. Будут уточнены после публикации электронного сервиса в промышленном контуре СМЭВ. Наличие этого тега исключает тег ServiceName.
Mnemonic	1, обязательно	String	Мнемоника электронного сервиса ГИС ГМП. Будет уточнена после публикации электронного сервиса в промышленном контуре СМЭВ.
Version	1, обязательно	VersionType	Номер версии электронного сервиса ГИС ГМП. Будет уточнен после публикации электронного сервиса в промышленном контуре СМЭВ.
TypeCode	1, обязательно	TypeCodeType	Тип сообщения. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
Status	1, обязательно	StatusType	Статус сообщения. Принимает значение «REQUEST».
Date	1, обязательно	dateTime	Дата создания сообщения. Заполняется в соответствии с Методическими рекомендациями версии 2.5.6.
ExchangeType	1, обязательно	String	Категория взаимодействия. Заполняется в соответствии с Методическими рекомендациями версии 2.5.6.
RequestIdRef	0..1, необязательно	idType	Не используется.
OriginRequestIdRef	0..1, необязательно	idType	Не используется.
ServiceCode	0..1, необязательно	String	Не используется.
CaseNumber	0..1, необязательно	String	Не используется.
SubMessages	0..1, необязательно	Контейнер	Не используется.
TestMsg	0..1, необязательно	String	Признак тестового взаимодействия. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
OKTMO	0..1, необязательно	String	Не используется.
MessageData	1, обязательно	Контейнер	Блок-обертка данных СМЭВ.
AppData	1, обязательно	AppDataType	Блок структурированных сведений. Элемент RequestMessage, описанный в файле Message.xsd.
AppDocument	0..1, необязательно	AppDocumentType	Не используется.

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

Таблица № 17. «Структура RequestMessage»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
RequestMessage	1, обязательно	RequestMessageType	Корневой тег запроса.
Id (атрибут)	1, обязательно	ID	Идентификатор сообщения.
Timestamp (атрибут)	1, обязательно	dateTime	Дата и время формирования сообщения.
senderIdentifier (атрибут)	1, обязательно	String	УРН участника-отправителя сообщения.
senderRole (атрибут)	0..1, необязательно	String	Полномочие участника-отправителя сообщения (УРН которого передается в атрибуте senderIdentifier), с которым происходит обращение к ГИС ГМП. Обязательно указание в случае, когда участник зарегистрирован в ГИС ГМП с несколькими полномочиями одновременно. Допустимые значения: 1 — ГАН (главный администратор доходов бюджета); 2 — ГАН (орган государственной власти (орган местного самоуправления)); 4 — АН (администратор доходов бюджета); 5 — АН (государственное (муниципальное) учреждение); 6 — ГАП (оператор по переводу денежных средств); 6 — ГАП (орган государственной власти (орган местного самоуправления)); 7 — АП (оператор по переводу денежных средств); 8 — АП (организация почтовой связи); 9 — АП (финансовый орган); 10 — АП (местная администрация); 11 — АП (банковский платежный агент); 12 — АП (банковский платежный субагент); 13 — АП (платежный агент); 14 — АП (учреждение, осуществляющее прием от плательщиков наличных денежных средств); 15 — ГАЗ (уполномоченный многофункциональный центр); 16 — ГАЗ (орган государственной власти (орган местного самоуправления)); 17 — АЗ (оператор единого портала); 18 — АЗ (оператор регионального портала); 19 — АЗ (многофункциональный центр); 20 — АЗ (орган записи актов гражданского состояния); 21 — АЗ (орган (лицо), уполномоченное рассматривать дела и выносить постановления); 22 — АЗ (орган, осуществляющий функции по исполнению судебных актов).
callBackURL (атрибут)	0..1, необязательно	anyURI	Не используется.
RequestMessageData	Элемент заменяется на один из ниже перечисленных.
DoAcknowledgmentRequest	1, обязательно	DoAcknowledgmentRequestType	Запрос на принудительное квитирование по инициативе АН/ГАН, запрос на принудительное квитирование с отсутствующим в системе платежом, запрос на проставление статуса «Услуга предоставлена» (подробнее см. п.п. 5.5 — 5.7).
ChargeCreationRequest	1, обязательно	ChargeCreationREquestType	Формирование начисления с признаком «Предварительное начисление» (подробнее см. п. 5.8).
ExportRequest	1, обязательно	ExportRequestType	Запрос на экспорт сущностей из ГИС ГМП (подробнее см. п. 5.4)
ImportCertificateRequest	1, обязательно	ImportCertificateRequestType	Запрос на загрузку и обновление сертификатов ключа проверки ЭП (подробнее см. п. 5.9).
ImportRequest	1, обязательно	ImportRequestType	Запрос на импорт сущностей в ГИС ГМП (подробнее см. п. 5.2).
PackageStatusRequest	1, обязательно	PackageStatusRequestType	Запрос статуса протокола обработки пакета (подробнее см. п. 5.3).
Signature	0..1, необязательно	Не используется.

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

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

Таблица № 18. «Структура сообщения ответа к веб-сервису»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
GISGMPTransferMsg	1, обязательно	Контейнер	Корневой тег ответа.
Message	0..1, необязательно	Контейнер	Служебный блок атрибутов СМЭВ.
Sender	1, обязательно	orgExternalType	Данные о системе-отправителе сообщения. Указываются идентификатор и наименование ГИС ГМП.
Code	1, обязательно	String	Идентификатор системы. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
Name	1, обязательно	String	Наименование системы. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
Recipient	1, обязательно	orgExternalType	Данные о системе-получателе сообщения. Указывается информация об ИС участника, обращающегося в ГИС ГМП.
Code	1, обязательно	String	Идентификатор системы. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
Name	1, обязательно	String	Наименование системы. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
Originator	0..1, необязательно	orgExternalType	Данные о системе, инициировавшей цепочку из нескольких запросов-ответов, объединенных единым процессом в рамках взаимодействия. ГИС ГМП не регламентируется порядок заполнения данного тега.
Code	1, обязательно	String	Идентификатор системы. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
Name	1, обязательно	String	Наименование системы. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
ServiceName	1, обязательно	String	Мнемоника электронного сервиса ГИС ГМП. Будет уточнена после публикации электронного сервиса в промышленном контуре СМЭВ. Наличие этого тега исключает тег Service.
Service	1, обязательно	ServiceType	Данные об электронном сервисе ГИС ГМП. Будут уточнены после публикации электронного сервиса в промышленном контуре СМЭВ. Наличие этого тега исключает тег ServiceName.
Mnemonic	1, обязательно	String	Мнемоника электронного сервиса ГИС ГМП. Будет уточнена после публикации электронного сервиса в промышленном контуре СМЭВ.
Version	1, обязательно	VersionType	Номер версии электронного сервиса ГИС ГМП. Будет уточнен после публикации электронного сервиса в промышленном контуре СМЭВ.
TypeCode	1, обязательно	String	Тип сообщения. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
Status	1, обязательно	StatusType	Статус сообщения. Заполняется в соответствии с методическими рекомендациями версии 2.5.6. В ответе может принимать значение «RESULT», «INVALID», «REJECT» или «FAILURE».
Date	1, обязательно	dateTime	Дата создания сообщения. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
ExchangeType	1, обязательно	String	Категория взаимодействия. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
RequestIdRef	0..1, необязательно	idType	Не используется.
OriginRequestIdRef	0..1, необязательно	idType	Не используется.
ServiceCode	0..1, необязательно	String	Совпадает со значением одноименного реквизита сообщения запроса.
CaseNumber	0..1, необязательно	String	Не используется.
SubMessages	0..1, необязательно	Контейнер	Не используется.
TestMsg	0..1, необязательно	String	Признак тестового взаимодействия. Заполняется в соответствии с методическими рекомендациями версии 2.5.6.
OKTMO	0..1, необязательно	String	Не используется.
MessageData	1, обязательно	Контейнер	Блок-обертка данных СМЭВ.
AppData	1, обязательно	AppDataType	Блок структурированных сведений. Содержит элемент ResponseMessage, описанный в файле Message.xsd.
AppDocument	0..1, необязательно	AppDocumentType	Не используется.

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

Таблица № 19. «Структура ResponseMessage»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
ResponseMessage	1, обязательно	ResponseMessageType	Корневой тег запроса.
Id (атрибут)	1, обязательно	ID	Идентификатор сообщения.
кqld	1, обязательно	Token	Идентификатор сообщения-запроса.
timestamp (атрибут)	1, обязательно	dateTime	Дата и время формирования сообщения.
senderIdentifier (атрибут)	1, обязательно	String	УРН отправителя сообщения.
ResponseMessageData	Элемент заменяется на один из ниже перечисленных.
DoAcknowledgmentResponse	1, обязательно	DoAcknowledgmentResponseType	Ответ на запрос на принудительное квитирование по инициативе АН/ГАН, запрос на принудительное квитирование с отсутствующим в системе платежом, проставление статуса «Услуга предоставлена» (подробнее см. п.п. 5.5 — 5.7).
СhargeCreationResponse	1, обязательно	СhargeCreationResponseType	Ответ на запрос формирования ГИС ГМП начисления с признаком «Предварительное начисление» (подробнее см. п. 5.8).
ExportChargesResponse	1, обязательно	ExportChargesResponseType	Ответ на запрос на экспорт начислений из ГИС ГМП (подробнее см. 5.4).
ExportPaymentsResponse	1, обязательно	ExportPaymentsResponseType	Ответ на запрос на экспорт платежей из ГИС ГМП (подробнее см. 5.4).
ExportQuittanceResponse	1, обязательно	ExportQuittanceResponseType	Ответ на запрос на экспорт квитаний из ГИС ГМП (подробнее см. 5.4).
Ticket	1, обязательно	TicketType	Техническая квитанция, содержащая результат обработки запроса или протокол обработки запроса.
Signature	0..1, необязательно	SignatureType	Не используется.

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

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

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

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

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

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

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

— пакет принят в обработку (ResultCode=”10”);

— установлено несоответствие XML-схеме (ResultCode=”11”);

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

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

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

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

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

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

— пакет принят в обработку (ResultCode=”10”);

— установлено несоответствие XML-схеме (ResultCode=”11”);

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

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

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

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

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

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

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
RequestProcessResult	1, обязательно	ResultInfo	Корневой тег ответа.
ResultCode	1, обязательно	Token	Код результата обработки: 0 — если запрос успешно принят или код ошибки в случае отказа в приеме к обработке документа (см. перечень кодов в главе 5.9).
ResultDescription	0..1, необязательно	String	Описание результата обработки (см. перечень описаний результатов обработки в главе 5.9).
ResultData	0..1, необязательно	String	Данные результата обработки (для системного анализа). Для кода обработки «11» (Формат запроса (файла) не соответствует xml-схеме) в теге содержится детальная информация о выявленных несоответствиях.

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

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

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

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

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

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

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

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

Таблица № 21. «Структура ответа на запрос статуса обработки импортируемого пакета (если обработка пакета завершена)»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
TicketPackageProcessResult	1, обязательно	Контейнер	Корневой тег ответа.
EntityProcessResult	1..n, обязательно	Контейнер	Статус обработки каждой из сущностей в составе пакета.
ResultCode	1, обязательно	Token	Код результата обработки: 0 — если сущность успешно принята или код ошибки в случае неуспешного импорта (см. перечень кодов в главе 5.9).
ResultDescription	0..1, необязательно	String	Описание результата обработки (см. перечень описаний результатов обработки в главе 5.9).
ResultData	0..1, необязательно	String	Данные результата обработки (для системного анализа). Для кода обработки «11» (Формат запроса (файла) не соответствует xml-схеме) в теге содержится детальная информация о выявленных несоответствиях.
entityId (атрибут)	1, обязательно	Token	Идентификатор элемента. Соответствует атрибуту Id обработанной сущности.

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

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

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

Таблица № 22. «Структура запроса на экспорт»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
ExportRequest	1, обязательно	DataRequest	Корневой тег запроса.
Id (атрибут)	0..1, необязателен	ID	Необходим для наложения ЭП в формате XadES. Должен иметь структуру <буква [A-Z]>_<GUID>. Обязателен при наложении ЭП под запросом.
kind (атрибут)	1, обязательно	String	Атрибут, устанавливающий тип запроса. Допустимые значения описаны в пунктах 5.4.2 — 5.4.6.
originatorID (атрибут)	0..1, необязательно	URNType (см. описание в п. 2.5.6.10)	УРН участника, сформировавшего запрос. Если запрос сформировал участник косвенного взаимодействия, то заполнение тега является обязательным.
Filter	1, обязательно	Контейнер	Фильтр для получения сущностей из ГИС ГМП.
Conditions	1, обязательно	Контейнер	Условие для получения сущностей из ГИС ГМП.
ChargesIdentifiers	1, обязательно	Контейнер	Список УИН, по которым запрашиваются сущности.
SupplierBillID	1, обязательно	Token	УИН. При запросе начислений соответствует атрибуту supplierBillID начисления. При запросе платежей соответствует тегу SupplierBillID платежа. При запросе квитанций соответствует УИН начисления (указан в атрибуте supplierBillID), на которое ссылаются квитанции. Может быть множественным, при этом итоговая выгрузка будет являться объединением выгрузок по каждому из указанных УИН.
Payers	1, обязательно	Контейнер	Список идентификаторов плательщиков, по которым запрашиваются сущности.
PayerIdentifier	1, обязательно	Token	Идентификатор плательщика. При запросе начислений соответствует значению тега UnifiedPayerIdentifier или AltPayerIdentifier. При запросе платежей соответствует значению тега PayerIdentifier. При запросе платежей по связанным начислениям игнорируется. При запросе квитанций соответствует значению тега UnifiedPayerIdentifier или AltPayerIdentifier, указанного в начислении, на которое ссылаются квитанции. Может быть множественным, при этом итоговая выгрузка будет являться объединением выгрузок по каждому из указанных идентификаторов плательщика.
Timeslot	0..1, необязательно	Контейнер	Временной интервал, за который запрашиваются сущности. Если тег Timeslot не указан в запросе, то возвращаются удовлетворяющие остальным параметрам запроса сущности, импортированные или созданные в ГИС ГМП за весь период функционирования системы.
startDate (атрибут)	1, обязательно	DateTime	Дата и время, не ранее которых была импортирована в ГИС ГМП самая старая из возвращаемых сущностей или была создана самая старая из возвращаемых квитанций.
endDate (атрибут)	1, обязательно	DateTime	Дата и время, не позднее которых была импортирована в ГИС ГМП самая новая из возвращаемых сущностей или была создана самая новая из возвращаемых квитанций.
AdditionRestrictions	0..1, необязательно	Контейнер	Дополнительные ограничения.
SubordinateIdList	0..1, необязательно	Контейнер	Список идентификаторов участников косвенного взаимодействия.
TaxpayerIdentification	1..100, обязательно	Контейнер	Идентификация получателя средств. Наличие данного/данных тега/тегов исключает наличие тега/тегов PayeeID.
inn (атрибут)	1, обязательно	INNType (см. описание в п.2.5.6.2)	ИНН получателя средств, указанный в возвращаемой сущности. При запросе квитанций соответствует ИНН получателя, указанному в начислении, на которое ссылается квитанция. Если указано несколько тегов TaxpayerIdentification, то итоговая выгрузка будет являться объединением выгрузок по всем участникам косвенного взаимодействия, каждая из которых определяется отдельным тегом TaxpayerIdentification.
kpp (атрибут)	0..1, необязательно	KPPType (см. описание в п. 2.5.6.3)	КПП получателя средств, указанный в возвращаемой сущности. При запросе квитанций соответствует КПП получателя, указанному в начислении, на которое ссылается квитанция.
PayeeID	1..100, обязательно	String	УРН участника, сформировавшего сущность. При запросе квитанций соответствует УРН участника, сформировавшего начисление, на которое ссылается квитанция. Если указано несколько тегов PayeeID, то итоговая выгрузка будет являться объединением выгрузок по всем участникам косвенного взаимодействия, каждая из которых определяется отдельным тегом PayeeID. Наличие данного/данных тега/тегов исключает наличие тега/тегов TaxpayerIdentification.
KBKClassifier	0..1, необязательно	Контейнер	Перечень КБК.
KBK	1..100, обязательно	KBKType (см. описание в п. 2.5.6.5)	КБК, указанный в сущности. При запросе начислений соответствует КБК, указанному в начислении. При запросе платежей соответствует КБК, указанному в платеже. При запросе платежей по связанным начислениям игнорируется. При запросе квитанций соответствует КБК, указанному в начислении, на которое ссылаются квитанции. Может быть множественным, при этом итоговая выгрузка будет являться объединением выгрузок по каждому из указанных КБК.
OKTMOClassifier	0..1, необязательно	Контейнер	Коды ОКТМО.
OKTMO	1..100, обязательно	OKTMOType (см. описание в п. )	Код ОКТМО. При запросе начислений соответствует коду ОКТМО, указанному в начислении. При запросе платежей соответствует коду ОКТМО, указанному в платеже. При запросе платежей по связанным начислениям игнорируется. При запросе квитанций соответствует коду ОКТМО, указанному в начислении, на которое ссылаются квитанции. Может быть множественным, при этом итоговая выгрузка будет являться объединением выгрузок по каждому из указанных коду ОКТМО.
Exclude	0..1, необязательно	String	Признак, означающий ненулевые УИН (допустимое значение — ZERO-UIN). При запросе платежей должна возвращаться информация о платежах, в которых указан УИН, отличный от нуля.
Paging	0..1, необязательно	Контейнер	Параметры постраничной выдачи (при больших объемах экспортируемых данных).
pageLength (атрибут)	1, обязательно	Int (>=1)	Количество элементов на странице выдачи (количество сущностей в ответе).
pageNumber (атрибут)	1, обязательно	Int (>=1)	Номер страницы выдачи. Вся полученная в результате выполнения запроса выборка разбивается на блоки размером pageLength, начиная с первого элемента. Последнй блок может быть меньше, чем pageLength. Возвращается только блок, номер которого равен pageNumber.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица № 23. «Структура ответа на запрос экспорта начислений»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий для типов запроса CHARGE, CHARGENOTFULLMATCHED CHARGEPRIOR, CHARGEPRIORNOTFULLMATCHED	Комментарий для типов запроса CHARGESTATUS, CHARGEPRIORSTATUS, CHARGETEMPSTATUS
ExportChargesResponse	1, обязательно	ExportChargesResponseType	Ответ на запрос начислений.	Ответ на запрос начислений.
Charges	1, обязательно	Контейнер	Перечень начислений и признак конца выборки	Перечень начислений.
hasMore (атрибут)	1, обязательно	boolean	Признак конца выборки: false — достигнут конец выборки, true — после последней выгруженной сущности в выборке имеются другие.	Признак конца выборки: false — достигнут конец выборки, true — после последней выгруженной сущности в выборке имеются другие.
needReRequest (атрибут)	0..1, необязательно	boolean	true — требуется повторный запрос. В случае, если для получения ответа потребовалось задействовать внешнюю систему и ответ от нее не был получен (внешняя система недоступна либо получена ошибка).	true — требуется повторный запрос. В случае, если для получения ответа потребовалось задействовать внешнюю систему и ответ от нее не был получен (внешняя система недоступна либо получена ошибка).
ChargeInfo	0..n, необязательно	Контейнер	Данные начисления.	Данные начисления.
ChargeData	1, обязательно	Base64Binary	Данные начисления, полученные при импорте от АН/ГАН.	Данные начисления, полученные при импорте от АН/ГАН.
ChargeSignature	0..1, необязательно	Base64Binary	Данные файла ЭП начисления, переданного от АН/ГАН в ГИС ГМП.	Данные файла ЭП начисления, переданного от АН/ГАН в ГИС ГМП.
AmountToPay	1, обязательно	long	Остаток суммы подлежащей оплате, указанной в начислении (в копейках).	Остаток суммы подлежащей оплате, указанной в начислении (в копейках). При переплате начисления принимает отрицательное значение; при полной оплате — значение «0».
QuittanceWithPaymentStatus	0..1, необязательно	String	Не заполняется для данного запроса.	Статус квитирования с платежами (заполнен всегда). Возможные значения: 1 — сквитировано; 2 — предварительно. сквитировано; 3 — не сквитировано; 4 — сквитировано с отсутствующим в системе платежом.
IsRevoked	0..1, необязательно	boolean	Не заполняется для данного запроса. Возвращаются только действующие неоплаченные начисления / частично оплаченные.	Показатель аннулированного начисления. Возможные значения: true — начисление аннулировано; false — начисление действующее.
date (атрибут)	0..1, необязательно	dateTime	Не заполняется для данного запроса.	Дата аннулирования начисления

В случае возникновения ошибки при обработке запроса на экспорт начислений код ошибки возвращается в сообщении ответа в теге 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 (глава . «XML-схемы сущностей и сообщений ГИС ГМП») , описание параметров приведено в Таблице № 24 «Структура ответа на запрос экспорта платежей».

Таблица № 24 «Структура ответа на запрос экспорта платежей»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
ExportPaymentsResponse	1, обязательно	ExportPaymentsResponseType	Ответ на запрос платежей.
Payments	1, обязательно	Контейнер	Перечень платежей и признак конца выборки.
hasMore (атрибут)	1, обязательно	boolean	Признак конца выборки: false — достигнут конец выборки, true — после последней выгруженной сущности в выборке имеются другие.
PaymentInfo	0..n, необязательно	Контейнер	Данные платежа.
PaymentData	1, обязательно	Base64Binary	Данные платежа, полученные при импорте от АП/ ГАП.
PaymentSignature	0..1, необязательно	Base64Binary	Данные файла ЭП платежа, переданного в ГИС ГМП АП/ ГАП.
PaymentStatus	0..n, необязательно	Контейнер	Признак “Услуга предоставлена” или “Сквитировано с начислением”.
name (атрибут)	1, обязательно	String	Обозначение. Для обозначения факта квитирования платежа с начислением в name указывается значение «Сквитировано с начислением». Для обозначения у платежа признака «Услуга предоставлена» в name указывается значение «Услуга предоставлена».
value (атрибут)	0..1, необязательно	String	Код, уточнение. Для обозначения факта квитирования платежа с начислением в value указывается УИН, c которым сквитирован платеж. Для обозначения у платежа признака «Услуга предоставлена» в value указывается значение «1».

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

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

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

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

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

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

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

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

Таблица № 25 «Структура ответа на запрос квитанций»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
ExportQuittanceResponse	1, обязательно	ExportQuittanceResponseType	Ответ на запрос квитанций.
Quittances	0..1, необязательно	Контейнер	Перечень квитанций.
hasMore	1, обязательно	boolean	Признак конца выборки: false — достигнут конец выборки, true — после последней выгруженной квитанции в выборке имеются другие.
Quittance	1..n, обязательно	Расширение типа QuittanceType (см. описание в пункте 2.4)	Данные квитанции.
IsRevoked	0..1, необязательно	boolean	Не возвращаются для запроса типа QUITTANCE. При запросе типа ALLQUITTANCE возвращаются следующие значения: true — неактивная квитанция; false — квитанция действующая.

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

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

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

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

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

Таблица № 26 «Структура запроса на проведение квитирования начисления с платежами по инициативе АН/ГАН»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
DoAcknowledgmentRequest	1, обязательно	DoAcknowledgmentRequestType	Корневой тег запроса.
Id (атрибут)	0..1, необязателен	ID	Необходим для наложения ЭП в формате XadES. Должен иметь структуру <буква [A-Z]>_<GUID>. Обязателен при наложении ЭП под запросом.
originatorID (атрибут)	0..1, необязательно	URNType (см. описание в п. 2.5.6.10)	УРН участника, сформировавшего запрос. Если запрос сформировал участник косвенного взаимодействия, то заполнение тега является обязательным.
SupplierBillID	1, обязательно	token	УИН.
Payments	1, обязательно	Контейнер	Перечень идентификаторов платежей.
PaymentSystemIdentifier	1..n, обязательно	token	УИП. Для запроса квитирования начисления с отсутствующим в ГИС ГМП платежом необходимо использовать единственный тег PaymentSystemIdentifier, заполненный значением «PaymentNotLoaded», см. пункт 5.6.

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

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

Таблица № 27 «Структура ответа на запрос проведения квитирования начисления с платежами по инициативе АН»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
DoAcknowledgmentResponse	1, обязательно	DoAcknowledgmentResponseType	Корневой тег ответа.
Quittances	0..1, необязательно	Контейнер	Перечень квитанций.
Quittance	1..n, обязательно	QuittanceType	Данные созданной квитанции.

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

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

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

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

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

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

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

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

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

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

— АЗ с полномочиями органа ЗАГС;

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

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

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

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

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

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

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

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

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

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

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

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

Таблица № 28 «Структура запроса на формирование предварительного начисления»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
ChargeCreationRequest	1, обязательно	ChargeCreationRequestType	Корневой тег запроса.
Id (атрибут)	1, обязательно	ID	Необходим для наложения ЭП в формате XadES. Должен иметь структуру <буква [A-Z]>_<GUID>.
originatorID (атрибут)	0..1, необязательно	URNType	УРН участника, сформировавшего шаблон начисления. Если запрос сформировал участник косвенного взаимодействия, то заполнение тега является обязательным.
ChargeTemplate	1, обязательно	ChargeTemplateType (описание элементов представлено в Таблице № 29. «Тип ChargeTemplateType»)	Шаблон начисления, на основании которого ГИС ГМП будет сформировано предварительное начисление.
Signature	0..1, необязательно	ds:SignatureType	ЭП xml-документа (шаблона начисления). В теге содержатся реквизиты ЭП, соответствующие стандарту XML Advanced Electronic Signatures with Time-Stamp (описание стандарта находится в сети Интернет по адресу http://www.w3.org/TR/XAdES/).

Таблица № 29. «Тип ChargeTemplateType»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
ValidUntil	1, обязательно	Date	Дата, вплоть до которой актуально предварительное начисление, сформированнное ГИС ГМП по запросу участника. Дату указывает участник, направивший запрос на формирование предварительного начисления.
SupplierOrgInfo	1, обязательно	OrganizationType (см. описание в п. 2.5.1)	Данные организации, являющейся получателем средств.
BillFor	1, обязательно	String	Назначение платежа.
TotalAmount	1, обязательно	unsignedLong	Сумма начисления. Целое число, показывающее сумму в копейках.
KBK	1, обязательно	KBKType (см. описание в п. 2.5.6.5)	КБК.
OKTMO	1, обязательно	OKTMOType (см. описание в п. 2.5.6.4)	Код ОКТМО получателя средств.
BudgetIndex	1, обязательно	BudgetIndexType (см. описание в пункте 2.5.5)	Дополнительные реквизиты платежа, заполняемые в платежном поручении при оплате государственной услуги.
UnifiedPayerIdentifier AltPayerIdentifier	1, обязательно	String	Идентификатор плательщика для ЮЛ или ИП. Алгоритм формирования идентификатора плательщика для ЮЛ или ИП описан в пункте 3.2. Наличие данного тега исключает наличие тега AltPayerIdentifier.
AltPayerIdentifier	1, обязательно	String	Идентификатор плательщика для ФЛ. Алгоритм формирования идентификатора плательщика для ФЛ описан в пункте 3.2. Наличие данного тега исключает наличие тега UnifiedPayerIdentifier.
TreasureBranch	1, обязательно	String	Сокращенное наименование органа Федерального казначейства.
TOFK	0..1, необязательно	String	Код ТОФК, в котором открыт лицевой счет получателю или финансовому органу.
FOName	0..1, необязательно	String	Наименование финансового органа.
LSvUFK	0..1, необязательно	String	Номер лицевого счета получателя или финансового органа в ТОФК.
LsvFO	0..1, необязательно	String	Номер лицевого счета получателя в финансовом органе.
AdditionalData	0..n, необязательно	Контейнер	Дополнительные поля начисления.
Name	1, обязательно	String	Наименование поля.
Value	1, обязательно	String	Значение поля.

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

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

Таблица № 30. «Структура ответа на запрос формирования предварительного начисления»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
ChargeCreationResponse	1, обязательно	ChargeCreationResponceType	Ответ на запрос формирования предварительного начисления.
ChargeData	1, обязательно	Base64Binary	Данные предварительного начисления, сформированного ГИС ГМП по запросу участника.

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

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

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

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

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

Таблица № 31 «Структура запроса на загрузку или обновление сертификата ключа проверки ЭП участников»

Наименование	Кол-во тегов, обязательность тега или атрибута	Тип данных	Комментарий
ImportCertificateRequest	1, обязательно	ImportCertificateRequestType	Корневой тег запроса.
RequestEntry	1..n, обязательно	RequestEntryType	Контейнер.
operation (атрибут)	1, обязательно	String	Вид операции. Возможны значения: APPEND — загрузка нового сертификата ключа проверки ЭП. REPLACE — обновление хранящегося в ГИС ГМП сертификата ключа проверки ЭП.
ownership (атрибут)	1, обязательно	URNType (см. описание в п. 2.5.6.10)	УРН владельца сертификата ключа проверки ЭП.
serialNumber (атрибут)	0..1, необязательно	String	Уникальный номер сертификата. Обязательно указание при обновлении сертификата (operation= «REPLACE»).
certificate (атрибут)	1, обязательно	Base64Binary	Файл, содержащий сертификат ключа проверки ЭП участника в кодировке Base64.

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

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

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

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

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

Идентификатор ГИС ГМП

Уникальный идентификатор начисления (УИН) — это новый реквизит платежного документа, введенный Минфином РФ в 2014 году для осуществления уплаты налоговых платежей и других сборов в бюджетную систему Российской Федерации.

Что такое УИН и для чего он нужен

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

Данный идентификатор начислений необходимо указывать:

• при оплате услуг органам местного самоуправления и государственной власти;
• при осуществлении платежей в бюджет Российской Федерации.

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

Где узнать уникальный идентификатор начислений (УИН)

Начинающий бухгалтер может задаться вопросом, где ему узнать УИН. Специальных документов и справочников, предоставляющих эту информацию, не существует. Код УИН является уникальным и не может повторяться. Уникальный идентификатор присваивается при начислении платежа администратором доходов бюджетной системы Российской Федерации. В случае самостоятельного расчета налога или страхового взноса у такого платежа кода УИН не будет.

УИН всегда состоит из 4 частей и 20 знаков.

1. Знаки с 1 по 3 предназначены для получателя платежа, администратора поступлений в бюджет или кода органа исполнительной власти.

Для налоговой это код 182, а например, для ГИБДД три первые цифры УИН будут 188.

2. Знак 4 – не используемый в настоящее время идентификатор, поэтому имеет значение 0.

3. Знаки с 5 по 19 — уникальный номер осуществляемого платежа или индекс документа в налоговой системе РФ.

4. Знак 20 является контрольным блоком, высчитываемым по специально разработанному алгоритму.

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

Как расшифровывается уникальный идентификатор начислений (УИН)

При получении требования об уплате налогов (взносов) из налоговой или другого фонда необходимо обратить внимание, есть ли в данном документе 20-значный код уникального идентификатора (УИН). Если он имеется, то при формировании платежного документа УИН необходимо внести в поле «Код». Например, УИН 98765432109876543210. Если код УИН не указан, то тогда, так же как и при добровольном платеже, необходимо в данном поле поставить ноль.

При отсутствии уведомления от налогового органа у физических лиц есть возможность самостоятельно сформировать платежный документ. На сайте ФНС России существует интернет-сервис, который позволяет налогоплательщику формировать квитанции на оплату, при этом индекс документа (УИН) присваивается автоматически.

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

Что такое код УИН в платёжном поручении и где его взять

Заполняющий платёжное поручение нередко наталкивается на поле №22, и сразу возникает вопрос: что это за «код УИН» и откуда его взять? Сразу хотим успокоить — нужен он далеко не всегда (вернее, во многих случаях там ставится ноль). Итак, УИН – это уникальный идентификатор начисления. Его нужно прописывать при совершении платежей через банк.

Что такое УИН

УИН — цифровой код, который нужен для контроля над платежами в бюджет государства от ФЛ и ЮЛ. Это значение, в которое входит 20 цифр. От других сведений цифры отделяются символом «///».

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

Идентификатор заносится в поле «Код». Это поле обозначается цифрами 22. Указывать код УИН в платежных документах нужно обязательно. Без этого невозможно направить средства в бюджет страны. Т.е. даже если УИНа нет, нужно ставить ноль. Пустым поле оставлять нельзя. К примеру, это могут быть платежи:

• Налоги.
• Государственные пошлины.
• Штрафы.
• Пени.
• Различные задолженности.

Сотрудники банка не примут платежки без указания кода. Его также нужно прописывать при переводе средств через терминалы.

К СВЕДЕНИЮ! Для каждого типа платежа код УИН будет различным. А потому очень часто возникает путаница. Плательщики не знают, какие именно цифры указывать в платежках.

Значение составляющих идентификатора

Каждое число, включенное в идентификатор, имеет свой смысл:

• Первые три числа. Присваиваются казначейством.
• Четвертое число. Обозначает ведомство, от которого пришел запрос на перечисление средств.
• Пятое число. Представляет собой код платежа.
• Шестое и седьмое число. Дата проведения платежа.
• Числа с 8-го по 12-е. Серия и номер.
• Двадцатое число. Нужно для повышения уникальности идентификатора. Присваивается конкретной платежке.

Идентификатор утверждается получателем средств. Формирование его – это автоматический процесс. Код должен быть уникальным для каждого платежного документа.

ВАЖНО! Плательщику нельзя формировать код самостоятельно, используя произвольные числа. Если код УИН будет просто придуман, средства не дойдут до их получателя.

ВНИМАНИЕ! Иногда, если лицо не знает свой идентификатор, можно проставить «0». В некоторых случаях код УИН дополняется буквенными обозначениями. Это могут быть русские или латинские буквы.

Что обозначает идентификатор в квитанции

Код служит идентификации платежа. В нем содержится эта информация:

• Кем выставляется платеж.
• Адресат платежа.
• За что именно уплачиваются средства.

Сотрудник банка может расшифровать код, после чего он направляет платеж его адресату. Все начисления в бюджет фиксируются в системе ГТС ГМП. Наличие кода позволяет безотлагательно зафиксировать платеж.

Правовая база

Использование идентификатора было установлено Приказом Минфина №106н от 24 ноября 2004 года. Это был первый документ, который утвердил использование УИН в качестве реквизитов. Однако когда действовал только этот документ, код использовался в рекомендательном порядке. Необходимость его применения появилась после выхода Приказа Минфина №107 от 12 ноября 2013 года. Соответствующее обязательство связано с формированием системы ГИС ГМП.

До 31 марта 2014 года идентификатор указывался в поле «Назначение средств». После этой даты код стал вноситься в поле «22».

Еще один регулирующий документ – ФЗ №210 «О предоставлении госуслуг» от 27 июля 2010 года. Он утвердил идентификатор платежей, который нужен для быстрой доставки средств по назначению.

Для чего нужен УИН

УИН требуется для быстрого и эффективного распределения средств. Представители банков и бюджетных структур на основании этого кода определяют, кому предназначаются средства. Так как код служит идентификации, он будет уникальным для каждого платежного документа.

Система УИН служит упрощению системы бюджетных платежей и сборов. Она позволяет исключить появление платежей с неопределенным назначением. Указание идентификатора позволяет быть уверенными в том, что средства точно дойдут до своего адресата.

Как получить идентификатор

Для получения УИН нужно проделать следующие действия:

1. Получение от бюджетных структур требования об уплате средств (пени, штрафов, налогов).
2. Именно в этом требовании можно найти нужный идентификатор.
3. В платежный документ вносятся все цифры, содержащиеся в требовании. Вносить их нужно в код «22». Это поле находится в нижнем блоке платежки.

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

ВАЖНО! Код УИН актуален только для платежей, адресатом которых являются государственные и бюджетные структуры.

Когда в коде УИН нет необходимости

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

Рассмотрим пример. ЮЛ оплачивает НДС. Реквизитом в этом случае может являться КБК. Он указывается в поле 104. ИП и ФЛ в качестве кода может использовать ИНН. Однако если в строке 22 не будет указано ничего, платежка не принимается. А потому в этой строке нужно прописать «0».

Особенности указания кода при различных типах платежей

Нюансы указания УИН зависят от конкретного вида платежа.

Налоги

Нужный УИН содержится в индексе требования. Это актуально в том случае, если плательщику выставляется платежка. Если же он уплачивает текущий налог самостоятельно, идентификатор указывать не требуется. В поле 22 проставляется код «0». Основание – Письмо ФСС №17-03-11/14-2337 от 21 февраля 2014 года. Также заменить реквизит можно ИНН (письмо ФНС №3Н-4-1/6133 от 8 апреля 2016 года). Однако в платежных документах можно указать и УИН, и ИНН.

Госпошлина

Госпошлина уплачивается на основании поступившей квитанции. Если она получена по месту обращения, нужный идентификатор – это индекс квитанции. Однако обычно плательщик не обращается в органы за документом. То есть код ему узнать не от куда. В этом случае в строке 22 указывается «0».

Уплата услуг детского сада

При уплате услуг детского сада также нужно указывать идентификатор. Нюанс получения кода заключается в том, что обычно детские сады не выставляют никаких письменных требований родителям. Где получить УИН? За ним можно обратиться в бухгалтерию сада. Код включает в себя обозначение ребенка. За УИН достаточно обратиться один раз. В дальнейшем платежи будут совершаться по ранее полученному коду. Так же выполняется оплата обучения в платных школах.

Штрафы ГИБДД

Штрафы ГИБДД оплачиваются по документу, являющемуся основанием для назначения платежа. В этом же документе и указывается УИН. В коде содержится эта информация:

• Номер протокола.
• Дата составления этой бумаги.

Рассмотрим расшифровку идентификатора:

• Первые три числа. Номер распорядителя. Номер для ГИБДД – 188.
• Четвертый символ. Адресат – 1.
• Пятый символ. Назначение средств. Если выплачивается штраф, проставляется цифра 1.
• Шестой и седьмой символ. Дата оформления бумаги, на основании которой совершается платеж.
• Остальные числа. Серийный номер.

Если присутствует постановление, на основании которого выплачивается штраф, плательщику не обязательно указывать УИН. Сделать это за него может банковский работник.

Что такое уникальный идентификатор платежа? Как узнать уникальный идентификатор платежа

Но даже если не удалось узнать и указать в поручении идентификатор, это не дает право банкам отказываться принимать его. Банк обязан принять и перевести средства, даже если не указан УИП (уникальный идентификатор платежа). Правило это прописано в официальных документах налоговой службы. В нем вполне ясно указано, что физическому или юридическому лицу достаточно указать свой ИНН, а в строке (код 22) уникального идентификатора платежа вписать «0». В таком случае банк не имеет права отказаться от перевода платежа. Но предприниматель должен учитывать, что в случае ошибки или задержки банк ответственности не несет.

Для налоговой службы он нужен для того, чтобы более эффективно проводить фискальную политику и выявлять злостных неплательщиков. Юридическим и физическим лицам нужен в качестве наиболее удобного и быстрого способа оплатить налоги. В результате правительство может контролировать действия налоговиков и пресекать случаи, когда их действия превышают переданные им полномочия, что нередко случалось ранее. Бизнесмены менее зависят от воли отдельного налогового инспектора и страдают от незаконных поборов. Сократилось количество проводимых проверок.

Что такое уникальный идентификатор начисления

• У государственного или муниципального органа власти, который является администратором платежа;
• Через интернет-портал государственных услуг при наличии регистрации личного кабинета;
• В кредитной организации, осуществляющей прием и перевод денежных средств в бюджетную систему. Узнать УИН в банке можно только в том случае, если у него есть соглашение с государственным органом, администрирующим платежи, по формированию идентификаторов.

С 4 февраля 2014г. утвержден новый порядок заполнения поручений на перевод денежных средств для оплаты бюджетных платежей. Порядком предусмотрено заполнение всех обязательных реквизитов, указанных в правилах по осуществлению переводов. При переводе налогов, сборов и других обязательных платежей в бюджет, администраторами которых выступают государственные или муниципальные органы власти, обязательно надо указывать уникальный код – УИН. Он является идентификатором для отнесения платежей по их назначению органами Федерального казначейства. УИН позволяет производить процедуру зачисления быстро и избежать при этом ошибок.

Как узнать идентификатор плательщика

Так, например, добровольное перечисление налога на основании расчетных данных деклараций указания УИН не требует.
Определяется такой платеж на основании КБК, а реквизиты плательщика, будь то физическое или юридическое лицо, идентифицируются при помощи ИНН и КПП.
То же самое касается и прочих переводов средств. Идентификатор в таких случаях также не используется.
Чтобы быть уверенным в полном погашении обязательств перед государством, следует периодически сверяться с органами ФНС. О том, в какой форме с 2019 года составляется акт сверки, читайте в статье «Внимание! Новая форма акта сверки с налоговой». УИП ― что это такое УИП ― присвоенный получателем платежа код, не относящийся к бюджетным перечислениям.

Если предприниматель не имеет доступа в интернет и к электронной системе «Госуслуги», он может послать обычное письмо в ближайшее отделение налоговой службы или явиться лично для получения идентификатора. Какие документы нужны для получения идентификатора? Все зависит от того, в какой форме будет составлен документ и как оплачиваться. Если это бумажный документ, то необходимо отправить письменный запрос в налоговый орган.

Что такое УИН в квитанции и как его узнать в 2019 году

УИН формирует организация, в адрес которой совершаются начисления. Если платеж совершается в ГИБДД, УИН может сформировать банковский работник. Каждый плательщик имеет свой уникальный код для каждого отдельного платежа. Если плательщик не знает, какой УИН следует проставить, в соответствующей графе квитанции нужно указать значение 0. Если оставить эту строку пустой, банк не сможет принять платеж. Некоторые сталкиваются с проблемой, когда при совершении платежа код не идентифицируется. В этом случае необходимо обратиться в организацию, в которую направлен платеж, и проверить правильность указанного в платежном документе кода.

Постановление Министерства финансов о том, что этот показатель требуется указывать в платежных документах, было принято в начале 2014 года. После вступления в силу этого постановления в форму 0504510 «Квитанция» уникальный идентификатор был внесен как обязательный реквизит.

Нередко граждане сталкиваются с необходимостью правильного заполнения необходимых реквизитов в платежных ведомостях, налоговых декларациях, штрафных квитанциях, платежках, оплачивающих услуги бюджетных организаций. Затруднения обычно вызывают поля, где необходимо проставить идентификатор плательщика (ИП) и еще один идентификатор — УИН (он же УИП). Как узнать, что это такое? Что такое идентификационный номер плательщика, обычно граждане знают: в форме декларации о налогах он указывается обычно как ИНН.

Что такое УИН: правила присвоения и указания

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

Когда необходимо указывать УИН

Решение о необходимости указания данного реквизита в ряде случаев принято согласно приказу Минфина РФ N 107н от 12 ноября 2013 г. Так, следующие платежные поручения по перечислениям в госбюджет должны обязательно содержать УИН и идентификатор плательщика:

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

Форма квитанции, в которой нужно обязательно указать УИН — 504 510.

Какой идентификатор указывают в НДФЛ и при налоговых сборах

В декларации о доходах указывают не УИН, а идентификатор плательщика (ИП):

• для юридического лица — ИНН;
• физического — СНИЛС или другой, в том числе альтернативный, идентификатор физлица;
• для иностранной организации (ИО) — код ИО (КИО).

В строке № 22 «уникальный идентификатор начислений (платежа)» необходимо проставить «0».

Внимание! Нет необходимости формировать УИН при уплате земельного, имущественного, транспортного налога. В этих случаях в платежных документах формы N ПД, присланных из НС, в качестве УИН нужно указать индекс налогового документа.

Платежное поручение можно оформить непосредственно на сайте Федеральной налоговой службы, воспользовавшись электронным сервисом. При этом УИН будет присвоен автоматически.

Разъяснение по этим вопросам дала федеральная налоговая служба, которая конкретизировала случаи, когда не нужно указание УИН.

Надо ли указывать УИН в других платежах

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

Если банк неправомерно требует указать УИН в платежной ведомости, работникам необходимо напомнить о письме ФНС РФ N ЗН-4−1/6133@ от 8 апреля 2016.

Как присваивается УИН

Согласно приказу ФС ФБН № 48 от 28.02.2014 г. необходимо присваивать не только УИП, но и ИП:

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

Правила присвоения идентификатора содержатся в приложении 1 приказа ФС ФБН.

Код УИН (УИП) содержит 20 цифр, идентификатор плательщика ИП — 25.

Состав кода УИН по разрядам

• Первые три разряда содержат код главного админа по государственному бюджетному доходу (государственного органа, местной администрации, ОМСУ — ст. 6 Бюджетного кодекса РФ).
• Разряды 4 — 6: последние три цифры кода РПБС (реестр получателя бюджетных ср-в). (Реестр создан на основании приказа Минфина № 163н от 23.12.2014 г.).
• Разряды 7 — 9: индекс структурной единицы (если организация не имеет структурных подразделений, ставятся нули).
• Разряд 10-й — код дела: 1 — если принято решение о наказании за АП в виде штрафа по КоАп; 2 — если дело передано мировому судье.
• Разряды 11 — 14: год и месяц регистрации АП.
• Разряды 15 — 19: порядковый номер регистрации АП.
• Разряд 20 — контрольный ключ.

Примечание: При отсутствии административных дел о правонарушениях в полях идентификатора, предназначенных под 10 — 19 разряды проставляются нули.

Отсюда ясно, что в простой квитанции за садик в десяти предпоследних полях кода будет стоять «0».

Где взять код главного администратора доходов

Код главного админа госдоходов берется из перечня, установленного федеральным законом № 359 — ФЗ от 22 ноября 2016 г.

Перечень кодов можно увидеть .

Как рассчитать контрольный ключ в коде УИН

Контрольный ключ представляет из себя цифру от 0 до 9 и должен занимать один разряд (одно поле).

• Чтобы рассчитать ключ необходимо каждому разряду присвоить вес от единицы до десяти (от старшего разряда, то есть самого первого поля, до младшего). После 10 разряда, снова начинают присваивать вес, начиная с единицы.
• Каждую цифру УИН умножают на присвоенный вес и складывают сумму всех произведений.
• Полученную сумму делят на 11. Остаток деления — это и будет контрольный ключ.
• Если при расчете получают двузначное число, повторяют присвоение веса, но не от 1 до 10, а уже 3 до 5 включительно. Повторяют расчет. Если и на этот раз получится число больше 9, то в 20-м разряде там, где должен быть контрольный ключ, ставят 0.

Идентификатор плательщика — что это такое?

Различают ИП для юридических, физических лиц и иностранных организаций (ИО). При этом индивидуальные предприниматели считаются физическими лицами.

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

Для ИО — это КИО, то есть код иностранной организации, плюс КПП.

Идентификатор плательщика физического лица

Для физических лиц в качестве идентификаторов могут быть использованы:

• страховой номер лица, застрахованного в Пенсионном фонде РФ (СНИЛС);
• серия и номер паспорта или водительского удостоверения;
• серия и номер техпаспорта на транспортное ср-во, полученного при его регистрации;
• иные сведения, разрешенные для применения в кач-ве идентификаторов личности, согласно законодательству (например, военный билет, паспорт моряка и др.).

Код идентификатора физлица — это двузначное число. Разрешенные коды идентификаторов физических лиц:

Присвоение альтернативного идентификатора физическому лицу

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

• Первые два разряда ИП занимает код документа.
• Следующие 20 разрядов (от 3 до 22) — серия и номер док-та в одной строке без промежутка между ними).
• Последние три разряда — код страны, гражданство которой имеется у плательщика.

Правила указания идентификаторов определяются приложением 2 приказа ФС ФБН № 48 (информация мало отличается от представленной в главе Когда необходимо указывать УИН настоящей статьи).

Краткий заключительный обзор

Идентификатор налогоплательщика ИП и уникальный идентификатор начислений УИН — это разные вещи:

• ИП указывается в налоговых документах при уплате стандартных дежурных налогов (на доходы физического лица, имущественные, транспортные и др.).
• В роли ИП для юридического лица может быть идентификатор налогоплательщика и код причины постановки на налоговый учет (ИНН + КПП).
• Для физического лица это могут быть идентификационные сведения, складывающиеся из номера-серии предоставленного документа (любого из перечня разрешенных) и кода страны гражданства.
• В самостоятельно заполняемых налоговых декларациях УИН не указывается.
• При уплате всех имущественных налогов в поле роль идентификатора начислений УИН выполняет индекс документа (самое верхнее поле слева на платежном документе, присланном из налоговой службы.
• УИН в штрафных квитанциях и платежках обычно также указывается в самом платежном документе.
• Самостоятельно созданные пользователями электронного сервиса ФНС платежные документы имеют автоматически присвоенный код.

Если в платежном поручение есть поле с УИН, его нельзя оставлять пустым, так как платеж из-за такой «мелочи» может не пройти. Даже если платежный идентификатор невозможно присвоить, и он не найден в документе, в поле для него необходимо поставить «0».

Нужно четко различать случаи, когда необходимо указывать уникальный идентификатор платежей:

• при наложении штрафных санкций со стороны налоговой службы (за сокрытие, недоимки, несвоевременную налоговую выплату);
• в платежных поручениях, присланных из государственных или местных муниципальных органов;
• в штрафных квитанциях за нарушение ПДД и другие административные проступки;
• в платежных ведомостях коммерческих организаций (при присвоении УИН получателем).

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

Проверка штрафов по УИН

Кстати, УИН, может быть и полезен — по нему, например, можно проверить штрафы ГИБДД. Заходим просто сюда, вводим в поле УИН и нажимаем «Проверить штрафы». Приятный бонус от инспекции — скидка в 50% в течение 20 дней после начисления штрафа.

Как подключиться к системе

Итак, что такое ГИС ГМП, понятно. Теперь разберемся с вопросом о подключении к системе.

Существует несколько способов входа в нее:

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

• Регистрация приобретенной системы.
• Инсталляция полученного файла программного обеспечения.
• Получение электронной подписи, логина и пароля у оператора.
• Корректная установка сертификатов электронной цифровой подписи.
• Загрузка и установка сертификата удостоверяющего центра.
• Проверка шлюзов, осуществляющих связь с региональной организацией, которая обеспечивает безопасность обмена данными в системе.
• Контрольное подключение в ГИС ГМП. Вход в систему.

2. При помощи агрегатора начислений. В случае когда вход такого типа более предпочтителен для плательщика, его осуществляет администратор доходов. Но для этого необходимо:

1. Направить запрос в организацию, которая занимается внедрением системы в конкретном субъекте.
2. Пройти регистрацию.
3. Подготовить рабочее место с соответствующим оснащением.
4. Проверить безопасность доступа.

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

Основные задачи подключения банков

Что такое ГИС ГМП для банков? Это инструмент, посредством которого они взаимодействуют с другими субъектами правоотношений, установленными российским законодательством.

Основными задачами подключения банков к работе в системе считаются:

1. Выстраивания работы в системе межведомственного электронного взаимодействия.
2. Взаимодействие с другими организациями посредством ГИС ГМП.

Первая задача реализуется следующим образом:

• Банк подает заявку в Министерство связи и массовых коммуникаций РФ.
• Организация покупает оборудование для кодировки данных.
• Происходит подключение к системе межведомственного электронного взаимодействия посредством оператора.
• Получение электронной подписи.
• Подача запроса на регистрацию в системе.
• Банк проводит тестовое подключение на взаимодействие с сервисами системы.
• Формирование заявки на активацию доступа.

Вторая задача заключается в непосредственном подключении к ГИС ГМП. Для этого:

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

Оплата

Для того чтобы провести платеж в системе, необходимо придерживаться следующего алгоритма:

Выбрать необходимую категорию и указать реквизиты:

— Для ФССП: дата постановления, категория и номер исполнительного производства, сумма к уплате.

— Для ГИБДД: серия, номер постановления, дата вынесения постановления, сумма к уплате – оплата штрафов; вид пошлины – оплата пошлин, где сумма ставится автоматически системой.

— Для уплаты налогов и задолженностей по налогам: вводится либо номер ИНН, либо номер налогового документа.

— Для Росреестра: указывается код платежа, состоящий из 20 цифр.

Указать назначение платежа:

— Для ФССП: необходимо выбрать отдел приставов и регион, ОКТМО проставляется системой автоматически.

— Для ГИБДД: указываются вид нарушения, регион и подразделение, КБК ставится системой автоматически; для оплаты пошлины выбирается регион и подразделение, ОКТМО проставляется системой автоматически.

Указать сведения о плательщике:

— Для физлица: полные фамилия, имя, отчество, регион и адрес регистрации.

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

Выбрать способ оплаты:

— Счет мобильного телефона.

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

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

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

Также основная база доступна для лиц, обратившихся в финансовые организации с целью информирования о задолженностях и т. п.

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

УИН: что это такое и где его взять?

Что такое УИН? Это уникальный идентификатор начисления (в сокращенной форме «УИН») используется при оплате штрафов, пошлин, взносов, налогов и пр. В этой статье мы расскажем что это за реквизит, где его брать и как правильно применять.

УИН: что это такое

Что такое код УИН?

УИН представляет собой записанную без пробелов комбинацию из двадцати или двадцати пяти цифр. Цель реквизита — обозначить какой это вид платежа и правильно его провести. Идентификатор облегчает учет денежных средств, помогает систематизировать информацию о поступающих платежах. Этот код нужен не для плательщика, а для государственных, муниципальных структур, работников банков и сотрудников казначейства.

На заметку! Не существует списков или таблиц, которые содержат все УИНы той или иной организации. Для каждого платежа разрабатывается своя уникальная комбинация символов, которая никогда больше не повторяется.

Для каждого платежа формируется свой уникальный идентификатор

В каких случаях УИН не нужно указывать в реквизитах?

УИН нужен при перечислении средств в фискальную службу: сборы, налоги и пр. Также его используют при проведении платежей в федеральные и городские органы.

Бывают ситуации, когда двадцатизначный код указывать не нужно:

1. ИП и организации сами рассчитывают налог, основываясь на собственноручно заполненных фискальных деклараций. В этом случае используется другой идентификатор платежа. Он стоит в графе 104. Если говорить простыми словами, если вы не получали никаких уведомлений с требованием перечислить деньги, идентификатор проставлять не следует.
2. Физлица погашают имущественные налоги. Но перед этим из фискальной службы приходит специальное уведомление. Здесь также используется свой идентификатор платежа.

На заметку! Даже если по правилам номер записывать не требуется, это поле не должно пустовать. Вместо двадцатизначного кода проставляют цифру ноль («О»).

Строка «Код» не должна оставаться незаполненной

Как формируется номер платежа

Уникальный идентификатор — это не набор случайных цифр. Все двадцать знаков имеют значение. Код делится на четыре части:

Таблица 1. Правила формирования идентификатора

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

В интернете есть специальные сервисы, с помощью которых возможно проверить правильность идентификатора.

УИН в платёжном поручении

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

Сначала организация или предприниматель получают уведомление из Пенсионного Фонда, Налоговой службы или Фонда Социального страхования РФ. В официальном уведомлении от государственного органа будет вписан код УИН. Именно его записывают в графу 22 при заполнении платежного поручения. Это поле находится в нижней части документа.

Если в официальном уведомлении кода УИН нет, в поле 22 нужно проставить ноль «0». Пустым его оставлять нельзя.

С помощью УИН происходит автоматическое зачисление средств на счет получателя. Поэтому невнимательность при заполнении номера идентификатора приведет к следующим последствиям:

1. Образуется задолженность перед государственным или муниципальным органом, так как деньги «зависнут» неизвестно где.
2. Начисляется пеня.
3. Потребуется искать, где потерялись деньги и перенаправлять их получателю.
4. Отправленные средства поступят на счет фонда или налоговой службы с опозданием.

На заметку! Никогда не используйте для оплаты УИН, предназначенный для другого платежа. Для каждого платежа этот код должен быть уникальным.

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

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

На заметку! Если ИИН плательщика указан, работники банка обязаны принимать текущие платежные поручения с цифрой «0» вместо двадцатизначного кода.

Видео — Код УИН при перечислении налогов (сборов) указывается в платежном поручении

Штраф ГИБДД по УИН

С помощью УИН можно проверить или оплатить штрафы ГИБДД. Это делают либо на официальном сайте gibdd.ru, либо на одном из предназначенных для этих целей интернет-сервисов.

Чтобы воспользоваться онлайн-сервисом по поиску штрафов, в нужное поле необходимо вписать уникальный код. Комбинацию из двадцати цифр (или двадцати пяти) можно найти в постановлении, которую выписал инспектор ГИБДД. Постановление оформляется в двух случаях:

1. Инспектор обнаружил нарушение, вынес предупреждение и применил меру наказания в виде штрафа.
2. Если административный штраф, выписанный на месте, не был погашен, возбуждается дело об административном правонарушении.

На вышеупомянутых ресурсах можно оплатить штраф онлайн, что довольно рискованно. На просторах интернета функционирует несколько мошеннических сервисов, цель которых — «выкачать» как можно больше денег за услуги. Если же вы все-таки предпочли воспользоваться одним из специализированных сайтов, обратите внимание на размер комиссии. В большинстве случаев она не превышает двух процентов.

Заплатить денежное взыскание онлайн можно не только с помощью сервисов в интернете, но и другими способами:

1. С помощью интернет-банкинга (комиссия при этом составит около 50 рублей).
2. На официальном сайте gibdd.ru.
3. Через портал gosuslugi.ru.
4. С помощью одной из электронных платежных систем («Вебмани», «Яндекс Деньги»).

На заметку! При уплате штрафа от автоинспекции УИН указывается в подкладном документе ПД4, квитанции и чеке.

Несколько важных моментов по оплате штрафов:

1. Если вы не проживаете по месту регистрации, проверяйте периодически наличие штрафов. Не допускайте, чтобы сумма денежных взысканий достигла десяти тысяч рублей. В противном случае вам могут запретить пересекать границу или на некоторое время лишат права управлять автомобилем.
2. Если оплатить штраф в течение двадцати дней после его наложения, можно снизить сумму взыскания в два раза.
3. Если вы считаете, что штраф был выписан незаслуженно, можно обратиться с апелляцией в суд района или в ГИБДД.
4. Обжаловать денежное взыскание разрешено в течение семидесяти дней со дня оформления постановления.
5. Если вы точно знаете что штраф был выписан, но при проверке в системе его не обнаружила, подождите некоторое время. Возможно, сотрудники Госавтоинспекции еще не успели внести информацию. Если прошло достаточно времени, а сумма административного взыскания не выходит, вероятно при внесении данных была допущена ошибка. В этом случае позвоните в ГИБДД и выясните этот вопрос.

Периодически проверяйте наличие штрафов от ГИБДД

УИН при оплате госпошлины

При оплате государственной пошлины мало кто из плательщиков знает какой код нужно проставить. Но платеж все равно можно провести. Для этого в графу «Код» внесите цифру ноль («0»).

На заметку! Если оставить поле «Код» незаполненным, в оплате пошлины будет отказано. Поэтому обязательно нужно проставить либо 0, либо двадцатизначный код. Но, некоторые терминалы не принимают платеж, когда в поле «Код» стоит ноль. Если код из двадцати знаков вы не знаете, можно попробовать оставить эту строку незаполненной и сразу нажать кнопку «Ввод».

Где взять УИН

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

На заметку! Если вы получили письмо с требованием оплатить налог, штраф или госпошлину, идентификатор указывать нужно. Если письма не было и платеж вы осуществляете по своей инициативе, УИН не нужен.

Первым делом нужно выяснить есть ли в уведомлении из государственного или муниципального органа номер УИН. И, если он есть, указать его в квитанции на уплату госпошлины, налога и др. Если УИН не указано, проверьте присутствует ли в верхней части уведомления реквизит «Индекс документа». Если есть, именно его следует указать в платежном документе в качестве кода. Номер индекса формируется по таким же принципам, что и УИН.

Если номер УИН указать все же нужно, но у вас его нет, лучше всего узнать нужный код у администратора, которому предназначается платеж. Это можно сделать несколькими способами:

1. Посетить организацию (лично или сайт), которая руководит поступлениями денежных взносов либо получателю платежа.
2. Воспользоваться сайтом Федеральной налоговой службы.
3. В банке, который проводит платежи в бюджетные организации.

На заметку! В кредитной организации могут сказать ваш номер УИН, только если у банка заключен соответствующий договор с администратором поступающих платежей.

Как оплатить налог по УИН из квитанции

В «Сбербанке» можно оплатить налог через всемирную паутину, зная только УИН документа или его индекс:

1. Зайдите в интернет банкинг на официальном сайте российского банка.
2. Найдите в меню кнопку, позволяющую оплатить или перевести средства.
3. Нажмите на «ГИБДД, налоги…»
4. Выберите строку «ФНС».
5. Теперь нажмите кнопку «Найти и оплатить».
6. В разделе, где перечислены все услуги, установите галочку напротив строки «Оплата налогов по индексу документа».
7. Выберите способ оплаты.
8. Введите индекс документа.
9. Внимательно проверьте всю введённые данные.
10. Подтвердите платеж.
11. Нажмите кнопку «Оплатить».

На заметку! Через онлайн-сервис Сбербанка можно оплатить только налоги владельца. Если вы оплатите со своего кабинета счета другого человека, платеж не дойдет до налоговой службы, деньги «зависнут», а долг будет считаться непогашенным.

Зная УИН, можно оплатить налог или пошлину через «Сбербанк Онлайн»

Если вы, как физическое лицо, — оплачиваете в отделении банка наличными, заполняете форму ПД-4сб, код указывать не нужно. При этом обязательно должны быть присутствовать сведения о плательщике: его ФИО, ИНН, данные о регистрации (постоянной, временной).

Оплатить налог можно и через другие финансовые учреждения, которые могут сформировать платежный документ. Если УИН или индекс документа известен, впишите его в квитанцию. Если такой информации у вас нет, просто поставьте в графу 22 цифру ноль («0»).

Как оплатить через «Киви»

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

Если налог еще не начислили, сервис покажет соответствующее уведомление.

Полезные советы

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

Еще одна распространённая проблема, с которой сталкиваются многие граждане. Человек получает квитанцию из бюджетной организации. Потом он решает еще раз проверить долг с помощью интернета. И видит, что УИН из квитанции не совпадает с кодом из системы. Здесь нет никакой ошибки. Дело в том, что УИН — всегда уникален. Поэтому при формировании квитанции был присвоен один код, а при повторном формировании в интернете система выдает уже другой код. В этой ситуации правильным решением будет указать при оплате УИН из квитанции, полученной из государственного или муниципального органа.

В счетах, которые выдают медицинские учреждения, тоже есть графа «Индекс документа» или «УИН». В большинстве случаев при оплате таких счетов не требуется указывать код, так как идентификатор не используется. При оплате в квитанции достаточно проставить цифру ноль («0»). Если указать код все же требуют, можно узнать номер в самом медицинском учреждении.

Что такое УИН?

В настоящее время отдельные банки хотят видеть в платежных поручениях УИН. Что это такое и зачем это нужно? Изменились ли требования к заполнению платежного поручения? Читайте об этом в предложенном материале.

Сегодня бухгалтеры начали сталкиваться с ситуацией, когда банковские работники просят их отражать в платежном поручении в поле «Назначение платежа» дополнительную информацию, а именно УИН и 20-значный код. Естественно, возникает вопрос, что это такое и зачем это надо указывать.

Сразу скажем, что в настоящее время по-прежнему действует Приказ Минфина РФ от 24.11.2004 № 106н «Об утверждении Правил указания информации в полях расчетных документов на перечисление налогов, сборов и иных платежей в бюджетную систему Российской Федерации» (далее – Приказ Минфина РФ № 106н).

Реквизиты, форма (для платежного поручения на бумажном носителе), номера реквизитов платежного поручения установлены в приложениях 1 – 3 к Положению о правилах осуществления перевода денежных средств, утвержденному ЦБ РФ 19.06.2012 № 383-П (далее – Положение № 383-П).

При этом на едином портале раскрытия информации о подготовке федеральными органами исполнительной власти проектов нормативных правовых актов и результатах их общественного обсуждения (regulation.gov.ru) представлен проект приказа Минфина «Об утверждении Правил указания информации в реквизитах распоряжений о переводе денежных средств в уплату налогов, сборов и иных платежей в бюджетную систему Российской Федерации» (далее – проект приказа Минфина). На момент подготовки данного материала документ находится в стадии «Завершение подготовки», следующая стадия – «Принятие акта».

Соответственно, одновременно планируется признать утратившим силу Приказ Минфина РФ № 106н.

Предполагается, что данный приказ начнет действовать с 1 января 2014 года, за исключением положений об указании в распоряжении о переводе денежных средств реквизита «Код», вступающих в силу с 31 марта 2014 года. Предусмотрены переходные положения, которые будут действовать до 31 марта 2014 года. О них мы расскажем дальше.

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

Исторический экскурс, или Что такое ГИС ГМП?

Распоряжением Правительства РФ от 25.10.2005 № 1789-р были одобрены Концепция административной реформы в Российской Федерации в 2006 – 2010 годах и План мероприятий по проведению административной реформы в Российской Федерации в 2006 – 2010 годах.

В соответствии с п. 2.2.2 Плана мероприятий по проведению административной реформы в Российской Федерации в 2006 – 2010 годах был разработан и принят Федеральный закон от 27.07.2010 № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг» (далее – Федеральный закон № 210-ФЗ) (п. 1 Перечня нормативных правовых актов, направленных на регулирование вопросов предоставления государственных и муниципальных услуг, в том числе вопросов предоставления таких услуг в электронном виде, одобренного Протоколом заседания Правительственной комиссии по проведению административной реформы от 08.04.2009 № 88 (разд. VIII)).

Федеральный закон № 210-ФЗ вступил в силу с 30.07.2010, за исключением отдельных положений. Настоящий закон регулирует отношения, возникающие в связи с предоставлением государственных и муниципальных услуг федеральными органами исполнительной власти, органами государственных внебюджетных фондов, исполнительными органами государственной власти субъектов РФ, а также местными администрациями и иными органами местного самоуправления, осуществляющими исполнительно-распорядительные полномочия.

Федеральным законом от 27.06.2011 № 162-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в связи с принятием Федерального закона «О национальной платежной системе» были внесены поправки в Федеральный закон № 210-ФЗ, которые вступили в силу с 1 января 2013 года. Таким образом, уже почти год действует ст. 21.3 «Государственная информационная система о государственных и муниципальных платежах» Федерального закона № 210-ФЗ.

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

• платежей за оказание государственных и муниципальных услуг, услуг, обозначенных в п. 3 ст. 1 и п. 1 ст. 9 Федерального закона № 210-ФЗ;
• платежей, являющихся источниками формирования доходов бюджетов бюджетной системы РФ;
• иных платежей в случаях, предусмотренных федеральными законами.

В данной ситуации речь идет в том числе о следующих государственных и муниципальных услугах:

об услугах, предоставляемых государственными и муниципальными учреждениями и другими организациями, в которых размещается государственное задание (заказ) или муниципальное задание (заказ), подлежащих включению в реестр государственных или муниципальных услуг и оказываемых в электронной форме в соответствии с Федеральным законом № 210-ФЗ, если указанные услуги включены в перечень, установленный Правительством РФ (п. 3 ст. 1 Федерального закона № 210-ФЗ);

об услугах, которые являются необходимыми и обязательными для предоставления государственных и муниципальных услуг и оказываются организациями, участвующими в предоставлении предусмотренных Федеральным законом № 210-ФЗ государственных и муниципальных услуг, перечень которых утвержда­ется:

1) постановлением Правительства РФ – в отношении услуг, оказываемых в целях предоставления федеральными органами исполнительной власти государственных услуг;

2) нормативным правовым актом субъекта РФ – в отношении услуг, оказываемых в целях предоставления исполнительными органами государственной власти субъекта РФ государственных услуг;

3) нормативным правовым актом представительного органа местного самоуправления – в отношении услуг, оказываемых в целях предоставления органами местного самоуправления муниципальных услуг (п. 1 ст. 9 Федерального закона № 210-ФЗ).

Ответственным за создание, ведение, развитие и обслуживание ГИС ГМП является Казначейство РФ. Оно устанавливает и порядок ведения данной системы по согласованию с ЦБ РФ.

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

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

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

Одновременно с 1 января 2013 года вступил в силу пп. 2 п. 1 ст. 7 Федерального закона № 210-ФЗ, в соответствии с которым органы, предоставляющие государственные услуги, и органы, оказывающие муниципальные услуги, не вправе требовать от заявителя представления документов и информации, включая подтверждающие внесение заявителем платы за предоставление государственных и муниципальных услуг, в том числе об уплате государственной пошлины за их предоставление. Соответствующие данные они должны брать из ГИС ГМП. При этом заявитель вправе представить указанные документы и информацию в органы, оказывающие государственные услуги, и органы, предоставляющие муниципальные услуги, по собственной инициативе.

Зачем нужен УИН?

Для реализации поставленных Федеральным законом № 210-ФЗ задач с 1 января 2013 года вступил в силу Порядок ведения Государственной информационной системы о государственных и муниципальных платежах, утвержденный Приказом Казначейства РФ от 30.11.2012 № 19н (далее – Порядок).

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

Участниками ГИС ГМП могут быть:

• оператор по переводу денежных средств;
• организация федеральной почтовой связи;
• территориальный орган Казначейства РФ, иной орган, осуществляющий открытие и ведение лицевых счетов в соответствии с бюджетным законодательством РФ;
• местная администрация;
• банковский платежный агент;
• банковский платежный субагент;
• платежный агент;
• платежный субагент;
• оператор Единого портала государственных и муниципальных услуг (функций);
• оператор регионального портала государственных и муниципальных услуг (функций);
• многофункциональный центр предоставления государственных и муниципальных услуг;
• администратор доходов бюджета, государственное (муниципальное) бюджетное или автономное учреждение (администратор начислений);
• главный администратор доходов бюджета, в том числе являющийся администратором доходов бюджета, имеющий в своем ведении администраторов доходов бюджета и (или) осуществляющий полномочия учредителя в отношении администраторов начислений – государственных (муниципальных) бюджетных и автономных учреждений, а также определенный субъектом РФ орган государственной власти субъекта РФ (орган местного самоуправления), обеспечивающий информационное взаимодействие между оператором ГИС ГМП и администраторами начислений.

Информационное взаимодействие участников (за исключением органов Казначейства РФ) с оператором ГИС ГМП осуществляется после прохождения процедуры регистрации только в электронном виде посредством единой системы межведомственного электронного взаимодействия (СМЭВ), предусмотренной Постановлением Правительства РФ от 08.09.2010 № 697, с применением усиленной квалифицированной электронной подписи участника в соответствии с форматами взаимодействия ГИС ГМП с информационными системами участников, установленными Казначейством РФ и размещенными на сайте этого ведомства в Интернете. Доступ участников к ГИС ГМП обеспечивается в круглосуточном режиме.

В ГИС ГМП используются два вида идентификаторов:

• идентификатор плательщика (ИП);
• уникальный идентификатор начисления (УИН).

Порядок формирования идентификаторов и допустимые ИП определены форматами взаимодействия.

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

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

ИП включает в себя идентификатор сведений о физическом лице или идентификатор сведений о юридическом лице.

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

• страховой номер индивидуального лицевого счета застрахованного лица в системе персонифицированного учета ПФР (СНИЛС);
• идентификационный номер налогоплательщика (ИНН);
• серия и номер документа, удостоверяющего личность;
• серия и номер водительского удостоверения;
• серия и номер свидетельства о регистрации транспортного средства в органах МВД;
• учетный код Федеральной миграционной службы;
• иные идентификаторы сведений о физическом лице, применяемые в соответствии с законодательством РФ.

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

• идентификационный номер налогоплательщика (ИНН) совместно с кодом причины постановки на учет в налоговом органе (КПП) юридического лица;
• код иностранной организации (КИО) совместно с кодом причины постановки на учет в налоговом органе (КПП) юридического лица.

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

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

Применение идентификаторов. Соответствующие разъяснения даны в Письме Минфина РФ № 02-04-05/7491, Казначейства РФ № 42-7.4-05/5.4-147 от 12.03.2013 «О Государственной информационной системе о государственных и муниципальных платежах».

Для плательщиков – юридических лиц идентификаторы рекомендуется указывать с учетом следующего.

Что касается ИП, идентификационный номер налогоплательщика (ИНН) совместно с кодом причины постановки на учет в налоговом органе (КПП) или код иностранной организации (КИО) совместно с кодом причины постановки на учет в налоговом органе (КПП) указывается в реквизитах распоряжения «ИНН» и «КПП» плательщика.

УИН (в случае его наличия у плательщика) обозначается в реквизите распоряжения «Назначение платежа» после указания текстовой информации, предусмотренной Положением № 383-П.

УИН в реквизите «Назначение платежа» распоряжения рекомендуется отражать с учетом следующих особенностей:

• для выделения информации об УИН после указания текстовой информации, предусмотренной Положением № 383-П, используется символ «///»;
• УИН указывается без пробелов в следующем порядке: «УИНX…X», где X…X – значение УИН (20 символов);
• при отсутствии у составителя распоряжения информации об УИН проставляется значение «0», например: «///УИН0».

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

ИП применяется следующим образом:

• в случае указания плательщиком идентификационного номера налогоплательщика (ИНН) ИП указывается в реквизите «ИНН» плательщика распоряжения;
• если в распоряжении не заполнено значение реквизита «ИНН» плательщика, иной ИП, предусмотренный Порядком, рекомендуется отражать в реквизите «Назначение платежа» распоряжения после указания текстовой информации, установленной Положением № 383-П.
• УИН (при его наличии у плательщика) обозначается в реквизите «Назначение платежа» распоряжения после указания текстовой информации, определенной Положением № 383-П.

Идентификаторы в реквизите «Назначение платежа» распоряжения рекомендуется указывать с учетом следующих особенностей:

• для выделения информации об идентификаторах после отражения текстовой информации, предусмотренной Положением № 383-П, используется символ «///»;
• в качестве разделительного знака между УИН и ИП используется точка с запятой («;»), например: «УИН…;ИП…»;
• идентификаторы указываются без пробелов в следующей последовательности: «УИНX…X;ИПZZ;Y…Y», где X…X – значение УИН (20 символов), ZZ может принимать одно из значений, приведенных ниже в таблице (представлена в сокращенном виде), а Y…Y – значение ИП (количество символов в соответствующем документе, но не более 20 символов).

Паспорт гражданина Российской Федерации

Военный билет военнослужащего

Паспорт гражданина СССР

Страховой номер индивидуального лицевого счета застрахованного лица в системе персонифицированного учета ПФР (СНИЛС)

Учетный код Федеральной миграционной службы

Свидетельство о регистрации транспортного средства в органах МВД

• в качестве разделительного знака между значением типа документа (в соответствии с вышеприведенной таблицей) и серией и номером документа используется точка с запятой («;»), например: «ИПZZ;Y…Y»;
• в ИП серия и номер документа (например, 01 – паспорт гражданина РФ) указываются без пробела, например: «///УИН0; ИП01;0201251245»;
• при отсутствии у составителя распоряжения информации о любом из идентификаторов вместо отсутствующего идентификатора указывается значение «0», например: «///УИН0;ИПZZ;Y…Y», «УИНX…X;ИП0»;
• если в распоряжении заполнено значение реквизита «ИНН» плательщика, ИП не указывается, например: «УИНX…X» либо
• «///УИН0»;
• если в распоряжении не заполнено значение реквизита «ИНН» плательщика и при этом составитель распоряжения не указывает информацию о любом из идентификаторов, проставляется значение «0», например: «///УИН0;ИП0».

Новые правила заполнения платежного поручения

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

С 31 марта 2014 года начнут действовать изменения, внесенные в Положение № 383-П Указанием ЦБ РФ от 15.07.2013 № 3025-У (далее – Указание № 3025-У).

Положение № 383-П будет дополнено новой нормой (п. 1.21.1), в соответствии с которой в распоряжениях будет указываться уникальный идентификатор платежа в случае его присвоения получателем средств. Уникальный идентификатор платежа должен будет доводиться получателем средств до плательщика в соответствии с договором. Банк получателя средств будет осуществлять контроль уникального идентификатора платежа в случаях и порядке, которые установлены договором, заключенным с получателем средств.

В распоряжениях о переводе денежных средств в бюджетную систему РФ будет указываться уникальный идентификатор платежа в соответствии с требованиями нормативных правовых актов, принятых федеральными органами исполнительной власти совместно или по согласованию с ЦБ РФ.

Кроме того, поле 22 «Код» сегодня, как правило, не заполняется. В Положении № 383-П сказано, что значение реквизита не указывается, если иное не установлено ЦБ РФ. С 31 марта 2014 года в данном поле будет отражаться уникальный идентификатор платежа в случаях, предусмотренных п. 1.21.1 Положения № 383-П. При составлении, воспроизведении распоряжения на бумажном носителе допускается указание уникального идентификатора платежа в реквизите «Код» двумя и более строками. Максимальное количество символов – 25.

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

Проектом приказа Минфина в соответствии с п. 7 ст. 45 НК РФ и в целях совершенствования органами Казначейства РФ, налоговыми органами, таможенными органами и иными администраторами доходов бюджетов, государственными (муниципальными) учреждениями автоматизированных процедур обработки информации, содержащейся в распоряжениях плательщиков налогов, сборов и иных платежей в бюджетную систему РФ, а также платежей за государственные и муниципальные услуги и услуги, являющиеся необходимыми и обязательными для оказания государственных и муниципальных услуг, предполагается утвердить правила указания информации:

• идентифицирующей плательщика, получателя средств, в распоряжениях о переводе денежных средств в уплату налогов, сборов и иных платежей в бюджетную систему РФ (приложение 1);
• идентифицирующей платеж, в распоряжениях о переводе денежных средств в уплату налогов, сборов и иных платежей в бюджетную систему РФ, администрируемых налоговыми органами (приложение 2);
• идентифицирующей платеж, в распоряжениях о переводе денежных средств в уплату таможенных и иных платежей от внешнеэкономической деятельности (приложение 3);
• идентифицирующей платеж, в распоряжениях о переводе денежных средств в уплату страховых взносов и иных платежей в бюджетную систему РФ (приложение 4);
• идентифицирующей лицо или орган, составивший распоряжение о переводе денежных средств в уплату налогов, сборов и иных платежей в бюджетную систему РФ (приложение 5).

Сравним новые правила заполнения платежного поручения с действующими в настоящее время правилами, утвержденными Приказом Минфина РФ № 106н, и выявим основные новшества.

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

В приложении 2 в поле 105 распоряжения будет указываться значение кода, присвоенного территории муниципального образования или населенного пункта, входящего в состав муниципального образования, в соответствии с Общероссийским классификатором территорий муниципальных образований (далее – ОКТМО). При этом указывается код ОКТМО территории, на которой мобилизуются денежные средства от уплаты налогов, сборов и иных платежей. При уплате налогового платежа на основании налоговой декларации (расчета) в поле 105 указывается код ОКТМО в соответствии с данной декларацией (расчетом). Напомним, что сегодня в этом поле отражается значение кода ОКАТО.

В поле 106 распоряжения указывается значение основания платежа. Как и сейчас, данный показатель будет иметь два знака, но сможет принимать кроме привычных значений (например, «ТП» – платежи текущего года и др.) еще и следующие:

• «ИН» – погашение инвестиционного налогового кредита;
• «ТЛ» – погашение учредителем (участником) должника, собственником имущества должника – унитарного предприятия или третьим лицом задолженности в ходе процедур, применяемых в деле о банкротстве;
• «РК» – погашение должником задолженности, включенной в реестр требований кредиторов в ходе процедур, применяемых в деле о банкротстве;
• «ЗТ» – погашение текущей задолженности в ходе процедур, применяемых в деле о банкротстве.
• Появилось новое значение, которое указывается в поле 107, – значение показателя налогового периода («ИН» – дата уплаты части инвестиционного налогового кредита).
• Также новые значения добавлены и для поля 108, в котором отражается номер документа:
• «ИН» – номер решения о предоставлении инвестиционного налогового кредита;
• «ТЛ» – номер определения арбитражного суда об удовлетворении заявления о намерении погасить требования к должнику;
• «РК» – номер реестра дела о банкротстве.
• Дополнены варианты заполнения поля 109 распоряжения:
• «ИН» – дата решения о предоставлении инвестиционного налогового кредита;
• «ТЛ» – дата определения арбитражного суда об удовлетворении заявления о намерении погасить требования к должнику;
• «РК» – дата реестра требований кредиторов.

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

• «НС» – уплата налога или сбора;
• «ПЛ» – уплата платежа;
• «ГП» – уплата пошлины;
• «ВЗ» – уплата взноса;
• «АВ» – уплата аванса или внесение предоплаты;
• «ПЕ» – уплата пени;
• «ПЦ» – уплата процентов;
• «СА» – налоговые санкции, установленные НК РФ;
• «АШ» – уплата административного штрафа;
• «ИШ» – уплата иного штрафа, предусмотренного соответствующими законодательными или другими нормативными актами.

Планируется, что в поле 110 распоряжения будет указываться показатель типа платежа, который будет иметь два знака и может принимать следующие значения:

• «ПЕ» – уплата пени;
• «ПЦ» – уплата процентов.

При уплате налога (сбора), в том числе авансового платежа, взноса, применении налоговых санкций, установленных НК РФ, уплате административных и иных штрафов, а также других платежей, администрируемых налоговыми органами, в поле 110 будет указываться значение «0».

Как мы сказали выше, согласно Указанию № 3025-У в реквизите «Код» распоряжения отражается УИН.

В реквизите «Назначение платежа» распоряжения после информации, установленной Положением № 383-П, будет указываться дополнительная информация, необходимая для идентификации назначения платежа.

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

Планируется, что новый порядок оформления платежных поручений вступит в силу с 1 января 2014 года. При этом Указание № 3025-У, которое вносит изменения в Положение № 383-П, начнет действовать с 31 марта 2014 года. В проекте приказа Минфина предусмотрены следующие переходные положения.

До 31 марта 2014 года в распоряжениях о переводе денежных средств, форма которых установлена Положением № 383-П, в реквизите «Назначение платежа» указываются УИН или индекс документа из извещения физического лица, заполненного за плательщика налоговых платежей налоговым органом и состоящего

из 20 символов, текстовая информация, предусмотренная Положением № 383-П, а также иные сведения, необходимые для идентификации платежа.

УИН указывается первым в реквизите «Назначение платежа». Он состоит из 23 знаков: первые три знака принимают значение «УИН», знаки с 4-го по 23-й соответствуют значению УИН.

Для выделения информации об УИН после уникального идентификатора начислений используется символ «///», например: «УИН12345678901234567890///».

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

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