Оформите запрос на демонстрацию системы

Мы свяжемся с вами в течение одного рабочего дня, чтобы определить ваши потребности и удобный формат демонстрации системы DIRECTUM:

Заказать демонстрацию

По вопросам выбора и приобретения:
present@directum.ru
+7 (341) 272-11-00

Вверх
@DIRECTUMCompany:   Пожалуйста, подождите, загружаем данные из twitter...

Организация адресного реестра в системе DIRECTUM

Иерархический адресный реестр состоит из двух основных понятий: Адресный элемент и Адресный реестр.

Структура адресного реестра Структура адресного реестра

Адресный элемент – это линейно-образующий элемент в цепочки построения адреса. К адресному элементу также относится Вид адресного элемента.

Поясним на примере. "Улица Ленина", где "Улица" – это вид адресного элемента, а "Ленина" – непосредственно сам адресный элемент. У адресного элемента есть понятие Признак адресного элемента. Он характеризует, является ли адресный элемент образующим адресный реестр или нет. Например, "Респ. Башкортостан" – является не образующим элементов. То есть адрес не может быть вида "Респ. Башкортостан д. 180-3". "Улица" – является образующим адресным элементом. Образующим адресным элементом может быть и деревня, село, поселок в силу малонаселенности при отсутствии улиц.

Адресный реестр – это совокупность адресных элементов с адресной информацией о расположении. Например, "РФ Респ. Башкортостан г.Уфа ул. Малая Кольцевая д. 180-3".

Компонента "Адресный реестр" состоит из справочников:

  • Адрес;
  • Вид адреса;
  • Адресный элемент;
  • Вид адресного элемента;
  • Фильтр поиска адреса.

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

  • Персоны;
  • Организации.

Возможности

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

  1. Качество данных вводимой информации. Без структуризации операторами могут допускаться ошибки формирования наименования. Например, полное наименование улицы – "Улица Мажита Гафури". Однако оно может некорректно записываться и как "М. Гафури". Такая информация в текстовом поле усложняет поиск данных и проверки дубликатов. При этом практически отсутствуют инструкции по унифицированному вводу адресных данных.
  2. Разграничение прав ведения адресных данных. Текстовые поля не позволяют разграничивать права доступа. Зарекомендовавшая себя схема – выделение улиц, городов и т.д. в отдельные справочники – позволяет вести сами наименования ответственным оператором или администратором, а адреса – обычным пользователям. Это устраняет проблему корректности наименований.
  3. Адресная информация не является прямой информацией объекта. Как правило, наименования улиц выносятся в справочник, а адресная информация о расположении находится у объекта. Это проблематично, если у персоны более одного адреса или у организации не совпадают почтовый и юридический адрес.
  4. Неконтролируемое распространение адресной информации. Например, несколько персон проживает по одному адресу. Если не выделять адресный реестр, у каждого человека будет "свой" адрес, хотя в действительности адрес один и тот же (если оператор вводит все строго по шаблону). Такая ситуация не позволяет, к примеру, автоматически работать в рамках одного адресного пространства. Другой пример: при переезде компании и соответствующей смене адреса в рамках адресного реестра легко автоматизировать арендные данные по адресу. Поскольку договор прикреплен к адресу и сама организации имеет адрес из адресного реестра, связка будет идти по одному справочнику, что устраняет дублирование и неконтролируемые адресный данные.
  5. Проблема переименования адресных элементов (например, улиц). Если улица выделена в отдельный справочник, то проблема решается легко. Если же улица пишется в текстовом поле, решить проблему актуальности наименования будет сложнее.
  6. Проблема учета территориальных и административных делений. Рассмотрим адреса "РФ Республика Башкортостан город Уфа улица Ленина дом 5" и "РФ Республика Башкортостан город Уфа Кировский район улица Ленина дом 5". Первый адрес является почтовым, а второй специфичный для некой системы. Кировский район – это административное деление, которое к самому адресу не имеет отношение. Частных решений таких ситуаций несколько, ниже будет рассмотрен подход в рамках иерархического адресного реестра.
  7. Иерархичность данных. Распространенный подход для обеспечения иерархичности данных заключается в создании отдельных, связанных между собой, справочников, "Страна", "Регион", "Город", "Поселок", "Улица". Однако такое деление не дает гибкости. Например, рассмотрим два адреса: в одном город является региональным ("РФ Респ. Башкортостан г. Уфа ул. Малая Кольцевая д. 180-3"), в другом - город не региональный ("РФ Респ. Башкортостан р-н Ишимбайский г. Ишимбай ул. Космонавтов д. 6-118"). У города Ишимбай есть "родительский" район. То есть эти адреса уже различаются количеством адресных элементов, но жесткая структура неиерархического адреса с трудом позволяет отображать это различие.
  8. Переоформление адресных территориальных единиц. Например, прилегающее поселение, деревня и т.д. входят в состав расширяющего города, или наоборот - город обрастает подчиненными областями. В системе необходимо корректно переоформить адреса. Если данные не иерархичные, то придется постараться с конвертерами. При иерархичных данных никаких дополнительных операций делать не нужно.
  9. Уникальность наименование улиц. Очень часто наименование улицы повторяется в различных населенных пунктах (например, улица Ленина). Иерархичность позволяет однозначно по одному адресному элементу идентифицировать всю адресную ветку.
  10. Проблема наименования видов адресных элементов. Часто возникают проблемы, когда улица в действительности является проспектом, бульваром или площадью, и это отражается в названии. При иерархическом адресном реестре трудностей с такими объектами не возникает.
  11. Интеграция данных. Четкое определение адреса позволяет значительно упрощать процесс взаимодействия.

Бизнес-эффект

Иерархический адресный реестр призван:

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

Пример работы

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

Данные по адресным элементам ведутся администратором, а сами адреса непосредственно операторами.

Фильтр для работы с адресами Фильтр для работы с адресами

Форма поиска/фильтра доработана таким образом, что при вводе новых данных (которых еще нет в адресном реестре) система автоматически на основе введенных данных предлагает создать запись в адресном реестре.

Вернуться к списку технических решений

Сертифицировано DIRECTUM:
Сертифицировано DIRECTUM
Версия:
1.0
Стоимость:
Решение платное. Стоимость предоставляется по запросу.
Бесплатное обновление версии решения в течении 1 года после приобретения.
Модель лицензирования:
Серверная?
  • Серверная - дает право устанавливать и использовать серверные компоненты технического решения и обеспечивает доступ клиентских устройств или пользователей на подключение к ним для их запуска. Рассчитывается по количеству работающих серверов.
  • Клиентская на устройство/пользователя - дает право клиенту (устройству или пользователю) подключаться к серверу.
  • Серверная + клиентская - представляет собой сочетание серверной и клиентской лицензий. Рассчитывается по количеству работающих серверов и клиентов, которые планируется использовать для работы с техническим решением.
Готовность:
Готовое?
  • Концепт – уровень готовности, который показывает наличие возможности создать полноценное решение под заказ.
  • Шаблон – уровень готовности решения, при котором решение дорабатывается под инфраструктуру заказчика.
  • Готовое – полностью готовое к использованию решение.
Условия ознакомления:
Живая демонстрация / Демо-стенд / Скринкаст
Поставщик:
МИТЦ
Авторизованный партнер

Сайт: www.mitc.ru
Написать: mitc@mitc.ru
Дополнительная информация
Совместимость:
DIRECTUM 4.8 - 5.0
Гарантийный срок:
1 год
Уровень поддержки:
Ограниченная?
  • Полная – решение предоставляется с гарантиями работоспособности ПО на протяжении срока действия Абонемента на новые версии системы DIRECTUM.
  • Ограниченная – решение предоставляется с гарантиями работоспособности ПО на протяжении гарантийного срока (обычно от 3 до 12 месяцев).
  • Как есть – решение предоставляется без гарантий работоспособности ПО.

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

Кнопка
связи