Продолжение цикла статей "Техники расширений стандартной системы SAP".

Все статьи цикла приведены внизу публикации.

1.Использование проверок во время ведения полей в диалоговых транзакциях системы (Техника Field-Exits).

Эта техника является одной из самых старых в системе и содержит два шага:

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

Предпосылка использования техники Field-Exit, следующая: в вашей системе на уровне профиля, должно быть разрешено использование Field-Exit. Для проверки работоспособности Field-Exit, необходимо выполнить транзакцию RZ11 – Ведение профильных параметров и проверить значение параметра abap/fieldexit, см. Рис.1. Для проверки состояния параметра, введите имя параметра abap/fieldexit, в поле «Имя параметра» и нажмите кнопку просмотра значений.

Рис.1: FE-0-1

Если в системе разрешено использовать расширения для полей экранов то значение переменной профиля будет установлено в состояние yes, Рис.2. Если значение переменной в профиле не определено или же установлено как no, то при попытке использования Field-Exit, будет выдаваться сообщение типа ENHANCEMENT с номером 032 – Система не сконфигурирована для полей пользователя. Вам следует обратиться к вашему администратору системы SAP, с целью установки правильного значения системной переменной в профиле системы. Эту процедуру нужно будет повторить для всех систем, т.е. разработки, тестирования и продуктива. Проблем, связанных с установкой данного параметра, я не встречал.

Рис.2: FE-0.2

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

Примечание: Ограничение: доступ только к изменяемому полю.Его в данном типе расширения можно обойти используя технику FIELD-SYMBOLS, хотя, скорее всего, SAP не будет рекомендовать эту технику обхода. Но, если очень нужно, эту технику обхода можно использовать. Подробнее об этом будет написано в конце настоящего раздела .

Для демонстрации использования техники Field-Exits, воспользуемся контролем полей в транзакции ведения инвестиционной программы. В ходе проекта элемент программы должен был содержать кроме стандартно имеющихся кодов БЕ и МВЗ, ответственных за реализацию элемента программы, код запрашивающей БЕ и МВЗ. К сожалению, транзакция ведения позиции инвестиционной программы не имеет возможностей расширения для добавления пользовательских полей. Разработчики посчитали, что тех 10 пользовательских полей, из которых 4 могут быть привязаны к простым справочникам, а остальные достаточно жестко типизированы, должно быть достаточно. Вынесение необходимых дополнительных полей (запрашивающая БЕ и МВЗ) в объект классификации, оказалось довольно медленным решением при построении отчетов по инвестиционной программе. Поэтому решено было использовать одно из пользовательских полей с типом CHAR(20). Однако к этому полю не привязано никакого справочника,  к тому же, в данное поле предполагалось записывать два значения по маске: «Код БЕ»/«Код МВЗ», поэтому как вариант решения, можно использовать проверку контроля введенных значений, используя технику Field-Exits.

1.1.Определение параметров используемого для Field-Exit поля

Определяем элемент данных, который привязан к переменной, которая, в свою очередь, привязана к полю экрана. Для этого стандартно в поле экрана нажимаем F1 – Переход к справочной информации к полю. Далее переход к техническим параметрам поля, Рис.3 .

Как видим элемент данных к полю экрана IMPR-USR00, называется IMA_USR00.

Рис.3: FE-1

1.2.Создание функционального модуля вызываемого для контроля вводимых значений в выбранном поле

Зная имя элемента данных, которое мы определили на предыдущем шаге, идем в транзакцию SE38 – редактор кода и запускаем отчет RSMODPRF, который позволяет создать нам функциональный модуль для проверки значений. Запускаем отчет, Рис.4.

Рис.4: FE-2

Вводим имя элемента данных, в поле «№ Поля пользователя». Можно этого не делать, если мы предполагаем, что экзит будет только один, но в общем виде, мы можем сделать различные функции проверки для элемента данных, в зависимости от того для какого поля и на каком экране используется данный элемент. Например, мы хотим, чтобы вызывался модуль Z в случае, когда поле находится в программе SAPLAIP2 на экране 0600, а в случае если это поле будет находиться на экране 0700, нам желателен  вызов модуля X. Вот тогда  и необходимо определение номера поля пользователя. В рассматриваемом случае такой проверки не нужно, поэтому оставляем поле не заполненным.

Итак, вводим имя элемента данных IMA_USR00 и выполняем отчет RSMODPRF . Система переходит к транзакции создания функционального модуля, при этом имя модуля будет сформировано по маске FIELD_EXIT_<Имя элемента данных>, при этом, если бы на предыдущем экране мы заполнили значение в поле «№ поля пользователя», то имя было бы сформировано по маске FIELD_EXIT_<Имя элемента данных>_<Значение введенное в поле № поля пользователя>. Фактически, таким образом, предполагается что вы не будете создавать более 37 различных вариантов функций для проверки значения.

Соглашаемся с предложенным именем функционального модуля  и переходим к его созданию, выбрав кнопку «Создать», Рис.5.

Рис.5: FE-3

Определяем группу функций и текст описания модуля, Рис.6.

Рис.6:FE-4

Как видим, несмотря на то, что имя модуля начинается не с разрешенных типов Z или Y, система разрешила нам выполнить ведение такого модуля. На входе нам предлагается переменная INPUT, а на выходе переменная OUTPUT. Типы переменных определяем, как элемент данных IMA_USR00, Рис.7.

Рис.7: FE-5

Теперь можно перейти к написанию кода реализации самой проверки, для этого переходим на закладку "Исходный текст" рисунок 7: FE-5.png. В нашем случае, значение, введенное пользователем в поле, проверяется на то, что первые символы это код БЕ, которая должна существовать в системе, далее идет разделитель в виде слеш («/») после чего идет код МВЗ. Код МВЗ «по определению» существует в той же контролинговой единице, к которой «привязан» код балансовой единицы.

FUNCTION field_exit_ima_usr00.
*"----------------------------------------------------------------------
*"*"Локальный интерфейс:
*"  IMPORTING
*"     REFERENCE(INPUT) TYPE  IMA_USR00
*"  EXPORTING
*"     REFERENCE(OUTPUT) TYPE  IMA_USR00
*"----------------------------------------------------------------------
  DATA: l_bukrs LIKE t001-bukrs,
        l_kostl LIKE csks-kostl,
        l_kokrs TYPE ima_vkokrs,
        l_str1 TYPE string,
        l_str2 TYPE string,
        lt_return LIKE bapiret2 OCCURS 1 WITH HEADER LINE.

* Если значение в поле не задано, тогда проверка не нужна
  IF input = space. EXIT. ENDIF.

  SPLIT input AT '/'(100) INTO l_str1 l_str2.
  CONDENSE: l_str1, l_str2.
  l_bukrs = l_str1.
  l_kostl = l_str2.

* Проверить код БЕ на существование
  SELECT SINGLE bukrs INTO (l_bukrs)
  FROM t001 WHERE bukrs = l_bukrs.

  IF sy-subrc = 0.
*   Получить код КЕ присвоенный к БЕ
    CALL FUNCTION 'RK_KOKRS_FIND'
      EXPORTING
        bukrs                  = l_bukrs
      IMPORTING
        kokrs                  = l_kokrs
      EXCEPTIONS
        assignment_not_allowed = 1
        insufficient_input     = 2
        no_kokrs_assigned      = 3
        no_kokrs_for_bukrs     = 4