Multilevel Worklist (SAP Library - Period-End Closing (CO-OM-CCA))

Multilevel Worklist

Use

The worklist of the Schedule Manager is a multilevel worklist. This worklist is particularly useful for the period-end closing activities.

Why Is the Worklist Multilevel?

In previous releases, the period-end closing process in the R/3 system consisted of a series of batch jobs. The sequence of the processing steps was established by the order in which the jobs were called. The objects were selected separately for each job. Through the selection criteria entered, it was possible to specify a unified scope of selection. This scope of selection had to be respecified for each processing step (that is, for each individual function of period-end closing).

When an object was processed, errors that occurred in previous processing steps were not taken into account. For this reason, it was necessary to check the objects that had errors once a job was completed. Any errors had to be corrected and then the job restarted for the entire scope of selection. In some areas (such as the period-end close in Product Cost by Period), it was already possible to create a single-level worklist for individual processing steps. With this single-level worklist, the objects with errors could be called up for each processing step, and the causes of the errors determined. The processing step could then be performed again for the object after the error was corrected. This worklist did not prevent objects with errors from being processed in the subsequent processing step (that is, in the subsequent job).

Advantages of the Multilevel Worklist

The worklist of the Schedule Manager is a multilevel worklist. This means that the worklist is generated for a sequence of processing steps rather than for just one processing step. The worklist therefore enables efficient execution of processing step sequences. Processes such as period-end closing can be performed much more efficiently with a multilevel worklist.

The multilevel worklist has the following advantages:

The processing step sequences (such as in period-end closing) can be performed faster than before.

Manual processing after completion of each job is no longer necessary. Manual processing is only necessary after executing a sequence of processing steps that consists of multiple jobs (for example, complete closing of an application component).

Furthermore, if errors were issued for objects in the single-level worklist, it was often necessary to repeat the processing steps for the entire scope of selection (and not just for the objects with errors). With the multilevel worklist, the processing steps are repeated only for the objects that have errors.

CPU time is reduced because objects are selected only once for each processing step sequence, instead of for each individual processing step. Objects are selected before the first processing step is executed. The multilevel worklist provides performance benefits particularly with complex structures in which dependencies between objects must be taken into account (such as complex project structures).

As a rule, jobs are planned and monitored by members of the EDP team. In many cases, these employees are not responsible for the correcting the errors shown in the error logs. With the multilevel worklist, you can directly inform the employees responsible for correcting the errors. This notification takes place by means of a mail message that is sent automatically through the workflow.

Integration

The multilevel worklist is part of the Schedule Manager and is always used with the other functions of the Schedule Manager (see Prerequisites).

The following applications, functions, and objects are currently supported by the multilevel worklist:

Cost Object Controlling: Manufacturing Orders and Product Cost Collectors

Process Flow	Period-end closing for manufacturing orders and product cost collectors
Scope of Selection for Processing Objects	Closing encompasses production orders, CO production orders (production orders without a quantity structure), process orders; product cost collectors and QM orders. With co-products, some of the period-end closing work is performed at the level of the items of the manufacturing orders. A prerequisite is that the following requirements are met for these objects: The objects are not assigned to a cost object hierarchy, or it is specified in the cost object category that the individual orders of a material are processed outside the cost object hierarchy (see Product Cost by Period). Account assignment can be made directly on the objects. This means that with regard to the selection of manufacturing orders, account assignment is made on the manufacturing orders themselves and not on a product cost collector. The objects do not have status DLFL (deletion flag). Product cost collectors are objects of the Product Cost by Period subcomponent. Manufacturing orders (including manufacturing orders without a quantity structure) are objects of the Product Cost by Order subcomponent.
Processing Step	Objects
Template allocation	Order header (including product cost collectors)
Revaluation at actual prices	Order header (including product cost collectors)
Actual overhead	Order header (including product cost collectors)
Preliminary Settlement for Co-Products, Rework	Preliminary settlement for co-products: Order header of manufacturing orders as processing objects; order items as receivers Preliminary settlement of rework: Order header of manufacturing orders as processing objects, order header of manufacturing orders or product cost collectors as receivers; but not: Settlement of rework on product cost collectors or manufacturing orders assigned to a cost object hierarchy (see below) Preliminary settlement of collective orders (old processing method without automatic goods movement) Header of manufacturing orders as processing objects, header of manufacturing orders as receivers
WIP calculation	Production and process orders or, in joint production, their items, as well as CO production orders and product cost collectors
Variance c alculation	Production and process orders or, in joint production, their items, as well as CO production orders and product cost collectors
Settlement	Production and process orders or, in joint production, their items, as well as CO production orders and product cost collectors

Cost Object Controlling: Cost Object ID (Cost Object Nodes in a Cost Object Hierarchy and General Cost Objects)

Process Flow	Period-end closing for cost object ID
Scope of Selection for Processing Objects	Period-end closing includes: Cost object nodes of cost object hierarchies and the single objects assigned to the cost object hierarchy These can be the following: Product cost collectors, manufacturing orders, production orders without quantity structure, and (if applicable) order items of manufacturing orders (with joint production) for which the following conditions apply: Account assignment can be made directly on the objects. This means that account assignment for manufacturing orders is made on the manufacturing order itself and not on a product cost collector. The objects do not have the status DLFL (deletion flag). Cost object hierarchies are part of the Product Cost by Period component. General cost objects General cost objects are objects of the Costs for Intangible Goods and Services component.
Processing Step	Objects
Template allocation	Cost object nodes of cost object hierarchies or the single objects assigned to the cost object hierarchy (product cost collectors, manufacturing orders or production orders without quantity structure); general cost objects
Revaluation at actual prices	Cost object nodes of cost object hierarchies or the single objects assigned to the cost object hierarchy; general cost objects
Actual cost distribution	Cost object nodes of cost object hierarchies; the single objects assigned to the lowest cost object nodes are the final receivers
Actual overhead	Depending on the Customizing settings, cost object nodes of cost object hierarchies or the single objects assigned to a cost object hierarchy; general cost objects
Preliminary Settlement for Co-Products, Rework	Only for orders assigned to the cost object hierarchy: Preliminary settlement for co-products: Order header of manufacturing orders as processing objects, order items as receivers Preliminary settlement of rework: Order header of manufacturing orders as processing objects, order header of manufacturing orders or product cost collectors that are assigned to the cost object hierarchy as receivers
WIP calculation	The single objects assigned to a cost object hierarchy; but not: Order items in joint production (manufacture of co-products), CO production orders
Variance calculation	Depending on Customizing settings, cost object nodes of cost object hierarchies or the single objects assigned to the cost object hierarchy
Settlement	Depending on Customizing settings, the top nodes of a cost object hierarchy or all nodes of the cost object hierarchy; if applicable, all orders assigned to the cost object hierarchy, and in joint production the items of the manufacturing orders; All general cost objects

Project System

Process Flow	Period-end closing for Project System
Scope of Selection for Processing Objects	WBS elements, networks, and orders
Processing Step	Objects
Generation of settlement rule	WBS elements
Template allocation	WBS elements, networks, and orders
Actual overhead	WBS elements, networks, and orders
Revaluation at actual prices	WBS elements, networks, and orders
Cost forecast	Networks
Interest calculation	WBS elements, networks, and orders
Project earned value	WBS elements, networks, and orders
Results analysis	WBS elements and orders
Incoming orders	WBS elements
Settlement	WBS elements, networks, and orders
Reporting	WBS elements, networks, and orders

Internal Orders

Processing Step	Period-end closing for internal orders
Scope of Selection for Processing Objects	Internal orders, maintenance orders
Processing Step	Objects
Template allocation	Internal orders, maintenance orders
Revaluation at actual prices	Internal orders, maintenance orders
Actual overhead	Internal orders, maintenance orders
Interest calculation	Internal orders, maintenance orders
Results analysis	Internal orders, maintenance orders
Settlement	Internal orders, maintenance orders

Sales Orders

Processing Step	Period-end closing for sales orders
Scope of Selection for Processing Objects	Sales order items that carry costs and revenues
Processing Step	Objects
Template allocation	Sales order items that carry costs and revenues
Revaluation at actual prices	Sales order items that carry costs and revenues
Actual overhead	Sales order items that carry costs and revenues
Results analysis	Sales order items that carry costs and revenues
Settlement	Sales order items that carry costs and revenues

Prerequisites

You are working with the Schedule Manager and are using all of its functions.

A prerequisite for the use of the multilevel worklist is that a constant quantity of objects (or, in subsequent executions, their subset) is processed in a predefined sequence of processing steps.

The selection set of the objects is determined through the application you select (for example, Cost Object Controlling: Manufacturing orders and product cost collectors) (see above), as well as through any additional entries that you may make when creating report variants (see below).

The sequence of processing steps is specified in the flow definition.

This means that you proceed as follows:

Go into the Scheduler of the Schedule Manager.

From the scheduler, create a flow definition. In the flow definition, specify the processing step sequence (for example, a sequence of all single functions of period-end closing for product cost collectors). The creation of the flow definition is realized through the Workflow Builder.

You access the flow definition with the menu options Extras ® Process the flow definition. When you create the flow definition, you should:

Specify which application the flow definition is intended for (such as Cost Object Controlling: Manufacturing Orders and Product Cost Collectors)
Make sure you create a flow definition with a worklist
The Workflow Builder appears. Depending on the application you selected, you receive a SAP template that you can modify to meet your requirements.

Create a task for each processing step in the flow definition. Such tasks can be, for example, reports for the single functions of period-end closing or user decisions.

To facilitate maintenance of the flow definition, the system offers you a default template. This consists of a task placeholder at the beginning of the flow as well as a task placeholder in the feedback loop. You define the placeholder at the beginning of the flow before the feedback loop as a report task for selecting the worklist. You define the single functions of period-end closing as tasks in the feedback loop.

To define the selection or a single function (such as overhead calculation) as a task, select the Program indicator when you create the task. Then, select the report from a proposal list that you want to include in the processing sequence (such as Overhead: Worklist of Manufacturing Orders)

Then create a report variant for the execution of the report. Maintain the parameters for the variant. Here you can specify various parameters such as whether a detail list is output and whether processing takes place simultaneously on multiple servers.

You can further filter the scope of selection of the object to be processed by using a selection profile.

In addition, enter the period and fiscal year.

Note

You can use the same flow definition each time if you enter selection variables instead of fixed values for the period and fiscal year when you maintain the report variants. In this case, the system calculates the period and fiscal year of the single functions dynamically from the current values for these variables when it executes the flow definition. This is only possible if you use selection variables (called TVARV variables) for the period and fiscal year parameters. When you create the report variant, you specify that you are working with selection variables. You maintain the selection variables by entering the transaction STVARV, or by starting the transaction through Extras ®Settings ® Selection Variables in the menu of the Schedule Manager and changing the variables there to the period and fiscal year to be processed. This enables you to use the same job variant every month. You only need to update the TVARV variable before executing the job variant.

You specify a user decision if you want the previous processing results to be checked after one or more processing steps. After executing the previous processing steps, the system automatically sends a mail message to the person responsible for checking the results (usually the cost accountant). When you create the flow definition, you specify which user receives this mail.

When you use the multilevel worklist, the system always specifies a user decision and a feedback loop for the reentry into postprocessing as the last step of the flow definition.

You can also insert user interactions at other points in the process definition if you want to check the objects processed up to a particular step before continuing with processing.

If you approve (release) the check of the objects with errors, you make it possible for the objects with errors to automatically be reprocessed later.

Enter the flow definition as a task in the task list of the Scheduler.

Start the task (the flow definition) in the Scheduler.

You monitor the flows and jobs during and after processing in the monitor of the Schedule Manager.

Features

Basic Functions of the Multilevel Worklist

The multilevel worklist is generated for an entire sequence of processing steps.

The scope of selection is determined once and is valid for all processing steps. The worklist encompasses the objects of the scope of selection for which processing in the present processing step sequence is both possible and necessary. The scope of selection, therefore, equals the maximum scope of the worklist. Certain restrictions can be specified for individual processing steps in the scope of selection. These restrictions are usually determined through selection profiles that are specified when report variants are created.

The processing steps are performed in an order strictly defined in the flow control of the scheduler. A processing status is maintained for each object and processing step. The processing status indicates whether further processing of the object is allowed.

Each processing step only contains the objects for which (based on the processing status of the previous processing step) processing in this step is allowed.

In each processing step, dependencies between objects are interpreted according to the application. For this reason, it can be necessary to include other objects when processing an object in a step. The system accounts for such object dependencies automatically. You do not have to make any additional settings.

Example

You want to perform results analysis for a WBS element (nonvaluated project stock). Production orders whose actual costs should be included in results analysis are assigned to the WBS element.

There are individual worklists for each processing step sequence (that is, each flow definition). Typical processing step sequences are the period-end closing sequences for the individual application components. Individual worklists are created for each application (for example, for internal orders and projects).

The multilevel worklist fulfills the following basic requirements:

The selected objects are processed as far as possible.
The selected objects are only processed when processing is both necessary and possible.
Object dependencies are taken into account.

Object dependencies can be encountered, for example:

In engineer-to-order environments
When you are using cost object hierarchies

Example

Suppose you are performing results analysis for WBS elements in an engineer-to-order environment. The system first determines which WBS elements are relevant on the basis of the selection criteria. These WBS elements are called primary objects because they are the original objects to be processed.

Results analysis also includes values that are posted to the production orders assigned to the WBS elements. These production orders are selected on the basis of their dependency on the WBS element. They are called secondary objects.

The determination of secondary objects depends not only on the type of worklist (for example, cost object hierarchies, projects), but also on the present business function and on the processed objects.

Example

Suppose you are performing period-end closing for a cost object hierarchy.

You calculate the actual overhead at the level of the cost object nodes. In this case, there are no dependent objects because every cost object node is included in overhead calculation. Relationships to other cost object nodes do not play a role.

You also want to distribute the actual costs assigned to the cost object nodes to the lowest cost object nodes of the assigned product cost collector. The following situation arises during distribution:

As soon as a cost object node in a cost object hierarchy is a primary object, all other nodes are secondary objects (as long as they are not also primary objects).

During the execution of the flow definition, the individual processing steps receive a list of the objects to be processed. Each processing step sends the processing status of each object and a list of the displayed messages back to the worklist.

Note

The scope of selection can contain all objects to be processed in a particular flow. However, in some situations you may want to perform the same flow more than once in parallel with different scopes of selection. This manual parallel processing can serve to reduce the overall run time.

Example

Suppose you want to perform period-end closing for the application component Product Cost by Order in Cost Object Controlling. You can process all production orders and process orders in a plant, or all plants in a controlling area.

You create multiple scopes of selection in which you select by plant and order type. This means that, for example, one scope of selection includes all production orders in a plant, while another scope of selection includes all process orders in that same plant.

The previous processing step in the sequence must be fully completed before the next step can be started.

After the entire processing step sequence has been executed, the user forces a manual check.

The user-defined flow of individual processing steps (specified in the flow definition), the check of the objects with errors, as well as the release of this check (for renewed processing of objects) should be repeated until all objects in all processing steps have the status OK. Once this is achieved, processing is completed.

Processing of Objects in the Worklist

You process the worklist in the monitor. The monitor shows a list of the faulty objects and the messages issued for the objects. This information is needed for analyzing and correcting the errors.

In the monitor, you can specify how objects are to be processed the next time the processing step sequence is executed. For example, you can specify the following:

That objects marked as faulty in a given processing step are excluded the next time that processing step is executed, and instead enter the subsequent processing step.
That objects processed without errors are nevertheless reprocessed if they are faulty in a business sense (for example, as a result of incorrect Customizing settings)

Note

If an object was processed without error in an update run for project interest calculation, new interest calculation can only be triggered if the previous interest calculation is first reversed. If no reversal is carried out, the object is not included in the recalculation of interest even though its processing status would normally allow this.

You control this through the processing status for the object and processing step.

Note

Note the following:

If an object has been changed since it was processed in the processing step sequence defined by the flow definition (for example, additional costs have been assigned to the object), this change is not taken into account if the object has already been processed without error. In this case, you should change the processing status for the first processing step of the processing step sequence to force reprocessing.

See also:

See the following sections for additional information on the monitor and how to use it:

Schedule Manager: Monitor - Working with the Object List

Processing Worklists

Processing Status

Triggering Reprocessing of Objects

Automatic Reprocessing

Once all objects have been processed and you have corrected the errors or specified that the processing step for which errors were issued should be skipped, the processing step sequence can be repeated in order to reprocess the objects that had been faulty in the previous run. You initiate reprocessing from the mail.

The system then processes the objects in the selection scope that had been processed with errors in the first run of the processing sequence and those that you instructed the system to reprocess (processing forced manually). For each object, processing starts with the processing step that had errors or for which processing was forced manually. The only processing steps repeated for an object are those for which errors occurred in the previous run, those that have not yet been performed, and those for which reprocessing was forced.

Both in the first run and in the repeated run, the only objects that are processed in each processing step are those that were successfully processed in the previous step and that have not yet been successfully processed in the current step. This limits the number of objects to be reprocessed in each step to those for which errors appeared in that step or in the preceding steps of the first run. Dependencies between objects are also taken into account. That is, depending on the object to be processed and the processing step, it may be necessary to reprocess additional objects even though they were already processed successfully.

Administrative Data Reorganization of the Multilevel Worklist

The administrative data of multilevel worklists encompasses the scope of selection, the step information (flow step), the processing status for the object, and the error messages for the object. This administrative data is deleted together with the workflow data of the Schedule Manager. It is not possible to archive the worklists.

Activities

Once all processing steps have been executed, the system informs you by mail that the results of the processing steps are ready for review. After you have checked the results and corrected any errors, the system asks you whether you would like to repeat reprocessing.

To make the relevant checks, access the monitor of the Schedule Manager.

You can access the monitor in the following ways:

From the mail
Directly from the menu of the application component

See also:

Multilevel Worklist: Process Flow