1. General

Allocations can generally be made in actual figures, in special cases in budget figures or in data tables, and are usually posted in the financial postings. It should be noted at the outset that each allocation is primarily a posting in the Controlling module, i.e. the allocation is generally not posted back to the financial accounting ("Fibu") in Navision, but is only saved in the Controlling tables. This opens up the possibility, among other things, of using other cost types. Furthermore, it is possible to delete postings without affecting the Financial Accounting. However, it is possible to transfer allocations/postings to the Financial Accounting via the menu item "Controlling Module / Tasks / Transfer of Postings to the Financial Accounting".

It is also possible to repost an already posted allocation for a specific period. In this case, the system calculates a difference to the existing posting and then saves it. Alternatively, the old records can be deleted and replaced with new ones.

The order in which allocations are processed in the system is determined in a server batch job. These can be found under "Controlling Module / Setup / Server Batch Jobs." The allocations are usually stored in a separate batch job named "Allocations." The posting keys listed in the rows of this batch job are processed sequentially.

This job must be started manually by the user. To do this, the batch job can be created as a task in a report, which makes the job executable on the web for users authorized to access this report. Alternatively, the user can start the batch job manually from the server batch job list using the "Run" button.

You can check the postings via the menu item "Controlling Module / Views and Analyses / Data Tables" after selecting the relevant data table and clicking the "Postings" button. Alternatively, reports can be configured in the web client that display different views of "pre- and post-allocations."

The setup of each individual allocation or allocation level is done in the menu item “Controlling Module / Setup / Posting Key”.

The meaning of the fields in the booking key is explained in more detail below

2. Posting key in the Controlling module

In the "Controlling Module / Setup / Posting Key" menu item, you can specify what should be debited or debited, how, and where the posting should be made. Posting keys can be assigned to all dimensions.

The following example describes the allocation of costs from general to productive cost centers. Explanations of the relevant fields in the individual tabs are provided below the respective sections.

1. General tab

2.2 Register Discharge

2.3 Register Discharge Dimensions

This tab determines the credit postings. In the example, all postings of the amount type specified in the "Credit" tab that have the specified dimensions (financial accounting account, department, location, etc.) and filters (e.g., account range 4000-8999, unproductive departments 500-700, competency field empty or marked INTERNAL). If no filter is specified (e.g., client and location dimensions), no filtering is performed; that is, all postings are selected.

2.4 Register Charge

The bookings filtered in the “Relief Dimensions” tab, and thus the calculated amount, are to be distributed according to a specific principle.

2.5 Register Charge Dimensions

This register is used to determine which dimension(s) should be debited. In the example, the unproductive departments 500 to 700 (see the "Dimensions Credit" register) are to be allocated to the productive competency areas 100 to 300. Mirroring the "Dimensions Credit" register (and the explanations for the respective fields provided there), this register determines the debit entries.

3. Set up a batch job

To execute the allocations in the correct order, it is necessary to set up a batch job. To do this, the posting keys are specified in the "Lines" tab of the batch job in the order in which they should be processed. In the "Type" column, select either "Posting Key (Single)" or "Posting Key (Multiple)."

The difference between the two is that with “Posting Key (Single)” only a single posting key can be specified in the “Detail Job” column and this will then be executed.

For "Posting Key (Multiple)," either a part of the posting key name is entered with a placeholder or a range, similar to a filter in Navision. The system then automatically determines all possible posting keys during execution and executes them one after the other, sorted alphabetically.

A combination of both variants is possible. However, here is an example of a definition that was constructed with individual posting keys due to the complexity of the requirement. Since the posting keys build on each other and take the values of the previous ones into account for the distribution, the order shown here had to be maintained become:

Such a batch job can then also be defined as a job in a web report and thus executed by the user who has the authorization to open the report.

4. Further possible settings

In addition to simply defining the posting keys, it is also possible to define which values should be allocated at what point in time using a grouping dimension, e.g. on the cost centers.

The respective posting key is then filtered on the grouping dimension and the values are thus restricted.

The allocation key according to which the values are to be allocated can either be determined dynamically for execution based on distribution curves using actual data, or it can be entered manually by the user as percentages for individual allocation keys via a web report. However, it should be noted that the total for each allocation key must then always be 100.

Manual entry has both advantages and disadvantages: the advantage is that the allocation will distribute the values the same way at a later date, since the distribution key hasn't changed. The disadvantage, however, is that the distribution key only changes when the user enters new values for the distribution curve.