Итак, существует задача автоматизировать бюджет. Бюджет движется снизу вверх. В данный момент настраивается STS. Необходимо чтобы бюджет по каждому филиалу (по филиалам сделана иерархия) проходил около 5-ти ступеней утверждения.

Исполнитель ->Начальник1->Начальник2->Начальник3-Начальник4

Решили разделить сеансами планирования.

Исполнитель ->Начальник1
Исполнитель ->Начальник2
Исполнитель ->Начальник3
Исполнитель ->Начальник4

Начальник соответственно будет ответственным, а исполнитель – заместителем.

Меня интересует, каким образом я могу ограничить возможности исполнителя, чтобы он мог ставить статус на утверждение, но не мог утверждать или отклонять?
То есть сейчас если исполнитель – проставлен заместителем, он может выставлять любой статус, в том числе «утверждено», хотя по идее такую возможность должен иметь только ответственный.

Стандартные объекты полномочий для СТС не позволяют такого сделать

Я кстати обратил на это внимание... И каким образом выкручиваться? Точнее так: Каким образом люди выкручиваются или почему у них не возникает подобных проблем?:)

Могу предложить 3-и варианта:
1. Прогнуть бизнес-процесс под стандарт системы,
2. Залезть в BSP код STS приложения и в зависимости от sy-uname скрывать не нужные Вам кнопки, например (сам BSP менял только для приложений сконструированных в Web interface Builder, поэтому где и что сделать подсказать не могу, но STS тоже обычное BSP-приложение, надо копать)
3. Использовать более сложный функционал Workflow или Webflow

Спасибо за обстоятельный ответ. Но по малообразованности задам некоторые уточняющие вопросы.
1. Может я не совсем понимаю стандарт системы, но неужель исполнитель "по идее" должен иметь возможность ставить любой статус? Или он не должен вообще не должен иметь возможность менять статус, а только заниматься непосредственно планированием?..
2. Как я понял SE80? Спасибо поковырялся чуток вроде бы действительно можно abap'ом(напильником) доработать. Но это крайний случай:))
3. Про это еще буду ковырять. Но пока хотелось бы остановиться на первых двух вариантах.

А у вас нет тут противоречия?

По идее это должно выглядеть как
Исполнитель ->Начальник1
Начальник1 ->Начальник2
Начальник2 ->Начальник3
Начальник3 ->Начальник4

А это укладывается в стандарт. Или все не так?

Ну во первых, начальник ничего в папке исправлять не будет. Если что то не понравится, ну допустим начальнику №3, переделывать все равно должен будет исполнитель.
А во вторых, если бы я и делал так, это никоим образом не решило мою проблему. Все равно в Сеансе: Начальник2 - Начальник3 Начальник2 (Долженствующий дорабатывать бюджет в случае если он не устроит Начальника3 )не должен иметь возможности ставить статус "утверждено". Чего я пока и не смог добиться

Вопрос: если начальнику №3 что-то не понравилось и исполнитель все переделывает, то начальники №1 и №2 уже не участвуют в утверждении новой версии бюджета?

Если начальнику №3 не нравится бюджет, то он его реджектит и каскадно скидываются все утверждения нижестоящих начальников. И все начинается по-новой, начиная с исполнителя:)

Неужели плохая схема?:)

Ответ: Конечно не участвуют. Мавр сделал свое дело, мавр может уйти... Схема может быть хороша, если это нужно, хотя мне непонятно как ее реализовывать средствами СТС.
В моем же случае это и вовсе ненужно

Ну значит у вас не схема

Т.е. ситуация у вас примерно следующая: есть исполнитель, он планирует для себя какую-то сумму в бюджете и утверждает ее у нескольких начальников департаментов (отделов, не принципиально).

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

Похоже все-таки создается автоматизированный бардак, то есть абапить вам надо будет долго и упорно

Отличный термин . Как жаль, что это так часто присутствует на проектах.

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