Currency Conversion

1 Currency Conversion

A currency conversion is always required when a subsidiary results in a different local currency for the group currency of the group. In order to allow for consolidation at a later stage, this local currency has to be converted into a single group currency. For reporting and other evaluation purposes, it is possible to convert the group currency into a uniform parallel currency in addition to this.

1.1 Adjusting Country, Group and Parallel Currency

The local currency of a company is in the company master (short word: CODT). The group and parallel currency is in the group / groups (short word: KTK) must be entered uniformly for all groups. The same group and parallel currency plates are also used for each user in the 'startup data + authorizations application (short word: STUPDTATH) should be deposited.

1.2 Activating the Currency Conversion

In the respective fact (short word: FCT) can be activated or deactivated via the 'Currencies' field via the following switch settings.

Local currency ( - )

Conversion is performed at this switch setting when the switch is started manually, but the system does not perform any tests. There is no currency conversion in the company financial statement monitor. A report evaluation only processes the local currency values, insofar as group and parallel currency values are available, these are ignored. A fact on which consolidation is performed must not have the button inserted on local currency (-), as the group currency is not evaluated, even in case of pure euro groups.

Country and group currency ( K )

This switch position completes the currency conversion, but only the country and group currency are tested and processed in reports.

Country, group and parallel currency ( P )

This setting converts both the local currency into the group currency and the group currency into the parallel currency and trials. The reports process all currencies.

2 Currency Conversion Parameters

The application Currency conversion parameter is either via the company financial statements + monitor (Short word: CFSMNR) by double-clicking in the column 'currency conversion' or directly via the short word 'FXCN' in the short word field. To create a currency conversion parameter, the following parameters must be stored:

Company

Entry of the company for which the currency conversion is to be performed

Period

Entry of the period in which the currency conversion is to be performed

V-Period

The last annual financial statement period (period indicator = 'J') is to be entered here, intra-year financial statements are not permitted

Fact

The fact at which the currency conversion must be made is set here

V-Fact

Nothing is normally entered in this field. Only if there is a change in the data types, and the previous financial statements insist on a different fact, a different fact for the calculation should be set here. Insofar as a different fact was presented, the carry forward automatically sets the V-facts.

2.1 Conversion Procedure

The 'currency conversion header' application allows you to define a so-called 'conversion master' for each individual foreign currency company in the system. IDL.KONSIS.FORECAST defines a conversion master as the mapping of conversion rules (UAW) to each account in the chart of accounts, depending on mirror attributes. This is done depending on the conversion method chosen. The tables below show the standard assignment of individual account groups with conversion rules in IDL.KONSIS.FORECAST. The Modification column provides options for setting up the account conversion rules for individual accounts differently.

'MCF' - Modified Cash Flow

In the standard specification, the income statement is calculated using the average rate for the corresponding period in accordance with its period perspective, which is balance sheet converted using the closing rate. In addition, the fixed assets and the equity can be historically converted with the updated average rate (FDK) by means of corresponding modifications. This prevents exchange-related differences in fixed assets and Capital consolidation.

The development transactions are calculated differently to the other conversion methods for the 'PAV', the delta for converting the account balance to the closing rate is balanced with the posting key with usage tag 'U' for conversion difference.

'MMW' - Modified with monthly weighted rates

Under this method of conversion, P+L statement accounts will be assigned the conversion rule 'foreign currency translation (FDK)' as a standard because they are to be converted at monthly weighted average rates. All newly created P+L statement accounts are automatically filled in with 'FDK'. In addition, the fixed assets and the equity can be historically converted with the FDK (updated average rate) by means of corresponding modifications, which prevents the translation-related differences in the fixed assets and Capital consolidation. Without modifications, all balance sheet accounts are converted to closing rate using the same method.

'MST' - Modified Closing Date Exchange Rate Procedure

In the standard specification, the income statement is calculated using the average rate for the corresponding period in accordance with its period perspective, which is balance sheet converted using the closing rate. In addition, the fixed assets and the equity can be historically converted with the updated average rate (FDK) by means of corresponding modifications. This prevents exchange-related differences in fixed assets and Capital consolidation.

'MCB' - Modified time reference procedure (fixed assets and equity)

IDL.KONSIS.FORECAST also supports the modified time reference. The standard guidance converts fixed assets and equity historically, while the remaining assets and liabilities are converted at closing rate. In the income statement, expenses and income are converted at currency rate average per period by default.

'MZK' - Modified time reference procedure (equity)

In this procedure 'MCB' only equity capital is converted historically, fixed assets and other assets and liabilities are converted to closing rate. Expenses and income are translated using the currency rate average per period.

RST - Day-Only Exchange Rate Procedure

In the "pure" closing rate procedure, all positions of the annual financial statements, assets, liabilities, income, and expenses, are converted uniformly to the closing rate (CR). No translation differences arise here on the time review.

2.2 Exchange Rate Type

The exchange rate type is to be saved in the currency conversion parameter for the group and parallel currency. The following distinctions are made:

EMS central rate - Euro - ( E )

The E exchange rate (EWS central rate-EURO) is only converted in conjunction with the time reference 'CR' for closing rate. The balances are divided by the value of the exchange rate (e.g. EUR 1 = CHF 1.5154, i.e. the balances are divided by 1.5154). This conversion is a fixed and immutable rate, and the currency rate average per period that may be maintained is not used for the currency conversion.

Exchange rate as multiplier ( M )

The M exchange rate (average rate of previous procedure) can be used as a multiplicative average rate for the time reference 'CR', 'PAV' as well as 'MAV' (in the example. GBP 1 as at 31/12/2008 = EUR 1,24, i.e. the balances are multiplied by 1,24).

Course as a divisor ( R )

The R-course (average rate lt. Stock exchange listing, recursive price) can also be used as a divisor for the time reference 'CR', 'PAV' as well as 'MAV' (in the example. Euro 1 at 31/12/2008 = GBP 0,744596, i.e. balances divided by 0,744596).

2.3 Reference Company

The Reference company field is suitable for a uniform conversion of all companies in the group. If reference is made to another company in the field 'Ref.Ges.', all settings of the reference company apply equally to the referencing companies. These are:

• The conversion procedure for group and parallel currency
• The exchange rate type for group and parallel currency
• As well as the different difference accounts (KtoBilDiff, KtoGuvPosD and KtoGuVNegD) for

These fields enumerated above may not be completed when specifying a Reference Company.

2.4 Difference Accounts

KtoBilDiff

The currency conversion calculates all balance sheet accounts according to the account conversion instructions. The identical accounts are converted to the closing rate in deviation and the difference to the actual conversion and the calculation to the closing rate is posted to this account.

KtoGuVPosD

The currency conversion calculates all P+L accounts according to the account conversion instructions. The identical accounts are converted to the closing rate in deviation and the difference between these two calculations is posted to this account, insofar as the amount is positive.

KtoGuVNegD

The currency conversion calculates all P+L accounts according to the account conversion instructions. The identical accounts are converted to the closing rate in deviation and the difference between these two calculations is posted to this account, insofar as the amount is negative.

2.5 Controlling Object

If the difference accounts (KtoGuvPosD and KtoGuVNegD) in the account master data have an identifier for Controlling, a standard controlling object can be saved here. This controlling object also creates a controlling balance on the difference accounts.

3 Exchange Rates

The Exchange Rate Overview (Short word: FXRTE ) provides the user with an overview of all the closing and average rates stored in the system. Using the selection and sorting fields of the application, the exchange rate inventory can be evaluated according to various aspects, such as the settlement period, fact or currency. A maximum of nine events can be entered for the exchange rate. Each input is automatically assigned six decimal places.

The exchange rates are to be deposited per currency code with:

of the facts to be converted

e.g. I4 = Balance of trade II, conversion can take place on all data types (company and group chart of accounts) in which a currency conversion parameter and exchange rates have been deposited

the exchange rate type

e.g. exchange rate as divisor ( R ) - The different exchange rate types are described in the currency conversion head rates.

the temporal reference

e.g. 'CR' for closing rate

the closing date

e.g. '12/31/2014' - always enter the last day of a month here. Other dates can be entered, but are not taken into account by the currency conversion.

4 Posting Key Conversion Instructions

The 'posting key Conversion Instructions' application can be accessed by either the 'Currency Translation Parameters' application or by typing the 'PSTKEYCNVR' shortcut. In the posting key conversion rules, individual posting keys can be converted with a different conversion rule to the account conversion rule. The total of all transactions is then adjusted with a conversion difference to the conversion of the account, insofar as no historical conversion is carried out.

5 Account Conversion Rules

5.1 General Explanations

The account conversion rules application can be accessed from the Currency Translation Parameters overview or via the 'ACCNVR' short term. A green filing in the "UAW group currency" or 'UAW parallel currency' shows that the displayed conversion rule corresponds to the selected conversion method and has not been modified. If one or more cells are highlighted in yellow, there is a deviation from the selected conversion procedure from the currency conversion parameter. These deviations are not mistakes; they are only intended to emphasize the deviations to the user.

5.2 Definition of Account Conversion Rules

Account conversion rules are fixed parameters for the currency conversion. Currently the following account conversion rules are valid in IDL.KONSIS.FORECAST:

FDA - Time base method for investments

This setting is only used for accounts that have been assigned to a schedule of assets. With this setting 'AQC' is converted historically. The individual DPN transactions are calculated using the standard conversion rules or posting key conversion instructions. This is followed by a translation difference that adjusts to the historical AQC rate.

FDK - Updated average rate

This setting is available for all accounts assigned to any Transaction development. In the historical calculation, all development transactions are converted, but there is no compensation for the closing rate on this account. Instead, the difference to the closing rate is posted to the corresponding difference account of the currency translation parameter. The total group currency / parallel currency of all development transactions of this account are transferred to the account balance.

PAV - Currency rate average per period

The account is converted to currency rate average per period, differences to the closing rate are posted to the accounts 'KtoGuVPosD' or 'KtoGuVNegD' from the currency conversion parameter.

CR - Closing rate

The account will be converted at the closing rate. If an account has a detailed breakdown (intercompany, controlling, Transaction development) and there is a difference after conversion, this is posted in the detail breakdown and therefore the details is adjusted to the conversion of the account balance.

VK - Specified course

A user can manually specify a course, with which the balance is converted. The difference to the closing rate is posted to the corresponding difference account of the currency conversion parameter.

VPK - Exchange rate previous period

The conversion is carried out to the exchange rate previous period of the account (the exchange rate can be seen in the application account Conversion Certificate). If there is no rate in the previous period, conversion to the corresponding conversion method is carried out instead (for balance sheet accounts = 'CR' and in the P+L = 'PAV')

5.3 Modification of Account Conversion Rules

By selecting a row and the action <Edit data> you get to the individual record, here the selected record can be changed. Only conversion rules that deviate from the standard can be entered. If you wish to change a different conversion rule back to the standard, this is possible via the 'Set UAW Standard' action. The 'mass update' function allows you to adjust various lines.

Change in individual account conversion rules for referencing companies

For a referencing company, there is usually no need to customize the account conversion rules, because the settings are adopted by the reference company. If the conversion rule 'VK' is stored for an account and the local currency differs between the reference company and the referencing company, in this exceptional case a rate must be saved in the account conversion rules.

6 Proof of Conversion

The 'account Conversion Statement' application can be used as a follow-on application from the currency conversion overview (short term: FXCN) or directly with the short word 'ACCNADT'. For each account with this account balance, the proof of conversion after currency conversion shows the currently applied account conversion rule of one or more companies for the respective selected facts and current period. In addition, the prices actually used and any currency conversion effects / translation differences identified are also reported. Standard account conversion rules are highlighted in green in the conversion rule column of the overview and in the yellow for different conversion rules.

Various columns are output in this application, which are calculated / composed as follows:

GC translation difference to closing rate in GC previous period (GC-Umrech Diff. VorPer)

In the left-hand column, for balance sheet accounts, the amount from the account translation verification of the previous period is accumulated in the column GC translation difference at the closing exchange rate in GC (GC conversion). diff. kumul.). For P+L accounts, this column is blank. In the right-hand column, the displayed amount of the Group currency is converted into the parallel currency.

GC translation difference compared to closing rate in GC Act. Period (GC-Umrech Diff. AktPer)

For balance sheet accounts, the left column shows the cumulative value between the previous period and the current period. For P+L accounts, this column is blank. In the right-hand column, the displayed amount of the Group currency is converted into the parallel currency.

GC translation difference to closing rate accumulated in GC (GC-Umrech diff. kumul)

For balance sheet accounts, the left column shows the cumulative value from the previous period and the current period. This difference amount to the closing rate is posted proportionally on the account 'KtoBilDiff' from the currency conversion parameter. For P&L Accounts, the difference to the closing rate is also shown here if the income statement is not calculated for closing rate. This difference depends on the S/H indicator on the account 'KtoGuVPosD' or 'KtoGuVNegD' posted.

PC translation difference to closing rate in PC previous period (PC-Umrech Diff. VorPer)

In this column, for balance sheet accounts, the amount from the account translation memo for the previous period is accumulated in the column PC translation difference for closing rate in PC (PC conversion). diff. kumul.). For P+L accounts, this column is blank.

PC translation difference compared to closing rate in PC Act. Period (PC-Umrech Diff.AktPer)

For balance sheet accounts, this column shows the cumulative value between the previous period and the current period. For P+L accounts, this column is blank.

PC translation difference to closing rate accumulated in PC (PC-Umrech diff. kumul.)

For balance sheet accounts, this column shows the cumulative value from the previous and current periods. This difference amount to the closing rate is posted proportionally on the account 'KtoBilDiff' from the currency conversion parameter. In the case of accounts on the income statement, the difference from the closing rate is also shown here if the income statement is calculated differently from the closing rate. This difference depends on the S/H indicator on the account 'KtoGuVPosD' or 'KtoGuVNegD' posted.

Total translation difference to closing rates in PC previous period (translation) Diff. kumul.VP total)

In this column, the 'GC translation difference to closing rate in GC previous period' (right column) converted to parallel currency is added with the value 'PC translation difference to closing rate in PC previous period'.

Total translation difference to closing rates in PC Act. period (conversion) Diff. Diff.AP total)

In this column, the 'GC conversion difference' converted in parallel currency is converted to closing rate in GC Act. Period' (right column) with the value 'PC translation difference to the closing rate in PC Act. Period'.

Total translation difference to closing rate accumulated in PC (translation. Diff.kum. total)

In this column, the 'GC translation difference to closing rate cumulative' converted into parallel currency (right column) is added to the value 'PC translation difference to closing rate accumulated in PC'.

6.1 Selection Options

BG Code. 1 (Assets) and 2 (Liabilities)

In the account conversion statement is referred to the BG code in the Selection area (not via the filter). 1 (assets) and 2 (liabilities) in the column 'GC translation difference to closing rate cumulative' at the bottom (third last line) there is a sum for all balance sheet accounts. This total, plus any rounding difference (one line below), results in the amount posted by the currency conversion in the difference account 'KtoBilDiff' from the currency translation parameter.

BG Code. 3 (Income) and 4 (Expenses)

In the account conversion statement is referred to the BG code in the Selection area (not via the filter). 3 (Income) and 4 (Expenses) in the column 'GC translation difference for closing rate cumulative' at the bottom (third last line), there is a total for all P+L accounts. This total, plus any rounding difference (one below), results in the amount posted by the currency conversion in the difference account 'KtoGuVPosD' or 'KtoGuVPosD'. 'KtoGuVNegD' from the currency conversion parameter.

This selection is of course also possible for the parallel currency. The rounding difference cannot be prevented as each account for the conversion statement is considered individually in the currency conversion. However, for the actual conversion of the account balances, a difference must be considered as a whole and also an overarching rounding difference must be derecognized.

7 Carry Forward of Currency Translation Parameters to a New Period

The elements of the currency conversion are presented with the follow-up process "Carry out carry forward into new period" in the CFSMNR-Monitor. In this context, the currency conversion parameter, the account conversion rules and the posting key conversion rules of the companies are carried forward.

8 Sample Calculations

8.1 FDA Conversion

The FDA conversion is intended to calculate the conversion at the updated historical DSP average rate. To make this possible, all posting keys that are included in the columns for DSP disposal and disposal should be included. DPN are set, a posting key conversion rule 'VPK' can be set. This ensures that all disposals are converted with the updated historical DSP average rate of the previous period.

Example using an investment account

Exchange rates

Calculation of depreciation difference:
Formula:
(Subtotal depreciation and amortization * historical AHK exchange rate) ./. (DPN carry forward in GC + DPN additions in GC)
Calculation:
(190.000,00 * 1,070530 = 203.400,70) ./. (74.937,10 + 132.600,00 = 207.537,10) = ./. EUR 4.136,40

8.2 FDK Conversion

The FDK conversion is performed by the leading Transaction development, i.e. the transactions are converted first. The account balance is then transferred from the GC total of all transactions and not self-converted. This results in an average historical rate. The difference to the closing rate is allocated to the 'KtoBilDiff' from the currency conversion parameter and can be traced in the conversion certificate.

Example using a capital account

Exchange rates

Calculation of historical FDK rate:
Formula:
(account balances GC value) / (account balances LC value)

Calculation:
431.185,50 / 400.000,00 = ./. 1,077964

Calculation Conversion difference FXCN difference account:

Formula:
(account balance LC value * SC rate) ./. (account balance LC value * FDK rate)

Calculation:
(400.000,00 * 1,130000 = 452.000,00) ./. (400.000,00 * 1,0777964 = 431.185,50) = EUR 20,814,50

Error message KON0427E:

Problem:

The currency conversion displays the error message KON0427E: "Difference in details of account ..."

Cause:

The conversion rule FDK was specified for the account. However, the sum of the breakdown data (principal or fixed asset transaction) in local currency does not match the national currency value of the account balance.

Solution:

Call the ACBAL application with the appropriate company, period, data type, and account number. Select the account row and branch through Action into the account's movement data depending on KZ2 (A = Appendix, K = Capital). Now the account's movement data can be compared with the account balance and the required debits/debits can be made.

8.3 SC Conversion

When converting to closing rate, the relevant account balance is converted at the specified closing rate. To the extent that there are carry-forward movements, a currency conversion effect is created for adjustment to the current closing rate; this is posted via the posting key with the usage tag 'K'. The remaining difference is due either to rounding differences or to deviating posting key conversion rules.

Example using an investment account

Exchange rates

9 Change to an Existing Local Currency

If a company chooses to report data in a different local currency from the previous one starting in the next period, not only data from the companies in the new currency must be provided, the carries forward must also be adjusted accordingly. However, these can only be provided to a limited extent by IDL.KONSIS.FORECAST.

9.1 Case 1 - Future local currency is already available in the current group or parallel currency

In this case, before carry forward into a new period in the partnership master data of this company (Short Word: CODT) the local currency can be adjusted accordingly. As soon as the company is carried forward into a new period, IDL.KONSIS.FORECAST takes over the values for the carries forward from the corresponding group or parallel currency of the previous period.

9.2 Case 2 - Future local currency is not available in group or parallel currency in the current period - 1. Solution

In this case, the data cannot be taken from the group or parallel currency column. In the company, before the carries forward have been made in the new period, is entered in the company master data (short term: CODT), the local currency is converted to the new currency and then performed the carry forward, IDL.KONSIS.FORECAST sets the carries forward in local currency with 0.00 and fixes the group and parallel currency values accordingly with VKW / VPW. The user must then call up the various development transactions and manually update the local currency values. Special authorizations are necessary for this action. However, a balance sheet and Guv report can be generated for the new local currency in connection with the previous period.

9.3 Case 3 - Future local currency is not available in group or parallel currency in the current period - 2. Solution

In this case, the data for future local currency can be generated in the current period using a new (or unneeded) fact. To do this, you must check whether such a fact exists and transfer the data there accordingly. The exact procedure is as follows:

1. Fact

Create a new fact or select a fact that will not be used otherwise. It is important to ensure that all Transaction developments in the FACSPI application are active in the same way as on the original fact. If a Transaction development is not turned on, the currency conversion will behave differently during the conversion.

2. Customizing Your Own startup data (Short Word: STUPDTATH)

Entry of the future local currency as a parallel currency indicator in the advance occupancy; a warning is reported here that there is a contradiction with the currency indicators of the group. This warning can be ignored.

3. Copy the currency conversion parameter to the new fact

Via <Edit data> for the currency conversion parameter can be copied by overwriting the data type with the new fact in the individual record and then 'Add' the currency conversion parameters in the new fact. The account conversion rules are also copied at the same time.

4. Copy the movement data

Via volume copying, all account balances and related details (IC balances, controlling balances, development transactions (investments, capital, provisions as well as others). Transaction development) to which new facts are copied

5. Changing exchange rates

For the new fact all exchange rates (also via quantity copying) must be created for both the current and the previous period. It must be checked whether the courses for the new local currency of the company are available subsequently, if so far there are no company with this currency so the rates for the current period must be entered.

6. Launching the currency conversion

Now the currency conversion can be started in the CFSMNR-Monitor in the current period. Caution: Selection in the CFSMNR monitor should be carried out without group and the company number must be adjusted accordingly.

7. Checking converted data

After conversion, balances etc. should be called up, and the parallel currency should be equipped accordingly.

8. Customizing Your Own startup data (Short Word: STUPDTATH)

Before any further steps are taken, the correct parallel currency indicator should be stored in your own startup data again to rule out errors.

9. Changing the Company Currency

In the company master data (short word: CODT), the local currency indicator can now be saved accordingly before the carry forward

10. Carry forward to the new period

This company must now be presented in the CFSMNR monitor with the different fact. During this process, the carry forward adopts the values from the parallel currency column of the previous period and type of data and enters them accordingly in the current period / fact in the local currency of the company.

Experience has shown, however, that there are always differences between the conversion of the subsidiary and the conversion into IDL.KONSIS.FORECAST. This is due in no small part to the conversion from local currency to group currency and subsequently to parallel currency. The differences must be adjusted accordingly manually in the Transaction developments, here e.g. a posting key for man. exchange rate differences. The carry forward on the 'KtoBilDiff' from the currency conversion parameter must also be posted manually in the capital transactions.

10 Logging of the Currency Conversion

10.1 General

In the context of the review of the currency conversion carried out by IDL.KONSIS.FORECAST, the user has a variety of means of verification. In addition to the local currency value, the consolidated currency value and the parallel currency value are also documented in all applications affected by the currency conversion. Exchange rates are also recorded.

Translation differences determined on the system side are posted separately. This relates both to exchange rate differences resulting from the conversion of balance sheet and profit & loss and to mirror applications.

10.2 Account Conversion Certificate

The conversion per account can be verified in the account conversion rules. This application can be accessed either as a follow-up application via the currency conversion headers, or directly via the call with the short word 'ACCNADT'. The exact description of the columns can be found in the description for conversion statements.

10.3 Account Balances (Short Word: ACBAL)

In the account balances is available after currency conversion in local currency, group currency and parallel currency. The following information from the currency conversion is available per account/account balance for the consolidated currency conversion:

• the account conversion rule,
• the exchange rate and
• the closing date.

More detailed information can be found in the conversion certificate.

10.4 IC Sub-Account Balances (Short Word: ICACBAL) and Controlling Balances (Short Term: CNTSAL)

In these views, all records were also converted to group and parallel currency after currency conversion. The sum of all records for an account then returns the account balance.

When reconciling IC account balances or controlling balances, it should be noted that minor rounding differences may occur as a matter of principle due to the addition of the individual details balances and the subsequent reconciliation check for the account balance of the respective account. IDL.KONSIS.FORECAST automatically compensates for these differences within the IC balances per account to the first record of an account in order to avoid any difference.

10.5 Development Transactions

In the development transactions (summary: FOREIGN EXCHANGE), statement of changes in equity (brief: CAPTRN), provisions (short term: PRVTRN) or individual Transaction developments (short term: DEVTRN) in the first step all transactions are converted for themselves. For these transactions, you can also see the reference date and especially the rate used, in addition to the respective conversion rule. You can also manually specify a rate (with conversion rule VK) or a specified group or parallel currency value (with conversion rule 'VKW').

If the respective account is converted to history (FDA or FDK conversion rule), the movement breakdown is considered to be the lead factor for the account balance. This means that the total conversion from the development transactions is transferred to the account balance. If an account is replaced with closing rate (conversion rule CR) converted, the account balance is leading and an adjustment to the account balance is made through the currency conversion.

It becomes more complicated when the account is converted to closing rate but is also an intercompany account. In this case, the account balance is converted first. The currency conversion then performs the conversion of the IC balances. In the final step, the development transactions are converted and reconciled for each IC company entered. If the IC balance in group or parallel currency is different from the proportional IC balance, the currency conversion in the development transactions creates a transaction with the posting key for conversion differences.

If an account is simultaneously a holding account and a fixed asset account, each details is converted for itself. Differences per IC company are booked in the shareholding transactions because the system mirror is the leading one. This means that if a user enters a new transaction in the shareholding transactions and sets it at a specific rate or group / parallel currency value, this must also be maintained in the corresponding fixed asset transactions after to avoid adjustments by the system.

11 Other Issues

11.1 Currency conversion at weighted average monthly rates (MAV)

The following procedure must be used to create an MAV Transaction development:

1. Creating a Transaction development via mirror definitions (short word: TRNDEVDFN)

The new Transaction development can be created with the wizard (star symbol), the names on page 1 and 3 of the wizard are free to choose. On page 2 (Mirror Attributes), the transaction development type 'Other' must be selected.

1.1 Creating a transaction development area

A Transaction development area (e.g. 0) must be created via the Wizard (star icon) in the lower table area. The descriptions on pages 1 and 3 of the wizard are also free to choose. On page 2 (mirror area attributes), in the Other options area, a check mark is placed for "Balance relevant" and "Monthly weight. average rates". In the carry forward control area the radio button 'with normal carry forward' must be selected.

1.2 Creating columns

There should be three columns:

01 => 'Carry forward'

02 => 'Ongoing change'

03 => 'Currency conversion'

No usage tag is required for all columns.

1.3 Creating posting keys

Four posting keys should be defined in total, this can be done in the posting key tab via the wizard (star icon). The posting keys shall be defined as follows:

=> 'MV' - Transaction development area 0 - transaction development column 01 - usage tag 'M'

=> 'LV' - Transaction development area 0 - transaction development column 02 - usage tag 'L'

=> 'KE' - Transaction development area 0 - transaction development column 03 - usage tag 'K'

=> 'UD' - Transaction development area 0 - transaction development column 03 - usage tag 'U'

2 Accounts

Below are all P+L accounts in the 'accounts' application (short term: COADFN) for the group chart of accounts to enter the new MAV Transaction development in the Transaction development field using the 'Change Quantity' function. The referring company accounts will then automatically receive the new Transaction development inherited from the respective assigned group account.

3 Exchange rates

Conversion of the current changes must be made at the monthly average rate. The time reference 'MAV' is used for this purpose, with which the corresponding exchange rate in the exchange rate table (short term: FXRTE).

4 Posting key conversion rules for MAV Transaction developments

The conversion rule 'MAV' is activated via the 'posting key conversion rules' application (short term: PSTKEYCNVR) to the posting key for constant change ( LV ) so that all ongoing changes are translated at this rate.

5 Posting key conversion rules for fixed assets statement

IDL.KONSIS.FORECAST supports currency conversion testing between DPN additions (old BSL standard: transaction development column 13 / new BSL standard: transaction development column 23 and 36) and depreciation accounts (with account flag = 'D'). Here, the DPN transactions are converted using the same conversion rule as the P+L accounts. However, at the average monthly rate, this is no longer possible without receiving differences. For this reason, posting key conversion rules with 'MAV' must be created for all posting keys assigned to the DPN access columns.

6 Posting key conversion rules for provision statement

IDL.KONSIS.FORECAST supports currency conversion testing between provision resolution (old BSL standard: transaction development column 03 / new BSL standard: transaction development column 24) and dissolution accounts (with account flag = 'Y'). Here- for the provisions resolves are converted with the same conversion rule as the P+L accounts. However, at the average monthly rate, this is no longer possible without receiving differences. For this reason, posting key conversion rules must be set up with 'MAV' for all posting keys assigned to the provision resolution transaction development column.

The same case exists for feeding provisions. It finds a sampling between the feeds (old BSL standard: transaction development column 04 / new BSL standard: 23) and the allocations to provisions in the P+L (account flag = 'Z'). For this purpose, posting key conversion rules with 'MAV' must also be created for all posting keys that are coded in this transaction development column.

7 Account conversion rules

Are the P+L accounts (balance sheet and P+L license plates 3 and 4) generated via the application 'account conversion rules' (short term: ACCNVR) with the conversion instruction 'FDK' (updated average rate) manually, the account balance is converted to weighted average monthly rates. Instead, in the Currency Translation parameter (Short Word: FXCN) of the company, or of the Reference Company, the conversion method 'MMW' may be selected. In this conversion process, all P&L accounts that have deposited a Transaction development are converted to FDK by default. ATTENTION: However, the conversion process is not without its hazards, as all manually adjusted account conversion rules are adjusted to the standard of the 'MMW' conversion process.

8 Activating the Transaction development in the fact / transaction development area application (Short term: FCTDEV)

Here the transaction development area for the data types on which monthly weighted average rates are calculated must be activated accordingly with an 'X'.

9 Activating the Transaction development in the Period / transaction development area application (Short term: PRDDEV)

Here the transaction development area for the period on which weighted average rates are to be calculated for the first month must be activated with an 'X'. If a future period is already active in the system, these must also be activated.

10 Current changes

If possible, the MAV Transaction development should be activated in the first month of a year. To have the transactions computed (e.g. in January), all companies should be marked in the CFSMNR monitor and the function 'Check / update status values' should be executed.

11 Carries forward

Interim financial statement period - for carries forward from an interim financial statement, the prior period values are combined to form a carry-forward period which accordingly contains the total of the previous months of the financial year. When using an MAV Transaction development, it is mandatory to carry forward the fixed asset statement and the provision statement during the year in addition to the MAV Transaction development, as otherwise the trial run (described under 5. and 6.) will not be performed without difference.

If, on the other hand, a statement is carried forward from an annual financial statement period, no movement set.

11.2 MAV Transaction developments additionally with weighted rates for controlling balances

If a P+L account has been marked as having controlling balances in the account master data in addition to the mark for the MAV Transaction development, the controlling balances are converted evenly with the calculated FDK rate from the account balances (or the account conversion certificate) per account. However, no weighting per controlling object is shown.

For these calculations, the automatic development transactions must also be supplemented with controlling information. These are derived from the controlling balances, depending on the account, or from the IC balances for IC accounts. Es is therefore essential that the IC balances must contain controlling information that matches the controlling balances.

If an additional weighting per controlling object is desired, the following additional settings must be made:

Mirror definitions application (Short Word: TRNDEVDFN)

Highlight the transaction development area for MAV and right-click to edit it (pencil icon). Set the "Calculation per controlling object" check mark under the properties. Exit the wizard with "Done" and save the Transaction development (diskette symbol)

Application of accounting periods (Short Word: CLSDTE)

In the periods, the expression "with controlling balances" and "Control details also for IC balances" must be activated.

Data Types Application (Short Word: FCT)

In the relevant data types, the expression "with controlling" and "details also for IC balances" must be activated.

Attention: Currently there is still a problem with importing the controlling balances. No development transaction auto-generation test modules are started after import. After the import, please call up the CFSMNR monitor and execute the function "Check / update status values". This functionality will be supplemented accordingly in the next FixPacks.

11.3 Notes on the exchange of group and parallel currency (Short term: CRCYCHG)

If the parallel currency is to be implemented in group currency, this step is supported by the special program CRCYCHG. This program does not convert the entire data stock at once, but only one fact and one period each.

There are two reasons why it does not make sense to differentiate by company:

• The group and parallel currency are only specified once in the cost unit/group or in the startup data. If the function is only performed for a part of the companies, it can only be determined by an entry in CMPCNT which value belongs to which currency. However, the currencies indicated in CMPCNT are hardly evaluated at present.
• Consolidation postings are not related to companies, but apply to a group. These have to be converted in one go, regardless of companies, otherwise vouchers will become inconsistent.

In the following tables, the GC values are to be swapped with the PC values and checked in the following overview of the CRCYCHG application:

• Account balances (Short Word: ACBAL)
• IC account balances (Short Word: ICACBAL)
• Controlling balances (Short Word: CNTSAL)
• Fixed asset transactions (Short Word: FATRN)
• Capital transactions (Short Word: CAPTRN)
• Provision movements (Short Word: PRVTRN)
• otherwise. Development transactions (Short Word: DEVTRN)
• Shareholdings (Short Word: SHRPAR)
• Stocks of ICs (Short Word: ICVOR)
• IC fixed asset transactions (Short Word: ICFATRN)
• Consolidation postings (Short Word: CNSPST)
• Postings (Short Word: PST)

Since a complete currency conversion is made and the values do not have to be copied, it makes sense to create the report results again. CRCYCHG converts the exchange rates previously set by the user to the new group currency and then recalculates each individual account balance. Only values that are fixed in the transactions with VKW / VPW will be retained accordingly.

Motion sets generated from the currency conversion are not handled separately. The result is a set where the GC value is nonzero while the PC value is zero.

If conversion is performed again, these values (recognizable via account number or posting key) are not converted but erased. The currency codes are exchanged for the relevant period and facts for all companies and all checkpoints. Assuming that the initial program call is intended to fundamentally change the group currency, all rates for STUPDT and KTK data that contain the previous GC/PC combination will also be changed. Repeated calls (for other periods/data types) are not subject to further updates.

In addition, an attempt is made to convert the current and cumulative differences in the FXCN header records into the new group currency. For this purpose, the corresponding account balances are read and, if necessary, totaled across all GIZ-specific role models. If the old group currency matches, the value is replaced by the total in the new group currency. If there are any differences in the accumulated balance differences for the current period, the previous value is not changed and a warning is issued.

Several tables have additional value fields in group currency without related value fields in parallel currency. As a result, these cannot be implemented by this application. These are:

• The investment book value in the group/subgroup can be recalculated by calling up the determination of holdings. Implementation is not necessary.
• Next data may have to be manually adjusted by the customer. This is net book value and proceeds in the fixed asset objects
• Threshold for clarifying differences in consolidation parameters
• Difference from Autoclearing CR/AE
• Lower and upper limit for manufacturing costs of products
• Various values at update Equity

The application to exchange group and parallel currency is called from the dialog application CRCYCHG, which must specify the fact, period, and preceding period (for FXCN header), but no company and no group/TK. In addition, the new currency codes for group and parallel currency must be indicated. Once these currency codes have been replaced, the entire process can be revised; however, please note the STUPDT and KTK: These two tables are implemented independently of period and fact.

Before the actual processing is called as a follow-on application, the following checks are performed:

• All PROCESSION rates for all companies must be error-free and contain the correct currency codes.
• For all companies with which account balances exist, PC values must also be available.
• There must be PC values in CNSPST.

This CRCYCHG-shortened call application also contains all overviews or master applications to the edited tables as follow-up applications, so that the result of implementation can be directly controlled:

• ACBAL
• ICACBAL
• CONBAL
• FATRN
• CAPTRN
• PRVTRN
• SHRPAR
• ICSTCK
• CNSPST
• PST
• CMPCNT
• FXCN
• STUPDT
• KTK

Regardless of these applications, the requirement to switch the local currency to parallel currency for a company must be seen. This must be done at change of period by corresponding change of local currency in the share capital master record. By depositing the currencies in the CMPCNT rate it is possible to determine which currency is applicable in which period. The problem here is only carries forward. If these were formed in local currency, then the formed carryforward rates must be manually converted and corrected. See Chapter "Changing an Existing local currency".