Зависимые переменные в отчёте

Ramil

Коллеги, здравствуйте!
Мне необходимо реализовать следующую задачу: при открытии отчёта в окне переменных есть 2 переменные X и Y необходимо настроить между ними связь например если в X пользователь выбрал значение Х1 то в Y доступно для ввода только значения Y1, Y2, Y3, если же выбрали X2 то в Y доступны уже другие значения - Y4, Y5. далее эти переменные будут на отчёте (в ниспадающем поле ввода) и там они тоже доступны для корректировки.

Кто сталкивался с похожей задачей, подскажите в каком направлении двигаться:
- делать эти переменные customer-user и потом описывать алгоритм в CMODE, но тогда этот алгоритм будет работать только при открытии формы и не будет работать в уже открытой форме;
- как-то выкручиваться на отношении признаков, тогда не очень понятно как это реализовывать при открытии самой формы;
- через переменную "Путь замены" - с ней ваще ничего не понятно, поскольку ни разу с ней не работал;
- ...

заране благодарен за помощь.

murmur

Посмотрите вот эту ноту 1565809

fedo

Самое простое это связать признаки через соединение в RSA1. Тогда такое поведение формы запроса переменных будет реализовано автоматически.

Ramil

большое спасибо за советы!
попробовал оба, наиболее "то что надо" оказался вариант с признаком "с соединением", но есть одно НО. на этом признаке в кубах уже есть данные, и пытаясь к ним добавить соединения, система ругается, ну и советует "сначала удалить данные"

можно конечно повозиться, создать копию куба. туда скопировать, всё преднастроить и потом вернуть обратно. можете подсказать как сделать проще и безопасней для данных?

murmur

С вашего позволения, Ramil, из ЛС перенесу ваше сообщение сюда, чтобы решение темы стало законченным

Ramil написал(а):

Заголовок: Зависимые переменные в отчёте

murmur написал:

Посмотрите вот эту ноту 1565809

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

Предположим, мы создали два признака. PLANT и PROVIDER. В обоих мастер-данные содержат по три элемента. Затем, построили запрос и создали в нем переменные VAR_3 для PLANT и VAR_4 для PROVIDER.

Напишем код в BADI (пример с потолка, главное - идея), реализующий логику: если пользователь выбрал VAR_3 = 1, то предоставить пользователю возможность выбирать в переменную VAR_4 любое из значений мастер-данных поставщика (в данном примере читаю таблицу SID-ов, но ничто не мешало бы читать, например, таблицу атрибутов, если бы PROVIDER был атрибутом PLANT); если пользователь выбрал VAR_3 <> 1 (любое другое, включая пусто), то список выбора для VAR_4 будет пуст.

Code:

METHOD IF_RSR_VARIABLE_F4_RESTRICT~GET_RESTRICTION_FLAT.

  field-symbols:
    <var_range> like line of I_T_VAR_RANGE[].

  loop at I_T_VAR_RANGE assigning <var_range>
  where
    vnam = 'VAR_3'.

    if <var_range>-low = 1.

      data:
        l_s_range like line of c_t_range[].

      l_s_range-iobjnm = i_iobjnm.
      l_s_range-sign = 'I'.
      l_s_range-option = 'EQ'.

      data:
        v_provider type /BIC/SPROVIDER-/BIC/PROVIDER.

      select
        /BIC/PROVIDER
      into
        v_provider
      from
        /BIC/SPROVIDER.

        l_s_range-low = v_provider.
        append l_s_range TO c_t_range.
      endselect.

      exit.
    endif.
  endloop.

  if c_t_range[] is initial.

    l_s_range-iobjnm = i_iobjnm.
    l_s_range-sign = 'I'.
    l_s_range-option = 'EQ'.
    l_s_range-low = '999'.
    append l_s_range TO c_t_range.
  endif.

ENDMETHOD.

Особенности: Фильтр в BADI настроен на признак PROVIDER, признаки PLANT и PROVIDER настроены на просмотр "Values in Master Data table" (M) (можно настроить и на Q или D, поиграйтесь - увидите в чем отличия)

Минусы: Кнопка Check, по сути, бесполезна, хотя, если настроить признаки на просмотр (Q) или (D), то есть шанс сделать ее востребованной

Ramil

если в BADI вставлять код, не об этом BADI идёт речь - BADi RSR_VARIABLE_F4_RESTRICT_BADI? если так, то к у нас её нет. у нас версия системы 7.0. или же Вы предлагаете вариант - самописной BADI?

murmur

BADI называется RSR_VARIABLE_F4_RESTRICT, это не классическое, а новое BADI. Вам надо только реализацию сделать. Я вообще на miniSAP-е проверял (тоже, кстати, 7.0)

Ramil

похоже я не понимаю

у нас в системе нет такого BADI. в справке к этой BADI указано что оно появляется только с версии системы 7.3.

Ramil

ещё раз перепроверил. BADI RSR_VARIABLE_F4_RESTRICT у нас в системе нет

. получается что предложенный метод для нашей системы никак не реализовать? можно ли написать своё BADI?

murmur

В ноте 1416952 сказано, что данное BADI доступно, начиная с версии SAP NetWeaver BW 7.01 (SAP NW BW7.0 Enhancement Package 1). У меня дома стоит, сейчас еще раз посмотрел, SAP NetWeaver BW 7.02 (то есть EHP2), никаких проблем.

Попробуйте обосновать перед базисом, что вам надо, кровь из носу, EHP первой версии, как минимум... и дайте ссылку на ноту 1416952. Хотя базис, как правило, пошлет куда подальше из-за одной-то BADI-шки, но вдруг... :wink:

Ramil

вариант обновления системы отклонён

помимо использования этой BADI есть ещё идеи?

murmur

Полно!

- напиться
- уволиться
- заплакать
- вариант fedo

Зависимые переменные в отчёте

Кто сейчас на конференции