Alias ID

[Mazzi 8]

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

[lexx174 373]

А может лучше alternate_id?

Я так понял нужно иметь дополнительный идентификатор

[Mazzi 8]

19 минут назад, lexx174 сказал:

А может лучше alternate_id?

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

Изменено 19 мая 2017 пользователем Mazzi

[Krusty 194]

3 часа назад, Mazzi сказал:

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

Alias -> Item n::n
Alternate ID -> Item 1::1

Альтернативные индентификаторы могут повторяться если применяются в разных контекстах.

Элиэс - устаревший механизм, его вообще грозились депрекейтнуть.

 

[Mazzi 8]

1 час назад, Krusty сказал:

Элиэс - устаревший механизм

я про Alias ID, а не про Alias Object. Даже в нашей древней версии он уже как legacy

[Mazzi 8]

Очередная задумка. Надо к набору данных (в нашей схеме работы набор данных - это документ (в понятиях ЕСКД), описывающий изделий) привязать идентификатор этого документа в системе внешнего заказчика. Отношение dataset->внешний id 1::n (на перспективу, если будет необходимость хранить для разных заказчиков/систем ).

Что посоветуете использовать? И возможно ли использование механизма Alias ID (altenate ID) в применении к Dataset?

[lexx174 373]

20 минут назад, Mazzi сказал:

Очередная задумка. Надо к набору данных (в нашей схеме работы набор данных - это документ (в понятиях ЕСКД), описывающий изделий) привязать идентификатор этого документа в системе внешнего заказчика. Отношение dataset->внешний id 1::n (на перспективу, если будет необходимость хранить для разных заказчиков/систем ).

Что посоветуете использовать? И возможно ли использование механизма Alias ID (altenate ID) в применении к Dataset?

применяйте к айтемам/ревизии. зачем именно к Dataset? То что подразумеваетс в ЕСКД как набор данных - это не обязательно строго Dataset в Тимцентре,потому что переводится одинаково.

[Mazzi 8]

2 часа назад, lexx174 сказал:

применяйте к айтемам/ревизии. зачем именно к Dataset?

В нашей схеме данных Dataset  - это именно документ. Например, для у ItemRev сборочный единицы, в общем случае будет несколько Dataset (спецификация, сборочный чертеж, ведомость покупных и пр.). И каждый из этих документов (Dataset-s) должен будет иметь различный идентификатор системы заказчика. Поэтому применять к ItemRev нельзя.

Изменено 14 ноября 2017 пользователем Mazzi

[lexx174 373]

1 час назад, Mazzi сказал:

В нашей схеме данных Dataset  - это именно документ. Например, для у ItemRev сборочный единицы, в общем случае будет несколько Dataset (спецификация, сборочный чертеж, модель и пр.). И каждый из этих документов (Dataset-s) должен будет иметь различный идентификатор системы заказчика. Поэтому применять к ItemRev нельзя.

Айтем типа Document чем не устраивает? Он и задуман как раз как контенер для различного рода документов. Набор данных - Dataset - в первую очередь предназначен для хранения собственно данных файла - геометрии если это файл NX, итп. У вас я бы сказал немного искаженный вариант представления документа в качестве набора данных.

 

Я правильно понял - у вас есть тип Документ на основе бизнес-объекта Dataset, и сами файлы это то что хранится в именованных ссылках? Вы такой подход реализуете? Если да - то это с точки зрения логики модели данных тимцентра - абра кадабра

 

Изменено 14 ноября 2017 пользователем lexx174

[Mazzi 8]

@lexx174Мы, наверно, с десяток лет шли к этой схеме. И поначалу у нас документом был отдельный Item со своим типом. Потом отказались и пришли к парадигме "Набор данных-документ" и используем ее уже два года.

Пример одного из наших кастомных объектов:

У него 4 набора данных отражающих документы: детальная опись (ДО), сводка масс (СМТ), ведомость покупных (ВП), титульный лист (ТЛ). Сами файлы, естественно, хранятся в именованных ссылках + там же форма, содержащая данные основного штампа.

[lexx174 373]

26 минут назад, Mazzi сказал:

@lexx174Мы, наверно, с десяток лет шли к этой схеме. И поначалу у нас документом был отдельный Item со своим типом. Потом отказались и пришли к парадигме "Набор данных-документ" и используем ее уже два года.

Пример одного из наших кастомных объектов:

 

У него 4 набора данных отражающих документы: детальная опись (ДО), сводка масс (СМТ), ведомость покупных (ВП), титульный лист (ТЛ). Сами файлы, естественно, хранятся в именованных ссылках + там же форма, содержащая данные основного штампа.

интересный подход. а в чем преимущества данного подхода(как вы их видите) в сравнении с подходом Item=документ?

 

p.s это у вас еще старый TC который IMAN?

[Mazzi 8]

4 часа назад, lexx174 сказал:

p.s это у вас еще старый TC который IMAN?

Ну не настолько ))) ТСЕ (Teamcenter Engineering)

4 часа назад, lexx174 сказал:

а в чем преимущества данного подхода(как вы их видите) в сравнении с подходом Item=документ?

Чем мы руководствовались (возможно не самый правильный подход):

1. Внесение изменений. Вносишь изменения в документ - создай новую ревизию изделия. Новая ревизия изделия - сразу всем ясно, что что-то менялось. При схеме Item=документ -можно внести изменения в документ и не отразить их в изделии, к примеру поменять массу, спецификацию и пр.

2. Более понятная нашим пользователям схема. Есть изделие - внутри все документы, описывающие его. Нет такого, что модель - это набор данных (ugmaster), чертеж - это тоже набор данных (ugmanifistation), а, к примеру, ведомость покупных - это отдельный Item.

3. Проще программная обработка.

4. Нам показалась лишней прослойка в виде отдельных Item, содержащих Dataset документов.

Это из того, что вспомнил, переходили на эту схему более трех лет назад.

[lexx174 373]

21 минуту назад, Mazzi сказал:

Ну не настолько ))) ТСЕ (Teamcenter Engineering)

Чем мы руководствовались (возможно не самый правильный подход):

1. Внесение изменений. Вносишь изменения в документ - создай новую ревизию изделия. Новая ревизия изделия - сразу всем ясно, что что-то менялось. При схеме Item=документ -можно внести изменения в документ и не отразить их в изделии, к примеру поменять массу, спецификацию и пр.

2. Более понятная нашим пользователям схема. Есть изделие - внутри все документы, описывающие его. Нет такого, что модель - это набор данных (ugmaster), чертеж - это тоже набор данных (ugmanifistation), а, к примеру, ведомость покупных - это отдельный Item.

3. Проще программная обработка.

4. Нам показалась лишней прослойка в виде отдельных Item, содержащих Dataset документов.

Это из того, что вспомнил, переходили на эту схему более трех лет назад.

спасибо за пояснения