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 does not perform any transformations in the database for IDL.KONSIS since the conversion of the consolidation function keys is already performed during release installation (see below). However, it has to be invoked once to satisfy the check for consistency of the release versions.
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. As a consequence scenarios which had been created with Release 2016 Update 1 or an even elder version and were not converted since this time no longer can be converted to the current version. These scenarios are designated now with "not convertible, please delete".
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.
As announced in previous versions the following menu idents are finally deleted with this Release 2020. Please assure before installation of this Release 2020 that no individual references (authorisations, individual menu structures, automate controls) are yet defined on these menu idents!
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.
Now the last name and the first name of a user are taken from the entries in the Active Directory (AD) if a user is automatically created in IDL.KONSIS.FORECAST based on a user in the AD and a template user in IDL.KONSIS.FORECAST. This way users can be identified in the IDL.KONSIS.FORECAST user list even when using technical keys.
The tool "batchrunner" serves for the remote call of single Konsis functions, e.g. via command line. The new menu ID "BATCHAUTOM" allows for an automatic sequence of an automate control issuing an external call of the program "batchrunner". In the command line of the "batchrunner" call "BATCHAUTOM" has to be specified in the parameter /start and, in addition, the proper menu ID of the automate control has to specified as parameter /AUTO_MENID. It is new now that the automate control may contain import applications, too, besides processing functions.
Now in the lower right corner of the application window a new icon appears allowing for the opportunity to download and view news on products and features provided by IDL. The news displayed in the following window usually contain a link to more extensive information on the IDL website. Prerequisites for this function are on the one hand, that it had been activated in the options dialogue (page "Common") which is the default setting, and on the other hand, that an internet connection is available (in case to be configured in the options dialogue, too).
The window for licence information was provided with a scroll bar so that the complete content can be viewed even on screens with very limited resolution.
Error messages with respect to missing authorisation now explicitly name the action (display, update, insert, delete, copy) instead of an action number.
If you change the file name when saving an Excel file created by the Excel export function, then now automatically the correct file type is appended as suffix (e.g. '.xlsx') to the file name as far as it had been removed in the file dialogue.
For Release 2020 the KVA key (KVA = voucher classification / consolidation function) was extended and in doing so a reconstruction of the consolidation voucher number was performed. Essential arguments for this project were
Part one of this reconstruction is the extension of the proper KVA key from up to now two digits to six digits in the future. These six digits are subdivided as follows:
By preservation of the basic KVA key in the first two places the familiar nomenclature is sustained to a great extent. By the two digit number for individually defined reconciliation groups their possible quantity is significantly increased. By the separate key parts for deferred taxes and carry forward it is easier to select consolidation postings for a basic KVA including their deferred taxes and/or carry forward postings.
Please mind the following particularities:
Part 2 of the reconstruction is the extension of the consolidation voucher numbers from up to now 14 digits to now 20 digits. From now on the voucher number is constituted out of the following seven parts:
The sequence number in the two final places is used in those cases where IDL had provided the corresponding KVA keys within the delivered meta data for the case that these keys were required. This concerns
By the fact that these sequence numbers are no longer part of the KVA key but only part of the voucher number many data records defined in the KVA table up to now with identical attributes are no longer required.
Please mind that the concerned KVA keys ('KK', 'FK', 'EK', 'PM', 'PP', 'PA' und 'PT') principally are provided with a sequence number in the voucher numbers. I.e. e.g. the first voucher for a capital consolidation is provided with 'KK....00' from place 13 on. The conversion provides for the preservation of the correct order of the voucher numbers:
Thus now the vouchers are displayed in the correct chronological order (up to now always alphabetical, i.e. 'K0' to 'K9' prior to 'KK').
The release installation provides for the conversion of nearly all existing KVA keys and voucher numbers to the new nomenclature using SQL scripts, since a conversion using the Release migration program would provide for unacceptable runtimes. Even the SQL conversion requires some time, up to about one hour depending on the size of the database.
Please mind that this SQL conversion cannot provide for a detailed error handling and logging as the migration program. A database backup before Release upgrade is already always seriously recommended by IDL, but this time it is indispensable.
The KVA key is converted in the following tables:
The consolidation voucher number is converted in the following tables:
In addition, the former KVA keys (places 13 and 14 of the old voucher number) are written into a new column (visible only as internal info column) providing that the old voucher number always can be reconstructed for purposes of revision.
Furthermore a new choice object 'KV1' was introduced, which is used in all places where not the six-digit KVA key but rather the two-digit basic KVA is needed. This object is used in the following tables:
Not converted are KVA keys or voucher numbers, respectively, in the following tables:
The concerned interfaces for import to Konsis were extended as far as required. Please mind:
Reading of data from the IDL.KONSIS database should work like up to now as far as
Otherwise an individual adjustment of the queries has to be performed. This applies for IDL.XLSLINK queries, too.
Branching off from other list applications into master data applications now generally leads into the new master data applications with wizard (e.g. KTODEF) and no longer into the old applications with selection area and single record application (e.g. KTO). Then parameters specified in the calling application (e.g. account number) provide for opening of the model (e.g. chart of accounts) and positioning on the respective line of the table.
In complex master data applications (with one leading and one or more dependent tables) conflicts of two users simultaneously modifying the same model are avoided by a lock mechanism. To avoid unnecessary waiting times for a user before he can open the model now there is the ability to open a model only for reading. Then no actions modifying data are possible and no lock for other users is set. The corresponding icon in the context menu of the leading table shows an eye and a small padlock.
The fact master data (FAC) were extended by a flag "IC specification for dev. transaction required". If this flag is set, development transactions on completely checked intercompany accounts have to be provided with an intercompany (see below).
A new licence component has been introduced for "Country-by-country reporting". Without this licence the page "Business activities" (page 5 of the wizard) no longer can be accessed.
As a medium-term goal of IDL.KONSIS transaction developments with sample accounting no longer will be supported. As a first measure now the specification of new transaction developments with sample accounting is not allowed anymore. Alternatively transaction developments with several development areas can be defined.
According to the new nomenclature of consolidation functions (see above) the posting key usage tag 'XZA' was renamed into 'XTA'.
The tables "Positions" and "Allocations (Pos/Acc)" are now synchronised. I.e. the selection of a position in the table "Positions" provides that this position is selected in the table "Allocations (Pos/Acc)", too, and vice versa.
After opening a model (chart of positions) now another registry tab "Allocations (Acc/Pos)" is displayed. Like "Alloctions (Pos/Acc)" the table of this registry tab shows the position/account allocations, however, ordered by account number. The representation is not in tree structure but rather as a flat table since this offers improved filter and sorting possibilities. Modifications are possible in this view by editing in the table, however, there is no drag&drop function for definition of new allocations.
The resource table of accounts allocatable to positions in addition now shows the IC details check and the consolidation function (KVA, reconciliation group) of the accounts in additional columns providing that a filter can be set for these columns.
In connection with submission monitoring per data stock as well as independent from this it is now possible to lock single data stocks (columns in the company financial statement monitor (EA)) just like it already had been realised for intercompany account balances. If a data stock is locked then this is visualised in the company financial statement monitor by the padlock icon in an additional column beneath the status of the respective data stock. After revoking the lock the icon for an opened padlock is displayed.
The information about the lock is stored in additional data records (check points) of the processing control (VERARB). The naming convention of these check points is "EA" + application abbreviation for unique data stocks (e.g. "EAKTO" for account balances) or "EA-" + transaction development key for development transactions (e.g. "EA-A" for fixed asset transactions), respectively.
The setting or revoking of the locks is performed in the monitor using the new sub-menus "Lock" or "Unlock", respectively, or in the respective list and forms entry applications using new entries in the context or action menu. It is prerequisite that the company and, in case, the transaction development are uniquely specified in the selection area. However, locking of development transactions by the actions in the company financial statement monitor always affects all developments of the respective type simultaneously.
As far as the current fact is part of a fact sequence the lock is set (is inherited) for all facts defined upstream of the current fact in the fact sequence, too.
If a data stock is locked, then the forms entry applications do not offer any entry possibility. Therefore the amounts are displayed in grey colour. In the list applications a message in the selection area points out that the data stock is locked.
The locks of single data stocks are checked by all programs which modify these data (carry forward, transfer, generation and delete functions, etc.) and evaluated like the lock of the complete company financial statement. Excepted from this check is the currency conversion since here only amounts in group and parallel currency are modified.
However, the status display for a single data stock can change despite of a set lock since the status depends on the consistency between different data stocks, too.
Sub-menus for lock and unlock of single data stocks were supplemented in the action menu. As far as single data stocks are locked or unlocked, this will be displayed in additional columns (see above).
In the application ABG submission dates now can be defined differentiated per company. Then submission dates with company are evaluated prior to submission dates without company (display with text "All"). The latter apply only for companies without specification of an individual submission date.
A submission date for a company with checkpoint "All" has priority over a submission date for the company "All". Thus the submission date for a company and a checkpoint is determined using the following priority list:
Actions for Lock and Unlock of the data stocks currently displayed were supplemented in the action menus of the list and forms entry applications. If a data stock is locked then no entries are possible in the corresponding forms entry application. A message in the selection area points out to the lock of the displayed data in list applications. (see above)
The display of a great number of intercompany account balances was significantly accelerated by reduction of database accesses.
Up to now only a check for consistency with the account balances was performed for checked but not balance relevant development areas. In addition, now a check for consistency with the intercompany account balances is performed as far as the account has intercompany details.
Using a new flag for the fact (see above) you now can control that the specification of an intercompany is required for development transaction on completely checked intercompany accounts. This is checked when entering development transactions (single record, forms entry, import). Furthermore missing entries are reported in the list applications as well as in the company financial statement monitor (EA) by a [red] status. Without setting of this flag the check is performed like up to now: If transactions with IC specifications exist then they have to be complete. If there is no transaction with IC specification then no error is reported.
The priority of messages with respect to different data constellations to be stored in the voucher header was revised. Generally error messages obtain a higher priority than warnings and warnings a higher priority than notes.
The automatic setting of the clearing flag of intercompany account balances for a couple of companies was now extended for the case that a voucher number as well as a voucher date had been transferred from the preceding system. If the comparison of the amounts per voucher number exhibits differences as well as the comparison of the amounts per voucher date, then in a further step it is checked whether the clearing flag can be set for intercompany account balances with agreement of voucher number and voucher date.
The application "Voucher classifications / consolidation functions" (KVA) was adjusted to the enhancements of the KVA key (see above). Especially the parts of the key (basic consolidation function, reconciliation group, flags for deferred taxes or carry forward, respectively) are displayed in separate columns in the table and in separate entry fields in the wizard.
While most of the data displayed here continue to be supplied by IDL as a standard individual KVA keys for the basic consolidation functions 'AE' (consolidation I&E), 'SK' (consolidation D&C) and 'MB' (manual vouchers) can be created and maintained as usual. Please mind the following differences to the nomenclature up to now:
KVA keys which only served for a subsequent key for otherwise identical items (e.g. 'K0', 'K1' etc. for 'KK') are no longer defined as KVA keys on their own and were therefore dropped.
When starting the application "Group monitor" as well as after saving of modifications in the application "Group definition" the check and refresh of the participations is automatically performed providing for actual data for the displayed shareholding percentages. This is now yet performed only for real groups but no longer for report sub-groups.
Now a status for the performed carry forward function is displayed for companies merged in the previous period although these companies are defined with consolidation method 'K' (no consolidation).
The keys of the IC clearing list were adjusted to the new nomenclature of the KVA key (see above), too. Except for 'SD' the keys used here are all four-digit consisting of the basic consolidation function ('SK' or 'AE') and the two-digit number of the reconciliation group ('00' to '99').
All consolidation functions were adjusted to the new nomenclature of the consolidation voucher numbers (see above). This concerns the processed as well as the generated consolidation vouchers.
Consolidation vouchers of capital consolidation ('KK', 'FK', 'EK') now are principally provided with a sequence number as the final two places of the now 20-digit consolidation voucher number (see above). Each first voucher is provided with the sequence number '00'.
The display of the list "Compensation temporary difference from first consolidation" was significantly accelerated by optimisation of database accesses.
Consolidation vouchers for merger which can occur multiply at simultaneous merger of several companies to the same incorporating company ('PP', 'PM', 'PA', 'PT') now are principally provided with a sequence number as the final two places of the now 20-digit consolidation voucher number (see above). Each first voucher is provided with the sequence number '00'.
The consolidation voucher number was extended from 14 to up to 20 digits (see above). Existing consolidation vouchers and postings are automatically converted to the new nomenclature. New vouchers are generated with the new nomenclature by the respective consolidation function.
As far as the previous consolidation voucher number is required again, e.g. required by revision, the previous KVA key (places 13 to 14 of the old consolidation voucher number) can be displayed in a new column (visible only with view option "Show internal columns").
Now seven entry fields serve for selection of consolidation postings and vouchers per voucher number in the list applications KONBEL and KONBUCH as well as for entry of a new consolidation voucher:
The latter four fields may be used or empty depending on the circumstances. Therefore the selection of these parts allows for the entry of '*' for selection of data where this part of the voucher number is empty (e.g. exclusion of carry-forward vouchers).
Here as well as in other list applications with display of consolidation voucher numbers the representation is in different columns which receive the common header "Voucher number".
The priority of messages with respect to different data constellations to be stored in the voucher header was revised. Generally error messages obtain a higher priority than warnings and warnings a higher priority than notes.
The display of data in the check rule result analysis list was accelerated. This especially applies for the usage of the clause "per account" in connection with very large charts of accounts.
Now additional descriptions are output in the lines of the check rule result analysis list. This especially concerns descriptions for transaction development areas, transaction development columns or posting keys at check rules for development transactions.
At automatic generation of postings or consolidation postings for current depreciations postings for current depreciation already existing now are deleted if they do not specify a fixed asset object. Amongst others this is helpful if the function "Copy group postings for sub-group report" (REPKTK) is combined with the transfer to another fact with a deviant chart of accounts so that the original fixed asset objects could not be maintained but rather had to be supplemented manually, which, however, was not possible for automatically generated depreciation postings.
The response time behaviour of IDL.FORECAST was improved by different measures.
Scenarios which had been created with Release 2016 Update 1 or an even older version and had not been converted since that time, no longer can be converted to the current version. These scenarios are provided with "not convertible, please delete".
If one company of a scenario is write-protected or the authorisation for changing the scenario is missing, then this company is no longer locked. I.e. other users are able to open, modify or delete this company of the scenario.
The dissolution settings are now displayed in the scenario properties.
The new action "Open in scenario wizard ..." was supplemented in the context menu of the scenario list for the purpose to copy a scenario and particularly adjust the periods. Then the wizard opens and the scenario is displayed with all of its properties. On the page "Select Data Areas" there is now the new possibility to set all specified periods back or forth for one year. However, individual table sheets and parameters are not transferred and thus in case have to be imported manually.
For copied scenarios it is now preserved and displayed at which time and from which other scenario it had been copied. For scenarios already copied before this extension only the copy date but not the source can be displayed.
If a scenario is locked for the selected company now nevertheless it is possible to view and even to modify the profiles defined for copying or splashing of balances.
The maintenance of planning parameters now requires an authorisation. On the one hand the authorisation for the company and the respective action has to be present, on the other hand generally the authorisation for the menu item "PLANPARA' has to be granted.
After refresh of the table now the previous expansion state of the columns is preserved. Up to now this only applied for columns.
In scenarios with the same year shared between the data areas ACTUAL and FORECAST and even selected for the data area PLAN now the annual totals are correctly calculated.
The transfer from the data area FORECAST to the data area PLAN now is always performed automatically if it is defined in the scenario that rules shall effect data-area comprehensive. The execution of this transfer by manual action or within a Forecast sequence is no longer possible. However, the transfer from the data area ACTUAL continues to be started manually.
The displays "Balance differences" and "Plausibility check" now display the debit/credit flag in a separate column providing for an easier subsequent processing in Excel.
The wizard for single vouchers was redesigned and enlarged.
If data stocks (account balances, intercompany account balances, controlling balances) are locked (see above), then they even cannot be refreshed by planned data.
A new icon (magnifying glass) was supplemented in the tool bar of the rule template tree. It serves for a search in the rule templates. This search can be referred to accounts, parameters, companies (company control), business units (company control), intercompanies (IC control), IC business units (IC control), names of the rule templates or comments. However, only results are displayed for which the user has at least display authorisation. You can open the rule template directly from the result list, either using the context menu or by a double mouse click, as far as a scenario is opened.
Sales, income, purchases and expenses rules now support the distribution of a source balance to different destination accounts. For this purpose like in the transition rule additional allocations can be added which each transfer a percentage to be specified of the source amount to the respective destination account. The percentages must not be negative and have to result in a total of 100%. Tax account as well as tax rate can be specified individually per allocation, too, if sales tax or input tax, respectively, are activated for the rule. The settings for payment, tax dissolution, general allowance (sales rule) and security deposit (purchases rule) cannot be specified per allocation, however, in case they mind the respective destination and tax account. Rounding differences are prevented.
A find function on the respective wizard pages was supplemented in all rules with a function for allocation of accounts. There you can search for account numbers, account descriptions and parameters: The accounts found by the find function are designated by a blue frame and the display is positioned to the first one of them. An icon beneath the find field allows for a jump of the display to the next place of recovery.
All rules with payment or dissolution components and specification of percentages in parameters or statistical accounts now can be easily recalculated if the entries in the parameters or statistical accounts were modified. Up to now the rules had to be deleted and then applied again.
A black box on the company level on the company control page of the rule wizards now points out that business units had been selected below the level of companies.
The procedure to restrict a company control to companies and business units was redesigned providing that the effect of the control is unique.
The function "Display" in the context menu of the table storage window was replaced by the actions "Activate" or "Deactivate", respectively, depending on its current state. When deactivating a table the 'M' formulae changes are deleted but restored again when activating the table.
Individual tables now can be restricted to a subset of companies, too. For this purpose a company control was supplemented, similar to rule templates.
The table storage window was extended by a column where information about the defined company control is displayed.
The function "Configure table sheet" now always can be called, i.e. even if the current company is not selectable in the company control of the table.
Changes generated by 'M' formulae in individual table sheets are no longer treated and displayed like manual changes. E.g. they cannot be unlocked and deleted in the account details display, however, they are deleted along when deleting the table sheet. Changes whose formula had been deleted at work with another company of this scenario are automatically deleted when opening a company.
Period specifications in formulae now can contain placeholders. Here 'Q1', 'Q2', 'Q3' and 'Q4' replace the month number for the respective quarter while 'J' means the complete year. The result is always the total of all contained periods. However, placeholders do not work in combination with cell references.
Numbers and periods in formulae and cell references now are always saved in a unique format (German), but are displayed in the user interface with respect to the format setting of the respective user and can be entered in this format, too.
The status "Balances existing" now becomes [red] (up to now [yellow]) if there are no P&L balances at all. [Green] means that at least one P&L account is present. States of intercompany and controlling balances are no longer represented by this status.
The new status "IC Details" becomes [green] only if all intercompany details are consistent with the account balances. Differences on completely checked intercompany accounts provide for the status [red], negative third party shares on partially checked intercompany accounts for status [yellow]. The status remains [?] until the first status check while [-] means that the scenario is without intercompany planning.
The new status "CNT Details" becomes [green] only if all controlling details are consistent with the account balances. Differences on controlling accounts provide for the status [red]. The status remains [?] until the first status check while [-] means that the scenario is without controlling planning.
Below the table of the Forecast monitor (PM) now an info line is displayed with brief explanations about the faulty states ([red] or [yellow]). In addition, sequence and parameters set for the selected sequence are displayed there.
The resource table of positions which can be added to a report now displays the b/s p&l code of the positions in an additional column providing that a filter for positions can be entered for this column.
The wizard page for restrictions to certain posting keys or transaction development columns now can be increased providing that the selection list then displays more entries.
The restriction of report lines of a cash flow report to certain consolidation functions was rearranged from the reference to a KVA key to the reference to a basic consolidation function (usually the first two digits of the new extended KVA key, see above). Note: This entry can be maintained only by the application REPZEI but not by REPDEF.
The calculation of report check sums, at generation of the report result as well as at display of report results, was adjusted so that the new nomenclature of the consolidation voucher numbers (see above) has no effect. Especially for reports generated with the old nomenclature of the consolidation voucher number the original check sum continues to be calculated providing that the check sum states of the report results remain [green].
The import/export formats were adjusted to the actual database extensions:
The behaviour of the import of master data with respect to the specification of short descriptions (optional or mandatory entry, automatic setting of the first 10 digits of the long description) was adjusted to the behaviour of the corresponding dialogue applications.
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 'SK' and 'AE' consolidation vouchers the program for loading of sub-group data with application of a transformation group serves for the correct order of the company numbers in the voucher number (alphabetically smaller company number first) for the case that the alphabetical order had been modified by the transformation to assure that a repetition of the consolidation function with the loaded data yields the same result. However, if 'SK' or 'AE' consolidation vouchers had been manually created without respecting the correct order of the company numbers in the voucher number it might happen, that two vouchers with the same voucher number resulted. In this case only postings for one of these vouchers were loaded while the postings of the other voucher were lost. Therfore now the correction of the order of the company numbers in the voucher number is performed only if the transformation group provides for the transformation of company numbers at all.
The rules for representation of values as positive or negative amounts depending on the b/s p&l code was revised for the case that the top-most node has the b/s p&l code for statistical amounts ('5'). Now in this case the b/s p&l code of the next sub-ordinate level (e.g. '8' for statistical earnings) is applied for all sub-ordinate levels.
When writing back decumulated amounts on p&l accounts entered in entry forms of IDL.DESIGNER now it is no longer required to transfer zero amounts for values not modified in the respective period. However, since existing data have to be deleted and copied from the previous period before import, the import has to be performed with the function "Delete and import ..." (menu ID 'TXL...').
The Release 2020 contains the final edition of the DCW interface for DCW release 3.50.