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

писали предпоссылку свою в схеме калькуляции по ВУ

Создал предпосылку '902' , видимые "рабочие" таблицы/cтруктуры: KOMK, KOMP, KOMT1, KONV ...
Возникло 2 вопроса.

1) По каким критериям определяется момент создания новой записи условия?
Предварительно определил:но вхождение многократное и ИМХО не однозначное.

2) Как определить наличие уже существуещего условия 'PR00', из внутр. таблицы или select-ом из KONV ?

я извиняюсь, не смогу сейчас прямо код выложить предпоссылки, нету системы той под рукой и не помню уже тонкостей ценновых структур и разбираться правда некогда, но просто при вводе перебиралась динамическая структура по текущей позиции и искалось такое же ВУ, вроде как KNUMH, если находилось, то предпоссылка на 4 - не выполняется. Точнее не могу. Хитрость может какая была, не помню. помоему всё было просто

Justudent, спасибо, буду искать дальше.

Предпосылки отрабатывают до расчёта цен. И проверять наличие того или иного условия в схкалк в них - дело неблагодарное. Лучше, имхо, в формуле стоимости это дело проверять. А проверять можно прямым считыванием из внутренней таблицы XKOMV по KSCHL. Или при помощи подпрограммы provide_condition_data и таблицы rkomv.

Поставил брейк-поинт в provide_condition_data, при создании нового условия 'PR00', provide_condition_data - не отрабатывает.

вообщем наверное я вас ввёл в тупик, так как в отладчике так и не смог действительно провести такую проверку, нету данных.

поискал на sdn, там советуют так




и так


Hi,

It is possible.



первое логично, второе как тоже рабочий вариант

Justudent, спасибо за ответ.
Т.к. ответственный за настройки не приемлет первый вариант, принимаю за рабочий второй.

Вопрос теперь: какой USEREXIT задействовать?

Гм... "Для того, чтобы что-то откопать, сначало надо это закопать". Как я сказал, вам надо в самописной формуле расчёта стоимости выбрать из таблицы xkomv ту запись, которая содержит kschl = PR00. Если такая запись есть, то можно утверждать, что условие уже существует в схкалк. Дополнительно можно проверить, введено ли оно вручную и прочее.

А вместо выборки из xkomv можно воспользоваться вызовом provide_condition_data в вашей самописной формуле стоимости (для этого надо этот вызов запрограммировать (читай "закопать")). Ну а потом уже ставить точку прерывания и смотреть (читай "откапывать").

Angie, спасибо за ответ.
Коллеги подсказали userexit USEREXIT_PRICING_PREPARE_TKOMP - сейчас рассматриваю это направление, если не получится попробую ваш вариант.

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

Раз пошли по ЮЭ, то, ИМХО, уж лучше использовать userexit_pricing_check (программа LV69AFZZ). Посмотрите, где он вызывается. На шаг раньше перед ним вызывается kondition_pruefen, в котором система проверяет введёное пользователем условие по своим критериям (присутствие в схеме калькуляции, например).

Вряд ли он поможет в вашей задаче. Он вызывается до расчёта цен и предназначен для других целей (новые поля в расчёте цен и всё такое).

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


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


Спасибо. Попробую этот вариант.