When searching for a way to select quotas without doing a manual select, I found the following class is the Fiori odata packages.
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 ).
But 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.
However, if you look inside the method read_time_accounts you’ll find another class that is used to read the quotas. The names of the result fields are slightly different, but at least the endda is used in this case.
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.
