Ситуация следующая.
1. Есть система классов - виды оборудования. По каждому классу есть свои признаки.
2. Есть единица оборудования, принадлежащая определенному классу, у нее есть признаки.
3. Запутаюсь и читателя запутаю так дальше писать ). Будем проще. У компрессора есть редуктор. У редуктора есть свои тех. характеристики. Насос - единица оборудования, класс - насосы, соответствующие признаки... Как представить в системе редуктор? Заводить единицу оборудования "редуктор" и монтировать на насос, а затем заводить в системе класс редукторы? Заводить как материал? Как монтажный узел?
Из этого вытекает ишшо вопросик, но об этом позже. Все по порядку.
Убедитьно прошу помощи у уважаемой апчественности!

На мой взгляд.
1. Компрессор - ЕО
Редуктор - тоже ЕО
2. Произвести монтаж редуктора на компрессор.

Если необходима классификасия - завести соответствующий класс.
Если редуктор складируется - привязать материал.

А в чем, собственно, сложность?

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

Согласна с ВН , но еще все зависит от тех целей, которые ты преследуешь. Еще можно попробовать варьировать вышестоящими классами.
Может быть подробнее напишешь, что нужно получить конкретно

Да, полностью согласен по принципам. Использую такие же

Исходя из принципа создания ЕО (OlegDm): ЕО для редуктора заводить не следует, редуктор ремонтируется в ППР насоса.
Остается материал. Где хранить параметры редуктора? Заводить классификацию материала или добавлять поля в основную запись материала? А если параметров больше десятка? И все нужны, чтобы правильно заказать эту запчасть? Где их хранить? Как уважаемые PM-щики решают такую проблему?

Сделать компрессор ТМ, а электродвигатель, редуктор, механизм-насос заводить как ЕО, а можно компрессор и как ЕО представить и к нему заводить подчиненные ЕО: электродвигатель, редуктор, механизм-насос. Но смысл в том, что в технической системе редуктор является передаточным звеном между электродвигателем и насосом-механизмом и стоит с ними на одном уровне иерархии.
Что касается системы классов, то действительно, в виде классов ЕО необходимо создать класс редуктора, более того у редуктора могут быть подчиненные классы, например редуктор цилиндрический, редуктор конический, редуктор червячный и т.д. (каждый со своими признаками).

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

Все-таки лучше всего использовать классификацию материалов.

А доп.поля мы используем для ЕО и ТМ и только для наиболее важных технических параметров.

Может будет лучше вести материал партиями, и класифицировать партию.

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

PS: Пример абстрактный, так что просьба не цепляться

Это все замечательно, но хотелось бы узнать мнение, каким образом Вы выходите из такой ситуации: нужно вести данные, например, по редукторам, но с учетом характеристик и периода использования на том или ином насосе (т.к. возможны перемещения). Но сам редуктор не числится как основное средство. Я предложила вести редукторы как ЕО, далее создаем иерархию ЕО. Будет ли корректным вести эти комплектующие, для систематизации данных, новым типом ЕО? С одной стороны удобство - получение отчетов, диапазоны № другие, ракурсы... Какие в данном случае есть минусы в разделении на типы оборудования Возражения, которые я услышала были не убедительными. Мне интересно компетентное мнение коллег.

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


Ну исходя из моих скромных познаний в этой области все вроде как красиво и строго по рекомендациям саповской справки

[quote="Uukrul"]
Мне показалось что как раз мнение ты узнать не хочешь, ты хочешь чтобы кто-то тебе написал, что вот да, я редукторы в насосах веду таким и таким образом и все у меня вот так и так... Но помоему тут ни у кого насосы с редуторами пока не попадались, так что тебе высказали мнение, а не решение твоей проблемы.

К сожалению, это только Вам показалось (разве был повод не доверять моим словам ) Я не просила решения, а как раз изложила свое. А редукторов и насосов у меня близко нет на том проекте о котором я писала, просто продолжила вышеизложенный пример. Руководитель проекта, уперся и не хочет, чтобы я вела данные по комплектующим, как отдельный тип ЕО. РМ он не знает вообще, но из-за этого вопроса я концептуальный проект не могу закончить А время идет... Хотя я все равно буду настаивать на своем, но дополнительные КОНТРаргументы мне не помешали бы, тогда я бы знала свои слабые места и может быть придумала бы что-то другое Дифирамбы мне мне не нужны (себя похвалить я всегда смогу ), а как раз необходим критичный подход.

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


Тогда удачи...

Основным аргументом может быть только то, что ожидает заказчик от внедрения PM, точнее что он хочет учитывать, а твоя задача подсказать и настоять на выборе схемы реализации выдвинутых требований. Если он в предложениях указал, что хочет отслеживать данные по работе и обслуживанию редукторов в насосах, то какие проблемы... Заводить ОЗМ не целесообразно так как она не дает таких возможностей для учета, иначе нужно для бъектов ТОРО делать прямую связку ОЗМ-ЕО, какой смысл в дублировании информации, тем более что запасов по такой ОЗМ практически никогда не будет, так как все редукторы в эксплуатации, а насос поставляется сразу укомплектованый редуктором.