See how to configure the newly updated SAP Closing Cockpit to assign individual tasks and hierarchies properly.
Key Concept
SAP recently redesigned its ERP-based SAP Closing Cockpit and plans to deliver it with an add-on option of a new task scheduling tool, Central Process Scheduler (CPS). SAP plans to make this generally available to customers by mid-second quarter of 2008. Closing Cockpit aims to make your closing process speedier and more controlled, ultimately delivering cost savings to your bottom line. It then can provide accurate and timely information to senior management and external stakeholders. To use the new Closing Cockpit, you must have an active SAP ERP 6.0 system with Enhancement Package 3 installed. In addition you need ERP Support Package 1 installed within the SAP ERP system. As for the SAP NetWeaver technical base, you should have SAP NetWeaver 7.0 with Support Package 14 installed.
SAP revamped the Closing Cockpit to include new functions for users on an SAP ERP 6.0 system. In addition to revamping the Closing Cockpit task list to provide a more user-friendly interface via a Web-enabled view, SAP has added other new features to enable better task assignment, task list management, graphic interface, and cross-system integration via Central Process Scheduler (CPS), among other benefits. All these new features are available with SAP ERP 6.0 and the addition of Enhancement Package (EP) 3. (For further information regarding the contents within EP 3 go to https://websmp110n.sap-ag.de/erp.)
I’ll show you a five-step process to take you from the project planning phase through configuration steps to configure the new Closing Cockpit in your system.
Step 1. Conduct planning and research
Step 2. Create the basic template data
Step 3. Build the closing template hierarchy structure
Step 4. Configure individual tasks
Step 5. Change the template to an executable task list
Step 1. Conduct planning and research. Before you begin to configure Closing Cockpit you need to understand the closing process and closing schedule currently in use. Most companies control and schedule their close by documenting their tasks, task owners, time sequences, and estimated time of task execution in some sort of a spreadsheet. If you have such a documented schedule, you are off to a good start. If there is no documentation available, then you need to do some research to generate such a documented schedule. The proper configuration of Closing Cockpit requires a thorough understanding of the actual closing process from beginning to end.
Key points that you must understand include:
- Tasks to be performed
- The order of performing the tasks
- Who owns the task
- Who executes the task
- Who reviews and approves the results after the task is completed
- How long the task takes to complete (run time)
- The post-close audit requirements
After you have identified and documented these key points, you can move ahead to the next steps to begin the configuration of Closing Cockpit. The information in step 1 is the source document for the following configuration steps. Therefore you should take all the time necessary to ensure this schedule is complete.
Step 2. Create the basic template data. The cockpit template basic structure provides the formal structure for the organizational hierarchy, closing tasks in the form of lists, and ownership of the task by identifying the individual task owners. The template task list configuration can also control the order of precedence or sequence of the individual task execution. For example, normally you should complete all the FI accrual processes prior to running the final Controlling (CO) expense allocations. Setting task precedence within the template ensures the proper sequence of task execution during the close. By configuring the Closing Cockpit template, you set up the basic closing model that the system copies to a date-specific task list. After copying the template into a task list, the individual task owners can begin the closing process. In other words, after you finish configuring the template it becomes the formal schedule for each month’s close when you copy it into a task list. The actual process of copying the template and assigning the closing date would normally been done by someone other than individual task owners. It would most likely be done at the corporate level — for example, by a corporate accounting manager or controller.
You complete the configuration of the cockpit template by using transaction code CLOCOC or by following menu path Financial Accounting > General Ledger > Periodic Posting > Closing > Closing Cockpit (Manage Templates and Task Lists). This brings you to the Closing Cockpit display screen. Every time you enter the template using the transaction code or menu path it automatically comes up in display mode. To perform any configuration steps or changes you must change the screen status to change mode via the change screen status icon
. After changing the template screen status to change mode, select the menu option Template/Task List.
From the drop-down menu you have two options. You can create a new template completely. Or, to save some time and effort, you can copy a task list configured from Schedule Manager (in the R/3 4.7 release) or select one of the SAP- delivered task lists. To use the copy option, select Other Template/Task List followed by the Save As option.
In this example I’ll build a template from scratch. To do this, select the Create Template menu option. Within the pop-up template configuration window, the system asks for the following information: the name of the template (text entry), closing hierarchy structure, template description (text entry), person responsible for task list after it is created, authorization group, and factory calendar ID.
The closing hierarchy setting selected here determines which organization structures the configured template addresses when you complete the task list folders and structure assignments in the next configuration step. It is important to consider this because it controls the hierarchy structure in the task list. The most common settings for a financial closing are the controlling area and company code selections. Other options include profit centers and operating concern for Profitability Analysis (CO-PA) reporting, which you use mostly for final result reporting. In my example, I’ll use controlling area and company code because the objective is to design a template that you can use to control a monthly financial closing schedule.
After you complete the text entry for the template title or description, the next entry identifies the person who is responsible for the follow-up task lists that the system copies from the template. This is an important setting because it gives this person authorization to make some changes to the task schedules and to execute and review the various tasks contained in the task list. In the authorization group setting, you can restrict access to the template with prior authorization group settings. Note that it is not a mandatory setting, but considering who has access to templates and task lists is important for security reasons.
When you configure the individual tasks (which I’ll get to in step 4), you need to identify the day within the closing schedule on which the task runs. By using the factory calendar setting, which is a new feature in EP 3, the final schedule automatically allows the task list scheduling function to recognize any non-working days and reschedule the task around them. After you have completed the basic settings and saved the template, you can move on to the next step for the closing template.
Step 3. Build the closing template hierarchy structure. After you have completed the basic planning and setup of the template, the next step is the construction of the template. The template structure starts with the construction of a hierarchy of task folders. After you complete the folder hierarchy, you then assign organizational structures to the folders. You can determine the organizational structures that are available at this step by the settings you completed in step 2.
Figure 1 shows the setup of my example template using the controlling area and company code as the template hierarchy selections. This view includes all the controlling areas assigned to the single client. You can see in the example that each controlling area has been assigned to a folder under the client name folder (IDES in this example) at the top of the list.

Figure 1
Initial task list configuration
Note
In this example you can see many folders are delivered automatically. This is because this example is using an SAP demo server that has more than 200 controlling areas in use. In your system it would only display the active controlling areas in the client. If this is still too confusing it is possible to delete the folder structures and start from scratch. Also, folder names are simply text entries so you can change the names via the context menu if you wish. You can also add and delete folders via the context menu.
To confirm the assignments to the folders, right-click on any folder to bring up the context menu and examine the assignments to the folder. In the example in Figure 2, I selected the CO Europe folder and you can see by the green plus sign that Controlling Area 1000 is assigned to the folder. This means that during the task configuration (step 4) you can assign tasks to execute across all company codes within controlling area 1000.

Figure 2
Assignment of Controlling Area 1000 to folder (the green + indicates formal assignment)
If you wish to add another controlling area or change the current assignment to a folder, you can use the change icon to add or delete controlling areas from the folder. In my example you don’t need to make any changes because the proposed assignment of controlling area 1000 is correct. Next you need to review and refine the assignment of the company codes within controlling area 1000. Right-click and use the context menu to display the company codes assigned to controlling area 1000. Just as with the controlling area assignments, you can delete or change the company code assignment by clicking on the change icon to change the screen status to change. Figure 3 shows that the system also lists all company codes within controlling area 1000 with the option to add or delete the individual company codes. Again, the system determines the displayed structure of each folder, in this case, controlling area to company code, when you select the template hierarchy in the initial setup (step 2).

Figure 3
Company code assignment to CO area (green + indicates formal assignment)
The structure configured in step 3 controls at which level in your organization each task executes. For example, if you assign a task at the highest level (in this example, the IDES folder) this task executes across all controlling areas and company codes within the single client. If you assign the task at the controlling area folder, it executes across all company codes within the controlling area. If you assign the task at the company code folder level it only affects the single company code when it is executed.
After you have completed the folder structure and the formal assignment of the controlling areas and company codes, you now can configure the individual tasks to be performed during the closing process.
Step 4. Configure individual tasks. Some of the initial decisions to consider during individual task configuration are who is responsible for the task and what organizational structures the task affects. In the template used for this example, you can set the task execution to affect all controlling areas within the current client, at the controlling area level to affect all company codes within the controlling area, or at the single company code level. This configuration structure was determined by the configuration completed in steps 2 and 3.
If a task is required that affects all organizational structures within a client, you should configure it and attach it to a folder in which you’ve assigned all controlling areas. Examples of such tasks include an information broadcast via workflow stating that the closing process is ready to begin, or the opening of the next accounting period. Depending on your closing schedule, you’ll likely find more examples of tasks that executives should execute.
Likewise, some tasks should only affect single controlling areas. The next level of task configuration and assignment is to those folders with controlling areas formally assigned. An example of this type of task is the monthly billing cutoff or inventory movement cutoffs that should affect all company codes within a single controlling area.
Finally, consider those tasks that are relevant only for the individual company codes. As described earlier, configure and assign tasks to the individual folders in which you have formally assigned individual company codes. Also, remember during this configuration step that the key to the structure and task assignment is the initial spreadsheet or schedule that you completed in step 1.
In this example, you need to add a CO expense allocation task that you assign to a single company code (IDES AG) within a single controlling area (CO Europe). The first step in this process is to configure a task folder at the proper organizational level.
Then you need to configure a new folder for CO expense allocations. You add this task folder under the folder assigned to controlling area CO Europe and then under the company code folder to which you assigned the company code IDES AG. To do this, right-click on the correct folder (IDES AG) to access the context menu and click on Create Sub-Folder, which brings up the pop-up window in Figure 4.

Figure 4
Add task folder
Next configure the actual task to be assigned to the task folder. Right-click on the new task folder and select Add Task from the context menu. This brings up the task configuration screen (Figure 5).

Figure 5
Add task configuration window
The first section of the task configuration screen requires the names of the task (text entry), task owner (responsible block), and responsible party who executes the actual task. In some cases the task owner and the responsible party are the same person. Remember that you can set tasks to execute at various organizational levels. For example, the person who owns and reviews the task might be in Europe while the person who actually executes the task might be in Asia. The system compares the entries in this screen with the actual user sign-on names. In this example, the system displays real last names but it is possible to use other sign-on authorizations by position (e.g., AP1 (Accounts Payable 1)).
Next you need to identify the actual type of task. Within this option, you need to set individual tasks as actual programs with no variant assigned, programs with job variants assigned, transaction codes, memo entries, flow definitions, or, as shown in this SAP ERP 6.0 example, remote tasks using CPS.
Note
By using CPS, you can use several new features beyond those of the basic Closing Cockpit. Among these are cross-system linking, which allows the host ERP system to call and schedule a task on remote systems, such as a CRM system or even a non-SAP system. Also available is event-based scheduling rather than a time-based system. This feature automatically compresses the closing schedule based on job completions. For more information, go to the SAP Service Marketplace and the CPS page:
https://service.sap.com/job-scheduling.
In brief, the differences between the various task types are:
Program without variant. Selecting this option assigns an executable program to the task folder. However, as you execute the task, you need to perform certain operational parameters. In this example regarding CO allocations, because you have not assigned a job variant, the person executing this task must identify the cycles, time frame, and so on, just as in executing the cycle from the main CO menu path.
Program plus a job variant assigned. You can schedule this type of task to kick off automatically based on the scheduled time. It also allows you to configure a job variant that establishes the execution parameters for the task. In this case, the job variant supplies the operational parameters required for the cycle to execute. These types of tasks are useful because they execute automatically without any intervention. Examples of this type of task are the application of overhead costs to production orders, settlement of various internal orders, or the execution of cost center expense clearing cost allocation cycles.
Transaction. This task calls a single transaction code. It operates almost the same as the program task without a job variant but uses the transaction code rather than the program, so it is a bit easier to configure. For example, transaction code KSU5 calls up a CO assessment cycle. Because there is no program variant available to make the cycle selection, the system displays the normal CO assessment cycle selection screen to the task processor. You need the task processor so you can enter the cycle parameters and execute the cycle following the same routine as if using the standard ERP CO procedures.
Notes. This task selection option creates a task that is a memo format entry. For example, the task list may call for certain confirmations and checking routines, such as checking to ensure the monthly allocation is set for the correct amount, or that the work in process (WIP) inventory value is correct. This type of task allows the task owner to make a memo entry for recording the completion of the task and any additional comments that are relevant. This type of task is very useful for recording comments and documentation of the closing process and audit and compliance issues.
Remote task. With the addition of CPS, you can set up remote tasks that you can execute outside the host ERP client. For example, it is common practice to host the payroll systems on isolated systems other than the central ERP server. Or in another example, many companies perform the billing procedures using a CRM server rather than the SD functions within ERP. To interface the cockpit tasks with these remote servers, your system needs CPS, which then activates the remote task configuration feature. The configuration of this type of task requires the identification of the remote system and the program or task that is to be executed on the remote system. As shown in Figure 5 CPS is active within this system example; if CPS were not active the remote task configuration option would not be available.
Next is the event/time scheduling for the task. Again, the best source of task sequencing is the existing closing schedule (from step 1). The first requirement for the task schedule is the number of off-set days from the first day of the closing (day “zero”). For example, certain tasks run prior to the first day of the closing cycle and others run after the official start of the closing cycle. Assume that the first day of the current closing cycle is March 1, 2008. For a task that runs two days prior to the closing cycle date (March 1/day zero), enter a - 2 in the offset block. This means that after you establish the task list for the March 1 close, the system schedules the task that has a date setting of -2 to execute on February 27, or two days earlier. For those tasks scheduled to run two days after March 1 enter a +2 in the offset block, and the system schedules the task to run on March 3. This template “day” schedule is not assigned to any specific calendar dates within the template because templates are not date specific. The system assigns the actual calendar dates to individual tasks after you convert the template to a date-specific task list (step 5).
Next enter the scheduled starting time for the task and finally enter the expected run time for the task. You can also designate the task as belonging to the critical path task listing to enable better tracking via sort routines within Closing Cockpit.
Finally, assign the new task to the closing types where you might use it. Checking all boxes enables you to copy the task into any type of task list that you might use in a monthly, quarterly, or annual closing process. There is no harm in checking all boxes to enable the task to be copied into various templates.
After you have completed the task configuration, return to the main template screen by clicking on the red check icon on the bottom of the pop-up window. The new task is added to the CO Expense Allocations folder and produces a button (Co Assesment Cycle in this example), which indicates this task is configured as a transaction code and requires the task processor to execute the task manually. The final step in the configuration of the cockpit template process is to save it for future use as a task list.
Step 5. Change the template to an executable task list. Now that you have completed the template you can copy the template into an executable form or a date-specific task list. (For more on templates and task lists, see the sidebar, “Differences Between Templates and Task Lists.”)
First copy the closing template to a date-specific task list. To perform this step, use transaction CLOCOC to access the available templates. Select Template/Task List from the blue menu bar to access the available templates. From the drop-down menu options, select the Other Template/Task List option to see all the available templates. Double-click on the template name to display the template. To create a date-specific task list, reselect the menu option Template/Task List and then Create Task List(s) to bring up a task list configuration pop-up window (Figure 6). Don’t forget to change the screen setting to the Change option.

Figure 6
Pop-up window for copying templates to date-specific task lists
The most important block in the task list configuration pop-up window is the Key Date field. Enter the first day of the closing cycle. This becomes day zero within the task list and the system uses this date to schedule all individual tasks that you configure in the selected template (see step 4). You also need to identify the Closing Type (in this example monthly [M]), Posting Period (3), Fiscal Year (2008), task list Status (Released), and the person responsible for the task list (FULLMER).
Note
Although it is possible to set up multiple task lists tied to different dates, the status setting controls when the task list becomes executable. You can only execute the task list after the task list owner changes the status to Released. If you choose to set up multiple task lists for an entire year, you would only set the single task list that you would use for a particular month to Released. You could review all other date-specific task lists, but could not execute them. Other task list status settings are: Not Released, Released, Active, and Closed.
After you copy the template to a date-specific task list and set the status to Released, it becomes executable and the system schedules the individual task to exact calendar days and day-specific time frames. As always, the success or failure of a project such as this one depends on thorough preparation and planning at the front end. To be successful, you need to have a clear understanding of the current closing routines, the required tasks, who is responsible for each task, which tasks when executed should affect which level of the organization, and finally a clear process for review and documentation.
Differences Between Templates and Task Lists
The major differences between the template and the task list are:
- Templates allow for configuration of various tasks but cannot execute any task. The task list is not configurable but allows for the execution of the various tasks.
- Task lists are copies of single cockpit templates. You should configure cockpit templates to allow for repeated use, with little or no changes from period to period.
- You configure tasks within the template and cannot change them within the task list
- You initially schedule tasks within the template, but you can reschedule them within the task list if required
- It is possible to create sequences of date-specific task lists by selecting the menu option Create Task Lists. This is useful if you wish to create an entire year’s worth of task lists at one time.
Gary Fullmer
Gary Fullmer is currently associated with MI6 Solutions as a solution architect. Prior to MI6 Gary recently worked for SAP Labs for 13+ years. While at SAP Labs, he spent his first four years as a CO instructor developing and delivering all CO courses offered in the SAP course catalog. For the next six years, he assumed the role of a FI/CO solution manager, where he focused on interfacing with customers for CO, SEM, and FI solutions. During the remainder of his time with SAP, he worked on SAP General Ledger migration techniques, the SAP IFRS adoption model, and SAP’s enhanced financial closing, and continues to consult on these topics. His educational background includes an MBA from Rensselaer Polytechnic Institute, an MS from Utah State University, and a BS from Utah State University.
You may contact the author at gary.fullmer@MI6solutions.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.