Здравствуйте! Имеется ракурс ведения в директории Pкрс.
Как правило ведение ракурса создается опцией "генератор ведения таблиц" - создается автоматически сгенерированная группа функций, которая чудесным образом связывается с ракурсом.
Можно ли отказаться от этой опции и заместо нее привязать свою оригинальную программу ведения с нужным функционалом к ракурсу. Так, чтобы в SM30 по имени ракурса вызывалась эта программа?

Не совсем понял, что такое "программа ведения с нужным функционалом к ракурсу", но можно создать свою транзакцию для программы. Зачем упираться только в se30?

Это программа со своим ALV гридом, запросами, обработчиками, стилизацией.
Свою транзакцию к программе - это понятно. Но есть требование - запускать через SM30.

Чье требование?
SM30 обычно используется только в системах разработки для ведения настроечных таблиц.
А в системах разработки обычные пользователи не работают. Для команды внедрения/поддержки такой вопрос решается через руководителя.
Обычным же пользователям без разницы, какая транзакция, лишь бы пункт в меню был.

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

В генераторе ведения есть события и там можно писать любой ABAP-код и делать там что хочешь.
Средства поиска тоже можно делать на основе ФМников и тоже писать там любой ABAP-код.

Вы задачу более конкретно описать можете?

Плюсую. Плюс в ракурсе прямо на экране можно бабахать хоть свои кнопки, с произвольным текстом и пиктограммой.
Через эти кнопки вызывать абсолютно любой функционал. Реализовывать абсолютно произвольные проверки в PAI путем добавления собственных модулей. Хошь пей, хошь стирай. Да тут нормы ГТО можно сдать.

1. добавить свои поля. В ракурсе (Ркрс) поля добавить не смог, таблицы могут присоединяться только чрез отношения.
2. Написать свой SELEC запрос в котором будут данные для всех полей включая добавленные. Данные собираются из разных таблиц стандартных и настоечных.
3. Вывести на экран полученную таблицу, открывать доступ на запись предварительно проверив пользователя.
4. некоторые ячейки можно редактировать в зависимости от значения.
5. В определенных колонках по F4, или кнопке средство поиска в ячейке, вывести таблицу - справочник с данными чрез свой SELECT. Выбирать строку, вставлять значение из определенной ячейки.
6. Отредактированные значения проверить на правильность и допустимые диапазоны.
7. Сохранить низменные данные в настоечных таблицах, откуда они были загружены.

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

так Объект ведения поправите в этом случае, чтобы ведение конкретной z-таблицы в продуктиве выполнялось.


программные события на ракурс ведения докрутить.


тоже через события ракурса ведения доабапить емнип можно

Можно конечно удивить мир и изобрести свой ракурс ведения с нуля (хоть на ALV-редактируемом, хоть на сапквери). А из стандартного генератора взять только ФМы, которыми настроечные записи в транспортный запрос загоняются. В т.ч. вызывать эту альтернативщину по событию при запуске (инициализации) ракурса SM30. Но зачем? Стандартные лекала САПа предполагают что вы свой функционал под его стандарты подгоняете, а не изобретаете свой дублирующий ZSAP.

Так понял, по сабжу нужно для полей правильно определить домены и сделать средство поиска по уму. Единственное, для чего реализуют свой z-интерфейс, - это чтобы от глобальной блокировки записей уйти. Остальное все блажь.