Всем привет.

Для формирования отчета в BEx Query Designer в моем случае нужны переменные типа Customer-Exit.
Как известно для этого используется транзакция CMOD и функция EXIT_SAPLRRS0_001 проекта RSR00001.
В этой функции находится INCLUDE ZXRSRU01, в котором и задается код для таких переменных.

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

И вот здесь возникает проблема...
Насколько я понимаю, user-input всегда, в конечном счете, хранится в таблице I_T_VAR_RANGE.



И казалось бы всё просто, надо всего-лишь очистить эти строки в этой таблице, и продолжить выполнение программы.

Я пробовал сделать это разными способами, например вот так:



Причем как на уровне I_STEP = 2 так и на уровне I_STEP = 3.

И согласно отладчику - все ОК, эта строка успешно удаляется.
Но на следующем уровне, она возникает в I_T_VAR_RANGE снова, словно феникс из пепла.

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

Откуда же она берется снова?
Можно ли вообще как-то программно зачистить этот статический фильтр, чтобы он вообще никак не влиял на результаты отчета?

На I_STEP = 3 Вы можете только проверить введенные значения и либо принять их (тогда выполнение отчета идет дальше), либо отклонить с созданием особой ситуации и выводом сообщения (тогда процесс автоматически сбрасывается к I_STEP = 2, но добавить или удалить значения из I_T_VAR_RANGE на I_STEP = 3 Вы не можете.
Попробуйте на I_STEP = 2 добавить новую строку с теми данными, которые Вы хотели удалить, при этом в поле SING указать E (Exclude).

P.S. Переменная при этом вроде бы должна быть типа "Опция выбора".

Добрый день, если я правильно понимаю суть вопроса, то как вариант можно создать две переменные одна из которых - "Готова ко вводу" и заполняется вручную, пользователь вводит значения на СЭ, затем во второй переменной типа Customer-exit считываются на этапе I_STEP = 2 значения первой, производятся необходимые Вам расчеты, заполняется внутренняя таблица, E_T_RANGE для второй переменной.

Air_demon

Cпасибо за идею, попробовал так.
Однако, такой подход вызывает свои собственные трудности

Да, действительно, если пробовать такую комбинацию типов:
Переменная ввода (UI) = Interval, Кустомер-экзит-переменная (CE) = Interval.
И вот такой абап-код:



То возникает ошибка на уровне CE-переменной.

Если же использовать переменную типа Опция Выбора, то какая бы переменная ей не являлась (не важно, UI или CE, или обе), то возникает ошибка наподобие такой:


Получается, что для атрибутов типа дата вообще нельзя использовать переменные Опция Выбора, так чтоли...

Но не понятно как реализовать эту идею с исключением диапазона.

AlexanderGamov

Добрый день, а что означает фраза "пользователь вводит значения на СЭ"?

Но, если я правильно вас понял, я примерно так и делаю (точнее, я уже пробовал различные комбинации).
Однако возникают всяческие ньюансы, которые всё портят.

В моем случае переменная-1 (Customer Exit, Multiple Single Values) берет значения из переменной-2 (User Input, Interval)
И посредством SELECT на основании переменной-2 формирует выбор из 5 значений которые попадают в E_T_RANGE.
И на этом этапе все работает верно, и так как нужно.

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

Причем, мне индусы на другом форуме подсказали, что во вкладке Фильтр значения более глобальны, пробуй делать через Ограниченные Показатели. Ну я попробовал сделать и так, но это помогает лишь отчасти (если диапазон не соприкасается с sy-datum), плюс дает дополнительные проблемы, связанные с обязательностью ввода...

Фишка в том, что у меня есть другой почти такой же отчет, он не требует ввода от пользователя, и юзает только I_STEP = 1 уровень.
И в нем стоит точно такой же SELECT что и здесь. И все прекрасно работает. Но вот стоит только пропускать все через I_STEP=2, то сразу идут искажения.

Простейшим решением проблемы была бы просто возможность зачистки I_T_VAR_RANGE, однако может быть это вообще невозможно (у нас кстати SAP GUI 7.20). Если это так, то жаль, тогда придется выдумывать какие-то шаманские фокусы. В принципе, если интересно, я могу описать задачу подробнее, это в целом несложный отчет на базе признака с составным ключем (вкладка Compound). Возможно есть какое-то более оптимальное решение.

Какая ошибка?
Если ругается, что нельзя применить L_S_RANGE-SIGN = 'E', то поставьте "I" и попробуйте сделать исключение на уровне определения ограничений в QD.


А переменные находятся в разных областях запроса (одна в фильтре, другая в значениях по умолчанию)?

Вот такая, весьма невнятная:




[s]Почему-то у меня эта опция не всегда доступна. Как-то раньше мне удалось включить исключение для старой переменной типа даты, а вот теперь эта кнопка почему-то не активна.

Есть какая-то специфика?[/s]
C этим моментом разобрался. Просто переменная не была сохранена.

[s]Но даже когда я вставлял старую переменную таким образом, получалось вот такое:

То есть вероятно гарантии нет, но я еще пробую как-то подкручивать.[/s]
Ошибки удалось избежать, продолжаю экспериментировать.

Я пробовал по всякому. Сначала переменные были в области "Фильтр" причем по такому принципу:

Атрибут1:
Переменная ввода1
Переменная C-Exit1

Атрибут2:
Переменная ввода2
Переменная C-Exit2

Причем Переменна С-Еxit2 использует для своей работы Переменную Ввода1.

Впоследствии, я перешел на чуть более результативный подход:


Однако тут возникают свои проблемы: эти переменные, вмонтированные в ограниченный показатель (или это точнее сказать "локальный выбор?", потому что он только для отчета создался), почему-то превращаются в ОБЯЗАТЕЛЬНЫЕ, а это не желательно.
И там еще остается проблема неправильного прощета, когда диапазон касается sy-datum.

ОК, отчасти всё получилось.

Но, конешно, вопрос очистки этой таблицы так и остается открытым.

Но в моем случае удалось применить обходной маневр этой проблемы.
Спасибо Air_Demon'у за поддержку.

По иронии, главная загвоздка была в том, что UI-переменная была типа "Интервал", а СЕ-переменная "Несколько значений".
Не заметив этого момента, я потратил много времени на попытку обойти "вероятные системные ограничения", а ларчик просто открывался.

В результате нашлось такое решение, CE-переменная превращается в диапазон от 00000000 до sy-datum, что модифицирует диапазон введенный пользователем.