Краткий обзор TUTDF Форматирование файлов TUTDF
В руководстве по использованию Формата передачи данных TransUnion (TUTDF) описывается, как составлять отчёт на основании записей о физических и юридических лицах для предоставления в Национальное Бюро Кредитных Историй (НБКИ). Данная информация предоставляется в виде Формата передачи данных TransUnion (TUTDF). TUTDF состоит из сегментов, каждый из которых содержит информацию определённого типа.
Важно помнить следующее:
В начале каждого набора данных, передаваемых в НБКИ, должен присутствовать только один сегмент заголовка TUTDF.
В конце каждого набора данных должен присутствовать только один сегмент завершения TRLR. Данный сегмент нужен для того, чтобы удостовериться, что все данные были получены. Для подтверждения того, что все данные предоставлены, в данном сегменте может также приводиться контрольное число.
Вслед за заголовком TUTDF должна быть одна или несколько записей, касающихся физических или юридических лиц. Записью называется блок определенных сегментов, представленных в определенной последовательности, отражающих одно информационное сообщение о кредитной истории субъекта. Для каждой записи, касающейся физического лица, требуемые сегменты должны быть отправлены в следующем порядке: ID, NA и AD, затем опционально может быть добавлен сегмент PN, и далее только один из сегментов TR, LE, BK или OF. Для юридического лица данные должны следовать в порядке ID, BU, AD, PN, далее – один из сегментов TR, LE, BK или OF. Требуемые сегменты должны присутствовать в каждой записи независимо от того, содержат ли они модифицируемые данные или нет. Система отклонит любую запись, переданную без обязательного сегмента.
Если субъект имеет более одного кредита (счета) в банке, необходимо всегда повторять блок сегментов (для физического лица это ID, NA, AD и TR, для юридического лица - ID, BU, AD, PN, TR) соответствующее количество раз для каждого кредита (счета).
Длина сегментов может быть различной.
В таблице, приведённой ниже, описываются различные сегменты, из которых состоит TUTDF.
Сегмент
|
Название
|
Обязательность
|
Максимальное число записей
|
TUTDF
|
Заголовок TUTDF
|
Обязательно
|
1 на обновляемый файл – первый сегмент
|
ID
|
Данные, идентифицирующие личность
|
Обязательно
|
1-99 на запись о субъекте кредитной истории
|
NA
|
Имя (название)
|
Обязательно1
|
1 на запись о физическом лице
|
BU
|
Предприятие
|
Обязательно 1
|
1 на запись о юридическом лице
|
AD
|
Адрес
|
Обязательно
|
2 на запись о субъекте кредитной истории
|
PN
|
Номер телефона
|
Условное2
|
5 на запись о субъекте кредитной истории
|
TRLR
|
Трейлер
|
Обязательно
|
1 на обновляемый файл – последний сегмент
|
Только один из ниже приведенных сегментов может быть включен в одну запись о субъекте кредитной истории
Сегмент
|
Наименование
|
Обязательность
|
Максимальное число записей
|
TR
|
Описание кредита
|
C4
|
1 на запись о субъекте кредитной истории
|
LE
|
Юридический статус
|
C
|
1 на запись о субъекте кредитной истории
|
BK
|
Банкротство
|
C
|
1 на запись о субъекте кредитной истории
|
OF
|
Официальная информация
|
C
|
1 на запись о субъекте кредитной истории
|
Примечание:
1. Сегменты NA и BU являются взаимоисключающими.
2. Сегмент PN является обязательным для юридических лиц.
3. Если участник хочет изменить информацию: Фамилия, Номер документа и т.д. до следующего цикла передачи данных, последняя запись о сделке должна быть послана повторно, чтобы гарантировать, что запись TUTDF синтаксически правильна и позволяет системе выполнять эти модификации.
Итак, перечисленные выше правила формирования файла с данными и сегментов (как элементов такого файла) можно свести к следующим таблицам:
Таблица 1.Обязательные сегменты файла.
Сегмент
|
Физлица
|
Юрлица
|
HEADER
|
Обязателен
|
Обязателен
|
TRLR
|
Обязателен
|
Обязателен
|
Таблица 2. Обязательные сегменты каждой записи.
Сегмент
|
Физлица
|
Юрлица
|
ID
|
Обязателен
|
Обязателен
|
NA
|
Обязателен
|
Запрещен
|
BU
|
Запрещен
|
Обязателен
|
AD
|
Обязателен
|
Обязателен
|
PN
|
Допустим
|
Обязателен
|
TR/LE/BK/OF
|
Обязателен
|
Обязателен
|
Следующие синтаксические правила используются для правильного построения данных при работе с TUTDF.
Элементы (поля) данных должны располагаться в последовательности, определённой в настоящем Руководстве по применению TUTDF.
Символ табуляции (Tab) является зарезервированным служебным символом, который разделяет поля в пределах каждого сегмента. Значения полей не могут содержать символ табуляции; при включении символа табуляции в элемент данных он будет интерпретирован как разделитель между двумя полями. [TUTDF не располагает “освобождающим” символом, другими словами, символом который, при использовании его в сочетании с выделенным служебным символом, таким как табуляция, “освободит” служебный символ от сервисной функции и позволит ему быть интерпретированным как обычный элемент данных].
Управляющий символ перевод строки (в десятичной системе = 10, в шестнадцатиричной = 0A)является зарезервированным служебным символом, который разделяет сегменты. По причине, описанной в пункте 2, значения элементов данных не могут содержать символ перевода строки , так как он является зарезервированным символом, разделяющим сегменты. При включении символа перевода строки в элемент данных он будет интерпретирован как разделитель между двумя сегментами.
Символ табуляции должен следовать за каждым полем, кроме последнего, после которого должен присутствовать символ перевода строки. То есть если в сегменте 8 полей, то строка должна содержать 7 табуляций и 1 перевод строки.
Все сегменты должны начинаться с поля «Название сегмента», имеющего соответствующе значение (ID01, ID02 и т.д., кроме TUTDF и TRLR, не имеющих нумерации). Нумерация сегментов (01, 02 и т.д.) должна начинаться с 01 для каждой записи.
Если значения полей содержат один или несколько лидирующих или замыкающих символов пробела, то эти символы будут удалены ещё до разделения данных на типы, предусмотренные определением полей.
Все поля описываются с использованием определённых отличительных признаков, таких как типы данных, минимальная и максимальная дозволенная длина данных, и допустимые значения. Кроме того, спецификацией сообщений определяются такие признаки, как расположение поля, его обязательность и максимальное число применений.
|
