Возможно. Не проверял. Но за информацию спасибо.

Друзья, еще один вопрос.
Ситуация следующая. Рассматриваем деблокирование в несколько уровней. Допустим, 2 уровня. Пусть нижний уровень выполнил деблокирование, затем выполнил верхний. На данном этапе нижний уровень может сам по себе, независимо от верхнего, может отменить деблокирование. На своем уровне. Тогда цепочка полностью отменится. То есть, нужно будет снова деблокировать согласно первоначальному порядку.
С точки зрения логики процесса это немного странно.

Скажите, можно ли заблокировать возможность отмены деблокирования заявки более низким уровнем без согласования с более высоким? Если да, то как?

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

http://sapboard.ru/forum/viewtopic.php ... c&&start=0

- должно дать ответ. Если коротко - порядок деблокирования не определяете, окончательное деблокирование за "главным начальником", соответственно только он отменит деблокирование или ABAPом.

Не работает. Даже если убрать порядок деблокирования. Без порядка получается, что неважно, кто из 2-х деблокировал первым. И тем более неважно, кто отменил деблокирование. Там получается только одно - два равнозначных человека должны деблокировать. Только при их параллельном деблокировании заявка деюлокируется окончательно. Это немного другой процесс по логике.

Кстати, по ссылке тоже ничего конкретного не прописано кроме EXIT_SAPLMLSR_021.
Кстати, не подскажете, что это, и где глянуть?

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

Тем не менее, это стандартное поведение системы. И с точки зрения логики процесса странностей особых нет.



Ну можно что-то придумать. Люди придумывают, по крайней мере. Как здесь, например.

Там не приведено конкретного решения кроме EXIT_SAPLMLSR_021. Так и не понял, что это и где.



Странность в том, что, получается, после визы главного начальника можно изменить все, что угодно. По идее процесс должен идти по цепочке в обратном порядкею То есть, только согласовав с начальником (он деблокирует), можно более низкому уровню открыть заявку на изменение.

По этому поводу еще вопрос. В деблокированной заявке почему-то позволяется изменять номенклатуру позиций. При этом, нельзя изменить количество или цену. Также можно менять даты поставки.
Спрашивается, каким образом это можно запретить?

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

Спасибо)) К моменту прочтения ответа сам уже разобрался))
Но все равно благодарю.

Добрый день, Коллеги!
Может быть, кто-нить встречался с подобным... даже не знаю как назвать...

Делаю элементарные настройки - стратегия выдачи по Виду заявки:
- Признак создал, значения ввел;
- Класс (для выдачи полностью) создал, признак пристегнул;
- Делаю стратегию и... на классификации... Ерунда какая-то получается - не пойму в чем дело...
Система ругается: "Ошибка в классификации (класс ZM_PR_OLL, вид класса 032)".
Проверяли и Признак, и Класс - всё нормально.
Настраивалось всё это не один раз... Поднял старые Протоколы настроек - по ним всё сделал. Такая же ерунда...
Где я лопухнулся - непонятно (бывает, что "прошлепаешь" элементарщину какую-нить...).

С уважением,

Здравствуйте, Коллеги.

Сбросил Буферы (тр. /$SYNC), сделал новые признаки, классы,
сделал новую стратегию и... всё получилось.
В чем была ошибка - так и не понял...

Успехов!

Бывает, у меня тоже что-то подобное было.

Вместо этого достаточно просто задать значение признаков через CL20N, а не черзе SPRO.

Напомните, пожалуйста - как мы даем конкретному юзеру права на деблокирование какого-либо кода.

Нигде не могу найти...


Спасибо

Объект полномочий для заявок M_BANF_FRG Код деблокирования в заявке

M_EINK_FRG вроде
но есть более надежный способ: ST01