Best Practices to use the Workforce Timesheet API

[PanduJanga]

In this blog, I would like to explain how to use the Workforce Timesheet API effectively without running into Locking issues in S/4 HANA Public Cloud.

When the Time entries are posted via Workforce Timesheet API, the entries are saved in CATS DB and CATS CO tables. Once the Time entries are approved, a Background job is automatically triggered to update the ACDOCA( Universal Journal ). The RCATS CO, referred to as Transfer to CO background Job locks the employee while it updates the ACDOCA.

Example1:

Time entries are posted to the S/4 HANA Public Cloud in batches.

Batch 1 consists of 1000 time entries of various employees ( employee1 to employee 10)

Batch 2 consists of 1000 time entries of various employees ( employee 5 to employee 15)

The RCATS CO program locks all the employees in batch 1. When batch 2 tries to acquire a lock on employee 5 to employee 10, it fails and continuously retries to acquire the lock. This process overloads the enqueue server and eventually consumes all the background processes. Apart from this RCATSCO program, there are other background jobs that try to acquire locks on the employees or use the background processes.

Transfer to CO

how to ensure that the locking issues are reduced?

• Scenarios which require pushing huge volumes of timesheet information should have the MAX_LOCK parameter set. let's say the MAX_LOCK parameter is set to 5 only 5 employees will be locked at a time instead of all the 10 employees in batch 1 ( refer to example 1). the Locks on the employees are held for a shorter period of time and help in reducing the collisions between various batches.

 

• When pushing the employees in batches they should follow the below pattern while forming the batches
  
  
  
  • 
    

    {
    
       Batch1 {
    
    
    
                changeset1 [ {employee1 time entries}] ,
    
                changeset2 [ {employee2 time entries}] ,
    
                changeset3 [ {employee3 time entries}] ,
    
                 :
    
                 :
    
                 :
    
                changeset10 [ {employee10 time entries}] 
    
    
    
    
    
               }
    
    }
    
    
    
             

    
    
  
  
  
  

 

what if the transfer to CO fails?

when transferring to CO there are possibilities for failure and below are a few examples. if the entries are not transferred to CO though it appears that there is no open action item from the employee the billing amount on the project doesn't add up. The best practice is to ensure there is no such accounting object-related errors. However, during month-end and year-end closure, we cannot delay the period of closure, in case huge volumes of time entries are not reflected in the project billing or Universal Journal

• 
  
  
  
  • Employee is terminated
  
  
  • The project is no longer valid
  
  
  • Cost rates are not maintained for the activity type
  
  
  • The errors can be corrected by running the Process unposted time confirmation background job  in test mode ( select the test run in step 3 Processing options )
  
  
  
  

Recommendations:

The Overhead accountant Persona can repost these entries after correcting the accounting errors but the transfer to CO Program Locks the Employee so there is a possibility that the locking issue might occur again so in such cases follow the below recommendations.

• use the Schedule Overhead accounting Jobs  Job template to reprocess the time entries


• Click on Create button  to create a new Job and select the Job Template "Process Unposted Time Confirmations (SAP)"


• In the second step, there is the possibility to schedule the job in recurrence if there are more times entries from the previous month or year
  
  
  
  • for example, let's say there are 100000 entries for the Month of May and the current date is June 1st  schedule multiple jobs as follows
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    Job	Time of the Day	Date from and to ( step3 selection parameter)
    Background Job 1	Before the start of Business hours	May 1st  to May 10th
    Background Job 2	During the Midday when business activity is less	May 11th to May 20th
    Background Job 3	After business hours and well before midnight as there is a nightly job which runs at 00:00 hrs	May 21st to May 31st

    
    
  
  
  • before scheduling the job set the Max Parallel process to 10 so that the job runs faster and also ensure the MAX_LOCK parameter is set so that not all the employees are locked at once.
  
  
  
  

I hope this blog was helpful for external Timesheet Integration with S/4 HANA Public Cloud.

 

Additional references:

CAT7: Parallel processing and performance improvement during transfer of aggregated time sheet data ...

CAT7: Lock problems

 

Thanks for reading!

Pandu