Что такое MDM key в 1С и как с ним работать

MDM key — это ключ сопоставления (идентификации) объектов нормативно-справочной информации в системе 1С:MDM (Master Data Management — управление нормативно-справочной информацией). Такой ключ позволяет однозначно связать один и тот же элемент справочника — например, контрагента, номенклатуру или договор — в разных информационных базах холдинга, даже если в каждой базе у него свой внутренний идентификатор и даже разное наименование.

Проблема, которую решает MDM key, знакома любой компании с несколькими учётными системами: в одной базе контрагент заведён как «ООО Ромашка», в другой — «Ромашка ООО», в третьей — «ООО "Ромашка"». Для человека это один и тот же партнёр, для программы — три разных объекта. Без единого ключа консолидированная отчётность, сквозная аналитика и корректный обмен данными между базами невозможны.

В этой статье разберём, как устроен MDM key, где он хранится, как происходит сопоставление объектов, какие настройки влияют на качество идентификации и каких ошибок стоит избегать при внедрении и эксплуатации 1С:MDM.

Зачем нужен MDM key: суть проблемы дублей

В распределённой структуре предприятия каждая информационная база ведёт свои справочники автономно. Главный ключ объекта внутри базы — его уникальный идентификатор (GUID), но он уникален только в пределах одной базы (или узла плана обмена). При выгрузке данных в центральную MDM-систему GUID из разных баз ничего не говорят друг о друге.

MDM key решает задачу сквозной идентификации: центральная система анализирует набор реквизитов объекта (ИНН, КПП, наименование, адрес, артикул, штрихкод и т.д.) и присваивает ему ключ. Если по правилам сопоставления объект признан уже существующим, он получает тот же ключ, что и «эталонная» запись. В результате все дубли из периферийных баз оказываются связанными одним ключом.

Практический эффект: аналитика по контрагенту перестаёт дробиться на три разные строки в отчётах, обмены не создают новых дублей, а изменение эталонных данных можно централизованно транслировать во все подключённые системы.

Как устроен механизм сопоставления в 1С:MDM

Типовое решение 1С:MDM построено вокруг понятия «золотой записи» (golden record) — эталонного объекта, собранного из наиболее достоверных реквизитов всех связанных записей. MDM key в этой схеме — идентификатор золотой записи, а механизм сопоставления определяет, какие входящие записи к ней относятся.

Сопоставление выполняется по настраиваемым правилам. Обычно применяется комбинация подходов: точное совпадение по ключевым реквизитам (например, ИНН + КПП для контрагента), нечёткое сравнение строк (для наименований с разными вариантами написания) и взвешенная оценка, где каждому реквизиту назначается вес, а решение принимается по суммарному баллу сходства.

Результат сопоставления может обрабатываться автоматически (при высокой степени уверенности) либо направляться на ручную разборку — когда система не может однозначно решить, дубль это или самостоятельный объект. Пороговые значения уверенности настраиваются в параметрах правил.

Где хранится ключ и как его увидеть

В центральной базе 1С:MDM ключ привязан к золотой записи и хранится в служебных регистрах сопоставления, которые связывают внешние представления объектов (источник, тип объекта, идентификатор в источнике) с эталонной записью. Конкретные имена регистров зависят от версии решения, но логика всегда одна: пара «источник + внешний идентификатор» → «ключ MDM».

В прикладных базах, подключённых к MDM, ключ обычно сохраняется как дополнительный реквизит или запись в регистре соответствия, заполняемом подсистемой обмена. Это позволяет при повторных выгрузках не инициировать поиск заново, а сразу адресовать объект по известному ключу.

Чтобы посмотреть ключ конкретного элемента, откройте карточку объекта в центральной MDM-базе и перейдите к связанной информации о сопоставлении — там видны все привязанные источники и их идентификаторы. В периферийной базе ключ ищите в дополнительных сведениях элемента или в регистре соответствия объектов, если он используется вашей интеграционной подсистемой.

Настройка правил идентификации

Качество работы MDM key почти полностью определяется настройкой правил сопоставления. Начинайте с выбора «сильных» реквизитов — тех, что однозначно идентифицируют объект: ИНН и КПП для российских контрагентов, штрихкод или связка «производитель + артикул» для номенклатуры. Эти реквизиты должны давать максимальный вес.

Для нечёткого сравнения наименований включите нормализацию: приведение к одному регистру, удаление организационно-правовых форм, кавычек и лишних пробелов. Без нормализации «ООО Ромашка» и «ромашка ооо» получат низкую оценку сходства, и система создаст лишнюю золотую запись.

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

1. 1
   Определите перечень объектов НСИ, которые будут проходить через MDM (контрагенты, номенклатура, договоры)
2. 2
   Выберите сильные идентифицирующие реквизиты для каждого типа объекта
3. 3
   Настройте нормализацию строковых реквизитов (регистр, ОПФ, кавычки, пробелы)
4. 4
   Задайте веса реквизитов и пороги автоматического сопоставления
5. 5
   Прогоните правила на тестовой выборке и разберите спорные случаи вручную
6. 6
   Включите промышленную загрузку и настройте регламент контроля качества

Обмен данными и роль ключа в интеграциях

В обменах через 1С:MDM ключ выполняет роль адресационного идентификатора. Когда периферийная база отправляет новый объект, центральная система ищет ему соответствие и возвращает ключ; при последующих выгрузках этого же объекта ключ передаётся вместе с данными, и повторный поиск не требуется.

При централизованном ведении НСИ схема обратная: золотая запись создаётся или изменяется в MDM, а затем вместе с ключом рассылается подписанным системам. Базы-подписчики по ключу понимают, какой локальный объект нужно обновить, а не создают новый.

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

Типичные ошибки и ограничения

Самая частая ошибка — запуск автоматического сопоставления на «сырых» исторических данных без предварительной чистки. Если в базах половина контрагентов без ИНН, а наименования заполнены произвольно, любые правила дадут большой процент ошибок, и доверие к системе будет подорвано.

Вторая типичная проблема — чрезмерное доверие к автоматике. Ложное слияние двух разных контрагентов под одним ключом опаснее, чем пропущенный дубль: документы и аналитика начнут относиться не к тому юридическому лицу. Порог автоматического слияния должен быть консервативным, а пограничные случаи — уходить на ручную обработку.

Также учитывайте ограничение: MDM key идентифицирует объект, но не отменяет необходимости согласования состава реквизитов между системами. Если в одной базе у номенклатуры есть обязательный реквизит, которого нет в модели данных MDM, потребуется доработка модели или правил обмена.

Как проверить качество сопоставления

После внедрения или изменения правил полезно регулярно оценивать результат по нескольким контрольным точкам: доля объектов, сопоставленных автоматически; размер очереди ручной разборки; количество золотых записей с признаками ложного слияния (например, одна запись с несколькими разными ИНН).

Практический приём — выборочная проверка: возьмите случайную выборку золотых записей и вручную сверьте связанные с ними объекты из источников. Если в выборке встречаются ошибки, проблема системная, и правила нужно пересматривать, а не исправлять точечно.

Контрольные точки

Как проверить результат

Связанные записи золотой записи

Норма

Все записи относятся к одному реальному объекту

Тревожный признак

Под одним ключом разные ИНН или разные товары

Очередь ручной разборки

Норма

Стабильно небольшая и разбирается по регламенту

Тревожный признак

Непрерывно растёт, никто не обрабатывает

Повторные выгрузки из баз

Норма

Объект уходит с тем же ключом, дубли не создаются

Тревожный признак

При каждой выгрузке создаётся новая золотая запись

Частые вопросы

Чем MDM key отличается от GUID объекта в 1С?

GUID уникален только в пределах одной информационной базы (или связанных узлов обмена) и ничего не говорит о том, что объекты из разных баз — это одно и то же юридическое лицо или товар. MDM key назначается центральной системой по результатам анализа реквизитов и объединяет все дубли объекта независимо от их локальных идентификаторов.

Можно ли использовать 1С:MDM только для контрагентов?

Да, это частый сценарий старта: сначала централизуют один наиболее проблемный справочник, обычно контрагентов или номенклатуру, отрабатывают правила и процессы, а затем подключают остальные объекты НСИ — договоры, банковские счета, организации.

Что делать, если два разных контрагента ошибочно слились под одним ключом?

Золотую запись нужно разделить: отвязать ошибочно присоединённые объекты источников и создать для них отдельную эталонную запись с новым ключом. После этого проверьте, какие документы и отчёты могли использовать ошибочную связь, и скорректируйте правила сопоставления, чтобы ситуация не повторилась.

Теряется ли MDM key при обновлении конфигурации?

Сами данные сопоставления хранятся в информационной базе и при штатном обновлении сохраняются. Риск возникает при нештатных ситуациях: переходе на иную редакцию решения, изменении структуры регистров сопоставления или ручной чистке «лишних» данных. Перед такими работами сделайте резервную копию и выгрузите таблицы соответствия.

Обязательна ли ручная разборка, или всё можно автоматизировать?

Полностью отказаться от ручной разборки можно только при очень чистых данных и жёстких ключевых реквизитах. На практике всегда остаются пограничные случаи — неполные реквизиты, опечатки, реорганизованные юрлица. Разумный подход: автоматизировать очевидные совпадения, а спорные случаи направлять ответственному за качество НСИ.

Подходит ли 1С:MDM для обмена между базами одной компании без холдинговой структуры?

Да, решение применимо и для двух-трёх баз, если в них независимо ведутся одни и те же справочники и дубли создают проблемы в отчётности и обменах. Для простых случаев с одним направлением обмена иногда достаточно типовых планов обмена с сопоставлением объектов, но при нескольких источниках MDM-подход управляемее.