Именно нужно генерировать интерфейс, при этом подключать к нему также сгенерированный запрос. Как правило интерфейс будет простым, самое главное, это КАК подключить запрос к форме и после этого КАК ее залить в хранилище

Ну так генерите программы на лету, заливайте их в хранилище и пользуйтесь. ABAP такое умеет - посмотрите как работает транзакция SE16.

То есть вы предлагаете на ABAPе написать?

Довольно логичное предложение, учитывая, что ABAP это стандарт для SAP и вдобавок это ABAP форум
Почему хочется писать на С# каком нибудь?

Так как сам являюсь программистом, а с недавнего времени перешел в SAP))) Гуру ABAPa, которым я предлагал написать такую автоматизацию, в одни голос отвечали - нереально.

у С# есть компоненты для доступа к SAP таблицам - посмотрите документацию по .NET Connector http://help.sap.com/saphelp_trbk30/help ... ameset.htm - например SAP table class.
Возможно если его возможностей хватит - то вполне реально написать такую динамическую "генерилку" на C#.
На абапе тоже есть оператор dynpro generate или что-то типа ( для внутреннего использования) - его использует BDT для динамической генерации экранов,
но вам с непривычки проще наверное на C#.

хотя нет - sap table - это класс для описания табличного параметра RFC модуля - одним C# не получится обойтись - надо и на абапе писать

угу, то-то и оно...

Нереально в данном контексте означает долгоб дорого и нецелесообразно.
Именно поэтому вас и просили конкретнее описать проблему. В SAP есть оргомный выбор интсрументов занесения данных в систему. Но без подробного описания никто не сможет вам ничего конкретного порекомендовать.

Ни разу не гуру, но я их понимаю.
SAP слишком хитро манипулирует данными, вряд ли удастся создать что-то лучше стандартных инструментов

Реализовывать лучше на абап. Ага. Все-таки родной язык системы.
Генерировать экраны через обычные абап-экраны - муторно. Приклад, которые бы это делали в стандарте - не так уж и много(пердложенный варинат с тр-цией Se16 не очень подходит, т.к. в ней генерируется особенный тип экрана -selection screen, который вобщем-то не предназначен для ввода данных, он больше предназначен для ввода ограничений для отчетов). Можно конечно извратится, но очень уж неудобно будет. Обычно делается супер-пупер экран с максимальным интерфейсом. Динамически у полей этого экрана устанавливается обязательность и видимость. Ну и доп.прошиваются необходимые проверки. Пример можно посмотреть в станд. ФМ POPUP_GET_VALUES
Динамич. формирование выборок - в общем не проблема, нужно только иметь для задачи формальное описание правил формирования запросов.
Если есть возможность использовать веб-динпро -то с его помощью генерировать динамический интерфейс гораздо проще. Но там будут свои проблемы связанные с его особенностями(начиная от производительности и заканчивая подвязкой своей логики обработки).

В целом ясно, но как понимаю, Вы предлагаете все же делать Web-форму ввода. Мне же все-таки нужно использовать экселевский файл в формате Analyzer'а. По поводу формального описания правил формирования - все норм, все будет.

Если я на основе формальных правил, хотя бы уж нагенерирую Bex-запросов это уже будет огромным шагом.

В SE16 есть маска ввода и редактирования значений, если натройки таблицы позволяют.

пердложенный

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

В данном случае "нереально" - ни в отношении меня. Не вижу больших проблем разобраться в АБАПовской "кухне", благо за плечами хороший опыт программирования. "Нереально" здесь - даже с учетом хороших знаний в области ядра системы и абапа сложно будет реализовать задачу. Вот так вот