When you start IDL.KONSIS.FORECAST 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 version. 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 following menu ID was deactivated with this release. It will be deleted in one of the subsequent releases. Please remove all individual usages (authorisations, menu structures) of this menu item until then:
As far as these applications could be invoked directly via short word entry now an automatic switch to the short word of the new application as substituted is performed when entering one of the disposed short words.
The following menu IDs are finally deleted with this release:
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 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.
In line of the extended licence parameter (see above) now the defined users are classified with respect to their roles in IDL.KONSIS, IDL.FORECAST and IDL.XLSLINK. For this purpose the table and the application USE were extended by three corresponding flags. For IDL.KONSIS the following user types are distinguished:
For IDL.FORECAST only Full and Light users are distinguished, for IDL.XLSLINK there is only the type Full user. The entry of a user type per product is optional. If an entry is missing then the user cannot use this product.
The defined users are classified by the release migration in the following way:
If the migration registers that the number of users of a user type is greater than the number specified in the licence file then a corresponding notification is output. In case after migration the classification has to be adjusted to the proper role of the user to avoid message because of violation of licence limits.
When logging on to IDL.KONSIS.FORECAST as well as at display of users in the application USE the number of users per product and classification is compared to the corresponding number in the licence file. If the number of one type exceeds the licenced number a corresponding notification will be output. If it is determined at new entry of a user or at modification of its classifications that a licence limit will be exceeded then a notification message is output, too. It is urgently recommended to let the licence file be adjusted since these check will be more restrictive in the future.
Beside an authorisation check due to the menu authorisations allocated to the user group of the user now a check for authorisation with respect to the classification of the user is performed. If this authorisation is not present then e.g. the following message is output: "The application "Consolidation postings" (KON|MOD|KC1049) is for your user not licenced. Please let check the licence user types of your user."
An IDL.FORECAST Light user is not authorised for the definition of rules but only for their application. Besides the authorisation for special IDL.FORECAST applications (PLAN, PM, PA etc.) an IDL.FORECAST Full user has the authorisation for the maintenance of master data required for and the company financial statement data used in IDL.FORECAST, too.
For IDL.XLSLINK it is only checked at login to an IDL.KONSIS.FORECAST database whether the user is classified as IDL.XLSLINK Full user.
The representation and the update of the number of faulty password entries was revised. The table of the application USE no longer shows a number of faulty entries (usually either 0 or 3) but rather a lock icon which shows the state closed if the number of faulty password entries has reached 3. The number is still displayed in the single record application USEE. In addition, the reset of a lock is no longer performed by reset of this counter to zero but rather by a new action "Reset login attempts" in the context menu (right mouse key) of the list (USE) or the single record application (USEE).
First and family name are now provided with the user ID if a new user is automatically generated at authentication via Active Directory.
If, at authentication via the Active Directory user, no "user group for data objects" is specified for the template user when attempting to create a new user, then now the program looks in the IDL.KONSIS user groups for exactly one AD data group which is allocated to the AD user in the Active Directory. If no such IDL.KONSIS user group is found an error message is output ("Data user group not found"). If more than one such IDL.KONSIS user groups are found then an error message is output, too ("Data user group is not unique").
All processing functions of IDL.KONSIS now write all messages reported by them into a log table. For this purpose each executed application is provided with a job number. Several applications invoked in one call out of a calling application (e.g. company or group monitor or automate control) receive the same job number but are distinguished by a step ID. Note: Import processings are not yet considered here.
The list of the executed applications is displayed by the new list application "BG Processing job control" (short word 'BGPJOB'). Here the timestamp of the execution is logged as well as the user who invoked the function. From here you can branch off into the message protocol as well as into a list of the parameters set for this function.
When calling an automate control now you can control via an additional parameter whether messages shall be displayed on the screen or rather be suppressed. If messages shall be suppressed then no messages are output, too. Rather it is assumed that requests taken by the application always shall be answered with the button declared as the default button, i.e. the button triggered by the <Enter> key. Subsequently request, error and execution messages can be viewed in the job protocol mentioned above.
In applications with several windows the element situated in the focus, i.e. on which keyboard entries act, is now emphasized by a red border. Selected elements in other windows are provided with a grey border and a light grey background.
In addition, the area out of several areas situated behind each other placed in the foreground is more clearly emphasized by a red frame of its registry tab.
Registry tabs are now displayed shortened if the available area is not sufficient for a complete display. The scroll bar used up to now in this case is dispensed with this.
If, caused by the chosen selection, a very large number of data has to be read from the database, then now you are requested whether you really want to do so since a long response time is expected. You can abort the processing if this is not wanted. Otherwise the data are read correspondingly and the progress is visualised by a progress display. Usually a number of 100.000 data records is used as the threshold amount for this message. Excepted are applications which do not allow for a reduction of the amount of requested data like e.g. the report result display. Please mind that the amount of data records requested from the database is not always identical to the number of data lines finally displayed.
It is now possible to distribute excel files generated out of IDL.KONSIS.FORECAST by Excel export directly as e-mail attachment. For this purpose a button <E-Mail> was supplemented in the file dialogue displayed at Excel export which can be used alternatively to <OK> and <Cancel>. In this connection the button <OK> was renamed into <Save> since only in this case an Excel file is saved in the pre-selected or chosen directory.
When pressing the button <E-Mail> opposite to the button <Save> Excel is not started for display of the generated file. Rather, just like the corresponding button in the print dialogue, the pre-selected e-mail client opens with the function for a new e-mail and the generated Excel file is pre-selected as an attachment. The subject is pre-selected with (e.g.) "Excel export out of the application ICKTOSAL".
The entry of a short text now in most cases is optional. In addition, short texts are no longer generated from the first ten characters of the long description. Excepted from this are short texts of groups, companies. business units, transaction development columns, posting keys and report IDs. Here the short text continues to be a mandatory entry since it is used in other places of IDL.KONSIS.FORECAST.
When editing in the table including mass-update now optional entries which are selected via a choice dialogue can be provided with an empty value. For this purpose the choice dialogues exhibit an additional entry "empty". This corresponds to the entry '*' in mass-update of the conventional applications.
Several applications show a list of open tasks in the bottom part of the application window. Depending on the type of the task icons for automatic (gear wheel) or manual (hand) are displayed before the task. These icons are now deactivated if the user has not authorisation for update of the data.
In complex applications (applications with several tables) all performed modifications are yet saved in the database when pressing the <Save> button. The situation that one user overwrites the modifications of another user this way is now omitted by a lock entry for the first user opening an object (chart of accounts, transaction development, report, check rule etc.). Then another user can only read the allocated data but cannot change them anymore.
When exporting data from an application with several tables a radio button group on the right hand side of the export dialogue allows for the selection of the table of which data shall be exported. In this radio button group now always the table displayed in the foreground and holding the focus is pre-selected.
Correspondingly the print preview is applied to the table displayed in the foreground and holding the focus, too.
In connection with the extended licence parameters (see above) now the companies defined in the company master data are classified due to their usage in IDL.KONSIS.FORECAST and IDL.XLSLINK. For this purpose the table was extended by three corresponding flags. For IDL.XLSLINK there is only the type "Full company" (usage in the Excel entry form), for IDL.KONSIS and IDL.FORECAST the following types are distinguished:
The defined companies are classified by the release migration program as follows:
This classification has to be adjusted to the real usage of the companies to avoid messages with respect to violations of the licence parameters.
When logging in into IDL.KONSIS.FORECAST as well as when displaying the company master data in the application GES the number of companies per product and classification is compared to the corresponding entries in the licence file. If the number of companies of a certain type exceeds the licenced number then a corresponding indication message is output. If it is determined that a licence limit is exceeded when entering a new company or changing the classification of a company by manual entry or by import, then an indication message is output, too. It is strongly emphasized to let the licence file be adjusted since these checks will be performed more restrictively in future versions.
In addition the company master data were extended by the following fields for additional information about the company:
For the time being these fields only serve for information and are not evaluated in IDL.KONSIS. However, the value added tax identification number is required for the country-by-country reporting.
The maintenance of these fields is performed in the application "Companies" (GES) on a separate wizard page "Legal properties". The page "Properties" already existing was renamed into "Technical properties". Modifications in these fields are stored in the change log (GESLOG).
The import/export format as well as the import table I110 for companies were extended by the new fields for the licence classification and the legal properties.
The windows for selection parameters as well as for the resource table (accounts) now are only displayed if the table for position account allocations is situated in the foreground, but no longer if the table of positions is placed in the front.
When deleting an account in the application "Chart of accounts definition" (KTODEF), a position in the application "Chart of positions definition" (POSDEF), or a controlling flag 1 in the application "Controlling definition" (CTLDEF) then now automatically all data records with reference to the data object to be deleted are deleted, too, from the table of position/account allocations providing that that the object itself can be deleted without corresponding foreign key violations. Please note, that this extension does not apply for deletion in the applications "Accounts" (KTO) and "Positions" (POS). Here the report of a database error (foreign key violation) is continued.
The "IC account flag" ('B', 'I', 'J', 'V') was replaced by two new attributes "IC details" ('B', 'I', 'V') and "Validation of IC details" ('X', 'A', '-') (see below). An automatic conversion of the old flag is performed by the release migration program (see above). Both attributes always have to be specified together.
Within this the dependencies between accounts and their allocated group or aggregation accounts had to be newly managed:
When entering a group or aggregation account the attributes "IC details" and "Validation of IC details" are transferred (inherited) if the combination with the existing attributes of the account would not be admissible.
If the b/s p&l code of the allocated group account was not compatible with the b/s p&l flag of an account, then the wizard of the application 'KTODEF' complained the group account as faulty and it was no longer possible to modify the b/s p&l code. Now the b/s p&l code of the group account can be selected or entered, too.
The list "Fixed asset objects" now exhibits the chart of account in addition to the account number as far as it had not been selected uniquely as a selection criteria. Thus cases where a fixed asset object was allocated to a wrong chart of account can be uncovered more easily.
Accidentally the entry of a controlling flag 1 had been allowed with a length of up to 14 characters. However, the usage of controlling flags 1 with a length of more than three characters provided for a program error (exception) in the position/account allocations when opening a model in the application "Chart of position definition / account allocation" (POSDEF). Therefore now again controlling flags 1 can be defined only with a length of up to three characters.
Note: If you already have defined controlling flags with a length of more than three characters, then we recommend to replace them by controlling flags with a length of up to three characters. Then you have to adjust all usages in controlling objects, check rules / positions and position/account allocations. After adjustment the controlling flags with too long keys should be deleted.
The response time of selection dialogues was reduced by optimisation of the database access. This especially affects the display of large amounts of data.
Check sums of selected data are now output independent from the selected sort option, i.e. even if the data are not primarily ordered by company. Therefore the display is performed in a check sum block behind the proper data even if the data are primarily ordered by company.
The display of detail data of account balances (when ordered by company and account) was adjusted to the representation already applied for intercompany account balances since version 17.1. Differences between account balances and detail data are no longer reported in a message window but rather displayed in a column on its own near the total per account and the account balance. A double mouse click on an amount in the difference column opens the single record map with pre-selection of the difference amount to be cleared. This concerns controlling balances (CNTSAL), shareholding (GESGES), IC fixed asset (ICANLBEW), fixed asset (ANLBEW), capital (KAPBEW), provision (RUEBEW) and other development transactions (SPIBEW).
The previous "IC account flag" ('B', 'I', 'J', 'V') was split into two flags:
Thus there are now nine different possibilities instead of four up to now:
| Validation \ IC details | 'I' | 'B' | 'V' |
|---|---|---|---|
| 'X' (full) | 'I' | 'B' | new |
| 'A' (proportional) | 'J' | new | new |
| '-' (not at all) | new | new | 'V' |
New possibilities are e.g.:
The status display in the company financial statements monitor (EA) as well as the flags in the column "IC details" of the account balances (KTOSAL) are now determined with respect to the "Validation of IC details" specified for the accounts. I.e. even the IC detail 'V' is now supplied with a background colour.
The clearing of intercompany account balances using the clearing flag was revised in several items:
In addition, the possibility to distribute exported Excel files directly per e-mail (see above) was primarily provided for IC clearing.
The status validation of controlling balances now reports only once per account that no required controlling object had been entered with respect to the account definition even if several data records are concerned since the error message does not contain a unique reference to the faulty record(s).
As an alternative missing controlling objects are now displayed with a red background in the column of the respective controlling dimension. In the same way accounting standards deviating between account and fact are represented.
A new sort option 'SG' was invented for development transactions which orders the displayed transactions primarily by development areas. The order of the development areas is as follows:
Below the development area the data are ordered like sort option 'GK'. In addition, the sort option 'SG' is pre-selected when branching off from the financial statement monitor (EA) or the account balances (KTOSAL).
The applications for forms entry of development transactions now perform a check of the data when starting the application as well as after saving of modifications. In case a list of error and information messages is displayed. However, differences between transaction totals and account balance are not shown since these differences are already visualised by the difference amount in the validation line. But now e.g. a difference between fixed asset transactions in the development column for current depreciations and the corresponding p&l account balances is reported if you branch off from the forms entry monitor (I-EA) into the forms entry application and thus explains the status [yellow].
For fixed asset objects disposing over the cast of the year (entry of a selling date) now depreciations are calculated until the disposal date and in case postings are generated. These postings or transactions, respectively, are maintained at carry-forward over the cast of the year even after the disposal date and have to be eliminated like production costs.
When transferring company financial data to the next fact amongst others balances and postings are comprehended to a new balance. For easier analysis of the origin of the data now the voucher number of the processed postings is stored in the balances origin-lists and displayed in the corresponding list applications (KTOHER, KSTHER).
The currency conversion of a company with business units now can be performed even if the total balance of the account with account flag 'U' over all business units does not result in zero.
When displaying group companies in the applications KTKDEF or KTKGES the number of companies per IDL.KONSIS classification (see above) is compared to the corresponding entry with the licence file. If the number of companies of one type exceeds the licenced number then a corresponding information message is reported.
However, a restriction of the consolidation functionality due to the specified classification of the companies is not performed for the time being but will be supplemented in one of the next versions. Therefore it is strongly recommended to specify a correct classification already now.
If you selected several sub-groups or companies in the group structure table of the application "Group definition" (KTKDEF) intending to copy them to another group in one step, then now sub-groups or companies, respectively, already allocated to the destination group companies are automatically deselected and reported, however, all other data are inserted. Up to now in this case the action had been completely aborted.
A function "mass-update" was supplemented in the list application "Consolidation parameters" (KTKPAR). However, this function can only be applied to uniform parameters. Therefore it is presupposed that a unique consolidation function / voucher classification has been entered in the selection area. Possible use cases are:
As a consequence from this enhancement now the consolidation parameter 'FK' is no longer displayed when selecting the consolidation function 'KK' as well as consolidation parameter 'EN' when selecting 'EF'.
The "Automat for Consolidation Functions" was arranged more clearly and refreshed by the following actions:
For fixed asset objects disposing over the cast of the year (entry of a selling date) now depreciations are calculated until the disposal date and in case postings are generated. These postings are maintained at carry-forward over the cast of the year even after the disposal date and have to be eliminated like production costs.
For better retrace of possible problem constellations the table of group processing controls (KVERARB) contains a column which specifies with which IDL.KONSIS.FORECAST version the most recent modification has been performed. This version information is now provided by all relevant processing programs.
Check rules now can be defined for inventories IC-stocks (ICVOR), too. For this purpose the new data type 'V' has to be specified in the check rules / positions (applications PRFDEF or PRFPOS).
In the same way now check rules can be defined for shareholding transactions (GESGES). For this purpose the new data type 'B' has to be specified.
Analogously to the account master data (see above) now both new attributes "IC details" and "Validation of IC details" can be specified in the check rules / positions (PRFDEF or PRFPOS) instead of the previous "IC account flag". Existing data are converted correspondingly.
You have now the ability to release faulty check rule results manually, i.e. to set them to the status [green]. This is especially helpful if there are reasonable exceptions for fulfilment of the check rule, e.g. a carry-forward check for a company new in the group companies and therefore without data in the previous period.
A manual release is granted by a correspondingly named action in the context menu of the check rule result lists (PRFERG and PRFERGK). In addition, there is another function to revoke a manual release. The corresponding menu IDs PRFERGREL and PRFERGREV can be authorised separately. By standard the authorisation is granted only to the user groups IDLADMIN and IDLKON.
A manually released check rule result is displayed with a corresponding icon (hand icon) or with colour [green] and the character 'M' when displaying coloured status cells in the check rule result list. When revoking a manual release then the status is set to "faulty" again.
If, after a manual release, no faulty check rule results are yet present, then the message in the processing control record (VERARB or KVERARB, respectively) is set to "manually released", too. Even the status of the monitor applications (EA or KTKGES, respectively) then shows the hand icon or the letter 'M', respectively.
If the check rule result calculation is repeated after a manual release, then the status "manually released" remains as far as the amounts of the left and the right hand side of the check rule are identical to the amounts stored in the check rule result.
If there are no applicable check rules for a company or a group, then the check rule result status displayed in the monitor applications (EA, KTKGES) is set to [-]. In addition, the check rule result lists (PRFERG, PRFERGK) do not display any results. Reasons for none-applicability are:
The check rule result analysis now represents data on accounts for statistical quantities as well as calculated ratios always without debit/credit flag. Thus seeming differences because of different debit/credit flags are omitted.
Since the former IC account flag 'J' has been disposed (see above) several descriptions and message texts had to be renamed. In addition, now new icons instead of the icons with the letter 'J' have been introduced.
The check for a negative third party share on intercompany accounts (IC details 'I') without account balance check (validation of IC details '-') was removed from the planner spreadsheet checks since it is admissible here.
The financing rule now considers the IC details of statistical accounts for the financing amount at calculation of interest rates and financing duration. Thus no longer several statistical accounts are required for loans from different intercompanies.
Within a financing rule now a "loan rule" can be defined, too. For this purpose you have to set a new flag in the financing rule to "Rule for lender" (instead of "Rule for borrower"). Then a uniform item is represented from the lender's point of view, i.e. the debit/credit flags are interchanged compared to the financing rule from the borrower's point of view. In addition, the descriptions for liabilities and interest expenses are replaced by receivables and interest income.
The transfer rule was extended by functions which allow for a separated reposting of debit or credit amounts, respectively, and thus provide for an exact differentiation for a cash flow report. This is performed by activation of the new flag "with D/C control" and the separated entry of destination accounts for debit or credit amounts. If a balance shall not be reposted for a certain debit/credit flag then the account entry for this debit/credit flag can be omitted. In addition, there is a new page "Advanced settings" in the wizard of the rule where threshold amounts can be specified. Then only the portions above this threshold amount, incl. consideration of the reposting factor, are reposted. Moreover it can be controlled that the reposted amounts are posted back in the subsequent period providing for a reposting of accumulated values. This is the default setting, too.
Besides explicit amounts and references to statistical accounts parameters can be used in IDL.FORECAST rules. A new function for the administration of these parameters or their values, respectively, now has been created and replaces the former maintenance function. Existing parameters are converted into the new structure by the scenario migration.
Parameters are now represented in a time scale. I.e. you can see the explicit parameter value for e.g. each month of the scenario. Thus changes of the parameter value are always performed separately per period. However, you have the possibility to declare a parameter not as "Single value" but rather as "Forward", then it is automatically applied for all subsequent periods.
However, deviating parameter values for single companies still have to be defined per company separately. Parameters can be transferred from other scenarios, too. Then they completely overwrite existing parameters with the same name. The usage of parameters for a seasonal distribution to the months of a year yet will be supported in one of the following versions.
The business cases of a template are now displayed ordered by fact and period. Within this the facts are ordered with respect to their order within the scenario, periods are ordered chronologically. Up to now the order was alphabetical with respect to the displayed texts.
Amounts are now displayed in complete length in the window for account changes. In case a scroll bar has to be used for display of the other contents of the line (description of the change, icons).
The Forecast formulae SAL, IC, CNT and POS now can be combined with each other, e.g. as a total like "SUM(SAL(..);IC(..);CNT(..);POS(..))" or in condition formulae like "WHEN(SAL(..)>0;POS(..);IC(..)". However, the formulae MSAL and MIC continue to be not usable in combined expressions.
Numerical constants in formulae now can be specified with as many decimal digits as it is technically possible. However, the result of the formula as well as general amounts continue to be in the format of currency amounts (with a maximum of 13 digits before and two digits after the comma). I.e. you can specify amounts with more decimal places in the formula field but not as a balance or an amount in a cell.
When exporting a table sheet then the period structure of the exporting scenario is exported along. If the period structure of the importing scenario is agreeing (identical number and dissolution of actual, forecast and plan years) the references to periods and facts are looked for and replaced by their counterpart in the destination scenario. This is committed by a message after successful import. Sometimes this message also contains a summary about which periods / facts are mapped to which new periods / facts. If the period structure does not agree then no replacement is performed which cannot be recognised outside the formulae.
If the table sheet uses cell references for periods and facts in the formulae then these are not mapped. They are only mapped if period and fact are specified explicitly in a formula. The reason for this behaviour is that arbitrary entries looking like periods and facts in cells cannot be safely replaced because always the combination of period and fact has to be replaced which cannot be recognised outside of formulae.
Error messages in the formulae were further differentiated and designed more meaningful. Additional information of the error can be viewed in the tool tip of the cell.
Caused by an error in the application "Controlling definition" (CTLDEF) new controlling flags 1 did not yield an automatic allocation to a report column and thus could not be referenced in a column definition for a controlling report by the function of expense method.
Please note: The allocated columns can be displayed with the aid of the view option "Display internal info columns". If entries already are missing there these can be supplemented by an update on this record.
The application formula editor (FED) now yet serves only for the definition of ratios. You still can view the formula definitions of report column options, however, a branch off into the single record application (FEDE) is no longer possible. For update of formulae of report column options now you can use only the application "Report column options" (SPADEF).
The action "Display list" in the calling application "Import" (IMPORT) is now available for the data objects "Fact sequences", "Posting key groupings" and (again) "Controlling objects".
The import/export formats were adjusted to the current database extensions (amongst other company master data, see above).
The import/export format of accounts was extended by the field "Validation of IC details" (see above). The field "IC details" is to be used instead of the former field "IC account flag". If only the IC detail is specified in the import data, then the validation of IC details is supplemented due to the previous IC account flags. Correspondingly a 'J' is converted into 'I' and 'A'.
The import/export format for intercompany account balances (see above) was extended by a four digit field for the clearing flag. The previous two digit field can continued to be used for clearing flags up to 99 but is just limited to two digits.
Besides the "IC detail" (up to now "IC account flag") you can now specify the "Validation of IC details" for a range of account numbers in the "Account groups" (KTOGRP). Data already existing are converted with respect to the former IC account flag.
The foreign keys between the import/export job tables (I001, I005) and the user table (A016) were removed. I.e. a user can be deleted from the user table even if import/export jobs are defined with his user ID.
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.
Just like other applications the table of MIS parameters in the application MISPAR now displays a column showing whether a comment (help text) is defined for a parameter.
From Release 2016 on IDL offers a standard interface named "IDL Smart Connectivity for SAP" for the transfer of data relevant for consolidation from SAP to IDL.KONSIS. This interface is based on the Netweaver technology and thus on the most recent technology for unloading of data from SAP. IDL Smart Connectivity for SAP is available for the old general ledger as well as for the new general ledger. It is a proprietary development of IDL which allows our customers the highest flexibility and extensive automation of the transfer of structure (chart of accounts, companies, ...) and transactional data (account balances, intercompany balances, development transactions, ...) in interaction with the Microsoft Integration Services. Within this it is assured that the SAP system guidelines with respect to authorisations and CTS (Change and Transport System) are followed completely.
The solution has been certified by SAP.
Of course, Interfaces from SAP to IDL.KONSIS realised in the past at our customers which were implemented based on IDL.IMPORTER and SAP Connectivity can be used continuously. We emphasize our customers to check for migration to IDL Smart Connectivity for SAP.
If you are interested in the new SAP interface please contact the IDL hotline or your contact person in the IDL sales.
The Release 2018 Update 1 contains the current edition of the DCW interface for DCW release 3.50.