The IDL Konsis 2013.0 release includes changes and enhancements to the products IDL Konsis, IDL Forecast, IDL Workflow, IDL Connector (old and new) and IDL Publisher.
The IDL Konsis 2013.0 release is a major release and therefore it must not be left out of the release sequence. The minimum requirement for this release is the last IDL Konsis major release 2012.0 dated September 11, 2012.
The amendments and corrections that have taken place up until the release closure for the major release IDL Konsis 2012.0 are contained in this major release, too.
You should always perform a database backup before you install a new release. To prevent a user from losing data, a notice on the necessity of backing up data will be issued by the installation program at the start of installation.
You must always perform the release migration (see ch. 2.1) first, after a new release has been installed. For this reason, a message will be issued when you start IDL Konsis for the first time to let you know that migration has not yet taken place. This message box has now been expanded to include the button 'Start migration now'. If you click this button, migration will start automatically. Following successful completion of the migration on this way, IDL Konsis does not need to be restarted again. All of the applications will be available immediately.
If migration is not started in this manner, for instance because the logged in user does not have access rights, all other applications will be locked. The only exceptions are the applications that are used to maintain authorization data, in case the logged-in user is not authorized to carry out migration, due to the use of individual authorization groups. Following manual completion of migration, you will need to start IDL Konsis again to ensure that all of the application functions are available again.
IDL Konsis release 2013.0 uses version 1.7 of Java. For all local installations as well as for an application server IDL delivers the corresponding JRE (Java Runtime Environment) on the release CD. This does not apply for remote internet clients connected to the application server. There the JRE has to be updated by the users themselves (Java update to the most recent version due to automatic proposal).
The new IDL Connector for the MS Excel connection of IDL Konsis (see below) delivered for the first time with release 2012.0 requires at least MS Excel 2003.
OLAP interfaces may contain requests on account flags in the account master data especially on the account flags 'I' and 'J'. These requests have to be adjusted because of the displacement of these flags into the new attribute "IC account flag" (see below).
A new unique standard (pluginlauncher.jar with IDL Importer) for the SAP connection is delivered since release 2012.0 for the old general ledger as well as for the new general ledger. In the medium term this standard replaces the previous interfaces (kcusap.jar with IDL Importer and kcusap.exe with function modules). These previous interfaces are no longer developed further from the release 2014.0 on. On demand you can reorganise to the new standard your interface with the aid of your IDL BI consultant. Questions on this subject are answered by the IDL technical support or by your IDL BI consultant.
The new columns "IC account flag" and "Matching P/L , transaction development" were supplemented in the import formats of the data stocks "Accounts" (KTO), "Account categories" (KTOGRP) and "Check rule positions" (PRFPOS) (see below). The account flags 'D', 'Y' and 'Z' can be delivered in the column "Account flag" like up to now for a transition time. They are transferred into the correct column by the import application. However, please adjust your interfaces to the new logic up to installation of release 2014.0. Opposite to this the flags 'B', 'I', 'J' and 'V' can be delivered in the column "Account flag" in the long term.
When you start IDL Konsis for the first time after it has been installed, a message will be issued to inform you that migration has not yet taken place. This message box includes the button <Start migration now>. Migration will start automatically if you press this button.
The migration program will complete the following transformations in the database:
The following menu IDs are new or include new authorised actions in this release. If completely maintained customer-specific authorisation groups are used, you might need to enter access rights for these menu items (BENMEN). In most cases, the menu authorisations of the user group IDLKON and/or IDLWIN can be used as a template.
The Simplified Procedure for Administration of Customer Specific User Groups is recommended as an alternative to complete maintenance of authorisations for all menu items. For this functionality, the new authorisation level '0' can also be specified for menu authorisation (BENMENE). This states that an authorisation available for a reference user group should not be issued for the user group that has been entered.
The list applications "Processing controls" (VERARB) and "Group processing controls" (KVERARB) can no longer be invoked from the menu tree or by short word entry. However, a direct branch into these lists is supported by a double mouse click on the new columns for a total status in the applications "Company financial statements monitor" (EA, see below) or "Group companies + monitor" (KTKGES, see below), respectively.
It is no longer permitted to delete languages (application SPR) since this may cause referential integrity errors at installation of a new IDL Konsis release or update. Alternatively the status of the language may be set to "inactive" if the language is no longer used and e.g. shall not be displayed any more in the language selection boxes, too.
The area <Options> of the login dialogue now contains a second registry tab for settings of a proxy server. You can enter host, port, user name and password for an http proxy here. This page can only be edited when calling the application as an internet client.
A new look&feel "Modern UI" has been introduced for a topical representation of the IDL Konsis user interface. "Modern UI" can be set in the options dialogue. It is intended to make this setting obligatory in the future providing that the other representation variants will be no longer available.
The following modification become active at setting of <Modern UI>:
The zoom control for rescaling of the table display was revised. It now contains a plus and a minus button at its ends for increasing or decreasing the scale in steps. Beneath this control a combo box is displayed offering several standard scales, e.g. 100%. On the other hand the double mouse click function for rescaling to 100% has been disposed with this.
The filter line now displays icons in the selection box if the column contains only icons. This e.g. concerns the help text column of the new applications "Transaction development definition" (SPIDEF) and "Report definition" (REPDEF).
The display of help texts on an internet client connected to an application server was significantly accelerated.
Supplements to the meta data automatically inserted into the IDL database with each IDL Konsis release can optionally be taken. For this purpose IDL provides a set of files on the release CD in the directory LieferBatch.
Most of the former TXT files are replaced with this release by Excel files with Connector references which can be brought into the data base with the aid of IDL Connector. This serves for several advantages:
Each Excel file contains a cover sheet with the title "General". This sheet contains some central settings which can be adjusted by the user on demand. Thus e.g. the name of the corresponding database has to be entered as far as it is not accessed as "IDLDB". In addition this sheet contains notes on further modifiable keys, too.
The files provide data for the following tables:
Please note for the transaction development definitions that there is an old standard which was exclusively provided up to release 2012.0. Now only single supplements (e.g. posting keys for new usage tags) for this standard are delivered. Supplements to the old standard are ordered by releases in the Excel file so that supplements for a certain release can be carried over selectively.
Beneath the old standard a new standard for transaction development is introduced with this release. Amongst others this standard uniquely defines transaction development columns for all developments. An automatic migration from the old standard to the new one cannot be offered since development structures are individually defined. Please contact your IDL Konsis consultant if you intend to migrate to the new standard.
The Excel files contain columns with data and columns with Connector references for the old IDL Connector (cells with grey background showing e.g. "KPSPIXXX") as well as for the new IDL Connector (cells with blue background showing e.g. "SPI - ??"). Presupposition for the direct usage of the Connector references is the installation of the old or the new IDL Connector. If this is not the case, e.g. due to a missing IDL Connector licence, corresponding TXT files for import in IDL Konsis can be generated by your IDL consultant.
The fact entered as fact for group financial statements after a new installation of IDL Konsis in the first start-up data (application VORINITE) is used as "ex fact" (fact for definition of the group companies) but not inserted into the start-up data of the user but rather into the fact master record of the data entry fact.
The fact master data were enhanced by a new flag which specifies whether statistical data are held on this fact or not. "Statistical data" here means data on statistical accounts with b/s p&l flag '5' to '9'. This flag is automatically initialised with the release migration due to the existence of statistical data on each fact. The flag is evaluated at closing of the company financial statement to the next fact.
The list "Company /business unit allocations" (GESUBR) now reports a message if a fact has been entered which does not allow business units at all.
The previous field "Account flag" was distributed to three separate attributes:
The flags 'B', 'I', 'J', 'V', 'D', 'Y' and 'Z' are transferred into the new attributes by the release migration. The same applies for the account categories (KTOGRP) for definition of ranges of numbers for certain account characteristics which are evaluated at import.
The consistency checks between attributes of an account and attributes of an allocated account for aggregation of planning were tightened e.g. for a correct carry forward of development transactions into the next period without loss of data. Now errors are reported instead of warnings.
A dialogue with the question whether position account allocations are to be copied from the existing account is displayed when copying an account via the single record application (KTOE). When committing this request with <Ok> the position account allocations of the original account are copied for all charts of positions. Restrictions due to the p&l flags of the account and positions are followed.
The list "position account allocations" (POSKTO) now additionally displays the columns "Thereof position" from the position master data and thus allows for additional filtering and sorting.
The application "Transaction development definition" (SPIDEF) now displays in a column of the leading table (transaction developments) whether a help text is defined for this object. Furthermore this help text can be viewed or edited by usage of the corresponding icons in the tool bar.
The application "Transaction development definition" (SPIDEF) was enhanced by an export function. Since the application handles data of different tables after selecting the menu item "Export" at first a dialogue appears for selection of the tables to be exported. Data of the selected tables are written into export files just like export in the previous list applications SPI, SBE, SSP, BSG and BSL.
The application "Transaction development definition" (SPIDEF) now reports a message in the list "Open tasks" if transaction development areas had been defined for the shareholding development 'B' but were not supplied with area usage tags 'AHK' or 'AFA', respectively.
The last usages of the posting key usage tag 'KM' have been disposed, amongst others in the application "update equity" (see below). Therefore the usage tag 'KM' is disposed, too. All allocations of this usage tag to posting keys are deleted by the release migration (see above). The LieferBatch files don't contain this flag any more, too.
However, the posting key usage tag 'XKS' (reposting of retained earnings at disposal from the group companies) is newly introduced and applied by the deconsolidation function (see below). It may be allocated only to posting keys of a capital transaction development (development type 'K').
Posting keys with the usage tags 'AFA', 'E', 'F', 'NE', 'NF', 'P' and 'XZA' as well as 'ME' and 'MF' for the transaction development 'B' (shareholdings) are no longer supplied with a reservation flag. Thus these posting keys are displayed in the selection lists for posting keys and can be entered manually. It is no longer required to define an additional posting key for manual usage in these cases.
The posting key usage tag 'N' (other changes in the actual period) can now be used in automatic transaction developments. It is required if the automatic is disabled in certain periods (ABRSPI flag 'M'). At carry forward over the cast of the year the posting key may be switched between the posting keys with the usage tags 'L' (automatic changes in the actual period) and 'N'.
The splitting of the account flags in the account master data into three attributes (see above) has been followed in the check rule positions (PRFPOS). The accounts of a check rule position can be restricted to all of these three characteristics. This is evaluated by the calculation of the check rule results as well as by the display of the check rule analysis list (PRFERGANA).
Check rules now can work on controlling balances. For this purpose you have to set the data type of one side of the check rule to one of the defined controlling dimensions (e.g. 'CD01' for the first controlling dimension). Besides controlling balances postings or consolidation postings with specification of controlling objects of this dimension are processed at calculation of the check rule result on this side.
In addition check rules can be restricted to controlling objects. For this purpose you can specify single controlling objects or a controlling flag in the check rule positions. This restriction is evaluated independently from the restrictions to accounts or posting keys. The restriction to controlling objects is permitted for check rule sides with the data type of a controlling dimension (see above) or the data type 'I' (intercompany balances), however, here only for the first controlling dimension.
Check rules can now be defined for single business units. For this purpose a business unit has to be specified for the respective check rule position. This restriction is evaluated independently from restrictions to accounts, posting keys or controlling objects.
Furthermore you can specify for a check rule that it is to be evaluated per object of an object type. Admitted are
These 'per'-entries can be combined with each other. Then the check rule result is calculated per object or object combination existing in the processed data. The check rule result becomes [red] as far as at least one of the objects or object combination fails. The 'per'-entries are not allowed for the check rule operators 'L<0', 'L>0', 'L<>0' and 'L EXIST'.
The "Company financial statement monitor" (EA) now displays an additional status column for the total status. The total status represents the "worst" of all detail states, i.e. it is [red] if at least one of the detail states is [red], too. E.g. you can use this status for filtering of all companies with a status unlike [green]. In addition, a double mouse click in this column allows for a quick branch into the list "Processing controls" (VERARB).
Without entry of a business unit the companies are now displayed without empty lines between them. This is independent from whether data with or without business unit are present.
Inactive vouchers are no longer considered at determination of the status of postings.
The lists and single record applications for company financial statement data displayed in many cases the account flag from the account master data. Additionally some lists allowed for a selection by the account flag. Since this flag now has been distributed to three attributes (see above) it had been decided in the context of each application which of these three flags is useful and therefore displayed in the future.
The posting key group of the account is now evaluated at automatic determination of posting keys, especially at generation of transactions for changes in the actual period, providing that only posting keys suiting to the account are assigned.
A column for the group/sub-group was supplemented to the table of inventories IC-Stocks (ICVOR). This column is set to the group/sub-group for processing of the elimination of current asset results (ZU). Thus in connection with the voucher number it can be retraced in which voucher this record had been processed. The display of this column happens in the consolidation list "Elimin. current assets results list" (ZWERGUV), too.
The list "Postings" (BUCH) no longer shows a message window with messages due to debit/credit differences and missing posting keys. Rather the corresponding cells in the columns "Difference" or "Posting Key", respectively, are provided with a red background. For this purpose difference columns had been supplemented for group and parallel currency.
Company financial statement vouchers are now designated if they have influence on the equity capital ("capital effective"). Like already before for the consolidation vouchers the flag for effect on the net result is set to 'K' in this case.
The entry of an intercompany is now required for postings on shareholding accounts (IC account flag = 'B').
There is now a new function for deletion of company financial statement data (e.g. for deletion of test data), which on one hand allows for a more differentiated deletion than before, on the other hand allows for a global deletion of many of the data. This function is invoked in the company financial statement monitor (EA) in the action or object menu "Delete functions..." by the menu item "Deletion list company financial statement". This action is applied to a selected line (company) as well as without selected lines to the complete selected group companies.
In contrast to the previously existing delete functions this action does not start immediately a deletion process bur rather displays a list with all data for the selected keys which may be deleted. This display does not refer to the processing control (VERARB) but rather to the data really existing in the database. Thus e.g. it is displayed, too, if there exist data with and without allocation to business units simultaneously.
Beside account, controlling and intercompany account balances and balances-origin lists, inventories IC-stocks as well as shareholding transactions and all transaction developments with transactions are displayed separately providing the deletion of single transaction developments. In addition it is displayed for transaction developments whether there are data carried forward. For all data stocks it is displayed whether data on statistical accounts exist.
For deletion of data you have to select the lines for the data to be deleted (selection of all lines with <Cntl-A>) and invoke the action "Delete company financial statement" from the object menu (right mouse key). If the selected data contain data on non-statistical accounts as well as on statistical accounts then you are requested to decide whether only data on statistical accounts, only data on non-statistical accounts or all data shall be deleted. If the selected data contain carry forward transactions then you are requested whether carry forward transactions shall be deleted, too.
The entry field "from period" in the selection area of the list "Processing controls" (VERARB) for selection of an interval of periods was provided with an own label.
The list for the processing control log (VERARBLOG) now displays the message type (error/warning/info) and the short text of the message for illustration of the message number. However, message type and message short text do not belong to the logged data.
A double mouse click into the columns "Difference", "Curr.convers.difference", "Difference total", "Company balance" and "IC-company balance" in the application "IC clearing list" (KGESGES) branches now again off into the list "IC account balances" (ICKTOSAL) like before release 2012.0. Only a double mouse click into the columns "IC-posting company" and "IC-posting ic-company" branches off into the new list "IC-account balances and postings" (ICSALBUCH).
The function for XBRL export has been deactivated in the list "Position balances" (POSSAL). In the meantime a more valuable function for the XBRL export is available within the IDL Publisher (see below).
The new flag "with statistical data" in the fact table is now evaluated at transfer of company financial statement data to the next fact. A transfer of data on statistical accounts (b/s p&l code '5' to '9') is performed only if this flag is set for the source fact as well as for the destination fact. Otherwise no statistical data is deleted on the destination fact, too, at action "Delete and create company closing new fact". This is especially helpful if statistical data are added to the balance sheet and p&l data on a higher fact yet.
The transfer of controlling balances to the next fact was significantly accelerated.
The currency conversion of the company financial statements now identifies a conversion difference (deviance to the conversion by the closing date exchange rate) for the result account (account flag 'E') and displays it in the "Account currency conversion audit trail" (KTOUMR).
Rounding differences at the harmonised conversion of development transactions of a development column with the flag 'D', 'Y' or 'Z' and accounts with the same account flag (from now on "Matching P/L , transaction development", see above) are now automatically cleared. For this purpose a couple of development transactions with a total of zero is generated. One of these transactions in the respective development column serves for the clearing of the rounding differences to the account balances, the other transaction is supplied with the posting key with usage flag 'U' (currency conversion difference).
Comments entered in the IC clearing list (KGESGES) after a D&C or I&E reconciliation in the company financial statements on an upstream fact are now automatically adopted as comments of the D&C or I&E reconciliation, respectively, in the IC clearing list of the actual fact. It is presumed that the IC account balances had been transferred directly from the upstream fact to the actual fact (entry of the previous fact in the processing control record of check point "ICKTOSAL").
All supplements of the check rule definitions (see above) are evaluated correspondingly at calculation of the check rule results. Especially with specification of "check rule per ..." the calculation is performed per object or object combination, respectively. If an error occurs for one object the status of the complete check rule becomes erroneous.
The list "Check rule results analysis" (PRFERGANA) was revised corresponding to these enhancements. Check rules with a "check rule per ..." clause are displayed ordered by these objects on the topmost level followed by a break down to left and right side etc. A common description column was supplemented for all keys. In addition, a column for the status of the different objects was supplemented.
If only results of single check rules are calculated then it is not possible to determine a check rule status for all check rules. Therefore in this case the status is provided with the message "Check rule results not up to date - data has changed" (status of the company financial statements monitor becomes [yellow]).
These enhancements apply as well for the calculation of check rules on the level of group statements.
The lists and single record applications for group financial statement data displayed in many cases the account flag from the account master data. Additionally some lists allowed for a selection by the account flag. Since this flag now has been distributed to three attributes (see above) it had been decided in the context of each application which of these three flags is useful and therefore displayed in the future.
The flag "incl. sub-ordinate sub-groups" was provided with an own label in all group statement data lists. In addition the entry field "from period" for specification of an interval of periods in the list "Group processing controls" (KVERARB) was provided with a label.
Status values referring to the complete group (e.g. currency conversion, check rule result, lock) are displayed in the node line for the group in the usual tree representation of the group companies. A top line for the group/sub-group now has been supplemented in the list representation, too, for purpose of the display of these status values.
The list "Group companies + Monitor" (KTKGES) now displays an additional status column for the total status. The total status represents the "worst" of all detail states, i.e. it is [red] if at least one of the detail states is [red], too. E.g. you can use this status for filtering of all companies with a status unlike [green]. In addition, a double mouse click in this column allows for a quick branch into the list "Group processing controls" (KVERARB).
The following consolidation function are now represented by an own status column:
The status 'KLW' becomes [red] if the calculation of the exchange rate effects could not be processed, e.g. due to missing exchange rates at the time of carry forward. On the other hand the status 'KF' becomes no longer [yellow] in this case.
A new status icon (page with a warning triangle) or a new status columns (orange), respectively, have been invented for the case that a corresponding voucher is incorrect (debit/credit difference) or incomplete (e.g. missing entries for posting keys, fixed asset objects, controlling objects etc.). A double mouse click on this icon branches off into the list "Consolidation vouchers" (KONBEL) where the reason for this status can be taken from the message in the voucher header.
The addition date is now represented by its colour as a required entry field. Thus a date for addition to the group companies has to be specified even for non-consolidated companies (consolidation method 'K'). This date has to be adjusted at change of the consolidation method.
The status 'KF' for subsequent consolidation now remains unchanged at entry of a disposal date. Up to now it had been set to [yellow] since all depreciations had to be newly calculated. This is no longer required since a new calculation of the depreciations in all vouchers for this company is now performed automatically.
The column and the entry field for the valuation method were removed from the table of the list (KTKGES) and the single record map (KTKGESE), respectively, since this information had no relevance for consolidation.
The graphical display of the group structure was revised.
The IC clearing list (KGESGES) now allows for the display of data for a group incl. data for all sub-ordinate sub-groups. Thus e.g. for a company from a sub-ordinate sub-group all intercompany relationships can be displayed in the super-ordinate group independently from the group level.
The flag for display of data incl. data from sub-ordinate sub-groups is automatically set when calling the IC clearing list per double mouse click on the respective status column out of the group companies monitor (KTKGES). This flag is transferred to the list of consolidation postings (KONBUCH) at subsequent branches.
It is no longer reported by a message in the voucher header if a consolidation voucher exhibits a difference only in parallel currency since this problem usually can only be solved by performing the currency conversion. Thus the status of the corresponding consolidation function remains [green] in case.
The list "Consolidation postings" (KONBUCH) no longer outputs a message window with messages due to debit/credit differences, missing posting keys and missing fixed asset objects. Rather the corresponding cells in the columns "Difference", "Posting Key" or "Fixed asset object", respectively, are provided with a red background.
A refresh of the corresponding consolidation function status is now performed after each deletion of a consolidation voucher. The status becomes [red] (consolidation has to be repeated) or [empty] (preconditions for this function are not fulfilled) depending on the result of the status check, if it had been [green] (processing successfully performed) before.
If a transaction development is defined containing several checked development areas - one manually maintained balance relevant area and one automatically generated not balance relevant area - then usually only one manual posting is entered for the balance relevant area and only one consolidation posting is generated on the consolidation parameter accounts for the balance relevant area, too. Now in these cases a consolidation posting for the not balance relevant area is generated compensating the difference between both development areas as far as a posting key with usage tag 'L' is defined in this area.
Consolidation postings on the result account (account flag 'G' or 'E') representing the net result of the voucher are now generated for pure p&l vouchers with no effect on the net result. Then the result postings represent the displacement of the result between both companies. Up to now the generation of these postings was dependent from the fact, that at least one posting on a balance sheet account was present in the voucher even if this posting had an amount of 0.00. Postings on neutralisation accounts are considered at calculation of result postings. Thus e.g. no result postings are generated for an 'AE' voucher if a p&l account is specified as neutralisation account.
The former action "Generate neutralisation postings" was enhanced and therefore renamed into "Automatic generation of consolidation postings". Beneath neutralisation postings this action adjusts result postings and postings for automatic but not balance relevant transaction development areas (see above) to the effective consolidation postings, too.
The lists "Account balances and consolidation postings" (KONSAL) and "Transactions and consolidation postings" (KONBEW) now have a better support for data on statistical accounts:
The reference consolidation function specified in the voucher header is an information about the application generating the voucher. It was now determined that 'AU', 'SU' and 'KU' consolidation vouchers specify 'AU', 'SU' and 'KU', respectively, as reference consolidation function since there are separate applications for these transaction development repostings. This had already been applied to the consolidation functions 'FU' and 'QU'.
Now there is a separate consolidation parameter 'KS' for deconsolidation. This parameter is automatically generated per group/sub-group, period and fact by the release migration and supplied with the following accounts:
In addition there is an account for retained earnings, but no neutralisation account like in all other consolidation parameters since the deconsolidation eliminates other vouchers incl. their (different) neutralisation accounts and no new neutralisation postings must be generated within this.
In addition, there is another similar consolidation parameter 'NF' for non-cash disposals from the group companies. In case this parameter is generated and supplied with the deconsolidation accounts for non-cash disposals supplemented in the consolidation parameters 'KK', 'EK' and 'FK' with update 2012.0 B.
On the other hand the dislocated account dispose in the consolidation parameters 'KK', 'EK' and 'FK'.
There is a new consolidation parameter 'NE' for non-cash additions to the group companies, too. This parameter has the same structure as the consolidation parameter 'KK' for cash-effective first consolidation.
When deleting a consolidation parameter then the user now is always (like already up to now for the consolidation parameters 'SK' and 'AE') asked whether existing consolidation results are to be deleted since they become invalid by this change. However, opposite to the previous SK and AE behaviour you can answer with <No> for the intention to maintain existing results.
The group carry forward function is now available with the option "incl. sub-ordinate sub-groups". This option can be selected when calling the function out of "Group companies + monitor" (KTKGES) as well as out of "Create group carry-forward >new period" (PERKTK). Then the data from the actual group and of all sub-ordinate sub-groups are carried forward in one operation.
If the participation check determines for a company and a consolidation function that consolidation vouchers exist in the actual group level, although the processing should be performed completely in a sub-ordinate sub-group (status [T]), then this function asks you per company and consolidation function whether consolidation vouchers shall be deleted. Furthermore the consolidation functions 'KU', 'QU' and 'FF' are newly included in this check.
The first consolidation repostings (KU) no longer processes development transactions with allocation to an intercompany. Thus it is assured that the company financial statement carry forward transactions are not eliminated twice by the "First consolidation repostings" (KU) and the "SK repostings after consolidation D&C" (SU).
The reposting of difference amounts from the subsequent consolidation (KB) now is performed with the posting key determined for the difference amount on both sides as far as there is no posting key specified for the reposting account in the consolidation parameter 'KK'. Thus the issue is exhibited on the reposting account in the same transaction development column as the original posting.
However, if a posting key is specified in the consolidation parameter 'KK' then both postings are supplied with this posting key. It is recommended in this case to use a posting key from the reposting development column.
The function for update of minority interests determines the exchange rate effect on the result now from the information in the account currency conversion audit trail (KTOUMR) generated by the currency conversion (see above).
The display of data for the update equity is now possible for periods already locked, too.
Entries in the line "Other changes affecting net income" in the block "Transfer/Carry forward" in the column for the actual period in the entry form for update equity lead to a consolidation posting on the account "Actual changes associated companies" of the consolidation parameter 'EF'. For this posting now (like already up to now for the counter-posting) a posting key allocated to the carry forward column is used. Up to now a posting key with the disposed usage tag 'KM' had been used here.
The descriptions of the actions for the consolidations D&C and I&E ('SK' and 'AE, respectively) have been changed. The word "automatic" was discarded.
The preservation of manually added consolidation postings at repetition of the consolidations D&C and I&E can now be controlled. For this purpose a new flag "Preservation of manual postings" was supplemented in the consolidation parameters 'SK' and 'AE' with the following settings:
The setting '1' corresponds to the former standard and is set in all existing consolidation parameters at release migration.
Comments entered in the IC clearing list (KGESGES) after a b/s or I&E reconciliation in the company financial statements on an upstream fact are now automatically adopted as comments of the consolidation D&C or I&E, respectively, in the IC clearing list of the consolidation fact. It is presumed that the IC account balances had been transferred directly from the upstream fact to the actual fact (entry of the previous fact in the processing control record of check point "ICKTOSAL").
Both applications (SK, AE) in the options with and without previous deletion as well as the corresponding transaction development repostings (SU, AU) are now offered as global application, too. I.e. The applications can be invoked directly from the action menu of the application "Group companies + monitor" (KTKGES) without selection of lines and then process all group companies in one step. This global call for the consolidations D&C and I&E has the advantage versus the invocation for each company separately, that each couple of companies is processed only once. You can call the global function in an automate control by omitting the specification of the parameter "Company".
The function "SK Repostings after consolidation D&C" (SU) now processes manually entered 'SK' consolidation postings on intercompany accounts. Thus it is supported that intercompany balances reported too late can be posted manually without having to repeat the complete consolidation D&C. However, if postings not corresponding to intercompany balances of the company financial statement are entered manually then the "SK Repostings after consolidation D&C" exhibits differences. The same applies for the "AE Repostings after consolidation I&E" (AU).
Rounding differences for quota consolidated companies are cleared by the consolidations D&C (SK) and I&E (AE). The posting key with the usage tag 'Q' is no longer used for this clearing posting since it is intended only for changes of the quota. Rather a posting key for changes in the actual period (usage tag 'L' or 'N') is used.
The entry of an overhead/direct percentage of 0% in the product margins (PROMAR) is now processed as a margin of 0%. Then deviating information in the product data (PRODAT) is not concerned.
The direct call of the single record application "Intercomp. account stocks" (ICVORE) is no more supported in the "Elimin. current assets results list" (ZWERGUV) since this was capable of being misunderstood. A branch off into the company financial statement list "Inventories IC-stocks" (ICVOR) was supplemented instead which allows for the call of the single record application in a subsequent step.
It is now supported to consolidate more than 99 IC-stock data records per couple of companies. Up to 99 an own posting record is generated per IC-stock in the 'ZU' consolidation voucher like before. All additional IC-stocks are posted with posting record number 99, too. Furthermore the runtime of this processing was reduced significantly especially when processing many data.
A deviant comparison fact can now be entered for calculation of quota clearing amounts (QU). This closes a potential gap at calculation of the deconsolidation result.
Conflicts for consolidation vouchers with consolidation function 'PM' could arise at simultaneous merger of several subsidiaries to the same shareholding company. To avoid these conflicts now only for the first merged subsidiary a 'PM' voucher is generated. For the following merged subsidiaries vouchers with consolidation function 'P0', 'P1', etc. are generated.
A new account flag 'C' was invented to classify accounts (e.g. retained earnings, IFRS reserves) which have to be considered at calculation of a deconsolidation result. All accounts already considered (accounts for retained earnings in consolidation parameters, facts and account master data) are automatically provided with account flag 'C' by the release migration except for the accounts with the account flags 'W' and 'X'. The deconsolidation function now considers all accounts with the account flags 'C' and 'X' at calculation of the deconsolidation result.
The reclassification of the retained earnings to the result from deconsolidation is now performed in two steps. In the first step the amount from the account for retained earnings (account flag 'C') is reposted to the general account for retained earnings (account flag 'X' or, if not defined, account for retained earnings from the fact (FAC), respectively). In a second step the retained earnings are eliminated on the deconsolidation result account. The posting key with the new usage tag 'XKS' (reposting deconsolidation) is used for repostings from the special to the general account for retained earnings.
The states of all consolidation functions from now on are stored exclusively in the table "Group processing control" (KVERARB). The status values kept before directly in the table of the list "Group companies + monitor" (KTKGES) are transferred into new group processing control records by the release migration, even for closed periods and statements.
This storage of the status information offers several advantages:
The keys of the check points were chosen as the two digit consolidation function names. This applies for entries with deviating keys which were held in this table before release 2013.0, too.
The action "Manual release" was supplemented in the list "Group processing controls" (KVERARB). This action offers the facility to superimpose an erroneous status in the group companies monitor (KTKGES). E.g. this may be required if certain issues have to be posted deviating from the IDL Konsis standard on demand of the financial auditor or if consolidation vouchers were not created by the IDL Konsis function but rather were entered manually.
A manual release is exhibited in the group companies monitor (KTKGES) by a special hand icon. The original message (error or warning) is preserved in the list "Group processing controls" (KVERARB). The manual release is documented by an additional column for the release state. The modification information exhibits which user had performed the manual release at which time.
A manual release can be revoked by another action in the list "Group processing controls" (KVERARB). Then the original message and its status become active again. A manual release is automatically revoked, too, when performing the corresponding consolidation function.
The manual release function is not available for the check points 'KTKWUM' (currency conversion), 'KTKGRAPH' (storage of the graphical display of the group structure) and 'KTKAB' (lock of the group financial statement).
The deletion of group processing control records is no longer permitted.
The list of the change log of group processing control records (KVERARBLOG) now displays the message type (error/warning/info) and the message short text for explanation of the message number. However, message type and short text do not belong to the logged data.
The selection area for selecting a company and business unit for the scenario to be loaded has been removed. The entry fields are now located above the scenario list. The icons for saving and closing a scenario previously located in the selection area are now located in the global tool bar. Writing balances is supported by a menu item in the menu <Action>.
Opening a choice dialogue via function key <F4> is now supported for the company and the business unit fields in the scenario list.
The scenario list displays all companies / business units already created for a scenario below the scenario. Double-clicking on this company / business unit line opens the scenario for the company and business unit directly.
A filter line is now provided in the scenario list.
If a scenario is created for a company / business unit combination but this combination is not defined in the company business unit allocations (GESUBR) for all facts / periods of the scenario, then the missing allocations are listed in a window. A button allows for the automatic generation of all missing allocations in the FORECAST and PLAN area provided that the allocations are complete for the ACTUAL area.
A scenario can be locked for a company / business unit via a new entry in the object menu of the scenario list. The lock is indicated by an icon, the tool tip of this icon states the user and the timestamp of the lock. A locked scenario can only be opened for reading.
The question dialogue whether parameters of a modified scenario shall be transferred is now suppressed if the scenario is opened for the first time for this company.
Copying a scenario can now be restricted to single companies and business units. Within this you can select for which companies / business units balances and rules shall be copied.
Table headers were added in the window for selecting reports for a scenario (selectable reports or selected reports, respectively).
The time resolution of the periods of a scenario can now be defined more flexibly. The previous definition of one resolution for the entire scenario has been removed. Instead of you can specify on the second page of the scenario wizard for each of the allocated periods whether they are to be divided into months, quarters or years. The corresponding check box is deactivated if the required periods are not defined in the period master data (ABR). The period selection box on the right hand side displays which resolution is available for each period. If you drag these periods on the corresponding 'M', 'Q' or 'J' fields with the mouse into the list of selected periods then the corresponding check box is automatically selected. Furthermore the preview is now permanently displayed and refreshed.
You can now define in the property dialogue of a scenario by activating the check box "Rules across data areas", that rules defined in the FORECAST area shall affect later PLAN periods. This is supported by the sales, income, purchase, expenses, personnel and dissolution rules as well as by the investment and the financing rule. It is presumed that FORECAST and PLAN periods do not overlap. This allows for a "Rolling Forecast". However, without activating this option, investment and financing rules still are not permitted in the FORECAST area.
Periods restrictions for parameter values can now be specified as a period interval by entering a from-period and an until-period. Both borders of the interval may be open (empty).
It is now supported to load balances from a fact differing from the target fact of the scenario. For this purpose, the menu item "Configure Source Facts" was added to the action menu. When using this menu item, a dialogue opens allowing for the entry of a differing source fact for the FORECAST area as well as for the PLAN area. These settings are saved in the scenario and applied for all loading operations.
In addition, this dialogue for setting of source facts provides a control for the mode of calculation of decumulated amounts in the first FORECAST period: as the difference to the ACTUAL amounts of the previous period or as the difference to the FORECAST amounts of the previous period which then have to be present as account balances, too.
The balance of the result account (account flag 'E') is now calculated by IDL Forecast in the same way as by IDL Konsis.
Accounts without entry flags in the account master data for any period type ('M', Q', 'J') are not displayed in the scenario at all. If an account has different M, Q and J settings, then the cells are locked against data entry for periods that are not permitted according to period type.
If a plan aggregation account is not contained in a scenario or is not valid, then the account balances assigned to this aggregation account are not aggregated but rather displayed in their accounts of origin. In addition, the message "STOP! The aggregation of the following accounts is not possible: ..." is reported each time the plan aggregation check is performed.
A button allows switching between cumulated and decumulated representation of the checking block. The cumulated representation allows for a direct comparison with checking blocks in IDL Konsis.
A new dialogue for detailed splashing and copy functions was added. Splashing can be performed according to previous amounts, to reference data or equally distributed. An amount can be modified directly or increased or decreased by a fixed percentage. Rounding rules can be specified for the results. Copying can be performed from definable source areas for account balances, controlling balances or intercompany balances.
There is a new menu item "Check for Missing / Double Rules" in the action menu. When choosing this action, a dialogue opens which lists in a table all balances with missing rules or which are transferred by multiple. You can order the entries by account, period, etc. by clicking on the table header.
Two new dialogues allow restricting of the intercompany or controlling view of the table area to certain IC companies or controlling objects, respectively.
When leading over balances between data areas, intercompany and controlling balanced are transferred as well. The same also applies for the carry forward of balances to the next period within a data area.
With the aid of the new icon "Insert cells" in the toolbar, additional lines or columns can be inserted into the table, which allows the definition of calculations in the cells using simple calculation formulae.
Additional sheets can be added as well. The formulae can refer to cells of areport sheet. These sheets can be configured by assinging the available dimensions (positions, accounts, years, quarters, facts, months) to lines or columns. These table sheets allow switching between the display of account balances, controlling balances and intercompany balances as well. Additionally, a filter line is available.
Besides the already existing option "Activate Intercompany planning" which allows displaying intercompany balances in the planning sheet, there is now an additional option in the scenario settings "apply rules on ic balances" allowing for a rule-based intercompany planning.
When activating this option, balance changes by rules, carry forwards or manual changes on intercompany accounts are not performed on the level of account balances, but rather on the level of intercompany balances. No changes can be performed on account balances for intercompany accounts. For this reason, this option may not be activated or deactivate after the scenario has been created.
For each account, a list of IC companies can be defined. This list is generated automatically when starting the scenario on the basis of the ACTUAL balances and can be extended automatically or manually if necessary. Besides this, globally valid IC companies may be defined independently from the account-based settings.
Relations to third parties on accounts with IC account flag 'J' are treated like relations to a specific intercompany. This concerns carry forward, the processing of rules and manual changes. The third party portion of the account balance may be distributed separately on different accounts with the sales, income, purchase and expenses rules.
An additional page is included in the rule wizards allowing to select the IC companies for which the rule is to be created, provided an intercompany account has been selected for the rule. Tax, bank, general allowances, investment and depreciation accounts may not be intercompany accounts with ic account flag 'I'. For accounts with ic account flag 'J' the entire balance is posted to third parties.
There is a new menu item in the view menu "Warning for incomplete IC details". A warning icon is displayed in all account cells with incomplete intercompany details if this item is activated.
IDL Forecast now allows creating a short-term liquidity report, derived from the opening balance of assets on liquid resources and cash-effective changes in the actual period resulting in a final balance on liquid resources.
Constitution of the liquidity report is done via a new wizard which defines four basic positions. The user has to determine which accounts define the liquidity and allocate these accounts according to the basic positions as follows:
The short-term liquidity report is shown in an additional table sheet with details for positions and accounts. It is possible to define several variants of a liquidity planning, each of them displayed in a separate table sheet.
Up until now, rules could be restricted to certain periods or to the entire PLAN or the entire FORECAST area. Now you can restrict rules to the first or last period of each data area as well as the first or last period of each year.
Rules with payment or dissolution components defined in the FORECAST area now affect the PLAN area as well, provided that the FORECAST and PLAN areas do not overlap and the respective new option has been set in the scenario properties. In that case, the investment, financing and leasing rules can be defined in the FORECAST area.
A special carry-forward rule for retained earnings is created for accounts with the setting "Reposting at carry forward" when balances are carried forward from a year end period to an interim period in the same data area. The value of the closing balance is posted as an account entry in the specified account for retained earnings.
The period definitions in the payment and tax dissolution components of the sales, income, purchase, expenses and personnel rules now always refer to months, regardless of the time resolution of the scenario. The required conversion to the time resolution of the scenario (see above) is performed automatically when applying the rule. Thus the same rule can be applied in areas or scenarios with different time resolutions. Already existing rule templates referring to periods with a quarter or year resolution will have to be adjusted by the user. Otherwise incorrect results will occur when the rule is applied.
Period definitions in dissolution rules or general posting record rules continue to refer to periods instead of months.
The ability to enter parameters for percentages in the payment postings of the sales, income, purchase and material rules has been removed in this release.
It is now possible to set separately for each of the variables of a posting record rule, whether it is represented as part of the posting record in the business case viewer.
The wizard for the general posting record rule was revised. Amongst others the definition of the variables was integrated into the definition of the relation rules. The range of definable rules was not restricted within this.
A comment can now be added to each individual relation rule of the general posting record wizard. For this purpose, a comment button was added below the delete button of each relation rule. The comment editor opens when clicking this button. The tooltip on the button displays the comment.
The wizard for the transition rule now supports the allocation of accounts with the mouse (drag and drop). No account is preset on the right hand side for mass allocation. Instead of this, the text "Select account" appears.
The investment and the financing rule now offer the ability to enter existing loans. For this purpose different loan types (amortisation loan, bullet loan) and a starting date before the beginning of the PLAN area may be specified. Interest payment intervals can be selected independently from redemption payment intervals. The generated redemption chart can be manually adjusted or manually entered entirely with the option "user defined". The duration of the financing is always specified in months.
A business case description can be entered for a financing rule just like in the investment rule.
A warning or error message, respectively, is output in the rule wizards if the payment and dissolution components do not balance to 100%. This message now reports the difference amount for easier correction.
Choice dialogues are now invoked by the function key <F4> for the parameter text fields in the rule wizards as well.
The status of rule templates is no longer represented by different text colours but rather by icons in additional columns in the template tree:
Furthermore, a new column shows where this rule template had been applied. Possible values are "All periods", "FORECAST", "PLAN", a certain period or period interval.
A filter line was added to the table of rule templates.
A new button allows hiding all empty business cases, i.e. business cases whose postings contain only amounts of zero or empty. The number of hidden business cases is displayed.
Another new button in the account, controlling and intercompany viewers allows hiding all empty account entries, i.e. changes that contain only amounts of zero or empty. The number of hidden entries is displayed in the bottom of the window.
Comments (up to 500 characters) can now be entered for all account balances as well as account changes. For this purpose, the object menu (right mouse key) of these objects was extended by the functions "Edit comment" and "Delete comment". The comment is displayed as tooltip for the respective object. Commented cells are designated by a comment icon (book) in the report table and in the details windows. A double mouse click on this icon opens the comment editor.
Comments are exported to IDL Konsis,. However, they are stored in the remark field and thus shortened to 70 characters.
The calculation statistics were removed and can no longer be activated in the IDL Forecast options.
You can now select several positions or report lines simultaneously in the application "Report definition" (REPDEF)
The application "Report definition" was enhanced by a "Preview" view of the defined report. This preview is displayed in an additional register tab in the lower part of the application window. The preview serves for an impression of the final report. For this purpose all formattings of the report definition are displayed in connection with a selectable column option. The cells always represent a dummy value (12,345.67). However, the algorithms of the report are not considered yet.
Because of the basic display of the report structure in a tree structure in the application "Report definition" (REPDEF) allocations to super-ordinate positions located behind the position cannot be displayed. If the application loads this kind of report a warning message is output reporting that this allocation is removed when saving.
Same positions consecutively following on each other in a transaction development report now are only permitted if restrictions for the origin fact of postings are defined for these positions. Then these lines are merged to one line at display in REPDEF as well as in the report result. Lines not complying with this (without restrictions) provide an entry in the open task list and are automatically eliminated when saving.
The new standard column option #KFSGE was supplemented for the cash flow report. It corresponds to the column option #SUMGE (statement of account per company) for a b/s p&l report.
An error message is no longer reported if the action "Create report" is issued for a report with allocation to a reference version. Rather this action is simply ignored. So you now can select a list of reports and create them in one call without interruption by error messages even if reports with a reference version had been selected. However, you receive no information, too, if only a single report with a reference version had been selected.
A warning message is output when creating a report containing several subsequent lines with identical positions without further restrictions (compare above).
Controlling reports for the function of expense method (report type 'E' with report option 'C') with allocation of controlling balances to different positions due to the controlling flag 1 can now be created on the level of aggregated controlling objects. The evaluation is performed based on the elementary controlling objects providing that the same combination account / aggregation controlling object may appear multiply in the report if controlling objects with different controlling flags had been aggregated.
Rounding differences between the residual book value of the previous period and carry forward in the actual period may appear in transaction developments with development areas for quota consolidated companies. These differences are now cleared at report generation providing that the report result does not exhibit any differences. However, thus the amounts displayed in the report result are no longer identical to the amounts displayed in the development transaction lists (e.g. ANLBEW).
It is now supported to write position balances for a cash flow report which then can be evaluated e.g. with IDL Connector as report result. For this it is presumed that all superordinate nodes (i.e. nodes without allocation of accounts) are allocated to a separate chart of positions. This chart of positions has to be designated in the new flag "Chart of positions for cash flow positions". Another assumption is that the option "Write position balances" is set to 'P' or 'S' in the report header (REP). Position balances are written only for this designated chart of positions.
The action "Zoom balances & transactions" for a line on the lowest level of a company cash flow report (representing transaction development columns or posting keys) now branches off to the corresponding display of the list "Development transactions" (SPIBEW).
A characteristic of the report result list is to display amounts in the node lines if the nodes are collapsed while the amounts in the node lines remain empty if they are expanded and the last line of the details is a total line. This behaviour is now reenacted in MS Excel after an export to Excel.
A new function (item in the context menu) now allows for duplicating a workflow. The new workflow is identical to the old one incl. all of its descriptions. However, the new workflow is not yet started and thus can be modified.
This function is especially helpful if a workflow has already been started and is thus locked for changes but has to be modified for further applications.
The maintenance of the workflow tasks has been significantly extended. The available menu items were arranged in a special menu tree for selection of the allocated menu item. On the top level this menu tree shows the application type (list / form entry / import / processing). Below this the menu is built up analogue to the IDL Konsis menu tree and thus allows for a good orientation and navigation.
The selection of parameters is now dependent from the selected menu item. Only parameters processed by the respective application are offered. In addition, it is checked whether all required parameters have been specified.
Beside explicit keys you can now specify special values for the parameters just like in the workflow automate control, e.g. "Parameter from Settings" (#VOR) represents the key of the start-up data of the user while "Parameter from Start..." (#START) represents a key defined in the start node. The latter requires the definition of these keys in the start node. In addition, there you can select "Parameter from selection keys" (#KEY) or "Parameter from optional input in selection field" (#OPT) providing the entry of the parameters in an entry box when starting the workflow.
The new columns "IC account flag" and "Matching P/L , transaction development" were supplemented in the import formats of the data stocks "Accounts" (KTO), "Account categories" (KTOGRP) and "Check rule positions" (PRFPOS) (see above). The account flags 'D', 'Y' and 'Z' can be delivered in the column "Account flag" like up to now for a transition time. They are transferred into the correct column by the import application. However, please adjust your interfaces to the new logic up to installation of release 2014.0. Opposite to this the flags 'B', 'I', 'J' and 'V' can be delivered in the column "Account flag" in the long term.
The new attributes of the "Account categories" (KTOGRP) are evaluated at import of accounts (TXTKTO) just like other attributes by providing accounts with an account number out of the specified interval with the corresponding flags.
Like in the dialogue application now also at import of companies (TXTGES) only a warning message is output if a company chart of accounts or chart of controlling objects is modified. Up to now the import rejected this change with an error message.
References to the disposing format type 'KSTSAL' (replaced by 'CNTSAL') and the disposed format name '#TXT061' in the import/export format definitions (IEF, IEFFEL) and the import/export jobs (IEJOB) are automatically deleted by the release migration.
The previous object type for transformation groups 'AGB' was replaced by both object types 'POP' (charts of positions) and 'RID' (Report idents).
The group-wide and the group/sub-group exchange of data have been modified to include various database enhancements. For this reason, they are not compatible with previous release versions.
Transformation groups now can be applied for data exchange of company data. A new item "Delete & reload company financial statement with transformation" (GESDLADNMU) was supplemented in the calling application "Group subgroup data exchange" (KONDAT) for this purpose.
The new IDL Connector is able to run with MS Windows 8 and MS Excel 2013 including the 32 bit and the 64 bit version.
A separate IDL installation path as well as a corresponding ini file now can be specified for each database connection.
Combo boxes for selection of master data as keys for connector references now can be defined in the Excel cells. The menu item "Field/list box" in the menu "Tools" serves for this purpose.
A filter can be applied for the function "Refresh" providing that either only references or only list boxes are refreshed.
The essential key fields in the read function references are now obligatory entries (like in IDL Konsis) and correspondingly designated by colours.
If a database field of a master data record has no value when reading then the new IDL Connector displays no value for this field, too. This is different from the old IDL Connector which displayed a '*' in this case.
The new read function "Group companies" allows for reading of the "Participation book value", "Participation capital percentage (add.)", "Participation capital percentage (multiple)", "Participation capital voting percentage" and "Participation capital voting percentage" by selection of the appropriate field definition.
The write function (export) is now available in the new IDL Connector for nearly all data. The variants "Save" and "Delete/Save" are facilitated as far as supported by the IDL Konsis import. After selection of the export function (selected area, worksheet or workbook) a dialogue opens which allows for the selection of the tables to be exported. The export operation starts after pressing the <Export button>.
The release 2013.0 CD contains the current version of IDL Publisher. IDL Publisher serves for the generation of business reports in the direction of MS Word and, from the year 2013 on, for the XBRL reporting (e.g. the generation of an E balance sheet, the publication in the federal bulletin or the requirements of bank reports (FinRep)).
The software of IDL Publisher is installed depending on the user licence in the installation path in the subdirectory "Components". If you have installed IDL Publisher in a different location you have to copy the installed directory to this location.
OLAP interfaces may contain requests on the account flag in the account master data especially on the account flags 'I' and 'J'. Because of the relocation of these flags into the new attribute "IC account flag" (see above) these requests have to be adjusted. This especially applies if the standard MIS tables ('K8xx') are not used.
Consolidation postings with posting keys of not balance relevant transaction development areas are no longer included in the calculation of the data for the table K850 (account balances from the group point of view).
A new unique standard (pluginlauncher.jar with IDL Importer) for the SAP connection is delivered since release 2012.0 for the old general ledger as well as for the new general ledger. In the medium term, this standard replaces the previous interfaces (kcusap.jar with IDL Importer and kcusap.exe with function modules). These previous interfaces are no longer developed further from the release 2014.0 on. Please reorganise your interface to the new standard on demand with the aid of your IDL BI consultant. Questions on this subject are answered by the IDL technical support or by your IDL BI consultant.
In this connection the maintenance of the interface parameter is relocated from the options dialogue into a new application "Administration of the SAP integration" (SAPDMIN). This application allows for
On the side of the client the logic has to be implemented in tcl scripts since the SAP plugin serves only for integration of the IDL Importer job on the side of the server.
The SAP standard interface with IDL Importer template from now on can be invoked only via rstart. Thus the options dialogue as well as the login dialogue could be simplified.
The new application SAPADMIN is available only for users with the SAP interface licence.
The release 2013.0 CD contains the current edition of the DCW interface for DCW release 3.50.
The following English language documentations have been updated or enhanced in the documentation directory together with this release:
For a current version of the hardware and software requirements please refer to the service center of the IDL web page (www.idl.eu).