Добрый день.
Ситуация следующая, по очень сложной логике у клиента подстьавляется ФП в заказ на закупку. Для реализации этой подстановки ипользуем user-exit на базе стандартного расширения SAPLFMD и пользовательской таблицы. ФП выбирается по многим показателям: виду затрат, типу контировки МВЗ/СПП-элемент/ТОРО-заказ, типу контрагента.

Но появились исключительные случаи, когда необходим ручной ввод. Случаи поддаются индентификации: необходим ручной ввод для ФП, если контировка на СПП-элемент и первые три символа СПП-элемента = XYZ и определенные виды затрат.
Можно ли как-то реализовать при помощи нового шага деривации удаление первого значения ФП, на основании первой логики, и осуществить ручной ввод?

Я сделала правило, затирающее первоначальные ФП, но при этом система не дает сделать выбор руками, пишет, что ФП не определена... Как это можно побороть?

Почему мне необходим новый шаг в стратегию:
1. Если ограничить условием в первом шаге, то очень много видов затрат, и почему-то не отрабатывает все равно:(
2. Дописать в ABAР-коде -ттоже не вариант, опять делать пользовательскую табличку...
Есть ли какое-то решение?

Заранее спасибо

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

Так не получится, потому как шаг инициализации как раз отрабатывает в случае, если ФП не пустое (поэтому в этом шаге вообще нельзя прописать какие-либо условия). Т.е. оно в любом случае будет затирать значение в этом поле, хоть введенное вручную, хоть нет.

Можно поставить правило "Не перезаписывать, если уже заполнено" на первом шаге, тогда система даст поменять ФП после того, как деривацией определилось какое-либо значение, но это тоже не есть гуд, потому что пользователи будут просто забывать менять ФП.

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

Писал не имея системы под боком под "Не перезаписывать если не пустое" как раз и подразумевал "Не перезаписывать, если уже заполнено", а шаг деривации подразумевал не новый, а который определятся юзер-экзитом. Думаю получится , если прописать два шага:
1. Автоматическая деривация через User-exit с прописанным условием: СПП-элемента <> XYZ или не определенные виды затрат. У целевого поля "Не перезаписывать, если уже заполнено"
2. Назначение технической ФП = ZN для СПП-элемента = XYZ и определенные виды затрат. У целевого поля "Не перезаписывать, если уже заполнено"
Создать проверку на невозможность сохранения документа с ФП = ZN.
Тогда и пользователь не сможет сохранить с технической ФП и значение введенное вручную не перезатрется шагами деривации. - Я как то заметил при трассировке деривации, что шаги user-exit на базе стандартного расширения SAPLFMD отрабатывают, как до так и после ручного присвоения и не учитывают условия которые прописываешь в условиях шага - обязательно нужно в код юзер-экзита условие писать. Чтобы не загружать подобными тонкостями хотел обойтись описанием шага юзерэкзита без условий, но с параметром "Не перезаписывать, если уже заполнено". Конечно для того чтобы проконтролировать одназначное заполнение пользователем значение вручную лучше как написал сейчас с условием и вторым шагом.

Так не проще ли просто на первом шаге деривации прописать условие, что ФП определяется только если СПП-элемент <> XYZ и определенные виды затрат?
В этом случае при этих условиях просто ФП не определиться и система не даст провести документ. И не надо будет никаких проверок делать.

На первом шаге безусловно нужно ставить условие, причем в текст юзер экзита.
Если до этого никакого другого определения ФП на более раних шагах не было, то согласен второго шага и не нужно делать.

Постараюсь немного прояснить ситуацию.
1. Первый шаг - это в заказ тянется тех.ФП из заявки на закупку
2. Второй шаг - техническая ФП в заказе перезатирается исходя из ряда условий реализованных при помощи пользовательской таблицы и user-exit. По маске виды затрат определить нельзя, т.к они из разных групп, и даже в одной группе идут не по порядку:( Так же заказчик против использования четко прописанных правил ограничения в user-exit, например, я не могу просто перечислить виды затрат, необходимо создать еще одну пользовательскую таблицу, и т.д. Кроме того, любое изменение разработки тянет за собой редактирование кучи документов и безумные процессы согласования!!!
3. Я использую не инициализацию, а присвоение. Попытаюсь, но не думаю, что шаг с "Не перезаписывать, если уже заполнено"отработает, т.к поле будет заполнена при помощи предыдущих шагов, и пользователи просто провтычут изменить что-то, а система даже не поругается:(((

Еще есть какие-то идеи? (Или я не все рекомендации рассмотрела???)

В общем, я добилась от заказчика, того, чтобы определились все-таки с ФП, ручной подстановки не будет, будем выполнять очередную переконтировку:)
Всем, спасибо за участие в обсуждении и советы!