да мне незачем придумывать, потребности заказчика возникают вне зависимости от моих фантазий:)

курсы, хелпы читала, спасибо)

если у кого-то есть описание синтаксиса - буду благодарна за ссылку.

Даже не знаю как вам помочь...... Синтаксис изучил путем проб и ошибок. Российский метод - это не читать инструкции))))) А какая у вас проблема? Может и нам будет полезно озадачиться и помочь вам...

Я щас озадачена довольно специфичными вопросами (производственными):
Готовый продукт ГП1 изготавливается из полуфабриката ПФ1, ПФ1 изготавливается из полуфабриката ПФ2. У всех продуктов есть некая характеристика, скажем Цвет.

Если цвет ГП1 - красный, то цвет ПФ1 - зелёный, если цвет ПФ1 - зелёный, то цвет ПФ2 - синий.

(возможны ещё и варианты: если ГП1 - белый, то ПФ1 - фиолетовый или жёлтый и т.п.)

Создала таблички соответствия для каждого уровня. Прописала в профили отношения типа:
Table Color (Color = $root.Color, Color1 = $self.Color1)
Отношение работает, но только для первого уровня. Т.е. срабатывает для ПФ1, а для ПФ2 уже не подтягивает значение.
Причём, если я делаю моделирование для ПФ1, то в ПФ2 всё подтягивается как надо.

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

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

я написала, что использую таблицы для каждого уровня спецификации...

проблема в том, что значения подтягиваются только для первого уровня...

Сори, невнимательно читал Попробую разобраться...

GoSu, тебя не затруднит в двух словах описать основные операторы, например, $self., $root. и что нить еще...

Можно использовать следующие переменные объекта:
$ROOT является конфигурируемым материалом самого высокого уровня в конфигурации.
$SELF является материалом, которому присвоено данное отношение.
Материал, которому присвоена операция или процедура, является тем же самым материалом, для которого выводятся значения при операции или процедуре. Чтобы четко обозначить, что операции или процедуры выводят значения только для тех материалов, которым они присвоены, перед признаками ставится переменная $SELF.
В описании отношений, которое присвоено непосредственно материалу заголовка, как $SELF, так и $ROOT обозначают материал заголовка.
$PARENT относится к объекту, находящемуся непосредственно над $SELF в многоуровневой конфигурации.
Переменная $PARENT для материала заголовка не имеет смысла, так как материал заголовка не имеет материала более высокого уровня.
В описании отношений, присвоенном позициям спецификации, $PARENT ссылается на конфигурируемый материал, для которого была создана спецификация, а $SELF - на материал позиции спецификации.
Однако в многоуровневой интерактивной конфигурации $ROOT может ссылаться на два различных объекта.

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

SELF: конфигурируемая в настоящий момент инстанция
PARENT: объект, находящий непосредственно над объектом SELF в иерархии сортировки
ROOT: начальный объект (корневой объект сортировки)

Все зависит от задач......

Здравствуйте коллеги.

Есть два вопроса:
1. Сделал все как описано ниже, не могу установить статус отношения в "Деблокировано", он у меня всегда сбрасывается. У меня классификация ЕО (модуль ТОРО)
2. Каким образом можно сформировать значение признака? т.е. есть признак "Дата планируемой поверки/калибровки", он закрыт для редактирования. Хочу с помощью ФМ формировать его значение и показывать пользователю при входе в классификацию ЕО.

Slim, первое что надо сделать, это написать простенькое отношение, которое будет формировать значениепризнака равное константе. Это получилось сделать?

Спасибо, Левон, за ответ. С Первым вопросом уже разобрался: пришел с обеда и статус почему-то у меня поменялся и все заработало.

По поводу второго вопроса, никаких предположений нет. И вообше так можно сделать, как я хочу?

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

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