Skip to Content
Author's profile photo Former Member

Case Study On HCM Outbound Interfaces


     Here i want to share an idea on HCM outbound interfaces which we extensively used in our project.

This blog gives you a basic idea on how we designed our HCM interfaces and please pour in your thoughts as well if you have alternative ideas and suggestions.

     In SAP HCM, we often need to send HR Delta data (details of the changes from last run date) to third party interfaces on regular basis. For example, many companies want to secure the services of third party tools like HRG, BENEFEX, PeopleFluent etc to streamline their HCM related jobs. Since the requirements are specific to the third party tool, we often need to develop bespoke interfaces. In our project we have developed a standard template for all the HR interfaces with which we can send ‘Full load’ i.e. current data of all the employees for the initial run to the third party interface and ‘Delta load’ i.e. sends data whenever there is a change in data from the last run date.

     This template is flexible and with the minimal code (can be re-used both for ‘Delta Load’ and ‘Full Load’ as well) which we will discuss as we go in to more technical detail and this can be re-used in SAP HCM interfaces which use PNP LDB and require to send data on timely basis.

Technical Details:

     Two blocks along with the standard PNP screen are added on the selection screen like below (refer screenshot1) with one facilitating the type of Run and the other having Last Run Details (which is not editable) and another option called ‘Override Last Run Date’ to give the flexibility to change the date from which this interface has to consider the changes.

  • Advantages of Run Details Block:

     Same program can be used to schedule the jobs with the slight changes in variants. Code in the program can be common for both the Delta run and Full load with the exception being Full load runs for whole population while delta load runs only for the employee who has the changes in the desired infotypes since last run date.

  • Advantages of Last Run Details block:

     Administrator can always have a look at the last run date on which the program was scheduled and the changes are expected only from that date only. Last run date can be changed by overriding it by placing another date in Override last run date field.

This block is visible only when the radio button “Delta Load” is selected. (Refer Screenshot 2)

     A custom table has to be created to store the values of the interface names and their last run dates which will be updated whenever the program is scheduled. Last run date will be picked up from this table. For the first time, full load has to be scheduled for whole population and the date will be updated.

Code Snippets

Piece of code which can be used to find the changes in the infotype for delta load when using PNP. If the flag is set, particular employee’s data will appended to final internal table to be sent.

Flag has to be cleared after GET Pernr statement.

In HCM, there is a scope of “future dated” records, so for them, the begin date is checked and for normal records, the change date is checked if it falls in specific intervals.

  LOOP AT pxxxx WHERE aedtm GE p_last OR begda GE p_last.

    IF  pxxxx-aedtm < pxxxx-begda AND

        pxxxx-begda BETWEEN p_last AND sy-datum.

      gv_flag = abap_true.


    ELSEIF pxxxx-aedtm BETWEEN p_last AND sy-datum AND pxxxx-begda LE pxxxx-aedtm.

      gv_flag = abap_true.




For Delta Load

See if the flag is checked then append the data

Wa_final-person = pxxxx-data.

Append wa_final to it_final.

For Full Load

Wa_final-person = pxxxx-data.

Append wa_final to it_final.

So, the code in blue can be re-used for both the processes instead of writing two separate programs. Data can be sent via PI or GI to third party systems.

Full load can be scheduled on need basis.


Here, we aren’t checking if the specific field which was asked (by third party tool) got changed or not. We are checking if there is a change in whole infotype. The reason is as you guessed performance. As we thought there is no harm in sending the same data again to third party tool as these records can be very few when compared to actual population.

We encountered one more problem with this approach. The requirement is to send the records of the employee if there is a change in manager details. As the details of the manager are not stored in any specific table and checking for the change in HRP tables in PNP LDB is time consuming, we went for a separate solution to tackle this problem which i will try to explain in the continuation blog.

Please let me know your thoughts to improve this idea or other approaches which you might have implemented to solve these kind of scenarios.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hello Sagar,

      it looks good but as you rightly said it does not cover all cases. Another issue I see is when historical data are being changed (by historical I mean records with validity periods either in the past or in the future). The target systems very often cannot cope with such changes.



      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hello Olivier,

      Thanks a lot for your kind words.

      Let me add few more details about historical data and the way the data will be sent to target systems to cope up with the changes 🙂 . Kindly let me know your ideas as well.

      Regarding historical data, let me segregate that into two parts.

      1. Past

      2. Future

      As i mentioned in the comments in the code snippet section;

      For Past, we dont check the begin date, we check the change date (aedtm) field.

      For example, if i change the end date of a record which has begin date on 01.01.2004 and end date as 01.01.2005 but i changed the end date to 01.01.2006. here both the intervals are in past. but the change date is today. So that record will be picked up in delta changes.

      Regarding Future dated records.

      For future dated, we will be considering the begin date and not the change date. For example, i will be changing the begin date from 01.01.2015 to 01.02.2015, that record will not be picked up now.

      It will be picked up when the interface runs on 01.02.2015. because, the change is effective from "that" day. (like employee joining (becoming active stat2 = 3).

      i hope i have understood your comment correctly. Please let me know if i have missed something here. Thanks again.

      Best Wishes,


      Author's profile photo Former Member
      Former Member

      Hello Sagar,

      I see two problems in your solution (if I got it right):

      In HCM infotypes can be created, changed and deleted at any time in any timespan. IMHO, you can not reliably use the change date of a infotype dataset for anything...

      This is a big difference to some other modules like FICO.

      1. What happens, if a infotype is changed, beginning in the past, before your last run?


      •     First run 01.01.2014: Infotype IT0002 (from 01.01.1980 - 31.12.9999) marital status = unmarried
      •     Data change on 1.1.2014: Person married on 12.12.2013 - gets a new dataset beginning at 12.12.2013 to 31.12.9999, the last dataset is delimited to 11.12.2013. So, two datasets have changedate 1.1.2014.
      • Delta run on 02.01.2014: what should it do now?

      2. What happens, if a infotype dataset is deleted?

      Example: Infotyp 0015/0014: Person has a wagetype, but it's wrong and removed.

      • The Delta run will find nothing, because the dataset is not there anymore.

      I think, there might be better examples. But in our HCM systems that stuff happens all the time.

      There are two ways to create a reliable Delta-mechanism:

      1. Save the last output to a file or database table and compare it with next result. With some skill, that can be programmed as a general function useable by many programs.
      2. Read change pointers or infotype audit logs. This is quiet slow, because cluster tables involved.
      3. Use ALE and its change pointers for interfaces.

      Best regards,


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hello Heiko,

      Thanks a lot for your ideas. Very much appreciated 🙂

      For the first scenario, we will be getting the latest record(only one) always unless we are asked to get multiple records from last run date which is possible. Example : Bonus related records which can be multiple from last run date, then we will loop and send multiple records for a single employee. It happened when we were dealing with appraisal process where we got to send multiple records since last run date. In the example given, only the latest record where the employee status got changed (from unmarried to married) will be sent i.e. an entry with the updated marital status will be sent.

      For deleted records,

      Interfaces are bespoke and built according to thrird party tools which are going to use it. Many of them weren't interested in deleted records, but yes, as you said, they may be interested. For example, systems like "clarity" were interested and we had to hit cluster tables which was time consuming. The above idea was based on majority of the interfaces which we have dealt, so thought of presenting an idea. However, if they need deleted records also, they got to hit the cluster tables as mentioned 😀

      Thanks a lot again for your time and sharing your valuable comments. Cheers.

      Author's profile photo Former Member
      Former Member

      Hello Sagar,

      I have a similar requirement where 'future dated' records were required based on change date (AEDTM). My requirement in detail is..

      We're running ALE-IDOCs to third-party system based on Company code filter in distribution model. Execution through PFAL.Now, we got a problem for some data records.

      i.e, when checking IT1 via System begda, if no COMPANY CODE is found at present, record is not sent. Instead if Co-code is blank, then needs to look ahead for next future dated entry, and take that company code to send.


      Current day 06-01-2014 (today)

      User creates record with Hiring action from 22-01-2014, this creates IT0 and IT1 record dated 22-01.2014 (along with IT2,6,8,9 etc)

      When saving record, this is not selected to go to third-party system as no entry in IT1 for current system date 05-01-2014.

      (at present a manual send / update of record has to take place on/after 22-01-2014 for date to be sent across interface).

      So adding check so that if no Co-Code found dated current sys date, to look for next/future record and send based on company code of future entry.

      Could you suggest something on my requirement? Also, please attach "Delta run" code snippet completely which might be helpful for me.