Show TOC

 Cycle Locate this document in the navigation structure

Definition

A cyclecan comprise one or more segments

This graphic is explained in the accompanying text.

You can create up to 999 segments in a cycle.

Use

Theoretically, you can define a cycle for an entire controlling area.

For performance and allocation reasons, however, you can create several cycles, which you can process sequentially. This ensures that one cycle is processed before the next cycle is executed.

This division into cycles is advisable for many reasons:

You can allocate the costs of organizational sub-areas separately by dividing them into cycles, including time-based divisions. You do not need to repeat all the cycles if errors occur or changes are required.

This graphic is explained in the accompanying text.

You have divided your allocations into four cycles. An error occurs in the third cycle. You can correct this error and repeat the allocation for this cycle. You only have to repeat the fourth cycle if it is dependent on the results of the third cycle.

This method is attractive to organizations with a large number of cost centers or business processes, where it is too time-consuming to process allocations in a single cycle. Dividing allocations into multiple cycles also allows you to allocate costs at different times.

You can create modular allocation cycles. For example, you can process service cost centers or business processes in the first cycle and the individual cost centers or business processes in a later cycle.

Dependent Cycles

Cycles are said to be dependent, if a cycle uses the results from a previous cycle’s allocation. Therefore, you must execute dependent cycles in the correct order to ensure correct results.

Note the following requirements:

If you have specified several cycles in the initial screens (collective start), the system executes the cycles sequentially. The allocation results for a cycle are transferred internally to the next cycle. The database update time is insignificant. Iterative relationships between cycles are not included.

If you start dependent cycles separately, data exchange takes place in the database, but the end results correspond to those for the collective start.

Dependent Segments

The sequence of the segments in a cycle has no effect on the cycle results.

The system uses two forms of segment execution:

Executing without the iteration indicator: Each segment is processed separately. Dependent or cyclical segment relationships are ignored.

Execution with iteration indicator: Allocation takes place iteratively between segments until all senders are credited or the agreed residual percentage is reached. Dependent or cyclical segment relationships are processed.

(see Iterative Processing of Cycles )

Validity Periods for Cycles

Cycles are saved time-based. You must define a validity period for each cycle.

This graphic is explained in the accompanying text.

You create the cycle VER10 for the period from 01/01/1997 until 31/05/1997 and from 01/06/1997 until 31/12/1997. The cycle exists in two validity periods.

From 01/01/1997 to 31/05/1997 and

From 01/06/1997 to 31/12/1997

When allocating costs, you can select a given validity period for the cycle. If you select the cycle starting on 01/01/1997, the system selects the first of the two cycles for processing.

This graphic is explained in the accompanying text.

The cycle you select must be valid for the posting period.

For example, you cannot allocate costs in the second half of a fiscal year for a cycle defined exclusively for the first half of the fiscal year. In the example above, this means that for the cycle VER10 of 01.01.1997 you could not allocate costs in period 08.1997.