The release 2006.1 is an interim maintenance and therefore may be left out in the release sequence. Prerequisite for this release is the last main maintenance 2006.0 of Sept. 17th 2006.
The supplements and corrections to the last main maintenance released until Febr. 9thd 2007 are contained in the current interim maintenance.
This documentation describes the enhancements since the previous main maintenance 2006.0.
Group transaction development reports and group cash flow reports containing disposing companies do not yield the same report result compared to previous releases due to the modified proposition of the new deconsolidation (a balance sheet for the disposing company has to be delivered, that is included in group financial statement). In these cases group reports should be generated newly only if the deconsolidation has been processed with the current release 2006.1.
I.e. you sholdn't generate group transaction development reports or group cash flow reports for closed periods, if they contain disposing companies. However, this change has no influence on b/s or p&l group reports since these reports already considered account balances of disposing companies (with entry of a disposal date in the group companies (KTKGES)).
The development planning of IDL provides that group transactions (fixed assets, capital and provisions) are no longer supported with one of the next releases, since these data are redundant to the consolidation postings and don't contain additional information. Therefore the users are challenged
As announced for more than one year the IDL Connector does no longer support the version MS Excel 97 with the current release, particularly since the hotline service was also ceased meanwhile for MS Excel 97 by Microsoft. Please upgrade to a newer Excel version.
The old application server (only solution up to release 5.3.1) will no longer be supported with the next main maintenance planned for September 2007. Only the new application server (available since release 5.4.0, standard solution since release 5.4.1) will be supported. Please update to the new application server in time if you are using the old application server.
When differentiating data for business units a frequently used constellation is to segment only p&l data while b/s data are declared for the complete company. Since IDL Konsis doesn't allow such mixed states also b/s data have to be allocated to a business unit, either one of the p&l business units or a business unit of its own.
IDL Konsis verifies the consistency of the net result of b/s and p&l also in these cases. For this purpose a compensation account has to be defined, that yields the result of the p&l business units as a b/s account, e.g., while it provides a net result of 0,00 for the b/s business unit. Thus the total net result of all business units corresponds to the net result of the company.
IDL Konsis now supports this constellation. For this purpose the table "Company Business Unit Allocations" (GESUBR) was extended by an attribute "Account Group" which specifies, whether a business unit serves only for b/s or only for p&l data. The following definitions are allowed:
All applications for entry or import of company's financial statement data with business unit now also check, whether the b/s + p&l code of the corresponding account accords with the account group ('B' or 'G') entered in GESUBR. In case a warning is output.
In addition an automatic compensation of the differences in the net result is provided for all business units with entry of an account group if a compensation account is defined. This compensation account is specified by the account flag 'U' in the chart of accounts. If this is a b/s account the net result is the total of all p&l balances, i.e. zero for a b/s business unit (account flag 'B'), the other way round for a p&l account as compensation account, respectively.
Note: There is no automatic check of the sum of all balances on the compensation account. The user has to provide consistent data so that this sum of all business units results zero. A corresponding hint is given when entering an account group in GESUBRE.
In some cases development transactions only serve for historical currency conversion (conversion rule 'FDK') of equity capital or shareholdings. Then capital transactions were defined for companies with foreign currencies only, fixed asset transactions even then only for shareholding accounts. The enhanced company financial statements status display in the group companies monitor (KTKGES) introduced with release 2006.0 now became <red> at least for all companies with foreign currency, although the data were correct from the user's point of view.
For these cases now the position '0' was suppelemented for the flag for development transactions of the period (ABR). Like the value '0' of the flag for controlling balances of the period (FAC) this means, that development transactions are optional per company and account. With the position '0' an error (status <red>) only then is reported, if there are development transactions whose total doesn't agree with the account balance. The user is responsible for his own, that development transactions are present for the respective companies and accounts.
Since this flag is allocated to the period you can control, that development transactions have to be complete for the annual financial statements, however restricted to certain companies and/or accounts for interim financial statements.
The automatic desconsolidation (disposal of a company from the company group) was redesigned completely.
The new concept is based on the statement, that the financial statement of a disposing company at the disposal date is part of the group financial statement (balance sheet, p&l, developments, cash flow). In case the interim balance sheet at the disposal date has to be copied into the year end period. These data then also are concerned in the subgroup data exchange (KONDAT).
Like up to now the disposal from the company group is defined by a shareholding transaction (GESGES) with posting key '03' and entry of the disposing percentage and a disposal date in the company group monitor (KTKGES). For exact calculation of the participation percentage at the disposal time this has to be a date. The entry format was changed correspondingly (up to now a period).
In addition the following new attributes have to be entered for the shareholding disposal: Result value for disposal, b/s + p&l code of this value, account for result of disposal.
The posting records '01' to '08' of the new 'KS' voucher eliminate the postings on b/s accounts with the same posting record number of the 'KF' and 'KK' vouchers. Postings on the accounts for net result and retained earnings are excluded.
Posting record '00' of the new 'KS' voucher eliminates the pro rata account balances of all b/s accounts. Accounts with development details are eliminated per column and with respect for the posting key for disposal from group companies (usage tag 'F').
The result of these postings (i.e. the remaining difference per posting key) is posted onto the account for deconsolidation result (from consolidation parameter 'KK') at the disposing company. If results out of the membership in the group had been reposted (e.g. from retained earnings to reserves) then these amounts have to be reposted to the retained earnings in the company financial statement oder in the 'KF' voucher before deconsolidation to show these amounts as result from deconsolidation.
The result value for disposal entered in the shareholding transaction (GESGES) is reposted onto the account for desconsolidation result, too. These postings are put into posting record '01' of the 'KS' voucher at the disposing company.
An own account for deconsolidation of minority interests was supplemented in the consolidation parameter 'KA'. Postings for deconsolidation of minority interests are written into an own voucher with consolidation function 'KX' in the voucher number.
The posting record '01' of the 'KX' voucher with one company in the voucher number eliminates all postings on the account for minority interests (from consolidation parameter 'KA') of the posting record '01' of the 'KA' and 'KV' voucher with one company in the voucher number (direct minority interests).
All postings on the account for compensation of minority interests in the posting records '02' of 'KA' and 'KV' vouchers with one company in the voucher number are eliminated, too. These postings are put into posting record '02' of a 'KX' voucher with one company in the voucher number.
All balances on b/s accounts (except for capital accounts and the difference compensation accounts due to consolidation parameters 'KA' and 'KK') of the disposing company are eliminated with the direct minority interest. These postings are put into posting record '00' of the 'KX' voucher with one company in the voucher number.
Remaining differences are posted on the account "result from deconsolidation" from the consolidation parameter 'KA' at the disposing company for each posting record.
All postings on b/s accounts (except for the account for retained earnings from consolidation parameter 'KK' and the net result account with account flag 'E') of the 'KA' and 'KV' vouchers with two companies in the voucher number (indirect minority interests) are eliminated in a 'KX' voucher with two companies in the voucher number with the same posting record number. Remaining differences are posted on the account "result from deconsolidation" from the consolidation parameter 'KA' for each posting record.
'ZA' and manual postings carried forward (i.e. 'VX', 'VA', 'VM', 'V0', 'V1' ... and 'V9' vouchers) are eliminated. This concerns all vouchers with the company number of the disposing company in the first or second position of the voucher number. This also concerns postings for other companies than the disposing one. Postings on transaction development accounts with posting key for carry forward (posting key with usage tag 'V' or other posting keys for the same development column) are reposted with the posting key for group companies disposal (usage tag 'F'). Exception: postings on the accounts for retained earnings (account flag = 'X' or according to consolidation parameters 'KK' and 'KA') are not eliminated on this account but on the account "result of deconsolidation" of the consolidation parameter 'KK'. These postings are written into a voucher with the same companies in the voucher number as the origin voucher but with the new consolidation function 'KY'. Thus a voucher '001 002 VM' provides a voucher '001 002 KY'.
Furthermore the deconsolidation function checks whether all consolidation postings for the disposing company are included in vouchers that contain the number of the disposing company in the voucher number. Otherwise a warning is reported.
If a parent company is deconsolidated the shareholdings of its child companies remain unchanged. Nevertheless the child companies dispose from the group companies and thus have to be deconsolidated. This constellation is to be described by a disposal and an addition of shareholdings (GESGES) with the same transaction date in connection with a disposal date in the group companies (KTKGES). Then the deconsolidation handles the disposal but doesn't concern the addition. On the other hand the first consolidation doesn't concern the addition, too, since the addition date is greater or equal to the disposal date in KTKGES.
The development reposting for group companies disposal is integrated in the new deconsolidation. Thus it is omitted as a function of its own. 'SU' vouchers are no longer created, too.
If a goodwill is capitalised in capital consolidation due to IFRS then currency effects have to be concerned in subsequent periods. Thus the goodwill value in local currency has to be entered and maintained. This entry occurs at capitalisation of the goodwill in the compensation of differences from first consolidation (VUB). It is stored in a new attribute of the fixed assets master data (ANLOBJ).
Since, due to IFRS, no depreciation is provided for goodwills the entry fields for depreciation parameters are omitted. The new fixed asset object always yields the depreciation type 'K' (no depreciation).
Furthermore, now it is supported to capitalise the goodwill for another company than the acquired one. You may enter a company and also a currency code in "Capitalise Goodwill IFRS". However, the company is preset with the acquired company and the currency code with its currency code, so that usually no additional entries are required.
Because of the characteristics of the function for copying consolidation postings for report subgroups a voucher may only contain postings for companies whose company number is contained in the voucher number. Therefore the posting of the goodwill due to IFRS is not put into the 'KK' or 'EK' voucher with two companies in the voucher number (like up to now) but rather into a 'KK' or 'EK' voucher with one company in the voucher number (namely the goodwill company). Since a 'KA' voucher with one company number in the voucher number already exists for minority interests, here a voucher with the new consolidation function 'KG' is created.
A compensation account is required to provide coherent posting records. This is the account for "Reserve Goodwill IFRS", that has been supplemented in the consolidation parameters 'KK' and 'EK' (for facts with accounting standard 'I' = 'IFRS'). The difference amount is posted contra this reserve account at the child company in posting record '02' of the 'KK', 'EK' or 'KA' voucher. The voucher with one company number yields postings from goodwill contra the reserve account at the goodwill company. Several goodwills for the same company are distinguished by different posting records. These two pairs of postings are linked in the way, that deletion of one pair automatically provides the deletion of the other pair.
The fact (FAC) has to be provided with accounting standard 'I' (IFRS) to trigger these new rules. Then the action menu of "Compensation of Differences from first Consolidation" (VUB) is reduced to the compensation types in accordance with IFRS "Capitalise Goodwill (IFRS)" (new), "Defer temporary Difference Amount" and "Other Clearing". Without accounting standard 'I' the action menu remains as comprehensive as up to now. Then with "Capitalise Goodwill" the extended functions (entry of value in local currency, deviating goodwill company) are not placed at the disposal.
A 'KK' or 'EK' voucher with one company is carried forward into a 'KF' voucher with one company in the voucher number and in case merged into an existing 'KF' voucher. In the same way a 'KG' voucher is carried forward into a 'KV' voucher. This happens in the common group carry forward as well as in the function "Sequent Consolidation (KF)" for one company. Within carry forward the exchange rate differences on the stored local currency amounts are calculated and posted (goodwill contra compensation of currency differences). If the exchange rate difference cannot be determined due to (yet) missing exchange rates or currency conversion headers the 'KF' status is set to <yellow>. After supplement of the missing data the sequent consolidation (KF) has to be repeated or the new special function "Curr.conv.diff. goodwill IFRS" has to be performed to get 'KF' status <green>.
The closing rate has to be corrected by an index for companies with high inflation rates at calculation of currency effects. For this purpose a closing rate corrected by this index may be entered with exchange rate type 'SKH' (closing rate for hyperinflation) into the table of exchange rates (WKZWKA). If this is defined the exchange rate effects are calculated with 'SKH' exchange rates instead of 'SK' exchange rates.
A later reposting of goodwills to other companies is not supported automatically but has to be posted manually. At change of the fuctional (local) currency of the goodwill the circumstance should be reposted to a new fixed asset object to be able to reconstruct the history.
If the company that caused the goodwill disposes from the group companies nevertheless a goodwill posted at another company remains. Deviations have to be posted manually, too.
You now can enter for a equity capital account, whether differences between equity capital of the company's financial statement and the equity capital posted in the capital consolidation shall stay on the respective account or shall be reposted on a so called "Difference Amount Capital Sequent Consolidation" account. With the aid of this function you can achieve zero balances from the group point of view for certain capital accounts.
For this purpose the attribute "Reposting to Sequent Consolidation Account" was supplemented in the account master data. This flag is only to be set for equity capital accounts and thus is located as extension of account flag 2 in the map KTOE. An empty value means like up to now: no reposting.
The "Difference Amount Capital Sequent Consolidation" account used for this reposting was supplemented in the consolidation parameter 'KK'.
The new function for calculation and posting of these difference amounts is called per company as a subsequent function of "Group Companies + Monitor" (KTKGES). The action was supplemented in the submenu for capital consolidation. The vouchers generated by this function yield the consolidation function 'KB'. The function also provides a new status column 'KB' in the "Group Companies + Monitor" (KTKGES). The status is set to '-', if no postings were created, or 'X' (<green>), if a 'KB' voucher were created. This status display is based on an entry in the table for group processings (KVERARB) with check point 'UBFOLKON'.
Precondition for the generation of a 'KB' voucher are equity capital accounts with flag "Reposting to Sequent Consolidation Account" set in the account master data as well as the entry of a "Difference Amount Capital Sequent Consolidation" account in consolidation parameter 'KK'. For the labelled accounts on the one hand the account balances or, if present, the capital transactions, respectively, on the other hand consolidation postings in 'KF' and 'KK' vouchers are read and accumulated. If the shareholding of the group for a company is less than 100% the account balances are multiplied with this interest (the rest is proceeded by the minority interests in the 'KA' voucher). The difference between the company's financial statement and consolidation postings ist eliminated by a 'KB' posting. The contra posting is done on the "Difference Amount Capital Sequent Consolidation" account.
If the shareholding values have changed simultaneously, they have to be proceeded by the first or deconsolidation before "Difference amount subsequent consolidation (KB)". These postings ('KS', 'KK', 'K0', 'K1' etc.) are considered in addition to 'KF' postings.
'KB' vouchers are considered in the general group carry forward as well as in the subfunction "Sequent Consolidation (KF)" per company. They are carried forward into a 'KF' voucher. The consolidation report allocates 'KB' postings to the column for capital consolidation.
If the interests in quoted companies have changed compared to the previous period, this change has to be reported for transaction developments in the way, that the interest of the last year is reported as carry forward, while the resulting difference has to be reported in a column "Quote Changes" (similar to a column "Addition/Disposal from Group Companies"). The case of a fully consolidated company becoming quoted or the other way round has to be handled analogeously.
The change of a quota can be determined only with respect to a group/subgroup. Therefore this desired reposting cannot be performed in the company's financial statement but rather by consolidation postings on the respective group/subgroup level. If necessary this reposting has to be performed on each group/subgroup level newly.
A corresponding function now has been supplemented in the application "Quotal Clearing (QU)", that provided a compensation of rounding differences by quotal calculation for the net result. Thus a new function and an additional status column are omitted. This application didn't create consolidation postings up to now. Therefore new consolidation vouchers with consolidation function 'QU' are generated.
For the creation of consolidation postings the following preconditions have to be fulfilled:
Then repostings are provided for all carry forward transactions, i.e. automatic carry forward as well as manual transactions. It is assumed that these posting keys are subsumed in a development column for carry forward. Therefore the development (or each development area, respectively) has to contain a posting key with usage tag 'V'.
Fully consolidated companies are always calculated with 100%, since 100% of the company's financial statement are concerned in the group financial statement. The real shareholding percentage is irrelevant.
Since 'QU' postings concern the column for carry forward with being carried forward from the previous period they may not be processed in the "Cash Flow Repostings" (FU). They may not be concerned in the "Check Carry-forward New Period", too. They are excluded (like 'KU' postings).
Subgroup postings that are not correct from the point of view of the superordinate group have to be corrected in the superordinate group. This is achieved (like in other consolidation functions) by eliminating the subgroup postings and calculating and posting the postings for the current group/subgroup level newly. If the company is quoted in the subordinate subgroup only but is fully consolidated in the superordinate group this function also has to be performed for fully consolidated companies. This is also valid, if the company is fully consolidated in the current period but was quoted in the previous period.
"Calculation Participations & Layer" performs a corresponding check to set the 'QU' status to <red> if this function is to be performed. The status is set to <green> by "Quotal Clearing (QU)", if a 'QU' voucher or a difference account balance (function up to now) has been created. Otherwise the status is set to <->.
Several report functions have been supplemented. Besides others these are:
The status (e.g. in the applications "Comp.financ.stmts + monitor" (EA) or "Group companies + monitor" (KTKGES)) now can be displayed by symbols instead of coloured cells:
Via the options dialogue (menu bar -> Options -> Options... -> View) each user can select, whether the status shall be displayed with coloured cells (as up to now) or with the new symbols.
Up to now for triggering a line action the line first had to be selected with the left mouse key before the action menu could be opened with the right mouse key to select an action. Now the line of the current cursor position is seelcted at click with the right mouse key, too, if no other line had been selected yet. Thus in many cases one mouse click can be saved.
However, if more than one lines has been selected already (using the left mouse key) then the right mouse key provides no additional selection. Thus a list of lines to be processed cannot be destroyed with the right mouse key.
If additional entry fields suppressed before are needed after a first action <Display> these fields are supplemented automatically. However, the size of the selection area was not adjusted leading to a shortened display of fields and buttons. Now the size of the selection area is adjusted automatically.
The first line of any message window now always shows the current IDL Konsis version. Among others this serves for correct allocation of screenshots sent to the IDL hotline to the IDL Konsis version.
The display of a connection mode was supplemented in the info box (Menu bar -> Help -> Info...). This information serves for distinction between start of the application via application server or via common client.
In special cases (e.g. activation of test aid for error analysis) the user has to perform entries in the ini file. However, sometimes the users don't have the right to open the IDL Konsis linkage. Therefore the name and path of the ini file as well as the work directory are displayed in the info box, too.
At start of IDL Konsis for a short time the information is displayed (on the so called splash screen), for which customer and with which serial number the IDL Konsis installation was licensed.
The display of the detailed licence informationen (menu bar -> Help -> Licence info...) was designed much more clearly.
The list application "Group companies + Monitor" (KTKGES) now checks, whether the number of consolidated companies (consolidation type 'V' or 'Q') exceeds the corresponding number in the licence file. If this is the case a warning is reported with the advice to refresh your licence.
Since Update A for Release 2006.0 the copy of data into the clipboard contains format descriptions for MS Excel (coloured background of columns, lines and cells als well as format types of columns, e.g. account numbers as text field to avoid truncation of leading zeroes). This process now could be accelerated considerably.
Vertical lines (so called pipe symbols), that were used in the IDL Konsis definitions for line feed in table headers, are now suppressed. However, a line feed doesn't work in MS Excel.
The converting program for this release performs the following changes in the database:
The following menu IDs are new in this release. 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 menu items MISSPR und MISSPRE have been dropped.
An entry field for the e-mail address was supplemented in the user table (USE). Here an address up to a length of 100 characters may be entered. For the time being this entry is just for information, however, in future it might be used for an automatic e-mail delivery.
The deletion of users without extra authorisation for user administration (USEE) is now possible analogue to the insert of a new user, if the user to be deleted possesses the same or less authorisations than the current user.
The root menu item "Metadata Maintenance" (serving only for metadata maintenance by IDL) now is suppressed for authrisation group IDLADMIN, too. It was already suppressed for all other standard authorisation groups before.
The form entry applications were pooled in a menu node for its own ("Forms data entry" between "Masterfiles" and "Comp. financial stmts.") in the menu tree for IDL WinKons. The menu "Reporting" was enhanced by the menu items "Reports in group structure" (REPSTR), "Report" (REPERG), "Report mirrored" (REPERGS) und "Position balances ex reports" (POSSAL), that up to now could be invoked indirectly as subsequent actions only.
A new sub-node "Report result display" was supplemented in the node "Reporting" in the remaining product versions. This node contains the menu items "Report", "Report mirrored", and "Position balances ex reports" located one level upper until now. Usually these applications are not called directly but rather as a subsequent application of the report lists.
An attribute "Reposting to Sequent Consolidation Account" was supplemented in the account master data. This flag may be set for capital accounts only and thus is allocated to the account flag 2 in the map KTOE (see above).
Accounts with account flag 'J' now may be entered as reference account consolidation D&C. Accounts with account flag 'I' still are excluded from entry.
For the purpose of Goodwill Pushdown Accounting the table for fixed asset objects (ANLOBJ) was extended by the attributes "Amount local currency" and "currency code" of this amount.
An account without account flag 'D' now may be entered as account for depreciations, if no such account is defined in the chart of accounts. Without usage of account flag 'D' the otherwise obligatory check between fixed asset transactions for column '13' (depreciations current period) and corresponding p&l accounts can be suppressed.
For display and maintenance of intercompany fixed asset objects (for elimination of fixed assets results, 'ZA') now distinct applications ICANLOBJ and ICANLOBJE were built. Here only fixed asset objects of card type 'A' (IC disposal) and 'Z' (IC addition) can be administrated.
For the time being the applications ANLOBJ and ANLOBJE still can administrate fixed asset objects of card type 'A' or 'Z' in principle, however, the special attributes for intercompany fixed asset objects (income account, Selling to IC company, fixed asset origin card) are no longer available.
The directory "LieferBatch" on the release CD was extended by definitions for a transaction development for finance objects as individual transaction development 'S8'.
Definitions for other transaction developments in this directory were revised in parts (e.g. supplement of english translations).
The documentation of the directory "LieferBatch" was revised, too, and is now accessible online (menu tree IDL Konsis 2006.1 -> Information and documentation -> Application guides -> Batch files for supplement of standards in directory LieferBatch).
The export format of the list applications "Description indiv. development transactions" (ISP), "Column description indiv. development transactions" (ISS), and "Description development areas" (ISB) were converted to the standard import format (#TXT) for transaction development definitions, so that exported data may be imported via TXTIS.
The form entry for fixed asset transactions (I-ANLBEW) requires unique specifications per posting key, whether a positive input value is to be treated as a debit or a credit amount. Thus all posting keys delivered by IDL as metadata as well as additional optional posting keys in the directory "LieferBatch" were assigned to a default debit/credit flag. It is recommended to assign other individual posting keys to a default debit/credit flag, too.
A selection control for "valid from" and "valid until" period was supplemented in the list application "Posting Keys" (BSL). This selection works analoguely to the corresponding selections in "Accounts" (KTO), "Controlling Objects" (KST) and "Positions" (POS). I.e. all posting keys are displayed, that are at least partially valid in the given range of periods. For example if entering a "valid from" period all posting keys are excluded that were valid before this period only.
A new usage tag 'Q' was invented for the new function of "Transaction Development Repostings of Quota Changes". It designates posting keys which serve for changes of quota. For transaction developments with automatic elimination (for cash flow reporting) there also is the usage tag 'SQ' to eliminate the postings with the 'Q' posting key.
The table for company business unit allocations (GESUBR) was enhanced by an attribute "account group" (see above.).
The list application "Periods" (ABR) now supports mass update of the flags for the different detail data (all kinds of transactions, shareholdings, intercompany account balances, controlling balances).
The flags for development transactions now can be set to the new value '0', if the details shall be entered incompletely (only certain accounts or companies) (see above).
In some cases the short word of a fact is used in the column header of a report. Therefore it is now a mandatory entry field.
The status "Currency conversion" for companies consolidated at equity (consolidation type 'E', i.e. only at selection for group companies) is now displayed as <-> instead of <red>, if the processings table (VERARB) doesn't contain an entry for check point 'WUM'.
Up to now the release of a company financial statement was only allowed with a unique entry of a business unit (i.e. with entry '*' when working without business units), although the function works for the complete company, since the release always was combined with a check and refresh of the status information, which may be performed for unique business units only. Since the status is refreshed at each change of company financial statements data completely, this conjunction can be dropped. When releasing a company financial statement no longer a refresh of the status information is triggered. Thus the release function may be invoked without unique entry of the business unit.
When calling "group companies + monitor" (KTKGES) now no longer a company is delivered as parameter, so that the complete group companies are displayed.
When calling the individual development transactions (SPIBEW) via action menu no parameter for the development (e.g. 'S1') is delivered. Then the entry of the default development happens just like calling the list application SPIBEW directly via short word.
At entry of reported data it is checked, whether a given account number is in accordance with the "account group" entered in the company business unit allocations (GESUBR) (see above).
If the processing records (VERARB) for the selected data contain message numbers a message is displayed in the selection area of account balances (KTOSAL). This message even was displayed if e.g. several companies were selected but only one account. In this case a message like "no data existing" is confusing since evidently data are existing. Therefore this message now is displayed, if
IC account balances on accounts with account flag 'J' are checked against account balances in the following way: The sum of the IC account balances must neither exceed the account balance nor result in the opposite debit/credit flag. Deviations provided an error status display (red). Since several users reported these deviations to be intended, they now are displayed as warning status (yellow). This concerns the company financial statement monitor (EA) as well as the account balances list (KTOSAL).
The display with interchanged couples of companies at IC-Sel option 'SK' oder 'AE' (display of balances of company A with respect to IC company B followed by balances of company B with respect to IC company A) now can be called even if the company is not entered uniquely. However, precondition then is the entry of a group for selection for all group companies in the interchanged couple view.
The automatic check of accordance between fixed asset transactions for transaction column '13' (depreciations current period) with acoount balances of p&l accounts with account flag 'D' now is performed only if any account with account flag 'D' is defined in the chart of accounts. This change was possible, since the depreciation account in the consolidation parameter 'KK' (mandatory entry, see below) now may be an account without account flag 'D', if no such accounts are defined in the chart of accounts.
For display and maintenance of intercompany fixed asset transactions (for elimination of fixed assets results, 'ZA') now distinct applications ICANLBEW and ICANLBEWE were built. Here only fixed asset transactions for fixed asset objects of card type 'A' (IC disposal) and 'Z' (IC addition) can be administrated.
For the time being the applications ANLBEW and ANLBEWE still can administrate fixed asset transactions for fixed asset objects of card type 'A' or 'Z'.
This enhancement was introduced with respect for the planned abolition of group transactions (see above). Then the applications ANLBEW and ANLBEWE will only serve for administration of fixed asset transactions of the company financial statements. Since intercompany fixed asset transactions continue to be required for elimination of fixed assets results, these new applications are required.
These three attributes were supplemented in the table for shareholdings/participations for the redesigned function for deconsolidation in case of group companies disposal: Amount of profit or loss of disposal, debit/credit flag for this amount, and account for this amount. These attributes have to be entered at disposal from group companies (posting key '03').
The behaviour at double mouse click on a line of the list application vouchers (BEL) was revised depending on the current column:
The call of the single record application for postings (BUCHE) now is possible independent from the sort option. This is valid for the action "Delete", too. Just for the entry of a new posting without draft (i.e. without a selected line in the list) the unique entry of a voucher number is required, but even this is independent from the sort option.
Errors at <Save> of entered data now are additionally designated by coloured background of the incorrect attributes. If an incorrect attribute is allocated to an additional dialogue the cell for this additional dialogue is designated.
Accounts, for which no data may be entered due to their validity in the current period or to their accounting standard with respect for the current fact, are no longer available in the entry form.
The check for a valid and unique entry of the business unit (i.e. '*' for companies without business units) now is performed before data entry (up to now at saving of entered data).
The entry of negative values now is allowed in all additional dialogues.
You can copy the contents of a cell with key combination <Ctrl>C into the clipboard for later insert into another cell. Precondition for this is the setting of the option "Select field" in the options dialogue.
The column option and the sort option are suppressed in print preview and print output just like other applications (report display e.g.).
The previous period from the company startup data (VOR) is preset in the map, if present.
The entered report ID is passed to other form entry applications for transaction details as a parameter.
The column option is preset depending on the definition of sequence numbers for posting keys for form entry (BSL):
Report IDs for b/s or p&l reports now may be used for form entry of development transactions, too. In this case the account details only show accounts for the respective development. In addition for standard developments the positions are selected for b/s+p/l code '1' (for fixed asset development) or '2' (for equity capital and provision development), respectively. Therefore the report ID entered in the company startup data (VOR) now is preset in these applications, too.
The transformation of keys due to entered and defined transformation group allocations (UMSOBJ) was dislocated from the import applications into the user interface layer (GUI). This has two essential advantages:
In this context two attributes were supplemented in the table "Fields for import/export formats" (IEFDEF): transformation object type (e.g. GES for company codes) and transformation group restriction (for distinction between company code and intercompany code). Thus the transformation can be performed by the GUI layer without application logic.
As a consequence of this enhancement the consolidation voucher numbers in several import/export formats had to be subdivided into three single attributes: 1st company code, 2nd company code, and consolidation function.
However, the posting key has to be defined as an attribute including the posting key type as prefix, since the posting key without posting key type is not unique at least for postings, but rather depends on the account. Therefore a new field 'BSLEG' was supplemented in the import/export formats for development transactions and postings. Due to a planned extension of the posting key this field is defined with 4 digits and should be used for transformations.
An attribute "property" was supplemented in the table "fields for import/export formats" (IEFDEF). This entry is used by the import API for the name of the methods, that the user can use to call the import API.
The import of controlling balances can be confined to those controlling objects, that are allocated to a specific business unit, by specifying this business unit in the calling application IMPORT. Now controlling balances for other objects are no longer reported as an error, but rather are counted as "number of ignored records" in the termination panel.
The default file name for import of individual development definitions was changed to KPISXXXX.txt. This corresponds to the default file name used at export from the list applications (ISP, ISS, ISB).
At import of individual development transactions (e.g. liabilities) on mere intercompany accounts now a missing intercompany code is supplemented automatically, since only one intercompany is permitted on these accounts.
Controlling balances in balance sheet accounts are no longer reported as an error at import of controlling balances. They rather just aren't processed. The number of "ignored" data records is reported in the termination panel.
Up to now applications for import of intercompany fixed asset objects and transactions (for elimination of fixed assets results, 'ZA') were provided as separate applications. However, the only difference to the standard import applications for fixed asset objects and transactions was the usage of a different default file name (KPANLICO.txt and KPANLICB.txt instead of KPANLOBJ.txt and KPANLBEW.txt) This now has been changed.
These applications now allow only the import of objects with fixed asset card type 'A' or 'Z' or the corresponding transactions, respectively. The standard import applications behave the other way round.
An advantage of this change is, that the action "Delete data & Import..." now is available for IC fixed asset transactions, too. Then only IC fixed asset transactions are deleted. However, the standard import application for fixed asset transactions deletes the transactions of the company financial statement. Therefore the import of group fixed asset transactions with the action "Delete data & Import..." is not supported.
At carry forward of company financial statements (or sub-function for single data stocks) the user now is requested to decide (just like in currency conversion), which currency codes are to be used for a new period, if the currency codes for the new period aren't yet determined and the codes for group and parallel currency of the company startup data (VORADMIN) of the user disagree with the currency codes of the origin period. The currency codes of the new period are set accordingly.
Postings affecting net income of the consolidation functions 'MB' (manual vouchers) and 'ZU' (elimination of current asset results) now are carried forward onto the accounts for retained earnings of the new consolidation parameters (see below) if defined.
A carry forward posting on the account for net result (with subsequent reposting to an account for retained earnings) is generated for postings affecting net income. If this account is a capital account the posting keys '29' or '30' (equity carry forward) were used. Since this provided an error in the check of the group carry-forward (simultaneous usage of automatic and manual carry forward posting keys) the posting key for automatic carry forward ('21') is used now in this case.
Due to the redesign of the deconsolidation one-time carry forward postings for companies disposed from the group companies in the previous period are created. These postings represent the effect on net income of the disposal from the company financial statement as well as from the 'KS' postings in the next period by repostings from the account for net income to the account for retained earnings.
Vouchers and postings that concern more than one report sub-group, i.e. between companies of two different report sub-groups, could be allocated in IDL Konsis in two ways up to now:
Now a third mode was introduced, that allocates vouchers not affecting net income like solution 1. to the superordinate group, however vouchers affecting net income are handled like solution 2. with reposting in the debit or credit account, respectively. This third mode is triggered by a new entry field "Posting affecting net income only" that can be entered besides the debit and the credit account. The entry 'X' means: use debit and credit account only for vouchers affecting net income. This entry is only allowed in conjunction with the debit and the credit account. The distinction between affecting net income and not affecting net income is not made per voucher but rather per posting record.
The new exchange rate code 'SKH' was supplemented for the calculation of currency exchange effects for goodwill push down accounting. This exchange rate represents the closing rate corrected by an index for currencies with hyperinflation.
The group currency conversion now provides vouchers not affecting net income in group currency to stay not affecting net income in parallel currency. As the case may be two compensation postings are generated on the compensation accounts for b/s and p&l, respectively.
Two new functions were enhanced in the sub-menu "Capital consolidation":
Due to demands of the new deconsolidation the date for disposal from the group companies was changed from period to date fromat (i.e. including day number). A warning is reported if a disposal date is entered without a shareholding disposal (GESGES record with posting key '03') with the same transaction date existing. A warning is reported, too, if a disposal date is removed while a 'KS' voucher is already existing.
If accounts for an automatic transaction development are entered in a consolidation parameter ('SK', 'AE', or 'JU'), then the posting key with usage tag 'L' (changes in current period) is allocated to this account automatically, if the user didn't enter another posting key.
An account for "Reserve goodwill IFRS" was supplemented in the consolidation parameters 'KK' (capital consolidation) and 'EK' (equity consolidation), that has to be entered for facts with accounting type 'I' (IFRS). This account is used for compensation of difference amounts with goodwill due to IFRS (s.o.).
An account for "Difference amount capital sequent consolidation" was supplemented in consolidation parameter 'KK', too, that is used by the new function "Difference amount subsequent consolidation".
An account without account flag 'D' now may be entered as account for depreciations (in consolidation parameters 'KK' and 'EK'), if no such account is defined in the chart of accounts. Without usage of account flag 'D' the otherwise obligatory check between fixed asset transactions for column '13' (depreciations current period) and corresponding p&l accounts can be suppressed.
An account for "Result of deconsolidation" was supplemented in consolidation parameter 'KA' (minority interests), that is used by the new deconsolidation.
A new consolidation parameter 'ZU' was supplemented for elimination of current assets results (see below).
A new consolidation parameter 'MB' was supplemented for manual postings. This parameter contains only one account for retained earnings, that is used instead of the account for retained earnings of the consolidation parameter 'KK' for manual postings at carry forward. Further individual consolidation functions 'M0' to 'M9' do not support a consolidation parameter of their own.
The subject of capital reduction now is supported by the capital first consolidation automatically. The corresponding posting key '10' for shareholdings (GESGES) had already been introduced in release 2006.0, so that a unique distinction between shareholding disposal (posting key '03' with percent values) and capital reduction (posting key '10' without percent values) is assured.
Capital reductions are processed just like capital increases (posting key '08') with opposite signs: The shareholding reduction (GESGES with posting key '10') is posted against capital reductions (KAPBEW with posting key '03') with the same transaction date in a 'KK' voucher. The processing can be performed automatically or manually. Differences are posted on the account for temporary differences and have to be compensated just like other capital consolidation types.
The 'KK' status of the group companies monitor (KTKGES) is set to <red> by the calculation of participations & layers at presence of a shareholding record with posting key '10'.
The automatic reposting ('KU') at capital consolidation at addition to group companies now processes only the carry forward of the company financial statement (posting key with usage tag 'V' and further posting keys for the same development column). However, exchange rate effects on the amounts carried forward (posting key with usage tag 'K') are no longer reposted, since these arise from exchange rate changes in the current period and thus do not belong to the amount at period begin.
The automatic reposting at disposal from group companies has been dropped since it is integrated in the new deconsolidation. Here 'KU' vouchers are no longer generated.
The functions for compensation of temporary differences were shortened for facts with accounting type 'I' (IFRS). In addition "Capitalise goodwill" is replaced by "Capitalise goodwill IFRS". You find a detailed description in chapter Goodwill Pushdown Accounting.
A standard fixed asset object with different naming conventions was preset in the compensation functions for capitalise goodwill, capitalise goodwill IFRS, defer temporary diff. amount for equity companies, and disclosure of hidden reserves. However, a distinction of these objects by naming conventions is no longer required. Thus a unique naming convention for these preset fixed asset objects was introduced.
The deconsolidation of a company disposing from the group companies was redesigned completely (see above).
However, the disposal of shareholdings (company remains in the group companies) is processed like before with the following change:
The account for retained earnings no longer is excluded categorically from calculation of minority interests, if carry forward of minority interests within a 'KV' voucher exists, but only postings with posting keys for carry forward ('01') and repostings ('17'). Other capital transactions on the account for retained earnings (e.g. profit distribution with posting key '06') are processed like capital transactions on other accounts.
Quoted companies are now considered in elimination of fixed assets results as follows:
This solution was adapted to the elimination of current assets results, too, since there up to now always the quota of the accepting company was used.
If consolidation types or quota percent values differ in different group/sub-group levels, then in the superordinate group all postings of the subordinate sub-group are eliminated and the consoldation function is repeated.
The following attributes can be entered in the new consolidation parameter 'ZU' for elimination of current assets results:
The release specific converting program (KONV061) generates a consolidation parameter 'ZU' for each combination of period, fact, and group, where inventories IC-stocks (ICBEW) exist. In this context group means, that both companies are contained in the group companies as fully or quoted consolidated. The account for retained earnings is initialized with the account for retained earnings of the consolidation parameter 'KK' with the same keys period, fact, and group. The elimination account remains empty. The (mandatory) flag is set to 'E' according to the method valid until now.
The behaviour at double mouse click on a line of the list application consolidation vouchers (KONBEL) depending on the current column was revised:
There ar two new sort options 'BK' and 'SK' in the list application consolidation postings (KONBUCH) for sorting of the selected data by posting key or development column, respectively. Unlike the sort options 'KB' and 'KS' the account number is not the leading sort key.
If a consolidation posting of a capital consolidation voucher in posting record '06' (compensation of differences by hidden reserves) on a depreciation account is created or updated the entry of a fixed asset object is no longer required.
The redesigned deconsolidation creates postings for posting record '00'. These now can be selected.
At release of a group statement for a superordinate group all subordinate sub-groups are released automatically, too. However, the release of each sub-ordinate sub-group could be revoked independent from the superordinate group. Thus the group statement of a subordinate sub-group could be changed although the group statement of the superordinate group was released. This will not happen any more, since a sub-group statement's release only can be revoked, if there is no released group statement of a superordinate group.
The behaviour at double mouse click on a line of the list application company reports (REP) or group reports (REPK) depending on the current column was revised:
A selection field for reference report version was supplemented in the report lists (REP, REPK). Besides others the entry '*' provides the selection of reports without reference report version, i.e. only reports that can be generated. At generation without this restriction an error message is output for all reports without reference report version, for these reports cannot be generated by themselves, since they represent only layout alternatives with deviating options.
You now can display report result values in different currencies (local and group currency, e.g.) simultaneously. For this purpose a column option (SPO) has to be defined, which is supplied with the column object type "WKZ". The column descriptions (SPA) of these column options then must be provided with a new attribute that specifies, whether a column displays values in local ("LW"), group ("KW"), or parallel ("PW") currency.
As an example the column option "#ROHGW" has been supplemented in the delivered standard metadata. It shows the columns <Balance old (local curr)>, <Postings (local curr)>, <Balance new (local curr)>, <Balance old (group curr)>, and <Balance new (group curr)> for a balance sheet / p&l report for a company financial statement.
Reports now are generated only for those currencies, which should contain consistent data. For this purpose the flag "with WUM" of the (current) fact is analysed. Report results in parallel currency are generated only if this flag is set to 'P', report result values in group currency are generated if the flag is 'P' or 'K', otherwise the report result is generated only in local currency.
Accordingly company reports on a fact with the local chart of accounts can be generated in group currency, too, if a currency conversion is provided. Up to now these report were generated in local and parallel currency only.
This also means, that a group report (generally not generated in local currency) can be generated only on facts with the flag "with WUM" set to 'K' or 'P'.
You can now generate a multi period cash flow report. A new particular report type 'Q' (to be entered at the report ID, RID) is to be used for this type of report, since the current period is placed in the front columns and the previous period is positioned in the rear columns for the simple cash flow report, while the periods shall be ordered from past to future in the multi period report.
Due to the particular allocation to report value columns for this report type special column options are required for the display, too. The standard (meta data) delivered with this release contains the column options '#KFKP' (group statement) und '#KFNP' (company statement) for this purpose.
You now can define multi period reports over 13 periods, so that the previous accounting year can be displayed besides 12 months of the current accounting year, e.g.. However, for decumulated display of reports with 13 periods you need own individual column options, since the standard column options for multi period reports (#ALTPD, #BUCPD, #KONPD, #KTKPD, #NEUPD, #SUMPD) are designed for 12 periods.
You now can generate a report containing the company financial statements transaction developments of all companies of a group excluding the data of the group statement (consolidation postings or group transactions, respectively). Up to now this kind of report was only possible for b/s and p&l reports, since company and group statement data were allocated to different report result columns in these reports providing the possibility to suppress group statement data by appropriate column options.
However, transaction development reports allocate company and group statement data to the same columns. Therefore a distinction is required at the time of report generation. A new attribute in the report header provides this distinction, that can be entered (without a prompt text for its own) in addition to the report option. The following values are allowed:
Data exchange (groupwide as well as sub-group data) is not compatible between releases 2006.0 and 2006.1 on the one hand and older releases on the other hand. This is now reported by a corresponding error message.
The calling application "Group subgroup data exchange" (KONDAT) now arranges the subsequent applications more clearly and displays them in tree structure. The nodes represent the following application groups:
A set of new functions is provided beyond the node "Subgroup archiving" which provide a method for clearing old data not used any more from the production database. If these data shall not be deleted completely an archive database has to be installed, that stores the archived data. You have to update this archive data base with new IDL Konsis releases, otherwise the transfer of archived data will not be supported. Archiving is performed by the following steps:
You now can unload sub-group data even if the current period is already released (i.e. locked against changes).
If you unload more than 50 periods simultaneaously these are reported in the protocol file completely.
Up to now only customer individual posting keys (starting with 'K', 'L', 'M', or 'N') were unloaded in the head office and loaded in the sub-group. This is no longer sufficient, since an attribute for column sort definition for form entry had been supplemented in release 2006.0, which is maintained customer specific in the head office. Thus (already since update C for release 2006.0) all posting keys are transferred within the group-wide data.
The extensions of the IDL Connector are documented separately.
Up to now a maximum of 3 facts could be selected for MIS preparation. Each fact provided an own attribute in the measure tables (K810 to K813) in the database (e.g. K810-Balance-Actual, K810-Balance-Plan, K810-Balance-Forecast). The fact itself as defined in IDL Konsis (e.g. 'I4', 'P4') was not defined as dimension. This has been changed now incl. an enhancement of the number of facts. Furthermore the limitation to 4 report structures was discarded. Since these enhancements are not compatible with the data model up to now, a version number has been introduced in the MIS parameter:
Furthermore you now can define several MIS parameter sets parallelly. The key (up to now the fix value "MIS") can now be entered. In addition a MIS parameter set can be labelled by a description and a short word. One of these parameter sets has to be declared "active". This parameter set is used for MIS preparation. If a MIS parameter set is declared "active" all other MIS parameter sets are set to "inactive".
Authorsation checks were supplemented. Especially now only data of companies which the current user may read are unloaded at MIS preparation.
A data driven clearing of the dimension "report position/account" had been introduced with release 2006.0, i.e. all combinations of account number, debit/credit flag, and controlling flag with no allocated data were suppressed. In some cases these data were missing for subsequent processings. This data driven dimension clearing now can be suppressed. For this purpose an entry field "delete position/account" was supplemented in the map of application MISPARE with the entry values 'X' (with dimension clearing) and '-' (without dimension clearing). The existing parameter set 'MIS' yields the value 'X' representing the solution introduced with release 2006.0 by the release converting program.
The SAP transaction type group 12 (elimination addition in subsequent periods, e.g. posting key 160, credit in subsequent years) was allocated to IDL Konsis posting key '01' (cost additions) and thus handled as negative cost addition. Without real cost addition a negative value in column cost additions resulted in the fixed asset development. To avoid this the SAP transaction type group 12 now is allocated to IDL Konsis posting key '02' (cost disposal) by the IDL SAP interface.
The import of fixed asset transactions from Varial now is performed analogeously to the SAP interface, i.e. Varial exports account numbers with additional leading zeroes. At import on a fact with the group chart of accounts ...
For the topics
a newly revised and cross-application documentation was created. This documentation is in German and partly in English at the disposal and obtainable in the resource tree in the respective branches of the corresponding application functions. It isn't contained in the "doku" directory of the CD as separate pdf documents. 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. The documentation of these topics on the CD is no longer present.
With this release the following English-speaking documentations in the "doku" directory are updated or completed: