ФМ изменения условий цены

Добрый день.

Через условия цены у нас задается рыночная цена для формирования потребности.
Кроме автоматического расчета цен есть и ручной ввод. Выдается только единицам, ответственным за ведение цен.
Для ручного ведения цен используются транзакции MEKH, MEK1, MEK2, MEK3
Вид условия "MP01" (если играет роль).
В последнее время возникла необходимость добавить проверки и ограничения на ввод цен.
В виду того, что в данных транзакциях такой возможности найти не смогли, решили создать отдельную программу, которая уберет лишнюю информацию, и включит все ограничения.

Просьба подсказать ФМ для ведения условий цен.

Сбытовые ФМ смотрел, но не увидел таких таблиц, которые используются в нашем случае, а именно A049 и KONP.

Так же просьба подсказать таблицы, в которых хранится история по условиям.

Сам спросил, сам отвечу.
Как то у часто такое получается.

Разобрался как использовать bapi_prices_conditions для моих целей.
Остался вопрос к местной аудитории.

Использую таблицу A049.
Там требуется указать Закупочную организацию EKORG.
Не нашел в указанной BAPI, где требуется вписать EKORG.
При это она проставляется.

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

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

Еще вопрос. Если не указать операцию (OPERATION), то обновляется только цена.
Если указать, 009, то может обновиться дата.
Где можно увидеть список значений OPERATION?

И снова отвечаю на свой вопрос:

DELETE '003'
CHANGE '004'
INITIAL '005'
INSERT '009'
REQUEST '018'

Привет!
Где-то встречал совет не использовать эту бапи для работы с ценовыми условиями
ВОт только не могу найти где...
На нескольких проектах для создания ценовых условий MM/SD использовали ФМ RV_CONDITION_COPY.
Нареканий не было.

Если есть возможность настроить IDOCs, то посоветую для работы с условиями использовать IDOC COND_A.

Внутри обработчика IDOC(ФМ IDOC_INPUT_COND_A) как раз вызывается ФМ RV_CONDITION_COPY.
Если использовать IDOC, то вам как минимум не придется заботиться о журнале обработки, все ошибки будут видны в статусах созданных IDOCs.

Программно создать IDOC можно с помощью ФМ MASTER_IDOC_DISTRIBUTE.

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

RV_CONDITION_COPY - как с ее помощью создать новые записи, я разберусь
Как вносить изменения? а не пересоздавать записи?

Т.е. у меня есть 3 операции: создание, изменение цены и дат, установка метки удаления.
Со всеми ли операциями справится данный ФМ?

P.S. На текущий момент в силу ограничения времени имитируем работу транзакций mek1 и mek2. Но в дальнейшем хочу сделать все красиво. По этой причине и интересуюсь данной темой.