Добрый день

Столкнулась с такой проблемой

В классе конфигурации есть 3 признака с своими значениями:

TEST1 01 02
TEST2 03 04
TEST3 05 06

Признак TEST2 , TEST3 отображается только в случае когда для этих признаков указано отношение в виде предварительного условия TEST1 eq '01' and Specified TEST1

Тоесть, когда для TEST1 будет выбрано значение 2 - TEST2 , TEST3 - неактуальны и не должны отображатся

При создании предложения в конфигурации заполнены такие признаки с значениями

TEST1 01
TEST2 03
TEST3 05

При создании последующего документа заказа,копируется вся конфигурация из предложения.

Потом пользователю нужно поменять признак TEST1 с 01 на 02.

После такой замены ,по идее, признаки TEST2, TEST3 должны быть скрыты, но так как с предыдущего документа были заполнены поля , эти параметры висят с ошибкой "Конфигурация содержит конфликты"

Подскажите пожалуйста, как для признаков TEST2 , TEST3 указать отношение (предварительное условие или процедуру) чтобы при смене по признак TEST1 с 01 на 02, эти поля очищались и/или не отображались, так как эта информация для этого значения 02 не актуальна ?

Спасибо за помощь

Может стоит обратить внимание на признак копирование конфигурации в правилах копирования позиции торгового документа?

В правилах копирования типов позиций указана процедура копирования :"Новая конфигурация с механизмом конфигурации"...

Через стандартные операторы не получится. Только через функции (тр.СU65)

Да,есть такая транзакция, но как то не сталкивалась в работе с таким .... Направьте на путь истинный что в нём делать ..

Вкратце - абапить ))

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

могу только посоветовать использовать Условие выбора для Обязательно/Необязательно и вместо того, чтобы скрывать данные признаки, серить поля ввода, не убирая сами поля с экрана, может так устроит?

то есть, если пользоваться вашим примером



признаки TEST2 и TEST3 станут не обазятельными для ввода и станут не готовыми к вводу - не совсем то, что нужно, но без абапа

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

и согласен и не согласен с тобой, Troy

написать универсальную процедуру аннулирования признаков (конкретных) не получился. Под каждый признак-совокупность признаков своя вариативная процедура

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

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

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

хороший ход. согласен. тут был не прав

Спасибо за рекомендацию, сделали