Система нормативно-справочной информации: 4 архитектуры и как выбрать модель

Систему НСИ строят по одной из четырех архитектур. Реестр хранит только связи, мастер-данные остаются в учетной системе. Консолидация собирает копии справочников для отчетности. Коэкзистенция синхронизирует эталон из MDM с учетными системами — самый частый выбор. Централизация разрешает ввод только в MDM, другие системы работают на чтение. От выбора архитектуры зависят сроки и объем интеграций.

Обычно к этому выбору приходят так: к 1С:Бухгалтерии добавляется 1С:ЗУП, потом 1С:Управление торговлей. В каждой базе свои коды и наименования, картины целиком нет.

Реестр НСИ — мастер-данные остаются в 1С

НСИ соответствует понятию Master Data: базовым сущностям, на которых строится учет. Хранят их в виде справочников, классификаторов и словарей. В компании это конкретные объекты: номенклатура, контрагенты, организации, склады, статьи затрат.

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

Чего избегать: ждать, что дубли пропадут сами. Реестр их сопоставляет, а не устраняет.

Что сделать сейчас: выгрузить справочник контрагентов из каждой базы и сверить записи по ИНН.

Где реестр упирается в потолок

Допустим, один контрагент заведен в нескольких базах под разными наименованиями. Реестр связывает эти записи между собой, но менеджер в каждой базе продолжает создавать новые карточки под свои задачи.

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

Консолидация справочников для сквозной отчетности

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

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

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

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

Что сделать сейчас: выписать отчеты, которые сегодня требуют ручных правок, — это готовый список кандидатов на консолидацию.

Симптомы и их цена для бизнеса

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

Коэкзистенция — почему ее выбирают чаще всего

Эталон записи живет в MDM, а учетные базы держат синхронные копии. Обмен двусторонний: правки уходят из MDM в базы и возвращаются обратно. Регламент ведения НСИ решает, где разрешен ввод конкретного справочника и кто согласует изменения.

Отсюда и популярность у холдингов: сотрудники работают в привычной 1С, а эталон один и под контролем. Это компромисс между порядком в данных и привычным вводом.

Критерий: если в компании несколько конфигураций 1С и данные меняются часто, коэкзистенция — разумная точка старта. Справочники те же, что перечислены в разделе про реестр.

Чего избегать: разрешать ввод одного справочника и в MDM, и в учетной базе без правила приоритета. Тогда две правки одной карточки перезаписывают друг друга.

Что сделать сейчас: для каждого справочника записать, в какой системе он сейчас рождается.

Карточка товара как эталон

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

Централизация НСИ и работа служб на чтение

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

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

Если дочерние общества не ведут собственных автономных справочников и модель НСИ управляется из центра, централизация реальна. Цена модели — очередь заявок и нагрузка на службу НСИ.

На что обратить внимание: срок обработки заявки на новую карточку прямо влияет на отгрузки.

Что сделать сейчас: назначить ответственного за справочник номенклатуры — человека, который принимает заявки и отвечает за качество карточек.

Кто создает, согласует и проверяет

Служба НСИ работает по матрице ролей. Создание такой службы включает центр компетенций, положения и должностные инструкции.

Какую архитектуру НСИ выбрать — сравнение моделей

Модели отличаются по пяти параметрам.

Внедрение решения для управления НСИ занимает от полугода.

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

Что сделать сейчас: пройти чек-лист ниже и выписать ответы.

Регламент или MDM — чек-лист

• •Если учетных систем немного, структура НСИ простая, а номенклатура и контрагенты умеренного объема — хватает регламента.
• •Если баз несколько, структура НСИ сложная, но справочники меняются редко — подходит реестр.
• •Если нужна сквозная отчетность без правки источников — консолидация.
• •Если справочники меняются часто, синхронизация идет вручную и нужен двусторонний обмен — коэкзистенция.
• •Если модель НСИ управляется из центра и у дочерних обществ нет автономных справочников — централизация.
• •Если в текущей платформе есть модуль MDM (1С:ERP Управление холдингом), строить коэкзистенцию или централизацию проще.

Как устроен обмен данными НСИ

Схема цикла: ведение записи в эталоне → очередь публикации → передача через шину → подтверждение приема базой → обратный поток правок из систем → разбор расхождений по журналу изменений → и снова ведение.

Каждый шаг фиксируется, поэтому правка, застрявшая на полпути, видна в журнале, а не теряется незаметно.

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

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

На что обратить внимание: внешние справочники ФНС нужно обновить в информационных системах в течение 30 дней после публикации — иначе расхождение возникнет из-за устаревшего внешнего источника, а не из-за внутреннего обмена.

Что сделать сейчас: составить список интеграций и отметить, где обмен пока идет вручную.

Разбор расхождений на практике

Допустим, склад меняет единицу измерения товара в своей базе. Обратный поток приносит эту правку в эталон. Служба НСИ открывает журнал изменений, видит автора и решает: принять правку как исправление ошибки или откатить как отклонение от стандарта.

Решение зависит от причины правки, а не от самого факта расхождения: журнал показывает, кто и когда менял запись, а сверить это с регламентом должен человек.

Спроектируем архитектуру НСИ под ваш ландшафт: проект от 800 000 ₽, схему интеграций разбираем на первом созвоне — раздел «ERP-системы».

Источники

• •База знаний
• •Статья "Поисковые возможности системы ГАРАНТ"
• •Документы — Правительство России
• •3.2 Получение и состав справочников НСИ
• •ГОСТ Р 2.820-2023 Единая система конструкторской ...