This release 2010.0 includes modifications and enhancements of the products IDL Konsis, IDL Forecast, and IDL Connector.
The release 2010.0 is a main maintenance and therefore must not be left out in the release sequence. Prerequisites for this release are the last main maintenance 2009.0 from August 19th 2009. However, it can also be installed following the installation of the interim release 2009.1 from November 26th 2009 or the interim release 2009.2 from March 29th 2010.
The supplements and corrections to the main maintenance 2009.0 as well as the interim maintenances 2009.1 and 2009.2 up to the release date are included in this main maintenance.
This documentation describes the enhancements since the interim maintenance 2009.2. For all enhancements since the main maintenance 2009.0 please read the documentations "Release 2009.1 News" and "Release 2009.2 News", too.
A database backup has to be performed in principle before installing a new release. An advice for the necessary database backup is output by the installation program at the beginning of the installation to protect the user from data loss.
It is now checked for the consolidation of D&C (SK) and I&E (AE), whether all relevant intercompany balances are stamped with a consolidation voucher number as an evidence of their processing by the respective consolidation function just like already before the shareholding transactions with respect to the status of capital consolidation. If not all intercompany balances are stamped the respective status is set to [red].
For the purpose to avoid a change of the status values of closed periods it is strongly recommended to lock these periods, if the group financial statements have not been locked yet. Prerequisite for the period lock is the activation of object authorisation for all users.
For the purpose of unintentional change of status values of periods closed with a former IDL Konsis release the automatic status refresh introduced with release 2009.1 was deactivated (see below). Now the status refresh has to be invoked manually via menu action. This change was already delivered with the updates 2009.1 C or 2009.2 A, respectively.
Due to the new procedure for representation of the net result of consolidation vouchers (see "Release 2009.2 News") already introduced with release 2009.2 a group financial statement should be processed either completely using the hitherto release completely with the current release including carry forward of consolidation postings but excluding the function "Reposting group results".
The release migration for IDL Konsis (see ch 2.1) has to be principally performed as the first step after installation of a new release. The call of other applications is inhibited before performing the migration. Only applications for maintenance of authorisation data are excluded from this rule for the case, that the user has no authorisation for invoking the migration program due to the usage of individual authorisation groups.
After invocation of the release migration program IDL Konsis has to be restarted for the authorisation for all application functions.
Due to technical reasons the migration of IDL Forecast data cannot be performed within the IDL Konsis release migration. The migration of IDL Forecast data has to be started separately. A new entry in the action menu of the application "Planner spreadsheet" (PLAN) serves for this purpose (see below).
Additional functions of the MS Excel connection IDL Connector of IDL Konsis are planned for future releases, which require at least MS Excel version 2003. Therefore we recommend an upgrade to MS Excel 2003 or, even better, MS Excel 2007.
The migration program for this release performs no conversions in addition to the migration programs for the interim releases 2009.1 and 2009.2. However, the migration program has to be invoked once after release installation for generation of consistent release information of the different subsystems.
Deletion of Menu Authorisations:
The menu items 'EABVORxxx', 'LOEVORxxx' und 'PERGESxxx' ('xxx' = 'ANL', 'BET', 'KAP', 'RUE', 'SP0', 'SP1', ... 'SP9') as well as 'REPERGGxxx' and 'REPERGKxxx' ('xxx' = 'KAP', 'RUE', 'SP0', 'SP1', ... 'SP9') were already deactivated with release 2009.0 and have no longer any meaning. You have to delete all individual authorisations for these menu items before installation of this maintenance in order to delete these menu items when installing this subsequent release 2010.0. For each group only one menu item with 'xxx' = 'SPI' is remaining.
New Menu Authorisations:
The following menu items are new with this release. If completely entered customer specific authorisation groups are used, authorisations (BENMEN) for these menu items have to be provided. As a rule the authorisations of the user groups IDLKON or IDLWIN may serve as a sample.
New menu items in IDL Konsis:
New menu items in IDL Forecast:
Additional new menu items had already been supplemented with the interim releases 2009.1 and 2009.2. Please inform yourself there if you have left out these interim releases.
As an alternative solution to the complete definition of authorisations for all menu items the procedure for simplified care of customer specific user groups is recommended. With this functionality the new authorisation level '0' can be entered for menu authorisations (BENMENE), too. It declares, that a menu authorisation issued for the reference user group is not issued for the given individual user group.
The new standard authorisation group IDLWINSA was supplemented for the product version IDLWINKONS. Like the corresponding authorisation group IDLSYSAS for the product version IDLKONSIS a user allocated to this authorisation group is enabled to administrate other users and their authorisations but himself is not authorised for any application function.
Key parameters can now be provided with the extra specification '#OPT' at allocation of menu items to a workflow-automat in the application "Menu structure" (MENMENE). '#OPT' provides the output of an optional entry field for this key in the selection area of the workflow-control application, i.e. it can be entered but is not required. '#KEY' has priority to '#OPT' in workflow-controls with many menu items specifying '#KEY' as well as '#OPT' for the same parameter: The parameter field becomes a required entry field and the parameter is always supplied at application call.
A parameter for the chart of accounts was supplemented in the table for menu structure (MENMEN) for definition of workflow-controls. The chart of accounts is supplied for calls of functions for unload of data out of remote systems by the calling application "Data import and display" (IMPORT), too, and thus may be required if these functions are to be called by a workflow-automat.
The list application "Menu structure" (MENMEN) for definition of workflow-automates was enhanced by an action for "Mass update". There you can modify all defined parameters for several menu items in one step.
A button <Options> was supplemented in the login panel. When pushing this button a new panel appears where you can specify the database connection for the JDBC access. The entries merely correspond to the additional entries for IDL Forecast but are now required for new IDL Konsis functions (graphic display of the group structure KTKGRAPH), too.
You find further advices for specification of the JDBC database connection in the help text displayed when pressing the <help> button of this additional map.
The left and right borders of the application window are now displayed smaller, if no display area (e.g. resource tree) had been dragged into the border. Thus more space is left for application data.
The progress display of IDL Konsis was aligned to the progress display of IDL Forecast.
A find function was supplemented for the short word entry field. While entering the first letters short words suiting to the entry are determined and displayed in a drop down box below the entry field with a little time delay. If the desired short word is displayed, you can select it using the mouse pointer or the up and down keys without completing the short word entry.
The find function takes not only the short word keys into account but the menu item descriptions, too. Thus you can enter e.g. "group" or "currency" and receive a list of suitable functions. This applies for users with foreign user interface languages (French, Spain), too.
The find function even can include help texts. For the purpose to support this feature with good performance at run time a find index is built at the first start of IDL Konsis with this new release for each user. Since this index build requires some seconds a progress display is output during this time. This progress display contains two buttons to abort the build of this index, if it takes too much time (e.g. at connection via application server). <Cancel> affects only the current start of IDL Konsis, i.e. the build of the index is repeated at the next start. <No index> works permanently, i.e. even at next start of IDL Konsis no find index is build and the find function remains restricted to short words and their descriptions. The find function including help texts merely provides the offer of menu items for documentation for special items.
In addition you can activate an automatic correction of write errors via an icon (representing an 'A') besides the short word entry field. If this button is set on, then e.g. at entry of 'KTOSLA' the application 'KTOSAL' is displayed as the first menu item in the list of found menu items and is invoked when pushing <Enter>.
Another new button beside the short word entry field allows the control, whether newly called applications are to be displayed in a new tab or not. This buttons affects only applications called via short word entry or by selection from the menu tree (resource tree, quick start menu), but not applications started as a subsequent application via action or object menu out of other applications.
The options dialogue "Colours" was newly designed. All settable elements are displayed with their foreground and background colour and a text template on this page, so that all colour settings can be modified together and in context.
Three slide bars for the colours red, green, and blue as well as one slide bar for the setting of the brightness are displayed above this display of the colours of the elements. When pulling one of these slide bars the others are automatically aligned. These slide bars act upon all displayed elements and provide "harmonic colours" in their concurrence. You can exclude single elements from this harmonic colour setting by locking them against modifications. A padlock icon beneath each element serves for this purpose.
A reset button is output on the right hand side of this harmonic colour setting providing a reset of all colours to the original settings (last committed state). Additional buttons serve for export (disc icon) and import (directory icon) of colour sets. The colour sets are stored in a special format with suffix ".icos" meaning "IDL colour set". Colour sets can be transferred from one user to another this way.
Below these buttons you find a selection box with predefined colour sets. If you select one of these colour sets then all colours and all slide bars are automatically aligned. If one colour is modified or one slide bar is pulled then the selection box is reset to an empty selection.
If you do not like the harmonic colour composition, then you can set single colours like before. A mouse click on a colour box opens a colour dialogue like e.g. in MS Excel, which offers colours for selection. Pushing the button <more> opens the colour dialogue used in IDL Konsis up to now, that supports the colour settings in different ways (Colour palette, slide bars or numeric entries).
Some colours are determined like before and cannot be modified neither by harmonic colour settings nor by individual colour selection.
The options of the tab "Graphics" in the options dialogue were combined for improved clarity:
The previous flags "Table zoom" and "Enhanced quick starter" are now generally activated and can no longer be deactivated.
You can now create bar and pie charts out of all amounts displayed in IDL Konsis. This is true for all list and form entry applications as well as the IDL Forecast spread sheet. Three icons were supplemented in the title bars of these applications for this purpose.
The table icon displayed on the right is always activated. A mouse click on this icon activates the cell mode, i.e. a mouse click on an arbitrary cell does not select the complete line selected otherwise but only the single cell. A range of cell is selected at pressed mouse key, that can combine several lines as well as several columns. Alternatively you can select several single lines by several subsequent mouse clicks while holding the <Ctrl> key. Selecting a cell with deviating line or columns provides the automatic completion of a matrix of selected lines and cells. Only columns with numeric values are selected.
Alternatively a chart display can be triggered without change into the cell mode. Then the selection of lines in the usual line mode is always applied to all table columns with numeric values.
After selection of the desired cells you can create bar or pie charts from these values by mouse click on one of the other new icons. These charts are displayed in a new area on the application desktop. If more than one line and more than one column were selected, then several bar or pie charts are displayed beneath each other. Depending on the selected cells the bars or pie pieces, respectively, are designated with the contents of the fixed columns (e.g. account number) or with the table headers.
These diagrams refresh themselves automatically if values are modified. This especially applies applications for entry of values (form entry, IDL Forecast spreadsheet).
You can create an arbitrary number of diagrams, which are stored as tabs of this desktop area. These diagrams remain unchanged even after modification of the keys and new data selection in the original application. Therefore the diagrams display the original keys. However, the diagrams are automatically closed, if another application is invoked in the same tab.
The area for the display of the charts contains the following buttons:
Accounts with account flag 'U' (compensation account for business units) now may be provided with entry flags for the purpose of entry of postings on these accounts. This especially concerns the entry of postings affecting the net result for business units that are capable only for balance sheet or p&l accounts.
The new account flag 'G' specifies an account for group results. This account is required if the new result postings of consolidation vouchers affecting net result (see below) are not to be posted on the general result account (with account flag 'E') but rather on a separate group result account.
The new account flag 'N' specifies neutralisation accounts. Neutralisation accounts are allowed only for group charts of accounts. You may not enter any company financial statement data on neutralisation accounts. Consolidation postings on these accounts may only be entered, if a neutralisation account is specified in the corresponding consolidation parameter. Therefore they are usually not displayed in the account selection box (exception: neutralisation account of a consolidation parameter).
It is emphasized to specify the accounts for "charging balance sheet" and "charging profit & loss" of the consolidation parameter 'JU' (reposting group results) as neutralisation accounts. Then the next period carry forward automatically supplies all consolidation parameters with these accounts as neutralisation accounts.
The automatic generation of position account allocations for company charts of accounts with respect to the allocated group accounts with entry of an "account if D/C changed" now correctly considers account allocations with deviating debit/credit flags as well as the allocation of group accounts and their "account if D/C changed" to the same position.
An attribute for a firmly allocated company was supplemented in the table of controlling objects. The entry of this attribute is possible in the single record application (CNTE) as well as via import (via import table I103, too). At import a transformation from external into internal company keys is supported, too. This attribute is displayed in the table of the lists "Controlling objects" (CNT) and "Controlling balances" (CNTSAL).
The firm allocation of controlling object to a company provides that reported data (controlling balances as well as postings and intercompany balances with controlling attributes) for this controlling object may only be entered for this company.
You can now select fixed asset objects without allocated fixed asset objects on the level of the group chart of accounts by entering '*' in the field for an allocated fixed asset object in the list "Fixed asset objects" (ANLOBJ).
The new development column usage tag 'MER' serves for specification of transaction development columns for mergers. These columns are automatically checked for a total of zero for all development transactions and consolidation postings similar to columns for repostings. However this check is not performed for single companies but rather for group financial statements at creation of group transaction development reports, since the disposal by mergers are posted at other companies than the additions.
The new posting key usage tags 'ME' and 'MF' serve for the specification of posting keys for additions or disposals by merger, respectively. They are automatically determined by the (new) functions for mergers (see below) and applied to the generated consolidation postings. In addition, you can define manual posting keys for merger and allocate them to the transaction development column with usage tag 'MER', since the posting keys with usage tag 'ME' and 'MF' are not admitted for manual usage.
The posting keys with the usage tags 'ME' and 'MF' are allocated to the sample accounting for transaction developments with sample accounting. Thus there exist additional posting key usage tags 'SME' and SMF' for automatic elimination of the sample accounting. If you define posting keys with usage tag 'ME' and 'MF' for a transaction development with sample accounting, then you have to define posting keys with usage tags 'SME' and 'SMF', too.
The new posting key usage tag 'B16' was invented for representation of mergers in the shareholding transactions. A shareholding transaction with a posting key with this usage tag describes the principle merging process between shareholding and merged company as a disposal of participations.
You find enhancements of the former standard transaction developments by definitions of development columns and posting keys for mergers in the directory LieferBatch on the release CD.
You can now define transaction development areas without agreement to account balances. For this purpose you have to set the new flag "Without account agreement" for this development area (SBE). Another new flag specifies for development areas without account agreement, whether the according data are to be consolidated or not.
Even automatic generated transaction developments for cash flow reporting ("S9") may be enhanced by development areas without account agreement. Of course, the related data have to be manually provided. However, there still may be only one development area with account agreement for these transaction developments.
The specification of a transaction development area as "without account agreement" merely acts upon the posting keys allocated to this development area. Development transactions with these posting keys are not considered in the total to be compared with the account balance. Postings and consolidation postings with these posting keys are not considered at calculation of the totals of debit and credit amounts and the amount affecting net result.
Data with posting keys allocated to transaction development areas without account agreement principally can be carried forward as far as a posting key for automatic carry forward (usage tag 'V') is allocated to this development area, too.
The specification of a transaction development area without account agreement as "to be consolidated" or "not to be consolidated", respectively, affects the consolidation functions (especially the elimination of existing data) and the currency conversion. Data with posting keys allocated to not consolidated development areas are converted like statistical amounts, i.e. by a fixed exchange rate of 1, if not otherwise specified in the posting key conversion rules (BSLUAW), while data with posting keys allocated to a consolidated development area are converted like other data, i.e. e.g. by the closing date exchange rate.
Two new attributes "merged into" (company) and "merged at" (date) were supplemented in the company master data. These two attributes have always to be specified together and are not only displayed in the list "Companies" (GES), but rather in the monitor applications for company (EA) and group (KTKGES) financial statements, too, in separate columns as far as the merged-at date is located within the actual period.
If "merged at" is specified the valid-until period of the company is automatically set to the closing date of the second following annual statement. Although no data for the company financial statement of the merged company may be entered in the subsequent period, consolidation vouchers from merging have to be carried forward once.
Reported data for a controlling object (controlling balances as well as postings, consolidation postings, intercompany account balances and IDL Forecast data with this controlling object specified) may not be entered for a company, if the controlling object is firmly allocated to another company (see above).
Consequently the selection boxes for controlling objects offer only controlling objects, which either are allocated to the actual company or to no company, in these applications.
If the allocation of an account to a transaction development is modified, then data (transactions, postings) may exist for this account, which had obtained a posting key for the wrong transaction development. Up to now these data were not displayed and thus could not be deleted. However, errors might be caused by these data in subsequent processing (e.g. currency conversion), that could not be easily corrected.
Therefore the development transaction lists (ANLBEW, KAPBEW, RUEBEW, SPIBEW) were enhanced by the facility to select data with "Development = '%'". Then all transactions stored in the database are displayed independently from the transaction development of the account and can be deleted, too.
The automatic calculation of the changes in the actual period has been modified. Up to now the current changes always were calculated from the difference of the account balance and the total of transactions with other usage tags (e.g. carry forward). From now on the current change is calculated from the difference of the account balance and the total of all other transactions. Amongst others this allows the definition of additional posting keys for manual entry of special subjects (e.g. addition/disposal by merger).
This modification applies only to automatic transaction developments without sample accounting, since all posting keys without usage tag are allocated to the principal account details to be manually cared (e.g. maternity of liabilities) for transaction developments with sample accounting.
Development transactions with posting keys allocated to development areas without account agreement (see above) are not considered in the total to be compared with the account balance. These transactions are not considered at automatic generation of account balances from development transactions, too. However, they contribute to the check sums. The transaction lists (ANLBEW, KAPBEW, RUEBEW, SPIBEW) do not integrate these transactions in the usual order of the table but rather display them in a separate block behind the effective data. Thus the displayed totals can be understood.
Postings with posting keys allocated to development areas without account agreement (see above) are not considered in the totals of debit and credit amounts and in the calculation of the amount affecting net result.
Attributes for "Profit or loss value in local currency" and "Profit or loss posting key" were supplemented in the table for shareholding transactions.
The profit-and-loss attributes (account, posting key, value) must be specified only in connection with shareholding posting keys for disposal (usage tag 'B03') or merger (usage tag 'B16'). The restriction of the "Profit and loss account" to be a profit and loss account was dropped.
A merger (posting key with usage tag 'B16') always represents a total disposal of the merged company. These rules have to be followed:
The inventories IC-stock (ICBEW) now only allow the specifications of current asset profits. Negative amounts as well as negative percentages representing current asset losses are no longer permitted, since current asset losses may not be eliminated (lowest value principle).
The list "Postings" (BUCH) is now invoked with sort option 'KG' (sort by accounts) when branching from the account balances origin list (KTOHER) into the origin postings providing an easier reproduction of the audit trail.
The data entry form now displays invalid accounts, too, if a previous period was specified for comparison and balances existed for this account in the previous period. However, these lines are locked against data entry for the actual period.
The consolidation parameter 'JU' (reposting group result) is no longer carried forward, since its function is disabled from now on (see below). If you have supplied the accounts for charging balance sheet and charging profit & loss with the new account flag 'N', then all other consolidation parameters are supplied with these accounts as neutralisation accounts providing an uninterrupted transition from the charging function of 'JU' to the functionality of the neutralisation accounts.
The consolidation method of a merged company is modified from 'V' (fully consolidated) to 'K' (no consolidation) at carry forward of the group companies (KTKGES) from an annual statement into the next period.
The consolidation postings from merging processing are carried forward differentiated. Thus e.g. a voucher with consolidation function 'PM' (see below) is carried forward into a voucher with consolidation function 'VM' allowing an accumulation with 'VM' vouchers carried forward (and eliminated by the 'PM' voucher).
Development transactions supplied with conversion rule 'VK' (predefined exchange rate) and an associated exchange rate now are transferred including these conversion parameters. This applies for development transactions generated from postings with these data, too.
At transfer of shareholding transactions it is checked, whether the transferred data are identical to data already existing. If true an entry of a voucher number is maintained as a proof of a processed capital consolidation.
As a first step this control had been implemented for all shareholding transactions as a whole. However, this implementation caused a necessary repetition of all capital consolidations, if only one shareholding had been modified. Therefore now the entry of each single shareholding transaction is maintained if it is identical to a transferred transaction.
The only gap in this procedure is the case, that a shareholding transaction originally present is no longer contained in the newly transferred data. Then there is no transaction with a voucher number to be deleted for the purpose to set the 'KK' state of the group companies monitor to [red]. Thus in this case only a message is output advising the user of the necessity of a repetition or deletion of the processed capital consolidation.
You can now apply the check of the transfer of company financial statement data to the next fact to data on statistical accounts (B/S P&L code '5' to '9'). For this purpose you have to set the flag "Account group checks" in the fact master data (FACE) to the new value 'S' (including statistical accounts).
The default currency conversion rule for development transactions, postings, and consolidation postings with posting keys without account agreement depends on the new attribute "Consolidation" of the table "Transaction development areas" (SBE):
Of course, deviating conversion rules may be specified in the transaction data themselves or in the table "Posting key conversion rules" (BSLUAW).
The profit or loss value in group currency of shareholding transactions is calculated based on the new field for profit or loss value in local currency and the exchange rate of the real value of the shareholding transaction.
The field profit or loss value in group currency of the share holding transactions is now transformed at exchange of the group and parallel currency. This transformation is performed via a new calculation based on the profit or loss value in local currency and the exchange rate of the real value of the shareholding transaction.
Several new consolidation functions were defined for the new functionality for merger (see below). 'P' was selected as the common leading character. The second character is chosen similar to the KVA names for deconsolidation or to the KVA names for carry forward and deferred taxes:
Consolidation vouchers with these consolidation functions in the voucher number are created by the new consolidation function for mergers see below).
The additional KVA keys 'F0' to 'F9' for minority interests now can be inserted manually at demand just like the KVA keys 'K0' to 'K9'. However, in general these keys are automatically generated at the first occurrence of more than one shareholding modification within one period.
The group companies now are ordered by investment level in front of the former order by company number at sort option 'A' (flat table) of the list KTKGES. Thus the holding company is always displayed in the first place.
The group-companies monitor displays in its table a new status column for mergers with column header 'PS' beneath the status column 'KS' (disposal from group-companies) as far as merger transactions are present. In this case the attributes "merged into" and "merged at" of the company master data (see above) are displayed in additional columns, too.
The menu Action of the application KTKGES was modified and enhanced as follows:
A new function provides the graphic display of the group structure. You can enable this function via short word "KTKGRAPH", by selection from the menu tree (resource tree or quick starter) in the branch "Group consolidation", or as a subsequent action of the list "Group-Companies and Monitor" (KTKGES) in the branch "Processings". The required keys are either transferred from the previous application or the start-up data of the user.
This application offers two alternative representations "Group structure" and "Shareholder transactions". You can switch between them via action menu:
The nodes displayed in the graphics (groups, companies) offer an object menu (right mouse key) independent from the action menu, which supports the call of different subsequent applications for the respective object.
It is required for this application to press the button <Options> in the IDL Konsis login panel and activate the entry "Activate JDBC driver" in the subsequent map (see above).
The automatic status refresh for the group financial statement introduced with release 2009.1 in some cases caused the update of status values from [green] to [red] for consolidation functions already processed. This especially applies to statements created with an earlier release. The advice for previous lock of the corresponding periods or group statements issued by IDL was not followed in time or could not be followed in many cases.
This problem might even happen for group statements created with release 2009.1 or newer, especially if the company financial statement data were newly created after their processing. An enhancement with respect to this problem for data transferred again from the preceding fact had been realised with update A of release 2009.1, however, this solution took effect only for completely unchanged data. In addition other ways for creating new company financial statement data (e.g. via import) were not considered.
In additions, the automatic status refresh caused a significant increment of the response time for large group companies (with several hundred companies), that were unacceptable in the long run.
Thus the automatic status refresh is no longer performed at start of the list application "Group companies + monitor" (KTKGES). Rather a new menu item "Check & refresh status information" was supplemented in the action menu of this application in the submenu "Processings". Thus the user now has to decide (again), whether and when a status refresh shall be invoked.
This modification had been already delivered with updates 2009.1 C and 2009.2 A.
The automat for consolidation functions (invoked by the action in the sub-menu "Processings ..." of "Group-companies + monitor (KTKGES)) now contains the call of the consolidation of debts and the p&l consolidation in the version "Delete & ...". The hitherto version without prior deletion maintained [red] status values, since processings already performed were not repeated.
The automat for consolidation functions now calls the new complete function (menu item 'ZWELUVALL') instead of the previous list (ZWERGUV) for the elimination of current asset results (ZU). Thus this step can be performed without manual entry, too.
A profit or loss value entered in the shareholding transaction for disposal now is considered at deconsolidation of companies consolidated at equity, too.
A new consolidation function is provided for the merger of a subsidiary into its shareholding company. This function can be called as one complete function or in two sub-functions (capital consolidation or other consolidations, respectively) out of the group-companies monitor (KTKGES). Corresponding actions were supplemented in the new sub-menu "Deconsolidation ...". Preconditions for these functions are:
The sub-function "Merger capital consolidation PS" creates the following consolidation vouchers:
The sub-function "Merger other consolidation PS" creates the following consolidation vouchers:
The complete function for merger combines both sub-functions. The sub-functions allow a distinct repetition if basic data have changed. The status 'PS' becomes [yellow] if only one of both sub-functions has been invoked and [green] if both sub-functions have been performed.
New consolidation postings must not be created for merged companies (like companies disposed from the group-companies).
A previous period has no longer to be specified at call of "Update minority interests" (FF), since all calculations refer to the last previous annual statement.
You can now invoke the elimination of current asset results (ZU) as a complete function, which processes all existing inventories IC-stocks (ICBEW) of a company. The new action "Elimination current assets results complete ZU" of the group-companies monitor (KTKGES) serves for this purpose.
Up to now you had to call the list "Elimin. current assets results list" (ZWERGUV), select the lines to be processed and then call the function "Elimination current assets results ZU". You can now call the complete function out of this list, too.
All existing 'ZU' vouchers are deleted at call of the complete function, the data are newly calculated and the corresponding vouchers are created.
The complete function is prerequisite for the elimination of current asset results with exchange rate effects (see below), too.
A new alternative processing for the elimination of current asset results (ZU) was developed allowing the calculation of exchange rate effects. This procedure is performed, if the (new) account for currency difference is specified in the consolidation parameter 'ZU'.
Data of the previous period are considered for calculation of exchange rate effects, too. However, the comparison of data of the actual and the previous period is not possible for single transactions. Therefore the complete function per company (see above) is prerequisite for this type of processing. The call of the function as a line related action in the list "Elimin. current assets results list" (ZWERGUV) is not permitted, if the account for currency difference is specified in the consolidation parameter 'ZU'.
As another required prerequisite you may not specify different elimination accounts for different inventories IC-stocks for the same product/product group and the same intercompany. Thus it is suggested to centrally define the elimination account in the product master data (PRO) or in the consolidation parameter 'ZU'.
For the purpose of calculation of exchange rate effects the current asset results are calculated like in the hitherto processing but in local currency. An absolute specification of the current asset result in group currency is reconverted into the local currency applying the closing date exchange rate (SK). The p&l profit in group currency results from the conversion of the current asset result applying the currency rate average per period (PDK). The same calculation is performed for the data of the previous period. The posting amount results from the difference of the p&l profits, which is posted from the IC-stocks account to the elimination account. The remaining difference of the current asset results of the actual and previous period represent the exchange rate effect and is posted from the IC-stocks account to the account for currency difference.
All in all the actual current asset profit reduced by the current asset profit of the previous period is eliminated from the IC-stocks account. 'ZU' vouchers created by the exchange rate procedure receive the posting type 'WU' (repetitive posting with transfer) providing the carry forward of elimination of current asset results from the previous period. Therefore the values from the previous period are only considered, if the exchange rate processing had been applied in the previous period, too. Otherwise the exchange rate effect is only calculated for the actual period and the total current asset result is eliminated.
Like other consolidation functions the elimination of fixed asset results now inserts the group/sub-group and the consolidation voucher number into the processed company financial statement data (IC fixed asset transactions). This entry will later be evaluated for the status display of the group-companies monitor (KTKGES).
A neutralisation account (incl. posting key and controlling object) was supplemented in all consolidation parameters except for 'EN' (equity update clearing of negative value EF), 'QU' (quotal clearing), and 'JU' (compensation of group result). The consolidation parameters 'KK' (First consolidation capital KK) and 'EK' (first consolidation equity EK) were enhanced by two neutralisation accounts. Only accounts with account flag 'N' (see above) may be entered there. If specified additional postings on the neutralisation account are automatically generated (see below) for the corresponding consolidation vouchers.
The posting keys of the consolidation parameter 'FK' for minority interests (required since release 2009.1) now are optional again. Without specification of a posting key the postings on minority interest accounts are supplied with posting keys like before release 2009.1, i.e. usually with respect to the posting keys of the origin data.
A new account for currency difference (incl. posting key and controlling object) was supplemented in the consolidation parameter 'ZU' for elimination of current asset results. At specification of this account the new procedure for elimination of current asset results with calculation of exchange rate effects (see above) is performed. The selection box for this account displays only capital accounts, which are typically specified here. However, you may enter other accounts, too.
An additional consolidation posting is generated for consolidation vouchers affecting net result on the net result account (account flag 'E') since release 2009.2. This functionality replaces the former consolidation function 'JU' (Compensation of group result). However, the 'JU' function allowed the specification of other accounts than the net result account providing a differentiation of company and group results in the group financial statement.
A new account flag 'G' (group result) was introduced to furthermore enable this kind of differentiation. The result of a consolidation voucher affecting net result is posted on the account with account flag 'G' if defined. If no account with account flag 'G' is defined the posting is applied to the account with account flag 'E'.
If a neutralisation account is specified in a consolidation parameter (see above) then additional postings on this account are generated in the related consolidation vouchers. These postings compensate displacements in the b/s or p&l result, respectively, between both companies referred in the voucher. This feature enables you to reproduce the company financial statement results in the company details of the net result position of a group report, if these accounts are supplemented in the report.
The consolidation parameters 'KK' and 'EK' contain two neutralisation accounts. The first account serves for postings for the subsidiary (first company in the voucher number) while the other account serves for postings for the shareholding company (second company in the voucher number).
Neutralisation accounts usually are valid for a group of vouchers with different consolidation functions. E.g. the neutralisation account of the consolidation parameter 'MB' is applied to vouchers with consolidation function 'MB' (manual vouchers), 'VM' (carry forward of manual vouchers), and 'PM' (merger repostings of manual vouchers).
The consolidation function 'JU' (compensation of group result, see below) as well as all transaction development repostings ('SU', 'AU', 'KU', 'FU', 'QU') are excluded from the generation of postings on neutralisation accounts, since a development reposting does not post a replacement of the b/s or p&l result, respectively.
You can manually enter consolidation postings on neutralisation accounts, too. E.g. this might be desired to distribute the neutralisation amount onto different accounts or different posting keys. Then only the difference of these postings and the complete neutralisation amount is calculated and automatically posted.
In addition, the list "Consolidation postings" (KONBUCH) provides a function "Generate postings for neutralisation". This function deletes all manual entered postings on neutralisation accounts for the posting records of the selected postings and creates new neutralisation postings due to the standard of the consolidation parameter. Amongst others this function can be used to create neutralisation postings for the first time, if neutralisation postings are to be created in a period with already existing data, e.g. for vouchers carried forward, too.
Consolidation postings on neutralisation accounts are not considered for the totals of debits, credit and the effect on the net result of vouchers and posting keys. A new flag in the list "Consolidation postings" (KONBUCH) allows the suppression of the display of postings, which not contribute to these totals.
Consolidation postings on neutralisation accounts are carried forward like consolidation postings on other accounts. Neutralisation postings out of vouchers with posting type 'WX' (e.g. for consolidation of debts) are carried forward with a carry forward posting key and eliminated with the posting key for current changes, if the neutralisation account is allocated to a transaction development with carry forward.
Neutralisation accounts replace the previous function of the accounts for charging balance sheet and profit & loss of the consolidation parameter 'JU' in the function "Reposting group results". Thus the consolidation parameter 'JU' is no longer carried forward and the function "Reposting group results" will be deactivated in one of the next IDL Konsis releases. For an easy transposition you can supply these two accounts of the consolidation parameter 'JU' with the account flag 'N'. Then these accounts are automatically inserted as neutralisation accounts into the other consolidation parameters carried forward at the next period carry forward.
Consolidation postings with posting keys, which are allocated to transaction development areas (see above), are not considered for the calculation of the totals of debits, credits and the effect on net result per posting record like some other postings (see list below)
The list "Account balances and consolidation postings" (KONSAL) does not display consolidation postings with posting keys allocated to development areas without account agreement, since there are no corresponding account balances.
The display of consolidation postings in the list KONBUCH can be reduced to the effective postings. For this purpose an entry field was supplemented in the first line on the right hand side of the selection area. Consolidation postings of the following kinds are no longer displayed, if you enter an 'X' in this field:
Only with this selection the total of the displayed debit and credit values equals the displayed debit or credit total of the voucher.
A release migration of IDL Forecast data is required for release 2010.0 only, if you have not installed release 2009.2 before. Then you have to catch up the release migration for 2009.2 per scenario. A new action menu item of the application "Planner spreadsheet" (PLAN) serves for this.
The opening of a scenario not migrated is prevented with a corresponding error message.
Several settings (sort order of rule templates, display mode of account display, columns faded into the scenario list etc.) now are stored and maintained for the next application start.
The function "Refresh reports" now not only adds new account, but rather refreshes the report with respect for deleted, moved, or renamed accounts and positions.
You can now control at loading of account balances to IDL Forecast that missing account balances are to be treated like account balances with zero values. This may be required for the decumulated display of p&l balances, where up to now an empty value was displayed instead of a negative value, which balances in total with the previous period values to zero. For activation of this control you have to insert the line "useEmptyNullDifferentiation=false" in the domain [FORECAST] of the ini file.
The icon associated with the rule type is now displayed in the title bar of the rule definition assistant.
All accounts below one position now can be simultaneously allocated to a rule by selecting the respective position itself and pressing the allocation button.
The selection of an account in the selection tree on the right hand side can be provided by clicking on an account already allocated in the left hand side area.
The buttons <Ready> or <OK>, respectively, now are preselected in the rule assistants providing a quick commitment of performed entries by pressing the <Enter> key.
All rule assistants yielded an additional last page for a period control. Previous settings of the period control on the allocation page are dispensed with this. By default a rule has no period restrictions. The radio buttons "All forecast periods", "All plan periods", and "Selected period(s)" are activated if the check box "Period restriction" is selected. If "Selected period(s)" is selected, then a double list for selection of period is activated. This period control is preserved at storage of the rule as a rule template and appliance to another scenario. If additional period controls are activated at application of a rule template, then both controls are combined with AND. E.g. if the template specifies selected periods and the template is applied with "All forecast periods", then the rule is applied to all selected periods located in the forecast range.
The function for opening defined rules in the rule assistant again was moved to the business case viewer and reconstructs the complete business case (e.g. incl. payments) in the rule wizard.
Incorrect relationship rules are now designated more clearly in the assistant for general posting rules. In addition, an error message exhibits the reason of the error.
A check was supplemented at definition of a purchases rule, that the accounts for material expenses, liabilities, and security repostings either are all intercompany accounts or none of them is. This check is now applied to the cash discounts account of the sales rule, too.
Rules with a base value (e.g. purchases rule, personnel rule) now consider a change of the debit/credit flag of the base value. The general posting rule assistant now allows a control for each rule, whether the debit/credit flag shall be ignored (behaviour up to now), considered or inverted for the calculation.
The sales rule and the purchases rule now support payments in scenarios with only annual or quarter periods. Up to now this was only supported for scenarios with monthly periods.
Automatic changes now are always inherited by newly defined rules even if the debit/credit flag is not the expected one.
A new rule type "Transition rule" was supplemented providing the entry of the closing balance of an account as change in one or more other accounts. The assistant consists of only one page. You can define one or more account allocations with the button "Add account mapping". Each allocation consists of a source account (left hand side) and a destination account (right hand side). The balance of the source account is written as a change of the destination account at application of this rule. The rule can be enhanced by the addition of further destination accounts. Then you have to specify percentages for the distribution of the source amount into the destination amounts.
Another new rule type "Financing rule" was supplemented, which liquidates the opening or closing balance of an account in several subsequent periods by repostings to another account. You have to select the menu item "Dissolve opening/closing balance" of the object menu of an account line for definition of this rule. The menu item opens the rule assistant. At first the number and description of the account selected before are displayed. You cannot modify this account here. Below this account two check boxes are displayed providing the specification, whether the opening or the closing balance of the account is to be liquidated. Farther below you can select the destination account. In the bottom part of the window you find a list of dissolution components. Each dissolution component represents the reposting from the source to the destination account in a distinct period. It contains the period distance, the partition to be dissolved in this period as well as the destination account.
You now can define a financing as a rule independent from an investment rule.
You can now copy rule templates and template sets.
The rule template window allows the simultaneous selection and appliance of arbitrary templates, even out of other template sets, using the mouse key with the <Ctrl> key.
You can now define new template sets in the dialogue "Save template", too.
Incomplete rule templates and template sets are coloured in the template tree for improved detectability.
A button in the administration window for rule templates allows the display of the chart of accounts of the accounts used in the respective rule template. This option is maintained at restart of IDL Forecast.
Two attributes for default column options of company or group reports, respectively, were supplemented in the table of report idents (RID). These columns options are automatically entered and used at display of a related report result if the respective report header (REP) does not specify a default column option.
Thereof-positions with line type 'P' (detail line with printing) and value flag '6' (Values from subsidiary position) now exhibit the total of all subordinate positions, even if these are no thereof-positions. Thus the subordinate thereof-positions can be applied for different reports. However, none-thereof-positions with the flags 'P' and '6' exhibit only the total of the subordinate none-thereof-positions like up to now.
You can now display a sequence of values contained in a report result as midget graphics. This may be a midget bar chart (also called sparklines) or a midget line chart. For this purpose you have to perform the following steps:
The graphic types 'S' and 'L' provide a visualisation of the column values themselves. The graphic types 'SD' and 'LD' provide a decumulated display of the values without specification of formulae lines for the difference calculation, i.e. the value of the preceding column is subtracted from the value of each column.
The columns designated with a graphic type serve only for display in a midget graphic. If you want to display the according values in the report result display, too, you have to repeat the specification of these columns in the column option without entry of a graphic type.
Development transactions with posting keys for transaction development areas without account agreement (see above) can be used in transaction development reports without any restriction. However, the total column (net book value, specified by position '#REP#'/'SUM' in the formulae editor FED) does not contain these values.
Postings and consolidation postings with posting keys for development areas without account agreement (s.o.) are not considered in b/s and p&l reports, since these postings must not have any effect on the balances. This applies for the cash flow report, too, as far as the respective posting keys are not specified explicitly for a report line (REPZEI).
The branch "Import masterfiles" in the table of the application "Data import and display" (IMPORT) was subdivided for a more clear arrangement. The sub-menus "Basic masterfiles", "Definition developments", "Accounts & positions", "Company & group data", "Check rules", "Report definitions", and "Import/export format definitions" were inserted on the basis of the menu structure of the resource tree and quick start menu.
A previous period entered in the map of the calling application IMPORT now is transferred to all unload functions as parameter 09. You can reference this parameter in the external call entered for the respective menu item "UML..." with the instruction '%09'. Thus e.g. unloading of data for an interval of periods can be controlled.
It was introduced with release 2009.2 (as well as with update A of release 2009.1), that the period type specific entry flags of accounts are always set at import if not specified in the import data. The deletion character '*' had to be specified for the intention to leave an entry flag empty. However, this solution was not appropriate for data exported from IDL Konsis, since the entry flags were always set this way. Thus a new rule was defined for import: The entry flags are set, if all accounts contained in the import file are without specification of the entry flags.
New columns for posting keys were introduced in the standard import formats for development transactions with the extension of the length of posting keys in Release 2009.0. However, the old columns with limited length still are alternatively supported for compatibility with existing interfaces. But if the import was performed with transformation of the posting keys, then this was only possible at usage of the new columns. Now the transformation of posting keys is supported at usage of the old columns, too.
The import of inventories IC-stock is now supported for several periods. For this purpose a previous period has to be specified in the calling application IMPORT.
The import of consolidation postings with reserved posting keys is now admitted with extra authorisation. Then a warning message is output instead of an error message.
The sub-group data exchange was adjusted to several table enhancements. Thus compatibility to deviant releases within the group of companies is not guaranteed.
The group-wide data exchange was adjusted to several table enhancements. Thus compatibility to deviant releases within the group of companies is not guaranteed.
The response time of the read function could be reduced for large amounts of data. A cancel facility was supplemented for long run refresh processes.
The control of the refresh type was refined when working with internet client and server, especially in the offline mode (working without idle time or if the database is not available).
You now can evaluate the additional controlling dimensions in all read functions for data with controlling allocation.
The representation of debit and credit amounts as values with positive or negative sign was revised due to Connector Manual, chapter 5.2.
The facility for entry of an allocated OLAP position was supplemented in the write function for positions.
The firm allocation of a company to a controlling object is now checked in the Excel entry form. Faulty insertions are inhibited.
Missing authorisation checks were complemented.
The call of the SAP interface is supported for user specific menu items, that are distinguished from the original menu item only by a preceding '$' (e.g. '$UNLSALD' instead of 'UNLSALD'). From now on other user specific menu items are allowed for this purpose providing the ability to define more than two call alternatives. The transformation of the original menu id into the user specific menu item has to be specified in a transformation group. Then the call of the SAP interface with alternative parameters is invoked at entry of this transformation group in the calling application IMPORT.
The parameter "sDatasource" transferred up to now only in connection with import via 'I' tables and then in connection with ODBC authorisation data now is transferred in other cases for its own in the import definition variable "sDatasource" to the call of IDL Importer, too. Thus you can determine from the scripts of the IMD file, out of which IDL Konsis database a job was called.
It is now supported to call the MIS preparation (Create MIS data tables) via command line. E.g. this can be used to automatically invoke this function periodically (e.g. each night).
The file "batchrunner.jar" was created for this purpose. This file can be called via command line. The required parameters have to be specified in the call. Example for the call:
The parameter /start specifies the menu id of the called function. The parameters /dbname, /username, and /pass are required for login into the database. The parameter /MPK designates the MIS parameter key. A complete list of the supported parameters is output at command line call with the option "/?" or "/help" as parameter.
With this release the following English-speaking documentations in the "doku" directory are updated or completed: