Варианты экрана выбора

Если транзакция является отчётом, то у неё есть экран выбора.

И если параметров много, и вы часто заполняете их одинаково, то имеет смысл запомнить это в виде шаблона. Вот этот шаблон и называется вариантом.

А теперь – в подробностях…

Что это такое?

Экраном выбора (селекционным экраном) является экран, сформированный операторами PARAMETERS, SELECT-OPTIONS с вариациями. Он всегда имеет номер 1000. Такой экран может сгенерирован только автоматически и только для программы типа REPORT.  Вносить вручную изменения в такой экран — запрещается.

Если соотносить с вариантами транзакций (SHD0), то тут полное разделение:

Функции вариантов экрана выбора и вариантов транзакций реализованы похоже (похоже, но не то же).

Над экраном выбора всегда горит стандартная кнопка сохранения, и если её нажать, то появится экран сохранения:

Изменение экрана выбора

Вот тут можно порасставлять галочки и сохранить под нужным именем.

В-целом очень похоже на варианты транзакций, вот только значения “по-умолчанию” напрямую не показываются и напрямую не вписываются. Не очень приятное поведение.

Если к программе создан хотя бы один вариант, то появляется кнопочка, нажав которую можно выбрать варианты из списка:

Кнопка выбора на экране отчёта

NB: Мне вообще не нравится принятое название “селекционный экран” или “селективный экран”. В английском всё просто “Selection screen”.  Официально он называется всё-таки “экран выбора”, в этом можно убедиться в транзакции SE93.

 

Переносы

Варианты экрана выбора делятся на два вида:

Маркер CUS& нужно вводить ручками. Что-то вроде этого можно найти и в вариантах ALV, но там используется другой маркер-префикс: это прямой слеш, да и означает этот маркер чуть другое.

Если пользовательский вариант хочется перенести, то можно воспользоваться программой RSTRANSP. Можно включить и ручками, но там нужно будет склеить правильно имя объекта.

Если говорить о систематическом подходе, то лучше всегда придерживаться стандартной логики:

А то, например, может сложиться не очень приятная ситуация, если решат перенести корректировку варианта через запрос из разработки, и окажется что на продуктивной системе в варианте были сделаны локальные корректировки.

Использование

Пока пользователь у нас может только запустить отчёт, и потом выбрать из списка нужный. Можно сократить этот шаг:

 

Защита

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

А вот снять защиту с системного варианта непросто. Даже если зайти под владельцем, то снимать флаг защиты бесполезно – он при сохранении будет поставлен обратно. Получается что нельзя сменить владельца системного отчёта.

Ситуацию усложняет тот факт, что системные варианты хранятся в 000 манданте (и как следствие они являются независимыми от манданта). А лично меня не тянет идти ради этого в нулевой мандант. Поэтому даже снять флаг защиты с полпинка не получится. Ну а таблица не секретная: VARID; надо только написать вручную запрос учитывая мандант.

Снимаете защиту, и при следующем сохранении он защитится обратно, но уже на вас.

На закуску

Можно поглядеть на кучку программ RSVAR* – там есть небольшие помогалки на разные случаи.

Если что и стоит разведать дополнительно, то это механизм использования переменных.

С датой всё просто: если поле является датой, то там появляются дополнительные вкусняшки:

Переменные с датой

А вот если вам нужна какая-то условная константа с динамическим расчётом (например, код БЕ из профиля пользователя), то необходимо сделать какие-то дополнительные шаги. Вот это стоило бы копнуть дополнительно.

Может кто даст наводку?

Планирование

Есть стандартная функция платформы: можно запланировать регулярный запуск отчёта (например: ежедневно).

Если ввести параметры на экране выбора и запланировать запуск в фоновом режиме, то будет создан технический вариант вроде &0000000000012. В данном случае не играет роли, если вы перед этим вызвали какой-либо вариант для предварительного заполнения этих полей.

Поэтому если у вас есть динамические переменные выбора в варианте, то планировать следует из SM36 (где можно напрямую указать вариант), а не из SA38.

Опубликовано 05.06.2013 в 13:37 · Автор ivan · Ссылка
Рубрики: ABAP

10 комментариев

Подписаться на комментарии по RSS

  1. Написал(-а) Рыбальченко Алексей
    10.06.2013 в 21:43
    Ссылка

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

  2. Написал(-а) ivan
    11.06.2013 в 09:20
    Ссылка

    Само собой, обсуждение вариантов тут не затрагивает те вещи, которые пишутся напрямую в тексте ABAP-программы. И в каждой программе готовы появиться какие-то свои «феньки» в экранах выбора.

    Вот например, у меня есть стандартный трюк: если данный пользователь имеет права только на одну БЕ, то эту БЕ я прописываю на экране выбора и закрываю ввод. А это делается старым добрым ABAP-ом, без всяких вариантов.

  3. Написал(-а) T
    23.10.2013 в 13:42
    Ссылка

    Небольшое замечание не по сути статьи. Утверждение
    «Технически экраном выбора (селекционным экраном) является экран, сформированный операторами PARAMETERS, SELECT-OPTIONS. Он всегда имеет номер 1000. Такой экран может сформирован только для программы типа REPORT.» является не полностью корректным. Selection-screen может иметь и другой номер. Их может быть > 1. Никто не мешает создать его, например, в группе функций и затем вызвать через CALL SELECTION-SCREEN XXXX. А вот СТАНДАРТНЫЙ selection screen действительно имеет фиксированный номер 1000 и может быть только в программах типа REPORT.

  4. Написал(-а) ivan
    23.10.2013 в 14:00
    Ссылка

    Да, разумеется, есть такое пространство для манёвра. Просто в контексте данной статьи это не существенно.

    > Никто не мешает создать его
    Спорно. Я бы стал мешать разработчику так делать ;-)

  5. Написал(-а) ivan
    23.10.2013 в 14:10
    Ссылка

    Технически спорные формулировки тут ещё есть. Например:
    >Если транзакция является отчётом, то у неё есть экран выбора.
    Отчёт можно сделать и без экрана выбора. Но вот нормальные отчёты так никто не делает.

  6. Написал(-а) T
    23.10.2013 в 15:43
    Ссылка

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

  7. Написал(-а) Рустам
    20.02.2014 в 17:03
    Ссылка

    Спасибо Иван за статью. Даже не представишь как ты мне помог)

  8. Написал(-а) Валерий
    27.01.2017 в 12:48
    Ссылка

    Огромное спасибо за статью, Иван. Если впервые с этим сталкиваешься, как я, то информация очень полезная.

  9. Написал(-а) RPD
    23.02.2017 в 22:06
    Ссылка

    А вот если вам нужна какая-то условная константа с динамическим расчётом (например, код БЕ из профиля пользователя), то необходимо сделать какие-то дополнительные шаги. Вот это стоило бы копнуть дополнительно.

    транзакция STVARV.
    Но не думаю, что выйдет связать с профилем пользователя.

  10. Написал(-а) ivan
    23.02.2017 в 22:27
    Ссылка

    Выйдет конечно, но только если поле экрана выбора связано с MEMORY ID в ABAP:
    PARAMETERS: p_bukrs TYPE bkpf-bukrs MEMORY ID buk.

    Просто оно обладает недостатками:
    а) не всегда будет работать для стандарта, где иногда может не быть связки поля с MEMORY ID
    б) если пользователь в сессии заранее перебивал поле другими значениями, тогда будут подставлены последние, а не значения из профиля

Подписаться на комментарии по RSS

Написать комментарий