Skip to Content
Author's profile photo Imran Sajid

SAP Payroll vs SAP Time Management: Same Operation, Different Capabilities

In my previous article SAP Time Management & Payroll: Displaying Custom Schema Messages I made a direct comparison of the capabilities of standard SAP operations in Time Management & Payroll in trying to accomplish the same thing – generating a warning message during processing. In that article, I showed how it is easier to display messages in the Time Schema compared to the Payroll schema. I got positive feedback and intrigue in the topic – comparing standard tools that SAP provides in the form of schema functions/operations and how they differ in Time vs Payroll. I wanted to write this article to cover this topic a little more, but this time I am going to flip the script and talk about how the TABLE operation in Payroll is more powerful than the TABLE operation in Time Evaluation.

First, let’s take a look at the F1 help for each of these operations. Here is the SAP help screen for the Payroll operation.

Image 1.png

Now here is the F1 help for this operation in Time Management.

Image 2.png

Without paying much attention, you would see that these two operations share the same name and as a result probably behave very similarly, but this could not be further from the truth. Pay attention to the description in the Payroll version and it says “allowing you to access any fields in ATAB tables or internal tables that are used in Payroll” while the Time counterpart states it’s limitations in the form of the wording “The following Customizing tables are supported“.

Now let’s take a step back and take a look at what this exactly means. The Time Management operation allows us to access 5 tables: 001P, 503, 508A, 510I, & 559A. What about the payroll counterpart? I ran payroll, set a break point in the code for the TABLE operation and then looked at all the global variables available via the debugger – there were 2,293 of them available. Not all of them are internal tables that can be called, but many of them are and it shows that this operation allows a tremendous amount of flexibility in processing.

Image 3.png

Okay, so you have all of this flexibility, but what about a real world scenario where you may need to use this operation? I once had a client that wanted to make it so that in their development or sandbox environments they did not want to turn on the month end accruals in the system. In order to accomplish this, I wrote a rule using the TABLE operation in Payroll. The standard rule for month end accruals as delivered by SAP is UACO and it is called in the “Processing month end accruals” portion of the schema which is shown in my screenshot below.

Image 7.png

Image 4.png

This standard rule that says that accruals should be off. If the value of ACCMO is set to 1 then accrual computations are performed. If the value is 0 (As the standard rule sets it to) then accruals are not performed. So in order to make it dynamically work based upon the system that the user is logged into, I would write a small rule use the TABLE operation. Here is what it looks like. I would then replace the standard UACO rule delivered by SAP with my new rule.

Image 6.png

In this example I am using the TABLE operation to call the SYST table and then looking at the SYSID field in order to make a decision on whether accruals should be turned on or off. In this example, ECD = Development, ECT = Test, & ECP = Production. I also accounted for other system using *** (Sandboxes could be added later or something) and by default I turned it on for this system although you could elect to turn it off. Here is the result of my operation in the test system to show how it processes. As you can see, based upon the system (ECT) accruals has been turned on.

Image 8.png

In the example above, I showed just how powerful the TABLE operation is in Payroll and how I can check if it is production without any customization in the payroll schema using this operation. This only scratches the surface on just how powerful this operations really is. How would I accomplish this same type thing in Time Management? I have run into this exact dilemma and in order to look at the system and determine if it was development, test, or production in Time Evaluation I have had to create a custom operation. I published an article in SAP Experts (HR Expert) talking about this and how I did it “Preventing Future Time Evaluation Issues While Maintaining Testing Flexibility in QA“. I had previously implemented this customized functionality for 5 different clients so it was certainly something that many people found to be useful.

The great thing is that the SAP framework allows you the flexibility to accomplish your business requirements regardless, but in this case it is easier in Payroll!

UPDATE 6/2/2016

In doing some research to answer a question in the comment section below I found a relevant consulting note 1931655 from a few weeks ago 05/25/2016. Per the information in the note there is additional flexibility to be able to access tables other than the ones previously mentioned by adding your own logic. It is also mentioned that you should NOT use this operation to read infotypes within rules and if you needed to then you should create a custom operation.

Image 1.png

Feel free to share your thoughts in the comments below.

Assigned Tags

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

      Your blogs are some of my favorite in the HCM technical space.  Keep up the great work and sharing to the SCN community.

      Author's profile photo Imran Sajid
      Imran Sajid
      Blog Post Author

      I really appreciate that feedback Jarret. It means more than you think coming from someone that I respect as much you.

      Author's profile photo Jagan Gunja
      Jagan Gunja

      Hi Imran

      Good stuff, Imran!   I agree that it takes a while (years to be realistic), to understand fully about customizing, whether in tables/views, schemas, PCR's etc. 

      Often it has been observed that consultants change some part of a schema/PCR for a scenario, but do not see the full implications on other scenarios or the rest of the implementation.

      I also agree with you that schemas/PCR's can be customized in different ways to cover business scenarios.  Even custom features, functions, operations, etc are created often.  Some installations have also gone to the extreme, I have observed. 

      One point to note is when customizing a feature to add a new customer field to the feature's structure, it needs to be ensured that the fields are filled prior to calling the feature.

      Further, I was wondering if you have tested the above pcr with op'n TABLE for SYST table?

      I have gone through the payroll TABLE operation's ABAP code.  It checks the validity of the table name.  Unless you have changed the ABAP code or allowed other tables using form read-atab-natio or form read-atab-mod, if the table is not one of those allowed, the op'n gives an error.

      In PT op'n TABLE's code, it does not check the validity of the table name.

      .br JG

      Author's profile photo Imran Sajid
      Imran Sajid
      Blog Post Author

      Hi Jagan,

      Thanks for the comment and adding to the discussion. I must say that I never took a look at the code behind the TABLE logic, but I can confirm that I did test the above PCR and have used it in a client system before and it worked as expected. Your point above got me curious so I decided to take a look and here is what I found - you are absolutely right about the logic in the payroll TABLE operation code. After some debugging I found that the system gets the value (System ID in this case) within the VARGB operation

      It happens within INCLUDE RPCBU309_GET_TABLE_FIELD and SUBROUTINE get-table-field. Here are some screenshots showing this as well as showing the value returned in both the code as well as the output log of my schema.

      Image 3.pngImage 1.png

      Image 2.png

      I am guessing that the operation should work as expected even for other tables. I will openly admit that my use case of this operation has been limited to this scenario above so I can not say it definitively without testing.



      Author's profile photo Jagan Gunja
      Jagan Gunja

      TABLE itself does not get the field value. 

      In time eval, depending on where the TABLE is used (e.g., pcr called by MOD, pcrs' between bday and eday or pcr after eday), the table is positioned for a date, etc.

      The next op'n like HRS, etc get the value.

      In payroll, the TABLE op'n should have a valid table name. The op'ns like VARGB, NUM, etc get the data.