Individual development definitions in IDL Konsis have to be maintained user specifically and by the user himself. The same applies for those case, in which IDL Konsis provides certain posting key sets as a sample for different purposes. For the IDL Konsis user programs this means that you must not explicitly assign posting keys anymore. In fact postings keys in automatically created transactions and postings have to be determined unequivocally by other means. Normally this happens by allocating usage tags for certain posting keys, which therefore have to be allocated thoroughly even at individually maintaining the posting keys.
Further automatically applied postings keys are determined by other attributes of the individual development definitions, such as the usage tag of the transaction development columns (SSP) or the depreciation flag of the transaction development area (SBE).
If you cannot determine a specific posting key for a certain purpose, you use a posting key for actual changes. For automatic transaction developments this is the postings key with the usage tag 'L', for others it is used a posting key with the usage tag 'N'. If there cannot be found any posting key this way, it remains empty and has to be filled in manually.
The postings keys with usage tags are usually reserved for automatic functions. That's why they must not be specified in manually entered transactions and postings. An exception form the posting keys with the usage tag 'AHK', 'Bnn', 'KM' and 'N'.
In the future the system generally supports the differentiation of the allocated posting keys depending on the direction (debit/credit) of the change, which leads e.g. to a different allocation of result and posting key in the capital development list in the case of profit than in the case of loss. Requirement for that are two posting keys with the same usage tag but different credit/debit codes. This differentiation becomes particularly necessary, if both posting keys are allocated to different transaction development columns.
The following posting key usage tags are defined and can or have to be allocated in the posting key master data in order to achieve certain functionalities:
Afa : refers to the posting key used for the posting of automatic depreciations, provided that they are not meant to be posted with a disposing effect on the depreciation. 'Afa' must only be allocated for development fixed assets (development transaction flag = 'A').
AHK : refers to the posting key used for the posting of automatic depreciations, which are meant to be posted with a disposing effect on the production costs. 'AHK' must only be allocated for development fixed assets (development transaction flag = 'A').
B02 : refers to a participation posting key for an addition of participation, which is processed accordingly in the capital consolidation. 'B02' must only be assigned to participation posting keys (development transaction flag = 'B').
B03 : refers to a participation posting key for a disposal of participation processed accordingly in the capital consolidation or deconsolidation. It depends on whether it is a disposal of participation or the company leaves the group companies. 'B03' must only be assigned to participation posting keys (development transaction flag = 'B').
B04 : refers to a participation posting key for the manual setting for begin of period at the first consolidation of a participation with IDL Konsis.The allocated transactions are processed accordingly in the capital consolidation. 'B04' must only be assigned to participation posting keys (transaction development flag = 'B').
B05 : refers to a participation posting key for an actual depreciation (adjustment), which is processed accordingly in the capital consolidation. 'B05' must only be assigned to participation posting keys (transaction development flag = 'B').
B06 : refers to a participation posting key for an appreciation (adjustment), which has not yet been processed in the capital consolidation, but it is already scheduled to realize a corresponding extension. 'B06' must only be assigned to participation posting keys (development transaction flag = 'B').
B07 : refers to a participation posting key for allowances accum., which is processed accordingly in the capital consolidation. 'B07' must only be assigned to participation posting keys (development transaction flag = 'B').
B08 : refers to a participation posting key for an addition of capital, which is processed accordingly in the capital consolidation. The corresponding posting keys of the capital development list also contain this usage tag. 'B08' must only be assigned to participation posting keys (development transaction flag = 'B') and capital posting keys (development transaction type = 'K').
B09 : refers to a participation posting key for a simultaneous increase of participation and capital, which is processed accordingly in the capital consolidation. 'B09' must only be assigned to participation posting keys (development transaction flag = 'B').
B10 : refers to a participation posting key for a disposal of capital, which is processed accordingly in the capital consolidation. The corresponding posting keys of the capital development list also contain this usage tag. 'B10' must only be assigned to participation posting keys (development transaction flag = 'B') and capital posting keys (development transaction flag = 'K').
B13 : refers to a participation posting key for a manual setting of currency conversion differences, which is processed accordingly in the capital consolidation. 'B13' must only be assigned to participation posting keys (development transaction flag = 'B').
B16 : The posting key usage tag 'B16' was invented for representation of mergers in the shareholding transactions. A shareholding transaction with a posting key with this usage tag describes the principle merging process between shareholding and merged company as a disposal of participations.
B17 : The posting key usage tag was invented for the function ‚Intercompany sale of shareholdings disposal’ (IK). A shareholding transaction with a posting key with this usage tag (in combination with a posting key with usage tag B18) provides the required result, that nothing changed from the the group point of view. Posting keys with these usage tags were supplemented in the "LieferBatch" files. On demand posting keys with these usage tags have to be manually defined if the "LieferBatch" standard is not used.
B18 : The posting key usage tag was invented for the function ‚Intercompany sale of shareholdings addition’ (IK). A shareholding transaction with a posting key with this usage tag (in combination with a posting key with usage tag B17) provides the required result, that nothing changed from the the group point of view. Posting keys with these usage tags were supplemented in the "LieferBatch" files. On demand posting keys with these usage tags have to be manually defined if the "LieferBatch" standard is not used.
D : refers to the posting key for currency conversion differences in the sample accounting for a development transaction with sample accounting (control of development carry forward = 'S'), because the usage tag 'U' (see below) is already used for the currency conversion differences of the actual transaction development thus automatically being used in this function by the currency conversion. 'D' must not be assigned to development transactions with control of development carry forward = 'X' or '-'.
DIV : refers to a special posting key for dividends. This tag is evaluated at carry forward of company statements and at difference amount subsequent consolidation.
E : refers to posting keys for addition to group companies and is automatically used in this function at the repostings after change of the company group ('KU' voucher). For a transaction development with carry-forward you have to determine one posting key for each transaction development area with this usage tag.
F : refers to posting keys for disposal of group companies and is automatically used in this function at the Processing tag Deconsolidation KS ('KS' voucher). For a transaction development with carry-forward you have to determine one posting key for each transaction development area are with this usage tag.
FF : If indirect minority interests for changes in equity should be calculated and posted, all relevant capital transactions must have a posting key with the usage tag ‘FF’.
JU : refers to the posting keys for the setting of result used for the automatic calculation of the result on the account with the account flag 'E' for the detail as capital development list. 'JU' must only be assigned to capital posting keys (development transaction flag = 'K').
K : refers to the posting keys for exchange rate effects on carry-forward transactions and is automatically used in this function by the currency conversion. 'K' has to be assigned to transaction developments with control of development carry forward ='X' or 'S' to avoid an error in the currency conversion. In a development transaction with sample accounting (control of development carry-forward ='S') this posting key is allocated to the sample accounting.
KM : refers to posting keys for those consolidation measures used in the functions update equity (EF for the postings of additions and disposals at cost on the account "investment associated company"), minority interests (FF) and difference amount from subsequent consolidation (KB, there for postings on capital accounts) as well as deferred taxes (LT, for postings on the account deferred taxes profit+loss, if there are no posting keys used for it in the consolidation parameter LT). Generally these posting keys are allocated to a transaction development column "consolidation measures".
L : refers to the posting key for continued changes in an automatically created transaction development (transaction development automatic calculation ='X'). The transactions with this posting key are automatically generated from the difference between account balance and automatic carry-forward (usage tag ='V'). Usually postings and consolidation postings are also allocated to this posting key, except in the case of a transaction development with sample accounting and no other default posting key. In a transaction development with sample accounting (control of development carry-forward ='S') this posting key is allocated to the sample accounting.
M : refers to the posting key for carry-forward during the period the way it is needed for the conversion of account balances for the monthly assessed average exchange rate (posting key currency conversion direction 'MDK'). 'M' must only be allocated for development transactions with MDK flag = 'X'. In a development transaction with a sample accounting (control of development carry-forward ='S') this posting key is allocated to the sample accounting.
ME/MF : The posting key usage tags 'ME' and 'MF' serve for the specification of posting keys for additions or disposals by merger, respectively. They are automatically determined by the functions for mergers and applied to the generated consolidation postings. In addition, you can define manual posting keys for merger and allocate them to the transaction development column with usage tag 'MER', since the posting keys with usage tag 'ME' and 'MF' are not admitted for manual usage.
N : refers to the posting key for continued changes in non automatic transaction developments (transaction development automatic calculation ? 'X'). It is assigned by different applications, if postings with "changes in current period" are created and no other posting key has been determined as a default. For a development transaction with carry-forward parts you have to determine one posting key for each development transaction area are with this usage tag.
NE : Additions without effect on liquidity are differentiated at first consolidation repostings. Usually the reposting is performed with a posting key with usage tag 'E' (addition to group companies), while transactions for additions without effect on liquidity are reposted on a posting key with usage tag 'NE' (additions without effect on liquidity), if it is defined.
NF : The deconsolidation acts correspondingly (posting key usage tags 'F' or 'NF', respectively) to the additions without effect on liquidity.
P : Consolidation postings on the minority interest account are provided with a posting key with the usage tag 'P' (percental changes of shareholdings) at first consolidation of participation changes. A posting key with the usage tag 'N' (other current change) is used like before if no posting key with usage tag 'P' is defined.
Q : refers to posting keys for the repostings of rate changes and they are used in the function "Quotal clearing" for the reposting of rate changes. That's why its character is similar to the one of the postings keys with the usage tag 'E' and 'F'. For a development transaction with carry-forward parts you have to determine one posting key for each development transaction area are with this usage tag. In a development transaction with a sample accounting (control of development carry-forward ='S') this posting key is allocated to the sample accounting.
SD : refers to posting keys for the cancelation of currency conversion differences, which have been posted in a transaction development with a sample accounting (control of development carry-forward = 'S') to a posting key with the usage tag 'D'. A 'D' posting key always requires the definition of a 'SD' posting key. 'SD' must not be used for developments transaction without sample accounting (control of development carry-forward = 'X' or '-').
SE : refers to posting keys for the cancelation of addition to group companies, which have been posted in a transaction development with sample accounting (control of development carry-forward = 'S') to a posting key with the usage tag 'E'. 'SE' must not be used for transaction developments without sample accounting (control of development carry-forward = 'X' or '-').
SF : refers to posting keys for the cancelation of displosal of group companies, which have been posted in a transaction development with sample accounting (control of development carry-forward = 'S') to a posting key with the usage tag 'F'. 'SF' must not be used for transaction developments without sample accounting (control of development carry-forward = 'X' or '-').
SK : refers to posting keys for the cancelation of currency conversion differences, which have been posted in a transaction development with a sample accounting (control of development carry-forward = 'S') to a posting key with the usage tag 'K'. 'SK' must not be used for transaction developments without sample accounting (control of development carry-forward = 'X' or '-').
SL : refers to posting keys for the cancelation of continued changes, which have been posted in a transaction development with sample accounting (control of development carry-forward = 'S') to a posting key with the usage tag 'L'. 'SL' must not be used for transaction developments without sample accounting (control of development carry-forward = 'X' or '-').
SM : refers to posting keys for the cancelation of carry-forwards during the period, which have been posted in a transaction development for the calculation of monthly assessed average rates (transaction development MDK-flag = 'X') with sample accounting (control of development carry-forward ='S') on the posting key with usage tag 'M'. 'SM' must not be used for transaction developments without sample accounting (control of development carry-forward = 'X' or '-').
SME/SMF : If you define posting keys with usage tag 'ME' and 'MF' for a transaction development with sample accounting, then you have to define posting keys with usage tags 'SME' and 'SMF' (for automatic elimination of the sample accounting), too.
SNE/SNF : If you define postings keys with usage tag 'NE' and 'NF' (additions/disposals without effect on liquidity) for a transaction development with sample accounting, then you have to define posting keys with usage tags ‘SNE’ and ‘SNF’(for automatic elimination of the sample accounting), too.
SQ : refers to posting keys for the cancelation of clearing of rounding differences from the quotal currency conversion, which have been posted in a transaction development with sample accounting (control of development carry-forward = 'S') to a posting key with the usage tag 'Q'. 'SQ' must not be used for transaction developments without sample accounting (control of development carry-forward = 'X' or '-').
SV : refers to posting keys for the cancelation of automatic carry-forwards, which have been posted in a transaction development with sample accounting (control of development carry-forward = 'S') to a posting key with the usage tag 'V'. 'SV' must not be used for transaction developments without sample accounting (control of development carry-forward = 'X' or '-').
U : refers to a posting key for conversion differences for consolidation postings on transaction development accounts converted deviant from the account currency conversion rule (e.g. current depreciations with conversion rule 'PDK' on a fixed asset account with conversion rule 'SK'). Exchange rate effects already posted for this posting are considered.
V : refers to posting keys for the automatic carry-forward of postings and transactions in transaction developments with carry-forward (control of development carry-forward ='X' or 'S'). For a development transaction with carry-forward you have to determine one posting key for each transaction development area with this usage tag.
X : refers to posting keys for other automatic usage flags. This usage tag is not applied in the IDL Konsis-applications. It may, however, be assigned by the user for posting keys, which are, e.g., allocated to a consolidation parameter, in order to exclude a manual data entry with this posting key.
XEW : refers to the posting key, which is entered during the carry-forward of postings affecting net income to the next fact for the herefrom generated change of result, to provide its entry into the same carry-forward account during the period carry-forward. 'XEW' must only be allocated for capital posting keys (development transaction flag = 'K').
XJU : refers to the posting keys used in the period carry-forward for the reposting of the annual result or postings affecting net income to the carry-forward account. 'XJU' must only be assigned to capital posting keys (development transaction flag = 'K').
XKS: The reclassification of the retained earnings to the result from deconsolidation is performed in two steps. In the first step the amount from the account for retained earnings (account flag 'C') is reposted to the general account for retained earnings (account flag 'X'). In a second step the retained earnings are eliminated on the deconsolidation result account. The posting key with the usage tag 'XKS' (reposting deconsolidation) is used for repostings from the special to the general account for retained earnings.
XZA : if you use the flag position ‘Z’ (Posting for additional company) in KTKPAR_ZA, the posting keys for the reposting have to be designated with the usage tag 'XZA'. The posting key of the posting remains empty if no such posting key is defined and has to be supplemented manually.
Transactions without carry-forward (control of development carry-forward = '-') almost exclusively consist of posting keys without usage tags. The only exception is a posting key with the usage tag 'U' required for the posting of rounding differences from the currency conversion. For further automatic postings it is recommendable to define a posting key with the usage tag 'N'.
Transaction developments like the development fixed assets, the capital development list or the provision development list present simple transaction developments with carry-forward (control of development carry-forward = 'X'). Usually here are required the following posting keys with usage tags:
If the transaction development is subdivided into transaction development areas (such as development fixed assets with areas for costs and depreciation) you have to create posting keys with these usage tags for each transaction development area.
The posting keys with the usage tags 'Bnn' ('nn' = '02', '03',...) are required for the transaction development 'B' (shareholding/participations) for being able to carry out the allocated functions of the capital consolidation. In case you do not want to carry out a capital consolidation for adjustments, you must not assign the usage tags 'B05' and 'B07' and in later releases 'B06'.You may add any number of posting keys without usage tags.
An automatic transaction development is a transaction development with carry-forward, which requires the posting keys with the usage tags of a simple transaction development with carry-forward. In addition it requires a posting key with the usage tag 'L', which virtually represents a summing-up of all posting keys without usage tags. Since IDL Konsis creates the development transaction for this transaction development completely automatically, you must not create any posting keys without usage tag.
The IDL Konsis release-CD contains a sample for an automatic transaction development ("S9") in the list SupplyBatch.
You need a transaction development with sample accounting, if a transaction development without carry-forward is to be extended by information about carry-forwards and continued changes, such as for the purposes of the capital flow calculation. Such a transaction development consists of three parts:
In order to achieve a correct presentation in the report, the posting keys of these three parts have to be allocated to separate transaction development columns.
In the narrow sense transaction developments for the conversion with monthly assessed average rates (in the following called MDK transaction developments) are technically no transaction developments, particularly since they are only applied in the P+L. Thus they neither contain an automatic carry-forward of an annual financial statement (posting key with the usage tag 'V').
MDK transaction developments are automatic transaction developments therefore requiring a posting key with the usage tag 'L' for the automatic posting of the continued changes. In an MDK transaction development, however, they only present the changes compared to the previous month. The carry-forward of the previous month is posted by the carry-forward during the period to the posting key with the usage tag 'M'.
Normally you do not need any further posting keys with other usage tags, because on the one hand there is no need to repost carry-forwards for changes in the group companies, on the other hand there do not arise any currency conversion differences, because the accounts are assessed with the updated average rate (currency conversion direction 'FDK').
Just like normal automatic transaction developments MDK transaction developments can be added as sample accounting to a transaction development without carry-forward. Just as described in chapter 3.4 the transaction development consists of three parts: