Здравствуйте уважаемые форумчане, специалисты в области FI-FM. Извините за много букв - просто у меня уже крик души.
По воле судеб мне пришлось заниматься внедрением модуля FI-FM (практически в одиночку). По профессии я кодер (абапер), причем с упором на логистику, но никак не в FI. И уж тем более не консультант ни в FI, ни в FI-FM.

Не так давно пришлось начать вникать в данную предметную область (опыта мало), но мое руководство это видимо не беспокоит - как говорится приказы не обсуждаются. Система ERP 6.0.

Поставлена задача по внедрению классического бюджета (не BCS), пока только в части закупки (интеграция с закупками).
Сценарий вкратце такой: в договорах настроить использование плана по облиго (это я сделал). При сохранении генерится резервирование средств, которая сокращает бюджет обязательств (профиль 350). Контроль наличия производится по деблокированноиму бюджету. Далее идет цепочка: заявка (статическое обновление), заказ на поставку, в котором через расширение по определенным условиям автоматически проставляется ссылка на резервирование (договор в заказе - определяет РС, ПФМ и фин.позиция (которые определяются через дерривацию) - определяют позицию в РС), - это тоже все сделал, затем входящая фактура, ТАП, платеж (там еще сыро и есть много вопросов). Я написал это для общего представления бизнес процесса. Вопрос не в этом, а в процедурах актуализации бюджета.

Итак... Одна из задач начальства - написать Z разработку в виде одной транзакции (некое подобие АРМа пользователя) которая бы объеденяла функционал всех FR транзакций (ввод исходного бюджета, переносы, распределение, расширение, сокращение, деблокирование). Мотив руководства следующий. В стандартной транзакции по вводу исходного бюджета (FR50), да и в других (расширение, сокращение и пр.) нет текстов отражающих наименование ПФМ и фин.позиций - вроде как не нагладное для пользователей представление. В других транзакциях (к примеру изменение БО - FR01) очень непрозрачный и запутанный интерфейс - уровни иерархии представлены для всех ПФМ и фин.позиций, нет так же текстов определяющих наименование ПФМ и т.п.

Вобщем сделай нам разработку, где все ПФМ были бы представлены в виде дерева (ALV-Tree), чтобы на каждом нижнем уровне ПФМ была видна доступная для резервирования остаточная сумма бюджета. Разбей экран на две части (слева дерево ALV-Tree, справа спиcок всех фин.позиций (простой ALV-Grid) для текущего ПФМ, где было бы видно на какие финансовые позиции разнесены суммы для данного ПФМ.
А сделай еще так, чтобы можно было можно было бы мышкой (drag and drop'ом) перетаскивать суммы с одного ПФМ на другой (аналог переноса FR58).
И сделай еще так, чтобы можно было распределять у выбранной фин.позиции значения на нижестоящие в иерархии фин.позиций суммы (аналог распределения - FR54). Ну и кроме того чтобы можно было вводить на выбранный ПФМ расширения/сокращения, производить деблокирования.

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

Сперва напишу как технически реализоввывал задачу, а потом задам вопрос о том что меня смущает.

Техническая сторона решения.
Для решения данной задачи я использовал ALV-Tree который отображает иерархию ПФМ для указанной ЕФМ, версии бюджета, финансового года, категории бюджета (обязательства, платежи и виду бюджета (исходный/деблокированный).
В иерархии видны доступные для резервирования суммы на каждом ПФМ.

Для представления иерархии в дереве, обрабатываю таблицы FMHIVARNT, через ФМ FM_HIVARNT_READ_HIERARCHY считываю иерархию и по полученным данным в цикле строю дерево в ALV-Tree.
В этом же цикле для каждого ПФМ расчитываю доступный остаток денежных средств. Обрабатываю таблицу BPJA. Для исходного платежного бюджета по типу значения WRTTP in ('43', '46'), для исходного БО по типу значения WRTTP in ('70', '72'). Для деблокированного платежного бюджета по типу значения WRTTP in ('44', '46'), для деблокированного БО по типу значения WRTTP in ('71', '72').

Для функций ввода, расширений, сокращений, деблокирований исх.БО и БП использую ФМ KBPI_BUDGET_ENTER.
Для переноса использую ФМ KBPI_BUDGET_TRANSFER. Для распределений ФМ KBPI_BUDGET_DISTRIBUTE.

Теперь сам вопрос.
Бюджет вводится транзакцией FR50. В моем понимании при необходимости изменения бюджета (сократить или расширить используются транзакции FR52 - ввести расширение и FR53 - ввести сокращение). Для чего в таком случае нужна транзакция FR01 - изменение исходных обязательств?
Опять же непонятно если мы ввели расширение, то для уменьшения можно использовать сокращение. Зачем в таком случа нужны транзакции FR15 - изменение расширения и FR23 - изменение сокращения. В чем суть? Зачем изменять сокращение? Можно же просто использовать ввод расширение - для увеличения бюджета и сокращение - для уменьшения бюджета.
Еще есть распределение исходного бюджета и деблокированного (тр. FR54 и FR55)/ Не понимаю зачем тогда нужны транзакции распределения расширений и сокращений (FR56 и FR57)? В моем понимании ввод расширений и сокращений добавляют или сокращают денежные средства в, образно выражаясь, "общем котле". Зачем нужно отдельно распределять расширения и сокращения?

Еще раз прошу прощения за много текста. Хочется услышать объективный ответ по использованию данных транзакций. В чем заключается такая концепция? И прошу дать оценку возможности реализации Z-функционала по актуализации бюджета взамен этих транзакций.
Какие сложности и подводные камни могут возникнуть в процессе дальнейшей разработки данной Z функциональности. Решима ли данная задача собственными силами или это утопия?