I recently had two SAP HCM clients who have both been live with Time Management for quite some time experience the same short dump in their Time Evaluation program (RPTIME00) within a few days of each other. Typically, whenever I hear of a short dump in Time Evaluation the first thought that comes to my mind is "Custom Operation or Function". However, upon first looking at this short dump in transaction ST22 it was obvious that a custom operation or function was not the underlying issue. These short dumps were the exact same message originating from the exact same piece of code but the underlying issue was COMPLETELY different. I wanted to talk about this short dump and just share some my experiences with debugging this logic. First I will give a little bit of background on my two clients and the experience with each one.
Client 1
- Runs SAP Time Management with Clocking's
- SAP Gross to Net Payroll
- Uses SAP Payroll Tax Reporter so they apply support packs each year
- Currently upgrading to BSI 10.0 but SPs were already above requirement
- Short dump occurred in production environment.
- SAP ERP 6.0 EHP 0
Client 2
- Runs SAP Time Management with Clocking's
- SAP Gross to Net Payroll
- Outsources Quarterly & Year-End activities to ADP so they do not apply support packs annually
- Currently upgrading to BSI 10.0 and had to apply support packs to meet SP Requirement
- Short dump occurred in testing environment while doing support pack testing
- SAP ERP 6.0 EHP4
Here is the short dump - an internal table field has been defined too small.
As you can see the short dump points us to FUCUMBT. Anyone who has worked in Time Management long enough knows that this is Function CUMBT which is one of the last things that runs at the end of each day within the Time Schema processing. In further debugging, I was able to find a personnel number in the short dump so I copied the employee in question down to the test environment (For Client 1) and then ran time evaluation (In the past) to determine which day it was able to run up to so I can see the data within the Time Cluster tables. When I ran the current date, I was able to recreate the short dump in the test environment.
When running the problematic personnel number for Client 1 in the day before the short dump started I found the following entry in the SALDO cluster table
As you can see the amount in Time Type 0903 has a VERY large amount in it. This is extremely unusual especially considering that 0903 is a STANDARD SAP time type that deals with weekly overtime.
Right away I knew that something was wrong with customization in the time schema that was causing this standard time type to have an unusually high balance in it.
Ultimately with this Client, I found a few custom OT schema rules that were filling up MB0903 and compounding each day and as a result MB0903 was never being reset. The schema rules that were responsible had not been changed since 2005 but had finally grown large enough to cause the short dump!! In order to resolve the issue, I had to put in new logic to clear the time type similar to the standard SAP schema rule TW34.
Client #2 was a completely different story! These guys were implementing support packs as part of BSI 10.0 upgrade so I found the issue in the test environment while conducting my testing and trying to run a mass Time Evaluation on everyone. In order to see what was going on this time, I started at the same place in my debugging and found a personnel number from the short dump in transaction ST22 just like before. At this point, I ran the personnel number in time evaluation to the current date and even into the future to the end of the year and I did NOT get a short dump! I checked some of the main time cluster tables (TES, ZES, SALDO, ZL) and nothing looked off. This was very strange to me so I did another mass run of Time Evaluation to make sure it was not a fluke incident, but I got the same short dump except this time with a different personnel number. I looked into this second employee that was referenced in the short dump and once again nothing looked off with their time cluster data. Upon further research I did a comparison to Production and Test and did see that SAP changed some logic to the Time Program that was in QA but not in Prod as part of OSS Note 1879092 which was released on 10/04/2013 but was just put into this client's system with the support packs. Here is the change that I am referring to that was made by SAP.
For Client #2 the fact that the scheduled jobs in production were all running fine and not short dumping made me believe that it was an SAP program error as part of the support packs being applied rather than bad schema logic. Ultimately I did some further researching and digging and found OSS note 1942144 which describes the symptoms that I was seeing. I have included it here.
After this discovery, I used transaction SNOTE in the development environment to implement the note, put it on a transport, and moved it to QA. Once I confirmed the transport had been moved to QA I re-ran Time Evaluation on everyone via a background job using the existing production variant and while it took a long time to run due to the QA data being a few months old this time no short dump!
During my research and searching OSS notes I also wanted to point out to anyone reading this that I found a similar issue caused by the same logic that supposedly may also cause a short dump in Payroll in some instances. Neither of my two clients experienced this but for anyone having this issue please see SAP OSS Note 1966322 - RPCALCXX: Dump: Collect_Overflow_Type_P which should resolve the issue once applied.
In summary, I ran into two separate issues that happened to produce the exact same error message only two days apart and was just amazed at how different the underlying cause can be for two of the same exact short dumps! It also made me realize that you have to be careful with how you write your custom schema rules and be cognizant of time type balances because that logic can cause a big headache 10 years into the future!
- SAP Managed Tags:
4 Comments
