Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
ImranSajid
Product and Topic Expert
Product and Topic Expert

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.

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

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.

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.

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.

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.

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.

Feel free to share your thoughts in the comments below.

5 Comments