This documentation and the corresponding menu branch in IDL Konsis describe some central master data which have to be defined for each installation. These are
The country-codes are allocated enterprise-wide and are part of the group of the so called 'enterprise-wide data' which are selected and transferred in the case of the KONSIS-to KONSIS data interchange (KONDAT) with that.
Each company in IDL Konsis has to be assigned to a country. For this purpose you have to define country codes before you are able to define companies.
IDL recommends using the country ISO-Codes as keys as they are known by country:
Example:
A sample list is delivered with each release in the directory "Lieferbatch/WKZ-LKZ_ISO-Codes". Alternatively the encoding with car-identification codes or enterprise individual conventions are possible.
The application "Country codes" (LKZ) displays a table with all defined countries after invocation. New entries as well as modifications are performed using a wizard consisting of two pages.
Page 1: Descriptions
The country code has a maximum length of three-digit alphanumeric. Additional to the max. 35-digit description the 'valid from' period has to be specified. All other entries are optional.
Page 2: Multi Language Descriptions
Long and short descriptions of the country can be translated here into different foreign languages.
Each company in IDL Konsis has to be assigned to a currency. For this purpose you have to define currency codes before you are able to defines companies. If the currency code of a company differs from the group-currency a currency conversion is required.
'Currency Code' (WKZ) serves the identification of foreign currency companies in IDL Konsis.
It is recommended this to use Currency Code in accordance with ISO code company-wide: e.g. :
A sample list is delivered with each release in the directory "Lieferbatch/WKZ-LKZ_ISO-Codes".
The application "Currency codes" (WKZ) displays a table with all defined currencies after invocation. New entries as well as modifications are performed using a wizard consisting of three pages.
Page 1: Descriptions
The currency code key has a maximum length of three-digits alphanumeric. Additional to the max. 35-digit description and the short name (max. 10 digits) the 'valid-from' period has to be specified. Both the description and the short name can be specified in different languages.
Page 2: Properties
[ Currency Conversion Rate ]: Valid only for rates with the old-fashioned exchange type M to avoid problems with the number of significant digits. Possible entries are 1, 10, 100 etc. E.g. HUF with factor 100 and x-rate of 0,31527 to EUR, means: 100 HUF are 0,31527 EUR (instead of 1 HUF). While defining a new currency-code the default value of the currency conversion factor is 1.
[ Number of decimal columns ]: A thousand value currencies usually use 0, default value is <2>. Other entries are not supported.
Page 3: Multi Language Descriptions
Long and short descriptions of the currency can be translated here into different foreign languages.
The facts are allocated enterprise-wide and are part of the group of the so called 'enterprise-wide data' which are selected and transferred in the case of the IDL Konsis-to IDL Konsis data interchange (KONDAT) with that.
A data type is a sub-structure opportunity for balances, transaction-data and parameter data within an accounting period. They are used as an organization criterion for:
When started the application "Facts" (short word = "FAC") displays two tables:
The new entry and change of a fact is performed using a wizard which consists of five pages:
Page 1: Description
[ Fact ]: The fact is identified by a 2-digit alphanumeric key, which has to be defined by the user.
[ Validity from / until ]: Space of time for the validity of the fact with entry of the periods in format
[ Description ]: Description of the fact with maximum of 70 digits
[ Short name ]: Maximum 10 digits
Page 2: Common
[ Group fact ]: If this hook is not set, data on this fact use the company charts of account. If the hook is set, then the group chart of accounts as well as the account for retained earnings are required entries. With this entry, IDL Konsis recognizes if with a change from one to another fact (e.g. from I2 to I3) also a change from company chart of account to group chart of account takes place.
[ Plan fact ]: The definition of a fact being a plan fact provides for the aggregation of development transactions to a planning aggregation account if specified in the account master data at carry-forward into the next period.
[ with account aggregation ]: This flag determines whether data on a low-level fact are transferred and aggregated to an aggregation account optinally specified in the account master data at transfer to the next higher level fact. Controlling balances are transferred correspondingly to an aggregation controlling object.
[ Group chart of account ]: The group chart of accounts to be used has to be listed in the field provided for it at facts on group level.
[ Retaind earnings account ]: The specification of this account is required for facts on the level of the group chart of accounts. If there is no special 'retained earning account' (AccFlag = 'X') in the group chart of account, this entered account will be used for carry-forward of postings affecting the net result. With this it is possible to use different retained earning accounts per fact.
[ Fact group-structure]: The "Fact group-structure" specifies a reference fact used for determination of the group companies if a function has to consider data of all of the companies of the group. Amongst others different "Facts group-structure" per fact are useful if group statements are built on different facts (e.g. 'I4' for local GAAP, 'I6' for IFRS, 'P4' for plan statements). Without spicification of an "Fact group-structure" in the fact master data the specification in the user start-up data (VOR) is applied.
[ Accounting standard ]: An attribute 'accounting standard' can be selected in this application 'FAC' (for group level), as well as in the applications 'KTP' (only for company level) and application 'KTO' (only for group level). If you select a standard from the combo-box a check takes place that on the respective fact only data for accounts with this accounting standard or without any accounting standard are allowed. This kind of check also takes place for report data.
[ Account group checks ]: This entry allows for the restriction of the status display for the check of transition to the next fact to certain account groups ('B' = only balance sheet, 'G' = only p&l, 'S' = incl. statistical accounts). However, the log of the check is not restricted by this flag.
[ Exclusion group for check rules ]: If an exclusion group for check rules is selected, then the check rules allocated to this exclusion group are not executed. For further information see GUIDE check rules.
[ BU layer]: This property determines whether the data on the respective fact are differentiated per business unit or not. The setting "fact layer with/without business unit" means that this property is specified for each company on its own by definition of company / business unit allocations (GESUBR).
[ Currenies LC/GC/PC ]: This setting determines which currencies are expected on this fact and whether a currency conversion is required.
Page 3: Options for Balances and Details
[ Account Balances ]:
[ Intercompany ]:
[ Controlling ]:
[ Statistical data ]:
Notes for using audit trails:
Page 4: Controlling
[ Chart of controlling objects ]: For facts on the level of the group chart of accounts you have to enter a chart of controlling objects for each defined controlling dimension as far as the flag for controlling balances is activated for this fact. The controlling dimensions are designated with their individual descriptions.
Page 5: Multi Language Descriptions
Long and short descriptions of the fact can be translated here into different foreign languages.
The data type of the demonstration system of IDL Konsis are:
By this technique the data flow is described beyond all doubt in the consolidation system. E.g. balance sheets, profit and loss accounts as well as cash-flow-calculations can be prepared at each of the levels named above. Any time, the proof can therefore be led which balances were reported in IDL Konsis and were changed like this on the way to the commercial balance sheet II. This is particularly of importance for documentation and auditing purposes.
With this kind of procedure the data of consolidation is described faultlessly.
With these data type it is possible in IDL Konsis to carry for particular evaluation purposes only balances, transaction or parameter data for the corresponding data type, without master and structure data having to be kept redundant. The user is enabled to carry out simulations in the system quickly with that.
The following diagram shows a data type concept as it is used by many customers. It should be noticed that you not necessarily have to run through all four steps (I1, I2, I3 and I4). Mixtures will occure quite frequently. A part of the subsidiary subcompanies is already imported in at the level I1 (original general ledger), for example, while for other companies the complete commercial balance sheet II is already tendered on the data type I4.
Figure: Workflow between the different facts
Fact sequences are an optional extension to the usage of facts. A fact sequence defines the order of the transitions of data from fact to fact.
For this purpose the application "Facts" (FAC) exhibits an area "Sequences" on the left hand. At first you have to define a sequence by specification of its key, a description and its validity. FOr this purpose a wizard opens after pressing the mouse key on the star icon. Afterwards the sequence is displayed in the left hand table. A detailed comment can be supplemented.
In the following steps at least two facts have to be allocated to the sequence. This is performed by selecting the fact in the right hand table and dragging and dropping it on the sequence or in the desired position between other facts of a sequence. You have to order the facts in the way that transition is always proceded from the top to the bottom, i.e. with respect to the example of the preceding chapter 'I1' - 'I2' - 'I3' - 'I4'. With aid of the delete icon you can remove a fact from a sequence.
Each fact may only occur once within a sequence. Another plausibility check at allocation is, that a fact on the level of the company chart of accounts must not be the successor of a fact on the level of the group chart of accounts. All changes are saved immediately in the database without using a <Save> button.
The definition of a fact sequence provides for the following functions:
Since the number of transaction development areas is arbitrary, flags for activiation of these areas cannot be maintained in the fact master data (FAC). Rather the separate application "Facts / development areas" (FACSBE) controls, which transaction development areas are kept on which fact.
For easier maintenance this application is realised as a form entry application. The allocations can be displayed in a matrix (column option 'M', facts in columns, development areas as lines in tree representation with transaction developments as nodes) or in list (column option 'L') representation.
Each cell alows for the entry of the respective allocation flag. Deleting of this flag is not supported, however, a '-' can be entered with the same effect. The entries are checked and written into the database yet after pressing the 'Save' button (disk icon).
This allocation flag determines whether development transactions for this development area are to be maintained on the respective fact or not. It can accept the following values:
If a transaction development contains several checked development areas, e.g. like the fixed asset development, then these development areas always have to be provided with the same value for this flag.
In connection with the consolidation functions accounting periods needs to be created. In the application 'Periods' (ABR) periods will be defined. The overview shows all defined accounting periods which are already saved in IDL Konsis.
The following actions can be invoked using the context menu (right mouse key):
[ Mass update ]: Can only be used in the mode "Table cells editable".
[ Table cells editable ]: Allows for a modification of all data displayed in blue colour without opening the wizard.
[ Copy closing date periods... ]: This action allows for copying of selected lines (periods) into a new year. This way e.g. you can create periods for all 12 months of a new accounting year with one command. All flag settings (e.g.for detailed data) are copied from the corresponding month of the source year. Year numbers in descriptions are automatically adjusted to the specified destination year number. Periods already existing are not overwritten.
[ Periods / development areas ]: Branches off into the subsequent application 'ABRSBE'.
[ Authorise new accounting period like prev. period ]: Releases the selected period for all users by copying the rights for all user groups (defined in 'BENDEF') from the last period before this period.
[ Lock accounting period ]: Locks the selected period against modfications by withdrawal of all authorisations (except for 'Display') for all user groups which are defined in 'BENDEF'. If the change-log of consolidation postings and thus the "Four eye principle" for the release of consolidation vouchers is activated, then a period must not be locked if any consolidation voucher for this period is not yet released.
'Authorise and lock accounting period' is only useful, if the authorisation level '2' (authorisation via BENABR + specials) is applied for all users in the application 'VORADMIN'.
[ Period authorisations ]: Switches into the subsequent application 'BENABR'.
[ Exclusion groups / check rules ]: Switches into the subsequent application 'PRFZUO'.
[ Descriptions (long an short texts + column headers) ]: Switches into the subsequent application 'TXT'.
Page 1: Description
[ Closing date period ]: Format = 'MM/YYYY'
[ Description ]: Maximum length = 70 digits
[ Short text ]: Maximum length = 10 digits
Page 2: Common
[ Period type ]: The period type is a mandatory entry. The selection month (M), quarter (Q) or year (J) is the assumption for the correct process of the carry forward function and for the correct calculation of depreciations.
ATTENTION: Within one calendar year only one period should be designated as "Year". Several consolidation functions are based on the determination of the last yearly statement as the last previous period with period type 'year' instead of an explicit entry in KTKGES.
[ Previos period ]: Serves only for pre-selection of entry fields for previous periods in different dialogue applications (e.g. PERGES, KTKGES). It depends on the workflow of the customer whether the previous month or the previous year statement is specified here. Without an entry the previous period of the user's start-up data (VOR) is applied.
[ Exclusion group for check rules ]: If an exclusion group is chosen the check rules allocated to this exclusion group will not be performed in this period. For detailed information please see GUIDE Check rules.
Page 3: Optons for balances and details
[ + IC account balances ]: Determines whether intercompany account balances (ICKTOSAL) are maintained in this period and shall be checked with the account balances.
[ + IC fixed asset transact ]: Determines whether intercompany account balances (ICANLBEW) are maintained in this period and shall be checked with the account balances.
[ + IC inventories ]: Determines whether inventories IC-stocks (ICVOR) are maintained in this period and shall be checked with the account balances.
[ + Contr. balances ]: Determines whether controlling balances (CNTSAL) are maintained in this period and shall be checked with the account balances.
[ + Contr. details for IC balances ]: Determines whether controlling balances shall be checked with the intercompany account balances in this period.
Page 4: Multi Language Descriptions
Long and short descriptions of the fact can be translated here into different foreign languages.
Since the number of transaction development areas is arbitrary, flags for activiation of these areas cannot be maintained in the period master data (ABR). Rather the separate application "Periods / development areas" (ABRSBE) controls, which transaction development areas are kept in which period.
For easier entry of the maintenance of transaction development areas per period this application is realised as a form entry application. The allocations can be displayed in a matrix (column option 'M', periods in columns, development areas as lines in tree representation with transaction developments as nodes) or in list (column option 'L') representation. The amount of periods can be restricted to single periods (optionally in addition a not-changeable comparison period) or to a period interval by corresponding entries in the selection area.
Each cell alows for the entry of the respective allocation flag. Deleting of this flag is not supported, however, a '-' can be entered with the same effect. The entries are checked and written into the database yet after pressing the 'Save' button (disk icon).
This allocation flag determines whether development transactions for this development area are to be maintained in the respective period or not. It can accept the following values:
If a transaction development contains several checked development areas, e.g. like the fixed asset development, then these development areas always have to be provided with the same value for this flag.
Existing development transactions are carried forward into each period independent from this flag.
TZhe allocation flags of FACSBE and ABRSBR may be deviant. The following table informs about the effect of the different combinations.
| ABRSPI \ FACSPI | - | A | M | X |
|---|---|---|---|---|
| - | no | no | no | no |
| 0 (keine Bewegungen) | no | not permitted | not permitted | no |
| 0 (Daten vorhanden) | no | not permitted | not permitted | yes |
| F (Konzernwährung) | no | not permitted | no | no |
| F (Fremdwährung) | no | not permitted | without automatic | yes |
| M | no | not permitted | without automatic | without automatic |
| X | no | generated balances | without automatic | yes |
Explanations: