Эмммм...... Если я правильно понял, нужно найти все классы к которым присвоен признак1. Есть стандартный отчет, который это выполняет.

Добрый день.
Так получилось, что эта тема была отложена на 5 лет
Сейчас сравниваются два варианта ведения классов двигателей, на примере двигателя 4МТН225L6:
1) создается 1 класс двигателей (который называется "двигатели"), а всё остальное в признаки, в том числе и название двигателя:
Тип двигателя - 4МТН
Высота оси - 225
Длина - L
Число полюсов - 6
При таком варианте число значений каждого вида признака огромно. При этом признаки между собой могут вообще несочетатся, т.е. все висит на пользователе, когда он будет для ЕО выбирать признаки класса.
2) Создается на каждый тип двигателя класс (в данном случае класс "4МТН"), а все остальное в признаки.
При таком варианте количество значений каждого признака сокращается, они достаточно жестко привязаны к классу. Предполагается, что для пользователя это легче и ошибок меньше будет. Недостаток: вместо одного класса "электродвигатели" имеем 6000 классов
Вопрос: Скажите пожалуйста (кто ведет классификацию) имеются ли серьезные подводные камни (или садовые грабли), из за которых какой либо из этих вариантов менее предпочтителен?
Сейчас руководство склоняется к 1 варианту, но мы не можем понять: плохо это или нет.

Добрый вечер коллега, ну а если пойти 3.путём.
Ну если создать не 6000 классов двигателей, а только 5 или 6, ну двигатели для насосов, двигатели для тракторов, ну как то так. А так как один признак может использоваться в нескольких классов, то можете получить экономию. Да и в признаке если указать список значений, ошибок будет не много. Мы работаем так

Поддерживаю Süßstückchen.

При этом для признаков, значения которых зависят от других признаков, использовать описания отношений. Тогда ошибок типа: значение признака "Высота оси" не соответствует "Типу двигателя" - не будет.

Также не стоит пренебрегать проверками в user-exit при сохранении.

тогда этих отношений будет over 9000 чтобы проверить все возможные и допустимые комбинации значений признаков в классе
Тут два варианта:
- либо делать кучу шаблонных ЕО с классами, каждый из которых будет содержать определенный допустимый набор признаков с допустимыми значениями. А юзер, к примеру, только создает с образца нужную ему ЕО и все значения копируются.
- либо возложить ответственность на юзера, который заполняет значения в признаке. Классов будет с десяток к примеру, каждый класс содержит максимально возможный набор признаков и значений.

Подводные камни:
1) много классов - еще тот геморрой. Нужны пряморукие люди на поддержку этой структуры.
2) много проблем возникает при корректировке иерархии классов (если такая планируется) при активированном механизме наследования и уж тем более при наличии присвоений к классу

Красную кнопку создать не получится.

За чем же так "в лоб"?
В какой-нить настроечной таблице (или использовать для этого отдельные признаки) можно вести правила: зависимости значений одних признаков от значений в других.
В отношении (одном! для каждого признака; ну или одном для всех признаков одного класса) использовать эту таблицу.
При появлении новых, например, Типов двигателей - добавлять новое правило в таблицу, для чего можно сделать ракурс.

С другой стороны, аналогичное проще реализовать в user-exit.

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

Подскажите, пожалуйста, user-exit, о котором идет речь

Расширение CLFM0002 - Вызов данных классификации до сохранения

Возможно ли в exit CLFM0002 присвоить значения признаков для ЕО по одному признаку (что-то не получается) или там только проверку на заполнение признаков можно реализовать? Если не сложно, может кусочек кода есть

В exit CLFM0002 - только проверки.

Для присвоения значений используйте отношения в системе классов.

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

Уточню:


Индикатор: допустимо присвоение признаку нескольких значений?

Индикатор то стоит. Например: есть класс электродвигатели с набором признаков, одни из них TIP (тип двигателя) и P (мощность). При выборе пользователем значения TIP = МТКН , должны заполнятся несколько значений P (например 200,300,400). В таблице вариантов это не прпишешь,там связь между признаками должна быть однозначной. Как то так

Чего-то не понимаю:

Вроде из примера следует наличие трех допустимых значений, из которого пользователь должен выбрать одно?

Если нужны все три (присваивать сразу несколько значений не пробовал, но вроде должно сработать):

1. Создаем отношение; присваиваем классу.
2. В редакторе отношения - обращение к функции (создаем в CU65).
3. К функции прикручиваем ФМ. Это Z-ФМ внутри которого определяем нужные значения.
4. Признак получает значения из таблицы MATCH этой функции (читай ФМ)