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

P.S.
И да, оперативный запрос это треш, чтобы его пользователю объяснить проще у манагера деньги на простенький абапотчет получить.

Дак юзер уже использует готовый отчет, он просто кликает по номеру инфо-запроса и нажимает "Выполнить", далее все как в обычной транзакции. Не? Ну, безусловно, кто-то дает полномочия на изменения самого набора/запроса, но к чему? В остальном очень удобный и простой механизм. Очень часто поступающий запрос нельзя решить стандартным отчетом. Точнее их тьма, но либо они перегружены инфой и ею нельзя управлять, либо все в итоге упирается как раз в нехватку полномочий. А сделать прямой запрос к таблице KNA1, к примеру, чтобы вывести только необходимую инфу + probably что-то свое подшаманить, сцепить... это дело получаса. И нет всей этой организационной возни с присвоением объектов полномочий. Ну да, ответственность по возможности или невозможности предоставления такой инфы запрашивающему полностью ложится на плечи конса, но мы предполагаем, что у всех есть своя голова на плечах В общем мое личное мнение - вещь полезная.

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

В свободной кодировке добавьте логику для обработки вызова F4 для поля

AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_field.
Ниже опишите логику для вызова по F4
Например, вывод значений из внутренний таблицы lt_int_table и возвратом поля FIELD
call function 'F4IF_INT_TABLE_VALUE_REQUEST'
exporting
retfield = 'FIELD'
value_org = 'S'
tables
value_tab = lt_int_table
exceptions
parameter_error = 1
no_values_found = 2
others = 3.

P_FIELD - это что будет?
Кодировка делается для инфо-набора. Поле подтипа в инфо-запросе может быть отмечено как критерий выбора. А может быть и не отмечено, тогда для него не будет сгенерирован входной параметр и непонятно, для кого делать ON VALUE_REQUEST FOR .

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

Это поле критерия выбора.
Если поле в инфо-наборе не отмечено как критерий выбора, то его и не будет на селекционном экране.
И экранная логика не будет работать.
В случае автора темы это будет то самое поле, которое не имеет средство поиска.
А мы просто подменяем логику обработки нажатия F4.

А программа инфо-запроса сможет сгенерироваться, если поле подтипа не будет критерием выбора? Мне кажется, будет синтаксическая ошибка. Я сам не пробовал. Вы уже так делали на практике?

Не получится так сделать.
В инфонаборе можно создать свое поле, а можно - критерий выбора. После привязки к группе полей поле (именно поле) станет доступно для выбора в инфозапросе. А свой критерий выбора появляется на селекционном экране всегда, это не поле и оно не привязывается к группе, не подлежит обработке через основной список и пр.
Имена критериев выбора для селекционного экрана программа генерирует далее по следующему принципу:
- пользовательские критерии выбора будут сохранять свое имя;
- все поля, помеченные как "критерии выбора" в инфозапросе (в т.ч. пользовательские поля) будут генерироваться по типу SP&1 и т.д.
Но на имена сгенерированных системой полей в кодировке at selection-screen ссылаться нельзя, будет ошибка. Система знать не знает, что это, так как обработка идет в ФМ со сменой головной программы. Ассайнить - да, можно. А сослаться или обработать - нет.
А вот обрабатывать пользовательские критерии выбора (созданные в инфонаборе как критерии выбора) - пожалуйста. Но вот вопрос: как заставить систему выбирать из таблицы согласно пользовательскому критерию выбора? Да никак вроде нельзя. Она и понятия не имеет, что такое наш, к примеру, ZSPRAS.
Поэтому кодировать at selection-screen, мое мнение, не получится.
А вот создать свое поле, добавить его в критерий в инфозапросе + прицепить это свое поле к элементу данных с грамотным средством поиска - это, кажется, единственное здравое решение в этой ситуации.

+1 к своему полю, релизованному по мануалам, через структуру к которому привязано средство поиска. Тогда PNP сама все отработет