Skip to Content
Technical Articles

Uploading a PA Infotype record with Cost Assignment

Recently on an HCM implementation project for an Australian customer, we had a requirement to interface Employee Personal Expenses to SAP HCM. The personal expenses were to be uploaded into Infotype 0015 (Additional Payments) record in Personnel Administration (PA) along with the Cost Assignment Data. The Personal expenses were extracted from the Finance system (an external / non-SAP system) fortnightly by the middleware which then produced IDocs and delivered them to SAP.

We learnt that it wasn’t straightforward to upload Cost Assignment data into a PA Infotype record especially from inside an IDoc function module.  After searching on different forums and communities for a solution for over a week, we found a solution ourselves on one fine day and in doing so, learnt of two interesting ways uploading such data.

The intent of this Weblog is for HCM developers to understand two effective means of uploading Cost Assignment Data along with an InfoType record using an API oriented approach. This was a good learning from my project and I want to share this with all of you.

Cost Assignment Screen - Infotype 0015 (Additional Payments)

The Problem

Using proven techniques like BDC (Batch Data Communication) or Call Transaction we can program the upload of InfoType data along with Cost Assignment record quite easily as these techniques call the PA30 (Maintain Employee Data) transaction screens and pass the data to the underlying screens which have a provision to accept Cost Assignment data while creating or changing InfoType records

While these dialog-based upload techniques are suitable for Data Migrations using LSMW or a custom Z-program, they are unsuitable for use inside an IDoc function module. This is because each call to a PA30 transaction triggers its own separate LUW (Logical Unit of Work) and that’s not allowed inside an IDoc. The ALE framework outside an IDoc issues a COMMIT WORK to update both IDoc data and status consistently and every IDoc function module must adhere to this principle. This necessitates the use of non-dialog based techniques (similar to APIs) for upload into SAP using IDocs


The Solution

Although Cost Assignment Data appears to be part of the Infotype record (it is logically and technically linked to the Infotype record), it is stored separately in tables ASSOB and ASSHR and not in the PA Infotype Table(s) such as PA0014, PA0015, etc. That’s why even the widely used HR_INFOTYPE_OPERATION function module or other interfaces to create and change HR Infotype records have no direct provision to accept Cost Assignment data. But there is a way around it!

Below are two ways to upload the Cost assignment data as outlined below: –

1) Using HR_INFOTYPE_OPERATION function module: –


  • Export Cost Assignment Data such as Controlling Area, Company Code and Cost Center to a Memory ID say ‘ZHR_COST_ASSIGN’


  • Call function module BAPI_EMPLOYEE_ENQUEUE to lock the employee master record. Check the return parameter after the call and proceed only if the locking is successful else handle the error message(s) accordingly


  • Call function module HR_INFOTYPE_OPERATION (Do Not Commit! Pass ‘X’ to parameter NO_COMMIT). Inside the customer exit function module EXIT_SAPFP50M_002, import the cost assignment data from Memory ID ‘ZHR_COST_ASSIGN’ populated from above and transfer to the Cost Assignment structure IPREF


  • Evaluate the return message structure from the function module call. If there are no errors, call function module BAPI_TRANSACTION_COMMIT* else handle the error messages accordingly


  • Optionally call function module BAPI_EMPLOYEE_DEQUEUE* to unlock the employee


Please Note: –

Do not call the BAPI to Commit or Release Locks from inside an IDoc function module. The ALE framework invokes a COMMIT WORK after the IDoc function module is executed which takes care of making changes permanent in the system or releasing any locks


Implement and Activate Enhancement PBAS0002

Customer Exit PBAS0002, Function Module EXIT_SAPFP50M_002 –> Customer Checks for Personnel Administration and Recruitment:

This customer exit allows you to populate Cost Assignment Data in structure IPREF. You can even validate the Cost Assignment Data and raise an exception ERROR_OCCURED with an appropriate message to stop further processing


2) Using the Decoupled InfoType Framework: –

First call function module BAPI_EMPLOYEE_ENQUEUE to lock the employee master record. Check the return parameter after the call and proceed only if the locking is successful else handle the error message(s) accordingly


  • Create an instance of the HR Business Logic class
    CALL METHOD cl_hrpa_masterdata_factory=>get_business_logic

    to get an instance of the HR Business Logic class. Assign this instance to a reference variable G_MASTERDATA_BL


  • Refresh the Master Data Buffer
    CALL METHOD g_masterdata_bl->initialize


  • Create a new write buffer
    CALL METHOD g_masterdata_bl->start_trial


  • Create a new container instance for an Insert operation
    CALL METHOD g_masterdata_bl->get_infty_container

    Let’s suppose this returns an instance ref1 of type IF_HRPA_INFTY_CONTAINER. Type cast ref1 to another reference ref2 where ref2 points to an instance of class CL_HRPA_INFOTYPE_CONTAINER


  • Call the appropriate method to update the InfoType record in the Infotype container
    CALL METHOD ref2->modify_data

    This method call updates the Primary, Secondary and Cost Assignment records from the updated work areas that you pass to the method. This method returns a new reference (say) ref3 of type IF_HRPA_INFTY_CONTAINER_DATA. Type cast ref3 and assign back to ref1 which is of type IF_HRPA_INFTY_CONTAINER. Please Note: There are other related methods to explore such as MODIFY_PRIMARY_RECORD,   MODIFY_SECONDARY_RECORD and MODIFY_PREF


  • Insert the InfoType record from the updated InfoType container
    CALL METHOD g_masterdata_bl->insert

    You must pass the reference ref3 which points to the updated container


  • Evaluate the return messages in the MESSAGE_HANDLER parameter
    If an error is returned, then discard all updates performed as a trial

    CALL METHOD g_masterdata_bl->discard_trial

    If no errors are returned, then transfer updates performed as trial to the HR write buffer:

    CALL METHOD g_masterdata_bl->approve_trial


  • Write the changes in the HR buffer to the database:
    CALL METHOD g_masterdata_bl->flush


  • There are 2 variants to the parameter no_commit
    no_commit = ‘X’ – Does not commit to database (Ideal for IDoc scenarios)
    no_commit = ” – Commits data immediately



There are two methods of updating Cost Assignment Data in an HR InfoType. The first option using HR_INFOTYPE_OPERATION is easier to follow and simple to code though it requires implementation of an additional enhancement. The second option using the new Decoupled InfoType framework is more like a true API for uploading Cost Assignment data with detailed error handling though it requires more coding


The appropriate technique to use depends upon the circumstance and the framework in which the developer is implementing the Infotype updates


I hope you find this information useful and beneficial to apply in your projects!


Best Regards,

You must be Logged on to comment or reply to a post.