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 2019 Update 1 does not perform any transformations in the database for IDL.KONSIS. However, it has to be invoked once to fulfil 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.
The migration now can be performed by users allocated to the authorisation group IDLSYS, too.
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 following menu idents are finally deleted with this Release 2019 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.
Messages with respect to the exceedance of licence limits are now reported only by the list application (USE) but no longer by the single record application (USEE).
Temporarily the CBI configuration of user authentication is not available and cannot be selected in the configuration program. It is planned to reactivate this configuration with release 2020.
Wild-card certificates (with '*' as host names) now can be used as certificates.
Since Release 2018 it was possible to specify the column width in the print output with a length between 70 and 255 characters for columns which possibly can be longer than 70 characters (e.g. descriptions of accounts or positions). This length now can be set to values less than 70, too, providing that more other data are contained on one page. The minimum column width is now amounted to 30. The other options for these columns (line feed, cut) are available for smaller column widths, too.
Complex master data applications with a leading and one or more dependant tables now offer the opportunity to display data of several objects of the leading table (e.g. accounts of several charts of accounts, posting keys of several transaction developments) simultaneously and to edit them. For this purpose you have to select several lines in the leading table before triggering the "Open" action (eye icon). This enhancement provides for the following changes:
In Release 2019 this extension was supplemented in the following applications:
If an object of the leading table is copied then all allocated data are copied, too. Within this the request whether help texts shall be copied along is related to the help text of the object of the leading table as well as to help texts of the copied objects of the dependent tables.
The table of facts was extended by an attribute "Reference fact for exchange rates". This attribute can be entered in the wizard of the application FAC on the page "General". The evaluation of this entry is performed within the currency conversion (see below).
In addition the table of facts was extended by an attribute for a "Reference fact for Datamart". This attribute can be entered in the wizard of the application FAC on the page "General", too. The evaluation of this entry is exclusively possible in reporting with IDL.DESIGNER (see below).
The table of companies was extended by an attribute for the tax identification number (TIN). This number is different from the tax number (VAT) already present which is required for the "E-Bilanz" while the TIN can be used for country-by-country reporting. The maintenance of the tax identification number was amended on the page "Judicial properties" of the wizard for company data.
In addition, new for country-by-country reporting are entries of business activities which can be allocated to a company in a special dialogue on a new page "Business activities" and provided with validity intervals. You can select one or more of the values 'CBC501' to 'CBC513' specified by the legislator. The final value 'CBC513' ("Other entity") can be supplemented by an additional free text ("OtherEntityInfo").
Further new entry fields were supplemented on the page "Contact" to obtain complete address data for country-by-country reporting, too: Address type, building identifier, suite identifier, floor identifier, country subentity and district name. The address type is a selection field with one of the following entries:
In addition, there is an entry field "Address free" for an unformatted entry of the address.
All new fields except for the business activities were supplemented in the import/export format of company data (TXTGES), the import table I110, the change log as well as in the group-wide data exchange (KONDAT).
The new fields for country-by-country reporting, especially the entries for business activities, are temporarily available in general. However, IDL reserves to supplement a licence position for these data in the future providing that these data cannot be accessed any more without the corresponding licence.
Messages with respect to exceedance of licence limits at mass-update now are no longer output after each modified data record but rather only at the end of mass-update.
There is a new posting key usage tag 'USV' (description: "Cancel. carry-forward conv. diff profit and loss"). The usage of this usage tag is permitted only posing keys of equity capital transaction development (development type 'K'). Positing keys with this usage tag receive the reservation flag. The "Liefer Batch" files were extended by a corresponding posting key. This new usage tag is used only by the currency conversion (see below).
If you have selected several facts (e.g. '%') or a period interval, respectively, then these keys are displayed beneath each other when specifying the column option 'M'. For the purpose to see these data together on the screen the columns for the attributes of the development areas were moved from the fixed into the scrollable part of the table.
Both applications now evaluate the validity of the development areas. If the validity of a development area does not include a period or does not intersect with the validity of a fact, respectively, then the development area neither may be activated not the type of its activation may be modified. Only the deletion of the allocation is allowed. Allocations already existing which are invalid are designated by the background colour [red].
In addition the flag "Hide data with valid-until entry" of the user's startup data (VOR) is evaluated providing that facts and development areas with entry of a valid-until period are no longer displayed. Excepted are uniquely specified facts.
The period in the selection area of the page for position/account allocations is now an optional entry field. I.e. the period pre-selected there may be removed. In this case all defined position/account allocations independent from their validity, e.g. providing for the ability to display all positions to which an account had been allocated over time using the filter line. Therefore the application "Positions+accounts allocations - periodic display" (POSKTOP) serving for this purpose up to now will be deactivated on one of the next versions.
However, without entry of a period no changes can be performed on the allocations since it would not be unique from which period on the changes should be effective. Though possible is the deletion of data providing for the possibility that data with different validities can be deleted in one step without specification of the respective valid-from period.
When creating an account in a company chart of accounts now the flag "Reposting at carry forward" is always inherited from the allocated group account or the aggregation account, respectively. A manual modification is no longer possible. This inheritance is also performed at modification of the allocated group account or aggregation account, respectively, as well as when changing this flag for the group account.
If an account is provided with a valid-until period now a warning message is output to point out the user that the allocations of this account to positions yield the same valid-until entry and therefore amounts on this account in later periods are missing in reports. Since data are carried forward on this account nevertheless and data entry is permitted in order to repost these carry-forward data some subsequent problems may arise especially for transaction development accounts (see below). Then it is recommended as a measure to deactivate the flags for data entry per period type to omit manual entries for this account and to extend the validity of the account by one year. Then the validities of the position account allocations are automatically extended along.
If an account is copied you have the possibility to copy the position allocations of the original account along. If the validity of the new account is modified when doing so, then now the validity of the new position allocations is modified correspondingly. This especially applies if the validity of the new account is longer than the validity of the original one. Thus it is omitted that the new account is valid in periods where it is not allocated to any position.
The new menu item "Chart of position allocations" was supplemented in the context menu (right mouse key) of the account table. At selection of this menu item a display window opens showing all allocations of the account to positions. Opposite to the branch-off into the application POSDEF by the menu item "Position/account allocations" this display is independent from chart of positions and validity restrictions but does not allow for any modifications.
A new function allows for reading of the exchange rates published by the ECB and transferring them to IDL.KONSIS. This function is invoked by an action in the list application "Exchange rates" (WKZWKA) using the entries for closing date and period relation in the selection area as parameters. The determined data for all currencies defined in the application "Currency codes" (WKZ) are written into the import table (I118) at first and then are loaded into the IDL.KONSIS table (WKZWKA) on the fact specified in WKZWKA using the import application. It is preassumed that the group currency is 'EUR'.
Closing date exchange rates are adopted with the amount published by the ECB, either for the month-end date of the actual period or for the last working day preceding the month-end date since the ECB publishes exchange rates only for working days. If a deviant date had been used this is reported in the log output.
Average exchange rates are calculated by the new function. For this purpose the user is asked to specify the rule to be applied. Variants are:
'MDK' exchange rates (exchange rates average per month) are always determined by the second method.
Average exchange rates cannot be determined if the ECB did not publish exchange rates over the total range of time for a currency.
If a reference fact for exchange rates (see above) is defined for the specified fact then the associated list of exchange rates (WKZWKA) in addition displays the exchange rates of the reference fact and designates them correspondingly. However, for entry of new data the fact for which the exchange rates shall be inserted has to be entered in the selection area.
Exchange rates for closing dates deviating from the month-end of the actual period could already be entered up to now, however, they now can be evaluated by the currency conversion, too (see below). For the check for authorisation for the maintenance of exchange rates for closing dates deviating from the month-end of the actual period now the authorisation for next period defined in ABR is used.
If a double mouse click is performed in a column for development transactions of the company financial statement monitor for data entry (I-EA), i.e. a branch-off into the forms entry application (e.g. I-SPIBEW), then now the monitor application determines all development areas of this development and outputs a dialog window where the user has to select one of the development areas for entry of data. If no development area is selected here the branch-off is performed with the restriction "balance relevant" to work on all balance relevant development areas together. Automatically calculated development areas which do not require a manual maintenance are not offered for selection. The output of this dialogue window is suppressed if only one selection area is selectable.
Data on accounts which are invalid in the actual period may be entered and modified. This provides for the ability to repost existing (e.g. carried forward) data to another account.
However, data on invalid accounts are now emphasized in the list and form entry applications by [yellow] markings ([yellow] background or warning status). Corresponding messages are written into the processing control records (VERARB) or in the voucher headers (BEL, KONBEL). The account number as well as the amounts are provided with a [yellow] background in the tables if they do not balance to zero. Forms entry tables in report schemes do not show data on invalid accounts since there is no position/account allocation. Then possible data on invalid accounts are reported in a message window. Corresponding messages are output after import of data, too.
Some problems may arise from data on invalid accounts, especially on transaction development accounts, among other things:
Then it is recommended as a measure to deactivate the flags for data entry per period type in the account master data (KTODEF or KTOE) to omit manual entries for this account and to extend the validity of the account by one year. Then the validities of the position account allocations are automatically extended along.
Amounts displayed in additional columns (e.g. comparison values for account balances or differences to them) of the list applications are now displayed without decimal digits if the corresponding currency is specified this way. However, this does not apply for amounts in transaction currency and the compensation of difference amounts in local currency since different currencies may occur in the same column in these cases.
Up to Release 2019 a program error provided that IC fixed asset transactions had not been checked completely in connection with the allocation to different business units providing that certain errors (e.g. missing or invalid posting keys) had not been reported. This error was corrected. However, this correction provides for different check sums in this constellation although the data themselves remain unchanged. As a consequence, then the status for currency conversion became [red]. The concerned periods or statements have to be locked to avoid this effect.
If a voucher contains postings on accounts which are not valid in the actual period, then now a corresponding message number is written into the voucher header as far as the total of postings per account does not balance to zero.
If a voucher contains postings on invalid accounts which are not valid in the destination period, then now these postings are carried forward without output of messages and the voucher becomes active (up to now the carry-forward voucher became inactive). This corresponds to the carry forward of consolidation vouchers and postings.
If a reference fact for exchange rates (see above) is specified for the actual fact, then the required exchange rates are determined from the reference fact as far as they are not specified for the actual fact. In this case the associated list of exchange rates (WKZWKA) in addition displays the exchange rates of the reference fact and designates them correspondingly. Thus it is no longer required to maintain exchange rates on all facts on which a currency conversion is performed. Simultaneously the risk is minimized that the data are converted on different facts using different exchange rates. This enhancement is effective for the currency conversion of consolidation postings, too.
Company financial statements now can be converted using exchange rates for arbitrary closing dates. For this purpose a closing date deviating from the month-end of the actual period has to be specified in a new attribute of the currency conversion parameter (WUM). The conversion with exchange rates of the previous period may refer to a deviating closing date, too, if the currency conversion parameter of the previous period specifies a deviating closing date. This enhancement especially supports the correct conversion of disposing companies with the exchange rate of the disposal date, but can be used for an acquisition balance, too.
If different accounts for compensation of the balance sheet and the p&l difference, respectively, are specified in the currency conversion header and a posting key with the new usage tag 'USV' (see above) is specified for the transaction development of the account for p&l differences, then the capital transaction for the elimination of the p&l difference carried forward is provided with this posting key. If the accounts for compensation of the balance sheet and the p&l difference are identical or no posting key with the usage tag 'USV' is defined, then the elimination of the p&l difference carried forward is provided with the posting key with usage tag 'U' just as always up to now. This additional differentiation merely serves for the representation in cash flow reports but has to be considered in equity capital reports, too.
Now the IC clearing list (EGESGES) can be called directly form the application menu or per short word entry. This is especially useful if the list shall display data for several companies in one table. The direct call is supported, too, for the analogous list for IC consolidation (KGESGES). In order to distinguish between them KGESGES was renamed into "IC consolidation list" while EGESGES was renamed into "IC reconciliation list".
The function "Refresh IC-clearing" has been renamed, too. In the group financial statement (application KGESGES) it is now named "Rerun consolidation", however, in the company financial statement (EGESGES) it is named "Refresh IC reconciliation".
Now the "IC reconciliation list" (EGESGES) yet displays only IC clearing records emerging from a IC reconciliation in the company financial statement but no longer data records created by the corresponding consolidation function.
Several consolidation functions have been designed more performant. However this effect is noticeable only for large group structures.
When saving modifications in the group companies, especially after manual entries of multiple participation percentages, the check and refresh of participations is automatically started.
The function "Check & refresh participations" now allows for the definition of group companies with participation levels greater than 9. The new upper limit is 35 participation levels. Up to now levels greater than 9 were not displayed correctly but rather as an error. In addition, no multiple participation percentages for indirect minorities had been calculated.
With Release 2019 it had been allowed to specify threshold values in the consolidation parameters as percentages instead of absolute amounts. Since the difference percentages determined from comparison of the intercompany account balances at consolidation D&C and I&E (or the corresponding IC reconciliation functions for company financial statements, respectively) do not result from a simple calculation, this percentage is now displayed in the IC clearing list and saved in the corresponding database table. If several matching groups have to be considered (e.g. several business units, different transaction currencies) then the maximum value is applied which is responsible for a remaining difference not posted on the threshold value account.
Now the IC clearing list (KGESGES) can be called directly form the application menu or per short word entry. This is especially useful if the list shall display data for several companies in one table. The direct call is supported, too, for the analogous list for IC reconciliation for company financial statements (EGESGES). In order to distinguish between them KGESGES was renamed into "IC consolidation list" while EGESGES was renamed into "IC reconciliation list".
The function "Refresh IC-clearing" has been renamed, too. In the group financial statement (application KGESGES) it is now named "Rerun consolidation", however, in the company financial statement (EGESGES) it is named "Refresh IC reconciliation".
Now the "IC consolidation list" (KGESGES) yet displays only IC clearing records emerging from a consolidation function but no longer data records created by IC reconciliation in the company financial statement.
The application "List for elimination of current assets results" (ZWERGUV) now offers a new field "Incl. sub-groups" in the selection area. When entering an 'X' not only the data of the selected group but rather the data for intercompanies from sub-ordinate groups are displayed just like in other list applications. Then the group where the processing had been performed is output in an additional column. By sorting the data by the content of this column unprocessed data (column is yet empty) are displayed on top of the list. This selection is now standard when branching off from the group monitor (KTKGES).
Additional new columns in this table now display the status ("S") and the posting status ("P") analogously to the IC clearing list (KGESGES). The status is [green] if the line had been processed by a posting and otherwise [red]. The posting status shows a '1' if the processing had been performed in the actual group or a 'T' if the processing had been performed in a sub-ordinate sub-group or has to be processed there.
If the specified intercompany is not fully or quota-consolidated in the actual group companies, then the associated inventories IC-stocks are no longer displayed.
The specification of amounts in local currency for the compensation of difference amounts is now supported for non-cash additions to the group companies, too.
If the reference posting key for a posting key used in the shareholding transactions (GESGES) is not valid in the actual period then now the consolidation posting is nevertheless generated, however, the posting key remains empty. This is visualised by a message in the voucher header and a coloured background of the cell in the table of consolidation postings (KONBUCH).
If the addition date of a parent company is situated with in the actual period (e.g. addition of a complete sub-group) then the participation is not eliminated with the reference posting key of the posting key of the shareholding transaction but rather with the posting key for "Addition to group companies" (usage tag 'E').
If an individual account for minority interests is allocated for an equity capital account in the account master data then now not only the direct but rather indirect minority interests for this account are reposted on the allocated account. This especially applies for result shares and exchange rate effects.
The function for deconsolidation itself has not been modified. But you now have the ability to perform the currency conversion for disposing companies with the exchange rates of the disposal date (see above) and to copy the company financial statement converted this way into all periods until the end of the business year (see below) providing that the company financial data remain consistent to the deconsolidation postings.
A new function "Copy company financial statements deconsolidation" serves for copying the complete financial statement of a company disposed over the cast of the year into all remaining interim statement periods up to the end of the business year. This function is invoked out of the group monitor (KTKGES) by an action in the sub-menu "Deconsolidation". Thus it only can be called on facts on which the consolidation occurs. However, a deviating comparison fact can be specified as source.
The copying comprises the complete company financial statement data, i.e. account balances, intercompany balances, controlling balances, development transactions, inventories IC-stocks, vouchers and postings, currency conversion parameters, account and posting key conversion rules. Amounts in group and parallel currency are copied, too, as well as conversion information providing that no currency conversion has to be performed afterwards. Data possibly existing in the destination period are deleted ahead. Finally the company financial statement is locked.
Since this function copies the company financial statement itself, i.e. no real company financial statement can be stored parallelly, it can be used only for complete disposals (disposal on all group levels). If a company leaves only a sub-group, this has to be continued to be treated manually.
Consolidation postings for depreciations in the actual period are now eliminated at the merged company with the posting key for disposal by merger (usage tag 'MF') and inserted at the absorbing company with the posting key for addition by merger (usage tag 'ME'). The counter-posting is done each on the account for retained earnings from the consolidation parameter. Up to now the depreciation postings always were newly calculated in the merger vouchers.
If the compensation of the difference amount of the merged company was specified in local currency, then these local currency amounts, if applicable incl. accrued depreciations, are transferred to the absorbing company.
If a complete sub-group is added to the group companies, then now a 'KU' consolidation voucher is generated for the sub-group parent company, too. It is prerequisite that the addition date of the sub-group parent company in the sub-group is situated in the actual period. Then no 'KU' voucher is generated for this company on the higher group level and the status becomes [T].
A voucher for "First consolidation repostings" ('KU' voucher) now contains repostings for intercompany accounts, too, which up to now were generated by "Consolidation D&C repostings" ('SU' voucher). Then development transactions with carry-forward posting keys are not eliminated with the original posting key but rather with the posting key for addition to the group companies providing that the result in total is correct. The advantage is that it can be checked now after capital consolidation and without consolidation D&C (incl. repostings) whether all carry-forward transactions had been eliminated.
Consolidation postings with fixed asset objects which are invalid in the actual period now may be entered and modified. This provides for the ability to repost existing (e.g. carried forward) data to another account and thus to another fixed asset object.
If a consolidation voucher contains postings on accounts which are not valid in the actual period, then now a corresponding message number is written into the voucher header as far as the total of postings per account does not balance to zero.
If a reference fact for exchange rates (see above) has been specified for the actual fact or other facts reference to the actual fact as reference fact for exchange rates, then the function "Change currency data group currency <=> parallel currency" no longer can be performed since otherwise the condition that actual and referenced fact have to specify the same group and parallel currency would not be fulfilled.
Copying and inserting of cell contents is now supported in the parameter table. The amounts in the parameter table are displayed right-hand aligned.
Export of data to Excel is now possible in the windows for plausibility checks, balance differences, cross-company IC planning and account details.
The start of the planning application was accelerated, especially at definition of many scenarios.
The period preselected for the position/account allocations of a new scenario now is the period specified as valid-from period in the user's startup data (VOR). If no valid-from period is specified there, then the period is preselected with the first period after the ACTUAL time interval like up to now.
In addition, this period now is an entry field where even periods not defined in the application ABR may be entered. The choice dialogue with the periods defined in ABR yet opens if you click on the arrow icon beneath the entry field.
If no period is selected yet on the period selection page of the scenario wizard then now the period selection list is positioned on the period specified in the user's startup data (VOR).
The planner spreadsheet now yet contains only accounts which allow data entry due to the entry flags per period type (M, Q, Y). Otherwise it would have been necessary to write account balances in periods where these accounts are not permitted. Excepted from this rule are accounts which are automatically provided with amounts, like e.g. the result account.
Mere intercompany accounts which specify the own company as intercompany now are locked in the scenario providing that no balances can arise on these accounts.
The update of locks after several actions in the planner spreadsheet was designed more swiftly.
Statistical accounts now can be selected differentiated by b/s p&l code in the dialogue for refreshing or writing, respectively, of balances.
The context menu of the tree table of rule templates now contains a new sub-menu for controlling the type of application of the rules. The menu items offer the ability to activate or deactivate the settings "Apply rules only on existing accounts" for account balances and intercompany balances. This allows for the setting of this preference for several rules in one step.
The transition rule was supplemented by two radio buttons which control whether the closing balance or the changes in the actual period of an account shall be transferred. "Closing balance" is preselected. In the general rule you can select the changes in the actual period, too, besides the closing balance, opening balance and change.
In the formulae of the table cells of individual tables you have now the possibility to reference to parameters using the new function 'PAR'. The function 'PAR' has two arguments: the parameter name and the period. If applicable the period is adjusted at import of table sheets. All referencing formulae are newly calculated at modification of a parameter value.
It is now generally possible to specify the same account as source as well as destination account in the allocations of the cross-company IC planning. An error message is yet output only if the intercompany balance of an account is selected as source and as destination.
The status of the cross-company IC planning in the Forecast monitor (PM) now becomes [red] for faulty allocations, additionally the corresponding message at restart of the transfer, too, since the transfer cannot be performed any more. The text of the message is now "The cross-company IC planning contains erroneous mappings, please correct them". A partial transfer is now performed yet if exchange rates are missing.
The cross-company IC planning was enhanced by the possibility to transfer balances from assets / liabilities cash pool from other intercompanies. For this purpose special cash pool allocations are displayed and entered in a new registry tab of the application ICGP. Opposite to p&l allocations for cash pool allocations a bank account has to be specified for the destination company. During transfer the current change of the source balance sheet account is determined and inserted at the destination company as posting 'bank account to destination account' or 'destination account to bank account', respectively.
It is now reported as an error if an ICGP allocation had been defined with several identical destination accounts.
The currency conversion within the cross-company IC planning was adjusted to the currency conversion of IDL.KONSIS (see above) with respect to the introduction of a reference fact for exchange rates (see above). Thus now a currency conversion parameter (WUM) has to be defined always for the actual fact. Up to now the reference fact for group companies had been used alternatively. The reference fact for exchange rates is used instead of the reference fact for group companies for determination of exchange rates. In case it may be necessary to provide the plan facts with the reference fact for group companies as reference fact for exchange rates.
Up to now the display of the Forecast monitor (PM) was always refreshed automatically if you returned from another registry tab. This does no longer apply since the refresh took some time for extensive amounts of data. Rather refresh has to be manually invoked by pressing the according button.
Four new flags were supplemented in the Forecast sequence parameters (PAPAR). The new flags allow for the setting of the splashing and summation control. The setting of these splashing flags is a processing step on its own in the Forecast sequence.
Reports now cannot be deleted any more if they are referenced in an MIS parameter (MISPAR). This prevents problems at preparation of data for an OLAP or the Data Mart interface, respectively.
The setting 'X' for position/account allocation per period now can be activated for reports without a comparison period, too. This has no effect until a comparison period is supplemented later on.
The maximum column width of descriptions which may be longer than 70 characters (accounts positions) now can be set to values less than 70 (see above), providing for the print of more amount columns on one page. The minimum allowed maximum column width is now 30 characters.
A new import application (TXTABG) was established for the table of submission dates. The corresponding list (ABG) exports data in the corresponding standard TXT format providing for an easy re-import of these data. An import variant with deleting of data ahead is not provided. An import table ('I119', format type '#DB') was defined.
For the following data stocks with import functions already existing now an import table (format type '#DB') was supplemented in the database:
The import/export formats were adjusted to the actual database extensions:
Up to now account balances on the result account were reported as an error at import since the result balance is always determined by IDL.KONSIS. Now these balances are no longer reported as an error but rather simply ignored and documented correspondingly in the final log information. Amongst others this simplifies the import of account balances exported from IDL.KONSIS
The action mass-update was supplemented in the application "IE Job Control". It can provide for modification e.g. of the setting of the delete option or the specification of the origin for several jobs in one step. Earliest start timestamp and origin can be deleted, too, by entry of '*'.
For the goal to transfer data entered in the portal of IDL Workplace Server (IDL.DESIGNER) to IDL.KONSIS the Import Webservice is used which requires a login to IDL.KONSIS. When using Windows authentication here only the general user IDLADMIN could be used preventing a differentiated reproduction of the responsible users. Now you can use the authentication at the Windows AD controller here, too. For this purpose it is required to make the check of the group allocation (AD groups in IDL.KONSIS and groups of the user in the Active Directory) optional, i.e. the parameter "asGrpCheck" in the database configuration has to be set to "false". Then users can login with their user names within the domain.
For import processes started using the Import Webservice now you have the possibility to ignore (all) warnings. For this purpose you have to supplement the entry ";import.warnings.ignore=true" in the call at the parameter "Environment". Without this entry warnings are treated as errors.
The group-wide and the group/sub-group exchange of data have been modified to include various database enhancements. Amongst others the new table K031 for the allocation of business activities to companies (see above) was supplemented in the group-wide data exchange. For this reason, they are not compatible with previous release versions.
The possibility to transform an external company key into a company key and a business unit in IDL.KONSIS by specification of a second transformation object was restricted to the useful combinations of transformation restrictions:
Parameters of version '04' (IDL Datamart) now offer an additional setting "Debit/credit control". The entry corresponds to the entry options for standard reporting. Default value is 'GS' (balance on company level) which had been applied up to now, too.
The views OLAP_DIM_FactLayer and OLAP_TMP_FactLayer were enhanced by a column FACT_DM. If applying this column contains the comparison fact for Datamart (see above) specified for the respective fact. This entry can be evaluated in IDL.DESIGNER reports if the comparison fact of a report is different dependent from the selected fact.
In addition the new attribute "Debit/credit control" of the MIS parameter is evaluated analogously to the standard reporting.
The message window of IDL Smart Connectivity was newly designed providing that longer message texts can be displayed with aid of a scroll bar.
The Release 2019 Update 1 contains the current edition of the DCW interface for DCW release 3.50.