кстати кто либо работал плотно с SAP MDM-ом, интересует возможно ли в нём ведение версионности объектов (материалов там или контрагентов), тема серьезная, в момент Х, контрагент может изменить свое наименование, а нам необходимо также хранить и использовать в системах его старое наименование в том числе.

гы просмотрело тему 60 человек..не ответил ничего ни один..офигеть, неужели из присутствующих нету никого кто касался сего продукта????офигеть!

А что вы удивляетесь... Решение MDM пока еще слишком молодое, чтобы про него хорошо знали в России...

да уж..как же тогда его внедряют все усиленно елси никто его не знает.

Насколько позволяют мне судить мои скромные знания, версионности записей репозитория на настоящий момент (SP5) нет.

Про change tracking Вы вероятно в курсе, но этот механизм использовать для версионности трудно.

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

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

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

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

В МДМ есть понятие 'Harmonization'.Эта возможность отлавливает подобные отличия от оригинала.А когда событие поймано - тут уж можно самому версии создать

Может быть я не понял, о чем идет речь, потому что, на мой взгляд, решение очевидно. Как и в любой реляционной базе данных, нужно связать две таблицы соотношением один-ко-многим (COUNTERAGENTS-TITLES). В MDM есть понятие Qualified Table Field - поле с выбором значения. В процессе работы оператор может дополнять справочник значений такого поля или выбирать существующее из списка.

А вообще, у меня есть сомнения в том, что предприятие может так запросто поменять название без смены идентификаторов налогоплательщика (как ИНН+КПП) и других реквизитов.

да вот..может. вот в чем вопрос. оттуда и лезет сия ситуация. а вообще версионность, к примеру, есть материал. приводим в момент Х его наименование в соответствтие нормативному документу, по сути-изменение версии.. Тоже нужно отлавливать, что было до 10 числа а что после, а кто изменил и что и как.

Ммм, недопонял, нужно логирование (фиксирование этого изменения и, возможно, откат) или использование различных значений, соответствующих периоду операций/документов? Или Вы мне объясняете, что такое версионность?

В первом случае штатных инструментов нет, хотя лог ведется в служебной таблице БД. Мы ловим изменения таблиц при помощи собственной программы через Java API (для своего рода расширенного workflow).

Если второй случай - то он вполне вписывается в решение, которое я предложил (с использованием Qualified Table Fields для изменяемых атрибутов).

А еще у меня есть предложение перенести эту тему в Basis - там и советов больше дадут. Лично я на нее тут случайно наткнулся, потому что этот раздел обычно не читаю.

Может запоздало, но все же отвечу. Как говорят товарищи из Вальдорфва (из личной переписки с ними полугодовалой давности) Ведение версионности пока не предполагалось, только планируют реализовать временные периоды действия значений полей...
Но псевдр версионность можно реализовать посредствовом MDM Relationship завязав взаимосвязь на одну таблицу...

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