Basic Masterfiles

Table of Contents

• 1 General
• 2 Country Code (LKZ)
• 3 Currency Code (WKZ)
• 4 Facts (FAC)
• 4.1 Wizard
• 4.2 Example: Concept of Facts in IDL Konsis Demo System
• 4.3 Fact Sequences
• 5 Facts / Transaction Development Areas (FACSBE)
• 6 ClosingDateActual Periods (ABR)
• 6.1 Action menu of ABR
• 6.2 Wizard
• 7 Periods / Transaction Development Areas (ABRSBE)
• 8 Combinations of Allocation Flags in FACSBE and ABRSBE

1 General

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

• Country codes (LKZ)
• Currency codes (WKZ)
• Facts (FAC)
• Facts / Transaction development areas (FACSBE
• Periods (ABR)
• Periods / Transaction development areas (ABRSBE)

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.

2 Country Code (LKZ)

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:

• DE = Germany
• FR = France
• US = United States of America

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.

3 Currency Code (WKZ)

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. :

• EUR = Euro
• CHF = Switzerland Franks
• USD = US-Dollar
• TRY = New Turkish Lira

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.

4 Facts (FAC)

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:

• distinction of actual data, data for planning and budget or forecast data
• the different postings-/ correction of postings at the connection of the original financial accountant balances up to the consolidated accounts level
• parallel demonstration of account balances up to different accounting standards (like IFRS, US-GAAP, local GAAPs) in comparison
• simulation purposes

When started the application "Facts" (short word = "FAC") displays two tables:

• a table with all defined facts and their properties in alphabetical order on the right hand
• a tree table with all defined fact sequences on the left hand

4.1 Wizard

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 optionally 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.

[ Retained 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 specification of a "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).

[ Currencies 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 ]:

• The first check box "with account balances" determines whether account balances are expected on the fact. This generally applies. Exceptions are special facts e.g. for intercompany clearing.
• The second check box "with origin list account balances" controls whether an audit trail about the origin of the account balances (balances, postings) shall be generated when transiting data to this fact. This audit trail can be viewed in the list "Account balances-origin list" (KTOHER).

[ Intercompany ]:

• The first check box "with IC account balances" determines whether IC account balances are used on this fact at all and be checked with the account balances. The activation of this check box is prerequisite for the display of the status "ICKTOSAL", for the transition to the next fact and for currency conversion of these data as well as for IC reconciliation or consolidation D&C or I&E, respectively.
• The second check box "with details of IC general balances" on the right hand controls whether intercompany account balances are held for intercompany general accounts (account with a firm allocation to an intercompany) and generated at transition to this fact, respectively. Otherwise these data are not considered for IC clearing on this fact.
• The activation of the check box "with inventories IC-stocks" is prerequisite for the display of a status "ICVOR", for the transition and currency conversion of these data as well as for the elimination of IC-profit (current assets, ZU).
• The activation of the check box "with IC fixed assets transactions" is prerequisite for the display of a status "ICANLBEW", for the transition and currency conversion of these data as well as for the elimination of IC-profit (fixed assets, ZA).

[ Controlling ]:

• The first check box "with controlling balances" determines whether controlling balances are used on this fact and be checked with the account balances.
• The activation of the check box "with details of IC-balances" provides for a strong check of the specification of controlling objects in intercompany account balances as far as the corresponding flags in ABR are activated, too (see below). This entry concerns the plausibility checks and the report display but not the consolidation D&C and I&E.
• The check box "with origin list controlling balances" controls whether an audit trail about the origin of the controlling balances (balances, postings) shall be generated when transiting data to this fact. This audit trail can be viewed in the list "Controlling balances-origin list" (CNTHER).

[ Statistical data ]:

• The check box "with statistical data" determines whether statistical data (b/s p&l codes '5' to '9') are maintained. This is prerequisite for the transition of statistical data to the next fact and their transition check.

Notes for using audit trails:

• In general it is advisable to activate the audit trail before carrying out the action "Transition to new fact ('EA' or 'GESABV'), since this action has to be repeated after a subsequent setting of this flag. The data are written into 'KTOHER' or 'CNTHER', respectively, when changing from one fact into the next higher fact.
• ATTENTION: Manual modifications of data in the destination fact does not provide an alignment of the origin data. In this case the audit trails ('KTOHER' or 'CNTHER') can be deleted. This function can be invoked from the lists 'EA' and 'KTOHER'. (Changes should be performed only by postings on the source fact and repetition of the transition.) The deletion of audit trails is supported for single business units as well as for total companies.
• Audit trails are simultaneously deleted for account and for controlling balances. A corresponding message is output after deletion.
• A report with report option 'Controlling balances origin report' (G) or report option 'Account balances origin report' (H), respectively, has to be defined in the application "Company reports" ('REP').
• The report for audit trails contains the following error, which cannot be corrected by implication: If the company chart of accounts contains account aggregated to an aggregation account, with some debit and some credit balances, and the transition to a fact with the group chart of accounts has a destination account with debit/credit control, then the amount on the position with the account from the group chart of accounts is not correct. Only balances with the appropriate debit/credit code are summarized while the others appear on the other position specified in the debti/credit control. Without audit trail the amount on this account is allocated and exhibited correctly in the report. This problem can only be solved by abstinence of the debit/credit control in this place. Alternatively the report can be created without audit trail, since the audit trail can be retraced with the applications 'KTOHER' or 'CNTHER', respectively, too.
• There are differences between 'KTOSAL' and 'KTOHER' for the net result after business unit split, since this account is automatically cleared. This clearance is not performed for the audit trail. Therefore result accounts are not written into the table 'KTOHER' at transition and not considered for checks with respect to account balances.

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.

4.2 Example: Concept of Facts in IDL Konsis Demo System

The data type of the demonstration system of IDL Konsis are:

• I1=Data type of origin of companies data as taken over from financial systems(s)
• I2=Data type of companies balances modified by possible late postings, which origin is on data type I1-Level
• I3=Trial balance after mapping the companies balance to the group chart of account level.
• I4=Group Balance plus adjustment-postings on group level II which are entered into a ledger on data type level I3
• P4=Planning ledgers on group data level II

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 occur 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

4.3 Fact Sequences

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 proceeded 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:

• When transposing company financial statement data to the next fact it is checked whether the transition is permitted due to the defined fact sequences. If the specified destination fact exists in the sequence table as successor fact, then the specified source fact has to be one of the defined predecessor facts.
• Locks of company financial statements do not affect only the data of the respective fact but rather all preceding facts, too, as defined in fact sequences. If e.g. the statement is locked for fact 'I4' and a sequence is defined using the facts 'I1' -> 'I2' -> 'I3' -> 'I4', then the company financial statements on the facts 'I3', 'I2' and 'I1' are locked, too.
• Fact sequences are considered for setting of the status "Check transition to the next fact" in the company financial statement monitor (EA). If data are changed on a fact which is defined as a preceding fact in a fact sequence, then the status is set to [yellow] in all potential succeeding facts as far as the check point already exists. If the check of transition is performed on a successor fact and the status of the preceding fact is [yellow], then the status becomes [yellow], too (message in processing control: "Data of a preceding fact have changed"), since there are deviations in comparison to a fact located in the direction of the fact sequence start.

5 Facts / Transaction Development Areas (FACSBE)

Since the number of transaction development areas is arbitrary, flags for activation 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 realized 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 allows 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:

'-':

Development transactions for this development area are not maintained on this fact and are not checked, too (no status display in EA).

'A':

Account balances are automatically calculated from the total of development transactions. The balances for the respective accounts can only be generated from these development transactions. This value may not be set if the development area is declared as automatic. Furthermore, if the flag is set to 'A' the ABRSBE flag must not be set to '0' in any period.

'M':

Development transactions for this development area are maintained manually. I.e. even for a development area declared as "automatic" the difference between account balance and total of development transactions is not cleared automatically by a transaction of changes in the actual period.

'X':

Development transactions for this development area are maintained with respect to its definition.

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.

6 ClosingDateActual Periods (ABR)

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.

6.1 Action menu of ABR

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 modifications 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'.

6.2 Wizard

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.

[ Previous 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: Options 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.

7 Periods / Transaction Development Areas (ABRSBE)

Since the number of transaction development areas is arbitrary, flags for activation 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 realized 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 allows 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:

'-':

Development transactions for this development area are not maintained in this period and are not checked, too (no status display in EA).

'0':

Development transactions for this development area are maintained only for parts of the companies or accounts, respectively. This pays tribute to the ever more frequent instance of having to maintain fixed asset transactions only for participation accounts. As far as development transactions are existing they are checked for consistence with account balances. If no transactions exist no check is performed. If the flag is set to '0' the FACSBE flag must not be set to 'A' for any fact.

'F':

Development transactions for this development area are maintained only for companies with foreign currency (local currency different from group currency) in this period (maintenance like 'X'). No check is performed for companies with local currency equal to group currency (maintenance like '-'). This pays tribute to the ever more frequent instance of having to maintain capital transactions only for foreign currency companies.

'M':

Development transactions for this development area are maintained manually. I.e. even for a development area declared as "automatic" the difference between account balance and total of development transactions is not cleared automatically by a transaction of changes in the actual period.

'X':

Development transactions for this development area are maintained with respect to its definition.

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.

8 Combinations of Allocation Flags in FACSBE and ABRSBE

The allocation flags of FACSBE and ABRSBR may be deviant. The following table informs about the effect of the different combinations.

Explanations:

"yes":

Development transactions for this development area are maintained with respect to its definition.

"no":

Development transactions for this development area are not maintained and are not checked, too (no status display in EA).

"generated balances":

Account balances are automatically calculated from the total of development transactions.

"without automatic":

Development transactions for this development area are maintained manually. I.e. the automatic clearing of the difference between account balance and total of development transactions is not performed.

"not permitted":

This combination is not permitted and provides error messages.