DATA pernr TYPE pernr_d VALUE 1.
DATA(time_accounts) = cl_hcmfab_att_abs_bl_apis=>get_instance( )->read_time_accounts( iv_pernr = pernr
iv_begda = sy-datum
iv_endda = sy-datum ). "iv_endda is never used!
cl_demo_output=>display( time_accounts ).
Although there is an obligatory iv_endda parameter, it is never used inside of method read_time_accounts. Instead, there is some logic which checks for a T77S0 Parameter, and it will use either highdate or begda as endda value.
IMO, it would have made sense to mark iv_endda as optional, so it would be downward compatible and the parameter could be omitted on newer releases. Now it is a bit misleading.
Customizing SPRO → Personnel Management → Employee Self-Service (Web Dynpro ABAP) → Service-Specific Settings → Working Time → My Overtime Requests.
Adjusting the Fiori UI
If you want to hide fields in the Fiori frontend, or you want to adjust some labels, you can simply do this via Customizing: My Overtime Requests → Layout of the Web Application → Define Field Selection
Multi-Level Approval for Time Data Requests (HRPT_B_TMD_MULTI_APPROVERS)
The BAdI is called when opening the My Overtime Request App and a second time when clicking on the New Button to create a new OVT request. It’s not triggered when sending the request, what I initially expected. To reuse the code from the sample class,
* "Determine approver level
* DATA(cust_key_request_fields) = VALUE cl_hrpt_ovt_const=>ovt_cust_key_request_fields( pernr = iv_pernr
* ktart = iv_subtype
* date = is_request_period-start_date ).
* TRY.
* DATA(approval_settings) = cl_hrpt_ovt_cust_factory=>get_customizing_reader( )->get_approval_settings( REF #( cust_key_request_fields ) ).
* CATCH cx_hrpt_tmd.
* RETURN.
* ENDTRY.
* IF approval_settings-use_multiple_approver = abap_false.
* RETURN.
* ENDIF.
....
* "If no last approvers exist, use line manager, HR BP and HR Admin by default
* CALL FUNCTION 'BAPI_GET_LINE_MANAGER'
* EXPORTING
* im_objid = iv_pernr
* IMPORTING
* es_approver = line_manager
* ev_has_manager = approver_exists.
* IF approver_exists = abap_true.
* last_seqnr = last_seqnr + 1.
* line_manager-seqnr = last_seqnr.
* APPEND line_manager TO rt_approver_tab.
* IF lines( rt_approver_tab ) >= approval_settings-approver_level.
* RETURN.
* ENDIF.
* ENDIF.
you have to set the amount of approval steps in the customizing.
Custom Workflow
If you want to replace the default Workflow WS02400057 (PT_OVTREQ) with a custom one, you must adjust the customizing (as described here for the standard WF), and you’ll need to create a new BAdI Implementation for HCMFAB_MYOTQ_APPROVAL_INBOX analog HCMFAB_MYOTQ_APPROVAL_INBOX to get the Approve and Rejects Buttons working by providing the Workflow-ID and decision Step-ID.
Extensibility
Although it should be possible to extend both Fiori Apps via Adaptation Projects, I was unable to do so. Either it’s a problem with the new adaption editor, which got new released while writing the blog, or it is a problem with the apps itself. Whatever I tried, I was always running in issues.
Therefore, I did it the “classic” way and created an Extension Project and used the provided Extension Points. For the Approval App, I was unable to preview the application directly in BAS, perhaps because it is only an Inbox integration and does not run standalone. I therefore always had to deploy, to test my changes.
Badi Implementierung anlegen und Filter-Ausprägungen hinzufügen. Es muss für jede benötigte Filter-Ausprägung eine eigene BAdI Implementierung und Klasse angelegt werden.
Klasse anlegen und in der Interface Methode die Kundenlogik, wie in der Dokumentation empfohlen, in eine private Methode kapseln. Bsp.:
METHOD if_ex_pt_blp_user~process_data.
CHECK i_record IS BOUND.
IF i_record->data->category = cl_pt_tmw_tdm_const=>cat_infty
AND i_record->data->type = '2001'.
"hier die erforderliche Logik rein, z.B. weitere Prüfungen
process_it2001( EXPORTING i_record = i_record " Aktueller Satz
i_time_data = i_time_data " Aktuelle Zeitdaten
IMPORTING e_messages = e_messages " Ausgabemeldungen für die Transaktion
e_time_data = e_time_data ). " Neue und geänderte Daten
"An den konkreten Infotypsatz kommt man z.B. folgendermaßen:
DATA(record_data) = CAST cl_pt_td_it2001( i_record->data ).
DATA(p2001) = record_data->if_pt_td_it2001~p2001.
ENDIF.
ENDMETHOD.
Auswertungsweg O-O-S-P liefert unter einer gegebenen Org. Einheit alle Personen, auch aus tieferen OE.
T-Code: OOAW
DATA(lt_actor) = VALUE tswhactor( ).
CALL FUNCTION 'RH_STRUC_GET'
EXPORTING
act_otype = 'O'
act_objid = lv_oe " die Org. Einheit, von der gestartet werden soll
act_wegid = 'O-O-S-P'
act_plvar = '01'
act_begda = sy-datum
act_endda = sy-datum
act_tflag = space
act_vflag = space
authority_check = space
TABLES
result_tab = lt_actor
EXCEPTIONS
no_plvar_found = 1
no_entry_found = 2
OTHERS = 3.
IF sy-subrc <> 0.
" do error handling
ENDIF.
" Nur Pernr's relevant
DELETE lt_actor WHERE otype <> 'P'.
" Doppelte Pernr's entfernen
DELETE ADJACENT DUPLICATES FROM lt_actor.
Zum Testen des Auswertungsweges kann man den Report RHSTRU00 verwenden. Einfach Planvariante, Objekttyp und eine ObjektId einer Org. Einheit eingeben, sowie den Auswertungsweg und Statusvektor 1 (aktiv).
HRPAD00INFTY (method IN_UPDATE) is called by the old infotype framework (PA30, SAP50UPR)
HRPAD00INFTYDB (method UPDATE_DB) is called in the decoupled infotype framework
BAdI: HRPAD00INFTY – Verbucher / Infotyp-Pflege
Interface: IF_EX_HRPAD00INFTY
BAdI: HRPAD00INFTYDB – HR: Stammdaten, Infotype DB Update Logik
“The BAdI is called, after the decoupled infotype framework writes the infotype data to the database. This is done during method FLUSH.” Note: The Infotypes 2000-2999 are not decoupled yet! More here and here.
