Концептуально не верно, а технически без ошибок.

Это смотря какой концепт.

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

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

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

Если первое, то почему не делаете самое простое - просто убрать ВУ из схемы калькуляции? Если второе, то надо идти еще дальше, или удалить сам ВУ или убрать у него последовательность доступа.

Если в первом вас пугает т.н. "переходной этап", при котором изменение СК придется на не до конца проведенные документы в системе, то ИМХО лучше немного поработать с этим этапом, чем оставлять "мусор" в СК.

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

Пугает вот что, если я совсем уберу ВУ из СК. То если сторнируют документ, а потом захотят провести новый, то ВУ просто не будет т.к. срок действия нового ВУ еще не наступил. Проблема в том что значения ВУ меняются каждую неделю и новые ВУ не должны быть в предыдущем периоде.
Вот если бы в настройках можно было задать срок действия....

Хм, в записях условия нового ВУ вы можете указать начальный срок действия. Соответственно, если дата цены в документе раньше начального срока записи ВУ, то он у вас не появится в расчете.
Что касается старых ВУ оповестите пользователей, чтобы указали последний срок действия в своих записях по нему не 31.12.9999, а дату, после которой он не должен появляться. Со своей стороны в настройке ВУ укажите предлагаемую конечную дату (она должна по умолчанию ложиться при создании новой записи).


А вообще, то, что вы описываете, типичный пример переходного периода. Как говорится, волков бояться - волчат не рожать.

Дерзайте!

Аллё!?

Кстати, вопрос - у вас отчетность построена на видах условия?

2JaneSap.
у Вас условия исключается с помощью предпосылки в схеме калькуляции?

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

Вот решение твоей проблемы:
In the R/3 standard system, conditions with a zero condition value do not participate in exclusions according to exclusion groups. However, you can change the system response in such a way that conditions with a zero condition value also participate in exclusions.
To do this, add the value formula 038 (Include FV64A038), or a corresponding user-defined value formula that contains the source code from value formula 038, to the pricing procedure used for a condition that will definitely be part of the pricing result.

Ураааааааа!Я ИДИЁТ, УБЕЙТЕ МИНЯ КТО-НИБУДЬ! Заработало!Я ИДИЁТ, УБЕЙТЕ МИНЯ КТО-НИБУДЬ!Я ИДИЁТ, УБЕЙТЕ МИНЯ КТО-НИБУДЬ!!
Спасиб!