Проверки полномочий и платежи

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

Сначала у меня был стандартный интерфейс ввода «Требований авансового платежа» (f-47) и свой собственный отчетик следующего вида:

Место для проставления галочки уже было, кое-какие действия уже тоже были подвешены.

И вот мне захотелось сделать очень простенький воркфлоу на базе одного поля «Блокировка платежа», которое есть в создаваемых документах ТАП.

Проверка полномочий и операции на авансовые платежи

Сначала заходим в бухгалтерский документ и смотрим техническую информацию.

Создаём объект полномочий

Сначала заходим в транзакцию SU20 и добавляем нужное поле.

Справочник по таблице T008 – очень хорошо.

Затем создаём объект полномочий в транзакции SU21

Прописываем туда наше поле.

Добавление объекта в профиль полномочий

Затем следует добавить наш созданный объект полномочий в роль — в транзакции PFCG

Значения выбираются из справочника – просто замечательно.

Затем понятное дело нужно добавить в своего пользователя данное полномочия для тестирования.

У нас это разведено, поэтому для выполнения такого дела мне понадобилось обратиться к администратору.

А вот и простейшая программка для проверки:

REPORT  ZFIB_TEST.
PARAMETERS: p_ZLSPR like bseg-ZLSPR.
AUTHORITY-
CHECK OBJECT ‘ZLSPR’ id ‘ZLSPR’ field p_ZLSPR.
if sy-subrc = 0.
  
write: / ‘OK!’.
else.
  
write: / ‘Fail!’.
endif.

Проверяем, всё работает правильно (и даже не смотря на включенный профиль SAP_ALL).

Добавление смены статуса в интерфейс

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

Лепить много кнопок (по кнопке на каждый статус) – чревато регулярной правкой ABAP-кода. Делать их динамически – вероятно вообще нетривиально. Лепить своё окошко – лениво.

Добавлять свои элементы в интерфейс — сложно, так как отчетик был написан на базе  ‘REUSE_ALV_GRID_DISPLAY_LVC’.

Поэтому решил написать вот так

    WHEN ‘APPROVE’.

data: new_zlspr like bseg-zlspr.

"Вызываем средство поиска
       
call function ‘HELP_VALUES_GET_WITH_MATCHCODE’
         
exporting
            display                   =
‘X’
            matchcode_object          =
‘ZLSPR’
            INPUT_VALUE               =
‘X’
         
importing
            select_value              = new_zlspr
         
exceptions
            INVALID_DICTIONARY_FIELD =
1
            INVALID_MATCHDCODE_OBJECT =
2
            NO_SELECTION =
3.

if sy-subrc = 0 and new_zlspr ne space. "Если что-то выбралось
            AUTHORITY-
CHECK OBJECT ‘ZLSPR’ id ‘ZLSPR’ field new_ZLSPR. "запускаем проверку авторизации
           
if sy-subrc = 0. "Если авторизация прошла
               
data: TEXTL like T008T-TEXTL.
               
data: answer(1) type C.
               
select single TEXTL from T008T into TEXTL where ZAHLS = new_zlspr and SPRAS = sy-langu.
               
"Запрашиваем подтверждение
               
CALL FUNCTION ‘POPUP_CONTINUE_YES_NO’
                 
EXPORTING
                    TEXTLINE1           =
‘Вы действительно хотите изменить статус для выделенных документов?’
                    TEXTLINE2           = TEXTL
                    TITEL               =
‘Подтверждение’
                
IMPORTING
                   ANSWER              = answer.
               
if answer = ‘J’. "Если пользователь ответил "Да"
                   
loop at it_report where c = ‘X’. "Бежим по всем отмеченным строкам
                     
"Запускаем смену
                     
PERFORM SINGLE_CHANGE_ZLSPR using it_report-BUKRS it_report-BELNR it_report-GJAHR it_report-BUZEI new_ZLSPR.
                   
endloop.
               
else
                  
message W002(ZFI_BANK_PLAT). "Изменение статуса отменено
               
endif.
           
else. "Если авторизация не прошла
               
message E001(ZFI_BANK_PLAT) with new_ZLSPR. "У вас нет прав на работу со статусом &1
           
endif.
       
endif.

Выглядит просто и понятно. И при этом ещё и работает.

Проверяем, как работают полномочия, и заодно убеждаемся, что смена статуса откладывает данные в истории изменения документов.

Осталось в тудузник ещё отложить пункты:

  1. Согласовать с клиентом список статусов (и кто за них будет отвечать)
  2. Подвесить проверку авторизации и непосредственно в транзакции F-47, FB02

А вот и подошло время для подвески авторизации в стандартные транзакции:

Запускаем программу RSMODPRF.

Добавляем сюда наш элемент данных и экраны где он участвует.

Первая программа – работает при создании, вторая при изменении.

Потом пишем текст функционального модуля FIELD_EXIT_DZLSPR

    FIELD-SYMBOLS: <fs_ZLSPR> type DZLSPR.

if input ne space.
     
"Достаём предыдущее значение в поле
     
ASSIGN (‘(SAPMF05L)XBSEG-ZLSPR’) TO <fs_ZLSPR>.
     
if ( sy-subrc = 0 and <fs_ZLSPR> ne input ) or sy-subrc ne 0. "если произошла смена значения поля
        AUTHORITY-
CHECK OBJECT ‘ZLSPR’ id ‘ZLSPR’ field input.
         
if sy-subrc ne 0.
           
message E001(ZFI_BANK_PLAT) with input.
         
endif.
     
endif.
   
endif.

Проверяем работу. Всё заработало. Ура.

Вот я теперь думаю – а может всё такие стоит сделать проверку более стандартно (например, через GGB0)…

Осталось проработать только пункт (1) из тудузника и сделать прочие косметические правки.

Добавить комментарий

Ваш адрес email не будет опубликован.