Sequential Processing of Allocation Cycles in Universal Allocation

[Eugen_Simandel]

This blog is part of our ongoing “how-to” series exploring Universal Allocation in SAP S/4HANA Cloud Public Edition. In this post, we’ll dive into the principles of sequential processing of allocation cycles during an allocation run.

Sequential Processing in Regular Allocation Cycles

For the purpose of this article, we’ll define the following allocation types as regular:

- Overhead Allocation
- Distribution
- Intercompany Allocation

When processing regular cycles within a single allocation run, an intermediary cache temporarily stores the results of each cycle. These results are then passed to subsequent cycles in the sequence.

Example

In this example, two cycles are processed sequentially within one allocation run, with an embedded dependency.

Cycle 1 (CC_SEQ1): Costs for building maintenance are allocated from the Building cost collector cost center to other cost centers (such as HR, IT, or Sales Management).

Cycle 2 (CC_SEQ2): Building maintenance and other costs are further reallocated from Sales Management to individual sales departments.

Using the Allocation Run app (or via Schedule Overhead Accounting Jobs), we select both cycles in the correct sequence and add them to the run worklist.

The application processes both cycles as part of a single allocation run.

In the Receivers tab of the result report, you can see that the receiver object from Cycle 1 becomes the sender in Cycle 2, confirming proper sequential processing.

Thanks to temporary data persistence between cycles, both CC_SEQ1 and CC_SEQ2 are processed within the same allocation run job. Initial costs are correctly reallocated through both steps in sequence to the final receivers.

Sequential Processing in Top-Down Distribution

With the introduction of Universal Allocation in SAP S/4HANA Cloud Public Edition, the architecture of top-down distribution cycles has changed significantly. Compared to regular cycles, top-down distribution involves greater complexity and larger data volumes, which makes intermediary persistence within a single allocation run job not feasible.

Why it Matters

Sequential processing is highly valued by customers aiming to accelerate their period-end closing procedures. Without it, users have to wait for each individual cycle to finish before manually starting the next one.

Since intermediary caching is not possible due to data volume constraints, we introduced an alternative solution for top-down distribution.

How It Works

When running multiple top-down distribution cycles in a live run, a new control appears in the run dialog. This allows users to choose whether to process cycles sequentially, meaning that each cycle depends on the results of the previous one.

If sequential processing is selected, the system automatically splits the job into individual runs that are processed in sequence. The first cycle is processed, and once its results are posted to the Universal Journal (ACDOCA), the next cycle is triggered automatically—no manual intervention required.

Example

Let’s consider two top-down distribution cycles we want to process in a single run job with sequential processing:
- TDD_SEQ1: Distributes from Sales Organization to Customer Group level.
- TDD_SEQ2: Further distributes from Customer Group to individual Customer Detail level.

The user prepares a run worklist containing both cycles. Upon selecting the Live Run option, the system detects multiple top-down distribution cycles and presents the Sequential Processing option in the dialog.

When the user selects the Live Run option, the system detects multiple top-down distribution cycles and presents the Sequential Processing option in the dialog.

 Users can choose between two modes:
- Run sequentially but Stop on Error:  If any cycle ends with an error, processing stops. For example, if five cycles are in the worklist and Cycle 3 fails, then the processing of Cycles 4 and 5 is canceled. If the Situation Framework is enabled, the user is notified and can decide how to proceed.
- Run sequentially but Stop on Warning: If any cycle ends with a warning, processing stops. The user must decide how to continue.

In our example, the user selects Stop on Error. After initiating the run:
1. The first cycle is processed, and the first run appears in the Allocation Results app.
2. The second run job is automatically triggered after the first finishes, and the second cycle is processed.

The run report in Allocation Results shows that the initial run was split into two jobs, with data from TDD_SEQ1 used as input for TDD_SEQ2.

Summary

Sequential processing enables the handling of cycles with data dependencies. It is supported for both regular allocation cycles and top-down distribution cycles, though each uses a different method:
- Regular cycles use intermediary caching within a single run.
- Top-down distribution uses automatic job splitting and Universal Journal persistence.
This flexibility helps streamline allocation processes and supports faster, more efficient period-end closing.