Transactions in Companies 'Financial Statements'

1 View in the Company Financial Statements Monitor (CFSMNR)

Consistent development transactions in the company financial statements are a prerequisite for correct consolidation as well as for the creation of mirror reports with IDL Konsis.

The transactions in the company financial statements are recorded, processed, and tested on mirrors if the indicators for the maintenance of development transactions are set in the FCTDEV for the current data type and PRDDEV for the period. Then the mirror will be displayed in a column of the CFSMNR monitor.

2 General

In the account balances, the state of the development transactions is shown per account in the "Transaction development SPI" column. By means of the action menu or by double-clicking on the mirror identifier, the targeted branching takes place for the respectively selected account. Also the flags (e.g. amortization current year "D" for voting of the transactions) link by double-clicking. If necessary, a red difference will appear in a column between the sum of the development transactions and the account balance. Verification shall be carried out in all three currencies (LC, GC, PC). The user is alerted to the error situation at each complete call until the transactions are coherent. The control values are presented in a separate row of the table (if there are several business units per business unit).

Development transactions with posting keys that are assigned to unsampled transaction development areas are not included in the totals for reconciliation with the account balance. They are also not taken into account when generating account balances from the sum of the development transactions. But they flow into the control values. For all Transaction developments (except SHRPAR), the transactions not to be tested are identified in their own block under the test block for the sake of clarity.

Development transactions can be locked and unlocked separately for input.

Development transactions with reserved posting keys, which are automatically assigned by the applications for carry forward, calculating the current amortization current years or for currency conversion, may only be processed with special authorization.

The other Transaction developments (sorted by the nomenclature of the key field) are always displayed first, followed by the investment, share ownership, capital and reserve levels. The following chapters explain all Transaction developments/movements in order:

3 Development Transactions (DEVTRN)

3.1 Overview DEVTRN

Customized Transaction developments can be set up in IDL Konsis. The transactions required for this are recorded and maintained in the DEVTRN application.

The DEVTRN application provides the current overview of the development transaction company of an option for the selected fact and period. By default, the application opens with the development transactions for the first Miscellaneous Transaction development. Entering '%' in the posting key Transaction development field displays all capital, reserve, and individual Transaction development transactions.

In the DEVTRN overview, the Selection area contains the following fields:

Group/TK

An entry of a group in this field results in the selection of development transactions of all companies belonging to the group companies (if the authorization is given).

Company/ Period/Fact

Company Constraint by amount, period and fact

SortOption

Selection of the sort order, which are each equipped with corresponding intermediate and final summation:

• GK for sorting by company/account
• IG for sorting by IC company/company/account
• KG for sorting by account/company
• SG for sorting by mirror report/ company/ account
• ZG for sorting by assigned group account/company.

Transaction development of the posting key

Individual Transaction development containment

By car. movements of capital

only relevant for Transaction developments with sample accounting (discontinued model). The transaction development areas made Transaction developments with sample accounting redundant.

Business unit

Business unit containment

IC Company+IC Business Unit

Narrowing according to IC-business unit or IC-company

from period

If the entry in this field is valid, the complete transactions are displayed over all the periods of the specified interval, the machine carries forward (except those of the initial period) being read over. The transactions are sorted by period. The current account balance is always displayed.

Posting key

Selection by posting key

Transaction development area

Selection by transaction development area

Chart of Accounts + Account

Chart of accounts and account selection

Associated Chart of Accounts + Account

Selecting according to the assigned chart of accounts and account

Position plan / Schema + Position

Selection by chart of positions and position

ex Beleg

Selects development transactions generated from postings of an upstream fact. When the data is transferred to the next fact, the initial document number and the fact on which this voucher was recorded are noted. This information is retained even in the case of subsequent transfers to next data types, i.e. also in the case of a change of chart of accounts or compression of business units.

voucher classification

Selection by document classification

ex Belegdatenart

Selects development transactions generated from postings of an upstream fact. When the data is transferred to the next fact, the initial document number and the fact on which this voucher was recorded are noted. This information is retained even in the case of subsequent transfers to next data types, i.e. also in the case of a change of chart of accounts or compression of business units.

Language

Display the description etc. in a next language

3.2 Individual Record Application SPIBEWE

Development transactions are usually read automatically, as much as possible, either via an interface to a financial system or via an Excel form. If development transactions are to be captured or edited manually, this is done via the Individual Record Application SPIBEWE, which can be accessed via the star symbol in the upper right icon bar (re-create data) or via the pen symbol of the icon bar in the context menu (edit data). The key fields Period, fact company, Date and Transaction development must be clearly defined in the Selection area and can no longer be changed in the individual record application.

The following fields are available in the individual record application:

Account number

Only the accounts corresponding to the previously selected Transaction development will be offered in the selection. During entry and manual modification, the account master journal identifiers are evaluated. If the journal identifier for the period identifier of the current period ('M', 'Q' or 'J') is not set, no entry or change is possible.

Business unit

If the company financial statements are differentiated according to business units, each individual development transaction must be assigned to a business unit by specifying a business unit. Testing between account balances and development transactions shall be carried out per business unit. Furthermore, the indication of the business unit is subject to the test against the assignment of business units to companies via the COBUALC table.

Transaction Date

When a new development transaction is registered, the movement date is not pre-assigned. It is an optional (white) input field and does not need to be entered. If it remains blank, it will be assigned a default value at the time of payment: a) with the first day of the current financial year if it is carried forward according to the posting key's save transaction development column; or b) with the last day of the current period for all other posting keys. In addition, it is checked that the movement date must not be younger than the last time of the current period.

Posting key

The posting key characterizes the type of development transaction and controls in which column of the individual Transaction development the transaction appears.

IC Company/ IC Business Unit

This specification is only permitted for accounts with IC rip type "I". Company If data are recorded with the indication of the IC account balance, testing against the IC values is also carried out. If the sum of the transaction company for an IC account balance does not correspond to the corresponding sum of IC values, this shall be reported.

Value in local currency, conversion rule, exchange rate, effective date Exchange rate*

If the local currency is different from the group currency, the conversion rule can be used to control the rate at which the development transaction is to be converted. If you specify the conversion rule 'VK' (default rate), you must also specify the exchange rate and the cut-off date for this rate. If the conversion rule is not specified, the conversion is done via the account (ACCNVR) or the accounting key conversion instruction (PSTKEYCNVR).

Value of Group currency*

If the country and group currency are the same, the value LW is automatically taken over as the value KW. Otherwise, this field is only occupied by the currency conversion. Exception: For the conversion instruction 'VKW' (default group currency), the value KW must be entered.

Posting text

a brief explanation of each transaction can be entered here.

Upstream merger company

during the input, it is checked whether the input entry company is also an outgoing message (according to the master data in CODT), and whether the receiving company corresponds to the currently processed message. All companies that have such an entry in the company's master are offered in the selection. Next information on the automated IDL Konsis Role upstream merger can be found in the document MGRFS.

*The input in the fields for parallel currency works analogously.

Development transactions created by automated Roles may not be changed or deleted manually without a special correction.

3.3 More Actions and Branches in the Context Menu

• You can copy selected rows to another mass copy, period or fact by clicking the button company. Chart of accounts and local currency (according to the company) must not change. The mass copy generally checks whether such data already exists in the target environment. If it does, a warning message is issued. The user can then decide whether to add the copied data or cancel the copy operation.
• The mass update button can be used to change all the keys listed in the entry mask simultaneously for several selected rows.
• By switching to the form entry, one arrives in an input mask, in which an amount, a posting key and, optionally, next relevant data can be entered for each account in a detection line. Confirming the entry opens a next save entry line, which accepts the newly entered transactions from IDL Konsis. This action is provided with half a globe, since it acts either line-by-line or globally depending on the marking.
• There are next branching possibilities for company financial statements + monitor, account balances, IC account balances, postings, and mirror definition applications.

4 Fixed Asset Transactions (FATRN)

4.1 Overview FATRN

The application FATRN gives the respectively current overview of the fixed asset transactions of one or more companies or groups for the respectively selected fact and current period.

The following tests shall be performed (a) or may be performed (b):

• (a) the consistency of the sum of fixed asset transactions per account with the account balances on accounts with Transaction development mark 'A'
• (a) the consistency of the sum of fixed asset transactions on posting keys for transaction development columns with usage tag RP. The sum of the respective columns must be zero for each company.
• (a) the consistency of the sum of fixed asset transactions on posting keys for transaction development columns with usage tag MG. The sum of the respective column must be zero across all group companies.
• (a) Consistency of the charts of accounts and accounting types of the Asset Account (COADFN) and fact (FCT)
• (b) the consistency of the sum of fixed asset transaction development column for the usage tag RC and the Transaction development/profit and loss reconciliation 'D' (current depreciation) flag with the sum of the account balances on accounts with account flag 'D'

4.2 Individual Record Application ANLBEWE

If fixed asset transactions are captured or edited manually, this is done via the single application ANLBEWE, which can be accessed via the star symbol in the upper right icon bar (re-create data) or via the pen symbol of the icon bar in the context menu (edit data). The key fields Period, fact, and company must be clearly defined in the Selection area and cannot be changed in the single-sentence application.

In contrast to the development transactions (see above), the following additional fields are available in the single-set application:

Fixed asset object

Unlike the other development transactions, the details of fixed asset transactions is per fixed asset object and not per account. By default, only one fixed asset object is created in the company financial statement per account, but multiple objects per account are possible. Fixed asset transactions can only be made on accounts with Transaction development flag 'A'.

You cannot explicitly specify the debit/credit flag for the values. Rather, it is automatically detected and set according to the attributes of the specified posting key in the TRNDEVDFN in the BSL table according to the following rules:

1. If a default debit/credit flag is assigned to the posting key used, it is used.
2. If the posting key is in the transaction development area 'A' (Cost), Debit is used.
3. If the posting key has the transaction development area 'B' (amortization current years), credit is used.

When you enter negative values, the minus sign is eliminated and the debit/credit flag is rotated at the same time. This also applies to changes to existing rates.

5 Shareholding Transactions (SHRPAR)

5.1 Overview SHRPAR

The SHRPAR application provides the current overview of the shareholding/participation company of one or more companies for the selected fact and period. When invoked via the line action from the account balances ACBAL (via action menu or by double-clicking the IC-type=B), the targeted details for the respectively selected account takes place immediately.

The following tests shall be carried out:

• Total participation company on an amount greater than 100%
• Total participation company on an amount less than 0%
• Coherence of the sum of the equity movements on posting keys for the transaction development columns with usage tag RP. The sum of the respective columns must be zero for each company.

The overview of the shareholding contains, among other things, the specification of the consolidation voucher with which the transaction was processed in the current period (except for machine carries forward which are not "non-cash additions"). The voucher entries are set by the respective consolidation functions. This enables you to determine whether a shareholding transaction has been processed and, if so, with which consolidation document. You cannot enter the document entry manually, nor can you import, copy, or carry forward. If one or more shareholding transactions are changed after Capital consolidation, the registered document number is deleted. If transactions are again upcoded by a lower fact, the voucher entries are retained for constant amounts and percentages; if changes are made, the voucher entry is deleted. The Capital consolidation shall be performed again.

5.2 Individual Record Application GESGESE

The action menu of the overview allows you to access the individual record application GESGESGESE. The key fields Period, fact and Parent Company must be clearly defined in the overview and cannot be changed in the individual record application.

In contrast to the development transactions (see above), the following additional fields are available or have to be treated differently in the individual record application:

Transaction date

The movement date is a must field in the shareholding transactions and must be actively recorded.

Posting key

The posting key (especially via the usage tag of the posting key) controls which type of Capital consolidation is to be carried out (e.g. first consolidation in the case of BSL-Verw.Kz B02, B04, B08, B09 and B10, deconsolidation in the case of BSL-Verw.Kz B03, upstream merger in the case of Verw.Kz B16).

Capital%, Voice%, Result%

Only the percentage of capital is relevant for the determination of the shareholding and the Capital consolidation. As a rule, the same percentage is entered in all three fields. The percentage of the result is used only when calculating the pro rata annual profit or loss for minority interests. The percentage of votes has no Role. In the differentiation of shareholding by business unit, the shareholding in the subsidiary must be disclosed here. Example: Two participations in the same subsidiary (own share 80%), but in different IC business units, the total is not 160%, but only 80%.

Value of TC and currency group

If an amount is entered in transaction currency, a currency code is required.

Result Account

In this case, in the event of an excess or reduced income on a divestiture (posting key with VerwKz. B03) an account for its posting. Since the surplus/deficit account for the upstream merger can also be a balance sheet account, in the case of disposal and upstream merger the account is no longer restricted to BilGuV license plates. The user can therefore opt for a disposal or upstream merger balance sheet for an additional or lower income account.

ResultLW

This is the amount of excess or deficit revenue in local currency on a divestiture (with posting key with deferred tax B03).

Score. BSL

The Transaction development of the BSL is assigned the Transaction development of the surplus or deficit account. The input is therefore only possible in conjunction with the input of the account. A new posting key usage tag B16 (upstream merger) has been introduced for the case of upstream merger. This new posting key usage tag B16 may only be entered for Transaction development type B (participation) posting keys. Company This may only be entered in SHRPAR if a merger date and a merger company have been entered for the IC-entry in the company master record.

Zug-Ges

Intra-group sale access company

VerschmGES

The merging company must be cared for in order to be able to distinguish several situations, if necessary.

6 Capital Transactions (CAPTRN)

6.1 Overview CAPTRN

The application CAPTRN provides the current overview of the capital transactions of one or more companies or groups for the selected fact and current period.

Consistent capital transactions are a prerequisite for some subsequent processing in IDL Konsis: Only if capital transactions are properly maintained can a currency conversion be made to the historical, updated average rate for the capital accounts. They are also a prerequisite and the basis for the calculation of the foreign shareholding.

Since the account balance of the JÜ account (account flag E) is automatically generated as a computational variable, the capital raising is also automatically set for this purpose if the switches for maintaining the CAPTRN are set in the applications FCTDEV and PRDDEV. If the JÜ amount changes, already existing capital transactions are deleted and reset.

The following tests shall be carried out:

• Consistency of the sum of capital transactions per account with the account balances on accounts with Transaction development flag 'K'
• Consistency of the sum of capital transactions on posting keys for transaction development columns with usage tag RP. The sum of the respective columns must be zero for each company.
• Consistency of the sum of capital transactions on posting keys for transaction development columns with usage tag MG. The sum of the respective column must be zero across all group companies.

6.2 Individual Record Application KAPBEWE

If capital transactions are captured manually or if existing ones are edited, this is done via the individual record application KAPBEWE, which can be accessed via the star symbol in the upper right icon bar (re-create data) or via the pen symbol of the icon bar in the context menu (edit data). The key fields Period, fact, and company must be clearly defined in the Selection area and cannot be changed in the individual record application.

In contrast to the development transactions (see above), the following fields are not available in the individual record application:

By car. movements of capital

Capital transactions created by automated Roles may not be changed or deleted manually without special permission. This applies to carries forward from the previous period (BSL Verw.Kz. V and ZNR) and compensation movements from the currency conversion (BSL Verw.Kz. K and U). These posting keys are also not offered in the field selection.

7 Provision Transactions (PRVTRN)

7.1 Overview PRVTRN

Company The PRVTRN application provides a direct call with the current overview of the accrual movements of one or more groups for the selected fact and current period.

The following tests shall be performed (a) or may be performed (b):

• (a) the consistency of the sum of the account movements with the account balances on accounts with Transaction development mark 'R'
• (a) the consistency of the sum of the movements on posting keys for transaction development columns with usage tag RP. The sum of the respective columns must be zero for each company.
• (a) the consistency of the sum of the movement of posting keys in the reserve for transaction development columns with usage tag MG. The sum of the respective column must be zero across all group companies.
• (a) the consistency of the charts of accounts and accounting types of the reserve account (COADFN) and fact (FCT)
• (b) transaction development column the consistency of the sum of the deferral movements for the usage tag RC and the Transaction development/RC reconciliation 'Y' (resolution) and 'Z' (feed) flags with the sum of the account balances on accounts with account flags 'Y' and 'Z'.

7.2 Individual Record Application RUEBEWE

If you manually record accrual movements or edit existing ones, this is done via the individual record application RUEBEWE, which can be achieved via the star symbol in the upper right icon bar (re-create data) or via the pen symbol of the icon bar in the context menu (edit data). The key fields Period, fact, and company must be clearly defined in the Selection area and cannot be changed in the individual record application.

In contrast to the development transactions (see above), the following fields are not available in the individual record application:

By car. movements of capital

Reserve motions created by automated Roles may not be changed or deleted manually without special permission. This applies to the carries forward from the previous period (BSL) with admin. V) and compensation movements from the currency conversion (BSL with admin. K and U). These posting keys are also not offered in the field selection.

8 Summary of Special Features for Specific Transaction Developments

See Summaries for specific mirror types.