Allocation Cycle (SAP Library - Special Purpose Ledger)

Allocation Cycle

Definition

Allocation cycles summarize the rules and settings to enable an allocation to occur. An allocation cycle consists of header data and one or more allocation segments that are processed together.

Use

The header data of the allocation cycle contains information valid for all segments contained in the cycle. Within a cycle, you can define several segments. In one segment you determine the rules by which an allocation is carried out.

You can carry out the entire allocation operations of the allocation in one cycle.

You can define several cycles that are then processed by the system in the order in which they were entered. The system ensures that a cycle is processed in full before the next cycle is carried out.

Splitting into several cycles can be beneficial for the following reasons:

Performance reasons

System run time rises considerably the more segments you process in an allocation, and where the value intervals are too large

Allocation relevant reasons

Where subsequent changes are required, it is not necessary to repeat the entire allocation operations. You just repeat the cycles affected.

Using several cycles means that the allocation can occur at different times.

Cycles are saved time-based. For each cycle, you have to enter a validity period in the header data. The selected cycle has to be valid in the posting period. It is not possible, for example, to carry out an allocation with a cycle in the second half-year of a fiscal year where that cycle is defined solely for the first half-year.

Dependent allocation cycles

You can create allocation cycles that are based on one another. Cycles are deemed to be dependent on each other where one cycle uses the result of an allocation of a previous cycle. In the case of dependent cycles, it is imperative that the order of execution is observed. Before execution, be sure that:

If you have entered several cycles in the initial screens (collective execution), the system effects the cycles in the order in which they were entered. The allocation results of a cycle are transferred internally to the subsequent cycle. Iterative relationships between cycles are not taken into consideration.
If you start dependent cycles separately (individual execution), data transfer occurs via the database but the end results correspond to those of collective execution.

Dependent segments

The segment order within a cycle has no bearing on the result of cycle execution. The following execution types exist:

With Iterative indicator

When you process an allocation cycle iteratively, the result of one segment is then used by the other segments and processed further. The system continues to process the segments until all senders are completely credited.

Without Iterative indicator

When you do not process an allocation cycle iteratively, each segment in the cycle is processed independently of the other segments in the cycle. The result of one segment is not used by the following segments.

With Cumulative indicator

When you process an allocation cycle cumulatively, receiver tracing factor fluctuations or sender amounts to be allocated are cleared. In this way, a correct assignment of the allocated quantities and amounts is possible. Cumulative allocation smoothes the allocation over the periods.

You can find more information under Iterative/Cumulative Processing of Allocation Cycles.