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 for Release 2020 Update 1 does not perform any transformations in the database for IDL.KONSIS. However, it has to be invoked once to satisfy the check for consistency of the release versions.
In addition some checks are performed for indication whether the migration to Release 2020 had been finished correctly with respect to the new nomenclature of consolidation functions and voucher numbers.
In addition the migration program now performs modifications for IDL.FORECAST, too, which up to now were performed yet when opening a scenario for the first time.
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 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 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.
When changing a user with licence classification 'F' (Full User) for IDL.KONSIS it is now checked whether this user is the only one with this classification. In case the modification is rejected with an error message to avoid that a user locks himself out from working with IDL.KONSIS.
The entry for the change interval of passwords now can be set to empty again a periodic modification of passwords is no longer desired.
For the automatic definition of new users from the Active Directory based on template users in IDL.KONSIS it is now supported that the template users no longer must be unique with respect to the menu authorisation group if they differ with respect to the data authorisation group.
For entry fields in the selection area or the single record area with a drop down box now a tooltip with the description of a value in case entered there is displayed if the mouse pointer is placed on this field. Up to now the drop down box always had to be opened and the corresponding entry had to be looked for.
The key combinations <CNTL + Up arrow> and <CNTL + Down arrow>, respectively, now can be used to jump to the first or the last line, respectively, of a table.
Mass-export (pdf as well as Excel) now works uniquely with respect to files with the same name already existing:
If an exported table in Excel format is distributed as e-mail directly out of IDL.KONSIS then by standard the file receives the previous file name extended by the specification of the key parameters. Up to now this rule was applied to the direct creation of an Excel file only.
The applications for form entry of company financial statement data or consolidation postings were provided with a filter line. This filter line works like in other application types. Please mind that hidden lines are considered when saving.
If a mseter data application is called as a subseuqent application, e.g. out of the application IMPORT, then now the transferred parameters are evaluated in the way that in case a model is opened and the table is positioned on the respective line.
Drop down boxes of optional entry fields contain the entry "(empty"). This entry now is offered uniquely as the first item in the lists.
At mass-update of accounts in the group chart of account now the display of the company accounts automatically updated along can be suppressed at its first output. Then the collected messages are reported at the end of the action.
The list application "Exchange rates" (WKZWKA) was adjusted to other applications for maintenance of master data with respect to its handling. Thus the manipulation of data is no longer performed by a single record application (WKZWKAE) but rather by a wizard. Editing of data in the table is supported, too.
It is now possible to branch off from the list "Exchange rates" (WKZWKA) into the list "IE job controls" (IEJOB). This is especially helpful if you had transferred exhange rates from ECB and want to control which exchange rates had been processed.
The function for transfer of exchange rates from the ECB was revised in the way that the internet connection now has to be provided by the server instead of the client (see above). As an alternative to the automatic download you can also download the xml file with the exchange rates manually and then let this file be parsed by the IDL.KONSIS function.
The calculation of average exchange rates is now alternatively possible using the procedure applied by the ECB itself for calculation of annual average rates. This procedure calculates the average of all single daily exchange rates.
If in the "IC reconciliation list" (EGESGES, see below) the status for a reconciliation group is displayed [yellow] then now the status for the complete IC reconciliation ('SK' or 'AE', respectively) is displayed [yellow], too.
In the selection box for companies the choice "empty" is no longer offered. Instead of "ALL" is included since a submission date is applied to all companies if no company is specified explicitely.
A double mouse click on a detail status in the forms entry application for account balances (I-KTOSAL) now provides for a branch-off into the forms entry application for detail data (e.g. I-CNTSAL at double muse click on the b/s p&l code) even if the user has only display authorisation for the subsequent application and the entry fields are all locked.
The display of account balances in the list (KTOSAL) or the forms entry (I-KTOSAL) application may take some time if there exists a big number of intercompany account balances since the account balances are compared with the corresponding totals of the intercompany account balances for the display of the status colour in the column "IC account flag". This check is now suppressed if the general status of the intercompany account balances is without errors since in this case the intercompany account balances agree with the account balances per account, too, providing for a faster display.
The application "IC reconciliation list" (EGESGES) now displays the status [yellow] if the intercompany account balances had been changed since the last execution of the IC reconciliation. Within this modifications by import, manual entry or update, deletion, carry forward and transition are considered. Thus the status [yellow] means that the status (per company couple and voucher classification) determined most recently by IC reconciliation is no longer valid.
The handling of the application, especially the wizard, was improved at various points.
Now minority interests an a company not only are eliminated in a 'PG' consolidation voucher at merger of this company but rather are reposted in an 'PF' consolidation voucher.
Thus several 'PF' consolidation vouchers with the same company numbers can arise. Therefore 'PF' consolidation vouchers are provided with a sequence number at the final two places of the voucher number, too.
It is now supported to copy single consolidation postings from one voucher to another. For this purpose entry fields for the voucher number were supplemented in the mass-copy dialogue.
An entry field "Currency fur difference amount in LC" was supplemented in the selection area of the list "Consolidation postings" (KONBUCH). At double mouse click on the status "KLW" in the group monitor (KTKGES) the list "Consolidation postings" is invoked and "Currency for difference amount in LC" = '%' is transferred as parameter providing that all postings with a respective entry are selected. The action "Detail view" (magnifying glass icon) can be used to display the complete voucher to view the postings in their context.
If the posting key defined in a consolidation posting is not allocated to the transaction development of the account defined in this posting now the transaction development in the table is displayed with a [red] background.
The clause "per intercompany" now can be applied to check rules with the data type 'B' (shareholding transactions), too. Amongst others this allows for the definition of a check rule to compare shareholding an fixed asset transactions with respect to the intercompany specifications.
If you branch off by double mouse click on a [red] check rule result status from a monitor application (EA, KTKGES) into the check rule result list, then now the sort and selection option 'F' is pre-selected providing that only check rules with an erroneous result are displayed. However, a double mouse click on a [green] check rule result status like before continues to display all calculated check rule results.
The "LieferBatch" file KVA_SPO.xlsm with definitions for a standard consolidation report was rearranged to the new nomenclature of voucher classifications / consolidation functions (KVA). It uses the IDL.XLSLINK references rearranged accordingly.
Entry fields for a "From period" and a period flag were supplemented in the calling application "Split for group/sub-group report" in the extended mode. If entered the "From period" defines a period interval with respect ot the actual period and the action "Copy group postings for sub-group report" copies the consolidation postings into all periods defined in this interval provided that they have at least the specified period flag ('M' copies into all, 'Q' only into 'Q' and 'J', 'J' only into 'J' periods). In this case the comparison group is no longer a required entry field.
Additionally the action "Copy group structure with sub-groups" was supplemented in the calling application "Split for group/sub-group report". If called the current group structure incl. sub-groups is copied into all periods specified by the entries in "From period", actual period and period type. In case of data already existing in the destination are you are requested whether these data (incl. consolidation vouchers) shall be deleted ahead. This extension is especially useful for plan data.
When branching off into the applications "Import" or "IE job controls", respectively, now only the transferred parameters are pre-selected while e.g. group/sub-group and chart of accounts (up to now read from startup data in addition) remain empty in case. Thus potential problems at subsequent "Delete + Import ..." are avoided.
The list "IE job controls" (IEJOB) no longer displays the columns for date and time of the earliest import since this specification is not evaluated up to now. Furthermore these entries are initialised at update avoiding related error messages.
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.
Now you can specify a deviating fact for determination of the group companies per group on the new page 4 "Mapping fact to group companies"). This indication is stored in the column K808_K011_EX_FAC in the data base table K808. This entry can be evaluated by the IDL Datamart views to use different facts for different groups.
The column K806_REP_TYP in the data base table K806 is now provided with a 'C' if the report indicated in this record is used as a controlling report in IDL.KONSIS. This indication can be evaluated by the IDL Datamart views to provide for controlling details for these reports.
There were some views added and changed for the function of expense method. In some other views new columns and lines were added. However, the main views used for the OLAP interface have not changed.
Except for both webservice methods for creation or execution, respectivley, of import jobs, createOLAPImportJob() and executeImportJob(), now th two new methods createOLAPImportJobWithOption() and executeImportJobWithOption() are available which differ from the prvious methods by the additional parameter ignoreImportWarning (true/false). Using this parameter the behaviour of the import with respect to warings is controlled. Up to now the environment variable IMPORT_WRNING_IGNORE had to be set for this purpose.
The entry of intercompany account balances now completely supports the specification of entries for transaction currency. Up to now the transaction currency was not considered at aggregation of entered data providing for a loss of information.