GUIDE for transactions in companies 'financial statements'

Table of contents

1 View from the Company Financial Statements Monitor ('EA' Monitor)

Transactions contained in the company financial statement are entered in terms of transaction developments and processed, if the tag for maintenance of development transactions has been placed for the current type of data and period in the applications FACSPI and ABRSPI.

Image: Transaction development activation for a type of data in FACSPI

Image: Transaction development activation for a period in ABRSPI

If a new transaction development has been set up and no transactions exist yet in the respective accounts, the column in the “EA” monitor will remain hidden. If you would still like to have the transaction development displayed, the options "Blend out blank columns" and "Blend out zero columns" can be deselected via the menu item "view".

The status of the transactions for each company and account can be viewed as follows from the company financial statement monitor for the company marked:

- Double click in the column KTOSAL or

- Via action -> account balances or

- Direct entry of the abbreviation KTOSAL

Image: View in the “EA” monitor

Image: View in KTOSAL

The status of each account will be shown in the account balances in the "transaction development" column. The setting can be selected under the entry field "transaction development". The details of the respective account you’ve selected can be reviewed immediately via the input field by double clicking onto "transaction development" or by using the action menu. The flags that do not have background colors (for instance"D" for reconciliation of depreciations) link with the transactions by double clicking. This is very practical because you can see the selection you have made at a glance (for instance, registered depreciation transactions across all accounts or transactions for only one transaction development account, incl. differences). Here, a difference will possibly be shown with a red background in a line between the sum of the development transactions and the account balance:

Image: Display of the differences between the account balance and development transactions

With each complete call up, the user will be informed of the error situation until the transactions are correct. Differences for each account will be displayed in the message window:

Image: Error message in the event of differences between account balances and development transactions

Development transactions with posting keys that are not assigned to validated transaction development areas will not be included in the sum for comparison with the account balance. They also will not be taken into consideration while generating account balances from the sum of development transactions. They will be included in the control values, however. With all transaction developments (except for GESGES), the transactions that are not to be audited will be shown inside their own block under the test block for information purposes.

The possibility of displaying account terms in another language also exists with respect to all transaction development applications. This is selected via extended in the input field called "language".

All of the development transactions will be explained in the chapters that follow in their automatic order. Each of the columns in the “EA” monitor can be shifted individually.

2 Development Transactions (SPIBEW)

2.1 Overview

In IDL Konsis it is possible to set up as many as nine individual transaction developments on customers. The transactions required for this are to be entered and maintained using the application SPIBEW.

If accessed directly, the application SPIBEW will provide access to the respective current overview via development transactions of one or more companies for the respective type of data and current period that has been selected. The application will open by showing the development transactions for S1 on a standard basis. If the transactions are to be shown for another transaction development, the entry in the field 'transaction development' needs to be changed accordingly. If you enter '%', all of the transactions involving capital, provision and individual transaction developments will be shown.

If an account is to be allocated to a different transaction development than before, there might be data (postings, transactions) on this account that has an incorrect posting key. This data has not been displayed before, therefore it couldn’t be deleted either, but possibly resulted in errors in other areas of processing (e.g. currency conversion) which therefore could not be corrected very easily.

For this reason, the overview on transactions (SPIBEW) has been expanded to include the possibility of selecting data by making the entry "transaction development = '%'". Then, the data contained in the database will be displayed regardless of the transaction development for this account and may also be deleted.

Image: Application SPIBEW

In this selection area, you can decide what sorting sequence you would like to use with what selections. These will each include the respective preliminary and final sums:

Image: Sorting options

Special selections

Starting at period (abPer)
If an entry is made in this field, the transactions will be sorted according to periods. The current account balance will always be shown.
If a valid entry is made in this field, the complete transactions from all periods included in the interval specified will be displayed, whereby automated carry forwards (with the exception of the initial period) will be read over.
If a valid entry is made in this field in a MDK transaction development , you will be presented with the complete development of transactions throughout all periods included in the interval specified, whereby automated carry forwards (with the exception of the initial period) will be read over.
Transaction development column
This function allows for selection of the transactions contained in a specific transaction development column (e.g.carry forwards, addition, etc.).

In contrast to other transaction overviews, selection at the group level is not possible in SPIBEW. The reason for this is that development transactions can only be maintained at the company level. The data required for a group report is read from the posting keys in the consolidation postings.

2.2 Individual record application

Image: Individual record on an individual development transaction SPIBEWE

Development transactions are usually read in a mainly automated manner, whether this is done using an interface to a financial system or an Excel entry form. If development transactions are to be entered in manually or existing entries are to be worked on, this is done using the individual record application SPIBEWE that can be accessed by way of the action menu included in the overview. The key fields period, type of data, company and transaction development must be specified very clearly in the overview to begin with and can no longer be changed in the individual record application.

Special fields:

[Account number]
The first field in which an entry can be made is the account number. Development transactions can only be entered for accounts with (predetermined) transaction development tags = S1-S9. Only those accounts will be offered for selection which correspond to the transaction development that has already been selected. The entry tags in the account master will be evaluated while entries or manual changes are being made. If the entry tag for the period tag of the current period ('Y', 'Q' or 'M') has not been placed, no entries or changes will be possible.
[Business Unit / IC Business Unit]
If the company financial statements are maintained in a differentiated manner according to business units, each and every development transaction can be allocated to a business unit by entering in a business unit. Validation of account balances and development transactions is performed for each business unit. Furthermore, specifying the business unit for validation with respect to allocating business units to companies takes place using the table GESUBR.
[Transaction date]
When recording a new development transaction, the transaction date should not be preset. This is an optional (white) input field that does not require an entry. If it remains empty, it will be assigned a default value when save is pressed, but only if: a) it is the first day of the current business year, if it is a carry forward transaction, according to the transaction development column of the posting key or b) it is the last of the month of the current period with all of the other posting keys. In addition, the system will check to make sure that the transaction date is not younger than the last of the month of the current period.
[Posting key]
The posting key that must be set up for individual transaction developments in the application BSL first characterizes the type of development transactions and determines what column the transaction appears in with respect to the individual transaction development.
[IC company]
This entry is only possible for accounts that have the account tag I or J at the same time. If data is held with the entry IC company, it will also be validated against the IC account balances. If the sum of the transactions for an IC company does not match the corresponding sum of the IC account balances, this will be reported like differences in account balances.
[Conversion rule, exchange rate, effective date for the exchange rate*]
If the local currency differs from the group currency, the conversion rule can also be used to control what rate should be used to calculate the development transaction. If the conversion rule 'VK' (predetermined rate) is used, the exchange rate and the effective date for this exchange rate must also be listed. If the conversion rule is not entered, recalculation will take place using the account conversion rule (KTOUAW) or per posting key via the table BSLUAW.
[Value group currency*]
If local and group currency are identical, then the value LW will be automatically accepted as the value KW. Otherwise, only currency conversion will be entered into this field. Exception: if the conversion rule 'VKW' (predetermined group currency) is used, then the value KW must be entered.

*The entries in the fields for parallel currency essentially work the same.

Development transactions that are created with the help of automatic functions are not allowed to be changed manually or deleted unless that person has special access rights.

2.3 Further Actions

Image: Warning in the event of existing data

The automatic calculation of the transactions from the current period has been switched over in version 2010.0. In the past, these always had to be calculated based on the difference between the account balance and the sum of transactions with the help of other usage tags (e.g. carry forwards). In the future, the difference between the account balance and the sum of all other transactions will be calculated. This will make it possible to issue additional posting keys for manual entry of special contents (e.g. additions/disposals as a result of mergers).

This change will only affect automatic transaction developments without sample accounting, due to the fact that all of the posting keys that lack usage tags can be assigned to the actual account details that require maintenance with transaction developments that feature sample accounting (e.g. liabilities based on maturity).

Correct development transactions are the prerequisite for creating transaction development reports with IDL Konsis.

3 Automatic Transaction Developments for the Cash Flow Report

3.1 Overview

Information like the carry forward, ongoing changes or currency exchange rate effects on all of the balance sheet accounts will be needed for the cash flow report. To ensure that these do not need to be entered in manually, this information can be generated completely automatically by defining the appropriate posting keys. The prerequisite for this is the reservation of one of the nine individual transaction developments.

Image: Example of cash flow transactions

If an account for an individual transaction development with automatically generated transactions (typically 'S9') has the account tag 'B' for shareholding transactions (GESGES) at the same time, then the development transactions generated must be issued with an IC company (or also an IC business unit) in accordance with the GESGES details of the account. This mimic is similar to that of IC accounts (account tag 'I') with respect to ICKTOSAL details.

Normally, four posting keys (for each transaction development area) will be necessary that must be marked in the application BSL by the appropriate usage tags:

  1. Usage tag 'V' for a carry forward. These transactions will normally be generated by the periodic carry forward from the sum of the transaction from the previous period. If no balances were contained in the previous period, the transaction will be generated from the account balances of the previous period, if there were any.
  2. Usage tag 'L' for ongoing change. As soon as a posting key is defined by a usage tag entering or changing account balances for this transaction development, a transaction with this posting key will be generated based on the difference between the account balance and the carry forward transaction.
  3. In addition, development transactions with posting keys that have the usage tags 'E', 'F' and 'Q' will also be taken into consideration as they result from aggregation of a sub-group into a company financial statement (KTK2GES).
  4. Usage tags 'K' and 'U' for currency conversion effects on the carry forward or other conversion differences. Transactions that have these posting keys will be generated by currency conversion.

No additional posting keys will be needed for standard transaction developments (fixed assets, capital , provisions), due to the fact that there are already posting keys for carry forwards, currency conversion effects and conversion differences. Ongoing changes refer to the sum of all other transactions. The same applies for individual transaction developments that already use carry forward formation.

The case in which there are individual transaction developments without any carry forwards (e.g. liability transaction developments based on maturities) is more complex. Here, generally speaking, only a posting key with the usage tag 'U' is defined, under which the rounding differences that result from currency conversion are posted. The information for the cash flow report has to be maintained in parallel in sample accounting:

Image: Settings for the view including cash flow transactions

4 Fixed Asset Transactions (ANLBEW)

4.1 Overview

When accessed directly, the application ANLBEW shows the respective current overview of the fixed asset transactions of one or more companies or groups for the respective type of data and period selected. With this application, you can decide what sorting sequence and selections you would like to make that are equipped with the appropriate interim and final totals.

If an account is allocated to a different transaction development than before, this might result in data (postings, transactions) on this account that has an incorrect posting key. This data hasn’t been displayed before, therefore it could not be deleted either, but possibly resulted in errors in other areas of processing (e.g. currency conversion) which therefore could not be corrected very easily.

For this reason, the overview on transactions (ANLBEW) has been expanded to include the possibility of selecting data by making the entry "transaction development = '%'". The data contained in the database will then be displayed, regardless of the transaction development for this account and can also be deleted.

Image: Application ANLBEW

Depending on the chart of accounts tag used for the type of data at the level of the company chart of accounts or group chart of accounts, fixed asset transactions may be held. In terms of the types of data in the group chart of accounts, a distinction is made between

When gaining access via the line action from the account balances KTOSAL (by way of the actions menu or by double-clicking onto the transaction development tag = A), the exact details of the account selected will be displayed immediately.

When gaining repeat access from the consolidation postings (KONBUCH), however, the group/Tk will be retained so that only the fixed asset transactions for the group financial statement can be chosen.

Special selections:

Date purchased and date sold
If a date is entered here, only transactions on fixed asset objects will be selected that contain the appropriate information in the fixed asset object master.
Transaction development area
The transactions can be chosen by acquisition/production cost('A') or depreciation ('B') according to the tag in the posting key master
Transaction development column
This function allows for the transactions in a specific transaction development column (e.g. carry forward, addition, etc.) to be selected

If the appropriate switches for the maintenance of ANLBEW have been activated in the applications FACSPI and ABRSPI, validation of all of the fixed asset transactions for the company financial statement will take place for each company and business division with each complete call up of the overview. The following will be checked:

This check is performed on all three currencies. The check sums from the account balances or consolidation postings will be displayed in a separate line at the end of the table. Any differences will be presented for each account in the message window. The user will be informed of the error situation during each complete call up until the transactions are correct. These checks also take static accounts into consideration.

Accurate fixed asset transactions are the prerequisites for developing transaction development reports with IDL Konsis.

4.2 Individual record application

Image: Individual record for the fixed asset transaction development transaction ANLBEWE

If fixed asset transactions are recorded manually or existing transactions are processed, this will be done using the Individual application ANLBEWE that is accessible via the action menu in the overview. The key fields period, type of data and company must already be entered in clearly in the overview and cannot be changed in the individual record application anymore.

Special fields:

[Fixed asset object]:
Unlike other types of transactions, the details of the fixed asset transactions are on each fixed asset object and not per account. Normally, only one fixed asset object is generated for the company financial statement data per account, however multiple objects per account (that have different prefixes) are possible. Fixed asset transactions can only be listed in accounts that have the transaction development tag 'A'.
[business division / IC business division]:
If the account balances differ in terms of business divisions, then each individual shareholding transaction can also be allocated to a business division of the parent company. Validation of the account balances and shareholding transactions takes place per business division.
[Transaction date]:
When entering a new development transaction, the transaction date should not be preset to include a default value. It is an optional (white) input field and doesn’t have to be filled in. If it remains blank, the default value will be entered when saved is pressed, namely: a) with the first day of the current business year, if it is a carry forward transaction, according to the transaction development column of the posting key or b) at the end of the month of the current period with all of the other posting keys. In addition, the system will check to make sure that the transaction date is not more recent than the end of the month for the current period.
[Posting key]:
The posting key characterizes the type of fixed asset transaction, e.g. carry forward, addition, disposal. The posting keys for fixed asset transactions are divided into at least two transaction development areas: A for acquisition/production cost, B for depreciation.
[IC company]:
The IC company and perhaps the IC business unit should be included if the current fixed asset account is both an intercompany or participations account (account tag 'I' or 'B'). An appropriate warning will be issued if this entry is missing. The purpose of this entry is to store the data on IC balances (ICKTOSAL) or shareholding transactions (GESGES) in a consistent manner. Transactions with different IC information will not be aggregated during a carry forward for a period.
[Conversion rule, exchange rate, effective date for exchange rate*]:
If the local currency differs from the group currency, the conversion rule will help you to control what exchange rate should be used for conversion of a fixed asset transaction. If the conversion rule 'VK' (preset exchange rate) is used, then the exchange rate and the effective date for this exchange rate must also be entered. If the conversion rule is not entered, then conversion will take place in accordance with the account conversion rule (KTOUAW) or for each posting key via the BSLUAW table.
[Value KW*]:
If the local and the group currency are identical, the value LW will be automatically assumed as the value KW. Otherwise, this field will only be occupied by currency conversion. Exception: With the conversion rule 'VKW' (preset group currency), the value KW must be entered.

*The entries in the fields for parallel currency work in a similar fashion.

The debit /credit tag for the values cannot be explicitly prescribed. Instead, it is calculated automatically and entered in accordance with the attributes of the posting key specified in the table BSL according to the following rules:

  1. If a standard debit/credit tag has been assigned to the posting key used, then this is to be used.
  2. If the posting key includes the transaction development area 'A' (acquisition/production cost), debit is to be used.
  3. If the posting key includes the transaction development area 'B' (depreciation), credit is to be used.

If negative values are to be entered, the minus sign should be eliminated and the debit/credit tag should be reversed. This procedure also applies to making changes to existing sets.

The carry forward application (VORPERGES) accepts when fixed asset transactions have a positive value. It is thus possible to list the fixed asset according to AHK and AFA divided between various accounts.

The fixed asset card types 'A' and 'Z' for IC disposals / additions are kept as group fixed asset objects with which the IC additions and disposals that have already been posted in the company financial statement may be reversed again, as if this IC sale had never taken place. For this reason, the entries are checked as in the company financial statement, which means they must be entered in local currency and include currency conversion. If possible, this type of fixed asset transactions should be managed in the application ICANLBEW (see below), due to the fact that only transactions for the company financial statement are managed in the application ANLBEW.

Fixed asset transactions with reserved posting keys that are issued automatically by the applications used for the carry forward, for calculation of continued depreciation or for currency conversion may only be processed by users who have special access rights.

4.3 Further Actions

Fixed asset transactions created using automatic functions cannot be changed manually or deleted unless that person has special access rights. This applies to carry forwards from the previous period as well as balancing transactions as part of currency conversion. Furthermore, these posting keys will not be offered in the selection field.

5 Company Fixed Asset Objects (ANLOBJ)

5.1 Introduction

Fixed asset objects are designed to show objects or values in the balance sheet position 'fixed assets' in fixed asset transactions. The 'fixed asset' position from the company financial statement in the area of group financial statements can be filled, but also by way of consolidation contents. Separation into company and group fixed asset objects is thus necessary in order to ensure the reliable display and separation of this information.

Image: Application ANLOBJ

The application fixed asset objects ANLOBJ offers a respective current overview of the fixed asset objects of one or more companies, regardless of the type of data and current period. Basically, a distinction is made between three types of fixed asset objects:

Company fixed asset objects can be maintained regardless of the chart of accounts tag used for the type of data at the level of

.

When defining new fixed asset objects, please observe the name giving conventions for the fixed asset object prefix defined in the application KTP.

5.2 Selection possibilities

In the overview ANLOBJ, you can select from various criteria:

Image: Sorting and selection options

[Group/Tk]:
If an entry is made in this field, a distinction will be made between fixed asset objects at the company financial statement level ('*') and the group financial statement level (entry of group name or '%'). If no entry is made, all of the fixed asset objects will be shown.
[SortSelOpt]:
'GA' for sort according to company/fixed asset object; 'KG' for sort according to fixed asset account/company/fixed asset object
[Ges+AnlObj]:
Limit based on company and/or fixed asset object
[ZuoAnlObj.]:
Selection based on the group fixed asset object allocated
[KoPlan+Kto]:
Selection by account number
[AnKartType]:
Selection based on fixed asset card type B (group card calculated negatively by machine, K (group card general), L (group card by machine), M (multiple card company+group), or N (company/group zero card, not to be calculated); the card types B and L are not issued, but rather further maintained, but only to support old data.
[An+VkDate]:
Limit according to the date of purchase or sale of the fixed asset object
[Ab Änd.Dat.]:
Display of the fixed asset objects that have changed since this point in time
[Valid as of/Valid until]:
Limit to the fixed asset objects displayed based on their period of validity

5.3 Company fixed asset objects created by machine

Creation

The transaction development tag "A" is stored in the chart of accounts master (KTO) to show that this account is a fixed asset account that needs to be developed in the fixed asset transactions. Generation of fixed asset objects needs to be initiated for all companies after the master account has been entered into the company financial statement monitor as either an individual record or batch processing. Fixed asset objects depend on the type of data and the period, which means it doesn't matter what company level or type of data is entered when fixed asset objects are created at the company level. Here, the underlying company chart of accounts is much more important (GES001 applies for the types of data I1 and I2). To make sure that automatic allocation to the group fixed asset objects takes place, it is recommended that you perform automatic creation at the group data level first and then at the company level.

Image: Automated generation of fixed asset objects

The following panel will appear once processing has been completed. The number of added, changed, unchanged and defective fixed asset objects will be shown here:

Image: Example of a protocol panel following automated creation of fixed asset objects

This process of creating fixed asset objects is unique. This process needs to be repeated if new asset accounts are to be recorded in the company chart of accounts. In this case, the tag "A" would be noted in the log report when a new account has been created to indicate that 32 records have remained unchanged and one has been added.

Structure

By marking a company and selecting the respective overview "fixed asset objects", you will be able to branch off into these from the company financial statement monitor.

Image: Branch off into fixed asset objects

Image: Overview of ANLOBJ and external applications

This overview can be used to branch off into each individual fixed asset object. To do so, you must mark a line again and branch off in display mode using the right mouse button.

The following view for the fixed asset object A11010 will open up:

Image: Fixed asset object A11010

Application

The fixed asset objects that have now been generated will be used to maintain the fixed asset transaction. If, for instance, the fixed asset transactions are to be entered for Company 001 during the period 12.2008, you must select all of the accounts that have the tag A from the account balances, mark them and branch off into fixed asset transactions by using the right mouse button. Via the action -> enter, you will now be able to maintain the fixed asset transaction development by entering in the respective amount and a posting key (See also ANLBEW). Entering the respective fixed asset object that was generated earlier is the prerequisite for proper maintenance.

Image: Example of fixed asset transactions for ANLOBJ A11010 and the entry ANLOBJ in ANLBEW

5.4 Manually Generated Company Fixed Asset Objects

Besides automated generation of fixed asset objects, these can also be generated manually. In this case, the application ANLOBJ must be called up. Following selection of the company for which the fixed asset object is to be generated, a new one can be created by either marking an existing fixed asset object (whose entries will then serve as a template) or via the action -> Enter (blank template).

Structure

The entry mask corresponds with the one shown in the image above. The mandatory fields (with yellow and turquoise backgrounds) at the very least must be filled in. All of the others can be filled in or cannot be used for company fixed asset objects because they contain group-related contents.

Image:Empty template on creating a ANLOBJ

Explanation of the individual fields in ANLOBJE

1) AnlKartType
A mandatory field with a drop-down box (for valid entries, see drop-down box): Whether or not the fixed asset object is to be processed in the company fixed asset transaction development (card type 'M'), or also in the group fixed asset transaction development (card types 'A', 'B', 'K', 'L', 'Z') or not at all in the fixed asset transaction development (card type 'N') is determined with the help of the fixed asset card type. Intercompany fixed asset objects are specified by using the card types 'A' and 'Z'. The card types 'B' (negative calculation) and 'L' are no longer issued automatically in IDL Konsis therefore, they should no longer be used while making manual entries either. They have only been continued to offer support for old data.
2) Group/Tk
Optional attribute with the selection list: The group/sub-group must be specified for intercompany and group cards. If an entry is made, the system will check for whether the company entered is defined in the group/sub-group according to KTKGES (Calculation period and all types of data).
3) AnlObjBen
Fixed asset object term: Here, the user will have the chance to describe the fixed asset object in greater detail. The terms are not subject to multilingualism.
4) KoPlan+Kto
A mandatory field with a selection list: Here, an account (company or group account) is assigned to the fixed asset object. This account needs to be an active account (Bil/Profit + loss tag = '1' or '6') and a fixed asset account (tag 'A'). All fixed asset transactions for this fixed asset object will be allocated to this account.
5) AnschDate
A mandatory field: The date of purchase will be used as the starting point for automatic depreciation calculationwith intercompany and group fixed asset objects. It has no function for company fixed asset objects.
6) VerkDate
Optional attribute: When a date of sale is entered, automatic depreciation calculation will be limited to this point in time. With disposal cards (card type 'A'), this attribute should remain blank, due to the fact that depreciation calculation fictitiously needs to be continued beyond the point in time of the sale.
7) AfA-Art
A mandatory field with a drop-down box (See drop-down box for valid entries): The type of depreciation with which the respective fixed asset object is to be depreciated is defined here. As part of automatic determination of depreciation , the amount of depreciation for intercompany and group fixed asset objects will be determined based on this entry. This attribute is of no importance for company fixed asset objects. In addition, there are two types of depreciation 'SL' and 'SM' (Linear depreciation with special depreciation). Continued depreciation will be calculated as follows with these types of depreciation:
This means that all of the changes in the book value during the current period, increases or decreases in depreciation or additions cause special depreciation to the amount of ongoing depreciation with retention of the remaining term. This avoids the otherwise necessary effects on the carry forward, because otherwise the carry forwards of special depreciation would need to be distinguished from the carry forwards for other current changes.
8) AfA-Dauer
Optional numerical attribute: The depreciation duration must be specified in years with the depreciation types 'GD' and 'L', and in months with the depreciation type 'M'. The duration currently has only an informational character with the geometrical and arithmetical digressive depreciation (depreciation type 'GD'). It is used to calculate the depreciation amount as part of automaticn calculation of depreciation with the linear depreciation (depreciation type 'L' and 'M' respectively). The maximum values are 99 years and 999 months respectively.
9) AfA-Proz.
Optional numerical attribute: The depreciation percentage used to determine the appropriate depreciation value must be included as part of geometrical digressive depreciation (depreciation type 'GD').
10) AfA-Betrag
Optional numerical attribute: The depreciation value must be included when the depreciation of a fixed amount is entered (depreciation type 'F'). This amount will be posted each year, if automatic calculation of depreciation is used.
11) KtoAfA Bil
This is a balance sheet and fixed asset account ("AfA-KtoBil", value adjustment account) in which depreciation is posted separately to ensure that only acquisition/production costs are found in the primary fixed asset account. The net book value is calculated based on the sum of both accounts. It is only possible to specify a value adjustment account for group fixed asset objects (fixed asset card types 'B', 'K' or 'L'), and posting of the depreciation calculated automatically to the value adjustment account only takes place for the group level (consolidation postings), not for the company financial statement (postings), however, due to the fact that it has not yet been determined how the same fixed asset object is to be allocated to various accounts with certain types of processing.
12) KtoAfA Profit + loss
An optional attribute with a selection list: This account must be defined with IC fixed asset objects and can be defined with group fixed asset objects. This account is without function with company fixed asset objects. This account must be an expenditure account (Bil/Profit + loss tag = '4'); if in IDL Konsis accounts with the account tag 'D' are defined, then only these are available for selection. If an account with an account tag 'D' is entered as a depreciation account, it falls under the automatic check between fixed asset transactions for the transaction development column 13 (ongoing depreciations) and the corresponding profit + loss accounts with the account tag 'D'. The appropriate depreciation correction postings are performed in this account during consolidation processing. If no entry is made here, then the consolidation parameter KK specified in the depreciation account listed will be used in capital consolidation instead.
13) Controlling object
An optional attribute with a selection list: A controlling object of the first controlling dimension to which depreciation is to be posted can be entered in this position. If further controlling details are necessary for the appreciation account, these can be entered manually in the respective postings.
14) ZuoAnlObj
A nonmandatory field with a selection list: If fixed asset objects on various charts of accounts are maintained (company and group chart of accounts or also multiple group charts of accounts), this attribute will result in allocation of a fixed asset object from the respective group chart of accounts. This allocation takes place in the same manner as allocated group accounts.
15) and 16) currency tag and value in local currency
The two attributes "value in local currency" and "currency tag" can be used to maintain business values in local currency in the fixed asset object master.
17) Valid as of and valid until
A mandatory field or optional attribute: Defines the calculation periods starting at which or by when the values allocated to this fixed asset object (fixed asset transactions, consolidation postings, etc.) may be allocated and at which or by when it must be included in the respective fixed asset transaction development(s). Limitations to the validity of a fixed asset account will be automatically inherited by all of the allocated fixed asset objects, therefore the validity of a fixed asset object cannot be any longer than that of the fixed asset account. The appropriate checks take place even when there are changes in the fixed asset object master.

Application notice: If it is necessary to list individual inventories that pertain to an account at the company level, this case could be solved through the additional fixed assets from fixed asset objects. In this case, each individual inventory would have its own fixed asset object allocated.

Here, the question arises as to whether the information obtained cannot already be found in operational fixed asset accounting and whether it is even needed to produce the group financial statement. Due to the fact that the development in the fixed asset transaction development pertains to fixed asset objects, every inventory would need to be developed. For this reason, the effort that goes into maintaining many transactions should be compared with the benefit.

Like other types of master data, fixed asset objects can be issued with a longer description ("help text").

Image:Panel for displaying /editing the help text in a fixed asset object

6 Shareholding transactions (GESGES)

6.1 Overview

When accessed directly, the application GESGES provides the respective current overview of the shareholding/participations in one or more companies for the respective type of data and current period that have been selected.

In this application, the user can decide what sorting sequence he prefers to use with certain selections that are equipped with the appropriate preliminary and final amounts.

Image: Application GESGES

When accessed via the line action from the account balances KTOSAL, all of the details that pertain to the account that has been selected will be shown immediately. Here, a difference will appear with a red background inside a line between the sum of shareholding transactions and the account balance.

Participation transactions can be maintained for both company and group charts of accounts, however only the participations in the consolidation type of data are of relevance to consolidation processing.

Special selections:

Group/sub-group
When entering a group in this field, you will be offered a selection of shareholding transactions for all of the companies that are part of the group of companies (if you have access rights).
From period (abPer)
With an entry from a period in this field, you will be shown the complete development of the transactions across all periods of the specified interval, whereby the carry forwards that were generated in an automated manner will be overwritten.
Transaction development column
This function allows you to select the transactions from a specific transaction development column (e.g. carry forward, addition etc.).

If maintenance of the GESGES for the respective type of data and period has been activated by marking it with an X in the applications FACSPI and ABRSPI, a check calculation will be performed initially between the shareholding transactions that have been selected and the respective account balances in accounts with the account tag 'B' with each complete call up of the overview. The check calculation covers the three value fields for local, group and parallel currency. The check sums from the account balances will be shown in a separate line in the table. Differences for each account will be displayed in the message window and can be printed out from here.

The user will be informed of this error situation with each complete call up until the transactions are correct. If you limit the volume of data, the check calculation will be turned off, unless it is limited to one account.

Transaction development transactions with posting keys that are not allocated to transaction development areas will not be included in the sums used for comparisons with the account balance. They will not be taken into consideration even during generation of account balances from the sum of the development transactions. They do flow into the control values, however. Unlike the other transaction developments, the lines with the posting keys that have not been validated will be shown directly under the respective transaction to allow for better traceability.

Yet another check calculation relates to the percentages listed and is performed depending on the selection criteria chosen. A warning will be issued if the sum of participations in a company exceeds 100% or drops below 0% (more disposals than carry forwards and additions). This check for plausible percent values is not only performed for the end of the current period, but also for all of the intermediate deadlines (e.g. the date for group company disposal).

In addition, the system will rule out two shareholding transactions with different posting keys from having the same transaction date, due to the fact that the order in which they should be processed would be unclear. A special case of deconsolidation is the exception, namely if a company's parent leaves the group of companies. Then, a disposal and an addition that have the same date may be entered in for the subsidiary.

The display of the shareholding contains attributes for the group and the consolidation voucher. These attributes will be filled with the respective consolidation functions for the change in the shareholding. This makes it possible to determine whether a shareholding transaction has already been processed and how it has been processed. It is impossible to answer these attributes manually. The same applies to importing, copying, carry forward, etc. A message will be issued that says that capital consolidation needs to be repeated or deleted if there is a subsequent change in one or more of the shareholdings at one of the lower levels following capital consolidation. The voucher number entered will only be deleted for the records that have changed.

6.2 Individual Record Application

The action menu in the overview will bring you to the individual record application GESGESE. The key fields period, type of data and parent company must be specified clearly in advance and cannot be changed later in the individual record application.

Image: Individual record for shareholding transactions GESGESE

Special fields:

[Chart of Accounts and Account]:
The account number has to be entered to start with. Shareholding transactions can only be maintained in accounts that have the account tag 'B'. Only these will be shown in the field selection. The respective chart of accounts is already determined by specifying the type of data and company and will only be displayed. The entry tag in the account master will be evaluated when entries and manual changes are made. If the entry tag for the period tag of the current period ('Y', 'Q' or 'M') has not been placed, no entries or changes will be possible.
[Business Unit]:
If the account balances are assigned to business divisions, then each and every shareholding transaction can be allocated to a business unit of the parent company. Validation of the account balances and shareholding transactions takes place for each business division.
[Transaction Date]:
In most cases, the transaction date only has the function of documenting a change in the shareholding. With increases in capital (BSL '08' without specifying the percent values), however, the shareholding transactions will be compared with the same transaction date during initial consolidation. When entering a new development transaction, the transaction date should not be preset. This is an optional (white) input field that no entry must be made in. If it remains blank, the default value will be stored when you press save, if: a) it is the first day of the current business year, it is a carried forward transaction according to the transaction development column of the posting key or b) the last day of the current period with all other posting keys. In addition, the system will check to make sure that the transaction date is not more recent than the last day of the current period.
[Posting Key]:
The posting key characterizes the type of the shareholding transaction (e.g. carry forward, addition, disposal). Furthermore, the posting key controls what function of the capital consolidation a change in the shareholding processes (first consolidation with BSL '02', '04', 08 (capital increases without specifying percent values) and '09', deconsolidation with BSL '03', capital reduction (without specifying percent values) with BSL '10'). With the shareholding transactions, there are only posting keys at the company level, but not any with the BSL tag 'K' for group, due to the fact that no report for a "participation transaction development" is currently possible in IDL Konsis. Consolidation postings in participation accounts contain a posting key for the fixed asset transaction development.
Like the posting keys for fixed asset transactions, the posting keys for shareholding transactions are divided into transaction development areas for cost of acquisition and value adjustment. The posting keys '05', '06' and '07' have been assigned to the area of value adjustment. In addition, new posting keys for automatic carry forward ('11') and conversion differences ('14', '15') have been defined. As a result, the shareholding can also be maintained synchronously with the fixed asset transaction development even in the event of value adjustments. Shareholding transactions for value adjustments are not allowed to contain any changes in percentages.
[IC Company]:
IC company refers to the subsidiary in which a shareholding is held. It is possible to record participations in one's own self (company = IC company). This type of entry can be necessary for IFRS statements. The message that appears in this case is issued as a warning.
[IC Business Unit]:
If the company financial statements are managed according to business units, each and every individual shareholding transaction can be allocated to a business unit of the subsidiary by entering an IC business division. With capital consolidation (automated and manual), the IC business divisions may be treated separately, therefore segmental reporting is possible at the group level.
[Conversion rule, Exchange rate, Date the exchange rate takes effect*]:
If the local currency deviates from the group currency, then the conversion rule can be used to control the rate of exchange that the shareholding transaction should be converted at. If the conversion rule 'VK' (preset rate of exchange) is entered, then the exchange rate and the date at which this exchange rate takes effect must also be entered. If this conversion rule is not entered, conversion will take place according to the controls in the account conversion rule (KTOUAW) or per posting key via the table BSLUAW. In the event that a participation is held in a foreign currency (e.g. book value of the shares in a fund), the resulting currency conversion effects can be entered using the posting key '13' (without specifying percent values) as a shareholding transaction.
[Value KW*]:
If the local currency is the same as the group currency, the value LW will automatically be entered as the value KW. Otherwise, this field will only contain the currency conversion. Exception: With the conversion rule 'VKW' (preset group currency), the value KW has to be entered.
[Capital %, Votes%, Result%]:
The percentages must be entered with every change in the participation ratios. Even if the shareholding is differentiated according to business units, the participation share in the legal entity (subsidiary) has to be entered. Example: Two participations in the same subsidiary, but in different IC business units do not amount to a sum of 160%, but rather only 80%. With negative participation values (credit), the percentages have a negative effect. Generally, the same percentage is entered in all three fields. In calculating participation and capital consolidation, however, only the capital percentage is of importance. The result percentage is only used in calculating the share of annual profit or loss. The vote percentage currently has no function in IDL Konsis.
In certain cases (e.g. following several additions and disposals with significant deviations in the exchange rate) it has been possible for the participation book values to be zero or even smaller although the participation percentage was of course positive. The shareholding was then interpreted as a negative percentage and thus caused error messages. For this reason, the sign of the percentages was detached from the debit/credit tag of the participation values. In the future, the percentages must always be entered together with the sign, in other words, a negative percentage has to be entered for participation disposals. However, a warning will be issued, if the sign of the percentage does not match the debit/credit tag of the participation value. All of the existing shareholding transactions will be adjusted accordingly by the release conversion program. The check of shareholding transactions in a subsidiary for entire sums that make sense in the percentage values takes place as follows:
  1. The participation percentages are checked closely with respect to the one parent company specified in the record that is currently being worked on. This means that an error message will be issued during maintenance of shareholding transactions that result in participation levels in excess of 100% or smaller than 0%. This transaction urgently needs to be corrected by the user and cannot be stored.
  2. This check is also performed as strictly as in point 1 with respect to a specified group of companies in the overview (GESGES), in other words with respect to all of the parent companies contained in this group of companies. This check is also performed in the individual record application (GESGESE) with respect to the group/sub-group listed in the overview (GESGES). The main difference is that determining a group of companies is optional in GESGES. This check will not be performed if no group of companies has been entered.
  3. Globally speaking, in other words across all of the parent companies, the check will be performed just like before. In this case, a warning that can be ignored will only be issued if the threshold of 100% is exceeded or comes in below 0%. Nevertheless, this warning will not be issued if an error has already been recorded with respect to one of the first two aspects.
[Increased Revenue Account]:
In the event of increased revenue or a decline in revenue with a participation disposal (with the posting key 03), an account must be specified for posting it. Due to the fact that the increased revenue/decline in revenue account for a merger can also be a balance sheet account, this account will no longer be limited to a BS-profit + loss tag with an account for disposals and mergers. The user can thus decide in favor of a balance sheet or profit + loss account with the disposal and merger as an increased revenue/decline in revenue account.
[Increased Revenue Posting Key]:
The transaction development of the BSL will be filled with the transaction development for this account. For this reason, this entry is only possible in conjunction with the entry of the account. For this case of a merger, a new posting key usage tag B16 (merger) has been introduced. This new posting key usage tag B16 can only be entered for posting keys of the transaction development type B (participation). This can only be entered in GESGES if a merger date and merger company have been entered for the IC company in the set of master data for that company.
[Amount of Increased/Reduced Revenue]:
The amount of an increase or decrease in revenue is entered here in the local currency with a participation disposal (with the posting key 03) as well as its debit/credit tag. This attribute will be shown in a column in the GESGES overview. The previous input field for increased/decreased revenue in group currency will become a display field in the individual record application GESGESE. If WKZ-LW = WKZ-KW, then the LW value that has been entered will be immediately accepted as a KW value. Otherwise, the KW value will be set to zero if the LW value changes.

* The entries in the fields for parallel currency function in the same manner.

Shareholding transactions that were not created using automatic functions are not allowed to be changed manually or deleted unless that person has special access rights. This applies to carry forwards from the previous period (BSL '01') and compensation transactions from the currency conversion (BSL '00' and '12'). These posting keys will not be offered in the field selection either.

There is a better way to display how a participation has developed by entering a period interval on a period of time. In this view, the carry forwards will be suppressed, so that only the actual changes will be made visible. When working with interim financial statements, these will be suppressed in order to prevent multiple display.

Furthermore, an input field for the language has been added that can be used to set the language of the translations of the accounts and posting keys displayed.

6.3 Further Actions

7 Capital Transactions (KAPBEW)

7.1 Overview

When called up directly, the application KAPBEW offers the respective current overview of the capital transactions of one or more companies or groups for the respective type of data selected and current period. In this selection area, you can decide what sortation order and selections you would like to have. These are each equipped with the appropriate preliminary and final sums. By making the entry '%' in the "transaction development" field, all of the transactions for capital, accrual and individual transaction developments will be displayed.

If an account has been allocated to a different transaction development than before, this account might contain data (postings, transactions) that has an incorrect posting key. This data was not shown before and therefore could not be deleted either, but possibly resulted in errors during other types of processing (e.g. currency conversion) that could not be corrected all that easily.

For this reason, the overview for transactions (KAPBEW) has been expanded to include the ability to select data by entering "transaction development = '%'". Then, the data stored in the database will be shown independent of the transaction development of the account and can also be deleted.

Image: application KAPBEW

Special selection possibilities:

From period (abPer)
If a valid entry is made in this field, the complete development of the transactions during all of the periods of the interval that has been entered will be shown, whereby automated carry forwards will be overwritten.
Transaction Development Column
This allows for the transactions in a certain transaction development column (e.g.carry forward, addition etc.) to be selected.

During the call up through the line action from the account balances KTOSAL (via the action menu or by double-clicking onto the transaction development tag K), you will have immediate access to the specific details of the account that you have selected. In this case, any difference between the sum of the capital transactions and the account balance shown in a line might be displayed with a red background.

Capital transactions can be maintained at both the company and the group chart of account level. If the tag has been entered for maintenance of the capital transactions for the current type of data and period in the applications FACSPI and ABRSPI, then a check calculation is performed between the capital transactions that have been selected and the account balances or consolidation postings in accounts with the development tag K during every complete call up of the overview for the current type of data and period. The check sums will be displayed in a separate line in the table. Differences for each account will be shown in the message window and can be printed out from here.

With every complete call up, the user will be informed of the error situation until the transactions are consistent. If you limit the volume of data, this check evaluation will be turned off, unless it is limited to one account.

Validation of the transfer columns (the sum of all transfers must result in a 0) takes place including consideration of the statistical accounts.

Accurate capital transactions are the prerequisite for producing a transaction development report with the help of IDL Konsis.

7.2 Individual Record Application

Accurate capital transactions are the prerequisite for some of the processing that takes place later in IDL Konsis: Currency conversion to historical, amortized average exchange rates for the capital accounts is only possible if capital transactions are entered. They are also the prerequisite for creating a capital transaction development with IDL Konsis and form the basis for calculating foreign shares.

Due to the fact that the account balance of the JÜ account (account tag E) is formed automatically as a calculated value, the capital details on it will also be formed automatically if the tag for maintenance of KAPBEW has been placed in FACSPI and ABRSPI. If the JÜ value changes, the existing capital transactions will be deleted and the new value will be entered. With the help of this solution, the details will be entered automatically after all types of possible processing (import, type of data, carry forward, currency conversion, etc.).

The capital transactions must be entered manually or imported for all of the other capital accounts. The Menu KAPBEWE for manual entry can be accessed via the action menu in the overview. The key fields period, type of data and company must already be specified clearly in the overview and cannot be changed anymore in the individual record application.

Image: Individual record for the capital transaction development transaction KAPBEWE

Special fields:

[Account number]:
The account number is the first field that can be filled in. Capital transactions can only be maintained for accounts that have the transaction development tag K. Furthermore, only these will be shown in the selection for this field. The respective chart of accounts has already been defined by specifying the type of data and company and will only be displayed. The entry tag in the master account will be evaluated when entries or manual changes are made. If the entry tag for the period tag for the current period ('J', 'Q' or 'M') has not been placed, no entries or changes will be possible.
[IC company]:
Entries are only allowed for accounts that have the account tag I or J simultaneously. If there is data that includes the IC company, validation against the IC account balances will also be performed. If the sum of transactions for an IC company does not match the corresponding sum of the IC account balances, this will be reported like differences in account balances.
[Business Unit / IC Business Unit]:
If the company financial statements are maintained according to business units, then each and every capital transaction can be allocated to a business unit by entering a business unit. Validation between account balances and capital transactions takes place for each business unit. Furthermore, entry of the business unit is subject to a check against the allocation of business units to companies via the table GESUBR
[Transaction date]:
In most cases, the only function of the transaction date is to document the date of a change in capital. With increases in capital (BSL '02'), however, the capital transactions will be compared with the shareholding transactions that have the same transaction date as part of initial consolidation. The transaction date will not be preset when a new development transaction is entered. This is an optional (white) input field that must not be filled out. If it remains blank, it will be issued with a default value when save is pressed and this will be: a) the first day of the current business year if this is a carry forward transaction according to the transaction development column of the posting key or b) the end of the current period with all other posting keys. In addition, the system will check to make sure that the transaction date is not more recent than the last day of the current period.
[Posting key]:
The posting key characterizes the type of the capital transaction and controls which column of the equity transaction development the transaction will appear in. The debit/credit tag will be placed depending on the posting key. A negative value must be entered if the debit/credit direction chosen deviates from the posting key. The minus sign will be eliminated and the debit/credit tag will be reversed.
[Conversion rule, exchange rate, effective date of exchange rate*]:
If the local currency deviates from the group currency, then the conversion rule can be used to control the rate of exchange that should be used for the capital transaction. When the conversion rule 'VK' (predetermined rate) is entered, the exchange rate and the date it takes effect on must also be entered. Conversion will take place according to the account conversion rule (KTOUAW) or for each posting key via the table BSLUAW if the conversion rule is not specified.
[Value of group currency*]:
If the local currency is the same as the group currency, then the value LW will be automatically transferred over as the value KW. Otherwise, this field will only be occupied by the currency conversion. Exception: With the conversion rule 'VKW' (predetermined group currency), the value KW has to be entered.

* The entries in the fields for parallel currency function in the same manner.

Capital transactions generated using automatic functions cannot be changed manually or deleted unless that person has special access rights. This applies to the carry forwards from the previous period (BSL '01' and '17') and compensation transactions from the currency conversion (BSL '00' and '12'). These posting keys will also no longer be offered in the selection field.

7.3 Further Actions

8 Provision Transactions (RUEBEW)

8.1 Overview

When accessed directly, the application RUEBEW offers you a respective current overview of the provision transactions of one or more companies or groups for the type of data and current period you have selected. Inside this selection area you can decide what sorting sequence and what selections you would like to use that are equipped with the respective interim and final summation. If you enter '%', all of the transactions for capital, accrual and individual transaction developments will be shown.

Image: Application KAPBEW

Special selection possibilities:

From period (FromP)
Making a valid entry in this field will provide you with the complete development of the transactions over all of the periods contained in the interval chosen, whereby automated carry forwards will be overwritten.
Transaction development column
This allows you to select the transactions from a specific transaction development column (e.g.carry forward, addition, etc.).

The details of the respective account that has been selected will be displayed immediately with a call up via the line action from the account balances KTOSAL (using the action menu or by double-clicking onto the transaction development tag R). If there is a difference, it will be shown in red in a line between the sum of the accrual transactions and the account balance.

Provision transactions can be entered at either the company or the group chart of account level. If the tag for maintenance of accrual transactions has been placed for the current type of data and period in the applications FAC and ABR, a check calculation will be performed on the selected accrual transactions and the account balances or consolidation postings in accounts with the transaction development tag R with every complete call up of the overview.

The following will be checked:

The check is performed on all three currencies. The check sums are shown in a separate line in the table. Differences for each account will be shown in the message window and can be printed out from there. The user will be made aware of the error situation with each complete call up until the transactions are correct. If you limit the volume of data, the check calculation will be stopped, except for limits to an account.

Correct accrual transactions are the prerequisite for creating an accrual transaction development with IDL Konsis.

8.2 Individual Record Application

Accrual transactions at the company financial statement level are usually read in relatively automatically, whether this is via an interface to a finance system or an Excel entry form. Accrual transactions on consolidation postings are created automatically during the consolidation function. If accrual transactions are to be entered manually or existing ones are to be processed, this is done using the Individual record application RUEBEWE that can be accessed via the action menu in the overview. The key fields period, type of data and company must already be preset in the overview and cannot be changed anymore in the individual record application.

Image: Individual record for an accrual transaction development transaction RUEBEWE

Special fields:

[account number]:
The first field that can be filled in is for the account number. Accrual transactions can only be entered for accounts that have the transaction development tag R. Furthermore, only these will be shown in the selection for this field. The respective chart of accounts is already predetermined by the type of data and company and will only be displayed.
[IC company]:
This entry is only allowed for accounts that simultaneously show the account tag I or J. If data that includes entries from the IC company is added, validation will take place against the IC account balances. If the sum of the transactions for an IC company does not match the corresponding sum of the IC account balances, this will be reported like differences in account balances.
[Business Unit / IC Business Unit]:
If the company financial statements are managed according to business units, then each and every individual accrual transaction can be allocated to a business unit by entering a business unit. Validation between account balances and accrual transactions is performed for each business unit. Furthermore, the entry of the business unit is subject to a check against the allocation of business units to companies via the table <GESUBR>
[Transaction date]:
The transaction date in the accrual transactions only has the function of documenting a change in the accrual.
[Posting key]:
characterizes the type of the accrual transaction and controls which column of an accrual transaction development the transaction appears in. The debit/credit tag should be placed depending on the posting key. A negative value must be entered if a debit/credit direction that deviates from the posting key is chosen. The minus sign should be eliminated and the debit/credit tag should be reversed all at once.
[Conversion rule, exchange rate, effective date of exchange rate*]:
If the local currency deviates from the group currency, then the conversion rule can be used to control the exchange rate that the accrual transaction should be calculated at. If conversion rule 'VK' (predetermined exchange rate) is entered, then the exchange rate and the date that this exchange rate takes effect on must also be entered. If this conversion rule is not entered, then conversion will take place via the account conversion rule (KTOUAW) or per posting key via the table BSLUAW.
[Value of group currency*]:
If the local currency is the same as the group currency, then the value LW will be automatically used as the value KW. Otherwise, this field will only be used for currency conversion. Exception: The value KW must be entered with the conversion rule 'VKW' (predetermined group currency).

* The entries in the fields for parallel currency work the same way.

Accrual transactions that are created using automatic functions cannot be changed manually or deleted unless this person has special access rights. This applies to the carry forwards from the previous period (BSL '01') and compensation transactions from currency conversion (BSL '00' and '12'). These posting keys will not be offered in the selection field either.

8.3 Further Actions
Letzte Änderung: WERNER 30.04.2012 14:19