Дебетовые карты в Профайле (как всё устроено и работает)

1.

Дебетовые карты в Профайле
(как всё устроено и работает)
часть 1 – авторизации
часть 2 – клиринг
Справочное пособие для УППО ДБИТ ВТБ24
Автор: Шелков А.А. (УКТ ДБИТ)
Москва 2015г.

2.

Оглавление
коллеги, в режиме просмотра можно кликать по гиперссылкам (они подчёркнуты) для быстрого перехода
Раздел
Вместо эпиграфа……………………………………………………………………………………………………………………..
Вместо вступления…………………………………………………………………………………………………………………..
Что такое «карта» в Профайле ……………………………………………………………………………………………….
Схема взаимодействия Профайла с процессингом ………………………………………………………………
Часть 1 - авторизации …………………………………………………………………………………………… ……………….
Обработка онлайновых запросов от Мультикарты в Профайле ……………………………….
Версии протокола TCI и их изменение ………………………………………………………………………..
Обработка тайм-аутов ………………………………………………………………………………………………….
Поддерживаемые типы транзакций …………………………………………………………………………….
Где и как хранится информация о карточных авторизациях ……………………………………..
Как посмотреть карточные авторизации ……………………………………………………………………..
Углубляемся в детали… channels и payment associations ………………………………………….
Углубляемся в детали… сумма транзакции ………………………………………………………………..
Углубляемся в детали… транзакции по внесению наличных в банкомате ……………….
Углубляемся в детали… транзакции в реальном времени ………………………………………………
Углубляемся в детали… расчёт комиссий за проведение операции …………………………….
Приложение1: количество авторизаций ………………………………………………………………………
Приложение2: тайминги по обработке авторизационных запросов ………………………….
Приложение3: справочно: как Профайл работает в режиме 24х7 (общая схема) …….
Часть 2 - клиринг …………………………………………………………………………………………………………………….
Что такое клиринг …………………………………………………………………………………………………………
Формат файла ………………………………………………………………………………………………………………
Повторная загрузка клиринга ………………………………………………………………………………………
Определение суммы транзакции …………………………………………………………………………………
Технический овердрафт ………………………………………………………………………………………………
Мэтчинг клиринга с авторизацией ………………………………………………………………………………
Клиринг по перевыпущенной карте …………………………………………………………………………….
Где и как хранится информация о карточных транзакциях ……………………………………….
Дополнительно можно посмотреть: история карты ……………………………………………………
Главная книга, Трансформер и Агрегатор (упрощенная схема) ………………………………
Управление выгрузкой событий в Главную книгу ………………………………………………………
Страницы
3
4
5
6
7
8-9
10
11
12
13-15
16
17
19
20-21
22
23-25
26
27
28
29
30
31-33
34
35
36
37
38
39-41
42
43
44-46
2

3.

Вместо эпиграфа
Чтоб мудро жизнь прожить,
знать надобно немало,
Два важных правила
запомни для начала:
Ты лучше FIS спроси,
чем сам update-ом лезь,
И напрочь позабудь
select-ить что попало.
Коллеги, ещё раз напоминаю:
(перефразированные рубаи Омара Хайама)
FIS категорически не рекомендует
вносить какие-либо изменения в данные
на промышленной системе
при помощи SQL-запросов.
Причин, в моём понимании, три:
1) Обработчик SQL-запросов в Профайле это не часть базы данных, это всего лишь прикладной код в Профайле, который
разные люди в разное время меняли (последний раз - осенью 2015 в рамках работ по оптимизации производительности).
То, что в этом прикладном коде возможны ошибки – однозначно. Поэтому вот так просто взять и выполнить SQL UPDATE
на «бою» – большой риск. Хотя бы нужно сначала на тестовом контуре проверить, насколько корректно оно отработает.
Ошибки могут связаны ещё и с тем, что сама по себе база данных GTM ничего не знает о том, какие поля есть в какой
таблице, и даже о таблицах она ничего не знает – на уровне базы данных запрос будет выглядеть, например, так:
«прочитай элемент глобали ACN с индексом 1002305764 и дай 38-й листик на 51-й ветви». Привычными нам названиями
таблиц и полей оперирует вот эта самая программная надстройка над GTM, обработчик SQL-запросов, а она, как любая
программа, может ошибаться. Хотя очевидно, что чем проще запрос, тем меньше вероятность ошибки.
1) Когда сотрудник банка вводит SQL UPDATE руками, всегда есть вероятность ошибиться. А иногда небольшой опечатки
может быть достаточно, чтобы запрос был обработан совершенно иначе.
2) Ну и последнее. Чтобы что-то менять, нужно очень хорошо представлять себе структуру данных и последствия такого
изменения. Без этого поменять можно так, что на «ремонт ремонта» потратим времени и ресурсов вендора намного
больше, чем если бы сразу заказали «ремонт» тому же вендору
Мораль: если есть возможность – закажи Data Fix у вендора.
3

4.

Вместо вступления
• В 2009-2010 годах бизнес поставил задачу: создать бизнес-продукт «мастер-счёт с дебетовой картой».
• В соответствии с бизнес-требованиями карта не существует отдельно (как, например, сейчас в Way4), а
является средством доступа к текущему счёту. То есть, не нужно перекладывать деньги с текущего счёта
на карту, если хочешь расплатиться картой. Все деньги лежат в одном месте (на мастер-счёте), и при
этом можно в любой момент либо выполнить операцию по карте (которая привязана к мастер-счету),
либо выполнить операцию со счёта (например, сделать денежный перевод в другой банк).
• Поскольку счета «живут» в Профайле, то и карты потребовалось «поселить» там же
• Изначально Профайл не был (да и до сих пор не является) полноценной карточной системой и «не
обучен» полностью всем-всем правилам, установленным платёжными системами
• Однако ещё до ВТБ24 его научили работать с картами – в Профайле уже был реализован базовый
функционал работы со switch-ом (так иностранцы называют внешнюю систему, откуда приходят
карточные транзакции). В нашем случае транзакции приходят из системы TWO, установленной в
Мультикарте (разработчик системы – компания Компас Плюс)
• Некоторые возможности Профайла, которые изначально были заложены (например, возможность
привязать карту к нескольким счетам), мы не используем
• В ходе доработок Профайл в 2010 году научили генерировать номера карт (изначально Профайл умел
только получать их извне), научили особенностям работы с TWO (потому что эта система использует
свою собственную версию протокола обмена данными, хотя и основанную на стандарте ISO), научили
обрабатывать нужные банку типы карточных операций, научили выгружать в Главную книгу (т.е. в
Бисквит) финансовые события для построения проводок, научили отслеживать расходные лимиты и
взимать транзакционные (т.е. связанные с выполнением финансовых транзакций) и нетранзакционные
(их ещё иногда называют «мисковыми» или misc-овыми) карточные комиссии.
4

5.

Что такое «карта в Профайле»
• Перед тем, как обсуждать выполнение карточных транзакций, наверно, имеет смысл сказать пару слов
об объекте «карта».
• Карта может быть «основной/main» и «дополнительной/additional» (причём в терминологии Профайла, а
точнее, технологов банка, предложивших вендору такие названия) основная – это карта на имя
владельца счета, а дополнительная – это на третье лицо. Поэтому фраза «клиент выпустил себе
дополнительную карту» некорректна, вместо этого нужно говорить «клиент выпустил себе ещё одну
карту» (это проектная шутка времён 2010 года ).
• Каждая карта описывается строкой в таблице CRD и связанной с ней таблицей ZCRD.
• Каждая карта содержит две ссылки на клиента
• поле CRD.ACN – внутренний ID клиента, которому принадлежит мастер-счет, к которому выпущена карта
• поле ZCRD.ZEXTCIFID – внутренний ID клиента, на чьё имя выпущена карта (т.е. ID клиента-держателя)
• Карта не содержит явной ссылки на мастер-счёт. Узнать его можно либо вызвав ИНТ 104 (по номеру
карты), либо сделав запрос SELECT CID* FROM CRDGRP WHERE CRDNUM = …
• У каждой карты есть тип. От этого типа
• зависит алгоритм генерации номера карты
• не зависит список видов карточных операций, которые по ней можно провести
• зависит размер комиссий и расходных лимитов
• Типы карт описаны в таблице CRDTYP
• У каждой карты есть статус (поле CRD.STAT), это число. Например, «1» означает «Активирована».
Полный список статусов находится в UTBLCRDSTAT. Там же лежат флаги, определяющие возможность
проведения операции по карте, находящейся в каждом из статусов.
• Таблица UTBLCRDSTAT1 содержит схему переходов из статуса в статус; если нет строки,
соответствующей переход из одного статуса в другой с признаком «переход разрешён», то Профайл не
позволит изменить статус таким образом.
* CID – это внутренний (т.е. «родной») ID счета в Профайле. Одним из индексов для таблицы счетов является CID, другим – ZCONTRACT (20-значный номер счета)
Технически каждый индекс (кроме 1-го) это отдельная таблица, по которой значение преобразовывается в значение основного индекса. Например, если вы делаете
запрос «SELECT ACCTNAME FROM DEP WHERE ZCONTRACT=», фактически выполняется 2 запроса – сначала по значению ZCONTRACT находится CID, потом по
значению CID находится нужный счёт и из него извлекается значение ACCTNAME. Однако, обработчик SQL-запросов делает всё это невидимо для вас
5

6.

Схема взаимодействия Профайла с процессингом
• Для получения авторизационных запросов и ответа на них используется INT 5 в Профайле. Он был
реализован в соответствии с протоколом TCI (TranzWare Corebanking Interface) компании Компас Плюс.
INT 5 («пятый интерфейс») – онлайновый, доступность 24х7 (т.е. в т.ч. и во время закрытия дня).
• Для загрузки клиринговых файлов используется INT 6 в Профайле. Он был реализован в соответствии с
протоколом TIP (TranzWare Interchange Protocol) компании Компас Плюс. INT 6 («шестой интерфейс» пакетный, запускается по команде от «техпроцессов», во время закрытия дня не работает*
• У Профайла есть единственный канал получения информации о карточных транзакциях – это
Мультикарта. Все карточные транзакции проходят через TWO вне зависимости от того, на каком
устройстве они выполнены (включая устройства самого ВТБ24).
* - в случае, если INT 6 запущен во время закрытия дня, сработает проверка, и запуск будет блокирован. Если во время работы INT 6 начата процедура закрытия
дня, то часть транзакций не будет обработана (ошибка «Cannot determine teller posting date»). Запрещается начинать закрытие дня, если работает ИНТ 6.
6

7.

ЧАСТЬ 1
Авторизации
7

8.

Обработка онлайновых запросов от Мультикарты в Профайле (1 из 2)
• Формат TCI основан на стандарте ISO-8583 («Процесс передачи и формат финансовых сообщений
систем, обрабатывающих данные банковских платёжных карт»)
• Форматом TCI предусмотрены различные типы запросов, передаваемых из Мультикарты в Профайл, в
т.ч. (не полный список):
–
–
–
0100 – запрос на авторизацию
0220 – уведомление о финансовой операции
0800 – системное сообщение
• Тип запроса указывается в заголовке сообщения. Также в заголовке указывается битовая строка,
определяющая наличие или отсутствие полей в теле сообщения. Тело сообщения (т.е. набор полей,
содержащих бизнес-данные) представляет собой сплошную последовательность данных без
разделителей. Т.к. известна длина каждого поля (она регламентируется документацией по TCI) и
перечень переданных в сообщении полей (указан в заголовке, см выше), Профайл способен разобрать
полученное сообщение по полям, а затем и обработать эти поля в зависимости от типа запроса.
Пример запроса в формате TCI (выделены тип запроса и битовая строка)
A4M080000100F238669128A0800C00000000005000F0164714870022599222110000000000001000010040155072841390000001004
6051643010000082D0000000006888884214714870022599222=17070021321995010899990498ABC SHOP
MOSCOW
000 643 00220151004VISA VISAABBE0510 000000000
• До того, как Профайл сможет обрабатывать запросы от Мультикарты, необходимо выполнить вход в
систему (действие log-in или sign-in, кому как нравится называть). Это действие выполняется внутри INT
5 при получении от Мультикарты «системного» запроса с требованием выполнить log-in. Идентификатор
пользователя, от имени которого INT 5 «входит в систему» хранится в настройках (UTBLEXTINT.UID). В
протоколе TCI таким системным запросом является сообщение типа 0800, содержащее в поле 70
значение 001. Для Мультикарты (точнее, для TWO) этот запрос означает, что TWO переходит в режим,
когда решение об авторизации принимает банковская система (TWO умеет работать в разных режимах).
• Кроме запроса на log-in, системное сообщение 0800 может содержать значение 003 (эхо-тест). Если у
TWO нет реальных запросов для Профайла, TWO каждую минуту направляет запрос на эхо-тест, чтобы
проверить, что система на другой стороне «жива». В связи с тем, что в Мультикарте с Профайлом
работает не один хост (сервер), а много (7 по состоянию на 23/11/15), иногда такие запросы приходят
вперемешку с карточными (ночью и утром); по ночам запросов на эхо-тест много, днём их нет совсем. 8

9.

Обработка онлайновых запросов от Мультикарты в Профайле (2 из 2)
• Тип сообщения состоит из 4х цифр:
0ххх – первая цифра всегда ноль (формально означает, что используется версия ISO-8583 от 1987 года)
х1хх – вторая цифра обозначает класс сообщения
1 – авторизационное сообщение
2 – финансовое сообщение
4 – ревёрсал (т.е. отмена)
8 – системное сообщение
хх2х – третья цифра обозначает функцию сообщения
0 – запрос
1 – ответ
2 – уведомление
3 – ответ на уведомление
ххх0 – четвертая цифра всегда ноль (формально означает, что сообщение инициировано эквайером)
• Таким образом, например, 0100 – это запрос разрешения на выполнение карточной операции
(направляется из Мультикарты в Профайл), а 0110 – ответ на этот запрос (направляется из Профайла в
Мультикарту), при этом ответ может быть положительным (разрешение) или отрицательным (отказ).
• Некоторые поля запросов и ответов приведены ниже*:
P-2 – номер карты, формат N ..19(LLVAR), т.е. сначала 2 цифры длина поля, потом до 19 знаков – номер карты
P-3 – код транзакции (точнее говоря, код транзакции лежит в P-3.1, в первом подполе поля P-3), формат N3
P-4 – сумма транзакции или её эквивалент в валюте BINа (для транзакций из внешних для Мультикарты систем)**
P-39 – код ответа (определяющий разрешение или отказ), формат N5, при этом фактически ответ это последние 2 цифры
P-43 – информация о мёрчанте (торговой точке), состоит из 15 подполей с названием, адресом и т.п.
P-49 – валюта транзакции или валюта BINа (для транзакций из внешних для Мультикарты систем), формат N3
S-108 – внешний RRN (external retrieval reference number) – относительно уникальный ID транзакции, формат сложный
A4M080000100F238669128A0800C00000000005000F0164714870022599222110000000000002115210040155072841390000001004
6051643010000082D0000000006888884214714870022599222=17070021321995010899990498WWW.PAYEER.COM TOLYATTI 000
643 00220151004VISA VISAABBE0510 0000000000000000643VB24MCMS 016 3852770690733730006430000000000000000000211
520000000000000000013527705729391001 443092628D575129CF861056EC4E0B008B04120B26F82810026CR=2ET=5277057293
91TC=1000005MPI=0
* - поля обозначаются буквами P (primary) или S (secondary) и цифрами. Поля с 1 по 64 являются primary, начиная с 65 – secondary. На самом деле имеет значение
номер поля, а не буква перед ним.
** - сумма указывается в дробных единицах валюты (копейках, центах и т.п), без разделителя дробной части
9

10.

Версии протокола TCI и их изменение
Поддержка версий и изменения форматов
• Профайл работает с ограниченным
набором полей из получаемых от
Мультикарты сообщений, некоторую часть
полей он игнорирует. В принципе, эти поля
содержат какие-то данные, но для целей
обработки стандартных карточных
операций было решено обойтись и без них.
• В ходе работ по реализации INT 5 было
принято решение не дорабатывать
Профайл вслед за ежегодно меняющимися
форматами TCI. Вместо этого в INT 5
обеспечен контроль версии. То есть, если
протокол TCI меняется существенным
образом, меняются тип и версия протокола
(текущее значение «A4M08», кстати, в
документации есть описание уже для
«A4M10»), при этом в Профайле сработает проверка, и входящее сообщение «новой версии» не будет
обработано; такой подход предохраняет от ошибочного разбиения сообщения на поля и от
некорректной обработки сообщения с потенциально новой структурой полей.
• При этом «мелкие» изменения производятся ежегодно – добавляются новые варианты значений
подполей, меняется набор подполей (особенно в полях переменной длины).
• Однако, даже эти «мелкие» изменения (внутри одной версии) могут быть причиной проблем, поэтому
при каждом изменении в протоколе (о котором Мультикарта уведомляет банк), необходимо проводить
анализ влияния вносимых в протокол изменений. Описание изменений мы получаем от Компас Плюс.
На картинке приведён формат уведомления, который банк «адресно» получает от компании Компас Плюс (разработчик
программного обеспечения TWO). Уведомления приходят на адрес «обновления протоколов КомпасПлюс» и рассылаются
по сотрудникам банка, включённым в данную группу рассылки. В документе поперёк страницы фоном указано, кому
передана документация - ВТБ24 (ПАО). Банку запрещено кому-либо передавать данную документацию; исключений нет. 10

11.

Обработка тайм-аутов
Логика передачи сообщений при тайм-ауте
• Сообщение 0800 при отсутствии ответа Мультикарта повторяет до тех пор, пока Профайл не ответит
• Сообщение 0100 (запрос на авторизацию) обрабатывается следующим образом:
При неполучении ответа или получении ответа с задержкой (т.е. после тайм-аута) Мультикарта
считает транзакцию не разрешённой для проведения, отправляет эквайеру «отказ», одновременно
отправляет ревёрсал в Профайл
• Сообщения 0120 и 0220 (уведомления) обрабатываются следующим образом:
При неполучении ответа или получении ответа с задержкой (т.е. после тайм-аута) Мультикарта
пытается повторно отправить сообщение, и делает так до тех пор, пока Профайл не ответит
• Сообщение 0420 (ревёрсал) обрабатывается так же, как и уведомления
(справочно: по полученной от коллег из Мультикарты информации, тайм-аут в TWO составляет 17 секунд)
11

12.

Поддерживаемые типы транзакций
• Как было сказано ранее, в подполе Р-3.1 входящего сообщения в Профайл приходит тип транзакции
• INT 5 по этому коду определяет, умеет ли он обрабатывать такие транзакции
• если умеет, то обрабатывает в соответствии с заложенной логикой
• если не умеет, то отвечает на запрос отказом
• Если при обработке запроса «не прошли» какие-то проверки (у карты истёк срок использования,
недостаточно средств, превышен расходный лимит, и т.п.) Профайл отвечает отказом и указывает
соответствующий код возврата. Значения кодов возврата можно посмотреть в таблице ZUTBLCRDRSPC
• Если во время обработки запроса возникла системная ошибка, Профайл отвечает отказом (код отказа
54, система недоступна). Вообще, выбор кода отказа настраивается – об этом будет рассказано.
• Это относится к сообщения типа 0100 (когда Мультикарта запрашивает разрешение у Профайла)
Типы транзакций, которые Профайл умеет обрабатывать или скоро будет уметь
Код транзакции
Название транзакции
Выполняемые действия (кроме проверок)
010
020
030
050
063 / 064
070
081
110
111
112
113
116
130
132 / 133
Снятие наличных в банкомате
Внесение наличных через банкомат
Запрос остатка
Платёж через банкомат
Перевод с карты на карту через банкомат
Запрос выписки
Смена PIN-кода
Оплата товаров и услуг (покупка)
Оплата товаров и услуг (преавторизация)
Завершение преавторизации
Оплата товаров и услуг (по мэйлу / телефону)
Проверка карты
Оплата товаров и услуг (квази-кэш)
Перевод с карты на карту через POS-терминал
Повесить HOLD на сумму операции
Провести транзакцию по зачислению*
Сообщить остаток по карте в ответе
Повесить HOLD на сумму операции
(в разработке)
Сообщить мини-выписку в ответе
- (нет действий, PIN хранится в Мультикарте)
Повесить HOLD на сумму операции
Повесить HOLD на сумму операции
Скорректировать сумму HOLDа (если изменилась сумма)
Повесить HOLD на сумму операции
- (нет действий, кроме проверок)
Повесить HOLD на сумму операции
(в разработке)
* - транзакция по зачислению средств проводится во время обработки запроса, исключение составляет период времени после 22:00, когда транзакция откладывается до закрытия дня
в Профайле (связано с переключением в Мультикарте даты для устройств в 22:00 и необходимостью отразить транзакцию по карте и по устройству в одну и ту же дату)
12

13.

Где и как хранится информация о карточных авторизациях (1 из 3)
Коммуникационный лог
• Всё, что приходит из Мультикарты в Профайл, сохраняется в таблицах NSMLOG и NSMLOGD
• в NSMLOG есть поля: номер карты, дата, время
• в NSMLOGD лежит текст сообщения (разрезанный на несколько записей, т.к. иногда размер
сообщения может быть очень большим,- TCI допускает поля длиной до 99 999 символов)
• связь между NSMLOG и NSMLOGD - по ID сообщения (поля MSGTYP и MSGID).
• т.к. в настоящее время у нас только один источник сообщений, Мультикарта, то у всех сообщений
поле MSGTYP содержит значение ISOATM
• поле MSGID содержит 22-байтовое уникальное значение, состоящее из:
• даты (первые 5 символов), дата в Профайле это число (количество дней с даты Х), при этом
величина «1» означает 01.01.1841, а, например, 26.10.2015 соответствует значению «63851»
• времени (ещё 5 символов), время в Профайле это количество секунд текущего дня
• 5-ти последних цифр ID процесса, создающего новую запись с таким ID
• 6-ти последних цифр показания машинных часов (милли- и микросекунды)
• символа «А» (чтобы GTM считал всё значение ID символьным, а не числовым*)
• Всё, что Профайл отправляет в Мультикарту, также сохранятся в NSMLOGD
• Если Профайл получил сообщение, которое не умеет обрабатывать, или которое не требует обработки
(например, запрос на эхо-тест), то «следы останутся» только в NSMLOG/NSMLOGD
• На картинке
показано на
примере, как
связаны между
собой записи в NSMLOG и NSMLOGD
(в данном примере текст входящего сообщения
хранится двумя частями, а текст исходящего
сообщения – целиком)
* - для справки: в базе данных GTM нет жёсткого описания структуры глобалей (единица хранения информации, аналог таблиц в реляционной БД), поэтому в
любой момент можно добавлять в базу новые элементы или менять структуру глобалей, добавляя новые «ветки»; на уровне БД также не указывается
характеристика поля – текстовое или числовое. Чтобы GTM считал значение текстовым (для числового - длина 22 знака превышает разрешённую точность, могут
13
возникнуть проблемы), один из 5 крайних справа символов должен быть буквой, а не цифрой. В данном случае просто добавлена буква «А».

14.

Где и как хранится информация о карточных авторизациях (2 из 3)
Таблица карточных транзакций
• Все финансовые транзакции (списание/зачисление по карте), а также все прочие транзакции, за которые
предусмотрена комиссия, сохраняются Профайлом в таблице ZAUTHDTL. Поэтому, например, в ней
сохраняются транзакции с типом 081 (смена PIN-кода), даже несмотря на то, что сейчас установлена
нулевая комиссия, но не сохраняются транзакции с типом 116 (проверка карты)
• Каждой транзакции соответствует одна запись ZAUTHDTL
• Если транзакция была изменена или аннулирована, то запись в ZAUTHDTL будет скорректирована
• Выписка по карте, которая формируется ИНТ 72, извлекает из ZAUTHDTL детали транзакции
• ИНТ 5 при обработке авторизационных запросов создаёт в ZAUTHDTL записи со значением ISOATM в
после INTRFACE.
• Ниже приведены примеры записей в ZAUTHDTL (поле AUTHID соответствует MSGID в NSMLOG)
CALDT
CALTM
MID
ISOATM
INTRFACE
638534330413872635375A
AUTHID
2015-10-28
12:01:44
0220
020
ISOATM
638534333599114204790A
2015-10-28
12:02:15
0220
ISOATM
638534336290152525219A
2015-10-28
12:02:42
0100
ISOATM
638534353090152854011A
2015-10-28
12:05:30
ISOATM
638534360190152031465A
2015-10-28
12:06:41
ISOATM
638534407690152013401A
2015-10-28
12:14:36
Календарная дата запроса
Календарное время
Тип сообщения от Мультикарты
Код карточной транзакции
Сумма и валюта транзакции (оригинальные)
TRNTYPE
ORIGAMT
AUTCODE
RSPCD
10000.00 RUB
ORIGCRCD
000060950170
EXTRETREF
387012
VB24
VB24
000346
01
020
1000.00 USD
000060950172
387012
VB24
VB24
000347
01
010
15000.00 RUB
000060950174
387012
VB24
VB24
000348
01
0100
010
300.00 EUR
000060950177
387012
VB24
VB24
000349
01
0420
010
500.00 USD
530109000011
ATM01
CARD ACCEPTOR VISA
000350
01
0100
010
500.00 USD
530109000015
ATM01
CARD ACCEPTOR VISA
000351
01
External RRN
ID терминала
Название мёрчанта
TERMID
MERCHID
MERCHFIN
откуда
пришла
транзакция
код авторизации
и код ответа
Профайла
• В примере выше:
• Выполнено 2 операции внесения наличных (код транзакции 020), при этом было по 2 авторизационных запроса по
каждой транзакции (0100 – проверка возможности внесения и 0220 – уведомление о внесении); в таблице
ZAUTHDTL виден тип последнего сообщения
• Выполнено 4 операции снятия наличных, потом одна из них аннулирована (видно по типу сообщения 0420 ревёрсал)
• Первые 4 транзакции пришли с устройства ВТБ24 (см поле MERCHFIN), последние две – из VISA.
14

15.

Где и как хранится информация о карточных авторизациях (3 из 3)
Таблица исключительных ситуаций
• Если Профайл вернул ненулевой код (точнее, не «ноль-первый»; потому что именно значение «01» в
поле RSPCD соответствует ответу в Мультикарту «транзакция разрешена»), то в таблицу ZAUTHEXC
записывается причина, по которой Профайл посчитал проведение транзакции невозможным.
Причины могут быть самые разнообразные. AUTHID, конечно же, ссылается на MSGID в NSMLOG.
AUTHID
637394651313895400003A
637505399640114400001A
637505700140114400008A
637530431649604000170A
637530431740114400383A
637541363825047700222A
CALDT
CALTM
2015-07-06 12:55:14
2015-07-17 14:59:56
2015-07-17 15:50:01
2015-07-20 01:11:56
2015-07-20 01:11:57
2015-07-31 15:17:03
EXCDESC
Invalid card number
Not supported transaction code 064
RRN length exceeded (field 108)
Error while determining MISC fee. Service fee plan BASIC not compiled
Expiration date mismatch
Account closed
• Причина, по которой отклонён авторизационный запрос
• Примерно с середины 2015 года в ZAUTHEXC перестали заноситься записи, относящиеся к кодам 59
(недостаточно средств для выполнения транзакции) и 60 (превышение расходного лимита). Это сделано,
чтобы не «захламлять» эту таблицу. Управление тем, какие причины отказов попадают в ZAUTHEXC, а
какие – нет, настраивается при помощи таблицы UTBLEXTRSP1 (часть таблицы показана ниже)
INTRFACE
ISOATM
ISOATM
ISOATM
KEY
3784
OVRBALAVL
OVRZLMTTXN
DES
Invalid card number
Transaction exceeds available balance
Transaction exceeds the amount limit
RESPCDE1
52
59
60
ZSKIPEXC
true
true
• При возникновении конкретной проблемы в процессе работы ИНТ 5 (идентифицируется полем KEY),
Профайл проверяет необходимость добавить запись в ZAUTHEXC (или пропустить добавление, см поле
ZSKIPEXC) и отвечает в Мультикарту кодом возврата из поля RESPCDE1).
Хорошей практикой является периодический анализ содержимого ZAUTHEXC, например, таким образом:
SELECT DISTINCT EXCDESC FROM ZAUTHEXC WHERE CALDT BETWEEN … AND …
(или оптимизированный вариант условия – WHERE AUTHID BETWEEN … and …, поскольку AUTHID является индексом, такой запрос меньше нагружает базу, но,
требует больше усилий от вас, т.к. нужно сначала определить два значения AUTHID, что можно, сделать, например, через DIGGER)
Все «новые» и особенно «непонятные» причины отказов необходимо проанализировать (в т.ч. с
привлечением вендора), чтобы понять, нет ли каких-либо проблем в логике работы ИНТ 5
15

16.

Как посмотреть карточные авторизации
• В Профайле существует программный интерфейс (ИНТ 114А),
который возвращает данные коммуникационного лога
NSMLOG/NSMLOGD по конкретной карте за конкретный
период. Можно запросить только входящие, только
исходящие, либо все сообщения. Также можно запросить
либо сообщения, которые есть и в NSMLOG, и в ZAUTHDTL,
либо сообщения, которые есть только в NSMLOG, но которых
нет в ZAUTHDTL.
• Удобство ИНТ 114А в том, что он разбивает сообщение на
отдельные поля (в то время как если смотреть сообщение
SELECT-ом по таблице, видишь одну длинную строку
символов). Кроме того, из-за наличия спецсимволов
SELECTы могут работать некорректно и не возвращать часть
данных, а ИНТ 114А умеет обрабатывать спецсимволы
(показывает их в ответе как «\» плюс 16-ричный код).
• Также можно посмотреть авторизации по
финансовым транзакциям (пока они ещё не
стали транзакциями) при помощи ИНТ 72 (тип
запроса TRNOTHER). В это режиме ИНТ 72
возвращает существующие холды (а
авторизации по финансовым транзакциям и
приводят к созданию холдов).
• Если транзакция уже проведена
(заPOSTирована), то холд снимается, и ИНТ
72 не покажет его в списке авторизаций.
• Если запрос не приводит к созданию холда, то его также нельзя увидеть в ответе ИНТ 72 - TRNOTHER
16

17.

Углубляемся в детали… channels и payment associations (1 из 2)
• Поскольку бизнес-заказчиком была заявлена необходимость, скажем так, различного поведения карты в
своих и чужих устройствах (самый простой пример – различные комиссии за проведение операции),
Профайлу необходимо уметь определять, где совершена карточная операция
• Источником данных является поле P-43.11(Terminal financial institution name), 4 символа.
• Для целей обработки авторизационного запроса это поле называется payment association, но я его
предпочитаю называть «платёжная система» или «платёжная сеть», потому что оно показывает, откуда к
нам пришла транзакция. Возможные варианты конфигурируются в таблице ZUTBLPASSOC, при этом
поле ASSOC содержит возможные варианты значений поля 43.11во входящих запросах
ASSOC
DESC
BNET
MasterCard
NSPM
National MasterCard
NSPV
National Visa Card
TKKB
TKB-Partner
VB24
VTB24
VBW4
WAY4
VISA
VISA (BNET)
VPAY
All MK partners
NOTUS ONUS
true
NU
true
NU
true
NU
true
PR
false
US
false
US
true
NU
true
PR
Две правые колонки определяют тип устройства в каждой из
платёжных сетей, одна колонка просто показывает «наше»
устройство или «не наше».
Вторая колонка даёт более точную классификацию устройства: NU
– чужое, PR – банка-партнёра, US – своё.
Примечание: значение VPAY означает локальную сеть Мультикарты
(кроме устройств, явно выделенных в другие каналы – VB24, VBW4
и TKKB).
• Напоминаю
продемонстрированную ранее
картинку (добавлены названия
платёжных сетей) – в качестве
иллюстрации того, каким
значением заполняется поле
P-43.11 авторизационного
запроса, приходящего из
Мультикарты
17

18.

Углубляемся в детали… channels и payment associations (2 из 2)
• Комбинация кода транзакции и платёжной сети определяет channel (т.е. канал совершения карточной
операции). При этом, очевидно, все комбинации «код транзакции» и «платёжная сеть» должны быть
перечислены, чтобы во время выполнения ИНТ 5 не возникало ошибок.
• Таблица ZUTBLCHNLMAP хранит указанные выше значения и используется для определения канала.
ZTC
110
110
110
110
110
110
110
110
010
010
010
010
010
010
010
…
PASSOC
BNET
NSPM
NSPV
TKKB
VB24
VBW4
VISA
VPAY
BNET
NSPM
NSPV
TKKB
VB24
VISA
VPAY
…
ZCHANNEL
POS-OTHER
POS-OTHER
POS-OTHER
TKB-PARTNER
POS-VTB24
POS-WAY4
POS-OTHER
POS-VTB
ATM-OTHER
ATM-OTHER
ATM-OTHER
TKB-PARTNER
ATM-VTB24
ATM-OTHER
ATM-VTB
…
Показаны коды транзакции 110 (покупка) и 010 (снятие наличных в
банкомате) и как в зависимости от поля P-43.11 определяется канал
совершения карточной операции.
ZTC
Показаны сочетания:
– кода транзакции,
– значения POS entry mode,
– значения POS condition code,
– признака наличия CVV,
которые позволяют считать
транзакцию совершённой по
каналу internet
• Отдельным образом (по таблице ZUTBLCHNLINT) определяется, не
является ли транзакция совершённой по каналу INTERNET.
• Эта проверка проводится до проверки по ZUTBLCHNLMAP.
• Атрибут транзакции «канал» используется при проверке расходных
лимитов, клиент может настроить себе индивидуальный лимит на
сумму дневных покупок по каналу internet.
POSEM
POSCC
CVVVRES
ZCHANNEL
110
000
008
1
INTERNET
110
000
059
1
INTERNET
110
000
081
1
INTERNET
110
000
082
1
INTERNET
110
000
083
1
INTERNET
110
000
084
1
INTERNET
110
000
085
1
INTERNET
110
000
086
1
INTERNET
110
000
087
1
INTERNET
110
000
088
1
INTERNET
110
000
089
1
INTERNET
110
010
008
1
INTERNET
110
010
059
1
INTERNET
110
010
081
1
INTERNET
110
010
082
1
INTERNET
110
010
083
1
INTERNET
110
010
084
1
INTERNET
110
010
085
1
INTERNET
110
010
086
1
INTERNET
110
010
087
1
INTERNET
110
010
088
1
INTERNET
110
010
089
1
INTERNET
110
011
008
1
INTERNET
110
011
008
1
INTERNET
110
012
008
1
INTERNET
110
012
059
1
INTERNET
110
012
081
1
INTERNET
110
012
082
1
INTERNET
110
012
083
1
INTERNET
110
012
084
1
INTERNET
110
012
085
1
INTERNET
110
012
086
1
INTERNET
110
012
087
1
INTERNET
110
012
088
1
INTERNET
110
012
089
1
INTERNET
18

19.

Углубляемся в детали… сумма транзакции
• Входящий авторизационный запрос (в соответствии с документом по TCI) содержит следующие поля:
• P-4 – transaction amount (обязательное)
• P-6 – billing amount
• P-49 – transaction currency (обязательное)
• P-51 – billing currency
• S-106 – multicurrency data
• При этом в соответствии с документом по TCI поля 4 и 49 содержат оригинальную сумму/валюту только
в случае, если транзакция совершена в локальной сети Мультикарты; в противном случае эти поля по
описанию TCI содержат эквивалент в «биллинговой валюте», а фактически – рублёвый эквивалент.
• Необязательное поле S-106 содержит оригинальные валюту и сумму транзакции (подполя 106.2, 106.4)
• Алгоритм определения суммы транзакции в ИНТ 5 реализован следующим образом:
• Поля P-6 и P-51 не участвуют в определении суммы транзакции
• Поле P-49 может содержать только 3 валюты (RUB, USD, EUR), т.к. от платёжной системы не может
прийти другая валюта, а в локальной сети Мультикарты устройства не проводят транзакции в других
валютах. Cоответственно, с учётом того, что карты в Профайле выпускаются только к мастер-счетам (а
они в RUB, USD, EUR, конвертация в Профайле проводится только между этими тремя валютами.
19

20.

Углубляемся в детали … транзакции по внесению наличных в банкомате (1 из 2)
• Для удобства клиентов (и прежде всего, чтобы обеспечить возможность внесения средств на счёт для
погашения кредита день в день) банк «научил» Профайл выполнять транзакцию внесения наличных в
реальном времени
• В отличие от других транзакций, когда при получении авторизационного запроса Профайл вешает
«холд», а при обработке клиринга снимает этот «холд» и создаёт транзакцию по счёту, здесь транзакция
по счёту создаётся в момент обработки авторизационного запроса. Соответственно, при обработке
клиринга Профайл делает проверку, и если транзакция уже создана, второй раз он её не создаёт
• В этом алгоритме есть
исключение – в определённое
время и только для
ограниченного набора
устройств транзакции
по внесению наличных не
создаются, см рисунок:
• В связи с тем, что дата на устройствах «переключается»
в 22:00 (т.е. операции после 22:00 придут в реестре от
Мультикарты уже за следующую дату)
требуется обеспечить совпадение даты в операции
по устройству и по карте. Для этого в ИНТ 5 была
сделана доработка, которая позволяет «откладывать
на завтра» операции, проведённые по карте после
«времени отсечки» (сейчас настроено 22:00). Операции, которые проведены после начала закрытия
дня (точнее, после начала критического пути), снова проводятся в реальном времени.
20

21.

Углубляемся в детали … транзакции по внесению наличных в банкомате (2 из 2)
• «Отложенные на завтра» операции обрабатываются следующим образом:
• создаётся «холд» на отрицательную сумму для увеличения доступного остатка
• выполняется операция в будущей дате (т.е. в дате «завтра») – технически это означает всего лишь,
что Профайл запомнил запрос на выполнение это транзакции и отработает его, когда наступит
нужная дата. Да наступления этой даты такие «запомненные» транзакции не видны
• При наступлении «завтра» запомненные транзакции обрабатываются
• пакетная процедура QUE066 (входит в состав процедур закрытия дня) просматривает список
отложенных транзакций и пытается их выполнить; при успешном выполнении холд аннулируется, а
по счету проводится транзакция
• в случае возникновения ошибок QUE066 регистрирует их в отчёте REP220
• ВАЖНО: балансовый остаток не увеличивается в момент выполнения операции внесения наличных
после времени отсечки. Причина очевидна – транзакция по счету ещё не совершена (она отложена до
выполнения QUE066). И несмотря на то, что клиент сразу видит увеличившийся доступный остаток,
проведение операции (например, снятие средств) может быть невозможно, т.к. при обработке
авторизационных запросов Профайл может отслеживать наличие неотрицательного балансового остатка
тоже (а не только доступного остатка) – но это зависит от настроек пользователя для ИНТ 5
• Операции по внесению наличных,
выполненные во время критического
пути, обрабатываются стандартным для
Профайла образом – они видны в
выписке по счету (технически в системе
в это время действует механизм storeand-forward, обеспечивающий
неизменность балансового остатка и
одновременно учёт всех списаний и
зачислений по счёту).
• При выполнении операции внесения по счёту после начала критического пути, сразу увеличиваются и
доступный, и балансовый остатки. Поэтому клиент сразу же может расходовать деньги с карты.
21

22.

Углубляемся в детали … транзакции в реальном времени
• После объединения ВТБ24 и ТКБ возникла необходимость обеспечить погашение кредитов ТКБ с
мастер-счетов. Такое погашение было сделано через карту в Профайле, т.к. при помощи операции по
списанию с карты
• Как и при внесении наличных через банкомат, погашение кредита (обслуживаемого во внешней системе)
с мастер-счета при помощи карты в Профайле порождает транзакцию по счёту в реальном времени (т.е.
в момент обработки авторизационного запроса)
• Для того, чтобы идентифицировать карточные операции, по которым транзакцию по счёту необходимо
создать в момент обработки авторизационного запроса, была создана таблица ZUTBLCRDLCRC.
• ИНТ 5 при обработке авторизационного запроса сканирует строки этой таблицы и проверяет 4 атрибута
авторизационного запроса на совпадение. Таблица позволяет в одном поле указать несколько полей
через запятую, а также позволяет указывать маску значений (при помощи символа *)
• Ниже приведён пример настройки этой таблицы (в розовой строке указаны проверяемые поля
авторизационного сообщения). Обращаю внимание, что на промышленном контуре данная таблица по
состоянию на ноябрь 2015 пуста
SEQ
CRCDNO
PASSOC
TERMID
ZTC
Field 49
Field P-43.11
Field P-41
Field P-3.1
1
978,643
VISA
*
010,04*
2
643,978
BNET
3
643
VPAY
020
00100001
1*
22

23.

Углубляемся в детали … расчёт комиссий за проведение операции (1 из 3)
Транзакционные карточные комиссии
• Это комиссии, которые выполняются при выполнении финансовой операции (расход по карте или внесение наличных); в
общем случае сумма комиссии зависит от суммы операции.
• ВТБ24 не использует «родной» функционал системы из-за недостаточной гибкости; для расчёта транзакционных комиссий
в 2010 году была сделана отдельная разработка
• Данные для расчёта комиссии настраиваются в таблицах, как показано ниже (приведена только часть таблиц):
• Алгоритм работает следующим образом:
– Выбирается группа записей в ZUTBLTFEEPLN1, соответствующая пакету услуг (точнее, соответствующая тарифному плану в
конкретной валюте, он указан на счёте в поле DEP.FEEPLN) и коду КБО операции (может быть задан как код КБО, так и группа
кодов, см таблицу ZUTBLSTGFEETRN)
– Эти записи просматриваются по возрастанию значения SEQ, одновременно по STARTDT и ENDDT проверяется, что данная
запись все ещё активна, и её стоит рассматривать
– По каждой записи определяется ссылка на таблицу критериев ZUTBLTFEESEL (поле TFEESEL)
– Все поля таблицы критериев проверяются на соответствие атрибутам проводимой карточной операции (ID банка-эквайера,
валюта операции, канал проведения операции, тип карты (задаётся напрямую или через указание группы типов карт), Дт/Кт, а
также другим потенциально возможным атрибутам, не показанным на рисунке – например, тип устройства (своё/чужое), ID
конкретного устройства или страна, где находится устройство)
– В случае, если все критерии совпадают (важно: пустые поля таблицы не проверяются), строка ZUTBLTFEEPLN1 считается
выбранной, и производится расчёт суммы комиссии в соответствии с настройками таблиц ZUTBLTFEECAL, ZUTBLTFEESCH,
ZUTBLTFEESCH1 (ссылка на них находится в поле TFEECAL, см рисунок; сами таблицы не показаны)
23

24.

Углубляемся в детали … расчёт комиссий за проведение операции (2 из 3)
Нетранзакционные (мисковые*) карточные комиссии
• Функционал по взиманию мисковых комиссий «зашит» в некоторые карточные интерфейсы (например, в
ИНТ 8, ИНТ 53, ИНТ 102), либо эти комиссии могут взиматься извне явно при помощи ИНТ 100А (расчёт
комиссии определённого типа) и ИНТ 26 (списание со счета). Когда комиссии «зашиты» в интерфейс, это
означает, что при его вызове производится расчёт и взимание определённого типа комиссий:
Событие
Вызов ИНТ 8 (выпуск карты)
Вызов ИНТ 53 (перевыпуск карты)
Вызов ИНТ 102 (изменение статуса)**
Активация карты
Годовщина использования карты
Тип взимаемой комиссии
CRDISSUE
CRDREISU
CRDSTAUP
CRDACTIV
CRDSERV
• Также мисковые комиссии могут взиматься при выполнении некоторых
карточных операций (запрос остатка, получение мини-выписки, смена
ПИН-кода); в таблице ZUTBLCRDTC указывается тип комиссии для
конкретных кодов карточных операций (см рисунок справа)
• Сумма мисковой комиссии определяется по таблице FEESRV (необходимо обратить внимание, что для
одного и того же типа в FEESRV существует
множество различных записей – при работе
всегда используется последняя по дате). Либо
явно указывается сумма комиссии (FEEAMT),
либо даётся ссылка на другую таблицу, по
которой производится определение комиссии
• В таблице комиссий (например,
ZUTBLFEECARD) для каждого сочетания
атрибутов карты указывается размер
комиссии. Все поля обязательные и все
поля проверяются на строгое соответствие
* мисковые или misc-овые (с ударение на «о»), т.е. т.н. «прочие» комиссии
** для того, чтобы при изменении статуса взималась комиссия, в UTBLCRDSTAT1 напротив пары статусов (соответствующих переходу из одного статуса в другой)
было указано ZFEEAPPL= true; в настоящее время данная возможность не используется
24

25.

Углубляемся в детали … расчёт комиссий за проведение операции (3 из 3)
Отложенные комиссии
• В случае, если по бизнес-требованиям предусматривается возможность выполнения операции (за которую положено
взимать комиссию) и в случае отсутствия средств у клиента, комиссия может быть настроена как «откладываемая»
(deferrable), хотя чаще всего говорят «отложенная» или «deferred»
• В этом случае при отсутствии средств на счете Профайл вешает холд на сумму комиссии, а когда поступают средства,
снимает холд и списывает требуемую сумму (но целиком, а не по частям)
• В настройках выгрузки для бухучета (об этом будет рассказано позднее) указываются 3 различных кода:
- успешное удержание комиссии в момент выполнения операции
- выставление требования к клиенту (т.е. создание холда)
- удовлетворение ранее выставленного требования (т.е. снятие холда и списание комиссии)
(эти три кода настраиваются в таблице ZUTBLTRNTYPE, поля: TRNTYPE, DEFER, COLDEFPMT)
Запомненные комиссии
• В случае, если не требуется отражать не удержанную комиссию как требование к клиенту (например, мы выпустили
клиенту карту, но не уверены, что он вообще когда-нибудь её активирует и внесёт деньги; поэтому нет большого смысла
сразу же оформлять по учёту задолженность клиента перед банком), и тогда используется альтернативный вариант –
«запомненная» комиссия
• Информация о «запомненных комиссиях» (pending fee) хранится в таблице ZFEEDEF
• Комиссия за выпуск и перевыпуск всегда является «запомненной», она рассчитывается в момент выпуска или
перевыпуска, а взимается в момент активации карты (через минуту, через час, через год…)
• Если эта комиссия настроена как deferrable, и на счёте в момент активации нет денег, тогда создаётся холд, и в бухучете
отражается задолженность клиента перед банком
Бесплатные карты
• В рамках некоторых (платных) пакетов услуг клиенту полагаются одна или несколько «бесплатных» карт определённых
типов; это означает, что комиссия за выпуск и обслуживание этих карт не взимается
• В таблице ZUTBLPKGCRD приведён список (в разрезе пакетов) список групп карт и количество бесплатных карт в каждой
группе; список типов карт, входящих в группу, хранится в ZUTBLCRDTYPGRP
Бесплатное снятие
• В рамках зарплатных проектов устанавливается требование обеспечить определённое количество снятий (за период)
наличных в банкоматах «чужих» банков без взимания комиссии. Разрешённое количество снятий, счётчик фактических
снятий, а также период учета ведутся на карте (см поля, начинающиеся на ZFREEWTH, в таблице ZCRD)
25

26.

Приложение1: количество авторизаций (недельный период, данные за минуту)
26

27.

Приложение2: тайминги по обработке авторизационных запросов
Анализ проводился 18.09.2015
в течение 3 часов во время
пиковой карточной нагрузки.
По каждой карточной транзакции
были определены:
время отклика, замеренное Мультикартой,
время обработки, замеренное Профайлом.
(в соответствии со значением NSMLOG.ELAPSED)
График построен на основании
времени обработки, замеренного
Профайлом (поле NSMLOG.ELAPSED)
27

28.

Приложение3: справочно: как Профайл работает в режиме 24х7 (общая схема)
Обычный (нормальный) режим работы
Режим работы при задержке закрытия дня
Т.к. Профайл всегда работает только в одном
операционном мне, то для расчёта процентов,
штрафов и т.п. (для которых требуется сохранить
остатки по счетам по состоянию на конец
предыдущего дня), реализован так называемый
«критический путь», когда не производится
изменение таблицы счетов, где хранятся остатки.
Для внешней системы все вызовы Профайла во
время критического пути работают точно так же, как
и в любое другое время дня, однако, внутри
Профайла действуют совсем другие механизмы.
Все проводимые во время критического пути
транзакции (имеется в виду POST-ирование)
сохраняются в отдельной таблице и условно
отражаются в следующем операционном дне, а
после окончания критического пути переносятся в
основные таблицы базы данных как транзакции дня
Т+1. Все проводимые во время критического пути
транзакции меняют в реальном времени доступный
остаток и балансовый остаток дня Т+1
Целевая схема работы – вторая часть процедуры
закрытия дня запускается ровно в полночь. И тогда
Профайл работает синхронно с другими системами
(границей для проведения транзакций в Т или Т+1
является момент начала критического пути).
Проблемы возникают в случае, если по каким-либо
причинам процедура закрытия дня в Профайле
запускается с задержкой (см нижний рисунок). В
этом случае возникает проблемный период
времени, когда Профайл и другие системы банка
рассинхронизированы по дате. В этом случае
возникают проблемы при переводе средств между
счетами, которые ведутся в разных системах,
потому что «собрать баланс» в Главной книге в
случае, когда одна половинка операции отражена
«вчера», а другая «сегодня», невозможно.
28

29.

ЧАСТЬ 2
Клиринг
29

30.

Что такое «клиринг»
• Клиринг – это, фактически, безусловное требование платёжной системы к банку провести по карте
определённую операцию. Если ранее по этой операции был авторизационный запрос, то инициатор
ранее «спрашивал разрешение» на проведение операции. Если такого запроса не было, значит, кто-то
самостоятельно принял решение о том, что операцию можно провести, не спрашивая об этом банк
• В любом случае в момент обработки клиринга у Профайла нет выбора – он обязан провести операцию
по карте (единственное исключение – если карта уже закрыта). И уже потом соответствующие службы
банка будут разбираться, насколько обоснованной была эта карточная операция (самостоятельно или
после заявленной клиентом претензии) и не нужно ли её опротестовывать
• Отсутствие средств на счёте (на карте) основанием для отказа при обработке клиринга не является
• Как уже было сказано, для обработки клиринга в Профайле используется ИНТ 6
• На вход ИНТ подаётся клиринговый файл, который представляет из себя текстовый файл с
определённым названием (т.е. именем файла):
Фиксированная часть имени файла (не меняется)
Дата файла (формат ГГММДД)
Платёжная сеть, к которой относятся операции
Номер файла (внутри платёжной сети)
Расширение файла (не меняется)
ВАЖНО: файл с «неправильным» именем обработан не будет.
• Каждый запуск ИНТ 6 заносится в лог (таблица ZCRDINCS). В этом логе хранятся как успешные, так и
неуспешные запуски.
Примечание: в Профайле многие поля и таблицы, относящиеся к клирингу, содержат буквы INC – потому что (по непонятной для меня причине)
иностранные коллеги используют слово «inclearing», а не «clearing»; соответственно, INC – это начало слова «inclearing».
Буква Z, с которой начинаются названия полей и таблиц, означает, что это кастомное поле или таблица (т.е. созданная в ходе кастомизации)
30

31.

Формат файла (1 из 3)
• Все значения в файле указываются в формате «тэг=значение». Потом идёт разделитель и следующая
пара «тэг=значение». Разделителем является символ с кодом 10 (hex) или 16 (dec)
• Строки разделяются символом 0A (hex) или 10 (dec). Примечание – попытка дать на вход Профайла
файл с принятым для Windows двухсимвольным разделителем строк (т.е. 0D0A hex) приведёт к тому, что
символ 0D будет считаться частью последнего поля в этой строке. Иногда это не страшно
• Традиционно файл состоит из заголовка (header), тела и «подвала» (trailer)
• Корректное указание заголовка важно, потому что в противном случае ИНТ 6 не будет обрабатывать
файл. В заголовке указываются поля: «Encoding=Cp1251», «FileNo=0», «FileType=CS»,
«InstName=VB24», «PackNo=2795», «Test=0», «Version=4.00». Принципиально важно указать* кодировку
CP1251 (потому что ИНТ 6 не умеет обрабатывать другую кодировку), название получателя VB24
(потому что в ИНТ 6 стоит «тупая» проверка на это значение», тип файла CS (опять же тупая проверка),
что это не тестовый режим**, корректную версию протокола TIP***.
• Контроль версии протокола необходим для предотвращения ситуаций «неожиданного» изменения
содержания клирингового файла и ошибочной его обработки. При реализации ИНТ 6 было решено, что
банк не будет поддерживать все изменения версий TIP, но, тем не менее, будет отслеживать эти
изменения; соответственно, критичные для обработки клиринга изменения должны быть реализованы
как доработка ИНТ 6. Таким образом, при каждом изменении версии TIP, о котором банк информируют
Компас Плюс и Мультикарта, необходимо провести анализ на предмет необходимости доработки ИНТ 6.
После выполнения таких доработок или после принятия решения о том, что доработки не требуются,
можно изменить номер версии в настройках Профайла, чтобы он был готов обрабатывать файлы с
соответствующим значением в поле Version.
• Важно: принимаются файлы со значением версии равной или меньшей, чем указано в настройках
* - все «тупые» проверки выполняются против настроенных значений: UTBLEXTINT.ZCLRFILTYP (тип файла), UTBLEXTINT.ZCLRINSNAM (название
банка ВТБ24), UTBLEXTINT.ZCLRFILENC (кодировка файла)
** - использование test mode регулируется настройкой UTBLEXTINT.ZCLRALWTST (1=разрешено / 0=запрещено), при этом с точки зрения обработки
файла никакой разницы нет. Данный режим когда-то давно предусматривался исключительно для целей тестирования – т.е. в файле было бы
указано test=1, и файлы с таким признаком обрабатывались бы на тестовых контурах, но не обрабатывались бы на промышленном контуре. На
промышленном контуре должно быть установлено значение 0 (т.е. запрещено) во избежание случайной обработки тестовых файлов
*** - версия протокола TIP настраивается в поле UTBLEXTINT.ZCLRPRTCLV.
31

32.

Формат файла (2 из 3)
• В «подвале» указывается контрольная сумма для «тела» файла. Она рассчитывается по алгоритму
CRC16 (кому интересно, можно найти этот алгоритм в интернете). Контрольная сумма указывается в
формате «CRC=<значение>»
• Тело файла состоит из произвольного количества строк, содержащих информацию о карточной
операции. Каждая строка содержит множество полей (формат тот же – «тэг=значение), причём
значительная часть полей в настоящее время Профайлом не обрабатывается.
• Порядок полей в строке – произвольный (на усмотрение отправителя)
• Кодировка CP1251 разрешает использование символов с любым кодом от 0 (dec) до 255 (dec) или, что
то же самое, от 0 (hex) до FF(hex).
• Дата/время в формате UAMP передаются как целое число – количество секунд после 00:00:00 1/1/1901
• В общем случае поля могут содержать подполя (также разделяемые спецсимволом), а значения полей
могут содержать спецсимволы внутри значения (причём в общем спецсимволы могут совпадать с одним
из разделителей). Более детально формат описан в документе по формату UAMP (TranzWare Universal
Application Messaging Protocol).
• Формат UAMP не является, с моей точки зрения, «user-friendly». Хотя бы потому, что что символ 09 (hex),
который означает табуляцию и является традиционным для Windows разделителем полей в текстовом
файле, в формате UAMP является одним из разрешённых символов для значения поля. Или потому, что
UAMP формально разрешает передавать числовые значения в виде их 16-ричного кода (например, ID
терминала 41324334 можно передать как 41 (hex) 32 (hex) 43 (hex) 34 (hex), то есть «A2B4»). Сочетание
этих двух возможностей иногда приводит к появлению в строке файла всего «зоопарка» разрешённых
кодов (включая «табуляцию» (09 hex), «перевод строки» (0D hex) и т.п.), что приводит к проблемам при
сохранении клиринговой записи в текстовый файл DOS/Windows в виде отдельных полей и попытке этот
файл обработать (это одна из распространённых проблем при выгрузке данных из Профайла в КХД).
32

33.

Формат файла (3 из 3)
Наиболее «нужные» поля клирингового файла (ниже приведены тэги и описание значений):
– «A» (тип операции): 1240 – прямая транзакция, 4240 – ревёрсал (остальные не обрабатываются)
– «С» (код карточной операции,- такой же, как в авторизациях, т.е., например, 110 – покупка)
ВАЖНО: в клиринговом файле все числовые поля отображаются как числа, т.е. без лидирующих
нулей. Это относится и к полю «код операции», и к полю «код страны». Является ли
поле числовым или текстовым, нужно смотреть в описании протокола TIP
– «Е» (номер карты)
– «^» (external RRN, retrieval reference number)
– «m» (код авторизации)
– «Х8» (ARN, acquirer reference number)
– «B3» (дата и время карточной операции)
– «t» и «u» (оригинальные сумма и валюта, т.е. в валюте операции)
– «I» и «a» (сумма и валюта расчётов с платёжной системой, т.е. сколько МПС списала с банка)
– «s» (название мёрчанта)
– «S» (адрес мёрчанта)
– «Q» (идентификатор терминала)
– «R» (платёжная сеть)
– «P» (MCC – merchant category code)
– «X2» (ID банка-эквайера)
– «!» (порядковый номер строки файла)
Ниже показан пример строки клирингового файла:
1. разделитель полей не показан, но на самом деле присутствует
2. показанные ниже две строки это на самом деле одна строка файла
33

34.

Повторная загрузка клиринга
• Случайный (ошибочный) повторный вызов ИНТ 6 для одного и того же файла – ошибка «фатальная», в
смысле последствий. Т.к. клиринговый файл содержит несколько тысяч строк, повторная загрузка
клиринга означает, что в Профайле будут ещё раз созданы несколько тысяч транзакций (возможно, их
будет чуть меньше, чем строк в файле, т.к. среди них могут попадаться полные отмены операций, а
повторная полная отмена для уже отменённой операции просто игнорируется). В любом случае
последствия будут катастрофическими – будут претензии клиентов, потребуются ручные урегулирования
• Если вдруг почему-либо такая ситуация возникла, нужно либо запрашивать вендора о подготовке т.н.
Data Fix-а, либо своими силами готовить исправительный клиринговый файл
• Для того, чтобы избежать повторной загрузки одного и того же файла, сейчас в Профайле
предусмотрены несколько контрольных проверок:
– Сочетание даты, платёжной сети, номера файла должно быть уникальным (примитивная
проверка, которая легко обходится переименованием файла, т.е. изменением номера)
– Контрольная сумма не должна повториться для файлов с любым номером (за конкретную дату и
по конкретной платёжной сети)
– Три операции из файла (первая, последняя, и находящаяся посередине файла) не должны
существовать в системе как ранее обработанные; если хоть одна из них найдена, файл
признаётся дубликатом – глубина просмотра архива операций настраивается
34

35.

Определение суммы транзакции
• При обработке клиринга используется подход, аналогичный тому, который используется при обработке
авторизаций.
• Если валюта оригинальной транзакции совпадает с валютой карты (напоминаю, карты мы
выпускаем в трёх валютах – RUB, USD, EUR), то со счета клиента списывается сумма в валюте
оригинальной транзакции
• В противном случае используется сумма, которую платёжная система списывается с банка – она
списывается со счета клиента (если необходимо, с конвертацией)
• Т.е. расчёты с платёжной системой ограничены тем же тремя валютами, то загруженных в
Профайл курсов конверсии (RUB<-->USD, RUB<-->EUR, USD<-->EUR) достаточно для обработки
Поля клиринга, участвующие в определении суммы транзакции по счету (карте)
t – сумма оригинальной транзакции (в валюте «u»)
u – валюта оригинальной транзакции
I (ай заглавная) – сумма в валюте «a»
a – валюта расчётов с платёжной системой
35

36.

Технический овердрафт
• Как было сказано ранее, при обработке клиринга Профайл не проверяет остаток по счету (ни доступный,
ни балансовый). Соответственно, если сумма транзакции по счёту превышает остаток по счету, в
результате проведения транзакции остаток по счету становится отрицательным
• Для банка это означает овердрафт (т.е. кредитование клиента средствами банка). В данном случае это
будет неразрешённый овердрафт (т.к. клиент не запрашивал у банка разрешение на использование
средств банка, в отличие от разрешённого овердрафта, который является отдельным банковским
продуктом) или технический овердрафт
• Для Профайла это означает не более, чем отрицательное значение остатка
• Профайл начисляет проценты на отрицательный остаток (в терминологии банка это пени за технический
овердрафт)
• Чаще всего технический овердрафт возникает из-за курсовой разницы: например, клиент совершил по
рублёвой карте покупку на 1000 USD. В момент авторизации курс был 50 RUB/USD, то есть на Профайл
проверил, что на счёте есть такая сумма (пусть там было 52 000 рублей) и повесил холд на 50 000 RUB.
Однако, в момент обработки клиринга курс был уже 55, то есть со счета было списано 55 000 рублей, в
результате чего возник технический овердрафт на 3000 рублей.
В приведённом примере размер овердрафта может
быть и больше, например, в случае, если после
покупки на 1000 USD клиент (пользуясь остатком в
2000 RUB на карте) сделает ещё какие-то покупки,
уменьшив доступный остаток по карте до нуля. В этом
случае после клиринга на счёте будет «-5000 рублей».
• Проводить клиринг по курсу авторизации банку не выгодно, потому что платёжная система спишет с
банка 1000 USD в дату клиринга (соответственно, списав с клиента только 52 000 рублей вместо 55 000
рублей банк будет вынужден отразить 3000 рублей как расходы банка по покрытию курсовой разницы)
• Поскольку для банка овердрафт означает кредитование клиента, требуется соответствующий
бухгалтерский учёт этой операции
• При возникновении технического овердрафта в Главной книге открывается ссудный счёт, на котором
отражается задолженность клиента перед банком
36

37.

Мэтчинг клиринга с авторизацией*
• При обработке клиринга Профайл по каждой карточной операции из файла формирует транзакцию по
счету. Однако, кроме этого он должен аннулировать холд, который был создан ранее при обработке
авторизационного запроса. Для поиска авторизационного запроса (и связанного с ним холда)
применяется процедура под названием мэтчинг (matching).
• При обработке прямой транзакции (т.е. A=1240) применятся следующий алгоритм мэтчинга:
– Если известно значение ExtRRN (поле «^»), тогда производится поиск авторизации по полям:
• номер карты (поле «E»), сравнение с полем CRDNUM таблицы ZAUTHDTL
• код операции (поле «C»), сравнение с полем TRNTYPE таблицы ZAUTHDTL
• external RRN (поле «^»), сравнение с полем EXTRRN таблицы ZAUTHDTL
– Если найдено более одного совпадения, то делается дополнительная проверка по полям:
• код авторизации (поле «m»), сравнение с полем AUTCODE таблицы ZAUTHDTL
• дата операции (поле «B3»), проверяется вхождение значения ZAUTHDTL.TRNMSDT в
диапазон от «B3 минус дельта», до «В3 плюс дельта» (значение «дельта» настраивается в
UTBLEXTINT.SRCHDAYS и указывается в днях)
– Если значение ExtRRN неизвестно, то поиск авторизации проводится по полям:
• номер карты (поле «E»)
• код операции (поле «C»)
• код авторизации (поле «m»)
• дата операции (поле «B3»)
(все проверки аналогичны описанным выше)
• Если в результате проверок не найдено единственное (!!!) совпадение, то считается, что мэтчинг не
совершён, т.е. не удалось найти единственную авторизацию для данного клиринга
• Если мэтчинг не совершён, то последствие единственное: холд (если он вообще был) не снимается**
* - ниже описан мэтчинг для прямой операции. Алгоритм мэтчинга для ревёрсала можно найти в документации на ИНТ 6
** - если авторизационный запрос на самом деле был, но не был найден в процессе мэтчинга, есть 2 варианта дальнейшего развития событий:
1) клиент обратится с претензией, и холд будет снят вручную. Примечание: при ручном снятии холда через Profile Direct ему устанавливается
expiration date, равная текущей дате; при этом холд считает истекшим и не учитывается при расчёте доступного остатка
2) истечёт срок действия холда, и тогда холд будет снят автоматически. Примечание: срок действия холда устанавливается на коде операции
в таблице UTBLEXTTRN1 (поиск нужной записи производится по INTRFACE=ISOATM и CODE=код операции)
37

38.

Клиринг по перевыпущенной карте
• Очевидно, что карта может быть перевыпущена (по инициативе клиента, который потерял или испортил
свою карту), либо в плановом порядке (потому что у карты наступила expiry date). В обоих случаях
возможна ситуация, когда клиент совершал операцию по карте незадолго до перевыпуска, и в момент
прихода клиринга у него на руках уже карта с другим номером.
• Для того, чтобы нормально обрабатывать такую ситуацию, в ИНТ 6 встроена дополнительная проверка:
если карта закрыта потому, что она перевыпущена (поле CRD.RPLCRD непустое), то статус карты
«закрыта» не является препятствием для обработки клиринга
• При этом, если транзакция не была ранее авторизована, будут уменьшены расходные лимиты уже по
новой карте. Фактически, карточная операция будет проведена уже по новой карте.
38

39.

Где и как хранится информация о карточных транзакциях (1 из 3)
Таблица карточных транзакций
• Когда мы говорили об авторизациях, то говорили о таблице ZAUTHDTL, в которой сохраняются
карточные транзакции. Действительно, если была авторизация, то логично ждать и клиринг (кроме
случая, когда авторизация была аннулирована ). То есть, в ZAUTHDTL можно у видеть все транзакции,
по которым была авторизация.
• Однако, в эту же таблицу записываются и те транзакции, у которых не было авторизации; но в этом
случае в колонку INTRFACE записывается значение «CRD_INC» (признак, когда создана запись)
• Каждой транзакции соответствует одна запись ZAUTHDTL (если была авторизация, то при обработке
клиринга новая запись создана не будет; за исключением случае, когда не удалось провести мэтчинг)
• Ниже приведены примеры записей в ZAUTHDTL
INTRFACE
AUTHID
CALDT
CALTM
MID
TRNTYPE
CRD_INC
ISOATM
ISOATM
637501159394760600110A
637502077255675201283A
637502202414638401385A
2015-07-17
2015-07-17
2015-07-17
03:13:13
05:46:12
06:07:04
1240
0100
0100
110
110
110
Календарная дата (создания записи)
Календарное время (создания записи)
Тип сообщения (1240 – сразу видно клиринг)
Код карточной транзакции (110 – покупка)
Сумма и валюта транзакции (оригинальные)
ORIGAMT
ORIGCRCD
31.00 USD
24.44 USD
139.48 USD
RSPCD
AUTMATCH
01
01
false
true
false
INCDATE
2015-07-17
2015-07-18
здесь пусто,
если запись
создал ИНТ 6
признак мэтчинга
дата проведения клиринга (или пусто)
В примерах выше:
• Строка 1 – транзакция создана ИНТ 6, т.е. в момент обработки клиринга (авторизации не было, либо же мэтчинг её не
смог найти); обратите внимание на поля INTRFACE и MID
• Строка 2 – транзакция создана ИНТ 5, т.е. по авторизационному запросу, позже была обработка клиринга (мэтчинг прошёл
успешно, авторизационный запрос был найден, в записи проставлено AUTMATCH=TRUE, а также дата клиринга); в полях
INTRFACE и MID сохранены значения, проставленные ИНТ 5
• Строка 3 – транзакция создана ИНТ 5, при этом клиринга либо ещё не было по данной операции, либо клиринг был, но
мэтчинг на нашёл авторизационный запрос); обратите внимание на пустое поле INCDATE и AUTMATCH=FALSE
ВАЖНО: выборку записей из таблицы ZAUTHDTL делают по номеру карты и диапазону дат (лучше по диапазону AUTHID), в
противном случае выборка будет формироваться очень долго (за день ZAUTHDTL растёт примерно на 100 000 записей)
39

40.

Где и как хранится информация о карточных транзакциях (2 из 3)
Таблица клиринговых записей
• Все клиринговые записи сохраняются в таблицу ZCRDINCD, причём вне зависимости от того, была ли их
обработка успешной (статус записи показывает поле CLRSTAT, расшифровку – см в ZSTBLCLRSTAT)
• Если обработка клиринговой записи была неуспешной, в поле ERRDESC указывается причина
• Поле REC таблицы ZCRDINCD содержит полностью всю строку клирингового файла
• Ниже приведены несколько примеров записей в ZCRDINCD, первые 2 колонки – номер карты и ID счёта
CRDNUM
CID
TJD
CLRSTAT ZMTI
ZTC
EXTRRN
AUTCODE TRNAMT TRNCRCD
4093XXXXXXXX7437 401002677468 2015-06-19
3
1240 110
000076070059 087736
4900.00 RUB
4093XXXXXXXX7437 401002677468 2015-06-19
1
1240 110
000076070059 087736
4900.00 RUB
4093XXXXXXXX7437 401002677468 2015-10-07
1
1240 110
096660
1250.00 RUB
4093XXXXXXXX7437 401002677468 2015-10-08
1
1240 110
093651
29121.00 RUB
4093XXXXXXXX7437 401002677468 2015-10-10
1
4240 110
093651
8611.00 RUB
4093XXXXXXXX7437 401002677468 2015-10-14
3
4240 110
093651
10966.00 RUB
Дата обработки клиринга
Статус записи (1=успешно, 3=ошибка)
Тип сообщения и код карточной операции
External RRN и код авторизации (если были указаны в клиринге)
Сумма и валюта транзакции (оригинальные)
ERRDESC
Cannot determine teller posting date
Transaction previously reversed
описание
ошибки
обработки
В примерах выше:
• Строки 1 и 2 – видно, что ИНТ 6 запускался дважды, первый раз неудачно (во время закрытия дня, ну либо закрытие дня
началось до того, как закончил работу ИНТ 6); со второй попытки клиринг был обработан
• Строка 3 – обработана клиринговая запись
• Строки 4,5,6 относятся к одной операции (видно по одинаковому значению AUTCODE, а также по одинаковому ARN,
который на картинке выше не показан); при этом 4я строка показывает прямую операцию (ZMTI=1240), а 5я и 6я –
ревёрсалы (ZMTI=4240), причём по сумме видно, что это частичные ревёрсалы. Поскольку по состоянию на октябрь 2015
Профайл не умеет обрабатывать множественные частичные ревёрсалы, 6я строка отклонена с ошибкой (не обработана).
Статус обработки виден в поле CLRSTAT, для 6й строки он содержит значение 3 (т.е. «rejected»)
Общее примечание: выборку из ZCRDINCD делают по номеру карты и диапазону дат
40

41.

Где и как хранится информация о карточных транзакциях (3 из 3)
Таблица HIST (история счёта)
• Все изменения, касающиеся счета (в т.ч. вызванные операциями по привязанной к счету карте,
сохраняются в таблицу HIST. Это одна из самых больших таблиц в системе, по состоянию на октябрь
2015 года её размер составляет 50 ГБ
• Все записи HIST по одному счету (поле CID) пронумерованы по порядку (поле TSEQ)
• Ниже приведён пример записей HIST, связанных с обработкой авторизации и клиринга
CID
TSEQ
CDT
TIME
401004024617 16
2015-07-24 18:43:49
401004024617 24
2015-07-27 11:57:44
401004024617 25
2015-07-27 11:57:44
TAMT ENDBAL
TCMT
SPR
TSO
ATMC#5278XXXXXXXX1225 ~ ATMD#63757 ~
ATMM#637576742998389229579A ~ ATMT#MUI ~
AUTCODE#015408 ~ TRNTYPE#POS ~ ZACQIID#888884 ~
Permanent hold
RETAILZAUTHMET#PIN ~ ZCHNL#POS-OTHER ~ ZDEVTYPE#NU ~
Sequence
001976740965 ZORIGAMT#885.6 ~ ZORIGCRCD#RUB ~ ZORIGFIN#NSPM ~
Number 7 added
ZPOSCAT#5983 ~ ZROLE#OWNER ~ ZSTG#751400-01 ~
ZTERMID#31897009 ~ ZTFEEFLG#1 ~ ZTRNMSDT#63757 ~
ZTRNTYPE#751400-01 ~ ZLIMITID#
401004024617,7
RETAIL[PHLD]EXPDT:
(значение здесь не показано с целью экономии места)
001976740965
63789:63760:::
RETAIL885.6 9059.62
(значение здесь не показано с целью экономии места)
001976740965
Дата/время записи
Сумма транзакции и балансовый остаток
Комментарий к операции**
ID карточной транзакции (присваивается Профайлом)
поле TSO для карточной операции содержит важную
информацию, извлечённую из авторизационного
запроса или из клиринга: номер карты (тэг ATMC), ID
сообщения (тэг AUTHID), код авторизации (AUTCODE),
сумму и валюту (ZORIGAMT и ZORIGCRCD) и т.п.
В примерах выше:
• Строка 1 – в результате обработки авторизационного запроса создан холд (таблица PHLD, CID = 401004024617, SEQ = 7)
• Строка 2 – срок действия холда изменён с 63789 на 63760 (т.е. с 25.08 на 27.07*), иными словами, hold помечен как expired
• Строка 3 – проведена транзакция по счету на сумму 885,60 (судя по TSEQ и TIME, одновременно со снятием холда)
Общее примечание: выборку из HIST делают по внутреннему ID счета (SELECT CID FROM DEP WHERE ZCONTRACT=…)
* - чтобы посмотреть даты в более читаемом виде, запросите в SELECTе два вычисляемых поля OLDV и NEWV, Профайл вернёт «25/08/2015» и «27/07/2015»
** - в общем случае показывается, что изменилось в состоянии счета; создание и аннулирование холда тоже являются изменениями по счету (потому что меняют
доступный остаток по счету); чтобы получить более читаемую информацию, запросите в SELECTе также вычисляемое поле DIDSC
41

42.

Дополнительно можно посмотреть: история карты
Таблица CRDHIST (история карты)
• Все изменения состояния карты сохраняются в таблицу CRDHIST. Однако, в отличие от таблицы HIST
для счетов, финансовые изменения сюда не попадают. Логируются только изменения самой карты.
• Ниже приведён пример записей*, связанных с выпуском неперсонифицированной карты
CRDNUM
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
5278XXXXXXXX1225
HSEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
TJD
TIME
TCMT
2015-07-06
2015-07-06
2015-07-06
2015-07-06
2015-07-06
2015-07-09
2015-07-09
2015-07-09
2015-07-22
2015-07-22
2015-07-22
2015-07-22
2015-07-22
2015-07-22
2015-07-22
2015-07-22
2015-07-22
2015-07-22
14:23:53
14:23:53
14:23:53
14:23:53
19:25:36
13:43:45
13:43:45
13:43:45
08:30:48
08:30:48
08:30:48
08:30:48
08:30:48
08:30:48
08:30:48
08:30:48
08:31:11
08:31:11
ZCRD (VTB24 Custom) created
Card created
[CRD]ZBOO::3142:::
[CRD]ZCC::18:::
[CRD]STAT:10:13:::
[ZCRD]ZRSNMSG::Карта выпущена:::
[CRD]ISDT::63742:::
[CRD]STAT:13:11:::
[CRD]ZBOO:3142::::
[CRD]ZCC:18::::
[CRD]ZBOO::3142:::
[CRD]ZCC::18:::
[CRD]ZLMTPLAN::COMMON1:::
[CRD]ACN:1545187:923648:::
[CRD]ZNAME:PIN:АБАШЕВ:::
[ZCRD]ZEXTCIFID::923648:::
[ZCRD]ZRSNMSG:Карта выпущена:Активация карты при выдаче:::
[CRD]STAT:11:1:::
Код отделения: «пусто» --> 3142
Код филиала: «пусто» --> 18
Статус «неактивна» --> «изготовление»
Комментарий к статусу
Дата выпуска «пусто» --> «09/07/2015»
Статус «изготовление» --> «LOCKED»
Код отделения: 3142 --> «пусто»
Код филиала: 18 --> «пусто»
Код отделения: «пусто» --> 3142
Код филиала: «пусто» --> 18
Установлен план лимитов
CARD RE-LINK (была на тех. клиенте)
Cardholder name
CIF ID держателя карты
Комментарий к статусу
Статус «LOCKED» --> «ACTIVE»
В таблице выше показаны 5 блоков с изменениями информации о карте (обведены зелёной рамкой)
• Блок 1 – вызов ИНТ 85 (генерация номеров неперсоницифрованных карт), в Профайле создан объект «карта»; при этом
карта автоматически привязывается к техническому счету/клиенту
• Блок 2 – вызов ИНТ 15 (выгрузка карт в Октопус для изготовления), карта имеет статус SENTPROD
• Блок 3 – вызов ИНТ 102 (изменение статуса), изготовление карты завершено, карта готова для выдачи клиенту
• Блок 4 – вызов ИНТ 86 (card re-link), карта отвязана от технического счета/клиента и привязана к реальному клиенту
• Блок 5 – вызов ИНТ 102 (изменение статуса), карта активирована
* - нужно отметить, что поле TCMT содержит информацию об изменении в следующем виде: в квадратных скобках название таблицы (CRD или ZCRD), затем имя
поля, затем через двоеточие - старое значение (которое может быть пустым), затем через двоеточие – новое значение. Статус карты обозначается числом,
расшифровку можно посмотреть в таблице UTBLCRDSTAT
42

43.

Главная книга*, Трансформер и Агрегатор (упрощенная схема)
Поскольку Профайл ничего
не знает о правилах Российского
бухгалтерского учёта, он выгружает
в Главную книгу* не проводки по
счетам, а так называемые события
(финансовые и аналитические),
которые нужно преобразовать в
нужные проводки. За это отвечают
Трансформер и Агрегатор.
* «Главная книга» - это модуль
банковской системы, который
отвечает за сбор и хранение
бухгалтерских записей, т.е.
проводок по счетам.
По состоянию на октябрь 2015
Главная книга ВТБ24 – Бисквит.
Задача Агрегатора – собрать «половинки» операций, полученные из разных систем, и «сложить» из них
требуемый набор проводок (в т.ч. по счетам межфилиальных расчётов). Агрегатор – один.
Задача Трансформера – преобразовать фин. события в системе Профайл в проводки, составленные по
правилам российского бухгалтерского учета; также отработать аналитические события (открытие счета,
изменение ставки и т.п.). Трансформеров столько же, сколько Бисквитов.
Примечание: технически, Трансформеров в два раза больше, потому что данные из Профайла и из Агрегатора поступают в разные Трансформеры
(Transformer-GL и Transformer-GLM), то есть, их по два на Бисквит; но это техническая тонкость, не влияющая на понимание принципов их работы.
43

44.

Управление выгрузкой событий в Главную книгу (1 из 3)
• Для управления выгрузкой событий в Главную книгу применяются следующие настройки:
– В таблице UTBLEXTTRN1 для каждого кода карточной операции присваивается соответствующий
код КБО (код банковской операции)
– В таблице ZUTBLTRNMAP для каждого кода КБО указывается, каким интерфейсом он
выгружается в Главную книгу*; их два – ИНТ 24 (GLPost) и ИНТ 111 (GLCrdPost):
• GLPost выгружает события, которые обрабатываются Трансформером
• GLCrdPost выгружается события, которые обрабатываются Агрегатором
ВАЖНО: события по
карточным операциям должны
быть выгружены именно в
Агрегатор, т.к. в общем случае
могут потребоваться и
межфилиальные расчёты, и
поиск второй «половинки»
операции, пришедшей из
системы Way4
• Алгоритм определения интерфейса следующий:
• По коду карточной операции определяется код КБО и признак (списание/зачисление)
• По коду КБО и признаку Дт/Кт (англ: Dr/Cr) определяется тип фин. события
Примечание: хорошо видно, что по операции 114 (возврат товара) тип фин. события указан
в строке напротив «1» (т.е. «Кт», «зачисление»), а по остальным – напротив «0» («Дт», «списание»)
ВАЖНО: в соответствии с технической реализацией вместо EVENT=GLCrdPost можно указывать
для «карточных» (!!!) КБО пустое значение. Обрабатываются эти значения одинаково.
* По-английски «главная книга» - «general ledger» или, сокращённо, «GL», поэтому интерфейсы, связанные с выгрузкой в Главную книгу содержат эти 2 буквы в
названии.
44

45.

Управление выгрузкой событий в Главную книгу (2 из 3)
• На предыдущем слайде было сказано, что по таблице UTBLEXTTRN1 каждому коду карточной операции
ставится в соответствие соответствующий код КБО (код банковской операции). Тут есть исключения.
• Есть ещё одна таблица, в которой эти исключения настраиваются – ZUTBLBTCTBL
• Код КБО определяется в зависимости от следующих атрибутов транзакции
– ZAUTHDTL.TRNTYPE, оно же P-3.1 (Transaction code)
– ZAUTHDTL.MERCHID, оно же Р-43.1 (Terminal Owner)
– ZAUTHDTL.ORIGFIN, оно же P-43.11 (Terminal Financial Institution Name)
– Интерфейс, который производит определение кода КБО
(допустимо значение «*», т.е. любой из «CRD_INC» и «ISOATM»)
ZINTRFACE
*
*
MERCHID
TC
ORIGFIN
BTC
SMS Notification 50
VB24
725004-04
SMS Notification 51
VB24
725004-04
Дополнительно обращаю внимание, что для КБО 725004-04 настройки в ZUTBLTRNMAP сделаны так, что
выгрузка событий производится в ИНТ 24, а не в ИНТ 111.
TRNTYPE
DRCR
EVENT
725004-04
0
GLPost
725004-04
1
45

46.

Управление выгрузкой событий в Главную книгу (3 из 3)
• По каждой карточной операции может быть установлена комиссия. О том, как рассчитывается комиссия,
было рассказано ранее, а сейчас поговорим о том, как настраивается выгрузка данных по комиссии в
Главную книгу
– В таблице ZUTBLTRNTYPE указывается связь КБО основной операции и КБО комиссии
– Отсутствие КБО означается, что выгрузка события не требуется (и даже если комиссия была
удержана, событие по её удержанию выгружено в Главную книгу не будет)
– Комиссии всегда выгружаются в Трансформер (ИНТ 24 или GLPost)
– Комментарий к событию (иногда именуемый «назначение платежа») указывается в таблице
UTBLEXTTRN1 в строке, соответствующей коду карточной операции
• По карточной операции
также может быть установлен
комментарий (поле ZTCMT в
таблице UTBLEXTTRN1), однако, не практике это не делается. При этом логика сервиса УСБС,
обрабатывающего выписку, настроена таким образом, что если поле комментарий не заполнено, сервис
возвращает данные из полей «название мёрчанта» и «адрес мерчанта» (что гораздо нужнее названия
операции, например, «снятие наличных»)
46

47.

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