Posting adaptors

Configuration

 
 
The same configuration table is used for controlling posting as for controlling field-level pre-population.
In many cases a field is being pre-populated from an infotype field, and ultimately updates the same infotype field.  In such cases, a single table row is sufficient to control both the pre-population and the SAP update. 
 
Customer
FLM Customer Code
 
Form Type
Form Type
 
Version
Form Version. 
 
Status
Form Status.  (Optional)
 
Form Fieldname
Name of the Field on the Form (or dummy)
 
Country Group
Country Group (Optional)
 
No.
Sequential counter if the same field is used multiple times for the same form type.
 
Object Type
HR Object type (S, O, P etc)
 
Ref Fieldname
Field that stores the HR Object ID.
 
Priority
Used for pre-population only.
 
Infotype
HR infotype number
 
Subtype
HR Infotype Subtype (if required)
 
Field Name
Field name on the Infotype table
 
Pre-population control
Used for pre-population only.
 
Default Value
A hard-coded value for posting can be added.  For example, for updating fields that are not on the form but always have the same value.
 
Notes
Free text.
 
Post Control
2-character field that controls what posting adapter will process this row.
Typically use 'A' for Action-based posting, 'I' for infotype update, 'C' for custom.  This is freely-definable such that two seperate actions could be driven from one form.
 
Operation
Use to specify whether record is to be inserted, copied or delimited.
The default for Action-based updates if 'insert', as a new record is being inserted into infotype 0000.  So this can normally be left blank.
 
Difference Field
Used for change data scenarios, to compare 'old' and 'new' data, in order to trigger an update only when the data is changed.
Used only for infotype updates (not action-based updates).
 
BDC Screen Field
For action-based postings this over-rides the infotype/field with the actual SAP screen field name to be updated.  This is required in some specific circumstances.
 

FPE Function /FLMHR/FPE_ACTION_PLUS_700

 

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.

 

BDC Approach 

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

 

 

Processing Notes

  •  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.

Custom Wrapper Functions

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.

 User-exits

For scenarios where complex or dynamic logic is required for the posting, a user-exit INCLUDE is provided, /FLMHR/ZCUST_ACTION_EXIT_PVF.
For example, you may require calculations to be made before the update, or you may have specific fields that are only updated in specific circumstances, such as Date Types that are used for some employees but not others, or wage types that are dependent on the employee group.
The user-exit provides an internal table with all the proposed updates to each field, and custom code can be added to amend this table before posting.        

Swap Action

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

Organizational Relationship Postings

Posting to infotype 1001 is a special case that is handled separately. 

Configuration

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
ACL TEST 00   TXT_POS_ID P POSTED_DOC 1001 A008 SOBID C
The Field Name stores the first object ID.  In this case, the position ID taken from the form.
The Object ID stores the seconds object ID.  In this case, the posted document (an employee number), created at a previous posting step.
 

Custom FPE Function

A custom FPE Function will be required to call the SAP function 'RH_RELATION_WRITE'.  See the examples page to clone some sample code.
 

Generic Infotype Posting in PA/OM

Where no action is required, infotype updates can be made using posting function /FLMHR/FPE_INFOTYPE_700. 

FPE Function /FLMHR/FPE_INFOTYPE_700

This adaptor is designed to work off the Field level posting table /FLMHR/FLD_CNTRL and performs simple field updates to existing SAP PA/PD records when no HR Action needs to be involved. Please note the following restrictions on its use.
  • 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.

 
The posting adapter performs the following tasks
  • 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

Maintaining The Infotype List

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.

 

Custom Adapters

When you have posting requirements that cannot be met by standard posting adapter functions, then you will need to develop a custom posting adapter.
 
This could be required, for example, for complex business logic or when repeating rows are required in the update. (For example for infotypes 0014 and 0015).
 
In this scenario, the process is exactly the same as for writing a posting adapter for FLM without the FLM for HR framework.
 
Note that there is a very useful function, /FLMHR/FILL_RETURN, available, for filling the FPE messages.
 
See the examples page to clone some sample code for a custom posting adapter.