Skip to main content
insightsoftware Documentation insightsoftware Documentation
{%article.title%}
Published:
Was this article helpful?
0 out of 0 found this helpful

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 document number (selection in CNSVCH and CNSPST), which can be used to identify from which consolidation the voucher originates.

These parameters are defined in the CNSPAR application. However, in order for individual consolidation functions to be defined by parameters, these consolidation parameters must first be defined. The application "CNSFNC" (consolidation function) 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 2 groups of individual KVAs:

- Individual KVAs for manual vouchers (JMxx)

- Individual KVAs for IE and CD consolidation (IExx, CDxx)

2 Renewal of the CNSFNC Key in Release 2020

2.1 Objective

For the 2020 releases, an extension of the CNSFNC key (CNSFNC = consolidation function) 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 CNSFNC Key Nomenclature

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

  • digits 1 to 2: Speaking CNSFNC 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; CNSFNC keys 'Xx' are omitted for this.
  • Item 6: 'F' for carries forward or blank; the CNSFNC keys 'Fx' and 'CF' are omitted for this, 'X' and 'F' in combination replace the previous CNSFNC 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 CNSFNC 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 CNSFNC 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 (example 'CD'):
  • '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 document 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 CNSFNC key, therefore divided into its four parts like the CNSFNC 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 CNSFNC keys in the case of 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 CNSFNC key, but only occur in the document number, these data records previously defined with the same attributes are no longer required in the CNSFNC table.

It should be noted here that the affected KVAs ('KK', 'FK', 'EK', 'FMTR', 'PP', 'PA' and 'PT') in the document 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 document 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 CNSFNC keys and document 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 CNSFNC 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 CNSFNC key (digits 13 to 14 of the document number) is recorded in a new column (visible only as an internal information column), so that the old document 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 CNSFNC 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

CNSFNC codes or document 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 documents and transactions, new longer and subdivided fields had to be created for the document 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:

  1. there is no length restriction; and
  2. there is no explicit selection of specific CNSFNC or document 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]: Entry of consolidation function and subgroup 01 to 99 (Ex: 'IE' for IE consolidation and '01' for e.g. interest expense and income).

[Description] : Customized description.

[Short text]: Customized short word .

Page 2: Uses

This page shows where the abbreviations are used. No changes are possible here.

NOTE on the 'Use in' fields

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

  • Account: This CNSFNC can be deposited directly in the account master.
  • Consolidation parameters: A consolidation parameter can be created for this CNSFNC.
  • IC-Clearing:
  • Voucher number: CNSFNC is displayed in a document number.
  • CARRY FORWARD:

Page 3: Options

[Consolidation function Reference]: 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 CNSFNC for the carry forward determines in which voucher the carried forward consolidation postings of a voucher with the current CNSFNC in the document number are written. This reference CNSFNC thus serves as proof of how the presentation is formed. The reference CNSFNC is fixed in almost all cases. (Exception: for deferred taxes (Lx), it can be selected whether the carry forward of the original document (Vx) 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 CNSFNC in the document 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 CNSFNC in a column that is already in use, this field will be left blank and the respective CNSFNC will be entered in the field "REF-CNSFNC", the result of which will already flow into the selected column.

[IC-Clearing 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.
  • TW not allowed (-): Specify that no transaction currency is used. The disclosure of transaction currency values is therefore prohibited.
  • TW indication is mandatory (X): Specify that transaction currency is always used. The disclosure of transaction currency values is therefore mandatory.
  • TW specification is mandatory, LW specification at LW=KW (L): Specify like 'X' that transaction currency is always used. Without input, however, it is automatically assigned the values of the local currency, provided that the local currency is equal to the group currency. 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 (CNSFNC) 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 (CNSFNC) 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 import consolidation functions into the database using the import application.

Published:

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 document number (selection in CNSVCH and CNSPST), which can be used to identify from which consolidation the voucher originates.

These parameters are defined in the CNSPAR application. However, in order for individual consolidation functions to be defined by parameters, these consolidation parameters must first be defined. The application "CNSFNC" (consolidation function) 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 2 groups of individual KVAs:

- Individual KVAs for manual vouchers (JMxx)

- Individual KVAs for IE and CD consolidation (IExx, CDxx)

2 Renewal of the CNSFNC Key in Release 2020

2.1 Objective

For the 2020 releases, an extension of the CNSFNC key (CNSFNC = consolidation function) 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 CNSFNC Key Nomenclature

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

  • digits 1 to 2: Speaking CNSFNC 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; CNSFNC keys 'Xx' are omitted for this.
  • Item 6: 'F' for carries forward or blank; the CNSFNC keys 'Fx' and 'CF' are omitted for this, 'X' and 'F' in combination replace the previous CNSFNC 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 CNSFNC 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 CNSFNC 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 (example 'CD'):
  • '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 document 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 CNSFNC key, therefore divided into its four parts like the CNSFNC 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 CNSFNC keys in the case of 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 CNSFNC key, but only occur in the document number, these data records previously defined with the same attributes are no longer required in the CNSFNC table.

It should be noted here that the affected KVAs ('KK', 'FK', 'EK', 'FMTR', 'PP', 'PA' and 'PT') in the document 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 document 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 CNSFNC keys and document 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 CNSFNC 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 CNSFNC key (digits 13 to 14 of the document number) is recorded in a new column (visible only as an internal information column), so that the old document 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 CNSFNC 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

CNSFNC codes or document 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 documents and transactions, new longer and subdivided fields had to be created for the document 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:

  1. there is no length restriction; and
  2. there is no explicit selection of specific CNSFNC or document 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]: Entry of consolidation function and subgroup 01 to 99 (Ex: 'IE' for IE consolidation and '01' for e.g. interest expense and income).

[Description] : Customized description.

[Short text]: Customized short word .

Page 2: Uses

This page shows where the abbreviations are used. No changes are possible here.

NOTE on the 'Use in' fields

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

  • Account: This CNSFNC can be deposited directly in the account master.
  • Consolidation parameters: A consolidation parameter can be created for this CNSFNC.
  • IC-Clearing:
  • Voucher number: CNSFNC is displayed in a document number.
  • CARRY FORWARD:

Page 3: Options

[Consolidation function Reference]: 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 CNSFNC for the carry forward determines in which voucher the carried forward consolidation postings of a voucher with the current CNSFNC in the document number are written. This reference CNSFNC thus serves as proof of how the presentation is formed. The reference CNSFNC is fixed in almost all cases. (Exception: for deferred taxes (Lx), it can be selected whether the carry forward of the original document (Vx) 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 CNSFNC in the document 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 CNSFNC in a column that is already in use, this field will be left blank and the respective CNSFNC will be entered in the field "REF-CNSFNC", the result of which will already flow into the selected column.

[IC-Clearing 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.
  • TW not allowed (-): Specify that no transaction currency is used. The disclosure of transaction currency values is therefore prohibited.
  • TW indication is mandatory (X): Specify that transaction currency is always used. The disclosure of transaction currency values is therefore mandatory.
  • TW specification is mandatory, LW specification at LW=KW (L): Specify like 'X' that transaction currency is always used. Without input, however, it is automatically assigned the values of the local currency, provided that the local currency is equal to the group currency. 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 (CNSFNC) 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 (CNSFNC) 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 import consolidation functions into the database using the import application.

For an optimal Community experience, Please view on Desktop
Powered by Zendesk