Требования к форматам (стр. 1 )

Содержание

1 Введение.. 4

1.1 Назначение документа.. 4

1.2 Условные обозначения и сокращения.. 4

2 Процедуры приема и передачи информации.. 6

2.1 Маршруты приема и передачи информации.. 6

2.2 Порядок формирование и обработки информации.. 6

3 Описание формата обмена.. 7

4 Именование файлов.. 9

5 Описание структуры XML.. 10

5.1 Правила формирования корневого тега сообщения (RootTag) 11

6 Общие атрибуты структуры «Бизнес Данные» (Data Area) 14

6.1 Атрибуты структуры «Бизнес Данные» документа «Платежное поручение на общую сумму с реестром». 16

6.2 Пример схемы документа «Платежное поручение на общую сумму с реестром» 20

1  Введение

1.1  Назначение документа

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

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

1.2  Условные обозначения и сокращения

№	Термин	Содержание
1.	GUID	GloballyUniqueIdentifier – уникальный 128-битный идентификатор, представляется в виде строки из шестнадцатеричных цифр, разбитых на пять групп по 8, 4, 4, 4 и 12 символов соответственно, разделенных дефисами: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.
2.	XML	Расширяемый язык разметки, предназначенный для хранения и обмена информацией в структурированном виде.
3.	БИК	Банковский идентификационный код.
4.	КО	Кредитная организация.
5.	ОрФК	Органы Федерального казначейства – Федеральное казначейство и территориальные органы Федерального казначейства.
6.	ППО	Прикладное программное обеспечение.
7.	ТОФК	Территориальный орган Федерального казначейства. К территориальным органам Федерального казначейства относятся управления Федерального казначейства по субъектам Российской Федерации и подведомственные им – отделения управлений Федерального казначейства по субъектам Российской Федерации.
8.	УБП	Участник бюджетного процесса
9.	ФК	Федеральное казначейство.
10.	ЦАФК	Центральный аппарат Федерального казначейства.
11.	ЭП	Электронная подпись – реквизит электронного документа, предназначенный для защиты данного электронного документа от подделки, полученный в результате криптографического преобразования информации с использованием закрытого ключа электронной цифровой подписи и позволяющий идентифицировать владельца сертификата ключа подписи, а также установить отсутствие искажения информации в электронном документе. В электронном документе признается равнозначной собственноручной подписи в документе на бумажном носителе.

2  Процедуры приема и передачи информации

2.1  Маршруты приема и передачи информации

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

-  ОрФК – Клиент:

o  Информация из документа «Платежное поручение на общую сумму с реестром».

2.2  Порядок формирование и обработки информации

Информация, передаваемая и получаемая в рамках настоящих Требований, используя язык разметки XML, преобразуется в электронный документ (далее XML-документ).

Каждый электронный XML-документ содержит информацию из документа «Платежное поручение на общую сумму с реестром». Каждый такой пересылаемый документ передается с сопровождающей его служебной информацией. Такая служебная информация должна соответствовать стандарту Open Applications Group Integration Specification (OAGIS) и описанию, приведенному в пнастоящего документа.

Формирование XML-сообщений производится в формате UTF-8 и каждое сообщение снабжается заголовком:

<?xml version="1.0" encoding="UTF-8"?>

3  Описание формата обмена

В соответствии с настоящими требованиями информационное взаимодействие между органами Федерального казначейства и участниками бюджетного процесса, неучастниками бюджетного процесса, бюджетными учреждениями, автономными учреждениями осуществляется посредством обмена XML сообщениями. Формат входящих и исходящих сообщений соответствует стандарту Open Applications Group Integration Specification (OAGIS).

Каждое сообщение содержит один документ.

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

Конверт представляет собой XML сообщение и дополнительные служебные атрибуты, которые служат для доставки сообщения адресату.

Сообщение формируется на расширенном стандарте OAGIS.

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

–  Business Object Document (BOD) – само XML сообщение

―  Корневой тэг – Идентификатор формата сообщения (композиция);

―  Атрибут корневого тега – Версия формата сообщения;

―  Атрибут корневого тега – Программная среда (ASFK, OOS);

―  Атрибут корневого тега - Версия релиза ППО

–  Отправитель (набор атрибутов);

–  Дата отправления;

–  GUID сообщения (BODId) - (в отличие от GUID документа) логический уровень;

–  UserArea – расширения стандарта:

·  Получатель;

·  ФИО, должность пользователя сформировавшего xml-сообщение Приоритет – (1-100), рекомендательный параметр транспортной системе;

·  Тип сообщения – код типа сообщения;

·  Маркер документа;

·  Дополнительный параметры (не заполняется).

–  DataArea – область описания данных. В зависимости от типа сообщения может быть: документом, запросом, уведомлением, обновлением, отчетом, справочником, файлом и т. д.

·  Действие над объектом – «глагол» – Process, Sync, Load, и т. д. в соответствии с OAGIS.

·  Объект (структура описана в соответствующем подразделе ниже).

Уникальным идентификатором формата сообщения является композиция: Идентификатор формата сообщения + Версия формата сообщения.

4  Именование файлов

Xml-файлы используют единый принцип формирования имени файла: MDTTNNNNYYYYYYYYXXXXXSSSSFFFFFFFFZZZZZPPPP,

где использованы следующие реквизиты:

– 1-й разряд, «M» – месяц формирования файла: 1–9, A–C в 36-ричной системе;

– 2-й разряд, «D» – день месяца формирования файла: 1–9, A–V в 36-ричной системе;

– 3-4-й разряды, «TT» – тип документа (заполняется значением «06»);

– 5-8-й разряды, «NNNN» – порядковый номер файла за дату формирования: 0–9, A–Z в 36-ричной системе;

– 9-16-й разряды, «YYYYYYYY» – код бюджета организации отправителя (заполняется значением «»);

– 17-21-й разряды, «XXXXX» – код организации отправителя РУБП/ПУБП/НУБП (заполняется значением «00000»);

– 22-25-й разряды, «SSSS» – код ТОФК отправителя;

– 26-33-й разряды, «FFFFFFFF» – код бюджета организации получателя;

– 34-38-й разряды, «ZZZZZ» – код организации получателя РУБП/ПУБП/НУБП;

– 39-42-й разряды, «PPPP» – код ТОФК получателя (заполняется значением «0000»).

Расширение файла описывает его внутренний формат и должно состоять из трёх разрядов. Расширение файла должно иметь значение «xml».

Например:

.xml, где

5 – месяц Май;

5 – день 5-ый;

06 – тип документа;

131 - порядковый номер файла в течении 5-го числа;

- код бюджета организации отправителя;

00000 - код организации отправителя;

5100 – УФК по Новосибирской области;

- код бюджета города Новосибирск;

04063 – код УБП Новосибирскстат;

0000 – ТОФК получателя.

5  Описание структуры XML

Ниже представлен пример структуры формата XML сообщений:

<?xml version="1.0" encoding="windows-1251"?>

<ProcessRegPayOrder xsi:noNamespaceSchemaLocation = "ProcessRegPayOrder. xsd" xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance" versionID="1.0" systemEnvironmentCode="ASFK" releaseID="0.0.15">

<ApplicationArea>

<Sender>

<LogicalID>3400</LogicalID>

<Role>ASFK</Role>

</Sender>

<CreationDateTime>T16:39:25+04:00</CreationDateTime>

<BODId>D741E154-BC2D-0090-E043-C0A</BODId>

<UserArea>

<Group ID = "Core">

<Property name = "RecipientLogicalID"value = "9500.6000..1-22222.N. S"></Property>

<Property name = "Priority" value = "255"></Property>

<Property name = "Role" value = ""></Property>

<Property name = "MessageType" value = "Document"></Property>

<Property name = "MessageCode" value = "ИКС"></Property>

<Property name = "UserName" value = "UserName"></Property>

</Group>

</UserArea>

</ApplicationArea>

<DataArea>

…

</DataArea>

</ ProcessRegPayOrder>

Корневой тег ProcessRegPayOrder – идентификатор формата сообщения. Вместе с версией (атрибут «versionID») представляет собой уникальный идентификатор формата области описания данных (DataArea).

–  ApplicationArea – постоянный, неизменный формат (для всех типов сообщений);

–  DataArea – переменный формат; зависит от типа сообщения.

Таблица  1 – Перечень структур данных сообщения

Структура данных	Относительный XPath	Описание	Особенности заполнения
Сообщение	<ProcessRegPayOrder >	Все XML сообщение - Busioness Object Document (BOD)	ProcessRegPayOrder – значение корневого тега для документа «Платежное поручение на общую сумму с реестром»
Служебные поля	<ProcessRegPayOrder> / <ApplicationArea>	Область описания служебных, управляющих полей
Отправитель	<ProcessRegPayOrder> / <ApplicationArea> / <Sender>	Отправительсообщения
Расширения	<ProcessRegPayOrder> / <ApplicationArea> / <UserArea>	Расширения стандарта OAGIS
Дополнительные параметры	<ProcessRegPayOrder> / <ApplicationArea> / <UserArea>/<Group>	Дополнительные параметры
БизнесДанные	<ProcessRegPayOrder>/ <DataArea>	Область описания данных

5.1  Правила формирования корневого тега сообщения (RootTag)

Корневой тег любого сообщения формируется по правилам OAGIS 9.0. Корневой тег состоит из глагола и существительного. Существительное представляет собой бизнес-объект, передающийся в сообщении. Глагол представляет собой действие с данным бизнес-объектом, которое явилось инициатором исходящего сообщения или которое необходимо выполнить по получению данного сообщения.

Таблица  2 – Перечень атрибутов корневого тэга

Атрибут XML-тега	Формат	Обязательность	Описание	Особенности заполнения
versionID	String	Да	Версия формата сообщения.	Должна соответствовать версии данного документа в формате: «\d{3}.\d{2}».
systemEnvironmentCode	String	Да	Программная среда (Допустимы значения «ASFK»).	Заполняется значением ASFK.
releaseID	String	Да	Версия релиза ППО.

Таблица  3 – Перечень элементов структуры «Отправитель» (Sender)

Элемент: имя XML-тега	Формат	Обязательность	Описание	Особенности заполнения
LogicalID	String	Да	Адрес подсистемы отправителя сообщения.	Код ОрФК отправителя.
Role	String	Да	Роль отправителя.	Заполняется значением ASFK.

Таблица  4– Перечень элементов структуры «Служебные Поля»

Элемент: имя XML-тега	Формат	Обязательность	Описание	Особенности заполнения
CreationDateTime	YYYY-MM-DDThh:mm:ss (+|-)hh:mm (xsd:dateTime)	Да	Дата-время формирования в формате xsd:dateTime. Например, T12:40:10+03:00.	Дата и время формирования xml-сообщения.
BODId	String	Да	GUID сообщения.	([A-Z]|[0-9]){8}-([A-Z]|[0-9]){4}-([A-Z]|[0-9]){4}-([A-Z]|[0-9]){4}-([A-Z]|[0-9]){12}

Таблица  5– Перечень элементов структуры «Croup» «Core»

Элемент: имя XML-тега	Формат	Обязательность	Описание	Особенности заполнения
RecipientLogicalID	Xs:String	Да	Транспортная маска получателя	Указывается адрес подсистемы получателя сообщения: код УБП.
Priority	Xs:String	Да		Всегда заполнять значением «255».
Role	Xs:String	Да	Роль получателя.	Заполняется значением номер лицевого счета получателя
MessageType	Xs:String	Да	Тип перевозимой сущности. Report - отчет. Document - документ.
MessageCode	Xs:String	Да	Маркер документа.	Возможные значения: RPP – для «Платежное поручение на общую сумму с реестром».
UserName	xs:String	Да	ФИО, должность ответственного сотрудника сформировавшего xml-сообщение.

6  Общие атрибуты структуры «Бизнес Данные» (Data Area)

Таблица  6 –Атрибуты структуры «Бизнес Данные»