- Action-Based Postings in PA
- Organizational Relationship Postings
- Generic Infotype Posting in PA/OM
- Custom Adapters
This adaptor will process an HR Action and associated infotypes. It is designed to work off the Field level configuration table /FLMHR/FLD_CNTRL where POST is set to A (Action).
To use this adaptor you must provide every mandatory field for every expected infotype or the posting will fail. If the form data and business process do not allow all this data to be captured you have two options.
Clone the action
The first option is to copy the original HR action e.g. Z1 to create an FLM version e.g. ZF. This FLM version should have no infogroup assigned and be configured with the same “Reasons for Action” as the original. When configuring FPE the “swap action” adaptor can be used to revert back to the original action as described below.
An alternative option is to use a custom BDC based adaptor to create just the Action then “exit” the transaction and in doing so skip further infotypes. A reduced set of infotypes can then be added to the action using this or the infotype adaptor described later.
Example of configuration for Action-based posting for 'Change Hours', showing Screen Field
- If there are no entries in the configuration table for the form type then the adaptor will complete successfully and pass control to the next configured adapter, if one exists.
- The HR Action is read from the hidden subform SF_HRCONTROL and field TXT_ACTION.
- The SCREEN_FIELD column is used here in a special case to pass organisational data into to the action screen. These rows only need to be provided for new hire actions (but shown here for illustration purposes). If an entry for INFTY = 0000 / INFTY_FIELD = PERNR is passed then the current PERSG, PERSK, WERKS and PLANS values will be derived and do not need to be provided
The posting adapter performs the following tasks:
- Reads the employee number passed via the form field linked to the 0000/PERNR entry.
- Reads the effect date (DT_BEGDA) from the form and fails if this is not found or is blank.
- Reads the HR Action (TXT_ACTION) from the form and fails if this is not found or is blank.
- Reads all Field Level posting configuration for the customer, form type, version with the POST value set to A.
- Determines the SAP field name for posting by assuming this is Pnnnn-fffff where nnnn = INTFY and fffff = INFTY_FIELD. If a value for SCREEN_FIELD is passed then this is used.
- Replaces Personnel Area/SubArea, Employee Group and Position from current employee record to support infotype 0000 creation (ignored if this is a Hire action).
- Calls standard SAP function HR_MAINTAIN_MASTERDATA processing an INSS operation for infotype 0000 only.
- Calls standard SAP function HR_MAINTAIN_MASTERDATA processing an INS operation for infotype 0001 only. This will ensure that a payroll status record (infotype 0003) is created as a basis for the next update.
- Calls standard SAP function HR_MAINTAIN_MASTERDATA processing an INS operation (unless another is confgiured) for all remaining infotypes other than 0000 and 0001.
- On failure (or an abort from foreground processing) the updates are stopped and SAP error messages fed back to the FPE Log.
It is normal to add a custom wrapper function around the delivered function '/FLMHR/FPE_ACTION_PLUS_700'. This allows you to:
- Pass in different fields for the HR Action and Effective Date if not using 'TXT_ACTION' and 'DT_BEGDA'
- Control the 'Post Control' parameter which is defaulted to 'A'
- Change the parameter 'IM_USE_POSTED_DOC' which is defaulted to 'X'. When this flag is selected, the function looks for a previously created document number, passed back via ex_posted_doc in a previous adaptor, to use in this posting.
Here is an example of a custom wrapper function, which would work for a new hire scenario where there is no previously posted document (employee ID):
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45:
FUNCTION z_flm_test_post_700. *"-------------------------------------------------------------------- *"*"Local Interface: *" IMPORTING *" VALUE(IM_FORMS_DATA) TYPE /FLM/XML_TAB_T *" VALUE(IM_STEP) TYPE /FLM/PROCESS_SEQ *" VALUE(IM_DIALOGUE_MODE) TYPE CHAR1 *" VALUE(IM_FPE) TYPE /FLM/FPE *" VALUE(IM_STATUS_T) TYPE /FLM/FPE_STATUS_T *" VALUE(IM_RFCDEST) TYPE /FLM/FPE_RFCDEST *" EXPORTING *" VALUE(EX_POSTED_DOC) TYPE /FLM/PDOC *" VALUE(EX_SUBRC) TYPE SYSUBRC *" VALUE(EX_NO_POST_ATTEMPT) TYPE FLAG *" CHANGING *" REFERENCE(CH_RETURN) TYPE /FLM/MESS_T *"-------------------------------------------------------------------- * Data for manipulating form data DATA: lt_forms_data TYPE /flm/xml_tab_t, ls_forms_data TYPE /flm/xml_tab. lt_forms_data = im_forms_data. CALL FUNCTION '/FLMHR/FPE_ACTION_PLUS_700' EXPORTING im_forms_data = lt_forms_data im_step = im_step im_dialogue_mode = im_dialogue_mode im_fpe = im_fpe im_status_t = im_status_t im_rfcdest = im_rfcdest * IM_DOCUMENT = 'TXT_IM_DOCUMENT' * IM_ACTION = 'TXT_ACTION' * IM_EFF_DATE = 'DT_BEGDA' * IM_POSTING = 'A' im_use_posted_doc = ' ' IMPORTING ex_posted_doc = ex_posted_doc ex_subrc = ex_subrc ex_no_post_attempt = ex_no_post_attempt CHANGING ch_return = ch_return. ENDFUNCTION.
Function '/FLMHR/FPE_SWAP_ACTION_700' is delivered. This adaptor, if required, should run directly after the Action posting and will replace the FLM specific action previously created with the equivalent customer action.
This should be used in the case where no separate analysis of FLM Form updates is required such that all HR Actions can be reported together.
During the posting this function performs the following tasks.
- Reads the effect date (DT_BEGDA) from the form and fails if this is not found or is blank
- Reads the previous Posted Doc from FPE and fails if this is not found or is blank
- Read the entry from a single entry stored in the project variables under FPE_SWAP_ACTION. The “low” value should have the format of “oa/na” where “oa” = the old action and “na” the new action.
- Reads the current “old” action (just created) for the effective date
- Replaces the old action with a new action
- Modifies the previously read action and updates SAP
Add configurated for infotype 1001, where the subtype stores the relationship to be added.
|Customer||Form Type||Version||Status||Field Name||Obj Typ||Obj ID||Infotype||Subtype||Field||Post Control|
- This adaptor will only update/delimit SAP records active on the effective date (DT_BEGDA) stored on the form. The Data pattern for this field (and all other date fields) must be YYYYMMDD in line with the SAP internal format. In cases where specific past or future dates should be used then a custom adaptor must be used.
- Where the FLM form or HR configuration could permit multiple records for an infotype to exist then there is a risk the incorrect record could be updated. Therefore additional unit testing should be performed or a custom adaptor used.
If there are no entries in the configuration table for the form type then the adaptor will complete successfully and pass control to the next configured adapter, if one exists.
- Reads the effect date (DT_BEGDA) from the form and fails if this is not found is blank
- Read any existing Posted Doc, used with entries passing FORM_FIELD as POSTED_DOC
- Reads all Field Level posting configuration for the customer, form type, version with the POST value set to I.
- Sorts the configuration to ensure updates to many fields in a single infotype are performed once and at the same time
- Creates a dynamic table and work areas for the relevant infotype
Reads the current record form PA/PD based on the effective date into the work area
- If the OPERATION is LIS9 (Delimit) and no data is found a message is placed in the log and the next infotype is processed.
- If the infotype structure contains the fieldname PERNR then PA update are performed otherwise a PD update be attempted.
- Replaces the effective date and field value(s) within a new work area
Performs either a
- PA infotype operation via HR_CONTROL_INFTY_OPERATION (or HR_INFOTYPE_OPERATION for older SAP releases) passing the new work area and operation specified.
- PD infotype operation via various standard SAP funcntions to support a create, modify or delimit operation
- On failure (or an abort from foreground processing) the updates are stopped and SAP error messages fed back to the FPE Log
- On success the log is also updated and the next infotype update processed
Note that to support this adaptor an ABAP include (/FLMHR/ZCUST_INFTY_LIST) is provided and declares the structures of the most common infotypes likely to be updated. In the event, during development, that the posting tries to update an infotype not yet declared, the posting will fail, and the log will request that an update to this include is made.