Меняю значение цены.

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

Данный индикатор уже стоит. Снял другой индикатор "Условие варианта", помогло. Но он нужен для расчёта цены с помощью таблицы условия 57 "Варианты". Без него выбор цены через вариант не работает. может я изначально неправильно выбор цены через вариант настраивал. Вопрос: как правильно ?
Пошёл "курить" help , если кто подскажет по настройке буду очень благодарен.

Была похожая тема, но там, похоже, ничего не решилось.
viewtopic.php?f=2&t=38989
Попробуйте задать вопрос в той теме, вдруг Наташе в итоге удалось разобраться с проблемой.

Добрый день, Наташа

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

Константин

Из ноты 455271

This is the standard system response.
The solution of the problem specified in Note 76774 does not apply to manually changed and copied variant conditions. If you change a variant condition manually and call a new pricing which copies manually changed conditions, the system always retains the manually changed condition. Then the system displays the condition twice in the pricing result: the manually changed condition (condition origin = 'A' and condition control = 'C') and the automatically redetermined condition (condition origin = 'A' and condition control = 'A'). The cause of this is the logic which recognizes corresponding pairs of automatically and manually changed conditions and valuates them: It only considers the condition key, however, not the variant key (also see Note 199618, 'An explanation' section).

Solution
None.
Works as designed.

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

Так у меня первое условие автоматическое и так не активное становится при изменении валюты в заголовке , просто их два торчит в калькуляции, народ (пользователи) напрягаются и требуют убрать дубликат. Вот.
Я так понимаю они говорят , что всё нормально и это не лечится. Типично для Sap.

а вот знаете, а может стоит использовать свою предпоссылку на появление ВУ в схеме калькуляции?

её смысл будет в том, что она гуд, когда такого же KSCHL ещё в ней нет и наоборот (анализировать структуры komp-ы различных видов, там и на x и на y, не помню какие есть, надо вспоминать)

так вот может и помочь, угу

Коллеги, вы будете смеяться... А я - стыдиться и плакать!
Прошу прощенья, что не ответила сразу! Была полная запарка (ЗООпарк-а!), потом забыла про пост...
Пробемса решилась после того, как я присвоила VARCONd 300 классу (как по хэлпу написано)... И "почистила" условия - оказалось, что пару условий я сгоряча пометила как "условия варианта", а они таковыми не являлись.
Вот так, пардоньте... а ведь несколько лет с условиями вариантов работала. И такой прокол!!!

Попробуем , может и получится. Justudent , спасибо за помощь.

добрый день всем!
Столнулись с похожей проблемой... только вот VARCONd 300 классу присвоен и галочки "условие варианта" стоят где нужно.... Но все таки все условия, которые берутся из варианта задваиваются при повторном расчете цен (например конфигурацию изменили или просто в нее зашли).

Подскажите в чем может быть еще проблема?

Вот засада! Тоже наступил на эти грабли!

У нас при создании заказа сумма статистического условия варианта PR00 утраивается.
Изначально сумма определяется по номеру материала из таблицы A304.
Затем она повторяется для всех признаков, которые могут участвовать в расчете цены, несмотря на то, что для вариантов в VK12 отсутствуют записи.

Другими словами, есть 3 признака конфигурации, которые могут участвовать в расчете цены.
Для всех них в схеме калькуляции подтягивается сумма полученная для номера материала.
Получается утроение суммы. Эта проблема возникает для статистического условия.

Как побороть эту неожиданную проблему?

В последовательности выбора цены стоит галочка "монопольный доступ к условию" для таблицы условия A304 ?

Везде стоит "монопольный доступ". Кроме того таблица A304 самая нижняя в последовательности доступа.

Против лома нет приема...
Тупо удалил лишние строчки в экзите USEREXIT_XKOMV_BEWERTEN_INIT (RV61AFZB).
Жизнь наладилась.