This release IDL KONSIS 2007.1 is an interim maintenance and therefore it may be left out in the release sequence. Prerequisite for this release is the last main maintenance 2007.0 from Sept. 17th 2007.
The supplements and corrections of the main maintenance 2007.0 up to the release date are included in this interim maintenance.
This documentation describes the enhancements since the previous main maintenance IDL KONSIS 2007.0.
The development planning of IDL provides that group transactions (fixed assets, capital and provisions) are no longer supported with the next main maintenance 2008.0. These data are redundant to the consolidation postings and don't contain additional information. Therefore the users are challenged
As announced for two years the IDLCONNECTOR does no longer support the version MS Excel 97 with the current release, particularly since the hotline service was also ceased meanwhile for MS Excel 97 by Microsoft. Please upgrade to a newer Excel version.
The care of customer specific user groups can be provided more simply by a new procedure. Up to now it was necessary to enter and update authorisations for all relevant menu items. Especially at release updates new menu items had to be analysed and authorised in addition.
The new procedure is based on the allocation of the idividual user group to a standard IDL user group (IDLKON, IDLWIN e.g.) as reference. This allocation has to be entered at entry of a user group in the application "User groups" (BEN). Only standard IDL user groups (starting with "IDL") may be allocated.
With entry of such an allocated reference user group only deviations of the authorisations to the reference user group have to be entered for the customer specific user group. These may be additional authorisations als well as additional restrictions. Additional authorisation are defined in the menu authorisations (BENMEN) as usual by entry of authorisation level '1'. For the definition of additional restrictions the authorisation level '0' can be entered in the menu authorisations.
Menu authorisations entered in this way modify the authorisations of the standard IDL user group. This two step logic is evaluated at different places of IDL.KONSIS.FORECAST, e.g. when building the ressource tree, at check of short name entries and at activation of actions for subsequent applications in the action menus of the applications.
IDL.KONSIS.FORECAST 2007.1 contains a new function that provides a possibility to treat a consolidated subgroup like a virtual company.
The new calling application "Consolidation subgroup for creating indiv. financial statements", that can be called via menu tree (IDL.KONSIS.FORECAST -> System administration -> Extra functions) or via short name entry (KTK2GES), serves for calling the new function. The map of this application contains entry fields for period, fact, group/subgroup (source) and company (destination). In addition a flag controls, whether the protocols of previous processings shall be deleted.
The table shows the processed data stocks, which can be displayed via double mouse click or action "Execute marked application", respectively. All existing data stocks are processed, i.e. even those that aren't checked due to the flag positions of fact (FAC) and period (ABR).
The processing in effect is triggered by the action "Consolidation subgroup for creating indiv. financial statements". This function aggregates the financial statements of the companies belonging to the subgroup and the consolidation postings (in case including postings for subordinate subgroups) to financial statement date of the destination company. The following features should be attended:
The single processing steps are logged in a protocol, that is stored in the database and can be displayed via action "Display log-file". The log-files are collected (appended) up to a processing with flag "Delete log" set to 'J'.
The following enhancements to the check rule functionality introduced with release 2007.0 have been supplemented with this release:
These supplements are described in detail in chapter Individual check rules.
All warning messages output by IDL.KONSIS.FORECAST now contain the additional check box "Don't show this message again". You can mark this check box, if you don't want to see and commit this message each time. This suppression does not affect other messages and is restricted for one mass operation started (marking of several lines in a list application and start of an action). At next selection of this action the message will appear again.
Message windows, that may contain a lot of messages, now in some cases have a separate message line, that provides an aggregated message (e.g. "There are errors"). Thus this message is visible independently from the positioning in the message window and can be distinguished from other detailed messages easily.
Like warning message boxes these message windows contain the additional check box "Don't show this message again". If the user marks this check box, then message windows with the same aggregated message are not displayed at once. Rather the corresponding application responds due to the button (e.g. <OK> or <Continue>) chosen at the first appearance of the message window. The messages of the suppressed message windows are collected in one large message window and displayed at the end of mass processing.
Up to now this enhancement was realised only for some applications, especially the programms for report generation. Further applications will follow with the next release.
Up to now IDL.KONSIS.FORECAST distinguished between global actions (designated by a globe in action or object menus) and line actions (without icon in front of the action). Global actions act independent from selected lines and are processed only one time even if several lines have been selected. Line actions use parameters from the lines and are processed for each selected line. However, for some actions a combination of these types is useful. Thus a new action type was introduced, that is designated by a half globe. These actions work as follows:
You find first examples of this action typ in the application "Group companies + monitor" (KTKGES). The actions for calling the subsequent lists "Consolidation vouchers" (KONBEL) and "Consolidation postings" (KONBUCH) are designated with a half globe there. Dependent from the selection of lines the subsequent lists display data for the whole group companies or restricted to one company. Further examples are found in the action menus of the form entry applications.
Global actions now can be processed even if a line was selected, that otherwise doesn't support actions (e.g. empty or total lines.
Up to release IDL.KONSIS.FORECAST 2007.0 (including update D) at selection of lines for subsequent applications not only lines were counted, that support line commands, but rather each arbitrary line (e.g. empty or total lines) providing, that the number of lines to be processed was not in evidence. Now like before only processable lines are counted.
The find function (Menu -> Edit -> Find..., Cntl-F or binocular symbol) was changed in the way, that only those lines are found, that contain the searched character string within one cell (e.g. designation). Up to now also lines were found, that contained the search string distributed through several subsequent cells.
If no description is found for an object in the specified user interface language (French e.g.), then alternatively the text is read in the default language. Up to now this default language was German. From now on this default language is English.
The report result list in tree structure doesn't display total values in node lines, if the structure below contains a separate total line. However, the suppressed total value was copied into the clipboard (for subsequent pasting into MS Excel, e.g.), so that it appeared twice. Now the copying is performed like displayed in IDL.KONSIS.FORECAST.
The migration program for this release performs the following conversions:
The special character '_' (underscore) now is accepted in the e-mail address of a user.
Individual user groups (not beginning with "IDL") now can refer to a standard IDL.KONSIS.FORECAST user group (beginning with "IDL") as an allocated reference user group. Then only authorisations deviating from this reference user group have to be declared (see above).
The following menu items are new with this release. If 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.
As an alternative solution to the complete definition of authorisations for all menu items the new 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 (BENMEN), too. It declares, that a menu authorisation issued for the reference user group is not issued for the given individual user group.
The account flag 'J' is no longer handed down from the group account to the allocated company accounts, if the company accounts have the account flag 'I' or no account flag at all.
The choice dialogue for the "Account if D/C changed" now displays all accounts independent from their account flag 2, since accounts with deviating account flag 2 may be allocated as "Account if D/C changed" (only a warning message is displayed in this case).
The chart of controlling objects is now an enterable field for fixed asset objects, for the group chart of controlling objects is no longer necessaryly equal to the group chart of accounts due to changes in release 2007.0. This concerns the applications "Fixed asset object" (ANLOBJE), "Intercompany fixed asset object" (ICANLOBJE) as well as the import of fixed asset objects.
The table for company master data (GES) was enhanced by an attribute for an exclusion group for check rules (see below).
The flags for controlling details in the period (ABRE) and fact (FACE) master data now accept the new value 'I' (obligatory entry for intercompany account balances, too). A stringent check for the entry of controlling objects in the intercompany account balances (dialogue and import) is now performed only if both flags are set to 'I'.
The table for Period master data (ABR) was enhanced by an attribute for an exclusion group for check rules (see below).
The designations of the table "products" (PRO) were converted in a way, that characters of national character sets (Unicode) may be entered there. This is an addendum to the enhancements of release 2007.0.
The applications for care of the startup data (VORE, VORADMINE) enable the entry of the user's application language, that is stored in the table "User" (USE). Therefore at update of the startup data the user table always was updated, too. As a consequence at activation of logging of master data changes the logging table for changes of users (USELOG) displayed lots of changes without changed data. Now this table is only updated at change of the user's application language.
If you select one account in a list of details for account balances, then in case of a difference between total of detail data and account balance this difference is displayed in an empty line with red background. This line now is designated with "difference".
The subsequent calls for form entry applications in the action menus (up to now as global action and in addition as line action) were combined to one action with the icon of a half globe (see above). They act as global or line action depending on the selection of lines.
The stringent check for complete entry of controlling objects in the intercompany account balances introduced with Release 2007.0 didn't prove to be practicable in all cases. Therefore the flags for controlling details in the period (ABRE) and fact (FACE) master data now accept the new value 'I' (obligatory entry for intercompany account balances, too). A stringent check for the entry of controlling objects in the intercompany account balances (dialogue and import) is now performed only if both flags are set to 'I'.
It is no longer admitted to enter a development transaction, if the account or the fixed asset object, respectively, are invalid in the actual period.
A new action for branching into the list "Posting keys" (BSL) was supplemented in the list applications for development transactions (ANLBEW, KAPBEW, RUEBEW, SPIBEW).
If a transaction development account is a shareholding account (account flag = 'B') simultaneously, then the entry of an intercompany is allowed. Up to now this was only admitted for intercompany accounts (account flag = 'I' or 'J').
Shareholding transactions "on group level"(i.e. with entry of a group/subgroup and a posting key with posting key flag 1 = 'K') are no longer supported. Existing group shareholding transactions as well as the according group posting keys are deleted by the release migration program automatically. These transactions had no purpose, since a shareholding development report based on shareholding transactions is not supported. (The consolidation postings on shareholding accounts receive a posting key for the fixed asset transaction development.)
The entry field "group/subgroup" in the list "Shareholdings/participations" (GESGES) now serves for the selection of group companies like the balance (KTOSAL, ICKTOSAL, CNTSAL) and posting (BEL, BUCH) lists, if read authorisation is provided.
The warning messages with respect to dissonant percent values (capital, result and voting) were merged to one message window. Thus in case only one warning has to be committed.
The entry of a new voucher header (action <Edit data> without selected lines in the list "Vouchers" (BEL)) now is possible, even if the company and/or the business unit is not provided uniquely. Then these keys have to be entered in the single record application (BELE).
The calculated depreciation now is compared with a depreciation already posted. The existing depreciation postings are deleted and new postings inserted (like always up to now) only if they are deviating. Otherwise the existing postings remain. Thus the original modification timestamp is unchanged. Manual supplements like entry of controlling objects for additional controlling dimensions are maintained, too.
Entered data are checked for consistency after saving them. The result of this check now is shown in a message window.
Some actions in the action menus of the form entry applications are designated with a half globe (see above). The subsequent applications refer to the objects of a line or the total of the displayed data depending on the selection of lines.
The form entry application for account balances provides data views, that other applications do not provide, e.g. simultaneous display of balances and postings or different periods in parallel. For the purpose of using these functions independently from update authorisations the form entry application can be invoked even if only display authorisation is granted. The authorisation for writing of data (e.g. with respect to the release of the period via BENABR) is only checked when saving entered data.
The actions for calling subsequent form entry applications (intercompany account balances, development transactions) were subsumed to one submenu "Forms details".
The form entry applications of development transactions (fixed assets, capital, provision and individual development transactions) yield a new action for branching into the list "Posting keys" (BSL) in the action menu. E.g., the entries for the columns of the entry form can be modified there.
The special characters '_' (underscore) and '%' (percent), that are used as wild cards for one or an arbitrary number of other characters in IDL.KONSIS.FORECAST, now are accepted in external keys for transformation objects. In this context these characters are no longer interpreted as wild chards but rather as unique keys.
In addition multiple allocations of transformation objects are now supported in both directions. Up to now several external keys could be allocated to one internal key. From now on several internal keys can be allocated to on external key, too. However, a warning message is issued if ambiguous allocations exist in "Transformation group allocation" (UMSOBJE). Please mind, that a transformation group can be used
The import/export formats for vouchers and postings as well as consolidations vouchers and postings were supplemented by the flags for minority interests (only consolidation) and deferred taxes. This is especially helpful at import of data, that have been exported from another IDL.KONSIS.FORECAST database.
This feature provides a control for defined check rules, which are not to be applied always. Their appliance can be restricted to certain companies (e.g. only sales companies) or to certain periods (e.g. only annual statements).
For the purpose of using this feature those check rules, which are not to be applied always, have to be pooled in an exclusion group. The new applications "Exclusion group(s) for check rules" (PRFGRP, PRFGRPE) serve for the definition of an exclusion group itself. The new applications "Exclusion group(s) / check rule(s)" serve for the allocation of check rules to the exclusion groups.
These exclusion groups can be allocated to companies or periods providing the exclusion of the allocated check rules. The master data tables for companies and periods were enhanced by an attribute for an exclusion group for this purpose, which can be entered in the corresponding single record applications (GESE, ABRE). Since only one exclusion group can be allocated it might be necessary to define several similar exclusion groups, if companies use different check rules.
These supplements were considered in other applications, too, like data exchange (the tables "exclusion groups" and "exclusion groups / check rules" were supplemented in the group wide data exchange) and import (TXTGES) as well as the logging of master data changes (GESLOG).
Check rules can be applied to amounts in local, group and parallel currency. However, it might happen that amounts agree in local currency, but differ in group or parallel currency due to rounding effects of currency conversion. The feature of entering tolerances for check rules was implemented to avoid, that check rules result in an error status in this case.
You enter these tolerances in the check rule header (application PRFE). A tolerance can be entered per currency (e.g. 0,00 for local currency, but 1,00 for group and parallel currency).
These tolerances are eveluated at calculation of the check rule results, if the check rule demands equality of both sides. Then the check rule result becomes [green] even if both sides have a difference less or equal the given tolerance.
Now check rules can be applied to group statements, too. The same check rules as for the company statements are used. However, a new attribute in the check rules (PRF) controls, whether a check rule shall be applied to company statements only, to group statements only, or both.
The call of the subsequent application "Calculation of check rule result" was supplemented in the application "Group companies + monitor" (KTKGES). When called from here consolidation postings are considered besides account balances or other company finanacial statement data. The company financial statements of quoted companies are included pro-rata but, in addition, balances on accounts with account flag 'Q', too. This call is a global action. I.e. the check rules always check the complete group financial statements.
The result of the group check rules is stored in a new record (check point) of the group processing controls (KVERARB). The status of this check point (i.e. type of the assigned message) is displayed in a new column of the "Group companies + monitor" (KTKGES).
The new application "Check rule results for group" (PRFERGK) displays the results of the single check rules like the check rules for company financial statements. You branch into this new application via action menu from KTKGES (submenu "lists"), via ressource tree (submenu "Group consolidation") or short name entry ("PRFERGK").
If a single use voucher (posting type 'E' or 'WV') contains postings relevant for carry forward (postings on transaction development accounts or postings affecting net result), then a warning message (KON1967W or KON1968W) is assigned to the voucher header. Then the user should check, whether the voucher is to be carried forward completely (posting type 'WU'). The company financial statements monitor (EA) displays the status [yellow] in this case.
Postings now are carried forward (independently from the origin conversion rule) with conversion rule 'VKW' or 'VPW' (predefined amount group/parallel currency), respectively, again. The currency conversion (see below) then provides a differentiated treatment of the conversion rule depending on the conversion rule for the account.
At check of the period carry-forward now only those data stocks are validated, that should exist due to the flags in period (previous and actual period) and fact master data.
If an accounting type is allocated to the destination fact and the carry forward would lead to a violence of this accounting type (data on accounts with a deviating accounting type), then this conflict is displayed in a message window and the user can decide, whether data shall be carried forward nevertheless (button <Continue>) or whether only those data shall be carried forward, that are compatible with the accounting type of the fact (button <OK>).
If there are no data at all for the comparison fact, then the status for "check carry-forward new fact" becomes [-] instead of [green] up to now.
A conflict with respect to postings affecting net result existed between period carry forward (e.g. from 12. 2007 to 12.2008) and fact carry forward (e.g. from I3 to I4), if capital transactions were maintained on both facts:
This problem is enlarged, if individual accounts for retained earnings are allocated to the p&l accounts in the account master data.
This problem was solved in the following way:
If a single use voucher (posting type 'E', 'ET' or 'WV', consolidation function 'MB', 'M0', 'M1' ..., 'M9') contains postings relevant for carry forward (postings on transaction development accounts oder postings affecting net result), then a warning message (KON1967W or KON1968W) is assigned to the voucher header. Then the user should check, whether the voucher is to be carried forward completely (posting type 'WU'). The group company monitor (KTKGES) displays the status 'MB' for manual postings [yellow] in this case.
Minority interest (consolidation function 'KA') consolidation postings affecting net income are carried forward to the new account for retained earnings of the consolidation parameter 'KA', if it is given. Otherwise like before the account for retained earnings of the consolidation parameter 'KK' is used.
Like fixed asset transactions with posting keys '60' and '61' now transactions for other developments with posting keys for manual entry of values carried forward are converted with the exchange rate of the previous period. Posting keys for manual carry forward are recognized by using the same development column as the posting key for automatic carry forward (usage flag 'V').
Postings carried forward with conversion rule 'VKW' or 'VPW' (predefined amount group/parallel currency) are converted depending on the conversion rule of the account:
A flag "Selection option" was supplemented in the list "Account currency conversion audit trail" (KTOUMR). This flag accepts the following values:
With 'S' the list is displayed like before. This is the default value when calling the application from the menu tree or via short name entry.
With 'D' all lines are suppressed, that have no value unequal to zero in any difference column. This option is set when calling this list from currency conversion header (WUM/WUME) for the purpose of displaying a compact list of differences explaining a difference displayed in the conversion header.
The actions for calling the subsequent lists "Consolidation vouchers" (KONBEL) and "Consolidation postings" (KONBUCH) were designated with a half globe in the action menu (sub menu "Lists ...") (see above). Depending on the selection of lines the data for single companies or for the complete group companies are displayed in the subsequent lists.
In addition the call of the application "Transactions and consolidation postings" (KONBEW) was supplemented in the submenu "Lists...". On the other hand the call of the list "Fixed asset transactions" (ANLBEW) was removed, since its function is replaced by KONBEW (see above).
The call of the new application "Repostings after elimination of intercompany accounts I&E" (see below) was supplemented in the action menu in the branch "Consolidation of I&E...".
An own account for retained earnings was supplemented in the consolidation parameter 'KA' (minority interests). Furthermore new accounts provide a differentiation between minority interests on the capital and on the result on the one hand, between direct and indirect minority interests on the other hand.
The consolidation parameters 'EF' and 'EN' for update equity now are checked for multiple occurrence of the same account even across the parameters.
The status 'KA' (minority interests) is set to [red] for companies consolidated at equity (consolidation type 'E'), if there are indirect minority interests at this company. Then a minority interest calculation and posting (see below) has to be performed.
A new list "Shareholding/participations and progression of capital" provides a facility to display the shareholding development in conjunction with the corresponding equity capital consolidation postings and the difference amounts for one subsidiary. This application can be invoked from the menu tree (branch "Group consolidation"), per short name entry (KONGESGES) or as subsequent application from the group companies monitor (KTKGES).
The selection area of this list contains entry fields for group/subgroup, a flag for "including subordinate subgroups" (like in KONBUCH), (sub)company (optional), period, fact, and language (optional).
The table area has at tree structure with the following levels:
Except for the shareholding value in local currency the table displays only values in group currency.
The voucher and posting texts of the capital consolidation development repostings were redesigned. Besides others the posting texts now contain the acquisition date.
If a company is placed on a subordinate level of a multi-level group structure and its shareholding values do not change on the superordinate levels, then it is abandoned to eliminate the minority interest postings (consolidation function 'KA') from the subordinate subgroup and to post them again on the current group level. New consolidation postings are only generated for consolidation postings affecting net income and marked for minority interests. Without new postings the 'KA' status is set to [T] (postings of the subordinate group are used).
It is now possible to differentiate minority interests by result and equity capital on the one hand, by direct and indirect minority interests on the other hand. In addition to the account "Minority interests" three optional accounts were supplemented in the consolidation parameter 'KA' for this purpose. If the additional accounts are not specified, then minority interests are posted on the one account like up to now. The postings for minority interests on consolidation postings affecting net income are posted onto the account for minority interests on the result if specified.
Furthermore an account for retained earnings was supplemented in the consolidation parameter 'KA', which is used for carry forward of consolidation postings affecting net income if specified. If not specified, then like up to now the account for retained earnings of the consolidation parameter 'KK' is used.
Changes of direct minority interests are no longer posted in posting record '03' but rather in posting record '02' of the 'KA' voucher. Thus the postings are located in the same posting record as the original minority interest postings and balance to zero, if the minority interests are reduced to 0,00%.
When minority interests change in the current period, those postings on the retained earnings account (contained in the 'KV' voucher) which refer to the companies' net income or to consolidation postings affecting net income are completely adjusted. Up to now only the minority interest on the companies' net income was adjusted. The basis for these adjustments now is the forwarded postings instead of the current account balances or capital transactions as this was difficult to check.
When the shares in a company change, the current exchange rate effects are now calculated with the minority interests as of begin of the period instead of with the current percentage.
It is now possible to calculate and post indirect minority interests on the difference amount of companies consolidated at equity (consolidation type 'E'), too. The processing is like calculation and posting of indirect minority interests on fully consolidated companies. Accordingly now companies consolidated at equity yield the 'KA' status [red], too, by the "calculation of status and participation".
The deconsolidation now is supported for quoted companies, too. The following cases are distinguished:
The function for deconsolidation redesigned with release 2006.1 now is completed by enhancements of the D&C consolidation. Intercompany balances of the disposing company are no longer considered. However, intercompany balances of other companies with the disposing company as intercompany are processed for the purpose, that the account balances on intercompany accounts result in zero from the group point of view.
Provided that a reference account for D&C consolidation in the intercompany accounts' master data exists, even these intercompany account balances are eliminated by the D&C consolidation. The counterentry is posted on this reference account for D&C consolidation. If it is an account for a transaction development, then the posting key with usage flag 'F' (disposal from group companies) is used. The "repostings after elimination of intercompany accounts" (SU) are enhanced accordingly.
At "D&C consolidation" (SK) a separate posting record is used for each existing combination business unit / IC business unit in the 'SK' voucher. These posting records are correctly classified as segment internal or segment external for the purpose of segment reporting.
At "Repostings after elimination of intercompany accounts" (SU) only one posting record per transaction development is used. This posting record on the one hand contains postings for elimination of the D&C consolidation, on the other hand postings for elimination of development transactions of the company financial statements with entry of an intercompany. There is no sorting for business units so that a classification for segment reporting is not possible. Thus in general all postings are classified as segment external, although postings for segment internal cases are contained, too.
Therefore now 'SU' vouchers are excluded from the automatic determination of the segment flag. Rather the segment flag is set directly by the 'SU' consolidation function due to the following rules:
This processing does not work, if manual postings are supplemented in the 'SU' voucher! Therefore it is recommended in this case to insert these postings in a separate manual voucher.
There is a new consolidation function 'AU' for reposting of consolidation of I&E (AE). This function works in the same way as the function 'SU' for reposting for consolidation of D&C (SK) and creates one voucher with consolidation function 'AU' per company. This way transaction developments on P&L accounts are supported. Correspondingly in this case 'AE' consolidation postings might contain posting keys in this case, too.
The message KON0036 ("No data existing") is no longer displayed for report headers with entry of a reference version. In fact these reports do not contain any data, however, at report result display the data of the referenced report version are displayed.
The new report option 'I' provides the new facility of creating an "intercompany report", which processes intercompany account balances instead of account balances as input data. The intercompany is written into the report result as detail level 1 allowing a report result display with intercompanies in columns. For this representation the new column options '#ALTGE', '#BUCGE' and '#NEUGE' were created.
If present the intercompany report for company financial statements processes postings on intercompany accounts with entry of an intercompany, too.
An intercompany report can be generated as group report, too. Then in addition all consolidation postings on intercompany accounts (account flag 'I' or 'J') are processed. In this case the intercompany is determined from the (first) company of the voucher number, that is different from the company of the consolidation posting.
Up to now one report result value per reference consolidation function was written for consolidation reports (report type = 'V'). I.e. e.g. there was only one report result value for reference consolidation function 'MB'. To have the facility to display the manual posting types in separate columns, now 11 additional report result values are written for the separate consolidation functions 'MB', 'M0', 'M1', ... 'M9'.
The new standard column option '#KVAMB' can be used for displaying a consolidation report with separate columns for the manual posting categories. However, this column option only provides general descriptions. To achieve individual descriptions an analogue individual column option has to be created.
Up to now the transaction development reports checked the consistency of the Balance sheet/Profit & Loss code of the position to assure, that a fixed asset report only contains asset postions, while equity capital and provision reports should contain liability positions only. This check has been dropped, since deviating Balance sheet/Profit & Loss codes are admitted at other appropriations, too.
The consolidation functions "Difference amount subsequent consolidation (KB)" and "Cash flow repostings (FU)" were revised in a way, that error messages either do not occur at all (e.g. when calling 'KB' for the parent company) or are no longer output in the message line but rather in a message window. Thus the workflow control is not aborted, but only interrupted and can be continued after committing the message.
The application "Copy group postings for sub-group report" (Menu ID KOPKONBUCH) was revised in a way, that it can be started within a workflow control. However, the parameters for special accounts cannot be used, since they cannot be entered as parameter values in the menu structure (MENMENE).
The application "Calculation of check rule result" (Menu ID REPERGCALC) was revised in a way, that it can be started within a workflow control, too.
The facility to declare a deviating comparison fact was supplemented for the application "Group companies + monitor" (KTKGES).
A new facility provides the call of an application in the workflow control for a sequence of periods without the need for declaring these periods explicitly. For this purpose you have to enter the special value '#INT' for the parameter "actual period" in the menu structure (MENMENE) at the definition of the workflow control. This entry provides additional entry fields "from period" and "Period-Range" in the selection area of the work flow control application. Thus e.g. entering
causes the concerned application to be called for the periods "03.2008", "06.2008", "09.2008" and "12.2008". The table of the workflow application displays this application several times with corresponding periods. The order is ascending with time.
A previous period has to be entered besides the actual period in many cases (e.g. period carry forward). For this purpose you can enter the special value '#INT' for the parameter for the previous period in the menu structure (MENMENE), too. This entry provides an additional one digit entry field "previous period" in the selection area of the workflow application. You have to enter one of the values 'J', 'Q' or 'M'. This provides the determination of the previous period as the last previous period with this period type. E.g. the entry 'J' causes the period carry forward to proceed always based on the last annual statement.
The action menu of the workflow application was supplemented by a possibility to branch into the menu structure (MENMEN). The menu ID of the current workflow application is transferred as parameter. This is especially helpful for development of a workflow application.
The subgroup data exchange was adapted to several database enhancements.
The group-wide data exchange was adapted to several database enhancements. The new tables
were supplemented in the group-wide data exchange.
The extensions at the IDLCONNECTOR are documented separately.
The application server now emits requests (ping) to the client in certain time intervals. If the client does not respond within a time limit, then the database connection is closed automatically. Up to now the database connection remained at abort of the client.
IDL.KONSIS.FORECAST is able to run on version 11g of the database system Oracle.
However, the version 8i (client as well as server) of the database system Oracle is no longer supported since IDL.KONSIS.FORECAST release 2007.0.
Unloading of data from a SAP system using the IDL Importer now can be performed using the mode "remote start" (rstart), too. Up to now only the mode "Importer runtime" (imrun) could be used. This has the advantage, that no licence number is required for each client. The mode can be changed in the SAP options dialogue (or the file kcusap.ini). With rstart in addition the entry of a host name for the Cubeware Import Service is required.
The restriction, that the ini file (kcusap.ini) must not be located on a server directory, was dropped.
For the topic
new documentations were created. For the first instance this documentation is only available in German language and obtainable in the menu tree in the respective branch of the application function ("Masterfiles" -> "Check rules"). You can reach the documentation for deconsolidation via the menu tree "Group Consolidation" --> "GUIDE Group Consolidation" while the other documentation is found via application "Menu items" at the menu id DKDIRIM. These documentations aren't contained in the "doku" directory of the CD as separate pdf document. However, they can be generated any time via the symbol <Export as pdf> in the online help text viewer when required.
With this release the following English-speaking documentations in the "doku" directory are updated or completed: