Система централизованного справочника эталонных клиентских данных и способ объединения клиентских данных из учетных систем
Настоящее изобретение относится к области вычислительной техники, в частности к системе централизованного справочника эталонных клиентских данных и способу объединения клиентских данных из учетных систем. Технический результат заключается в обеспечении консолидации данных по корпоративным клиентам из различных информационных систем-источников банка, централизованного хранения, поддержании достоверной, актуальной и непротиворечивой информации и дальнейшем её оперативном распространении. Система централизованного справочника эталонных клиентских записей содержит: подсистему сбора первичных клиентских записей из информационных систем, выполненную с возможностью хранения по меньшей мере одной первичной клиентской записи в неизменяемом виде в базе данных; подсистему предобработки и валидации первичных клиентских записей, выполненную с возможностью валидации реквизитов по меньшей мере одной первичной клиентской записи по заранее заданным правилам; подсистему поиска дубликатов клиентских записей и формирования эталонных записей клиентов, выполненную с возможностью поиска дубликатов клиентских записей и формирования эталонных записей клиентов по заранее заданным правилам, подсистему распространения изменений по эталонным записям клиентов в системы-подписчики, выполненную с возможностью формирования нотификаций по каждой записи клиенту по факту создания или обновления клиентских записей и фильтрации потока распространения в зависимости от заранее установленных критериев; базу данных, выполненную с возможностью хранения по меньшей мере одной первичной клиентской записи в неизменяемом виде, а также эталонных записей клиентов и истории первичных записей. 2 н. и 7 з.п. ф-лы, 1 ил., 2 табл.
ОБЛАСТЬ ТЕХНИКИ
Настоящее изобретение относится к области вычислительной техники, в частности к системе централизованного справочника эталонных клиентских данных и способу объединения клиентских данных из учетных систем.
УРОВЕНЬ ТЕХНИКИ
Из уровня техники известно решение WO 2015149885 A1, 08.10.2015, в котором раскрыт способ запроса и обновления записей в базе данных. В данном решении описывается база данных, которая содержит основную структуру данных для хранения записей базы данных и структуру дельта-данных для хранения новых записей. Способ, включает в себя этапы, на которых осуществляется: получение множества запросов к базе данных, агрегирование принятого множества запросов к базе данных для получения пакета запросов к базе данных, выполнение совместного сканирования основной структуры данных с пакетом запросов базы данных, в котором записи базы данных в основной структуре данных запрашиваются относительно каждого запроса базы данных в пакете запросов базы данных, после этапа совместного сканирования, слияние основной структуры данных со структурой дельта-данных для обновления основной структуры данных с помощью новых полученных записей.
Из уровня техники известно еще одно решение, выбранное в качестве наиболее близкого аналога, RU 2409841 C2, 20.01.2011. В данном решении раскрыт способ актуализации информации в базах данных объектов управления автоматизированной системы управления. Способ заключается в том, что в административной части АСУ: вводят данные, требуемые объектам управления АСУ, проверяют введенные данные на соответствие типам данных полей таблиц сводной базы данных, если введенные данные соответствуют типам данных полей таблиц сводной базы данных, то результат проверки считают положительным, после чего данные сохраняют в сводной базе данных, а если введенные данные не соответствуют типам данных полей таблиц сводной базы данных, то результат проверки считают отрицательным и производят исправление данных в полях для ввода и их повторный ввод, после чего данные сохраняют в сводной базе данных, далее сохраненные данные учитывают и регистрируют время успешного проведения изменений, после чего формируют пакеты информации, содержащие необходимые каждому из объектов управления данные, с учетом структуры представления информации в базах данных клиентской части, сформированные пакеты информации учитывают, затем определяют возможный способ их доставки объектам управления, для этого формируют запрос конкретному объекту управления с целью контроля его к приему информации по локальной вычислительной сети (ЛВС) и отправляют этот запрос по ЛВС на клиентскую часть АСУ; далее в клиентской части АСУ: принимают по ЛВС выше сформированный запрос и подают его для аутентификации пользователя, в результате чего определяют готовность данного объекта управления к приему информации, если данный объект управления готов к приему информации, то по ЛВС обратно в административную часть передают квитанцию о готовности клиентской части к приему пакета информации по ЛВС; далее в административной части АСУ: получают по ЛВС квитанцию о готовности клиентской части к приему информации по ЛВС, производят распределение приоритетов пакетов для их отправки по ЛВС и присваивают пакету информации соответствующие служебные сведения - приоритет и контрольную сумму, затем пакет информации, дополненный служебными сведениями, отправляют по ЛВС на клиентскую часть; далее в клиентской части: получают дополненный служебными сведениями пакет информации и осуществляют проверку пригодности полученного к загрузке пакета, если пакет пригоден к загрузке, то его загружают в базу данных клиентской части, а если пакет не пригоден к загрузке, то отправляют квитанцию об ошибке на административную часть, при получении которой в административной части осуществляют повторное формирование пакетов информации для доведения их до объектов управления.
Приведенные выше известные из уровня техники решения направлены на решение проблем синхронизации, обновления и актуализации данных в информационных системах.
Однако, стоит отметить, что в известном уровне техники не обеспечивается единый унифицированный подход к хранению и использованию исходных данных. Основными отличиями предлагаемого технического решения от известных решений являются: уникальные алгоритмы валидации реквизитов в зависимости от статуса резидентства, категории клиента; логика расчета необходимых атрибутов, таких как статус резидентства, категория клиента, иерархический статус клиента; обеспечение возможности определять и обрабатывать «невалидные записи»; уникальные алгоритмы дедупликации клиентских записей в зависимости от статуса резидентства, категории клиента, иерархического статуса клиента; создание эталонного клиента и расчет всех атрибутов эталона в зависимости от уникальности атрибута, приоритета источника, времени обновления записи; алгоритм расчета типа корпоративного клиента в зависимости от наличия клиентских счетов; распространение изменений в системы-подписчики по факту создания/изменения клиентских данных.
Предлагаемое решение направлено на устранение недостатков современного уровня техники и отличается от известных ранее тем, что обеспечивает единство представления массива данных во всех информационных системах-подписчиках, содержит многокритериальные алгоритмы поиска дублей и предназначено для управления нормативно-справочной информацией.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Технической проблемой, на решение которой направлено заявленное решение, является создание системы централизованного справочника эталонных клиентских записей и способа формирования централизованного справочника эталонных клиентских записей из информационных систем, которые охарактеризованы в независимых пунктах формулы. Дополнительные варианты реализации настоящего изобретения представлены в зависимых пунктах изобретения.
Технический результат заключается в обеспечении консолидации данных по корпоративным клиентам из различных информационных систем-источников банка, централизованного хранения, поддержании достоверной, актуальной и непротиворечивой информации и дальнейшее её оперативное распространение. Дополнительный технический результат заключается в расширении арсенала технических средств изобретения.
Заявленные технические результаты достигаются за счет осуществления системы централизованного справочника эталонных клиентских записей, которая содержит:
подсистему сбора первичных клиентских записей из информационных систем, выполненную с возможностью хранения по меньшей мере одной первичной клиентской записи в неизменяемом виде в базе данных;
подсистему предобработки и валидации первичных клиентских записей, выполненную с возможностью валидации реквизитов по меньшей мере одной первичной клиентской записи по заранее заданным правилам;
подсистему поиска дубликатов клиентских записей и формирования эталонных записей клиентов, выполненная с возможностью поиска дубликатов клиентских записей и формирования эталонных записей клиентов по заранее заданным правилам;
подсистему распространения изменений по эталонным записям клиентов в системы-подписчики, выполненная с возможностью формирования нотификаций по каждой записи клиенту по факту создания или обновления клиентских записей и фильтрации потока распространения в зависимости от заранее установленных критериев;
базу данных, выполненную с возможностью хранения по меньшей мере одной первичной клиентской записи в неизменяемом виде, а также эталонных записей клиентов и истории первичных записей.
В частном варианте реализации описываемой системы, реквизиты первичных клиентских записей представляют собой по меньшей мере ИНН, ОГРН, КПП, ОКОПФ, ОКПО, SWIFT, БИК, страна регистрации, статус резидентства, категория корпоративного клиента, полное наименование клиента, краткое наименование клиента.
Заявленные результаты также достигаются за счет способа формирования централизованного справочника эталонных клиентских записей из информационных систем, который, в свою очередь, содержит этапы, на которых:
посредством подсистемы сбора первичных клиентских записей получают по меньшей мере одну первичную клиентскую запись из информационных систем;
посредством подсистемы предобработки и валидации первичных клиентских записей осуществляют валидацию по меньшей мере одного реквизита по меньшей мере одной первичной клиентской записи по заранее заданным правилам, причем валидация каждого реквизита по меньшей мере одной первичной клиентской записи проводится параллельно и для каждого реквизита реализовано свое правило, а также учитывается зависимость между реквизитами;
по результатам валидации проверяют наличие минимального состава реквизитов для проведения поиска дубликатов;
если клиентская запись не прошла валидацию, то создают или обновляют эталонную запись клиента в базе данных; если клиентская запись прошла валидацию, то осуществляют поиск дубликатов клиентских записей посредством сравнения реквизитов первичной клиентской записи с реквизитами всех имеющихся в системе первичных клиентских записей;
по результатам поиска дубликатов создают или обновляют эталонную запись клиента в базе данных, посредством переноса реквизитов на эталонную запись клиента со всех клиентских записей по заранее заданным правилам;
осуществляют распространение изменений эталонных записей клиента в системы - подписчики, формируя нотификации по каждому клиенту по факту создания или обновления клиентских записей и фильтрации потока распространения в зависимости от заранее установленных критериев посредством подсистемы распространения изменений по эталонным клиентам в системы-подписчики.
В частном варианте реализации описываемого способа, получают первичные клиентские записи посредством онлайн интеграции через веб-сервисы и очереди сообщений.
В другом частном варианте реализации описываемого способа, реквизиты первичных клиентских данных представляют собой по меньшей мере ИНН, ОГРН, КПП, ОКОПФ, ОКПО, SWIFT, БИК, страна регистрации, статус резидентства, категория корпоративного клиента, полное наименование клиента, краткое наименование клиента.
В другом частном варианте реализации описываемого способа, минимальный набор реквизитов зависит от статуса резидентства, категории корпоративного клиента, иерархического статуса.
В другом частном варианте реализации описываемого способа, на этапе создания эталонной записи в базе данных, если не найдено ни одной существующей эталонной записи, то создают эталонную запись, если же эталонная запись найдена, то создают связь клиентской записи с существующей эталонной записью.
В другом частном варианте реализации описываемого способа, правила переноса реквизитов на эталонную запись клиента со всех клиентских записей меняются если реквизиты являются одиночными или множественными.
В другом частном варианте реализации описываемого способа, при отсутствии обязательного атрибута в реквизитах клиентской записи, то по заранее заданным правилам создают обязательные атрибуты из дополнительных.
ОПИСАНИЕ ЧЕРТЕЖЕЙ
Реализация изобретения будет описана в дальнейшем в соответствии с прилагаемыми чертежами, которые представлены для пояснения сути изобретения и никоим образом не ограничивают область изобретения. К заявке прилагаются следующие чертежи:
Фиг.1, иллюстрирует общую схему реализации изобретения.
ДЕТАЛЬНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
В приведенном ниже подробном описании реализации изобретения приведены многочисленные детали реализации, призванные обеспечить отчетливое понимание настоящего изобретения. Однако, квалифицированному в предметной области специалисту, будет очевидно каким образом можно использовать настоящее изобретение, как с данными деталями реализации, так и без них. В других случаях хорошо известные методы, процедуры и компоненты не были описаны подробно, чтобы не затруднять излишне понимание особенностей настоящего изобретения.
Кроме того, из приведенного изложения будет ясно, что изобретение не ограничивается приведенной реализацией. Многочисленные возможные модификации, изменения, вариации и замены, сохраняющие суть и форму настоящего изобретения, будут очевидными для квалифицированных в предметной области специалистов.
Настоящее техническое решение обеспечивает унифицированный подход к хранению исходных данных, содержит многокритериальные алгоритмы поиска дублей и предназначено для управления нормативно-справочной информацией, обеспечивая единство представления массива данных во всех информационных системах-подписчиках. Следует отметить, что под системами-подписчиками понимаются внешние системы, подписанные на создание/обновление данных о клиентах в эталонном справочнике клиентов.
Также, следует отметить, что каждый элемент в системе может выступать в виде независимого блока, структура и поведение которого подчиняются определённым правилам. При этом, каждая подсистема может быть реализована в качестве функционального элемента. На фиг. 1 продемонстрированы основные подсистемы, входящие в систему централизованного справочника эталонных клиентских данных, с указанием последовательности проводимых проверок.
Система централизованного справочника эталонных клиентских данных состоит из следующих основных подсистем:
подсистема сбора первичных клиентских записей из систем-источников;
подсистема предобработки и валидации первичных клиентских записей;
подсистема поиска дубликатов и формирования эталонных клиентов;
подсистема распространения изменений по эталонным клиентам в системы-подписчики.
В рамках указанных подсистем выделяются следующие ключевые технические особенности.
Подсистема сбора первичных клиентских записей из систем-источников обеспечивает:
получение первичных клиентских записей вне зависимости от типа интеграции с системой-источником;
хранение первичных клиентских записей в неизменном виде;
ведение истории изменения первичных записей из систем-источников.
Подсистема предобработки и валидации первичных клиентских записей обеспечивает:
валидацию реквизитов первичных клиентских записей по уникальным правилам для каждого атрибута записи в зависимости от количества символов, категории клиента, статуса резидентства и т.д.;
проведение всех проверок реквизитов параллельно, учитывая зависимости между реквизитами и реализуя кросс-проверки;
расчет ряда обязательных атрибутов: статус резидентства, категория клиента, иерархический статус клиента;
логику расчета признаков «Невидимый клиент», «Невалидный клиент», при этом указанная логика меняется в зависимости от статуса резидентства и категории клиента.
Подсистема поиска дубликатов и формирования эталонных клиентов обеспечивает:
уникальные правила поиска дубликатов клиентских записей в зависимости от: статуса резидентства; категории клиента; иерархического статуса;
уникальные правила создания эталонных клиентов в зависимости от: признака «валидности» клиентской записи; отсутствия эталонного клиента; наличия существующего эталонного клиента, связанного с одной клиентской записью; наличия существующего эталонного клиента, связанного с несколькими клиентскими записями;
правила переноса реквизитов с клиентских записей на эталонных клиентов;
расчет типа корпоративного клиента при сборке эталонной записи;
определение связи между филиалом и головной организацией при сборке эталонной записи.
Подсистема распространения изменений по эталонным клиентам в системы-подписчики обеспечивает:
формирование нотификаций по каждому эталонному клиенту по факту создания/изменения клиентских данных;
фильтрацию потока распространения в зависимости от бизнес-критериев.
Способ объединения клиентских данных из учетных систем реализуется исходя из основных этапов жизненного цикла данных клиента, и состоит из следующих основных этапов:
создание/изменение записи о клиенте в системе-источнике;
импорт созданной/измененной записи из системы-источника;
создание/обновление эталонной записи о клиенте на основе дедупликации первичных записей;
распространение созданной/обновленной эталонной записи о клиенте в системы-подписчики.
Для получения первичных клиентских записей используются 2 основных способа интеграции:
онлайн интеграция через web-сервисы и очереди сообщений. Обновление данных происходит по факту изменения в системе-источнике;
квази-онлайн интеграция - репликация инкремента изменений по расписанию.
При этом все первичные записи хранятся без изменений.
Важным этапом перед сборкой эталонного клиента является валидация реквизитов первичной записи (ИНН, ОГРН, КПП, ОКОПФ, ОКПО, SWIFT, БИК, страна регистрации, статус резидентства, категория корпоративного клиента, наименование клиента (полное/краткое)). Основным принципом проверки реквизитов является проведение всех проверок параллельно, учитывая зависимости между реквизитами и реализуя кросс-проверки.
Если реквизит пустой или состоит из пробельных символов, то проверка данного реквизита не выполняется. Если реквизит не прошел проверку, дальше в обработке он участвует как пустой. Для валидации каждого атрибута существуют индивидуальные правила в зависимости от количества символов, категории клиента, статуса резидентства и т.д.
В качестве примера, ниже представлен алгоритм валидации атрибута ИНН:
В зависимости от статуса резидентства различны правила валидации ИНН. Если статус резидентства = Резидент, то выполняются следующие проверки:
1. В первую очередь ИНН проверяется на количество символов:
a. Для ИП = 12 символов, если количество символов не равно 12, ИНН является некорректным;
b. Для ЮЛ = 10 символов, если количество символов не равно 10, ИНН является некорректным;
2. Далее ИНН проверяется на формат: строго числовой. Если в ИНН указаны любые символы, кроме цифр, то ИНН является некорректным;
3. Проверка на «0»
a. Если сумма с 5-9 цифр равно нулю для длины 10 - ИНН является некорректным
b. Если ИНН состоит только из «0» - ИНН является некорректным
c. Если первые два символа «00» - ИНН является некорректным
4. Проверка ИНН на контрольное число
Проверка контрольной суммы (Символ имеющий порядковый номер N в ИНН обозначается как "ИНН[N]" ):
a. Для ИНН длиной = 10:
ИНН[10] должен быть равен (( (2*ИНН[1] + 4*ИНН[2] + 10*ИНН[3] + 3*ИНН[4] + 5*ИНН[5] + 9*ИНН[6] + 4*ИНН[7] + 6*ИНН[8] + 8*ИНН[9]) MOD 11 ) MOD 10)
Если равен, то ИНН корректен
b. Для ИНН длиной = 12:
ИНН[11] должен быть равен (( (7*ИНН[1] + 2*ИНН[2] + 4*ИНН[3] + 10*ИНН[4] + 3*ИНН[5] + 5*ИНН[6] + 9*ИНН[7] + 4*ИНН[8] + 6*ИНН[9] + 8*ИНН[10]) MOD 11 ) MOD 10)
Если равен, то проверить ИНН[12]:
ИНН[12] должен быть равен (( (3*ИНН[1] + 7*ИНН[2] + 2*ИНН[3] + 4*ИНН[4] + 10*ИНН[5] + 3*ИНН[6] + 5*ИНН[7] + 9*ИНН[8] + 4*ИНН[9] + 6*ИНН[10] + 8*ИНН[11]) MOD 11 ) MOD 10)
Если равен, то ИНН корректен
c. Во всех остальных случаях ИНН некорректен.
Если Статус резидентства = Нерезидент, то в данном случае валидируется TIN в зависимости от «Страны регистрации», например для Страны регистрации = Испания TIN валидируется по маске: L99999999 - Латинская буква (A,B,C,D,E,F,G,H,J,P,Q,S,U,V) + 7 цифр + 1 цифра (или 1 буква).
Ряд следующих атрибутов автоматически рассчитываются в процессе проверки:
• Статус резидентства по входным параметрам: Страна регистрации, статус резидентства, ОГРН;
• Категория корпоративного клиента по параметрам: ИНН, ОГРН, категория корпоративного клиента первичной записи, ОКОПФ, наименование клиента на русском и английском языках, БИК;
• Иерархический статус по входным параметрам: КПП, ОКОПФ, SWIFT, наименование клиента на русском и английском языках, категория корпоративного клиента,
Соответственно в расчете используются только непустые реквизиты, алгоритмы уникальны для каждого атрибута.
В качестве примера, ниже алгоритм расчета Статуса резидентства:
1. Атрибут «Страна регистрации» проверяется на корректность и соответствие Справочнику стран по стандарту ISO:
a. Если указана страна «Россия» - автоматически клиенту присваивается статус резидентства - «Резидент»
b. Если страна указана, соответствует Справочнику стран по стандарту ISO и не «Россия», итоговый статус резидентства - «Нерезидент»
c. Если страна не указана или указана некорректно (код не соответствует справочнику стран по стандарту ISO) - проверяется наличие заполненного Статуса резидентства (см. п.2)
2. Проверяется атрибут «Статус резидентства»:
a. Если «Статус резидентства» = Резидент, итоговый статус резидентства устанавливается как «Резидент», а в атрибут «Страна регистрации» записывается значение «Россия»
b. Если «Статус резидентства» = Нерезидент, в атрибут «Страна регистрации» ничего не записывается
c. Если «Статус резиденства» не указан, проверяется наличие заполненного атрибута ОГРН
3. Проверяется атрибут «ОГРН»:
a. Если ОГРН валидный, соответственно итоговый Статус резидентства устанавливается = Резидент, а в атрибут «Страна регистрации» записывается значение «Россия»
b. Если ОГРН невалидный или не указан, то итоговый статус резидентства считается неопределенным, значение не присваивается.
После валидации первичная запись проверяется на наличие минимально необходимого состава реквизитов для участия в поиске дубликатов. Минимальный набор реквизитов различен в зависимости от статуса резидентства, категории корпоративного клиента- иерархического статуса (Филиал/Головная организация). В таблице 1 приведены примеры минимальных наборов обязательных реквизитов для категорий клиентов и их статуса резиденства.
Таблица 1
| Статус резиденства | Категория корпоративного клиента | Минимальный набор обязательных реквизитов |
| Резидент | Юридическое лицо/ Кредитная орган изация | Головная организация: • Наименование • ИНН (или) ОГРН Филиал: • Наименование • ИНН (или) ОГРН • КПП (или) ОКПО (или) SWIFT |
| Индивидуальный предприниматель/ГКФХ | • Наименование • ИНН (или) ОГРНИП |
|
| Адвокаты/Нотариусы | • Наименование • ИНН |
|
| Нерезидент | Юридическое лицо/ Кредитная организация | Головная организация: • Наименование • Страна резидентства Филиал: • Наименование • Страна резидентства • КПП (или) ОКПО (или) SWIFT |
Заявленное решение по созданию, поддержанию в актуальном состоянии единого централизованного справочника эталонных клиентских данных юридических лиц представляет собой систему, позволяющую обеспечить полноту, унификацию и непротиворечивость информации о клиентах во всех учетных системах банка.
Формирование эталонных записей корпоративных клиентов осуществляется на основании первичных клиентских записей, полученных из систем-источников.
Цикл данных клиента состоит из следующих этапов:
• Создание/изменение клиента в системе-источнике;
• Импорт созданной/измененной записи из системы-источника;
• Создание/обновление эталонного клиента на основе дедубликации первичных записей;
• Распространение созданного/обновленного эталонного клиента в системы-подписчики.
Как отмечалось ранее, для получения первичных клиентских записей используются 2 основных способа интеграции:
Онлайн интеграция через web-сервисы и очереди сообщений. Обновление данных происходит по факту изменения в системе-источнике;
Пример web-сервиса и очереди сообщений:
Сервис получения первичной записи. Основное назначение сервиса - добавление/обновление первичной записи. При получении сообщения в сервисе происходит валидация предоставленного xml-сообщения по xsd-схеме. В случае успешной валидации сообщение попадает в очередь RabbitMQ. Далее сообщения разбирает Сервис адаптер первичных записей, который в свою очередь также валидирует данные на консистентность, целостность, непротиворечивость и сохраняет первичные записи в базу данных.
• Квази-онлайн интеграция - репликация инкремента изменений по расписанию.
При этом, все первичные записи хранятся без изменений.
В случае если выявлено, что у первичной записи недостаточно реквизитов, то запись передается в подсистему поиска дубликатов и формирования эталонных клиентов с признаком «Невалидная», дополнительно фиксируются все ошибки, сформированные в ходе процедуры валидации и проверки на достаточность реквизитов. Также в процессе валидации рассчитывается признак «Невидимого клиента», который проставляется для специально созданных технических клиентов, не участвующих в процессе дедубликации.
Основным процессом по созданию и поддержанию в актуальном состоянии справочника эталонных клиентов является процесс дедубликации. Дедубликация в свою очередь представляет собой процедуру сравнения реквиз итов первичной клиентской записи с реквизитами всех имеющихся в системе первичных клиентских записей.
Правила поиска дубликатов отличаются в зависимости от рассчитанных параметров: статуса резидентства, категории корпоративного клиента, иерархического статуса. В таблице 2 перечислены примеры возможных параметров для применения правил:
Таблица 2
| № | Статус резидентства | Категория клиента | Иерархический статус |
| 1 | Резиденты | Юридические лица/ кредитные организации | головные организации |
| 2 | Резиденты | Юридические лица/ кредитные организации | филиалы |
| 3 | Резиденты | Индивидуальные предприниматели / Адвокаты / Нотариусы / Главы крестьянско-фермерского хозяйства | |
| 4 | Нерезиденты |
Суть алгоритма проверки заключается в поиске дубликатов через «ИЛИ» всех первичных клиентских записей по ИНН и ОГРН, за исключением записей с признаками «Невалидный», «Невидимый», «Конфликтная запись». В случае незаполненных атрибутов ИНН «ИЛИ» ОГРН имеется система подсчета совпадающих заполненных дополнительных реквизитов, таких как Наименование клиента на русском и английском языках (полное/краткое), КПП, ОКПО, БИК, SWIFT.
Важной составляющей в процессе дедубликации является сравнение категорий корпоративного клиента и иерархических статусов записей. Данные параметры должны быть идентичными.
При этом, необходимо отметить следующее:
1) при дедубликации нерезидентов дополнительными реквизитами для сравнения являются: страна резидентства, КИО (Код иностранной организации);
2) сравнение наименований происходит по следующему алгоритму:
a. наименования приводятся к одному регистру
b. наименования очищаются от спецсимволов
c. из наименований удаляются опф (организационно-правовая форма) и слова-индикаторы филиала (например, слова «Филиал», «Представительство» и т.д.).
d. в зависимости от количества символов в наименовании процент совпадения для того, чтобы признать наименования совпавшими, различен
e. сравнению подлежат как короткие, так и полные наименования клиентов.
Итогом процесса дедубликации является первичная клиентская запись и коллекция клиентских записей, определенных как дубликаты рассматриваемой записи.
Следующим этапом в формировании единого централизованного справочника эталонных клиентских данных юридических лиц является создание эталонной записи в базе данных. В случае если не найдено ни одного существующего эталона, то создается новый эталон, если же эталон найден - то создается связь клиентской записи с существующим эталоном.
Алгоритм создания является автоматическим и включает в себя процессы создания эталона в зависимости от признака «валидности» клиентской записи:
1) Запись является невалидной, невидимой или конфликтной
a. При поиске не найдено ни одного существующего эталона - создается новый эталон
b. При поиске найден эталон с одной записью - эталон обновляется данными первичной записи
c. При поиске найден эталон с несколькими первичными записями - запись отвязывается от эталона и создается новый эталон, по оставшимся записям происходит пересборка эталона
2) Запись является валидной
a. При поиске не найдено ни одного существующего эталона - создается новый эталон
b. При поиске найден 1 эталон, и все первичные записи входят в коллекцию дубликатов - происходит обновление атрибутов эталона. Весь массив клиентских записей, определенных как дубликаты, привязывается к данному эталону, реквизиты пересобираются по правилам, описанным ниже;
c. При поиске найден 1 эталон, у которого имеются первичные записи, не входящие в коллекцию дубликатов. В данном случае первичные записи, определенные как дубликаты, остаются привязанными к эталону, причем происходит обновление его атрибутов, а записи, не входящие в коллекцию дубликатов, отвязываются от эталона и отправляются на дедубликацию, в результате чего собирается еще один эталон.
d. При поиске найдено несколько эталонов, то из перечня выбирается эталон с самой ранней датой создания и далее алгоритм b или c. При этом если в эталоне не остается больше первичных клиентских записей, то эталон удаляется, создается запись в истории, что данный эталон полностью включен в другой.
Важным этапом в создании эталона является перенос реквизитов на эталон со всех клиентских записей. Правила переноса меняются в зависимости от того являются реквизиты одиночными, либо множественными.
Если реквизиты одиночные, такие как ИНН, ОГРН, КПП, КИО, ОКТМО, ОКАТО и другие, то учитывается приоритет системы-источника, то есть даже если записей с высоким приоритетом больше одной, то выбирается тот реквизит, значение которого имеется в большем количестве первичных клиентских записей с максимальным приоритетом. Если же приоритеты по всем записям совпадают, то учитывается дата обновления реквизита - выбирается значение с самой последней датой обновления.
Исключительной обработке подлежат следующие реквизиты: Дата регистрации (учитывается самая ранняя дата); КПП (значение, начинающееся на «99», не учитывается и записывается в реквизит largeKPP (КПП крупного налогоплательщика)); Статус резидентства, Страна резидентства, категория корпоративного клиента, иерархический статус (данные реквизиты берутся с любой записи, так как уже определены в ходе этапа валидации первичной записи).
Множественными реквизитами у первичной записи являются контакты, адреса, различные документы. На эталон переносятся все неповторяющиеся контакты, адреса и документы переносятся по одной записи каждого типа, если записей с одинаковым типом больше одного, то выбирается наиболее приоритетная запись (у которой выше приоритет системы-источника) и максимальная степень заполнения. Приоритет системы-источника может быть изменен в зависимости от требований и регулируется администратором системы.
Одной из ключевых особенностей алгоритма создания эталона и переноса атрибутов на эталон, является расчет типа корпоративного клиента и определение связи между филиалом и головной организацией:
1. Тип корпоративного клиента вычисляется на основе данных по счетам клиентских записей, привязанных к эталонному клиенту.
Например:
Тип клиента = «Клиент», если к эталонному клиенту привязано более 1 открытого клиентского счета;
Тип клиента = «Бывший клиент», если у эталонного клиента отсутствуют открытые клиентские счета, но имеются закрытые;
2. При каждом создании/ обновлении эталона происходит определение связи между филиалами и головными организациями. Поиск ведется только для видимых и валидных эталонов среди видимых и валидных эталонов по ИНН или ОГРН. Обновление/привязка головной организации может поменять привязку для других головных организаций.
Завершающим этапом после сборки эталонного клиента является распространение изменений в системы-подписчики. Основной способ интеграции: online-интеграция (очереди сообщений, web-сервисы и т.д.) с распространением изменений по факту изменения в текущей системе по управлению данными корпоративных клиентов. Нотификации формируются по каждому эталонному клиенту по факту создания/изменения эталонных клиентских данных. Реализована возможность фильтрации потока распространения в зависимости от бизнес-критериев. Бизнес-критерии формируются для каждой системы-подписчика индивидуально.
Заявленное решение реализуется посредством вычислительного устройства, которое имеет возможность обеспечивать необходимую обработку данных.
В общем случае устройство содержит такие компоненты, как: один или более процессоров, по меньшей мере одну память, средство хранения данных, интерфейсы ввода/вывода, средство В/В, средства сетевого взаимодействия.
Процессор устройства выполняет основные вычислительные операции, необходимые для функционирования устройства или функциональности одного или более его компонентов. Процессор исполняет необходимые машиночитаемые команды, содержащиеся в оперативной памяти.
Память, как правило, выполнена в виде ОЗУ и содержит необходимую программную логику, обеспечивающую требуемый функционал.
Средство хранения данных может выполняться в виде HDD, SSD дисков, рейд массива, сетевого хранилища, флэш-памяти, оптических накопителей информации (CD, DVD, MD, Blue-Ray дисков) и т.п. Средство позволяет выполнять долгосрочное хранение различного вида информации, например, вышеупомянутых файлов с наборами данных пользователей, базы данных, содержащих записи измеренных для каждого пользователя временных интервалов, идентификаторов пользователей и т.п.
Интерфейсы представляют собой стандартные средства для подключения и работы с серверной частью, например, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire и т.п.
Выбор интерфейсов зависит от конкретного исполнения устройства, которое может представлять собой персональный компьютер, мейнфрейм, серверный кластер, тонкий клиент, смартфон, ноутбук и т.п.
В качестве средств В/В данных в любом воплощении системы, реализующей описываемый способ, должна использоваться клавиатура. Аппаратное исполнение клавиатуры может быть любым известным: это может быть, как встроенная клавиатура, используемая на ноутбуке или нетбуке, так и обособленное устройство, подключенное к настольному компьютеру, серверу или иному компьютерному устройству. Подключение при этом может быть, как проводным, при котором соединительный кабель клавиатуры подключен к порту PS/2 или USB, расположенному на системном блоке настольного компьютера, так и беспроводным, при котором клавиатура осуществляет обмен данными по каналу беспроводной связи, например, радиоканалу, с базовой станцией, которая, в свою очередь, непосредственно подключена к системному блоку, например, к одному из USB-портов. Помимо клавиатуры, в составе средств В/В данных также может использоваться: джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор мышь, трекбол, световое перо, динамики, микрофон и т.п.
Средства сетевого взаимодействия выбираются из устройства, обеспечивающий сетевой прием и передачу данных, например, Ethernet карту, WLAN/Wi-Fi модуль, Bluetooth модуль, BLE модуль, NFC модуль, IrDa, RFID модуль, GSM модем и т.п. С помощью средств обеспечивается организация обмена данными по проводному или беспроводному каналу передачи данных, например, WAN, PAN, ЛВС (LAN), Интранет, Интернет, WLAN, WMAN или GSM.
Компоненты устройства сопряжены посредством общей шины передачи данных.
В настоящих материалах заявки было представлено предпочтительное раскрытие осуществление заявленного технического решения, которое не должно использоваться как ограничивающее иные, частные воплощения его реализации, которые не выходят за рамки испрашиваемого объема правовой охраны и являются очевидными для специалистов в соответствующей области техники.
1. Система централизованного справочника эталонных клиентских записей, содержащая:
подсистему сбора первичных клиентских записей из информационных систем, выполненную с возможностью хранения по меньшей мере одной первичной клиентской записи в неизменяемом виде в базе данных;
подсистему предобработки и валидации первичных клиентских записей, выполненную с возможностью валидации реквизитов по меньшей мере одной первичной клиентской записи по заранее заданным правилам;
подсистему поиска дубликатов клиентских записей и формирования эталонных записей клиентов, выполненную с возможностью поиска дубликатов клиентских записей и формирования эталонных записей клиентов по заранее заданным правилам;
подсистему распространения изменений по эталонным записям клиентов в системы-подписчики, выполненную с возможностью формирования нотификаций по каждой записи клиенту по факту создания или обновления клиентских записей и фильтрации потока распространения в зависимости от заранее установленных критериев;
базу данных, выполненную с возможностью хранения по меньшей мере одной первичной клиентской записи в неизменяемом виде, а также эталонных записей клиентов и истории первичных записей.
2. Система по п.1, отличающаяся тем, что реквизиты первичных клиентских записей представляют собой по меньшей мере ИНН, ОГРН, КПП, ОКОПФ, ОКПО, SWIFT, БИК, страну регистрации, статус резидентства, категорию корпоративного клиента, полное наименование клиента, краткое наименование клиента.
3. Способ формирования централизованного справочника эталонных клиентских записей из информационных систем, содержащий этапы, на которых:
посредством подсистемы сбора первичных клиентских записей получают по меньшей мере одну первичную клиентскую запись из информационных систем;
посредством подсистемы предобработки и валидации первичных клиентских записей осуществляют валидацию по меньшей мере одного реквизита по меньшей мере одной первичной клиентской записи по заранее заданным правилам, причем валидация каждого реквизита по меньшей мере одной первичной клиентской записи проводится параллельно и для каждого реквизита реализовано свое правило, а также учитывается зависимость между реквизитами;
по результатам валидации проверяют наличие минимального состава реквизитов для проведения поиска дубликатов;
если клиентская запись не прошла валидацию, то создают или обновляют эталонную запись клиента в базе данных; если клиентская запись прошла валидацию, то осуществляют поиск дубликатов клиентских записей посредством сравнения реквизитов первичной клиентской записи с реквизитами всех имеющихся в системе первичных клиентских записей;
по результатам поиска дубликатов создают или обновляют эталонную запись клиента в базе данных посредством переноса реквизитов на эталонную запись клиента со всех клиентских записей по заранее заданным правилам;
осуществляют распространение изменений эталонных записей клиента в системы-подписчики, формируя нотификации по каждому клиенту по факту создания или обновления клиентских записей и фильтрации потока распространения в зависимости от заранее установленных критериев посредством подсистемы распространения изменений по эталонным клиентам в системы-подписчики.
4. Способ по п.3, отличающийся тем, что получают первичные клиентские записи посредством онлайн-интеграции через веб-сервисы и очереди сообщений.
5. Способ по п.3, отличающийся тем, что реквизиты первичных клиентских данных представляют собой по меньшей мере ИНН, ОГРН, КПП, ОКОПФ, ОКПО, SWIFT, БИК, страну регистрации, статус резидентства, категорию корпоративного клиента, полное наименование клиента, краткое наименование клиента.
6. Способ по п.3, отличающийся тем, что минимальный набор реквизитов зависит от статуса резидентства, категории корпоративного клиента, иерархического статуса.
7. Способ по п.3, отличающийся тем, что на этапе создания эталонной записи в базе данных, если не найдено ни одной существующей эталонной записи, то создают эталонную запись, если же эталонная запись найдена, то создают связь клиентской записи с существующей эталонной записью.
8. Способ по п.3, отличающийся тем, что правила переноса реквизитов на эталонную запись клиента со всех клиентских записей меняются, если реквизиты являются одиночными или множественными.
9. Способ по п.3, отличающийся тем, что при отсутствии обязательного атрибута в реквизитах клиентской записи по заранее заданным правилам создают обязательные атрибуты из дополнительных.
