Consolidation Functions

1 Consolidation Functions (CNSFNC)

IDL Konsis requires control parameters to set the framework for each consolidation step to ensure the consolidation functions run properly. They are thus also a component of the voucher number (selection in CNSVCH and CNSPST), which can be used to identify from which consolidation the voucher originates.

These parameters are defined in the Consolidation parameters application (CNSPAR). However, in order for individual consolidation functions to be defined by parameters, these consolidation parameters must first be defined. The Consolidation functions application (CNSFNC) is used for this purpose.

Certain KVAs are delivered IDL-side and cannot be changed (except for the field contents 'CNSFNC' report). The KVAs shipped from IDL-side can be recognized by the fact that they consist only of two letters followed by "00" or two spaces and the identifier L or D respectively. V exist, while customer-specific KVAs have a digit in the third and fourth position.

It is therefore possible to define individual, subject-related voting circles/groups in order to create smaller viewing units and greater transparency in the consolidation process (see the following chapters)

There are two groups of individual KVAs:

• Individual KVAs for manual vouchers (JMxx)
• Individual KVAs for IE and CD consolidation (IExx, CDxx)

2 Renewal of the Consolidation Function Key in Release 2020

2.1 Objective

For the 2020 releases, an extension of the consolidation function key was carried out, along with the conversion of consolidation voucher numbers. The main arguments for this project were

• Unification of the historical CNSFNC nomenclature
• Limit of 11 sets of documents (reconciliation groups) for debt and expense/income consolidation and manual vouchers
• Lifting of the limit of maximum 11 equity acquisitions (batches) within a financial year for an equity relationship
• Margin for future differentiations (e.g. separate carry forward of Sn vouchers instead of a VS voucher)
• Margin for future enlargements (recently letters for new issues were already scarce, talking abbreviations were no longer available)

2.2 New Consolidation Function Key Nomenclature

Part 1 of the conversion is the extension of the actual consolidation function key from two to six digits in the future. These six digits shall be allocated as follows:

• Digits 1 to 2: Speaking consolidation function key / basic CNSFNC, generally as before (e.g. 'IE', 'CD', 'CC', 'JM'), but without 'F' or 'W' for carries forward and without 'X' for deferred tax in first place and without digits in second place.
• Digits 3 and 4: Numerical from '00' to '99'; only for the base KVAs 'CD', 'IE', and 'JM', but there mandatory —> This increases the number of possible document sequences per processing function (tuning groups) from currently 11 to 100.
• Item 5: 'X' for deferred tax or empty; consolidation function keys 'Xx' are omitted for this.
• Item 6: 'F' for carries forward or blank; the consolidation function keys 'Fx' and 'CF' are omitted for this, 'X' and 'F' in combination replace the previous consolidation function keys 'Wx'.

The basic CNSFNC at the first two points maintains the familiar nomenclature in large parts. The two-digit number for individually definable tuning groups significantly increases their possible number. The deferred tax and deferred carry forward codes in the consolidation function key make it easier to select consolidation postings for a basic CNSFNC, including its deferred tax and/or carry forward.

The following special features must be taken into account:

• 'CD', 'IE', and 'JM' no longer exist as consolidation function keys, but only in connection with the number of a voting group. This also applies to the consolidation parameters (K046) and the CNSFNC in the account master (K010), which now have four digits. In order to obtain the usual numbers to a large extent, the following conversion is carried out here (take CD for an example):
• 'S1' --> 'CD01'
• 'S2' --> 'CD02' etc., aber
• 'CD' --> 'CD00' (available for all users)
• 'S0' --> 'CD10' (otherwise there would be duplicates)

• The previous CNSFNC 'ZA' (elimination of … results in fixed assets) did not have a "separate letter", since 'Z' had already been received by 'ZU' (e.g. Role 'PZ', 'XZ'), but used an 'X' (e.g. 'PX', 'XX'), although 'X' at the first position is the identifier of the deconsolidation. To avoid this confusion, 'ZA' has been renamed 'TA' and 'T' for subsequent Roles (e.g. 'PT', 'XT') instead of 'X'.

• CNSFNC keys that have not been used recently (e.g. 'AO', 'EM', 'KS'), have not been converted yet, but (also in the CNSFNC table) have still been continued, only their reuse has been prevented. These keys are now permanently deleted and will be replaced with the corresponding current keys if necessary.

2.3 New Nomenclature of Voucher Numbers

Part 2 of the conversion is the extension of the consolidation voucher numbers from the previous 14 digits to 20 digits. In future, the voucher number will consist of seven parts:

• Positions 1 to 6: first company (as before)
• Company digits 7 to 12: second place (as before)
• Digits 13 to 18: new six-digit consolidation function key, therefore divided into its four parts like the consolidation function key.
• Digits 19 to 20: New two-digit sequential number (only for certain base KVAs)

The sequence number in the last two digits is used in those cases where IDL had previously provided the corresponding consolidation function keys in the cases via the metadata. This concerns

• 'Kn', 'Fn', and 'En': Batches at Capital consolidation
• 'Pn', 'On', 'Rn', and 'Tn': Upstream mergers to the same receiving company

Since these sequence numbers are no longer contained in the consolidation function key, but only occur in the voucher number, these data records previously defined with the same attributes are no longer required in the CNSFNC table.

The affected KVAs ('KK', 'FK', 'EK', 'FMTR', 'PP', 'PA', and 'PT') in the voucher numbers are always provided with a number. This means that, for example, the first voucher for the Capital consolidation is given 'KK...00' in the voucher number from position 13. The conversion here maintains the original order:

• 'KK' --> 'KK....00'
• 'K0' --> 'KK....01'
• 'K1' --> 'KK....02' etc. (Dots here represent the number of spaces)

This now sorts the vouchers in the correct chronological order (always alphabetically, i.e. 'K0' to 'K9' before 'KK').

2.4 Conversion

In the context of the release installation, almost all existing consolidation function keys and voucher numbers are converted to the new nomenclature by SQL scripts, since an implementation by the conversion program would have meant unreasonable runtimes. SQL conversion also takes some time and can take up to one hour depending on the size of the database.

The consolidation function key is implemented in the following tables:

• K047 (CNSFNC): key, reference CNSFNC for carry forward, reference CNSFNC for reports
• K010 (COADFN): CNSFNC of IC accounts
• K012 (ACCGRP): CNSFNC of IC accounts
• K050 (CNSLST): CNSFNC in Key
• K046 (CNSPAR): CNSFNC in Key

The consolidation voucher number is implemented in the following tables:

• K048 (CNSVCH): key
• K049 (CNSPST): key

In addition, in table K048, the previous consolidation function key (digits 13 to 14 of the voucher number) is recorded in a new column (visible only as an internal information column), so that the old voucher number can always be reconstructed for the purpose of revision.

In the next, a new selection object KV1 was introduced, which is used in all places where not the six-digit consolidation function key, but only the two-digit base CNSFNC is needed. This is used in the following tables:

• K047 (CNSFNC): Reference CNSFNC (internal info column)
• K019 (GRPCNT): Key (also for status display in GRPMNR)
• K027 (REPLNDFN): Capital flow reports restricted by CNSFNC

Consolidation function keys or voucher numbers are not converted in the following tables:

• K210, K227 (ACCLOG, REPZEILOG): The minutes shall also include the amendment made at that time.
• K038, K039, K042, K045 (ICACBAL, xxxBEW, SHRPAR): The entries of the consolidation vouchers in which the respective CFSMNR data has been processed or eliminated may have to be determined using the recorded previous CNSFNC of the voucher (see above).
• K076 (REPERG): CNSFNC keys only appear in cash flow reports with restrictions according to CNSFNC. The only effect is that the description to the CNSFNC is no longer displayed.

2.5 Interfaces

The affected interfaces for import to Konsis have been extended as necessary.

• For consolidation vouchers and transactions, new longer and subdivided fields had to be created for the voucher number to be used.
• The account (TXTKTO) and Account Group (TXTKTOGRP) import applications have been designed to convert old two-digit keys in the old field to the new keys in the same way as the release conversion.

Reading data from the KONSIS DB should continue to function as before, provided that:

• There is no length restriction.
• There is no explicit selection of specific CNSFNC or voucher number keys.

Otherwise, the requests must be adapted individually.

3 CNSFNC Wizard

The process of capturing and modifying a consolidation function involves the use of a four-page wizard:

Page 1: Description

Consolidation function: Select a consolidation function from IE, JM, and CD.

Reconciliation group: Type in a subgroup 01 to 99.

Deferred taxes: Select this option for deferred taxes.

Carry-forward: Select this option for carry forward.

Description: Customized description.

Short text: Customized short word.

Page 2: Uses

This page shows where the consolidation function is used. No changes are possible here.

NOTE on the "Used in" fields

These fields are filled on the system side and are only used to visualize in which applications the respective consolidation function can be used or in which applications the respective consolidation function can be selected. If a check mark is set, this means for

• Account: This consolidation function can be deposited directly in the account master.
• Consolidation parameters: A consolidation parameter can be created for this consolidation function.
• Voucher number: This consolidation function is displayed in a voucher number.
• IC-Clearing: This consolidation function can be used in IC clearing.
• Carry forward: This consolidation function can be used in carry forward.

Page 3: Options

[State of consolidation]: The auto entry in this field links to the IDL predefined consolidation function. As a result, all tuning groups (n0-n9) you defined are triggered simultaneously with the respective consolidation function (via the GRPMNR). Conversely, it is basically not possible to run a consolidation function separately for a specific voting group as a whole, such as only for "S1". However, individual vouchers can be initiated separately in the IC Clearing (CNSLST) overview.

[Consolidation function Carry forward]: The reference consolidation function for the carry forward determines in which voucher the carried forward consolidation postings of a voucher with the current consolidation function in the voucher number are written. This reference consolidation function thus serves as proof of how the presentation is formed. The reference consolidation function is fixed in almost all cases.

Exception: For deferred taxes (Xx), it can be selected whether the carry forward of the original voucher (Fx) should be combined or whether there is a voucher for the deferred tax carry forward (Wx).

[Consolidation function Report]: Specify in which column of the consolidation report (RepType=V) values from the vouchers (with this consolidation function in the voucher number) should be written into the report result. Column numbers 05 to 50 are allowed, because the report result consists of a maximum of 50 value columns and the first four columns are occupied by the total values of balances and postings. Each column number can only be assigned once. If you want to display the result of a consolidation function in a column that is already in use, this field will be left blank and the respective consolidation function will be entered in the field "REF-CNSFNC", the result of which will already flow into the selected column.

[With transaction currency]: For the consolidation functions concerning IC-Clearing (consolidation of debts with 'CD', 'DP', 'S0', 'S1', ... 'S9' and income/expense consolidation with 'IE', 'A0', 'A1', ... 'A9') allows you to control the extent to which the transaction currency values are mandatory for the intercompany balances of the accounts associated with these transactions. The following input options are available:

• 'Empty': Nothing changes without specifying this attribute. You can specify transaction currency values.
• transaction currency not allowed (-): Specify that no transaction currency is used. The disclosure of transaction currency values is therefore prohibited.
• transaction currency is required (X): Specify that transaction currency is always used. The disclosure of transaction currency values is therefore mandatory.
• transaction currency is required, local currency transferred otherwise (L): Specify like 'X' that transaction currency is always used. Without input, however, it is automatically assigned the values of the local value, provided that the local value is equal to the group value. This control can be carried out in a differentiated manner according to tuning groups of IC accounts by the indication in the CNSFNC master. Setting this switch (to 'X' or 'L') is also recommended for splitting a transaction currency difference into a material and a currency difference (see below).

4 Individual KVAs for Manual Vouchers (JM), Their Carry Forward and Deferred Taxes

In order to allow postings with different carry-forward rules (booking type), customer-specific consolidation functions can be set up for manual situations ('JM01', 'JM02', ..., 'JM99'). In order that in the carry forward these postings are not combined into a voucher with CNSFNC 'JM00 V', so that the original differentiation is lost, corresponding individual KVAs 'JM01 V', 'JM02 V', ... 'JM99 V' for the carry forward of customer-specific JM-KVAs generated automatically at the time of creation. In addition, next custom KVAs 'JM01L', 'JM02L', ... 'JM99L' used for deferred tax posting on postings for individual JM KVAs.

These postings are used for deferred tax purposes (e.g. 'JM01L') with the new manual postings (e.g. 'JM01') to a presentation document (e.g. 'JM01 V'). However, it is also possible to use a separate document type (e.g. JM01LV) for the deferred tax carry forward and to allocate the deferred tax capital as carry forward capital gains tax.

Up to 99 sub-groups are available for the individual voting groups for manual vouchers, which are not overwritten by new release levels:

• JM01, JM02, JM03, ... until JM99

5 Individual KVAs Consolidation of Income and Expenses (IE) and Consolidation of Debts (CD)

Often there is a desire to define different voting groups in the IE/CD area, e.g. for interest income and expenses or an additional subdivision of other income and expenses. Here, too, differentiation is achieved by applying subgroups. The carry forward CNSFNC is always fixed for these subgroups and refers to the respective reference CNSFNC, so for 'IExx' the automatic carry forward CNSFNC is 'IE00 V' and for 'CDxx' the automatic carry forward CNSFNC is 'CD00 V'.

For the individual voting groups, up to 99 subgroups are available for IE and CD vouchers, which are not overwritten by new release versions:

• IE01, IE02, IE03, ... until IE99
• CD01, CD02, CD03, ... until CD99

6 Note on the Consolidation Report

Creating a consolidation report (presentation of the contributions of the various consolidation functions in separate columns) requires an assignment of the consolidation functions to the columns. In order to give you the highest possible design possibilities, the assignment is made more flexible as described above. However, this means that all new users have to perform this assignment completely manually themselves. To avoid this, a default column option for the consolidation report is provided in a ShipBatch file in the "Column Options_Consolidation report" release. You can import consolidation functions into the database using the import application.