The IDL Konsis 2012.0 release includes changes and enhancements to the products IDL Konsis, IDL Forecast and IDL Connector, as well as for the first time IDL Publisher.
The IDL Konsis 2012.0 release is a major release and therefore it must not be left out of the release sequence. The minimum requirement for this release is the last IDL Konsis major release 2011.0 dated August 8, 2011.
The amendments and corrections that have taken place up until the release closure for the major release IDL Konsis 2011.0 as well as for the subsequent interim release IDL Konsis 2011.1 are contained in this major release, too.
You should always perform a database backup before you install a new release. To prevent a user from losing data, a notice on the necessity of backing up data will be issued by the installation program at the start of installation.
In the face of the permanently increasing number of IDL Konsis applications accessing the database via JDBC (e.g. Group companies (charts)" (KTKGRAPH), "Report definition" (REPDEF, see below), IDL Workflow (see below)) working with IDL Konsis without JDBC connection is rarely useful. Thus the configuration of a JDBC connection is obligatory from now on.
Now the page <Options> automatically opens and the check box "Activate JDBC driver" is automatically activated at login, if no JDBC connection is activated. The check box "Activate JDBC driver" may be deactivated providing a login without JDBC connection, if it is not possible to configure the connection at once (e.g. because the driver ahs to be provided by the IT).
The login panel provides a help text for this configuration on the page "Options" when pressing the "?" button. For further advice on this subject please contact the IDL technical support.
You must always perform the release migration (see ch. 2.1) first, after a new release has been installed. For this reason, a message will be issued when you start IDL Konsis for the first time to let you know that migration has not yet taken place. This message box has now been expanded to include the button 'Start migration now'. If you click this button, migration will start automatically. Following successful completion of the migration on this way, IDL Konsis does not need to be restarted again. All of the applications will be available immediately.
If migration is not started in this manner, for instance because the logged in user does not have access rights, all other applications will be locked. The only exceptions are the applications that are used to maintain authorization data, in case the logged-in user is not authorized to carry out migration, due to the use of individual authorization groups. Following manual completion of migration, you will need to start IDL Konsis again to ensure that all of the application functions are available again.
Group development transactions used until release IDL Konsis 2007.1 (data in the development transaction table redundant to consolidation postings) are no longer available with the standard IDL authorisation groups since the authorisation for the corresponding menu items (KONANLBEW, KONKAPBEW, KONRUEBEW) had been withdrawn. On demand you can grant this authorisation to individual authorisation groups after installation of release 2012.0.
The application IDL Forecast requires a main storage of 1 GB. However, in many cases only 256 MB or 512 MB are adjusted. Please check your adjustment for the parameter "-Xmx" in the link of your IDL Konsis icon. When starting the application IDL Forecast (PLAN) a message is shown in case of lower memory allocation.
The html assistance that we know from experience wasn’t used very often is no longer included in the release CD or the installation directory provided for downloading since the 2010.1 release. If necessary, however, it can be ordered from the IDL hotline or downloaded from the service area of the IDL website. As usual, the help texts contained in the html assistance are still available online inside the application.
The new IDL Connector for the MS Excel connection of IDL Konsis delivered with this release for the first time (see below) requires at least MS Excel 2003.
A new unique standard (pluginlauncher.jar with IDL Importer) for the SAP connection is delivered with this release for the old general ledger as well as for the new general ledger. In the medium term this standard replaces the previous interfaces (kcusap.jar with IDL Importer and kcusap.exe with function modules). These previous interfaces are no longer supported from the release 2014.0 on. Please reorganise your interface until then with the aid of your IDL BI consultant. Questions on this subject are answered by your IDL BI consultant or by the IDL technical support.
When you start IDL Konsis for the first time after it has been installed, a message will be issued to inform you that migration has not yet taken place. This message box includes the button <Start migration now>. Migration will start automatically if you press this button.
In addition to the migration steps for interim release 2011.1 the migration program will also complete the following transformations in the database:
In addition to new menu IDs in interim release 2011.1 the following menu IDs are new or include new authorized actions in this release. If completely maintained customer-specific authorization groups are used, you might need to enter access rights for these menu items (BENMEN). In most cases, the menu authorizations of the user group IDLKON and/or IDLWIN can be used as a template.
The Simplified Procedure for Administration of Customer Specific User Groups is recommended as an alternative to complete maintenance of authorizations for all menu items. For this functionality, the new authorization level '0' can also be specified for menu authorization (BENMENE). This states that an authorization available for a reference user group should not be issued for the user group that has been entered.
The following menu items from IDL Forecast are no longer used. I.e. separate authorisation can no more be maintained. In case authorisations already assigned for these menu items are removed at release installation:
The menu trees (resource tree and quick starter) of IDL Konsis and IDL Winkons were revised with respect to factual contexts and unified. The following changes apply for both products:
The following modifications concern IDL Konsis:
The following modifications concern IDL Winkons:
You now have the ability to perform the user administration in IDL Konsis completely. Up to now, users had to be defined in the database or in an active directory, too. For this purpose you are able to enter a password in the application "User" (USEE) beside the user name, which is saved encoded. In addition, several rules for passwords and their maximum validity can be determined.
In this process, the real login to the database is performed exclusively with an internal user only known by the program, before the entered login data are compared with the entries of the user table. Then logins with applications outside IDL Konsis have no access to the database except for the administration user.
This login process is controlled by special entries in the ini files of the users. Without these entries the additional entry fields are not visible in the map of USEE.
Please contact the IDL technical support if you intend to apply this method.
A change log was established for the table of processing controls (VERARB). In contrast to other change logs this change log is performed independent from licences and principally always activated. The log table is initialised with the current status of VERARB at installation of release 2012.0.
The table of processing controls contains one record for each data stock (e.g. account balances, transactions of a development), per company, business unit, period and fact. As far as check sums, which are held in this table, are activated, the processing control record changes at each modification of the data. Within this change the values of timestamp, application (manual entry, import, carry forward, currency conversion etc.) and user are logged. Thus you can reconstruct at which time, by which user and on which way the data were modified. This information may be useful for backtracking problems.
The same applies to the table of group processing controls (KVERARB). However, here the significance is reduced since the majority of group processings is not maintained in this table.
New list applications "Changes of checkpoints" (VERARBLOG) and "Changes of group checkpoints" (KVERARBLOG) with appropriate selection and filter functions provide the view of the logged data.
The size of two windows of the application area can be changed by dragging the border line with the mouse. A double mouse click in the border line now reconstitutes the original sizes of the windows.
You can now define a focus colour in the options dialogue <Colours>. This colour designates the window of the IDL Konsis application which has obtained the focus, i.e. where keyboard entries take effect. The colour is displayed in the tab of this window. This entry works yet after a subsequent restart of IDL Konsis and requires the setting of the option "Gradient" in the options dialogue <Graphics>.
Several applications (e.g. "IDL FORECAST" (PLAN), "Transaction development definition" (SPIDEF), "Group companies (charts)" (KTKGRAPH)) require the activation of the feature "Modern desktop / tabbed pane" in the options dialogue <Graphics>. This option now is obligatory activated and cannot be disabled since working with IDL Konsis without this option is significantly constrained.
The filter line introduced with release 2011.0 provides many possibilities which required entries in the selection area before. Therefore several entry fields in the selection areas of the list applications were removed for the advantage of an improved clarity. This concerns lists for master files as well as for reported data. Examples:
In addition the reduction of entry fields was utilised to provide more entry fields with an own prompt text (e.g. previous / comparison fact in company financial statements monitor (EA)).
The action "Mass update" is now available in nearly all list applications and provides update entry fields for all attributes which are enterable in the corresponding single record application. As far as '*' is not permitted as a regular value of a field (like e.g. for descriptions) the entry of '*' provides the deletion of the respective field content.
A new icon was defined for the action "Details". This icon is now displayed in the tool bar of all applications supporting this action.
The hitherto restriction to a maximum of 65,000 lines at export to MS Excel is no longer existing.
Furthermore you can now decide by specification of the appropriate suffix of the file name whether a new Excel file is to be created in MS Office 2003 format (.xls) or in MS Office 2007 format (.xslx).
In addition, the user is requested if an existing file may be overwritten.
Many IDL Konsis functions refer to the period flag specified in the period master file (ABR). A wrong setting of this flag, especially of the flag 'J' (annual financial statement), may provide wrong results. Therefore now a warning message is shown if the flag is set to 'J' without having a distance of twelve months to the next previous as well as to the next following annual statement period. This may only apply in the rare case of an abbreviated financial year.
The list "Charts of positions" (POP) now supports a branch to the subsequent applications "Position/account allocations drag&drop" (Z-POSKTO) and "Position/XBRL concept allocations drag&drop" (Z-POSXBRL) for the selected charts of positions.
The actions for saving and closing a chart of positions (up to now in the toolbar of the charts of positions table) can now be invoked by icons in the global toolbar. An additional icon allows to fade out the table of the charts of positions after selection one of the charts of positions. Alternatively a new menu item in the menu <View> can be used for this.
An extended support of the XBRL functionality (E balance sheet e.g.) will be provided by the IDL Publisher (see below) from 2013 on.
The account master file was enhanced by another reference account "Account for aggregat. for planning". This entry is evaluated only by IDL Forecast (see below). It serves for the reduction of the number of accounts used for planning. The applications for the maintenance of the account master file check the accordance of several attributes (b/s p&l code, account flag, transaction development etc.) of account and allocated aggregation account for planning, however, only a warning message is shown in case of differences. There is no inheritance of attributes from the aggregation account for planning to the referencing account.
It is now permitted to allocate an account with account flag 'W' (account for retained earnings in the company chart of accounts) to an account of the group chart of accounts with account flag 'J' (account with incomplete intercompany details). E.g. this is required if dividends are distributed from the group account and therefore this account has to be provided with the consolidation function 'SD'.
The hitherto restriction to a maximum of 23 account flags 1 (functional areas) was annulled. However, the definition of more than 23 controlling flags (CK1) is reasonable only if the controlling flags are only used for a differentiated allocation of the data for one account to different positions (POSKTO). The generation of a report due to the function of expense method with representation of the functional areas in columns is still restricted to 23 areas. If more than 23 controlling flags 1 are defined then all additional data are balanced in the 23rd column.
The actions for newly entering, editing, saving and closing a transaction development (up to now in the toolbar of the transaction development table) can now be invoked by icons in the global toolbar. An additional icon allows for fading out the table of the transaction developments after selection one of the transaction developments. Alternatively a new menu item in the menu <View> can be used for this.
The table of defined transaction developments now displays the columns for validity and last modification. In addition a filter line and a print function are available for this table.
The maps with the transaction development characteristics up to now displayed beneath this table were dropped. The modification af a transaction development is now supported by a wizard just like a new entry. Descriptions in foreign languages can be deleted there now. The same applies for the dependent data.
The opened transaction development is highlighted only by a coloured background. The former designation by an arrow was dropped. The name of the opened transaction development is displayed in the title bar of the application and in the corresponding application tab.
The tab "Open tasks" now displays in a line that no table header is defined for the transaction development in a certain language. This table header is used e.g. in the company financial statements monitor (EA) but was no obligatory entry in earlier IDL Konsis releases.
Logic attributes are designated by green hook in the columns of the tables of dependent data (posting keys, development columns etc.) just like their entries in the wizards.
A copy function (entry with template) is now available for the lines of the dependent tables (posting keys, development columns etc.). Hereby at least a new key has to be entered.
Corresponding checks and possible "open tasks" were supplemented for the new posting key usage tags 'NE, 'NF, 'SNE' and 'SNF' (see below), 'B17' and 'B18' (see below), 'P' (see below) as well as 'XZA' (see below).
The call of the subsequent application "Posting keys" (BSL) was replaced by the call of the subsequent application "Transaction development definitions" (SPIDEF) in several other applications (e.g. "Development transactions" (SPIBEW)).
Besides the already existing types of transaction development areas
You can now define a new type of transaction development areas
The term "balance relevant" expresses that postings with a posting key allocated to a not balance relevant transaction development area do not affect the account balance at company closing with data transfer to the next fact. Correspondingly consolidation postings with a non balance relevant posting key are not concerned for a b/s or p&l report.
The new type is distinguished from the non-validated transaction development areas by a validation. I.e. the total of all development transactions of an account with posting keys of this transaction development area have to agree with the account balance. If this is not the case a [red] status is displayed for this transaction development in the company financial statements monitor (EA) just like a difference between the account balance and the total of all balance relevant transactions.
Please note that the validation of development transactions against the account balance is performed per development transaction area for the non balance relevant transaction development areas while the balance relevant transaction development areas are compared in total with the account balance (e.g. the total of production costs and depreciations in the fixed asset transaction development).
The classification of a transaction development area is represented by the three flags "without account agreement", "consolidation" and "balance relevant" in the application "Transaction development areas" (SBE). Not all combinations of these flags are allowed. This is clarified by the automatic setting and deactivation of the corresponding radio buttons in the application "Transaction development definition" (SPIDEF).
The new type of transaction development areas (validated, but not balance relevant) is not permitted for the transaction development 'B' (shareholdings/participations). This is not necessary since there is no shareholding report based on shareholding transactions. Only one validated development transaction area is permitted for capital and provision transaction developments (development type 'K' or 'R', respectively).
It is strongly advised to comprehend only posting keys allocated to the same type of transaction development area to one transaction development column, since the total of the transaction development column cannot be interpreted otherwise. However, principally mixed comprehensions are possible for special purposes.
With the aid of the new transaction development area type you can virtually define two (or more) transaction development details for the same account. Changes of the account balance then have to be represented by two (or more) postings: one posting with a balance relevant and one posting with a non balance relevant posting key. You can provide the non balance relevant transaction development areas with posting keys for carry forward, currency conversion differences (due to posting key usage tag) etc.. However, an automatic compensation of the difference to the account balance (posting key with usage tag 'L') is supported only for the balance relevant transaction development areas.
The sample accounting (type of carry forward = 'S' in the application "Transaction developments" (SPI)) used e.g. for simultaneous details for maturity as well as details for cash flow reporting can now be replaced by a non balance relevant transaction development area. For this purpose, you have to perform the following steps:
These changes can be performed with the application "Transaction development definitions" (SPIDEF). There inconsistent entries are listed below "Open tasks" for reducing faulty insertions.
There are new posting key usage tags 'NE', 'NF', 'SNE' and 'SNF' for additions and disposals without effect on liquidity (see below). The new posting key usage tags 'B17' and 'B18' for shareholding transactions for intercompany sales of participations (see below). A new posting key usage tag 'P' was invented for the capital transaction development for minority interest changes due to percental changes in the participations (see below). Finally a new posting key usage tag 'XZA' was introduced for the elimination of fixed asset results (see below). Data with these usage tags were supplemented in the "LieferBatch" files for continuation of the former transaction development standards.
The posting key usage tag 'AHK' (compensation of accumulated depreciation without affecting the net result) may only be allocated to transaction development areas with control for automatic depreciation calculation set to 'AHK' (acquisition costs).
From now on only four card types are supported for fixed asset objects:
The other card types valid until now ('B', 'L', 'N') are no longer permitted. However, they had no meaning different from card type 'K'. Existing fixed asset objects with the card types 'B', 'L' or 'N' are set to card type 'K' by the release migration program.
The list application "Fixed asset objects" (ANLOBJ) does no longer display any IC fixed asset objects (card types 'A' and 'Z') but only fixed asset objects of card type 'M' or 'K'. However, it still is not possible to use the same fixed asset object key for a fixed asset object (card type 'M' or 'K') as well as for an IC fixed asset object. A special error message is shown when assigning a key already used in the other table.
The entry field for a "Group/Sub-group" was suspended in the map of the single record application "IC fixed asset object" (ICANLOBJE), because IC fixed asset transactions are considered as company financial statement data. The determination of the group level of consolidating these data is performed yet at consolidation.
Furthermore the entry field "Sales date" was renamed into "Disposal from group date" for more clarification.
Descriptions of products and product groups for the elimination of current asset results can now be provided in different languages just like other master files. A language key entry field was supplemented in the maps of the list (PRO) and the single record application (PROE). The new import application (TYTPRO, see below) supports multi-language descriptions, too.
Check rule can now be comprehended to rule groups. For this purpose the table of check rule groups (PRFGRP) was enhanced by a flag distinguishing the type of the group. The following check rule group types are defined:
The table of check rules (PRF) was enhanced by an allocation of the rule to a rule group. Opposite to the allocation of check rules to exclusion groups via a separate allocation table (PRFZUO) a check rule can be allocated to only one rule group.
In addition the table of check rule groups (PRFGRP) was enhanced by an allocation to a super-ordinate rule group. This allows for arranging the check rules in a multi-level tree. This hierarchy is not available for exclusion groups.
These allocations are evaluated in the list of check rules (PRF) as well as in the list of check rule results (PRFERG) for representation of the data in a tree structure. Check rules not allocated to a rule group are listed at the end of the table in the top level.
Data of different facts can be displayed in the company financial statements monitor (EA). This is now supported if the "ex fact" (fact of determination of the group companies) is specified in the fact master file (FAC), too. However, it is presupposed that the "ex fact" is unique for all facts.
The "check and refresh of the status information" now involves a status refresh for postings, too.
The function for calculating deferred taxes in the company financial statements can now be invoked as subsequent application (sub-menu "Processings") from the company financial statements monitor (EA). The method with usage of a separate fact for the tax balance sheet is excepted from this, since the tax balance sheet fact as well as the destination fact can only be entered in the application "Deferred taxes header" (LTK).
A restriction to companies of a group/sub-group can be specified at selection of company financial statement data. Then usually an authority check for the group/sub-group was performed. This check was suspended. I.e. users having only authorisation for companies can perform a selection for group companies, too. An authorisation check is performed only for the companies of the group companies.
The selection of IC fixed asset transactions (ICANLBEW) and inventories IC stocks (ICVOR) by group companies is now supported for arbitrary facts. The group companies are determined from the "ex fact" specified in the respective fact (FAC) or the user-specific startup data (VOR).
The former actions "Fixed asset transactions", "Capital transactions", "Provision transactions" and "Development transactions" were replaced by a single action "Development transactions" in the list "Account balances" (KTOSAL). The application invoked depends on the transaction development of the account of the respective line. Thus you can branch into the transaction development details of different accounts with different transaction developments by a single selection and action.
If business units are provided with the entry of an account group in the "Company + business unit allocations" (GESUBR) then the accordance of balance sheet and p&l is automatically provided by an account balance generated on the account with account flag 'U'. The total of these balances on 'U' accounts of all business units has to result zero. This is now checked at validation of account balances. If this condition is not fulfilled the account balance state becomes [red] for all business units since the difference cannot be assigned to a single business unit.
The intercompany is now displayed with its description of up to 70 characters in the list "IC account balances" (ICKTOSAL) as well as in the single record application (ICKTOSALE).
A new list "IC-account balances and postings" has been invented for a better clearing of the IC reconciliation performed on facts below the consolidation level. Opposite to the list "IC account balances" (ICKTOSAL) here postings with specification of an IC company are displayed, too, providing a joint of all data considered in the IC reconciliation. Postings can be distinguished from balances by the entry in the column "Voucher no.".
This application cannot be directly invoked from the menu tree or via short word entry but only as a subsequent application of the "IC clearing list" (KGESGES). This proceeds at double mouse click on one of the value columns. The keys of a line (company, intercompany, consolidation function etc.) are transferred as parameters. These keys have to be unique.
The display is always performed in a couple view, i.e. the data of the company are opposed with the data of the intercompany. In case an additional subdivision is performed for couples of business units. The data are represented in a tree structure with open/close buttons.
Values are only displayed in group currency (in case in addition in transaction currency) just like in the "IC clearing list". The group currency amounts are calculated by an implicit currency conversion if not yet present just like in the IC reconciliation itself.
There are no direct modification options in this application. Depending on the origin of the data you first have to branch into the list "IC account balances" (ICKTOSAL) or into the list "Postings" (BUCH). This is supported by a double mouse click into the column "Voucher no.".
It is now checked whether all IC fixed asset transactions for one fixed asset object are allocated to the same business unit. The status for IC fixed asset transactions in the "Company financial statements monitor" (EA) becomes [red] if this is not applicable.
The short word entry for calling the list "Inventories IC stocks" was changed from "ICBEW" to "ICVOR" to avoid confusions with development transactions ("...BEW").
The flag "Display all postings" is now set in a subsequent display of the list "Postings" (BUCH) when called from the list "Vouchers" (BEL) or by the action "Details" in the list "Postings". Then the usually suppressed automatically generated postings are displayed, too.
You can now select postings without assignment to a controlling object in the list "Postings" (BUCH). For this purpose, you have to enter an asterisk ('*') in the first entry field (Chart of controlling objects).
Postings with a posting key allocated to a non balance relevant transaction development area (see above) are displayed below the totals per posting record, since they do not contribute to these totals.
When branching off from the list "Account balances-origin list" (KTOHER) into the posting list, only postings out of active vouchers are displayed.
The display of the business unit was supplemented in the analysis list of check rule results (PRFERFANA).
The p&l result of a business unit with account group 'G' (p&l) is now reposted to the balance sheet business unit (account group 'B' or 'M') at carry forward. The check of the reposting column of the capital transactions (posting keys with usage tag 'XJU') is now performed for the total of all business units since this check would fail for a single business unit.
IC fixed asset transactions are now converted according the currency conversion rule of the fixed asset account. If the account is converted historically (conversion rule 'FDK'), then no exchange rate effects or currency conversion differences are generated in the IC fixed asset transactions.
Exchange rate effects calculated for carry forward development transactions originating from a posting are now provided with the same origin fact and origin voucher number. This avoids a double calculation of exchange rate effects.
The currency conversion now performs an adjustment between inventories IC stocks (ICVOR) and the corresponding account balances. If the total of all inventories IC stocks per account is equal to the account balance in local currency, then the equality is also provided in group currency. If the total of all inventories IC stocks per account is less than the account balance, then the currency conversion provides that the total in group currency is not greater than the account balance. Differences (only rounding differences) are cleared on the first inventory IC stock record. The same applies for the conversion from group currency into parallel currency.
Postings for deferred taxes are now supplied with the same posting record number as the origin posting providing an easier backtracking.
The company financial statement for reclassification of postings in case of merger (MERGESBUCH) now displays a message window with the information that postings have been processed.
Up to now only one previous / comparison period could be specified for calculation of check rules. Thus is was not possible to define check rules with respect to e.g. the previous month as well as check rules with respect to the last annual statement. Furthermore the arbitrary entry of a previous / comparison period easily could provide faulty entries.
From now on the flag for the period control of a check rule (PRFE) may be set to one of the following values in addition to 'X':
A special treatment is provided for p&l accounts in check rules with period flag 'M' or 'Q': The amount of the previous period is always set to zero if the determined previous period has the period flag 'J' since p&l data always start with 0,00 at the beginning of the accounting year.
With the entries 'J', 'Q', or 'M' the previous / comparison fact is always determined from the period master file and applied at calculation of check rule results independent from a simultaneous explicit entry. This entered period is only used for check rules with the period control flag set to 'X'.
Thus existing check rules with period control flag 'X' are processed like before. However, it is recommended to switch these settings in the check rule definitions to the new values ('J', 'Q', or 'M') since this is more unique. The entry 'X' will be suspended in one of the next IDL Konsis releases.
Check rule positions (PRFPOS) can now be supplied with a minus operator. The according values then are subtracted from instead of added to the result of the check rule side. E.g. you need this supplement for calculation of differences between actual and previous period.
Check rule positions (PRFPOS) can now be restricted to a transaction development area. Then all data with posting keys allocated to this transaction development area are considered at calculation of the check rule result.
The enhancements reported here apply for the calculation of check rule results on the level of company financial statements as well as on the level of group statements if applicable.
The "First consolidation repostings" (KU) usually is automatically performed within the capital first consolidation ('KK'), however it also can be invoked separately, too, e.g. after subsequent changes of the development transactions. Now an own status column for this processing was introduced in the group companies monitor (KTKGES). The status is set as follows:
The generation of a consolidation report (display of the contributions of the different consolidation functions in separate columns) requires an allocation of the consolidation functions (KVA) to the columns. This allocation was given up to IDL Konsis release 2010.0. With release 2010.1 these given allocations were replaced by the ability of user specific definitions. As a consequence all new users had to provide for these allocations manually. To avoid this the former standard is now available on the release CD in form of a "LieferBatch" file in the directory "Spaltenoptionen_Konsolidierungsreport". The import into the database has to be performed by the new application for import of consolidation functions (see below).
Posting keys with posting key usage tag 'L' (automatically calculated actual modification) can now be entered in all consolidation parameters (KTKPARxx), if the respective account is allocated to an automatic transaction development.
Several restrictions with respect to the permitted accounts in the diverse consolidation parameters (KTKPARxx) were eased.
Now there are principally no restrictions of a KTKPAR account to one single b/s p&l code. If e.g. only asset accounts were permitted up to now, then liability accounts are now permitted, too, and vice versa. Thus e.g. you can now specify asset accounts as accounts for retained earnings in diverse consolidation parameters. The same applies for profit and loss accounts. Thus now loss accounts are permitted for the account "Dividend income out of phase" in the consolidation parameter 'FK'.
The accounts "Capitalise goodwill" and "Reposting participation" (only 'EK') in the consolidation parameters 'KK' (capital first consolidation) and 'EK' (equity consolidation) as well as the accounts "Impairment of hidden reserves" and "Appreciation of hidden reserves" in consolidation parameter 'EF' (update equity) have no longer to be allocated to a fixed asset transaction development.
Accounts without the account flag 'D' can now be specified as depreciation accounts in the consolidation parameters 'KK' and 'EK' even if the account flag 'D' is used. E.g. this may be required if the depreciation account is an intercompany account and provided with the account flag 'J'. Furthermore p&l account may be specified as account for "Currency conversion effect participation".
The former account "Investment associated company" of consolidation parameter 'EK' was renamed into "Reposting participation" to clarify its function. Furthermore the restriction for this account of being a shareholding account (account flag 'B') was dropped. For at equity consolidation this account must no longer be a fixed asset account, too. However, then the complete account balance is processed, since other transaction developments do not distinguish between acquisition costs and depreciation reserves.
Despite of the eases of restrictions, the selection box for accounts still offers only the accounts valid with respect to the former rule, since one of these accounts will be selected with a large probability. However, in many cases, other accounts are permitted.
The term "Difference amount" is yet only used for capital consolidation. The corresponding accounts in the consolidation parameters 'SK' (debt consolidation) and 'AE' (p&l consolidation) are now designated as "Suspense account".
Entry fields for controlling objects are no longer offered in the single record maps for consolidation parameters, if the user has no licence for the feature "Controlling".
The accounts "Net income elim.", "Net income elim. indirect", "Posting aff. net income elim." and "Posting aff. net income elim. indirect" of the consolidation parameter 'FK' (minority interests) have to obtain the flag "Transaction carry forward", if they are capital accounts. The flag is automatically set by the release migration program for all accounts already used in consolidation parameters.
The list "Consolidation postings" (KONBUCH) now allows the mass-copy of postings to a different posting record number.
Postings created by mass-copy now always yield the posting status '5' (manually entered) and thus can be modified arbitrarily afterwards, even if the origin postings were automatically created and may not be modified.
The list "Consolidation postings" (KONBUCH) now offers an entry field for selection by "Voucher company". Just like the same selection field in the list "Consolidation vouchers" (KONBEL), the postings are filtered now with respect to the company number in the voucher number. In contrast to the selection by "Company" complete vouchers are displayed, i.e. including the postings for the opposite company.
You can now select consolidation postings without assignment to a controlling object in the list "Consolidation postings" (KONBUCH). For this purpose you have to enter an asterisk ('*') in the first entry field (Chart of controlling objects).
The net income effect in parallel currency is now displayed in a new column of the list "Consolidation postings" (KONBUCH) as far as parallel currency is used.
Consolidation postings with a posting key allocated to a non balance relevant transaction development area (see above) are displayed below the totals per posting record in the list, since they do not contribute to these totals. These postings cannot be selected for calculation of deferred taxes or minority interests.
A double click in the column "Voucher no." in the list "Consolidation postings" (KONBUCH) now invokes the action "Details".
The restrictions for permitted accounts in the different posting records for compensation of difference amounts in capital consolidation vouchers (posting record number 02 up to 08) were eased.
Consolidation vouchers and postings must no longer be entered on facts with the business unit flag set to 'M' (mixed with and without business units). The restriction was already valid for automatic generation of consolidation vouchers. It is substantiated by the fact that consolidation requires a unique definition either with or without business units.
Consolidation postings can no longer be supplied with posting keys for shareholding transactions even if the account is not allocated to any transaction development. This entry had no meaning but provided wrong expectations.
The functions "SK/AE repostings after consolidation D&C/I&E" ('SU', 'AU') generates postings without specification of controlling objects since these entries might distort controlling reports. Therefore it is no longer checked at mass-update of these postings (e.g. for supplement of a missing posting key) whether a controlling object is specified.
Automatically generated neutralisation postings now may be modified (e.g. for entry of a different posting key or another neutralisation account). Then the posting status of the posting changes from '5' (automatically generated) to '1' (manually generated) providing the preservation of this posting at the next generation of neutralisation postings.
Processing of Arbitrary Accounts
Arbitrary accounts may now be entered in the form entry application for first consolidation. Up to now only capital accounts were permitted. Amounts entered for additional accounts are considered at calculation of the difference amount.
Reposting of Currency Effects in Shareholdings
It is now possible to eliminate currency conversion differences and exchange rate effects in the shareholding transactions (shareholding transactions with posting keys with usage tags 'K' and 'U' generated by the currency conversion).
An account "Currency conversion participation" including related posting key and controlling objects was supplemented in the consolidation parameters 'KK' and 'EK' for control of this feature.
The 'KK' status of the group companies monitor (KTKGES) becomes [red] if the prerequisites are valid, i.e. even in periods without other changes in the participations.
The additional repostings are generated by the automatic first consolidation as well as by the forms entry application if this account is entered in the consolidation parameter. An additional consolidation voucher is generated with elimination of the group currency amount of the shareholding transaction at the shareholding company and reposted on the account specified in the consolidation parameter. The company of the reposting depends on the transaction development area of the posting key: acquisition/production costs at the subsidiary, depreciations at the shareholding company.
These vouchers are provided with posting type 'EP' except for the annual financial statement. I.e. they are not carried forward in the course of the year since they receive different values in each period due to currency fluctuations.
Indirect minority interests are calculated and posted for these new postings if the respective posting keys are provided with the usage tag 'FF'.
Additions and Disposals without Effect on Liquidity
A company already participated from previous periods and without changes of its percentage or value based shareholdings within the group companies is called an "addition without effect on liquidity" if it is incorporated into the group financial statement for the first time because of other reasons (switch from an unessential to an essential company). A "disposal without effect on liquidity" is the reversion of this process.
Consolidation steps are required for these processes (first consolidation or deconsolidation, respectively) but cannot be detected from the shareholding transactions (additions or disposals in GESGES). It was possible to represent these processes in IDL Konsis with some tricks, but a distinction of the transaction development repostings ('KU') for cash flow reporting was missing.
Additions and disposals without effect on liquidity are processed independent from shareholding transactions. An entry in the new field "Transition of consolidation" in the definition of the membership of the company in the group companies (KTKGESE) has to be done instead. Here the values 'NLA' (disposal without effect on liquidity) and 'NLZ' (addition without effect on liquidity) are allowed. In addition you have to specify the date for disposal from the group companies or for addition to the group companies, respectively, to date the transaction. The new attribute is not carried forward into the next financial year since it loses its effect there.
The capital first consolidation is triggered by the entry 'NLZ'. Then the shareholding transactions carried forward are treated like additions and thus eliminated. Group/sub-group and voucher number are entered there as a proof of processing. A deconsolidation is performed at entry 'NLA', correspondingly. The "Status check and refresh" acts due to this rule.
First Consolidation Repostings (KU)
Additions without effect on liquidity are differentiated at first consolidation repostings. Usually the reposting is performed with a posting key with usage tag 'E' (addition to group companies), while transactions for additions without effect on liquidity are reposted on a posting key with usage tag 'NE' (additions without effect on liquidity), if it is defined. The deconsolidation acts correspondingly (posting key usage tags 'F' or 'NF', respectively). Posting keys with the usage tags 'SNE' and 'SNF' have to be defined for transaction developments with sample accounting for elimination of these postings.
The process of first consolidation repostings was changed, since different posting keys are required for capital transactions, too. From now on the capital transactions are eliminated in the 'KK' voucher with posting keys with usage tag 'E' or 'NE', respectively. In addition capital transactions are processed in the first consolidation repostings, too, and there reposted to posting keys with usage tag 'E' or 'NE', too.
The prerequisites for processing of the first consolidation repostings were modified, too. Now a reposting is performed independent from shareholding transactions, but only dependent from addition to group companies date (KTKGESE). Then e.g. first consolidation reposting is performed for all sub-group companies at addition of a complete sub-group.
Percental Changes of Shareholdings
Consolidation postings on the minority interest account now are provided with a posting key with the new usage tag 'P' (percental changes of shareholdings) at first consolidation of participation changes. A posting key with the usage tag 'N' (other current change) is used like before if no posting key with usage tag 'P' is defined. Thus different events can be further differentiated.
A new independent function serves for the correct processing of intercompany sales of participations on associated companies. This function combines the up to now separate functions for disposal and addition of shareholdings and provides the required result, that nothing is changed from the group point of view.
Two new posting key usage tags for shareholding transactions were introduced for description of this event:
Posting keys with these usage tags were supplemented in the "LieferBatch" files (see above). On demand posting keys with these usage tags have to be manually defined if the "LieferBatch" standard is not used.
A shareholding transaction with posting key with usage tag 'B17' requires the additional entries of profit or loss value, the related account and the company which bought the shareholdings. An entry filed for "Intercompany sale addition company" was supplemented in the entry map for shareholding transactions (GESGESE). A shareholding transaction with the posting key with usage tag 'B18' has to be entered for the company specified there. Both shareholding transactions have to specify the same percentage. Differences are reported by the function "Check & refresh participations". In this first version of this function, all existing participations have to be sold.
The group companies monitor (KTKGES) displays an additional status column for the new function designated by the abbreviation 'IK'. If the shareholding transactions described above are existing, this status is set to [red] by "Check & refresh status information".
You can find the new function "Intercompany sale of shareholdings IK" in the action or object menu of the group companies monitor (KTKGES) in the sub-menu "Capital consolidation ...". It generates two consolidation vouchers:
The posting rules described above apply for fully consolidated subsidiaries. However, they apply analogously for quota or at equity consolidated companies.
Direct minority interests are not affected by this event and therefore remain unchanged. However, indirect minority interests may be different between selling and buying shareholding companies. In this case manual postings still may be necessary.
This available first stage of extension supports only the case that selling and buying shareholding companies are in the same sub-group, that the subsidiary has only one shareholding company and that all participations are sold. Following stages of extension will support other constellations (partly selling of participations, several shareholding companies, sale for a super-ordinate group to a sub-group and vice versa, sale between parallel sub-groups).
The origin voucher number is now written into the posting remark of minority interest postings ('FF') on other consolidation postings affecting net income (posting record '09' of the 'FF' consolidation voucher) to ease matching.
Consolidation postings for adjustment of carry forward at percental changes of participations are now provided with the posting key with the new usage tag 'P' (percental changes of participations) at update of minority interests ('FF'). The posting key with usage tag 'N' (other current change) is used like before, if there is no posting key with usage tag 'P' for the respective transaction development. Thus different events can be further differentiated.
A pro rata annual result (with respect to the participation of the shareholding company) is calculated from the net result and put in the entry form of the update equity function, if a company financial statement is present for a company consolidated at equity. Additional prerequisites are the definitions of the accounts "Prorated net income" and "Prorated net loss" in the consolidation parameter 'EF'. Furthermore, a prorated net income must not be booked yet. The proposed amount may be changed manually.
A new entry line (account, posting key, controlling object) "Actual changes associated companies" was supplemented in the consolidation parameter 'EF' for update equity initialised by the release migration program with the data of the fields "Reposting participation" of the consolidation parameter 'EK' (equity first consolidation). However, deviating entries are allowed. This account is now used for the counter-postings of the postings for "Prorated net income" and "Prorated net loss". The ability of specifying a posting key is new, too. Up to now a posting key with usage tag 'KM' was used for this posting.
The threshold value account in the consolidation parameters 'SK' and 'AE' now may be assigned to a fixed asset development. A fixed asset object is automatically generated on this account and recorded in the posting when the first posting is generated for this account.
Rounding differences for quota consolidated companies are now compensated in the SK and AE repostings after consolidation ('AU', 'AU'). If defined, a posting key with the usage tag 'Q' (change of the quota) is used for the compensation posting. Alternatively, a posting key for current changes (usage tag 'L' or 'N') is used.
Development transactions for exchange rate effects and conversion differences from conversion into parallel currency are no longer considered by the SK and AE repostings after consolidation ('SU', 'AU'), since the currency conversion would post the same amounts a second time otherwise.
Up to now, the "Elimination of fixed asset results" ('ZA') always inverted the group-internal sale. I.e. the sold fixed asset object remained at the disposal company in the group point of view. Now alternatively, the fixed asset can be reported at the addition company corresponding to reality, but with the valuation rate of the original fixed asset object at the disposal company.
This process is controlled by the new flag "Company for posting" in the consolidation parameter 'ZA'. This flag is set to 'A' (Posting for disposal company) corresponding to the hitherto process. Alternatively, you can set this flag to 'Z' (Posting for additional company). This also is the new default value for all new consolidation parameters. With flag position 'Z', you have the following postings in the 'ZA' voucher:
The elimination of fixed asset results ('ZA') aborts now with an error if fixed asset transactions for one fixed asset object are allocated to different business units.
The former consolidation function 'JU' (Reposting group result) had become obsolete by the invention of result postings with 2009.2 and neutralisation postings with 2010.0. This function is now completely suspended, i.e. the call was removed from the action menu of the group companies monitor (KTKGES). The consolidation parameter 'JU' can be maintained no longer, too. Authorisations for these menu items are deleted by the release migration program.
The currency conversion for consolidation postings from group currency into parallel currency was conformed to the currency conversion of company financial statement postings. Among others, this concerns the following subjects:
It is strongly emphasized to allocate a main memory of 1GB (specification of "-Xmx1024m" in the destination of the icon link for the IDL Konsis call) for IDL Forecast. A corresponding warning message is shown, if less memory is specified. The maximum allocated memory now is displayed in the "Info" box (menu <Help> --> <Info>) beside the memory demand currently required, too.
You can now invoke the actions for saving (up to now a button in the selection area for company and business unit) and closing (up to now an icon in the toolbar of the scenario list) of a scenario with icons on the global toolbar. Saving can be invoked in the men <File>, too. An additional icon allows hiding of the scenario list after selection of a scenario. This can be invoked through a new entry in the menu <View>, too.
Menu entries, which do not trigger an immediate action but rather open a window, are now uniquely designated by three dots at the end of their description.
Windows depending on a scenario (account/controlling/intercompany display, business case viewer, balance difference display and calculation statistics) are yet displayed after opening of a scenario. The description of the opened scenario is displayed in the title bar of the application as well as in the corresponding application tab.
A new entry in the menu <View> extended especially for IDL Forecast provides fading in and out of the icons for rules in the table area. Up to now a button in the table panel served for this purpose.
Two other menu items, "Save panel positions" and "Restore panel positions", were supplemented in the menu <View> for IDL Forecast. The current panel positions are stored, when invoking the first menu item, and restored, when invoking the second.
The options dialogue IDL Forecast was enhanced by the control "Update validities automatically". With this control, you can switch off the automatic check of the cell validation after returning from a subsequent application. This check can be invoked by the new item "Refresh cell validities" in the menu <Action> as an alternative.
The options "Enable null/empty differentiation", "Enable controlling planning" and "Enable intercompany planning" have been suspended from the options dialogue. They may not depend on the user since these controls have influence on the exported balances. Therefore, these controls now are valid per scenario and have to be maintained in the scenario manager instead. Please mind: The controls for all scenarios are set to the standard ("null/empty" and "controlling" yes, "intercompany" no) with installation of the release 2012.0.
The active scenario is now emphasized by a folder icon (up to now an arrow and indented) in the scenario list.
A new table icon in the toolbar of the scenario list enables a control which columns are to be displayed or suppressed, respectively. Up to now, this control was performed via the object menu (right mouse key) of the scenario list. The ability of displaying the reports contained in the scenario, the user and the timestamp of the last modification (saving) of the scenario, was supplemented, too.
The wizard for definition of a scenario was enhanced by a navigation area listing the pages of the wizard. Thus the user is informed, where he is located in the wizard (designated by bold characters), which steps are yet missing (pages with missing or erroneous entries are provided with suitable icons), and which pages have been disabled (designated by grey characters). The wizard opens the respective page when clicking on a page description provided, that all previous pages are finished (labelled with a green hook). The <Ready> button can be pressed on any page.
An own tab for specification of the planned business units per company was supplemented in the panel for scenario characteristics. In addition, a page with statistical information (e.g. volume of the scenario) was added to the scenario characteristics.
The number of accounts used for planning can now be reduced by the usage of accounts for aggregation of planning. When allocating an account to an account for aggregation of planning in the account master files (see above), this account is no longer listed in the planning entry form. Actual data on these accounts are balanced at the aggregation account for planning. This applies for loading of balances on the forecast fact and on the plan fact, too.
You can now branch off from the planner spreadsheet into the lists "Accounts" (KTO), "Positions" (POS), "Position+Account allocations" (POSKTO) and "Report line descriptions" (REPZEI). These menu items were supplemented in the menu <Action>. In case the keys of a selected cell are transferred as parameters.
You can now use the tabulator key to step through the entry fields of the planner spreadsheet. The cursor then jumps to the next cell.
Beside globally acting parameters defined within the rules (e.g. terms of payment, general allowance, taxes), you can now define parameters specific for companies or periods (e.g. tax rate). Then the determination of the value used proceeds in steps: If a key specific value (for company and period) is defined, it is used; in the next step, a value with partial allocation to the keys (e.g. only the company) is used and finally a global value. All values representing a percentage can be defined as such a parameter.
Parameter values can be defined in the characteristics panel of the scenario wizard. The name and its values can be entered directly. The parameter name has to start with '$'. Company and period can be chosen from a selection box invoked by a double click. Each defined parameter has to obtain a standard value (i.e. without company and period). If you commit the panel with <Ok>, the scenario is automatically calculated with the new parameters. Parameters from another scenario can be imported using a button in the characteristics panel.
You have to specify a parameter entry (e.g. "$TAX") in the rule definition, if it is to be applied there. All fields with the ability of parameter entry are labelled yellow (colour can be modified in the options dialogue). The panels of the rule definition wizards now contain a button for the display of all available parameters. A warning message is shown if a rule refers to a non-defined parameter. These rules are branded in the list of rule templates, too.
A new check function (callable in the menu <Action>) lists all references in the rules of the scenario currently opened to parameters, which are not defined within the scenario. Another function displays the setting of the parameters of the selected period. If the parameters of a scenario have been modified, then a dialogue appears at the next opening of the scenario with the question, whether the modifications are to be applied.
The wizards for definition of a rule were enhanced by a navigation area listing the pages of the wizard. Thus the user is informed, where he is located in the wizard (designated by bold characters), which steps are yet missing (pages with missing or erroneous entries are provided with suitable icons) and which pages have been disabled (designated by grey characters). The wizard opens the respective page when clicking on a page description, provided that all previous pages are finished (labelled with a green hook). The <Ready> button can be pressed on any page.
A button <Takeover from selected cells> was supplemented in the wizards for definition of rules on the page "period control". This button activates the period control and puts the periods of the cells, currently selected in the planner spreadsheet, automatically into the selection box. In addition, the rule wizards were enhanced by a button selecting exactly those accounts, which are currently selected in the spreadsheet in the right-hand selection component.
Payment terms from now on are interpreted in the way that all liabilities are paid exactly after the course of the given number of days. Up to now it was assumed that the liabilities are paid constantly up to this date.
The entries of payment terms in days in the sales rule and in the purchase rule now remain maintained in the rule template and the generated business cases and are displayed at reopening of the rule template and in the business case viewer.
When opening the wizard for a new transition rule, a transition allocation is automatically proposed for each account selected in the planner spreadsheet. In addition, the transition rule allows for the allocation of the same account on the right-hand side to several or all allocations. An account selection field and a button "Set selected account as target account for all marked transitions" were supplemented for this purpose. In addition the following changes were performed:
The tax rate in the sales, purchases and expenses rules can now be defined as a firm value instead of a reference to a statistical account.
A negative base value factor is now permitted in the sales, purchases, expenses, income, transition and provisions rules. E.g. this is necessary for users which do not distinguish between profit and loss accounts by different b/s p&l flags.
A standard base value can now be set on the first page of the provisions rule just like in the transition rule and other rules with base values. This standard base value then is automatically applied for all account allocations.
Entry fields for input taxes were supplemented in the investment and in the purchases rule. The wizards were enhanced by an additional page for this purpose.
The field for the percental values is now always set to the residual percentage in the dissolution rule and other rules with dissolutions. I.e. if the first period was defined with 50% dissolution and the user activates another dissolution period, then the remaining 50% will always be displayed automatically in the field "Percentage". All other periods are initialised with 0% combined with the note, that 0% has to be adjusted to the real part.
Amounts on the debit accounts of a base value rule are now always posted with positive sign independent from the b/s p&l flag of the selected account, as long as the base value balance is positive. On the other hand, the values are always posted as credit values for the credit counter accounts, as long as the base value balance is positive. The debit/credit flags of the postings are switched for negative base value balances. (Attention: Base value rule templates already existing may exhibit another behaviour with release 2012.0 than before and have to be adjusted correspondingly!)
After opening a scenario, the panel for rule templates is displayed before the rule templates are loaded. Therefore, the panel initially displays only the note, that rule templates are loaded.
Copying rule templates and folders is now performed in two steps: "Copy" (or <Cntl+C>) and the new action "Paste" (or <Cntl+V>). Up to now, copying was performed completely at action "Copy", but the copy was located in the same folder as the original and had to be relocated afterwards.
A wizard for generating a folder structure for rule templates can now be invoked via the object menu (right mouse key) of the rule template tree. Firstly, you have to specify whether the folder structure has to be constructed due to companies or due to positions. Furthermore, you have to define the rules for the construction of the folder names out of the available keys and descriptions. After commiting, a folder is created per position or per company, respectively, with the corresponding name.
The characteristics of a rule template now exhibit a list of all parameters (see above) used in the rule template.
The description of a business case group is now supplied with the name of the rule template. The corresponding business cases are labelled with the period.
The selection of a statistical account used as a factor in rules (e.g. as tax rate) provides the display of a list of all business cases referring to this account.
The business case display now exhibits the concerned period. Rules within a rule group are displayed ordered by periods in the business case viewer.
A parameter reference (see above) is displayed behind the respective value display (e.g. "tax rate 19% (Parameter $TAX)") in the business case viewer.
The mouse pointer changes its picture to a hand icon when pointing to an account assignment in the business case viewer indicating that a subsequent display can be shown by a mouse click.
When deleting a business case, now all values generated on accounts by this business case optionally can be deleted, too, while values entered in rules are maintained. The dialogue <Delete values of the business case, too?> provides a corresponding option ("Yes, with values") for this purpose.
The descriptions of the modifications generated by rules were revised. Amongst others, the account number and the short text of a base value account from the p&l are indicated for assets, liabilities and other b/s accounts.
Up to now the business case view of a transition rule displayed only the percentages being transferred. From now on the amounts are displayed, too.
The T account representation of the account display was revised. Amongst others, rule icons are now displayed like in the list representation, and the selection of a business case in the business case viewer selects the corresponding account changes, too.
Following changes have been performed for the balance differences list:
Several functions of IDL Forecast were revised for the purpose of reducing response times. This especially concerns the following actions:
Report Idents (RID) were relocated into a new database table (K064 instead of K021) within the database. Furthermore, you find the texts for report IDs no longer with the object type 'AGB' but rather with object type 'RID'. The usual user is hardly affected by these changes. The rearrangement rather affects individual export interfaces (e.g. to MIS/OLAP systems).
The restructuring primarily has implications on authorisation data. The entries for the object authorisation of report IDs are now held with object type 'RID' (up to now 'AGB'), too. The authorisation for report IDs can now be defined in the user startup data (VORADMIN) independent from the authorisation for charts of positions.
Another advantage of this reorganisation is, that report IDs and charts of positions no longer share the same name space. I.e. you can now define report IDs with the same key as a chart of positions.
At this opportunity the former "Flag default report" (for forms entry) was subdivided into two flags: "Flag form data entry" (applicable / not applicable) and "Flag default report" (default report for forms data entry).
In this connection, it was also changed, that report groups are no longer kept in the table of report IDs (RID). The report type 'G' was dropped correspondingly. There rather is an own application "Report groups" for maintenance of report groups, which can be invoked by the short word 'RPG', too.
A new integrated application "Report definition" was created for the maintenance of report IDs (RID) and report line descriptions (REPZEI) which can be invoked with the short word 'REPDEF'. Especially this application serves for a more intuitive definition of the report line description by a suitable handling.
Like the application "Transaction development definition" (SPIDEF) this application initially displays a list of all defined report IDs with its essential attributes. New reports can be inserted or existing reports can be edited, copied, or deleted by the corresponding icons of the toolbars.
The maintenance of the master file of a report ID is performed by a wizard constituted of two pages. You can define the validity and multi-lingual descriptions on the first page. The second page comprehends the other attributes report type, transaction development, reference report id, column options and flags for forms data entry.
The data of the report line descriptions are displayed in the lower part of the screen. There are three display variants in three registry tabs:
You can define the report structure in the view <Tree>. You can displace lines in the tree structure via drag & drop with the mouse. Arrow icons can be used to indent and re-indent selected lines. The same applies to the view <OLAP>. If a report is opened containing entries for "Allocated position" located behind the respective position, a warning message is issued reporting, that these entries are deleted when saving (see below).
Another icon provides the display of a list of all defined positions, ordered by charts of positions, in a second table beneath the table of report lines. Positions from this table can be inserted into the tree table at the suiting position per drag & drop with the mouse, too. Depending on the rank of the position in the report and the allocation of accounts, the most established line types are proposed for these lines. This technique especially allows for a quick and intuitive definition of new reports.
The line number is yet displayed in the tab <Report lines>. It no longer can be entered, but rather is set automatically due to the graphically defined order of lines ascending with a distance of 1 and therefore might deviate from the original numbering.
The detailed editing of a report line is supported by a wizard that is invoked by the object menu (right mouse key) or by the pencil icon in the toolbar of the table after selecting one line. The wizard comprehends several pages:
The previous application "Report line descriptions" (REPZEI) permitted arbitrary combinations of line types and value flags although some of them were not reasonable. The new application "Report definition" converts these combinations into reasonable values, which are processed in a similar way at report generation. This conversion can be accepted or refused by the user.
In this connection, the line type 'R' (detail line without printing) is no longer supported. Now the line type 'E' (total line without printing (neg)) offers the possibility of using a total memory located behind the current line in a second pass and negating it. However, this is still not supported for all report types.
The report lists (REP, REPK) now display the status columns immediately behind the version description, i.e. the status columns are usually visible without scrolling. In contrast, unessential additional information, like chart of accounts or type of the chart of positions, are no longer displayed.
The debit/credit control of a report is no more defined by the report option, but rather by a separate attribute of the report header, and thus can be combined with other report options. The previous report option 'N' (with D/C as per acc.balances new) is no longer available. The new entry field for debit/credit control is set in all report headers and offers additional entry options:
Debit/credit control remains ruled out for cash flow reports (i.e. has to be set to '-'), since it would not work because of the special structure of the report. However, you can now provide transaction development reports with a debit/credit control different from '-' (see below).
The generation of "Position balances from reports" (POSSAL) is no more controlled by the report option, but rather by a separate attribute of the report header. The previous report options 'P' (with storing position acc.balances with comp) and 'S' (with storing position acc.balances) are no longer available. The new entry field "Storing position balances" offers the same parameter values 'P' and 'S', which can now be combined with other report options.
The generation of a report result with complete account details is no more controlled by the report option, but rather by a separate attribute of the report header. The previous report options 'K' (with complete acc.details as per POSKTO) and 'L' (with valid acc.details as per POSKTO) are no longer available. The new entry field "Complete acc.details" offers the same parameter values 'K' and 'L', which can now be combined with other report options.
The report option 'I' (report with intercompany details) is now available for transaction development reports (report type 'D'), too. Then the intercompany values are listed as the first detail level below the accounts. Data without intercompany specification are listed separately. With appropriate column options, you can display the data with intercompanies in columns (combined with transaction development columns if wanted).
This report is available as a company report and as group report. However, consolidation postings are always treated like data without intercompany, since consolidation postings do not directly specify an intercompany. Thus it is suggested to set the control "Restriction StatementOAcc/Consolid." in the report header to 'S' (report only with statement of accounts).
A debit/credit control can now be specified for transaction development reports, too, and thus is evaluated at generation of transaction development reports. Then the allocation to a position is always performed for the complete account and thus controlled by the total of all transaction development columns. The allocation may be dependent from the balance (total of all development transactions) or the sum of balance and postings. The setting '-' for the debit/credit control (corresponding to the hitherto behaviour) now no longer effects that values are reported at both positions, but rather provides the display on the position whose b/s p&l code agrees with the b/s p&l code of the account.
The new report option 'R' combines the report options 'C' (report from controlling balances) and 'T' (report with sub-group details) for b/s and p&l reports (report type 'E') and thus allows for a report for the function of expense method (allocation of controlling balances to positions due to controlling flag 1) with details for sub-groups. Account balances are processed for accounts without controlling details. Reports generated with report option 'R' exhibit the following detail levels below accounts:
Sub-groups on the highest level can be displayed in columns with appropriate report column options. Then the first detail level below the accounts exhibits sub-groups of the second highest level or controlling objects, respectively.
Furthermore you can now provide controlling reports (report type 'C' / controlling flag 1 in columns) with report option 'T' (reports with sub-group details). Reports generated with these parameters exhibit the following detail levels below accounts:
Controlling objects (e.g. cost centres) can be displayed in columns with appropriate report column options. Then the first detail levels below the accounts exhibit sub-groups in two levels, if present.
A flag "Build repeat column group" was supplemented in the table of "Report column options" (SPO). This flag has to be specified if an "Object type for report columns" was entered for this column option providing the display of the objects of the first detail level of the report (e.g. sub-groups, companies) in columns beside each other. The new flag is effective if several columns (SPA) of this column option are designated as repeatable (i.e. without the flag "Do not repeat for each key"). Then the new flag allows for the following alternative representations:
Column options allow for the definition of a column which represents the value of all line as a financial ratio to a reference position (e.g. volume of sales, total assets). When displaying this kind of report in a twisted view, i.e. e.g. a sub-group report with columns per sub-group, then this financial ratio always referred to the value of the total group. This rule was modified with release 2012.0. From now on, the financial ratio refers to the column key, i.e. the value per sub-group in the example.
A flag "Display intercompany" was supplemented in the selection area of the report result display (REPERG). An additional column exhibiting a firmly allocated intercompany is displayed in the account related lines when setting this flag to 'X'. This column was displayed by default up to the release 2010.0, but then was dropped. Please note that this value is determined from the current account master file and is not part of the stored report result.
The new component IDL Workflow allows for modelling of workflows in IDL Konsis. The application of this component requires the configuration of a JDBC connection to the database (see above). The first stage of expansion of this component released with 2012.0 comprehends a function for graphic interactive entry and representation of workflows, as well as a function for processing these workflows with status setting and integrated calling ability of IDL Konsis applications.
Both new applications, "Workflow editor" and "Workflow tasks", are pooled in the new menu <Workflow> located in the menu tree as a sub-menu in the branch <Extras / System administration>. The workflow range of functions is offered to all users without an additional licence.
The workflow editor can be invoked via entry of the short word 'WORKFLOWED', too. After starting, the application displays a list of all workflows already defined. The graphic editor opens on a double click on one of these workflows.
Alternatively the star icon can be clicked in order to create a new workflow. Then the new workflow has to be provided with a description in a wizard.
The workflow editor is a graphical interactive application for designing a workflow. A workflow consists of the following elements:
Each activity has to be specified in detail by a new wizard. Here you can enter multi-lingual designations and descriptions, duration or dates of the activity and persons in charge. You can allocate an IDL Konsis application to an activity with specification of the related parameters (similar to the definition of workflow-automates).
An activity can also represent a complete sub-workflow. Thus workflows can be nested hierarchically and even complex structures can be clearly arranged visually.
A workflow defined in this way yet represents only a template. A real entity of the workflow is created by pushing the icon <Start workflow>. The workflow started can be provided with a start date. A workflow can be started multiple times. Started workflows are listed in "Workflow tasks" (see below).
The list of workflows shows how many times a workflow has already been started. A workflow already started cannot be modified any more.
The workflow task list can be invoked via entry of the short word 'WORKFLOWETA', too. It shows a list of all started workflows. A restriction of the list e.g. to the display of all open activities is provided by the filter line.
For the moment the list is not restricted to single users even if persons in charge were entered for the activities. Rather each authorised user is able to process the following steps.
The selection of an activity provides the display of the corresponding workflow in the bottom part of the application window. Within this activities and milestones are supplied with an icon representing their states (e.g. closed, next step to be processed). The states can be explicitly set. The states of milestones are automatically set dependent from the state of the previous activities.
A double click on an activity opens a wizard, allowing for the start of the allocated IDL Konsis application, as far as the activity is allocated to an application. Furthermore, the status can be set. The status can be set to a lower value, too.
The control of suppressing message at import in the options dialogue <Import/Export> was revised and is now easier to understand. The previous settings are transferred automatically. The dialogue now contains two check box groups, <Start import> and <Finish import>.
The group <Start import> has the leading check box "Suppress start message box". It determines, whether the first message box with the request, whether errors are to be displayed or not, shall be output. The second check box "Suppress messages" is only activated, if the first check box is switched on. The entry in the second check box replaces the response to the first suppressed message box.
The group <Finish import> has the leading check box "Suppress final message box". It determines, whether the final message box with statistical information about the import process shall be shown or not. The second check box "Print final message automatically" is only activated, if the first check box ist switched on. The entry in the second check box provides an alternative output on a printer of the suppressed message box. This may be interesting for time-consuming import processes (e.g. during the night).
New import applications have been supplemented for the following tables for the import of files as well as for the import via database tables:
The standard import/export formats ('#TXT', '#DB') for the additional tables in the tables "Import/export format IDs" (IEF), "Fields for export/import formats" (IEFDEF) and "Allocations import/export fields to formats" (IEFFEL) are delivered with release 2012.0. Individual formats can be supplemented there.
The calling application "Data import and display" (IMPORT) for the file import and "IE job controls" (IEJOB) for the import via database tables were enhanced by calls of these import applications.
The import application for consolidation functions is required for the take-over of the "LieferBatch" file with recommended allocations for the consolidation report.
The error log file was reduced from seven lines per error to two lines (erroneous field and error message).
If an import job is aborted before the start of the import (e.g. at the security message "Do you want to delete?"), then the job is no longer set to an error state and thus can be started repeatedly without being copied before.
It turned out to be unhandy to transfer all parameters for an import application in the external call in the '%' syntax when calling an IDL Konsis import job out of the IDL Importer. Alternatively, it is now possible to write the values in to a parameter table in the database which is evaluated by the IDL Importer.
This new database table I005 contains columns for all relevant transfer parameter and, in addition, the job ID, the menu item of the application to be invoked, the name of the database and the user ID.
This new method is activated by the entry "pluginlauncher.jar" in the external menu call. In addition please note the following:
Examples for external calls:
The template has to be adjusted for reading parameters from the table I005 by the IDL Importer job. The transfer of passwords (SAP, IDL Importer and reconnection to IDL Konsis) was realised on the level of the "rstart" command line.
The group-wide and the group/sub-group exchange of data have been modified to include various database enhancements. For this reason, they are not compatible with previous release versions.
Data for report IDs are processed by the group-wide data exchange like before, however, they now are written into a separate file with suffix '.K064'.
Release 2012.0 contains a first edition of a new IDL Connector version. This version will replace the previous IDL Connector in one of the next releases. For the time being, both versions can be used in parallel. However, we recommend users with intensive usage of IDL Connector to use the new version already now for an efficient changeover at the time it is required.
The available edition of the new IDL Connector comprehends the read function but not yet any export function and no entry form. The following features of the previous IDL Connector are not yet supported:
The new IDL Connector requires at least MS Office 2003 and the operating system Windows XP. With MS Excel 2010 you have to permit the execution of AddIn's in the security centre below the menu item "Settings of access protection".
The new IDL Connector is realised as a discrete application and can be started by an icon on the desktop referring to the executable application IDL.IDLOffice.Office.exe. The version for MS Office 32 Bit is installed by default. A 64 bit version is available for users with MS Office 64 Bit. Please contact the IDL technical hotline for modifying the installation correspondingly.
The application window contains a menu bar on the left-hand side with the menus <Excel>, <Excel -> Extras>, <IDL KONSIS>, <Settings>, <Settings -> Refresh> and <IDL OFFICE>. The right-hand side displays status information for the called functions.
The menu <Excel -> Extras> contains the menu item "Add AddIn" providing the activation of the Excel AddIn for the new IDL Connector. All Excel documents have to be closed when starting this function.
The menu <Excel> allows for the start of MS Excel either for editing a new document or for opening an existing document. However, you can start MS Excel directly, too, after activation of the AddIn. Then the IDL Connector application is started automatically on demand.
The login to a database (and the logoff, too) is performed in the menu <IDL KONSIS>. Then IDL Connector is connected with the IDL Konsis server, since all database accesses of the new IDL Connector are carried out by the IDL Konsis application kernel. Therefore, the login takes place in the original IDL Konsis login dialogue.
The connector references of existing Excel maps can be converted to references for the new IDL Connector. You can convert single files as well as complete directories. Corresponding menu items are located in the IDL Connector menu <Excel -> Extras>. A security backup of the original Excel file with the old connector references is created automatically.
Apart from that, the handling of the new IDL Connector is not significantly different from the handling of the previous IDL Connector. However, the maps for definition of the connector references contain no mandatory entry fields (except for "System"), but are initialised with the values defined in the IDL Connector application settings. Please pay attention for the specification of certain keys like e.g. "Period" or "Fact", since otherwise the complete database table may be read and meaningless total values are calculated. Default values are used for the control parameters ("Modus", "Balance option"), if not specified.
A manual located on the release CD as a separate documentation (in German only) describes the first steps with the new IDL Connector. For further information, please contact the IDL technical support.
The entry form sheet was enhanced by the ability for entering several intercompanies per controlling object in the intercompany account balances. The entry form sheet supports now user defined decimal separators.
New fields were supplemented in the export functions of several master files.
The internal password (see above) is now supported by IDL Connector, too.
Memory utilisation and performance were optimised. MS Excel 2007 formulas are better supported by execution on several processors.
The release 2012.0 CD contains the component IDL Publisher, too. IDL Publisher serves for the generation of business reports in the direction of MS Word and, from the year 2013 on, for the XBRL reporting (e.g. the generation of an E balance sheet, the publication in the federal bulletin or the requirements of bank reports (FinRep)). The software of IDL Publisher is installed depending on the user licence.
Up to now, there were two methods of specifying the tree structure of a report for the representation in an MIS/OLAP system by allocation of positions to superordinate positions in the report line descriptions (REPZEI):
In the course of the realisation of the new application "Report definition" (REPDEF, see above), the meaning of both allocation possibilities was modified as follows:
A new unique standard (pluginlauncher.jar with IDL Importer) for the SAP connection is delivered with this release for the old general ledger as well as for the new general ledger. In the medium term, this standard replaces the previous interfaces (kcusap.jar with IDL Importer and kcusap.exe with function modules). These previous interfaces are no longer supported from the release 2014.0 on. Please reorganise your interface until then with the aid of your IDL BI consultant. Questions on this subject are answered by your IDL BI consultant or by the IDL technical support.
The release 2012.0 CD contains the current edition of the DCW interface for DCW release 3.50.
The interface was enhanced by posting keys for merger.
The following English language documentations have been updated or enhanced in the documentation directory together with this release: