The release IDL Konsis 2006.0 is a main maintenance and therefore must not 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 last main maintenance and the interim maintenances IDL KONSIS 5.4.1 und 5.4.2 (IDL WinKons 3.1 and 3.2, or PP Consis 4.2 und 4.2 SR1, respectively) released until Sept. 15th 2006 are contained in the current main maintenance.
This documentation describes the enhancements since the previous interim maintenance IDL KONSIS 5.4.2 (IDL WinKons 3.2 or PP Consis 4.2 SR1, respectively). If the last interim maintenance hasn't been installed yet you are recommended to catch up on the enhancements of the interim maintenances 5.4.1 and 5.4.2.
To avoid illegal use of IDL Konsis from release 2006.0 on a method for verification of the licence is contained. Therefore all customers will get a licence file per e-mail independently from the release CD. Without this file IDL Konsis 2006.0 cannot be installed.
If you want to install IDL Konsis 2006 without having a licence file, please contact the IDL hotline.
Because of the change of the meaning of posting key '08' for shareholdings (see below) users have to check, whether this posting key is used in the current period without being processed. If necessary the posting key '08' has to be replaced by the posting key '02'. This particularly concerns data forwarded during the period.
Due to the reorganisation of the capital consolidation (s. "Release 5.4.2 News ") it is recommended not to install this maintenance during group consolidation, if you haven't installed the interim maintenance IDL KONSIS 5.4.2 (or IDL WinKons 3.2 or PP Consis 4.2 SR1, respectively) before.
If you are updating to the current maintenance from a release older than IDL KONSIS 5.3.0 you should check, whether consolidation vouchers with consolidation function 'KL' (depreciations on fixed assets of capital consolidation) are existing in the previous period. If this is the case, the group carry forward should be performed with an older release, since 'KL' postings aren't forwarded any more from this release on.
Users who work with individual transaction developments, have to define custom-designed texts (description see Release 5.4.1 News) since this 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. 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) 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. 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. This error ist corrected. 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'.
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.
It is now possible to carry forward a company's financial statement's data for a single data stock. For this purpose in the calling application "Create Co.carry-forward > new period" (PERGES) you select the required lines (= data stocks) and then select the line command (without globe) "Create Co.carry-forward > new period" out of the object or action menu. Then only the selected stocks are carried forward.
Vouchers and postings are only to be carried forward together. Besides statement data (vouchers and postings as well as transaction developments) also control data (company business unit allocations, currency conversion data, data for deferred taxes, report headers) may be forwarded separately. However, the control data aren't carried forward if already data are existing in the destination period.
This enhancement is especially necessary for the first automatic creation of development transactions for cash flow reporting. Till now the complete carry forward had to be repeated, although other transaction developments as well as postings already had been aligned.
Postings affecting net income till now always were reposted to a particular account for retained earnings (due to definition in "Facts" (FAC) for group charts of accounts or account flag 'W' for company charts of accounts). This is now possible more detailed.
Now an individual account for retained earnings can be defined for each P&L account. For this purpose the database table for accounts was extended as well as the single record application KTOE and the import format for the application TXTKTO. The account for retained earnings has to be a b/s account. It overrides the previous account for retained earnings independent from the fact.
The posting keys for shareholdings/participations were reorganized:
Because of the change of the meaning of posting key '08' for shareholdings users have to check, whether this posting key is used in the current period without being processed. If necessary the posting key '08' has to be replaced by the posting key '02'. This particularly concerns data forwarded during the period.
At repetition of D&C or I&E Consolidation all vouchers created till now were deleted. Thus postings for adjustment of differences had to be entered again although in many cases IC balances were unchanged so that manual adjustment postings would have been still valid.
From now on manual adjustment postings are conserved at the action "Delete + ...". Manual postings are determined by their posting status '5'. In case, they are reallocated to another posting record number due to transaction currency and business unit combination. Exception: Manual adjustment postings are deleted if for the keys of the posting record (transaction currency, business units) no IC balances exist or no difference remains because of changed IC balances.
With changed IC balances the former adjustment may be wrong. This is registered by a subsequent validation leading to a corresponding status flag. Then open differences are announced for posting records with debit/credit differences or with a remaining balance on the account for difference amount. These differences have to be cleared as usual.
Like postings for minority interests on postings affecting the net result now also postings for minority interests on postings on capital accounts (in addition to capital consolidation) for the respective company can be created.
For this purpose the new value 'K' was supplemented for the flag for vouchers affecting net income (KONBEL). 'X' continues to be set, if the voucher is affecting net income. However, 'K' is set, if the voucher contains postings on shareholding oder capital accounts without being a voucher for the capital consolidation (consolidation types 'Kx', 'Ex').
The call of the subsequent application "Consolidation Vouchers KA" out of "Group companies + monitor" (KTKGES) sets the selection for the flag "Posting affecting net income" no longer to 'X' but rather to '%'. Then the consolidation voucher list (KONBEL) selects vouchers with flag = 'X' as well as vouchers with flag = 'K'. The single record application KONBELE allows the setting of the minority interests flag (KA) now also for vouchers with "Posting affecting net income" = 'K'. In this case all postings on capital accounts yield the KA flag instead of postings on P&L accounts. Corresponding checks are performed in the single record application "consolidation posting" (KONBUCHE), too.
When calculating and posting minority interests all postings with KA flag set are processed. Opposite to the P&L postings markable till now for the capital postings the elimination of minority interests is posted on the capital accounts themselves. However the same posting record number is used. Example:
In the following only companies are named, because it is assumed that company is the key most frequently used for the display of reports with keys in columns. However, the specifications are also valid for other keys, that can be used for display in columns, i.e. business units, subgroups and controlling objects.
The report result display was enhanced for the ability to display up to 100 value columns side by side, i.e. with column option '#KTKGE' e.g. up to 99 companies plus one column for the remaining total.
Furthermore it is now possible to determine the sequence of the companies in the columns (until now always alphabetical). For this purpose two new applications are introduced: In "Object sort defs. list" (OBJSORT) you define a general key with its descriptions, in "Object sort defs. column ref. list" (OBJSORTSP) you define the desired sequence of companies. You find both applications in the menu tree in the branch "Reporting" -> "Report Definitions".
The report display is performed in the defined sequence, if you enter the object sort definition in the report display list (REPERG) and a corresponding column option ('#ROHGE' e.g.). If the report contains more companies than defined in the "Object sort def. column ref." list the remaining companies are summarized in a special column for the remaining total.
With the aid of the new application "Report mirrored" (REPERGS) development reports can be displayed mirrored (lines and columns interchanged). Among others displays of this kind are required for the equity development in IFRS. The call of "Report mirrored" is possible from the report list applications (REP, REPK, REPSTR) by a separate entry in the object or action menu.
Furthermore "Report mirrored" provides the simultaneous display of the development of the current and the previous period. Prerequisite for this is, that the same report (same report id and version no.) is defined and created in the previous period. For this prupose the parameter "prev.Period" of the report header is used.
In the mirrored display of a transaction development positions are used as columns and the column allocations are used as lines. However, the tree representation of the positions can not be expressed. You also have to mind, that a line break with character '|' only can be produced in the column headers (i.e. now in the position descriptions), but not in the line descriptions (i.e. in the column allocations as defined in application SPA). Therefore it is recommended to define separate column options and charts of positions for this type of display.
The enhancement of the equity development by further posting keys and column allocations as demanded by IFRS is possible optionally (see below).
After returning from subsequent applications with possible change of displayed data list tables are always refreshed. Therefore up to now the list tables were displayed from there beginning when refreshed. From now on it will be attempted to maintain the previous position in the table, so that successive processing of lines can be continued immediately.
The options dialogue (menu bar -> Options -> Options), tab "Common" now describes the entry fields with "Text" and "Format" instead of "Text locale" und "Format locale". A frame around these fields is labelled "country specific settings".
When displaying very large lists (reports e.g.) it might happen, that the memory allocated by the application program did not suffice. A so-called "Heap Error" occurred. A new memory module now allows to allocate more memory and simultaneously provides a clearly smaller memory demand.
The primary keys of the database tables of period specific data (balances, their details, vouchers, postings e.g.) were newly defined. The usually unique selected keys for period and fact now represent the leading keys. This provides shorter response times. However, the gain is dependent from the database system.
Like the flexible import you now also have the possibility to use individual formats for export of data displayed in the IDL Konsis lists. For this purpose the file dialogue displayed at export now allows the entry of a file type besides the entry of a file name. As a default the file type "#TXT" is proposed providing an export in the standard format like up to now.
Alternatively an individual file type may be entered. This entry has to correspond to a format id, which has to be defined in the application "Import/export format IDs" (IEF) for the respective data stock ('KTOSAL' for account balances e.g.). These may be simple line formats (format type 'TXT', alternatively with fixed columns or comma separated) or XML formats (format type 'XML').
For TXT formats a format description has to be defined via application "Allocations import/export fields to formats" (IEFFEL). For XML formats a transformation stylesheet has to be entered in the help text of the format ID like the stylesheet for import XML formats. The export transformation stylesheet may be entered in addition to an import transformation stylesheet.
Exported data can be reimported to IDL Konsis using the same format ID.
Flexible export is especially interesting for IDL Konsis data to be processed by other applications.
The converting program for this release in addition to the conversions of interim release 5.4.1 and interim release 5.4.2 performs the following changes in the database:
The following menu IDs are new in this release in addition to the new menu items in release 5.4.1 and release 5.4.2. 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 execution of the functions for release of company and group financial statements (EALOCK, EAICLOCK and KTKLOCK) now was allocated to the standard authorization group IDLKON1 (for IDL KONSIS und PP Consis) and IDLWIN1 (for IDL WinKons), respectively. Similar customer specific authorizations groups should be changed correspondingly.
The authorization for execution of the functions for locking a period (ABRLOCK) as well as for revoking the release of company and group financial statements (EAUNLOCK, EAICUNLOCK and KTKUNLOCK) now was allocated to the standard authorization group IDLKON (for IDL KONSIS and PP Consis) and IDLWIN (for IDL WinKons), respectively. Similar customer specific authorizations groups should be changed correspondingly.
The menu ID REPBIK (Creating ratio reports) has been dropped. If customer specific menus refer to this menu ID, these entries have to be dropped before installation of this release. Otherwise errors arise during the installation.
The entry fields for selection for user groups in the application "Users" (USE) now only are displayed in the extended mode.
The application "Company startup data+authorization" (VORADMIN) now provides the facility of mass updating the ex-fact. This feature can be used if due to different consolidation levels (local GAP, IFRS) different facts for consolidation are used.
The account master data were extended by an attribute for a specific account for retained earnings (see above). This account has to be a b/s account and may be allocated only to p&l accounts. At carry forward it overrides the standard account for retained earnings.
The restriction, that no "Account if D/C changed" may be allocated to an intercompany account, has been dropped.
The list application "Accounts" (KTO) with Sort Option 'Z' (Sort by allocated group account) now displays the data for the group account like a sum below the lines of the allocated company accounts. Thus several columns displayed twice till now are omitted.
The list application "Controlling Objects" (KST) with Sort Option 'Z' (Sort by allocated group controlling object) now displays the data for the group controlling object like a sum below the lines of the allocated company controlling objects. Thus several columns displayed twice till now are omitted.
In case of change of the "Fixed asset type company/group" of a fixed asset object a check was supplemented in the single record application (ANLOBJE) as well as in the import application (TXTANLOBJ). Depending on the previous fixed asset type no fixed asset transactions (for types 'M', 'A' and 'Z') or no consolidation postings (else), respectively, may exist. Otherwise an error is reported.
The directory "LieferBatch" of the release CD contains a set of import files for definition of an automatic transaction development for cash flow reporting. With the aid of the import applications for individual development definitions and posting keys these data can be imported into the respective database. The transaction development 'S9' is used for this purpose, which therefore must not be used for other purposes. Further details are described in the corresponding file "read_me.txt".
Furthermode the directory "LieferBatch" of the release CD contains a set of import files for extension of an individual transaction development without carry forward (liability development e.g.) by posting keys and transaction columns for automatic creation of carry forward values and current changes as well as their elimination for the purpose of cash flow reporting. With the aid of the import applications for individual development definitions and posting keys these data can be imported into the respective database. The transaction development 'S1' is used as an example and has to be converted to the desired transaction development number. Further details are described in the corresponding file "read_me.txt".
Furthermode the directory "LieferBatch" of the release CD contains a set of import files for extension of the equity capital development by posting keys and transaction columns like they are demanded by IFRS. In addition also a corresponding column option including column descriptions and formula lines is contained. With the aid of the import applications for individual development definitions, posting keys, column options, column descriptions and formula lines these data can be imported into the respective database. Further details are described in the corresponding file "read_me.txt".
For this reason the directory "LieferBatch" was redesigned. It is now divided in the following subdirectories:
The entry of a short word for a posting key has become optional. Without entry of a short word the first ten characters of the description are used as short word.
Customer individual posting keys for the equity and the provision development now can be defined without allocation to company or group financial statement. Thus no longer two posting keys have to be entered for the same purpose. Those posting keys then may be used for capital transactions as well as for consolidation postings.
A real subgroup now can be allocated to a report subgroup as reference group/Subgroup. Then for the report subgroup no group companies (KTKGES) have to be provided (see below).
If a company's chart of controlling objects is modified online or via import it is checked now, whether controlling balances exist for the previous chart of controlling objects. If this applies, online a warning is output, which may be ignored. At import an error is reported, since warnings can be suppressed easily.
The Company financial statements monitor (EA) automatically preallocates the group/subgroup entry field with the group defined in the company startup data so that a selection of all group companies is provided as a default. If no group/subgroup is defined in the company startup data now the company from the startup data preallocates the company entry field. Otherwise a selection for all defined companies would be initiated.
A double click in the status column for postings no longer branches into the list "Postings" (BUCH) but rather into the list "Vouchers" (BEL), because the status is displayed <yellow> if vouchers without postings exist. Then in BEL vouchers with entry of a message can be selected and analyzed in detail.
A new status column for "Check carry-forward new period" is supplemented for the result of this check (<red> or <green>). Basis of the status display is a new record in the processings table (VERARB, Checkpoint = 'SIMPER').
At action "comp.financ.stmt.release" a warning is output, if not all status columns of the company are clean. Now no more warnings are output if only the columns for the B/S and p&l "IC status reconc." are <red>.
In the list applications "Account balances" (KTOSAL), "IC Account balances" (ICKTOSAL), "Capital transactions" (KAPBEW), "Provision transactions" (RUEBEW), "Individual development transactions" (SPIBEW), "Fixed asset transactions" (ANLBEW), "Shareholding/Participations" (GESGES") and "Postings" (BUCH) at SortOption 'ZG' as well as in "Controlling balances" (KSTSAL) at SortOption 'ZK' (sort by allocated group account) the columns for chart of accounts, account number and account description are comprehensed. The data lines display the company account, the total lines display the group account. The column for the chart of accounts is output before the account number in the fixed area of the table. The headers do no longer name the chart of accounts.
This analoguely applies for the list "Controlling balances" (KSTSAL) with SortOption 'ZC' (Sort by allocated group controlling object) referring to the display of the chart of controlling objects, the controlling object number and its description.
When branching from "Account balances" (KTOSAL) to "Accounts" (KTO) now always the account of the key of the selected data line independent from the SortOption is transferred as a parameter. Till now at SortOption 'VG' the aggregated account and at SortOption 'ZG' the allocated group account were transferred, e.g.
If the flag for controlling balances in the current fact is set to '0' (controlling details only for some P&L accounts) the B/S+P&L code in the list "Account balances" (KTOSAL) and the form application (I-KTOSAL) no longer is displayed with coloured background, if no controlling balances exist for this account. Up to now even for accounts without controlling balances this flag was displayed <green>, since this is a valid state.
At selection of account balances for a report position (e.g. like in a subsequent call from the report result list) the displayed balances are no longer validated. Therefore no differences are reported in the message window, too.
At constriction of the display of lists for details of account balances to one account a difference between detail data and account balance is no longer output in the message window but rather by a message in the message line. This eases the correction of detail data when branching from "account balances" for all lines with <red> detail marking.
A facility to select data for inter companies as well as ic business units was supplemented in the list applications for capital, provision and individual transaction developments (KAPBEW, RUEBEW, SPIBEW).
Furthermore these lists now have the facility (action) to branch into the new form entry application for development transactions (see below).
At validation of development transaction against ic account balances ic general accounts only are included, if the ic account balances flag of the current fact is set to '1' (ic account balances also for ic general accounts).
A development column for repostings (report result value '12') was supplemented in the capital development. The posting keys '17' (company financial statement) and '34' (group consolidation) used for reposting of capital transactions on accounts with account flag 2 = 'L' to the account for retained earnings (account flag 'X') were allocated to this column. The validation of the company financial statement was extended by a check for the total of this column for all accounts to be zero.
At entry of shareholding transactions the posting date now is preallocated with the ultimo of the month of the current period.
When changing shareholding data it is checked whether the posting date is larger than the current period. Then an error message is output.
The posting keys for shareholdings/participations were reorganized (see above).
At entry of postings on fixed asset accounts now a fixed asset object due to standard conventions is created if not existing yet. This is like the entry or import of fixed asset transactions.
The form entry for fixed asset transactions now is supported in the report structure (sort option = 'F'), too. In addition several entry columns for different posting keys can be adjusted (column option = 'FS').
At entry of values in columns for each posting key (column option = 'FS') the columns for entry of additional data are suppressed. For entry of these data you have to mark the line and then select the additional entry box via right mouse key.
Like the form entry for fixed asset transactions new form entry applications for other development transactions (capital, provision and individual development transactions) have been provided. You can start these applications from the menu tree (branch "Forms data entry") or via short word entry (I-KAPBEW, I-RUEBEW, I-SPIBEW). Instead of the fixed asset object here the account number is used as the key for data entry.
The layout of the lines for the accounts is controlled by the entry of the sort option with the following alternatives:
The column layout and entry type is controlled by the column option with the following alternatives:
If a tree representation is selected for a form entry application the tree now is expanded immediately. Thus all entry fields can be used for entry of data at once.
After pushing the button <Save> the display remains at the current position. Up to now a refresh resulted in positioning the table to its beginning, so that data entry couldn't be continued.
The columns for Modifier, Mod.Date and Mod.Time of the calling application "Data import and display" (IMPORT) are omitted now, after the columns for message number and short text already had been cancelled, too, since these data referred to the processings record (VERARB) that also provided the message number (if unique).
If data (e.g. account master data) are exported from IDL Konsis empty columns cause empty entries in the exported TXT file. Then, at reimport of these data ("valid until" e.g.) values already existing were not overwritten. Now these empty values are substituted by '*' at import, so that these attributes are set to the (exported) empty values. Precondition for this substitution is the control parameter HERKUNFT equal to KONSIS ("$$ HERKUNFT=KONSIS").
Leading spaces, (in descriptions e.g.) now are imported correctly again. In the previous release leading spaces were truncated.
The definition, which columns in which import formats are transformed from space to '*' specified above, is entered in the table "Fields for import/export formats" (IEFDEF), which has been extended for this purpose.
The attribute "datatype" was transferred from the table "Allocations import/export fields to formats" (IEFFEL) to the table "Fields for import/export formats" (IEFDEF), since it is independent from the format.
The applications for import of metadata, descriptions and help texts, which can be started via the separate calling application IARIMP (in the menu tree in the branch <System administration> -> <Translations> -> <Data import and display>), were adapted to use the tables for flexible formats (IEF, IEFDEF, IEFFEL). Usually these applications are without relevance for the user.
The import format for the account master data was extended by the new attribute for the account for retained earnings (see above).
For the import of IC-P/L-thereof-acc.balances (TXTICKONV) a possibility for XML import (among others for the Coda interface) was supplemented.
At import of postings on fixed asset accounts now a fixed asset object due to standard conventions is created if not existing yet. This analoguely applies for the entry or import of fixed asset transactions.
For the purpose of reimporting postings, that had been converted in IDL Konsis and then exported, the check of conversion rules (up to now only 'VKW' and 'VPW' allowed) was eased, if the control parameter HERKUNFT is set to 'KONSIS'.
A new application supports the import of account conversion rules. It is called from the calling application "Data import and display" (IMPORT) in the branch "Import others". The standard import format ('#TXT') is described in the table "Allocations import/export fields to formats" (IEFFEL). The imported data are checked like in the single record application "Account currency conversion rule" (KTOUAWE). Calling the import application via action "delete data & reimport TXT-file" is allowed only with a unique entry of a company or a group/subgroup. The regular import mode (without delete) also provides an update of data already existing.
If balances without details for business units are splitted into business units at fact carry forward (GESABV) due to controlling balances and ic general accounts are processed, then ic account balances are splitted into business units like the account balances.
IC account balances now are generated out of balances on IC general accounts, if the flag for IC account balances in the origin fact is set to '-'. Up to now IC account balances were only generated out of balances on IC general accounts, if the flag for IC account balances of the origin fact was set to 'X'.
IC account balances now are generated out of controlling balances, if the flag for controlling balances of the origin fact is set to '0' (controlling balances for some p&l accounts). Up to now IC account balances were only generated out of controlling balances, if the flag for controlling balances of the origin fact was set to '1' (controlling balances for all p&l accounts).
The calling application "Create Co.carry-forward > new period" (PERGES) no longer displays message numbers for the data stocks per line but rather a coloured status, which is set analoguely to the company financ. statements monitor (EA).
The carry forward of a company financial statement to a new period now can be performed for each single data stock (e.g. automatic transaction development for cash flow reporting, see above).
Carry forward transactions with group or parallel currency value 0,00 now only yield the conversion rule 'VKW' or 'VPW', respectively, if a currency conversion has been performed in the origin period and fact.
Carry forward postings now yield the conversion rules 'VKW' and 'VPW', if a currency conversion has been performed in the origin period, even if the value in group and/or parallel currency is 0,00.
If an individual account for retained earnings is entered for a p&l account, this account is used in carry forward of postings affecting net income instead of the default account for retained earnings (see above).
Consolidation postings carried forward now yield a convenient posting key, if the posting key of the previous period conflicts with the current account flag 2. If no posting key can be determined a warning is output and the posting key has to be added manually. Up to now in this case posting keys conflicting with account flag 2 were entered into the carry forward posting.
Postings for minority interests (KA) on the account for minority interests of postings affecting net income now are carried forward onto the account for retained earnings (with account flag = 'X') like the postings for the minority interests of the result account. The accounts for carry forward onto the account for retained earnings are determined from the consolidation parameter of the previous period.
Consolidation postings on accounts with account flag 2 = 'L' now are carried forward in two steps: Creation of a posting on this account with carry forward posting key ('21') and reposting with posting key for repostings ('34') onto the account for retained earnings (account flag = 'X'). Thus carry forward of the capital can be validated.
The number of postings for carry forward of rounding differences out of the deconsolidation was reduced.
At carry forward during the period in the destination period now only those consolidation vouchers are deleted, that are carried forward, too. E.g. a voucher for debt consolidation in the destination period is maintained at repetition of carry forward.
Consolidation postings of the consolidation function 'KL' (depreciations for fixed asset objects of capital consolidation) are no longer carried forward. Since 'KL' postings aren't created any more since release IDL KONSIS 5.3.0 only users updating from an older release to the current release are concerned.
Postings affecting net income for companies consolidated at equity now are carried forward in two steps like for other companies: a carry forward posting on the net result account and a reposting to the account for retained earnings.
A check was supplemented in the function "Check carry-forward new period" for company and group carry forward: Posting keys for manual carry forward (same development column as the posting key for automatic carry forward with usage flag 'V') may not be used, if data from the previous period have been carried forward (transactions or postings with the posting key for automatic carry forward already exist). Violations are reported.
A check was supplemented in the function "Check carry-forward new period" for group carry forward: The total of postings with the posting key for automatic carry forward has to equal the total of all postings of the previous period. Postings of the consolidation function 'KU' ("repostings after change of the company group") are excluded from this check since they arise from the company financial statement of the previous period rather than from group consolidation. Violations are reported.
The functions "Check carry-forward new period" for company and group carry forward now write the result of the check into the database tables for processings (VERARB) or group processings (KVERARB). For this purpose a checkpoint 'SIMPER' was supplemented. If the check registered differences in automatic carry forward or additional usage of manual carry forward posting keys a corresponding message is entered there. Based on these entries a new status column (<red> or <green>) is displayed in the company financial statement and group companies monitor (for groups only in the group line).
A selection for B/S+P&L code, account flag 1 and 2 was supplemented in the list applications "Account balances origin list" (KTOHER) and "Controlling balances origin list" (KSTHER) like in the balance list applications.
If a report group contains report subgroups, whose structure is identical to real subgroups, then the real subgroup now can be allocated to the report subgroup as reference group/sub-group. Then no group companies have to be provided for the report subgroup. When copying consolidation vouchers for report groups the group companies of the referenced real subgroup are concerned in this case.
An entry field for language was supplemented in the list application "Account currency conversion rules" (KTOUAW) providing the display of account descriptions in the desired language.
Up to now the list application "Currency conversion GCurr+PCurr" (WUM) and the single record application "Currency conversion header G/PCurr." (WUME) displayed the following difference from currency conversion:
In addition from now on also the differences from conversion of local currency into group currency, converted into parallel currency (by closing rate) are displayed besides the corresponding values in group currency. Furthermore the list application WUM displays additional columns (with description "total") with the sum of both differences in parallel currency. These correspond to the differences that would result from a direct conversion from local into parallel currency. These newly displayed values are not stored in the database but rather calculated (previous period with previous rate) at run time, if they do not result from account balances. This applies if B/S differences and P&L differences are stored at different accounts.
An error is no longer reported, if the D/C flag of an account balances switches between local and group currency or between group and parallel currency due to sliding average currency rates. Rather the group or parallel currency amount is stored as a negative value.
The list application "Account currency conv. audit trail" (KTOUMR) displays values from the previous period, that are read out of the previous period entered in the currency conversion header of the company. Now these values are no longer displayed, if the constellation of currency codes has changed between previous and current period. Then only the cumulated value is displayed and the same amount for the current period.
Analoguely to the list application "Currency conversion GCurr+PCurr" (WUM) (s.o.) also the list application "Account currency conv. audit trail" (KTOUMR) displays additional columns for the differences out of the conversion from local into group currency converted into parallel currency as well as the total of both differences in parallel currencies for accounts with conversion rule 'FDK' (sliding average currency rate).
The change of the parallel currency now is supported by ignoring the currency conversion rule 'VPW' (predefined amount parallel currency) of consolidation postings (usually used for carry-forward postings) providing a new conversion of all group currency amounts.
In addition, the application for currency conversion of group consolidation writes a record into the database table for group processings (KVERARB) with checkpoint ID 'KTKWUM' that contains the currency codes used. Thus a subsequent conversion can determine which currency codes had been used for the previous conversion. If differing from the currently specified codes (company startup data or group master data) a question is output where the user has to specify which currencies to use.
The comprehension of consolidation postings converted with different rates at carry forward may result in postings with credit amount in group currency and debit amount in parallel currency or the other way round. The currency conversion now consideres this constellation. Up to now a superfluous posting for difference clearing was generated.
The change of currency data now is performed for the data of the account currency conversion audit trail (KTOUAW), too, like the change of the amounts on the currency conversion difference accounts. I.e. the new difference in group currency results from the sum of the former difference in group currency (converted into the new group curency) plus the former difference in parallel currency. The new difference in parallel currency represents the former difference in parallel currency (converted into the new parallel currency) with opposite debit/credit flag. Thus the total account currency conversion audit trail corresponds to the B/S difference except for rounding differences.
The capital details of the balances of the accounts for conversion differences are generated in the way, that the carry-forward amounts are changed like the differences themselves besides usage of the currency rates of the previous period. A second transaction provides a correct detail. The conversion differences are converted using the currency rates of the previous period, too.
Checksums now are concerned in the change of currency data, too. The checksums of consolidation vouchers in group and parallel currency are interchanged as well as the consolidation posting checksums of group reports resulting in a <green> display for these checksums in "group reports" (REPK) after change of currency data. For this reason the subsequent calls of the list applications "group reports" (REPK) and "consolidation vouchers" (KONBEL) were supplemented in the calling application "Change currency data GCurr <=> PCurr" (WKZEXCH).
Up to now the "group companies + monitor" (KTKGES) tree display aborted with an error message, if not all companies allocated to a subgroup were allocated to the current group. From now on a tree display is provided as far as the group structure is correct, so that the correction of data is possible without changing the sort option. The missing companies are listed in a message window.
The selection of companies with certain processing status in combination with a consolidation function now is supported like in the company financial statement monitor (EA). The simultaneous entry of processing status (two entry fields for selection of 'E' and 'W', e.g.) and consolidation function (only those functions make sense, that correspond to a status column per company, i.e. not 'FU', 'JU' e.g.) provides the selection of all companies with the entered status for the entered function.
Up to now "group companies + monitor" (KTKGES) in the column "FinStmts" only displayed the status of account balances and currency conversion of the corresponding company. From now on the complete company financial statement except for postings is displayed. Always the worst status is displayed, i.e. <red> if at least one status column of the company financial statement monitor is <red>.
However, missing account balances are no longer displayed <red>, if the company is not to be consolidated (consolidation type 'K'), is consolidated at equity (consolidation type 'E') or leaves the group companies in the current period (disposal date entered). Then the status "FinStmts" is display as '-'.
A new status column 'MB' is displayed for manual vouchers (consolidation functions 'MB', 'M0', 'M1', ... 'M9', 'AO'). The status is displayed only in the group line:
A new status column 'WU' is displayed for the currency conversion into parallel currency of consolidation postings. This status is displayed only in the group line, too. The status value is derived from the entry for checkpoint 'KTKWUM' in the table for "group processings" (KVERARB) (see above).
A column for the result of "Check carry-forward new period" (see above) is supplemented after call of this check. The status is displayed only in the group line. The colour of this status (<red> or <green>) is based on the record for the checkpoint 'SIMPER' of the group processings (KVERARB).
Attributes for posting keys were supplemented in the database table for consolidation parameters. Each posting key is allocated to an account and is used, if a consolidation posting on this account is generated. This is especially helpful if accounts for individual transaction developments, whose posting keys connot be determined automatically, are concerned. The selection box for posting keys always refers to the account flag 2 of the respective account.
As a first step the entry of posting keys is supported for the consolidation parameters for compensation for the result of the group companies (JU), the debt (SK) and the P&L (AE) consolidation.
The consolidation parameter 'K' was divided into one consolidation parameter for capital consolidation and one consolidation parameter for minority interests. The consolidation parameter 'KK' now only contains accounts used for first consolidaiton (KK), deconsolidation (KS) and carry forward (KF). All accounts used for calculation and posting of minority interests now are found in the new consolidation parameter 'KA'. The division is performed automatically by the release conversion program.
The account for net result has been cancelled from the consolidation parameter 'KK'. The net result account designated by account flag 'E' in the chart of accounts is used instead at capital consolidation.
An account for depreciation of shareholdings/participations was supplemented in the consolidation parameters 'KK' (capital consolidation) and 'EK' (equity consolidation). If this account is entered the first consolidation generates consolidation postings even for shareholding/participation posting keys '05' (current allowances) and '07' (accumulated allowances).
For report groups only a calculation of participation values and level is performed but no determination of status values, since usually no consolidation functions are performed for report groups.
If a shareholding company and a subsudiary company to be consolidated are allocated to a superordinate as well as a subordinate group as fully consolidated (type 'V') the status values for capital consolidation are set to 'T' in the superordinate group, so that the capital consolidation only may performed in the subordinate group. This now also applies for child companies with consolidation type 'Q' (quoted).
At repetition of the debts or P&L consolidation via action "Delete & ..." now manual consolidation postings for difference clearing are maintained (see above).
Posting keys related to the accounts for threshold value clearing, conversion difference clearing and difference amount now can be entered. These posting keys are written into the postings generated on these accounts.
No posting key can be entered for the accounts for shareholding results and carry-forward in the consolidation parameter 'SK', since these accounts aren't used by the debt consolidation but rather by the group carry forward. No consolidation postings are generated on the account for shareholding results. The postings on the account for carry-forward always yield the posting key for automatic carry forward (usage flag 'V').
For the account master data it is checked since Release 5.4.1, that only statistical or only real accounts may be allocated to a consolidation function ('S0', 'S1' etc.). However, for statistical acounts no differences were determined up to now.
From now on also statistical accounts can be entered in the consolidation parameters, if only statistical accounts are allocated to this consolidation function. If the account for threshold value is a statistical account IC account balances on statistical accounts are processed like real accounts with posting of the difference on the threshold value account. This also applies for other methods of difference clearing (transaction currency e.g.).
Statistical accounts mean accounts with B/S+P&L code '6' to '9'. However, statistical quantities (B/S+P&L code '5') still are excluded from automatic processing.
The note for statistical accounts at execution of debts or P&L consolidation has been dropped. The status for consolidation functions with statistical accounts is set just like the status for consolidation with real accounts. This also applies for manual difference clearing.
The processing of the posting keys of the shareholding/participation transaction was modified (see above):
At participation addition (posting key '02' or '04') now only the equity capital at the transaction date is considered. Capital transactions with posting date higher than the posting date of the shareholding transaction are no longer covered.
The descriptions of vouchers, postings and fixed asset objects generated by the capital consolidation were improved.
If a shareholding account is not a fixed asset account then the corresponding postings do not yield a fixed asset object.
At compensation of differences via posting record '03' (Defer tmp. diff. amount) the usual parameters for fixed asset objects can be entered, if a fixed asset account is entered in the consolidation parameter 'EK' as the account for "Defer difference amount".
An account for deconsolidation was supplemented in the consolidation parameter 'EK', which is used for deconsolidation of companies at equity. Up to now always the account for deconsolidation of the consolidation parameter 'KK' was used. The release conversion program provides the copy of the account from 'KK' to 'EK'.
The amount in the line "Dissolution dif.amount as liability" enterable on the right side of the map of "Update Equity EF" (FORTEQE) now is added to the value of the line "Changes per act.period" on the left side. Thus the value of the line "Conditional value" on the left side represents the amount, which is displayed as "Investment book value KF" on the left side for the next period.
The entry fields of amount and debit/credit flag in the line "EF-adjustment P/L negative" have been dropped. Thus the value of the line "Conditional value" on the right side represents the amount, which is displayed as "Investment book value KF" on the right side for the next period, too.
Like postings of minority interests on all postings affecting net income now also minority interests on all postings on capital accounts of a company (in addition to capital consolidation) can be processed (see above).
The calculation and posting of minority interests now considers a previous/comparative fact entered in the "group companies + monitor" (KTKGES) just like a previous period.
Percentage changes of the direct minority interests now are processed even if the minority interests become zero in the current period.
Posting keys for capital increase/decrease ('K27'/'K28') are used instead of the posting key for carry forward ('K21'), if the indirect minority interests had changed compared to the previous period.
Changes of the equity (increase or decrease) compared to the previous period are no longer processed, if they concern inter company accounts (e.g. dividend income out of phase), since amounts would be eliminated twice otherwise.
Attributes for posting keys can be entered for the consolidation parameter 'JU'. Each posting key is allocated to one account. This posting key is used for all automatic postings on this account.
The flag for "posting affecting net income" of a consolidation voucher has been extended by the new value 'K' besides 'X'. While 'X' still refers to postings affecting net income, 'K' refers to postings on capital accounts beyond capital consolidation. Like 'X' 'K' is set automatically and provides ability of this voucher to be designated for minority interests (see above).
The sort options 'KB' (sort by posting keys) and 'KS' (sort by transaction development columns) were supplemented in the list application "consolidation postings" (KONBUCH) for the purpose of validation of postings on accounts for transaction development. Sorting is applied in the following sequence:
At sort option 'KB' and 'KS' posting key or development transaction column are displayed as fixed columns, respectively. The display of postings on accounts without allocation to a transaction development (account flag 2 empty) is suppressed at these sort options.
The possibility to change the posting key was supplemented in the action "mass update" of the list application "Consolidation postings". For this purpose you have to enter a posting key type as well as a posting key in the dialog box for mass update. The posting key type has to be consistent to the account flag 2 of the accounts of the selected postings.
A column "balance parallel currency" was supplemented in the list application "consolidation postings" (KONBUCH). Here the total of several postings (e.g. at sort by account number) in parallel currency is displayed, just like the display of the corresponding total in group currency.
The note at display of postings on statistical accounts now only is output, if the display contains statistical accounts besides true accounts (see above).
Consolidation postings now can be entered including the entry of an amount in parallel currency like already possible for postings. A parallel currency always has to be entered in junction with conversion rule 'VPW'. Especially this is helpful for entering historical data. Other conversion rules ('SK', 'PDK') are not allowed..
The deletion of consolidation postings now is allowed at sort option 'KK', too. It is no longer necessary to switch to sort option 'KE' for the deletion of consolidation postings.
The automatic validation of fixed asset transactions on group level against consolidation postings is no longer performed, if the flag "ex KONBUCH" is set to 'X' for the current period (ABR), since then group transaction development reports are generated based on consolidation postings instead of transactions. However, the action "check grp.transact./consolid.post." still is available.
Two new applications, "Object sort defs. list" (OBJSORT) and "Object sort defs. column ref. list" (OBJSORTSP) provide an opportunity to define the sequence of objects (companies, business units, subgroups, controlling objects) at the report display with objects in columns. You find these new applications in the branch "Reporting" -> "Report definitions" of the menu tree.
In OBJSORT a general key is defined, which has to be specified at the corresponding report list display. The determination of the sequence of objects is defined in OBJSORTSP.
Mouse double click in the report list applications (REP, REPK, REPSTR) has become column sensitive. Double click into a column for an attribute, that can be changed in the single record application REPE (description, report option, number of periods with compar. fact, columns option etc.) branches to REPE. Double click in all other columns branches to the report result display (REPERG).
The action menu of the report list applications was redesigned for the purpose of more clearly separating the action for creation of a new report from other applications (only lists) and avoiding unintended activation.
The action "report mirrored" was supplemented in the action menus of list and single record applications (see above).
The subsequent application "Company financial statement monitor" (EA) was supplemented in the action menu of the applications "company reports" (REP) and "reports in group structure" (REPSTR). The subsequent application "Group companies + monitor" (KTKGES) was supplemented in the action menu of the application "group reports" (REPK).
The report option 'P' ("with parallel currency in BIKIS") was dropped, since the former method for ratio reports (BIKIS) is no longer supported. Reports with this report option should be deleted.
Up to now the values of a position node line (line type 'P', value flag '6') were suppressed in the report result list, if this node is expanded and the lines following thereunder end with a totals line. From now on these values even are suppressed, if thereof-positions are following the totals line.
Several changes were performed to reduce the memory demand for the display of very large reports. Up to now in some cases the limit of available menory was exceeded.
When displaying a report result list with objects (companies, business units, subgroups or controlling objects) in columns you now have the opportunity to define the sequence of the objects (see above). Furthermore you can display up to 100 amount columns besides each other.
With the aid of the new application "report mirrored" (REPERGS) transaction development reports now can be displayed mirrored (i.e. lines and columns interchanged) (see above).
A new report type 'T' was defined for B/S + P&L reports. Reports with this report type are created with four value columns:
The column option '#ROHWT' incl. its column descriptions and formulae was introduced for the purpose of displaying reports with this report type.
You now can store ratios in the database tables for position balances (POSSAL) just like for real positions. Up to now only positions with value flags '0', '1' and '2' were written into POSSAL. From now on in addition positions with value flags '-', '6' and '7' are written into POSSAL.
The new transaction development column for repostings was supplemented in the standard column options '#KAPG' and '#KAPK' for capital transaction developments (see above). Individual column options have to be supplemented in the same way. Since posting keys '17' and '34' no longer are allocated to the transaction development column for carry forward, the capital transaction development report can be used for validation of carry forward.
The access to files written and read in the applications for data exchange were transferred from the application layer to the user interface layer. This has the following advantages:
For data exchange now always the standard import path is used as it is defined in the option dialogue, tab "Import/Export". No file dialogue is output at data exchange, so that this path cannot be changed.
It is inteded for the following release to support an own path for data exchange in the options dialogue.
The sub group data exchange was adjusted concerning different database table extensions. The additional attributes (e.g. posting keys of consolidation parameters) 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. account for retained earnings in account master data) aren't transferred into databases with an older release.
The extensions at the IDL Connector are documented separately.
Up to now the dimension "Report position/account" contained each account in all combinations of debit/credit flag and controlling flag 1. These combinations were created based on master data. From now on only those combinations are prepared, that refer to data in the value tables.
The unload of account balances now can be done differentiated, e.g. due to IFRS or due to local GAAP. The control is performed via control file "kcusap.ini". This supplement applies for the old interface ("kcusap.exe") as well as for the new interface ("kcusap.jar").
For the topics
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 <Group Consolidation> -> <GUIDE Group Consolidation>. 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.
The documentation of cash flow reporting already contained in the updates of the previous interim maintenance now is available online (branch <Reporting>), too, and therefore has been dropped from the CD. However, part B of this documentation is only available in German up to now.
The online documentation for master data has been divided corresponding to the grouping of menu items in the menu tree (Individual development definitions, Accounts & Postings, Company & Group data, other master data).
With this release the following English-speaking documentations in the "doku" directory are updated or completed: