Blogs on period end processing
I intend to write several blogs on period end jobs and how to expedite your period end using tips and tricks. In these blogs, I will explain the concept of the job and demonstrate how the performance of these jobs can be speeded. You should use the tag”Period end close” to list these blogs.
If you have questions/ comments/ suggestions, please send me your comments in the form below. Sharing your questions and experience using comment box below will help other readers to gain additional knowledge involved in this functionality.
Share this blog with your network using one of the social media icons at the top or bottom of this page.
Assumption for this blog
I will assume that readers have basic knowledge of SAP COPA (Profitability Analysis), SAP assessment cycle setup and execution process.
It will be useful to read my blogs on Summarisation levels in COPA. I will assume for the purpose of this blog that all assessment cycles are structured as recommended in section “Group and structure your assessment cycle receiver segments” in blog COPA Summarisation #4 – Tips to optimise the use of summarisation levels
What am I demonstrating
In this blog, I intend to demonstrate the process of parallelisation of assessment cycles using cycle run groups.
Initially, I will explain how cycle run groups are created. Then I will show how you should schedule the cycles in background to run in parallel.
Throughout this blog, I will visit some limitations, and caveats with parallelisation of cycle runs.
Assessment Cycles in COPA
COPA assessment cycles are among the last period end jobs to run. This is because all other processes including cost center and profit center assessments have to complete before COPA assessments can start. The complexity and run time of COPA assessment cycles depend on many factors, chief among them:
- Number of sender cost centers
- Number of receiver profitability segments
- Number of cycles/ segments
- Technical Dataset in COPA tables (number of Profitability Segments etc)
I would strongly recommend you structure your assessment cycles/ segments as mentioned in section “Group and structure your assessment cycle receiver segments” in blog COPA Summarisation #4 – Tips to optimise the use of summarisation levels.
Cycle run groups
To enable assessment cycles to run in parallel and not lock each other out, you need to assign all assessment cycles to cycle run groups. Each cycle group is scheduled to execute in parallel. Hence, you create as many cycle groups as you need parallel runs. However, it may not be a good idea to run multiple cycle run groups in parallel on a given server. Create as many cycle run groups as number of servers over which they will be run.
Create the run groups based on your grouping of receiver segments. For more details on how to group your cycles based on receiver segments, read section “Group and structure your assessment cycle receiver segments” in blog COPA Summarisation #4 – Tips to optimise the use of summarisation levels. This will allow you to easily group cycles. Below is a slide with the example from that section.
Create cycle run groups
Creating cycle run groups is an easy task. From the maintenance mode of assessment cycle, use the menu path Goto > Cycle Run Group to access the maintenance of cycle run groups.
You will have options to create, change and overview of cycle run group. You can select an existing Cycle run group or create a new cycle run group.
Schedule assessment cycles
On the assessment cycle processing screen, select the “background processing” indicator. Schedule the processing of all the cycles in background individually (one cycle at a time).
When you decide to execute, the system will prompt whether you want to execute immediately or schedule for a future time/ date. Schedule the cycles for a future time/ date – choose some later date, this allows you to organise your cycles in Background job session overview (Transaction code SM37).
Preferably choose the cycle run group + cycle name as the job name. In the above example, the Job name would be 001_IT. By default, SAP system will not assign an executing server. We will assign executing server depending on the cycle run group.
Once you have scheduled all your cycles individually, you have to perform 3 tasks:
- Assign an executing server to each Job
Go to the change mode of the job, and assign the executing server. Ensure that you assign different server for each cycle run group. If you have created more number of cycle run groups than number of servers, you should preferably schedule to run cycle run jobs after other is complete.
- Schedule a program that prevents cycle lock
When an assessment cycle has completed processing, the documents from that cycle post to respective table. However there is usually a time lag between end of processing of the cycle and the update of data into the tables. This time lag happens particularly when the cycle processing creates large number of documents. If the next cycle starts before the table update are completed, then the cycle will fail due to “table lock” problem. This is because the cycle checks to ensure certain tables are “not locked” or open to update before the processing starts.
SAP OSS note 70094 proposes a custom program code (ZZALLOC3) that should run after every cycle processing is completed but before the next cycle processing starts. The program checks for table lock and will complete once it finds that the tables are “unlocked”. That way, the next cycle can start processing only when the tables are “unlocked”. This is a useful program because it will prevent assessment cycles failing at period end due to “lock” issues.
Create the custom program in your system and schedule to execute it in background. You have to make several copy of the background job so you can sandwich this between each job and also at the end of each cycle run group.
- Schedule the cycles within each cycle group to execute as predecessor-successor job
Click on “Start condition” and select “After job”. In the “After Job” Name field, select the name of the predecessor job.
Once the jobs are scheduled as above, you will have Scheduled Job List somewhat like this.
For executing server #1,
The following cycles from another cycle run group are running in parallel on server #2.
All cycles from Server #2 might complete before cycles from Server #1 are completed (for example). But that is not relevant as long as you have efficiently grouped the cycles. If you have any other independent cycles to run, you could manually schedule them from the server that has completed the above jobs first.
Points to consider when creating cycle run groups
Cycles not assigned to cycle run groups are assigned to default run group 000 by SAP. While cycle run group 000 is processing, user is not allowed to process any other cycles in parallel. Hence, ensure that you assign ALL cycles to a cycle run group other than 000. Even if you want some cycles to run independently (and not in parallel), it is a good idea to assign them to a group and process them independently.
No two cycles within a cycle run group can be run in parallel.
Ideally, the cycle run groups processing in parallel should read different summarisation levels. That will improve efficiency of the read process of data in the tables.
Preferably, process each cycle group from different servers. You could do that yourself using SM37 or you could request your infrastructure team to assign assessment cycle job to servers.
Parallelisation of COPA assessment cycles has greatly reduced the runtime of assessments at month end close. As long as these have been properly designed and created, they can deliver significant benefits of shortened month end close.
I hope this blog has helped you understand the concept and setup of parallelisation of COPA cycles. Please do leave your comments below whether this article was helpful; and whether you have any suggestions/ comments; or if you would like to share your experience with COPA cycle run parallelisation.
I strongly recommend you share this blog with your network using one of the social media icons at the top or bottom of this page.
You could subscribe to a newsletter from this blog using the rss icon on the top right of this page.
Rajesh is regarded as an authority in optimising and re-engineering Finance processes for his customers. Rajesh has 12 years experience implementing SAP / IT / BPM Finance solutions for several customers; he was involved in two large global rollouts and has a strong focus on Management Accounting and Reporting primarily Product Costing, Profitability Reporting and Material ledger (Transfer Pricing, Actual Costing). He also has 7 years experience working in the business in Finance and Accounting functions. His business process knowledge combined with his IT expertise enables him to provide his customers with best-of-breed advice on business process / IT implementations.