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 has to be invoked once to satisfy the check for consistency of the release versions. For Release 2021 Update 1 it performs the following transformations in the database for IDL.KONSIS:
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.
No menu IDs are deactivated with this release.
The following menu IDs are deleted with this release. Please remove all individual usages of these menu IDs (authorisations, menu structures) before installation of Release 2021 Update 1:
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.
If you select a very large amount of data records (several 100.000) it may happen, that internal memory areas overflow and a technical error message ("Heap error") is issued after several minutes of waiting and no data are displayed. Therefore the expected memory demand is now calculated in advance and in case a warning message is output. You can ignore this warning by pressing the <OK> button accepting the risk to get the error pattern described above. Alternatively you can abort the operation by pressing <Cancel>.
In complex master data applications ("DEF" applications with leading and dependent table) it is now possible to select several lines of the leading table and to delete the according data. Except for foreign key violations in the database the deletion will be continued after errors.
The column "Role" was supplemented in the table for companies. This item is required for country-by-country reporting and thus allows for the following predefined values:
The application "Companies" (GES) provides for the maintenance possibility on page 4 (Judicial properties) of the wizard.
When copying an account you are asked whether the position/account allocations of the source account shall be copied along. However, this co-copying does not work if the newly generated copy is copied itself without saving the modification in the meantime. Therefore in this case now a message is output indicating that copy is only possible after the modifications performed up to now are previously saved.
It was supplemented for the function "Export to Excel" in the application "Chart of position definition" (POSDEF) that the table "Allocations (Acc/Pos)" now can be exported, too.
Since Release 2019 check sums for all selected companies are displayed as a block after the selected data. However, in case check sums were displayed for all companies (of a sub-group) although there were data only for a few companies, e.g. after branching off from the group monitor (KTKGES) into the shareholding transactions where only a restriction by intercompany is triggered (company = '%'). Now check sums are only displayed for those companies for which data are displayed.
The response time of the company financial statements monitor (EA) was reduced by optimisation of the determination of currency codes. The effect is significant at a large number of companies.
If an account is allocated to a position with deviating b/s p&l code (e.g. an income account allocated to an expenses position), it was not evident for the user whether the amount had to be entered as a positive or as a negative value. Therefore now an additional column with a debit/credit code is output which is derived from the b/s p&l code of the position. This representation corresponds to the Excel entry form.
After appropriate configuration the "Drill through" function allows for the display of the original data in the ERP system which lead to the (accumulated) account or intercompany account balances, respectively, in IDL.KONSIS. This function now allows for the print and export of the displayed data, too.
The list "Vouchers" (BEL) now offers a new function to eliminate a voucher. This function generates a new voucher (elimination voucher) which 1:1 reverts each posting of the original voucher. Exceptions:
The elimination voucher obtains the same voucher number as the original voucher with an appended '#'. For this reason vouchers with a 14-digit voucher number as well as vouchers with '#' as the last digit of the voucher number cannot be eliminated. The carry-forward function recognises the relation of both vouchers by the appended '#', too, and comprehends both vouchers to one carry-forward voucher, which usually (for exceptions see next paragraph) contains only zero amounts. If both vouchers shall not be carried forward at all, then the flag "Accumulation of carried forward" in the single record application BELE has to be set.
However, if a voucher formerly result effective and already carried forward is eliminated, the user has to take a manual action to replace the account for retained earnings by suitable p&l accounts, since an elimination of the retained earnings is contentually not correct. Then a complete aggregation of both accounts is not possible in the first period after elimination since this result effect has to be reposted to the account for retained earnings at first.
If intercompany account balances are present with specification of reference voucher number and date then up to now only data with agreement in both fields were cleared. In addition, now data are cleared, too, if only either the reference voucher number or the reference voucher date agrees. Depending on the kind of the data the number of automatically cleared intercompany balances can be increased significantly.
With Release 2020 Update 1 it had been introduced that modification on intercompany account balances which had taken place after already performed an IC reconciliation provide for a [yellow] IC clearing state in the list EGESGES. However, if several users simultaneously performed modifications on intercompany account balances, then competing accesses to the database could happen which provided for mutual blockings. Therefore the modifications from Release 2020 Update 1 were reverted for the time being.
The state of currency conversion is automatically set to [red] (yet to be performed) if an amount in local currency is changed in any of the company financial statement data to be converted. However, this control was not sufficient if the calculation of depreciations (on IC fixed asset transactions or postings carried forward) was repeated and resulted in the same amount in local currency. Then the status of currency conversion remained [green] although the amounts in group and parallel currency were not yet calculated and therefore zero. Therefore now the status of currency conversion is set to [red] if an amount in group or parallel currency is modified except for modifications by the currency conversion itself.
Different functions of consolidation were optimised so that some of them now provide for a shorter response time especially at a large number of group companies. Amongst others this concerns
For postings of deferred taxes on minority interests ('FF' consolidation vouchers) carried forward the voucher classification 'FF..L' has been supplemented in the KVA table. Specifications for this voucher classification were supplemented in the "Lieferbatch" file for consolidation reports, too.
Participations held by companies consolidated at equity are no longer considered at calculation of shareholding percentages.
When copying a consolidation voucher there is now an additional flag controlling whether the voucher shall be copied 1:1 (entry 'K') like up to now or the copy shall provide for the elimination of the original voucher (entry 'S', copy with interchanged debit and credit amounts). Opposite to the ordinary copy function the key group/sub-group has to be specified deviant from the origin. The following particularities are performed:
Please mind that vouchers with these keys can be generated by consolidation functions, too (except for manual vouchers 'MB...'). Then the elimination voucher would be overwritten.
The display of an extensive report (e.g. cash flow report) with several thousands of lines is now performed in significant shorter time.
In the mirrored report display with positions in columns, which is especially used for the representation of the capital development, now the data of the previous period are displayed at first and the data of the actual period afterwards. This representation is mandatory due to IFRS and DRS.
The column "Role" was supplemented in the import/export format for companies (see above).
Postings automatically generated by IDL.KONSIS now are designated as comment line by the export and ignored by the import function since they are newly generated after import anyway and provided with additional information (specified in "Source"). This concerns the postings for the result (account flag 'E' and posting key usage flag 'JU') as well as postings for the compensation of differences between business units (account flag 'U'). This was already applying for the import of result postings.
The runtime of the import of report line descriptions was significantly reduced, especially at a large number of report lines per report.
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.
For improvement of performance some database views have been persisted in the database.
The attribute "Role" (see above) for country-by-country reporting was supplemented in the view OLAP_DIM_Company.
The column K049_SEGMENT_KNZ (flag whether a consolidation posting is intrasegmentary or intersegmentary) which already was contained in the view OLAP_POSTINGS_VOUCHER was supplemented in the following views, too: