Конфигурации объекта

Автор Maxxx, 15.01.08, 16:42:59

« предыдущая - следующая »

0 Пользователей и 1 гость просматривают эту тему.

Maxxx

Добрый день!
Столкнулся с проблеммой. Необходимо чтобы в базе данных ЛОЦМАНА каждая конфигурация объекта сохранялась независимо от других - т.е. один и тот же объект чтобы находился в разных местах базы, и при изменении его конфигурации в одном месте это не влияло на всю базу. Пока я не нашел как это сделать - может кто знает -помогите!

Вячеслав _

Максим, используйте версионность.

Yorik

Добрый день! Просьба уточнить вопрос: конфигурация (или отображение информации об объекте) в ЛОЦМАН-Клиенте или еще где-нибудь?

Maxxx

В ЛОЦМАН-клиенте версия 8.5. Отображение состава изделия.

Yorik

Если я правильно все понял ситуация следующая: один и тот же объект (например Деталь) находится в разных составах (в разных Сборочных единицах) и почему-то необходимо чтобы отображение состава было разным в разных случаях. Если тип связи один (Состоит из ...) то конфигурация одна (см. Отображение в составе в Конфигураторе) если тип головного объекта тоже один и тот же. Если тип связи или тип головных объектов разный то в Конфигураторе можно настроить разные правила. К тому же можно поупражняться профилем. Если можно поконкретней описать случай, а то уж больно интересный вопрос...

Maxxx

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

Yorik

Если я правильно все понял, то речь идет о разных исполнениях одной сборочной единицы (по ЕСКД). Исполнение сборочной единицы ААА - это новая сборка (новый объект) только с обозначением ААА-01, он привязан к ААА связью Исполнения. Состав этих объектов просто разный. И в разных заказах просто должны стоять разные исполнения (разные объекты)...

Maxxx

Тогда я не пойму для чего нужна конфигурация...

Вячеслав

А Вы не обращались в ближайший офис компании?

Maxxx

Обращались. Но ответа не получил пока.

YorikER

Извиняюсь за некомпетентность. У нас ЛОЦМАН 7.1SP2 и вроде там никаких конфигураций небыло... Поднял документацию на ЛОЦМАН 8.5, почитал... пытаюсь переварить. Давайте поразмышляем... Исполнение - это одназначно новый функциональный объект, похожий по составу, различающийся некоторыми составляющими, но однозначно с другими потребительскими свойствами (длина, присоединительный диаметр и т.п.). Конфигурация - .то тот же самый объект, с теми же потребительскими свойствами, но с различными вариантами замен (патрон подвески газовый или гидравлический - автомобиль той же марки).Не путаете ли вы конструкторский и производственный составы изделия. Это самая распространенная ошибка при построении информационного потока. Конструкторский - это как изготовить изделие, производственный - как реально оно изготавливалось. Производственный - это полная копия конструкторского, но это абсолютно новые объекты, да и другого типа. При запуске в производство определяется какая конфигурация необходима и с чего делать производственную копию. Производственных копий можетбыть сколько угодно (сколько закажут сделать), они могут быть разной конфигурации, а конструкторская копия одна, в одном месте, но в разных вариантах. Фу...! Сам балдею от того как я умно написал... Ни в коем случае не претендую на истину в последней инстанции... Может я и не прав... А что скажет начальник транспортного цеха - т.е. Авторы?
Все может быть, что быть не может... Однако все же может быть...
И одного лишь быть не может - Чего вообще не может быть...

Maxxx

Это я все понимаю. Вот только не пойму как тут быть. Постараюсь придумать пример)). Есть изделие (допустим прицеп). У него две конфигурации. Допустим с дышлом и без дышла. И есть заказ - 2 прицепа с дышлом и один без дышла. Задача - выдать документацию, и создать отчеты - типа сколько и каких деталей изготавливать для данного заказа. Проблемма в том - меняем конфигурацию в одном экземпляре изделия - конфигурация меняется и в другом. Или я чего то не допонимаю(((...

YorikER

Я так понимаю, что путаница из-за неправильной структуры данных. АСКОН в своих базовых поставках неплохо разработал конструткорский регламент и еще не так сильно продвинулся в производственном. Многие пользователи начинают примеривать конструкторский состав изделия для реальных производственных задач, а так действовать нельзя. Попробую объяснить (может сам что-нибудь пойму 8-)... В базе данных есть объект (или проще запись), описывающий прицеп (сборочная единица). У этого объекта есть ключевой атрибут (обозначение) - ААА. Этот объект находится в одном месте и он один и уникальный... У этого объекта есть несколько конфигураций, при первой конфигурации в его состав входит объект типа деталь (Дышло) с уникальным ключевым атрибутом БББ, при второй конфигурации в прицеп вместо первого дышла входит другой объект типа деталь (пускай тоже Дышло), но с ключевым атрибутом ВВВ (возьмем именно такой случай). Все эти объекты уникальны и находятся каждый в своем (одном) месте базы данных. Все эти объекты явлются конструкторскими, они только описывают как изготовить изделие. В качестве аналогии возьми архив: документация на дышло лежит в одном месте, а поней можно изготовить множество железок по разным заказам. Продолжение следует...
Все может быть, что быть не может... Однако все же может быть...
И одного лишь быть не может - Чего вообще не может быть...

Вячеслав

Ребята, ну если один прицеп с дышлом, а другой - без него, так по всем правилам без дышла есть ИСПОЛНЕНИЕМ того, что с дышлом.

Maxxx

я согласен - это исполнение. Но этот пример (про прицеп) я взял из руководства пользователя лоцман. Там как раз конфигурирование изделий рассматривается с помощью этого примера. Я так понимаю что конфигурирование для данной ситуации неприемлимо?

YorikER

Продолжим... Теперь перейдем к заказу. Объект типа Заказ - головной производственный объект. Пускай по какому-то контракту мы создаем в базе данных объект типа Заказ с ключевым уникальным атрибутом 123654. В его состав входит объект типа Экземпляр изделия (!) под наименованием Прицеп с уникальным ключевым атрибутом 123654.ААА.1 в количестве - 2шт., где 123654 - номер заказа, ААА - обозначение прицепа, 1 - номер конфигурации данного прицепа. Также в этот заказ входит объект того же типа с тем же наименованием в количестве 1 шт., но с ключевым атрибутом 123654.ААА.2 - где 2 это вторая конфигурация. В состав Экземпляра изделия (ЭИ) 123654.ААА.1 входит объект типа ЭИ под наименованием Дышло с ключевым атрибутом 123654.БББ.1, где 123654 - номер заказа, БББ - конструкторское обозначение, 1 номер конфигурации самого дышла. В состав ЭИ 123654.ААА.2 аналогично входит ЭИ Дышло с ключевым атрибутом 123654.ВВВ.1. Обратите внимание, что в ключевой атрибут ЭИ входит номер заказа, что позволяет отделить реальные железки, изготовленные по одному и тому же чертежу в базе данных, но по разным заказам!!! Тем более, что заказы (и собственно железки) в производстве могут идти одновременно. Другие детали прицепов будут иметь в нашем случае одинаковую идентификацию. Но это другие типы объектов, не конструкторские!!! Именно производственные объекты теперь можно складывать и фиксировать по ним затраты, вопросы планирования и т.д. Продолжение следует...
Все может быть, что быть не может... Однако все же может быть...
И одного лишь быть не может - Чего вообще не может быть...

YorikER

Продолжим... Производственные объекты это объекты другого типа, они имеют прямой физический смысл, они описывают конкретную железку в цехе. Считайте что на каждую железку вы повесили бумажку (карточку), в которой отражается вся ее производственная история. Так вот экземпляр изделия - это и есть эта самая карточка в базе данных. Производственный состав - это полная копия конструкторского состава в базе данных (именно той конфигурации которая нужна для заказа), но на совсем других объектах!
Все может быть, что быть не может... Однако все же может быть...
И одного лишь быть не может - Чего вообще не может быть...

YorikER

Фиксировать объекты заказа и производственную историю на конструкторских объектах бессмысленно... Как я уже говорид конструткорские (кстати и технологические) описывают как надо изготовить ту или иную конфигурацию, а производственные объекты - как реально изготавливалась железка по конструктосркой документации... Уфффф... Кажется я иссяк! :o
Все может быть, что быть не может... Однако все же может быть...
И одного лишь быть не может - Чего вообще не может быть...

Maxxx

т.е. я правильно понимаю - для каждой детали или сборочной единицы в базе должен быть сопоставлен экземпляр изделия??? что-то я запутался  :%:

YorikER

В каждом конкретном заказе для каждой детали и сборки надо создать свои собственные объекты типа экземпляр изделия... Дерево заказа должно состоять из экземпляров изделия... Вопрос - Вы работаете в ЛОЦМАН-Клиенте или в каком-то собственном приложении?
Все может быть, что быть не может... Однако все же может быть...
И одного лишь быть не может - Чего вообще не может быть...