Re: Сборки в документообороте

Приглашаю всех, кто занимался модулем документооборота, обсудить следующую проблему.
Любое изделие - это сборка.
В архиве в файловом составе сборки должны присутствовать все детали в неё  входящие. Иначе конструктор не сможет работать с чертежём сборки - отсутствующие детали не прорисуются.
Те же детали должны присутствовать в архиве как самостоятельные документы.
Получается дублирование: конструктор может открыть обработчик как из детали, так и из сборки для той же детали. Изменения, проведённые из документа детали не будут учитываться в документе сборки и наоборот.
К чему это приведёт, особенно если изделие сложное?
Получается, что архив TCS вместе с модулем документооборота нельзя использовать для чертёжной документации. Так ли это по мнению уважаемого общества?
Используемая CAD - SolidEdge.
Буду благодарен за ответы.

Re: Сборки в документообороте

В архиве в файловом составе сборки должны присутствовать все детали в неё входящие

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

Положите документы сборки в связанные документы главного документа.

Далее, при выгрузке документа сборки (да и любого другого, как настроите) использую ТКС-АПИ выгружаете нужные вам документы ( а их лучше всего взять из связанных) до любого уровня. И все.

Re: Сборки в документообороте

Не до нужного уровня, а всё до самого низа. Вы конструктор и имеете перед собой сборку, которую Вы "выгрузили" не до конца, т.е. не все детали сборки видны. И Вы хотите нарисовать разрез. Что Вы нарисуете не имея полного составв сборки?
Было сказано: архив TCS не годен для организации архива чертёжной документации.
Хотелось бы иметь ответ именно на это, а не расплывчатые рекомендации по доработке TCS силами заказчика.

Re: Сборки в документообороте

Тут проблема не в архиве. Он то сам по себе то позволяет и хранить сборки, и хранить детали как отдельные документы.
Хранить файлы деталей в составе документа сборки - естественно не правильно по выше уже указанным причинам и не только. 
Делать это надо через связанные документы. И возможность для этого есть. Этот способ, кстати, решает и вопрос с правами на редактирование заимствованных деталей. Ведь, создавая новую сборку, когда Вы берете детали из друших сборок, которые при этом утверждены, Вы ведь не должны иметь возможность эти детали редактировать, правильно? Это один вопрос. Кроме того существуют еще как минимум следующие вопросы:
1. Добавление деталей (и узлов вместе с деталями) из архива в SE прямо в процессе работы со сборкой в SE.
2. При создании новых деталей в контексте сборки, при редактировании ее в SE необходимо, чтобы эти детали тоже появились в архиве как документы, связанные с документом сборочной единицы куда они входят. Иначе, если добавлять их просто как обычно в SE, то потом любой другой пользователь, кроме Вас, даже при наличии прав на просмотр сборки не сможет ее полностью открыть из архива, т.к. части деталей там просто не будет.

Все это и еще ряд вопросов - сводится к тому, что требуется некоторая доработка со стороны SE, которая бы позволила из SE корректно работать с документами из архива. Собственно именно этим вопросом мы сейчас и занимаемся. И как раз по поводу Solid Edge  :D

Re: Сборки в документообороте

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

Re: Сборки в документообороте

Николай писал(а):
Здесь не упомянулось о практически основной причине неприемлемости имеющей место ситуации: дублировании деталей.

Конечно не упоминалось, т.к. его нет. Файловый состав одной конкретно взятой детали хранится в ЕДИНСТВЕННОМ экземпляре. А в связанных документах хранится ТОЛЬКО ссылка.

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

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

Re: Сборки в документообороте

Уважаемый Андрей, Ваши ответы не конструктивны.
Связывание документов не поможет, не будет SE искать файлы по документам архива TCS.
Надо дорабатывать TCS - дорабатывайте, надо поработать с SE - работайте, у них развитая объектная модель, там много что можно сделать.
Обозначайте сроки и что к ним примерно можно ожидать.
Но ведите конструктивный диалог с людми, у которых договор с Вашими партнёрами из CS на Вашу систему.

С уважением, Николай Мартынов
ГИП САПР  ЦИТиАС
ОАО "Промтрактор", Чебоксары

Re: Сборки в документообороте

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


Уважаемый Николай! На форуме команды не раздаются кому и что делать. Здесь обсуждается КАК решается та или иная проблема в системе. Мы вам рассказали как это решается. Но похоже вам не интересно КАК, вам нужно готовое решение. Тогда зачем все эти вопросы, если вы самостоятельно ничего делать не собираетесь?

Re: Сборки в документообороте

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


Ваш вариант - документ на изделие состоит из фаилов SE на само изделие, на сб.единицы и детали, входящие как в изделие, так и в эти сб.единицы. Плюс эти файлы появляются в архиве в документах на сами сборки и детали. То есть дублируются в архиве. Так?

Вариант CS - документ на изделие состоит из фаилов SE на само изделие, а на сб.единицы и детали входящие в состав идут ссылки на дукументы, в которых находятся файлы.

Я могу вам сказать, что подход CS, в принципе не является просто нашей выдумкой. Данный подход призван обеспечить базовые принцыпы CALS-технологии (я надеюсь все слышали про такие):

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

И как в вашем варианте можно это реализовать не совсем понятно. Если мы один и тот же файл дважды занесём в архив, ясно что ошибок не избежать. 
Пример (чисто гипотетически): мы завели два чертежа на одну деталь(один хранится со сб.единицей, другой отдельно в другой папке), и как проводить извещения об изменении?
Как это видится Вам? Вазможно, я что-то не так понял?

Re: Сборки в документообороте

В архиве в файловом составе сборки должны присутствовать все детали в неё входящие. Иначе конструктор не сможет работать с чертежём сборки - отсутствующие детали не прорисуются.


   Ещё хочется заметить, что TCS не "заточен", как говорится, под какой-либо определённый CAD, так как в этом случае проблем только прибавится.

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