The release IDL KONSIS 5.4.2 (analogue IDL Winkons 3.2 and PPconsis 4.2 SR1) is an interim maintenance and therefore can be left out in the release sequence. Prerequisite for this release is the last main maintenance (IDL KONSIS 5.4.0 or IDL Winkons 3.0 or PP consis 4.01) of Sept. 15th 2005. The supplements and corrections to the main maintenance are contained in the current interim maintenance.
Because of the changes of the capital consolidation (see below) it is recommended, not to install this release during group consolidation.
Users who work with individual transaction developments, have to define custom-designed texts (description see Release 5.4.1 News) since the last interim maintenance for the used transaction developments. They otherwise cannot work with these individual transaction developments any more.
Beside the report display a number of further lists also contain multi-line headings from this release on. If the display of single-line and multi-line column headings is given with a different font (bold or not bold), this is caused by the selected font in the menu item <Options> -> <Options>-> <View>. Fonts representing a combination of font and style (e.g. <Arial bold>) shouldn't be used here. Rather font (e.g. <Arial>) and style (e.g. <bold>) should be stated separately.
The development planning provides that group transactions (fixed assets, capital and provisions) aren't supported with one of the next releases any more, since these data are redundant to the consolidation postings and don't contain additional information. The users are therefore challenged
The evaluation of the formulae for column options and ratios (cared with the application <Formula lines list> (FED)) calculated wrongly at a leading '-' in the first formula line. Instead of negating the first operand, the final result was negated. Customer individual column options and ratios are delivering perhaps wrong values after the correction of this error now if they were adjusted to the faulty formula calculation by 'Trial and error'.
The IDL Connector supports the version MS Excel 97 for the last time with this release as advised for over one year. Later releases will be no longer compatible. Therefore please upgrade to a more current Excel version on time particularly since the hotline service was also ceased meanwhile for MS Excel 97 by Microsoft.
Attributes for IC company and IC business unit were supplemented in the database tables for capital, provisions, and individual development transactions. For fixed assets transactions these attributes already existed. The main purpose of this enhancemant is a simplified development reposting of debts consolidation.
The new attributes can be entered via single record applications (KAPBEWE, RUEBEWE, SPIBEWE) or via import (TXTKAPBEW, TXTRUEBEW, TXTSPIBEW). Of course, the entry is allowed only for accounts with simultaneous account flag 'I' or 'J'. The entry of an IC business unit is checked for validity of the combination of IC company and IC business unit stated in the allocation table GESUBR.
If data are entered with IC company, these data are checked for consistency with inter company account balances (ICKTOSAL). If the sum of development transactions differs from the sum of IC account balances, this is notified just like differences to the account balances. Then the status of this development is displayed <red> in the <company's financial statement monitor> (EA). This is also true for fixed assets development.
The entry of IC companies into the transactions provides a detailed carry forward of these data (separate carry forward transaction for each inter company) as well as a detailed currency conversion (separate currency differences for each inter company).
On the other hand development transactions of automatic developments (with posting key with usage flag 'L') are generated with IC company and IC business unit, if coherent IC account balances are present. Analoguely this applies to the first generation of carry forward transactions out of IC account balances instead of the generation out of account balances.
The repostings after elimination of intercompany accounts is able to eliminate the transaction development for each column with the aid of these data, even if not all IC companies are processed on the current group/subgroup level. The manual correction of these data is no longer necessary.
Up to now only the fixed assets transaction development was differentiated in to areas, in this case for acquisition/production costs and for depreciations. An analogue classification now is possible for individual transactions as well as an extension of the areas of the fixed assets transaction development (e.g. for "impairment"). Since a mixture of posting keys with and without development areas makes no sense, an extension of the capital and the provision development is not supported. Development areas also cannot be used for automatic transaction developments (with posting key with usage flag 'L').
The definition of individual transaction development areas is carried out via the new application <descriptions development areas> (short word ISB). Such a transaction development area is identified by a single character and provided with corresponding descriptions here.
This characteristic then can be assigned to the posting keys of the respective transaction development in the application <posting keys> (BSL). The previous posting key flag 2 was also renamed into "development area" to the clarification. It has to be taken into account that posting keys have to be defined for certain functions defined by the usage flag per transaction development area. This concerns the period carry forward for company and group financial statements (usage flag 'V'), the currency conversion (usage flags 'K' and 'U') as well as the group companies change (usage flags 'E' and 'F').
The use of transaction development areas leads to a differentiated treatment of the transactions at the period carry forward (separate transaction per transaction development area), at the currency conversion (separate difference compensation per transaction development area) and at transaction development reposting at changes of the group companies (reposting per transaction development area).
The need increased by this extension for individual posting keys particularly for the fixed asset transaction development was taken into account in this respect that besides the first letter 'K' the first letters 'L', 'M' and 'N' also can be used for individual posting keys. A further-reaching individualization of the posting keys is planned for one of the next releases.
The number of available report result values (transaction development columns) was increased to now 50. This particularly concerns the individual transaction developments in which the values can be distinguished now in the report into 50 instead of till now 20 different categories. The new columns can be provided with texts via the application <column description indiv. development transactions> (ISS).
For the standard transaction developments (capital, provisions and fixed assets) the additional columns also were defined as customer individual. I.e. while the columns '01' to '20' as till now are delivered with fixed meanings, the additional columns can be defined for customer specific needs. These columns also can be descripted individually by the application ISS.
Especially for the fixed asset transaction development in accordance with IFRS the need for extension for finance fixed asset transaction development, Impairment or Fair Value may exist. To not overload the delivered standard hereby an extension of the standard was renounced. Such extensions are individually possible now, however. Patterns for these extensions are provided by IDL in the form of TXT files for the import. You find these files on the delivery CD in the directory "LieferBatch". For importing these files possibilities for the import of column options and individual transaction development definitions were completed in the calling application IMPORT.
The report result values '21' and '22' had special meanings as a sum of acquisition/production costs or sum of depreciations in the fixed asset transaction development till now. Since these columns now are individually usable, the operands '#REP#'/'21' and '#REP#'/'22' in the formulae (FED) for the column names (SPA) have to be replaced by the respective sum of the detailled columns. For the existing column descriptions a conversion by the release-converting programme is carried out provided that this is beyond all doubt possible. A hint otherwise is output, that the formula has to be corrected manually. In addition, these value columns are deleted in the existing fixed asset development reports.
The report result value '23' had a special meaning as a grand total of all transactions till now. Since '23' is an individually defineable column now a special alternative value was created so that the previous operand '#REP#'/'23' has to be replaced by the new operand '#REP#'/'SUM' in the formulae (FED) for the column descriptions (SPA). For the existing column names a conversion by the release-converting programme is carried out. Furthermore this value is transferred into the new value column for all existing transaction development reports.
The report result value '25' had a special meaning as a column condition till now. Since '25' is an individually defineable column now a special alternative value was created so that the previous operand '#REP#'/'25' has to be replaced by the new operand '#REP#'/'BED'in the formulae (FED) for the column descriptions (SPA). For the existing column names a conversion by the release-converting programme is carried out.
The family of the forms entry applications was extended by a form entry application for fixed asset transactions (see below). There values per fixed asset object and posting keys can alternatively be entered in lines or in columns per posting key.
To the restriction of the recording on the essential posting keys the table <Posting Keys> was extended by an attribute for the "column order in the form recording". Only at entry of a value in this attribute the posting key is offered for entry in the application. The order is determined by the numeric value (at most 30).
The facilities of customer individual consolidation functions (KVA) have been possible for manual facts ('M0', 'M1', ..., 'M9') for some time to make among others postings possible with a different forwarding rule (posting type). However, these postings are summarized at the group carry forward into one voucher with consolidation function 'VM', so that the original distinction is lost. Therefore now corresponding individual consolidation functions 'V0', 'V1', ... 'V9' can be defined for the carry forward of the customer individual MB consolidation functions.
In addition further customer individual consolidation functions 'L0', 'L1', ... 'L9' can be defined to be used for the posting of the deferred taxes on the postings for individual MB consolidation functions. In accordance with the previous logic these LT postings are summarized with the MB postings into a VK posting where the new individual consolidation functions for carry forward are then applied again.
The following rules apply to creating individual consolidation functions:
The D&C and P&L consolidation with quoted companies always eliminated 100% of the inter company balances of the fully consolidated company but only the quoted values of the quoted counter-company since the remaining quota represents no inter company facts but facts due to third parties. The result was inevitably a SK/AE voucher with difference which had to be corrected by the user manually.
The new solution for an automatic treatment of this case presupposes the detail of a quota reference account per inter company account. Corresponding details are possible by an extension of the account master data now.
Now only the quoted quota (in accordance with quota of the quoted inter company) of the inter company balances are eliminated directly by the D&C and P&L consolidation at the fully consolidated company. The resulting difference of the postings between the two companies is adjustable thus again and can be reprocessed in accordance with the rules for threshold value and transaction currency clearing.
The remaining quota of the inter company balances of the fully consolidated company (100% - quota) is reposted from the inter company account to the quota reference account indicated in the account master data in a further posting record. You therefore eliminate from the view of the group report 100% of the inter company balances of the fully consolidated company and the quoted amount of the inter company balances of the quoted company so that the inter company accounts are expelled with group balance 0.00.
IDL Konsis distinguished between the setting of a historical participation (posting key '04') by the manual first consolidation and an addition or an increase of capital (posting key '02') by the automatic first consolidation up to the release 5.4.0. With release 5.4.1 the posting key '08' was established, with which an addition also could be processed by the manual first consolidation in the current period.
The differences between a manual and automatic first consolidation were cancelled largely now. An automatic or a manual first consolidation can be carried out now independently of the posting key of the participation change. Facts which had already been processed in the automatic first consolidation also still can afterwards be modified with the help of the manual first consolidation. When starting the manual first consolidation the first time, those capital postings are automatically suggested, which would have been generated by the automatic first consolidation so far.
The capital consolidation vouchers receive independently of the processing function the consolidation processing 'KK' in the voucher number now. 'KE' and 'KM' aren't used any more. The status columns 'KE' and 'KM' correspondingly were also summarized in the Group companies monitor (KTKGES) to a status column 'KK' which also is initialized by the calculation of participations and layers. In connection with this, an automatic Equity first consolidation also gets possible.
To be still able to distinguish several processes within a period (e.g. historical setting of the participation to January 1st, till now by KM voucher, and participation addition to April 1st, till now by KE voucher) new consolidation functions 'K0', 'K1' etc., as well as 'E0', 'E1' etc. for the Equity consolidation are supported, which have to be defined via the application <consolidation functions> (KVA) before. Thus a separate voucher can be created now if in the example another participation addition happens at July 1st, too.
It is possible now to visualize the results of plausibility checks in the report result list in traffic lights representation (i.e. with coloured background). The plausibilities are formulated in the form of balance sheet ratios which produce difference values.
In the table for report line descriptions (REPZEI) three attributes for '< 0', '= 0' and '> 0' were supplemented, which can get the expressions <empty>, <green>, <yellow> and <red>. The application <report line descriptions> became extended for the display or care of these attributes.
At the report generation this control is taken on also into the report result so that it can be evaluated in the report result list (REPERG) and converted into a colour control of the value fields. The colour control for the cell has priority before the colour control for a line. For the time being, a restriction on certain columns isn't performed.
The new IDL Konsis application server which is already available in the release 5.4.0 is now declared as standard. The conversion of the old to the new application server is documented in the installation instruction for this release. Users who don't use the application server aren't affected by this change.
An order of the columns of a list changed by the user is remaining now until a change of the selection criteria leads to another column number or another default column order. Till now the column order was put on the default column order at each refresh.
If no line is highlighted in a list yet and the right mouse button is then pushed in the table, this line is marked automatically and then the object menu is opened. If other lines are already highlighted, the previous marking remains unchanged, no additional line is marked and the action refers on the lines already marked before.
Till now, the fixed area of lists was always provided with a uniform colour. In future, the line colour of the scroll area also is used in the solid area at tree representation. This applies to the online display like also for the print.
Errors in the mass copy function are no longer only displayed in the status line but as in the case of the mass update a message box with the additional question "copy continue? <yes>/<no>" is output. By this means the mass copy can be continued without the marking being lost.
The line break character '|' for column headings is taken into account now also at the end of a name. A combination of column headings in the print layout is only carried out when the lines of the column headings laying above that lines are also the same.
In addition, the characters '<', '>' and '&' are now correctly processed in multi-line headings.
If a user has adjusted UK English ('ENG') or U.S. English ('USA') as his application language (text locale in the options) or as map language (in application USE or VOR) the descriptions that couldn't be found in this language are read in the other English language variant at first, before other languages are consulted (e.g. German as default language). This applies both to the application (e.g. prompt texts) as well as to customer defined names of application objects (e.g. account descriptions).
The converting programme for this release carries out the following conversions in addition to the changes required for the interim maintenance 5.4.1 in the database:
The following menu IDs are new in this release in addition to the new menu items in Release 5.4.1. If custom-specific authorization groups are used, authorizations must be supplemented for these menu items if necessary (BENMEN ). In general the menu authorizations of the user groups IDLKON or IDLWIN may serve as a sample.
The authorization for changing of data was assigned to the application KONKTO (manual first consolidation), so that users without autorization for changes (e.g. user group IDLVIEW) don't cause any database changes.
The list <User> (USE) was extended by selection possibilities for menu authorization group and object authorization group. Thus all users can be selected with certain authorization groups.
The user language (for the display of application-specific translation, such as account descriptions) is now displayed as a column in the lists <Company startup data> (VOR) and <Company startup data+authorization> (VORADMIN). The change is possible alternatively here or in the application <User> (USE).
The account master data were extended by an attribute for a "quota reference account". Here for an inter company account one not inter company account can be assigned, to which the from outside quota is reposted at the D&C/P&L consolidation (see above).
Accounts with account flag 1 = 'J' can be allocated now as aggregation account both for accounts with account flag 1 = 'I' and for accounts without account flag since on the J accounts both inter company facts and facts due to third parties come together.
When entering a new accounting period in the application ABRE the flag for controlling details is now set to 'off' in the default. This complies with the standard of the majority of the users.
The new application <description development areas> (short word: ISB) serves for the definition of individual transaction development areas (see above). This application was inserted into the new menu node <Individual development definitions> of the <Master data> menu, where you also find the applications <description indiv. development transactions> (ISP), <column description indiv. development transactions> (ISS), both new applications in release 5.4.1, and the list <posting keys> (BSL). These applications now all can be invoked by short word, too (till now only subsequent application of <facts> (FAC)). These applications make also various branches possible under each other.
The application <column description indiv. development transactions> (ISS) was refined so that the new columns '21' to '50' also can individually (see above) be descripted. Since this also applies to the standard transaction developments (fixed assets, capital and provisions), these transaction developments can be selected now, too.
The previous entry field "posting key flag 2" was renamed into "transaction development area". This flag can be used now also for individual transaction developments (see above).
The list <posting keys> (BSL) is displaying the data in tree structure now. There are different variants for it which can be selected about the new entry field <Sortselopt>:
A new attribute of the table posting key is the "column order for the form recording". An entry in this attribute results in a value being able to be entered in the form recording for fixed asset transactions (see below) to this posting key. As of the next release this also applies to the planned form recordings for other transaction development transactions. This attribute works also for the recording forms of the IDL Connector. The numeric value determines the order of the entry fields.
In the application <posting keys> (BSL) a possibility for the mass update of the "valid till date" was completed. Thus posting keys no more used can be deactivated so that they aren't offered in the selections any more.
Individual posting keys for the standard transaction developments (fixed assets, capital, provisions) can now as well start with the letters 'L', 'M' or 'N' in addition to 'K'.
A new usage flag 'F' provides the identification of posting keys for the transaction development reposting at departure from the group companies (see below). Another two new usage flags 'SE' and 'SF' provide the identification of posting keys for the reposting of the carry forward elimination transactions (BSL with usage flag 'SV').
As reference group posting keys for participations fixed asset posting keys are deposited now which then are used for the postings at the capital consolidation on the participation account.
You now have the possibility to define individual consolidation functions (KVA) 'Vn' ('n' = '0', '1' ... '9') to be used for the carry forward of manual vouchers with the individual consolidation functions 'Mn'.
In addition, individual consolidation functions 'Ln' also can be established, which are used for the posting of deferred taxes of the respective manual vouchers. These postings also are reposted to the consolidiation function 'Vn' if defined. For this consolidation functions the flag for the consolidation parameter (KTKPAR) isn't set , i.e. there are no divergent consolidation parameters for these consolidation functions, but the KTKPAR LT ist always used.
The entry of a consolidation function 'Vn' or 'Ln' is only possible, if a consolidation function 'Mn' is defined. If no new individual consolidation functions are defined, everything runs like before. In future, new individual consolidation functions 'Vn' and 'Ln' will be co-created automatically if a consolidation function 'Mn' is inserted. If a consolidation function 'Mn' is deleted the consolidation functions 'Vn' and 'Ln' will be deleted, too, if they aren't used in other data.
Individual consolidation functions 'K0, 'K1' etc. also can be created so that participation changes at different times can be distinguished by separate vouchers in the capital consolidation (see above). Consolidation functions 'E0', 'E1' etc. can analoguely be established for the distinction of different equity participation changes.
The applications for the company business unit allocations (GESUBR) now offer the following additional possibilities:
If the flag of the fact (application FAC) for controlling details is '0' (controlling details for parts of the p&l only) the list (KTOSAL) and the form recording (I-KTOSAL) for account balances now display b/s/p&l flag of p&l accounts <white>, if no controlling balances are entered. The previous display <green> conveyed the impression of a complete elevation.
The help text to the respective account in the list <account balances> (KTOSAL) is shown at key <F1> now. The line has to be marked before.
A branch is possible from the list <IC account balances> (ICKTOSAL) into the transaction lists (ANLBEW, KAPBEW, RUEBEW, SPIBEW) now, too, if an account has the corresponding account characteristic 2.
The inter company balances of quota companies are shown at the branch from the report result list with proportionate values now in the rest value view of the ICKTOSAL so that the remaining value agrees with the shown rest value according to the report.
The transaction tables (capital, provision and individual transaction development transactions) were extended by attributes for the inter company and the inter company business unit (see above). These details are possible for accounts with account flags 'I' or 'J'. The combination inter company company/ic business unit is checked in accordance with the inter company account balances due to the setting of the fact and allocation table GESUBR. At missing entry a warning is output.
For transaction data (incl. fixed asset transactions) with entry of an inter company a validation is performed against the inter company account balances. Differences are notified analoguely to differences to the account balances and lead to the status <red> in the <company financial statement monitor> (EA). On the other hand transactions for automatic transaction developments (at definition of a posting key with usage flag 'L') are generated in detail to inter company if there are coherent inter company account balances.
A selection possibility for transaction development areas was completed in the list <individual development transactions> (SPIBEW) (see above).
At call of the list <individual development transactions> (SPIBEW) the transaction development 'S1' is no longer per default predefined but the respectively smallest one defined in application <description indiv. development transactions> (ISP).
When entering participations of foreign currency companies the pre-allocation of the conversion instruction is no longer 'SK' now so that if necessary divergent conversion instructions can be controlled by the application <Posting key conversion rules> (BSLUAW).
The automatic depreciation calculation in the company's financial statement still only works based on the acquisition/production costs (transaction development area of 'A') and the depreciation accumulated (transaction development area of 'B') although extended by further areas (see above). These additional transaction development areas aren't taken into account at the depreciation calculation.
In the forms entry application for account balances (I-KTOSAL) the help text to the respective account is shown at key <f1> now. This always refers to the account of the line in which the cursor is just placed.
If account balances shall be generated automatically from the transaction development transactions with the corresponding account flag 2 as defined for the transaction development by the flag 'A' in the fact master file (FAC), the corresponding account lines in the forms entry for account balances now are disabled for input.
The control sum per account displaying the difference between the sum of the inter company account balances and the account balance is shown <red> now. This control sum isn't in a column of its own any more.
The input field of the entry line always shows the currently calculated remaining difference.
The family of the forms entry applications was extended by a form entry application for fixed asset transactions. The call of this application is carried out via the menu tree in the node <Forms Entry>, via the short word I-ANLBEW or by branch from the forms entry for account balances (I-KTOSAL).
In this application values per fixed asset object and posting keys can alternatively be typed in one below the other or side by side in columns per posting key. The offered posting keys are defined by a new attribute in the posting key master data (BSL). This representation has the restrictions that per fixed asset account only one fixed asset object may be defined and that per posting key only one transaction may be entered.
Per input value additional attributes can be entered in two additional dialog boxes: one box for a remark, the transaction date, the IC company and the IC business unit, another box for details for the currency conversion in group and parallel currency.
Beside the entry field per fixed asset object there are lines and columns in which the sum of locked posting keys (e.g. for automatic carry forward), the sum of the entered values, the control value from the account balance as well as the currently remaining difference between account balance and fixed asset transactions is shown.
The operation of this application otherwise corresponds to the other forms entry applications.
Two new import applications serve for importing column options (SPO) as well as the individual transaction development definitions (ISP, ISS, ISB). A primary purpose of these applications is the import of standard scenarios for an extended fixed asset transaction development by posting keys, transaction development columns and report column options for Impairment and Fair Value as contained in the directory "LieferBatch" on the release-CD (see above).
The interpretation of the valid-till-date and the valid-from-date was faulty in several import applications. E.g. if the valid-till-date was given in the import file as "31.12.2005" this exact date was taken into the database with the consequence, that the master record was considered invalid for the period "12.2005". This error was eliminated in the import applications for currency codes (TXTWKZ), country data (TXTLKZ), accounts (TXTKTO), posting keys (TXTBSL) and fixed asset objects (TXTANLOBJ) now.
The import format for the account master data was extended by the new attribute for the quota reference account (see above).
The import format for posting keys was extended by the new attribute for the recording flag (see above).
The import format for report line descriptions was extended by the new attributes for colour control (see above).
The application <Import Report Column Descriptions> is displayed below in the branch <Master Data> now in connection with other report-related import applications.
The standard formats for the import of capital, provision and individual transaction development transactions were extended by the new attributes for inter company and IC business business unit (see above). The check of these attributes is carried out analoguely to the online entry.
Unfortunately, inter company balances delivered via the SAP interface with business units don't always have a correct inter company business unit either. To be able to import these data nevertheless, the check on a valid combination IC company/IC business unit was defused. If the actually necessary entry of an IC business unit is missing instead of an error message now a warning is output, which the user can ignore. However he has to complete the missing details to be able to execute a consolidation with business units.
The call application for the fact carry forward (GESABV) is displaying the individual transaction developments in single lines now. This makes it is possible to forward the data for one individual transaction development to the next fact independently from the others. The display of the individual transaction developments is limited to those defined in the application <description indiv. development transactions> (ISP).
GESABV displays a colour status now instead of a message code, which is determined exactly like in the company financial statements monitor (EA). The only exception is the easing of errors shown in the EA for companies which already have a departure date in the group companies definition (KTKGES) since the GESABV display is independent of the group companies. Till now a possible error was shown at different message codes per business unit although everything was correct.
Warnings concerning faulty data in the origin fact (such as missing inter company account balances) aren't displayed now any more since errors resulting from these discrepancies get visible anyway by the status colours in the invoking application (EA or GESABV). Till now a warning had to be confirmed per company, what particularly at the mass processing via the company financial statement monitor (EA) could be very beasty.
The table inter company stock capital (ICBEW) was included in the fact carry forward. The following restrictions apply to it, though:
Transactions (fixed assets, capital, provisions, individual transaction developments) with detail of IC company and if necessary IC business unit (see above) are forwarded differenciated with respect to these data, i.e. for each IC company / IC business unit a separate carry forward transaction is generated.
Carry forward of automatic transaction developments (with posting keys with usage flag 'L', also at automatic parallel development for transaction development without carry forward) always are based on the account balances of the previous period or on a simultaneous inter company detail based on inter company account balances of the previous period independent of the setting of the ABR-flag for this transaction development in the previous period.
If individual development areas are defined (see above), then the accompanying transactions (fixed assets, individual transaction developments) are differentially forwarded, i.e. per transaction development area a carry forwad transaction of one's own is created.
If after abolition of the parallel currency (e.g. till now still 'DEM') it arises for a company that all three currencies (local, group and parallel currency) are the same, the currency conversion header isn't forwarded any more now since it is superfluous.
If a currency conversion header (WUM) with entry of a reference company is to be forwarded and there is no currency conversion header for the referenced company in the destination period yet, then the currency conversion header of the referenced company as well as its account currency conversion rules (KTOUAW) also are forwarded, since otherwise the reported state wouldn't be consistent. A corresponding note is output in the message window.
If a consolidation function (KVA) 'Vn' ('n' = '0', '1' ... '9'; see above) is defined, 'Mn' and 'Ln' vouchers (according to the forward rules valid as hitherto) are carried forward into a new voucher with the consolidation function 'Vn' in the voucher number. If there is no consolidation function 'Vn', the carry forward is carried out like till now into a voucher with the consolidation function 'VM' in the voucher number.
Vouchers with the new consolidation functions (KVA) 'KK' and 'EK' (see above) are carried forward analoguely to the previous 'KE', 'KM' or 'EM' vouchers into a 'KF' voucher. A summary is performed with vouchers with the also new individual consolidation functions 'K0' to 'K9' or 'E0' to 'E9'.
If transaction development areas are defined in individual transaction developments (see above), then the accompanying consolidation postings (fixed assets, individual transaction developments) are forwarded to the forward posting key (posting key usage flag 'V') of the appropriate transaction development area.
Consolidation postings on accounts with account flag 2 = 'L' are always reposted on the account for net income(loss) of carry forward HBI (account with account characteristics 'X'). This was the case only for certain consolidation processings till now.
The account for net income elimination from the consolidation parameter 'KK' isn't used for carry forward postings now any more. The account for the net income from the consolidation parameter 'JU' of the previous period is used instead if available. If this isn't available either, the corresponding posting couple is dropped since it isn't needed for a continued group capital transaction development.
For equity companies postings of all consolidation functions are forwarded now. Only EM, EF and KF vouchers were processed till now.
In the function for deleting all transactions of a company financial statement forwarded transactions are excepted from deleting. This is analyzed due to the posting keys with usage flag 'V' now, so that the forwarded transactions for individual transaction developments are also excepted from being deleted. Transactions with posting keys with usage flags 'SV' (automatic elimination of carry forwards) 'M' (forward of monthly returns), and 'SV' (automatic elimination of these data) are excepted from being deleted, too.
FU vouchers (from the cash flow repostings) aren't processed when copying consolidation postings into a report technical sub group now any more. On the one hand, these vouchers yielded errors, because they represent a collecting voucher over all companies, which can't be classified as to be processed uniquely; on the other hand, the result anyway wouldn't be correct relevantly. When required the FU voucher can be created newly for the report technical sub group, however.
If a consolidation function (KVA) of 'Ln' ('n' = '0', '1' ... '9'; see above) is defined, deferred tax postings from 'Mn' vouchers are written into a new voucher with the consolidation function 'Ln' in the voucher number. If there is no consolidation function 'Ln', the LT postings are written into a voucher with the consolidation function 'LM' in the voucher number like till now.
The deferred tax on manual postings was completely posted on posting record '01' of the LM voucher till now even if the MB voucher used the posting records '01' to 'nn'. The LM voucher gets the same posting record numbers as the basic MB voucher in future.
The list of currency conversion headers (WUM) displays at selection for group companies the data for equity companies now, too. Missing currency conversion headers for equity companies aren't listed in the message window for missing currency conversion headers of group companies since they aren't always needed, though. Therefore furthermore equity companies are not taken into account at generation of currency conversion headers via action <Reference Company for Group>.
The currency conversion cares for an adjustment of rounding differences in group and parallel currency between inter company account balances and controlling balances now. It is prerequisite for it that the sum of the inter company account balances agrees with the corresponding controlling balance on local currency for a controlling object. The adjustment of the difference is carried out on the first inter company account balance per account and controlling object.
If transactions (fixed assets, capital, provisions, individual transaction developments) are held with detail of IC company and if necessary IC business unit (see above), these data are converted differentially, i.e. per inter company / business unit a conversion difference is calculated and posted. The consistency between development transactions and inter company account balances is maintained thereby.
The currency conversion was adapted on the use of individual transaction development areas (see above). Therfore the posting keys for conversion differences are determined due to transaction development area and usage flag in the fixed asset transaction development now, too. This has the consequence that the previous posting keys '32', '34', '35' and '36' aren't used any more. Among others currency differences of the regular depreciation (transaction development column '13') are reported no longer separately by it but they are contained in the currency differences of all depreciation changes of the current period (with BSL '38').
The conversion of the exchange rates when exchanging the currency data (WKZEXCH) was faulty since it didn't distinguish between closing rate and currency rate average per period. Average exchange rates are converted using the rate average per period of the previous group currency now. In addition, an exchange rate average per period is inserted for the previous group currency if not yet existing.
After the conversion no new currency conversion in the parallel currency was possible since on the accounts for currency differences in parallel currency there were values for in group currency. After the conversion no backward conversion was possible either since the balances on the currency conversion difference accounts didn't agree with the differences in the currency conversion header. Therefore the conversion of the differences and the balances on the difference accounts was redesigned. The accounts for differences in group an parallel currency aren't exchanged now any more just like the conversion methods and the exchange rate codes.
For this conversion the following constellations of the accounts are necessary in the currency conversion headers. Their non-compliance leads to a faulty break of the application:
The previous status columns 'KE' (manual first consolidation) and 'KM' (automatic first consolidation) were summarized to one status column 'KK' (see above).
For the capital first consolidation a status 'KK' which summarizes the previous separate status values 'KE' and 'KM' (see above) is now determined.
The debts and profit/loss consolidation between a fully consolidated and a quoted company eliminates only quoted amounts (in accordance with quota of the quoted company) of the inter company account balances of the fully consolidated company directly now, too. Thus the difference of the postings between the two companies is comparable and can be reprocessed in accordance with the rules for threshold value and transaction currency clearing. The threshold value itself is used as an absolute value, i.e. the quota is not applied to it.
The remaining part of the inter company balances of the fully consolidated company (100% - quota) is reposted in a further posting record from the inter company account onto the quota reference account if entered in the account master data (both postings at the same company). Thus from the view of the group report 100% of the inter company balances of the fully consolidated company and the quoted quota of the inter company balances of the quoted company are eliminated so that the inter company accounts show a group balance of 0.00.
In case that the quota reference account isn't entered in the account master data the second posting couple is omitted. If the account of the fully consolidated company has the account flag 'J', this is o.k. Otherwise the user has to repost the remaining amount on the inter company account manually.
In case both companies are quoted the posting rules are analogue. The inter company balances are eliminated with the altogether smaller quota for both companies. In the first step the postings result just like in the case of a fully consolidated company. If both companies have the same quota (e.g. 50%), the second step is omitted. Otherwise a posting couple is created for the reposting onto the quota reference account also here though only in height of the difference from the two quotas.
To allow a direct call by short word input of the application <inter company clearing list> (short word KGESGES), the application was supplemented in the menu branch <Group consolidation>.
The <repostings after elimination of intercompany accounts> simplifies considerably, if the company's financial statement development transactions are maintained with detail of the IC company and if necessary the IC business unit (see above) particularly at consolidation of the inter company balances of a company at different group levels. These details are then evaluated and only those development transactions are reposted, whose IC company also is consolidated at the respective group level. By this means the necessity of manual adjustments of the generated SU vouchers is omitted.
The differences between a manual and automatic first consolidation were suspended largely (see above). An automatic or a manual first consolidation can be carried out now independently of the posting key of the participation change. Transactions which had already been processed in the automatic first consolidation also still can afterwards be modified with the help of the manual first consolidation. When starting the manual first consolidation the first time, those capital postings are automatically suggested, which would have been generated by the automatic first consolidation so far.
The capital consolidation vouchers receive independently of the processing function the consolidation function 'KK' in the voucher number. 'KE' and 'KM' aren't used any more.
To still be able to distinguish several processes within a period (e.g. historical setting of the participation to Jan. 1st, till now by KM voucher, and participation increase at Apr. 1st, till now by KE voucher) new consolidation functions of 'K0', 'K1' etc. are supported, which have to be defined before via the application <Consolidation functions> (KVA). Then a separate voucher also can be created and the difference compensated separately via the application VUB if in the example another participation increase happens at July 1st.
In addition, in the application <manual first consolidation> (KONKTO) a new flag "sum of all participations" can be used for a balanced consolidation of all share holding changes in one transaction independant from the transaction date. This covers increases of capital and participation disposals as well as participation additions. So e.g. the historical development of the share holding can be represented in GESGES without the changes having to be processed one by one in IDL Konsis.
The <repostings after change of the company group> is differentiating into transaction development areas now (see above) provided that transaction developments are defined in this way. I.e. every company financial statement transaction is reposted to the posting key with usage flag 'E' or 'F' which is defined to the same transaction development area.
For a transaction development with an automatic auxiliary calculation for the purpose of cash flow reporting (in which contra-entry posting keys with the use characteristic 'SV' are defined) also posting keys with the usage flags 'SE' or 'SF' are needed for the reposting of the corresponding transactions.
If for a transaction development or a transaction development area respectively no posting key for reposting (with usage flag 'E', 'F', 'SE' or 'SF' respectively) is defined, this no longer is reported as an error but rather a message is output, that the corresponding reposting was not performed. The status of the first or final consolidation particularly isn't influenced by it any more either.
An automatic equity first consolidation also gets possible in connection with the standardization of the capital consolidation (see above). The created vouchers receive independent of the function of the consolidation function 'EK' (till now 'EM'). To be able to distinguish several participation changes within a period also for the compensation of differences individual consolidation functions 'E0', 'E1' etc. can be defined in the application <consolidation functions> (KVA), which then are used for the voucher numbers of additional vouchers.
Capital transactions with posting keys '01' and '17' aren't taken into account at the elimination of the direct minority interests of the equity capital on basis of capital transactions (if a KA carry forward to a KV voucher exists). These proceedings are also used for the elimination of the direct and indirect minority interests of the net income based on capital transactions to reduce the number of consolidation postings which cancel each other.
The <Compensation for the result of the group companies> (JU) is differentiating for posting record at the classification of vouchers according to postings affecting net income and others now.
For posting records affecting net income the balance sheets compensation is executed for balance sheet postings as for p&l postings till now on the annual result account defined in the consolidation parameter (KTKPAR) 'JU'.
For the compensation of the result effective postings into the equity capital transaction development the posting key '31' was used till now which affects column '10' (consolidation postings at capital) of the capital transaction development. Now posting key '25' is used which affects column '05' (P&L appropriated current period).
The automatic depreciation calculation in the group statements still only works based on the acquisition/production costs (transaction development area 'A') and the depreciation accumulated (transaction development area 'B') although extended by other areas (see above). These additional transaction development areas aren't taken into account at the depreciation calculation.
The mass copy of consolidation vouchers and postings is possible now, too, if the parallel currency of origin and destination area is different. The parallel currency values then are set to zero.
The report line structure also is displayed in the application REPZEI in tree structure now in case of error. All lines as of the first faulty line simply are then put in independently of given reference positions at the topmost level.
The table for report line descriptions was extended for three attributes for '< 0', '= 0' and '> 0' which can get the contents <empty>, <green>, <yellow> and <red>. The application <Report line definitions> was extended for the display or care of these attributes. These attributes are evaluated by the report result display for the background colour of certain values (see above).
The application <Report column descriptions> (SPA) got two additional functions (actions) to create gaps for additional columns or close gaps in an existing column option. Copying and deleting of the following column names is made less circumstantially now in one step incl. the assigned formulae by these actions.
By the introduction of dummies for report column headings sometimes the texts are the same for many columns also in different column options. To change several column texts uniformly, a mass update function was supplemented in the application <Report column descriptions> (SPA) for the description 2.
'25' (condition control) aren't available the previous operands '# REP #' for these purposes any more since up to 50 report result values can be used for transaction development reports now (see above)/'21' (sum AHk in the fixed asset transaction development), '# REP #'/'22' (sum depreciation in the fixed asset transaction development), '# REP #'/'23' (grand total of all transaction development columns) and '# REP #'/. '' 25 are' future place '# REP #'/'23' and '# REP #'/# REP # '/'SUM' or '# REP #'/to use 'BED'. '22' '# REP #' isn't in this meaning at the disposal any more and must if necessary be replaced by a sum of all AHk or depreciation columns/'21' and '# REP #'/. The former operands '#REP#'/'21' (sum acquisition/production costs in fixed asset transaction development), '#REP#'/'22' (summe depreciation in fixed asset transaction development), '#REP#'/'23' (total of all development columns) und '#REP#'/'25' (condition control) are no longer available for these purposes since up to 50 report result values may be used now (see above). Instead of '#REP#'/'23' and '#REP#'/'25' '#REP#'/'SUM' or '#REP#'/'BED', respectively, are to be used. '#REP#'/'21' und '#REP#'/'22' are no longer available in the original meaning and have to be replaced by an explicit sum of all acquisistion/production cost columns or depreciation columns, respectively.
The display parameter "key column" of the report result display (REPERG) controls whether the key shall be displayed even in a column next to the key translation or not. This parameter can be initialized by an attribute of the report header (REP) analoguely the columns and the detail option now.
Since the possibility of providing the display parameters detail option and column option (and now also key column) with default values via the report headers exist, users create identical reports repeatedly, only to display them with different display parameters comfortably. The result is a large set of superfluous data in the database.
The report header was therefore extended by an attribute for a reference report version. There the version number of a report already defined can be entered which then may not indicate another reference version. Reports with detail of a reference version cannot be created. They display the report of the referenced version provided with another pre-allocation of the display parameters.
If for a report line a colour control is defined (see above), the accompanying values are represented in traffic lights representation, (i.e. with coloured background). The colour control for the cell overrides the colour control for the line. For the time being, a restriction on certain columns isn't carried out.
For reports with detail of a reference version the report of the referenced version is shown provided with the pre-allocation of the display parameters (detail option, column option, key column) of the current version.
The detail option 'B' is used at the call of the detail view for a ratio (value flag = '7') analoguely to value flags '0' and '4'. The detail option in addition always becomes '1B' or '1BK' adjusted then when the column option has a type detail.
The new standard column option "#ROHTK" was introduced for the group b/s/p&l report. This displays the statement of accounts per sub group, the consolidation postings and the group result in columns of its own. "#ROHTK" therefore acts in the group report analogue the column option "#ROHGE" in the company report only with sub groups.
In the fixed asset transaction development the report result values (transaction development columns) '21' and '22' no longer represent the sums of acquisition/production costs or depreciations, respectively, since these columns can be defined individually now (see above).
A new transaction development column ('12') was introduced for transfers in the equity capital transaction development. The posting keys '17' and '34' used for the transfer of the net income to the account for retained earnings are assigned to this column. These posting keys had been assigned to the carry forwad column till now.
The standard column options for the capital transaction development ("#KAPG" and "#KAPK") were supplemented with a report column description (SPA) for transfers. This column is displayed as the second column besides the carry forward column. All further columns are moved to the right at 1. Customer individual column options for the equity capital transaction development have to be modified analoguely!
The sub group data interchange was adjusted concerning different database table extensions. The additional attributes (e.g. IC company for transaction development transactions) aren't transferred into databases with an older release.
Report results aren't accepted from versions previous to IDL Konsis 5.4.2 at the take-over of sub group data since the table structure has changed. A message (KON1727W) is output in the message panel and in the log file.
The group-wide data exchange was adjusted concerning different database table extensions. The additional attributes (e.g. posting key forms entry column number) aren't transferred into databases with an older release.
The extensions at the IDL Connector are documented separately.
The transaction type key MAFAZ is turned over by the SAP interface now into the posting key 'A05'.
A path which refers to the folder where the SAP Java Connector is installed can be entered now in the <SAP Options> dialog in the section <connection>. This entry is then saved in the kcusap.ini file.
For the topic
a newly revised and cross-application documentation was created. This documentation is in German and English at the disposal and obtainable in the resource tree in the menue <Company financial statements> -> <Currency conversion>. It isn't contained in the "doku" directory of the CD as separate pdf document, however, it can be generated any time via the symbol <Export as pdf> in the online help text viewer when required. The application help of the accompanying applications (<F2>) now contains only a reference to this cross-application documentation.
With this release the following English-speaking documentations in the doku directory are updated or completed:
The documentation of the currency conversion is no longer present, since an updated documentation now is available online.