MDM система для централизованного управления справочниками предприятия типовыми средствами

Обработки - Обработка справочников

6
Поставили мне пару недель назад задачу настроить единые справочники номенклатуры во всех базах холдинга. Учитывая количество 1С бухгалтерий, которых в процессе выполнения задачи оказалось 32, и учитывая, что они все разных версий (2.0, 3.0, отраслевые), задача казалась из ряда чистой воды подстава. Но решение с технической точки зрения оказалось простейшим.

Необходимым требованием для реализации этого способа является обновление всех конфигураций на управляемое приложение. Именно в Бухгалтерии 3, ЗУП 3 КОРП, ERP 2, УТ 11 имеются инструменты, которые мы будем использовать для нашей задачи.

Использовать мы будем EnterpriseData, относительно новый стандарт обмена в конфигурациях 1С. Стандарт EnterpriseData хорош тем, что конвертация происходит через промежуточный формат, собственно EnterpriseData. Следовательно, если типовая конфигурация поддерживает этот стандарт, то теоретически мы можем настроить обмены любых типовых конфигураций друг с другом. Т.к. все они понимают формат EnterpriseData, то они могут, как грузить в, так и загружать из этого формата.

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

Я решил проверить это предположение и попробовать настроить загрузку справочника Номенклатура из базы источника в базу приемника.

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

1. Создадим несколько баз:

- БП Мастер база - это будет наша центральная база из которой мы будем управлять нашими НСИ;

- Несколько Подчиненных баз (например, БП Подчиненная 1, БП Подчиненная 2, БП Подчиненная 3...)

Соответственно у нас должна будет получиться структура типа "звезда", когда из Мастер базы будет рассылаться НСИ в Подчиненные базы.

2. Идем в БП Мастер база, зададим ей префикс MD и включим возможность осуществления Синхронизации данных:

3. Создадим новую синхронизацию, нам необходимо использовать вариант "Другая программа", т.к. типовой синхронизации БП - БП не существует. Но нам будет достаточно и этого варианта:

4. Настроим параметры подключения.

5. Настроим правила отправки и получения данных

5.1 Правила отправки данных - Нормативно-справочная информация: оставляем "Отправлять всю";

5.2 Правила отправки данных -  Документы: нам грузить документы не нужно, поэтому ставим "Не отправлять";

5.3 Правила получения данных: в этой ситуации нам не важны, оставляем все поля пустыми

5.4 Тут нам необходимо выполнить замену правил регистрации объектов.

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

Для этого перейдем в форму загрузки Правил регистрации объектов:

Тут по соответствующей кнопке выполним сохранение правил на свой компьютер.

Эти правила нам необходимо загрузить в Конвертацию 2.1 и внести в них изменения.

Создадим новые Правила регистрации объектов

Зайдем в каждое правило, которое мы не хотим выгружать и в обработчик ПередОбработкой добавим одну строку:

Отказ = Истина;

Полученные правила нам необходимо сохранить в файл и загрузить в нашу настройку обмена в БП Мастер база

Сохраняем сделанные настройки.

6. Выполним начальную выгрузку данных

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

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

8. Идем в подчиненную базу и выполняем настройку правил отправки и получения данных в ней

8.1 Правила отправки данных - Нормативно-справочная информация: ставим "Не отправлять", т.к. НСИ мы будем передавать только в одном направлении от Мастер базы в Подчиненные.

8.2 Правила отправки данных -  Документы: документы аналогично выгружать не будем, ставим "Не отправлять"

8.3 Правила получения данных: так же оставляем не заполненными

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

Дальше можно развить тему, например, запретить создание элементов НСИ в подчиненных базах.

6

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. LordKim 27.11.18 02:41 Сейчас в теме
Но решение с технической точки зрения оказалось простейшим


Хотелось бы увидеть как решалась проблема дедубликации (замены существующих элементов на централизованные)

Задача "запретить создавать в подчиненных и залить в подчиненные из центральной" - да, очень простая
Сложности возникают на момент приведения к единой ссылке уже существующих данных...
pm74; Waanneek; +2 Ответить
2. lopatin 415 27.11.18 05:22 Сейчас в теме
(1) Тут надо пробовать, вообще в механизмах обмена есть сопоставление объектов, программа запоминает какая ссылка, какой соответствует.

А запретить создавать - на уровне ролей, которые можно успешно реализовать в расширениях используя за основу типовые.
4. LordKim 27.11.18 17:46 Сейчас в теме
(2) Есть сопоставление на уровне настройки првил КД и "программа запоминает" в регистре сведений (который присутствует только в типовых, и то не во всех), но я так понял что задача была поставлена не про начало работы, когда справочники пусты, тут все элементарно, а про унификацию существующих объектов НСИ (Номенклатура - частный случай)

И вот тут, собственно, и начинаются реальные проблемы
Потому что Х баз (в вашем случае 32), в которых активно ведется учет, имеют свой набор объектов НСИ, и формат транспорта (ED например) не решает проблему унификации (сопоставления), ни с формальной стороны, ни со стороны замены ссылок на корректные (центральные)

Более того, по умолчанию конвертация ищет по ссылке, соответственно не обнаруженные элементы она создаст (возможно задвоение), а если найдет - то заменит существующий элемент (вероятность низкая, но случается), а это очень серьезная проблема

Этим и вызван мой комментарий, так как ED я считаю (возможно необоснованно) "дохлым" форматом, использование которого для полноценной организации НСИ (действительно сквозной во всех БД, а не только в типовых 1С) - не рационально

Но вдруг там есть волшебная кнопочка "синхронизировать все", про которуя я просто не в курсе?
Или какой-то удобный инструмент унификации?
3. Waanneek 82 27.11.18 11:51 Сейчас в теме
(1)
Хотелось бы увидеть как решалась проблема дедубликации (замены существующих элементов на централизованные)


О да, больная тема! Обмен написать это 5-10% от работ по запуску интеграции..
Синхронизировать справочники когда их по 10-20+ тысяч с явными и не явными дублями и 70-80% не совпадает автоматически между системами - адская работа..
5. dkoder 28.11.18 08:49 Сейчас в теме
Сразу отказался от такой идеи.
Проблемы (у нас):
1. Есть не типовые конфы
2. Есть информационные системы не 1С
Пришлось писать свой механизм мини шины данных на WEBService (рекомендую).
Рекомендую почитать теорию МДМ от IBM: справочники, мастер данные, транзакционные данные.
И не забывать о копиях БД, которые будут дублировать обмены.
Я сделал две универсальных процедуры:
1. Выгружает данные элемента по метаданным в Структуру (только простые типы данных) затем ЗначениеВФайл
2. Загружает из ЗначениеИзФайла в структуру по метаданным в объект
Залил во все БД
Структура хорошо тем, что можно добавлять неограниченно данные, типа дополнительных свойст, регистро сведений, подчиненные объекты.
Да получается немного муторней чем через КД, но на больших данных более универсально
Оставьте свое сообщение