Der neue (na ja - so neu ist er auch nicht mehr) IDoc-Monitor bietet gegenüber der guten alten WE02 bzw. WE09 doch einige Vorteile, insbesondere in punkto Übersichtlichkeit und Folgebeleg-Absprünge. Was mich jedoch nervt ist, dass es z.B. keinen Absprung in den POS-Monitor (WPER) für POS-Nachrichtentypen gibt. Ok - ist sicherlich auch eine etwas extravagante Anforderung, aber gut dass es da BAdIs gibt (Details s. Hinweis 1897880 - BAdIs für WLF_IDOC). 

Mithilfe des BAdIs WLF_REPORT_PROCESS_BD können eigene OK-Codes hinzugefügt und ausgewertet werden. Das BAdI beherbergt die Methoden...

ADJUST_STATUS

Hier kann ein eigener Oberflächenstatus gesetzt werden. Hierzu habe ich mithilfe der SE41 den Status STANDARD des Reports RWLFIDOC_NEW in einen (leeren) Z-Report kopiert und eine Drucktaste/Funktionscode (ZWPER) hinzugefügt.

In der BAdI-Implementierung setze ich lediglich über den CHANGING-Parameter CV_PROGRAM mein leeres Z-Programm, so dass der namensgleiche Status mit dem neuen FCODE gezogen wird.

method IF_WLF_REPORT_PROCESS_BD~ADJUST_STATUS.

     cv_program = 'ZWLF_IDOC'.

endmethod.

HANDLE_FCODE

Hier wird dann auf die (eigenen) Funktionscodes reagiert und (in diesem Fall) in die WPER abgesprungen. In der Struktur IS_DOC_LIST_OUT stehen die Daten des  aktuell selektierten bzw. markierten IDocs zur Verfügung.  Über den CHANGING-Parameter CV_FCODE_PROCESSED wird dem System mitgeteilt, dass der (eigene) Funktionscode prozessiert wurde.

METHOD if_wlf_report_process_bd~handle_fcode.

    CASE iv_okcode.
      WHEN 'ZWPER'.
        cv_fcode_processed = abap_true.
        CHECK is_idoc_list_out-docnum IS NOT INITIAL.
        CHECK is_idoc_list_out-mestyp(3) = 'WPU'. "nur für WPUxxx-IDocs
        SUBMIT sapmwper AND RETURN
               WITH p_dat_b = is_idoc_list_out-credat
               WITH p_dat_v = is_idoc_list_out-credat
               WITH s_docnum = is_idoc_list_out-docnum.        
    ENDCASE.

ENDMETHOD.

Dies ist natürlich nur ein Beispiel für eine sinnvolle Funktionserweiterung in Retail-Systemen. Euch fällt sicherlich auch noch was besseres ein...

Der o.g. BAdI ist übrigens nur ein Teil des Erweiterungsframeworks, welches in diesem Kontext zur Verfügung steht. Der Erweiterungsspot WLF_IDOC_PROCESSING umfasst weitere BAdIs, z.B. WLF_ENH_IDOC_DATA_BADI, mit dem der IDoc-Liste zusätzliche Felder hinzugefügt werden können.

Im Hinweis 590421 ist eine Möglichkeit beschrieben, die Mahnliste RFMAHN21 um eigene Felder zu erweitern. Bei der im Hinweis genannten Lösung handelt es sich jedoch um eine Modifikation, die vermutlich nicht in jedem System verbaut werden kann/soll. Alternativ lässt sich das Ganze auch mit einem impliziten Enhancement bewerkstelligen, was dann im technischen Sinne eben keine Modifikation mehr darstellt...

Hierzu wird einfach an das Ende der Routine APPEND_MHND_EXT2 im RFMAHN21 ein implizites Enhancement eingefügt, welches dann den Beispielcode aus dem o.g. Hinweis beherbergt (in leicht abgewandelter Form). 

Siehe auch hier