Всем привет!
Грузим цены автоматически, при помощи Bapi из Эхеля.
Есть такая необходимость - при загрузке некоторые цены меняться не должны!
Можно ли какой-нить наворот придумать, чтобы это осуществить?
Оговорюсь, в самом Эхеле ставить какую-то метку нецелесообразно, поскольку люди отвечающие за загрузку прайса, могут намеренно менять "неизменяемые" цены.
Т.е. в VK12 надо предусмотреть какую-то приблуду, чтобы не давала цене меняться, а менять ее мог бы тока чел, со спец полномочиями.
В целом вроде так...

Заранее спасибо за идеи...

1) а при чем тут VK12 ? вы же используете BAPI , если конечно я вас правильно понял .
2) по каким признакам вы собираетесь разделять какие цены можно менять а какие нет, просто мне кажется логичнее было бы до вызова BAPI определиться какие записи будут менять цену а какие нету из экселевского файла ?
3) какие данные есть в экселевском файле ?

Какой BAPI вы используете?

Используем BAPICOND.
Да, вероятно VK12 тут не причем.
Я не знаю, что использовать в качестве признака, какие цены можно менять, а какие нет. До вызова Бапи на стороне Эхеля ставить отметку - низзя, ибо (было выше) - Оговорюсь, в самом Эхеле ставить какую-то метку нецелесообразно, поскольку люди отвечающие за загрузку прайса, могут намеренно менять "неизменяемые" цены.
В эхеле данные: ключи для загрузки в таблицы условий (таблиц две) и сами цены.

Вам тогда скорее надо найти какой то признак в VK12, наличие или отсутсвии которого проверялось бы в BAPI. Например поле KBSTAT статус обработки для условий. А ставить статус пускай, например, тоже через ту же приблуду может только специальный человек.
Конечно, так не прокатит если юзеры могут и ручками VK12 править. В таком случае именно на VK12 проверку придётся какую то навешивать

В нашей системе (ECC 6.0) BAPICOND что-то нету. Знаю есть такой BAPI_PRICES_CONDITIONS, неимоверно опасный, т.к. он практически делает прямой ? базы без каких-либо проверок.


Это похоже на "найди то не знаю что". Как вы собираетесь реализовывать задачу, если не знаете признаков? Вообще "изменять неизменяемые цены" - это oxymoron. Зачем позволять делать изменения в Excel, которые совершенно определенно не попадут в SAP? И как вы потом будете объяснять расхождения? Что-то IMHO много туманностей тут и непродумано как-то...

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