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.
In addition to the conversions of Release 2017 Update 1 the migration program will complete the following transformations in the database:
In addition to the amendments of Release 2017 Update 1 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 and/or IDLWIN can be used as a template.
The following menu items were deactivated with this release. They will be deleted in one of the subsequent releases. Please remove all individual usages (authorisations, menu structures) of these menu items until then:
As far as these applications could be invoked directly via short word entry now an automatic switch to the short word of the new application as substituted is performed when entering one of the disposed short words.
The 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.
You have now the ability to lock a user after three faulty password entries to ensure that the user must not attempt an arbitrary number of different passwords. This control can be enabled per user. It is presupposed that you work with the IDL Konsis internal password administration (no authentication by the database or via active directory).
For this purpose the user table (USE) was supplemented on the one hand by a flag for activation of this check, on the other hand by a counter for the number of faulty password entries. You require administrator authorisation (IDLSYS or IDLADMIN) for modification of these data. Unlocking of a user is performed by the administrator, too,
The authentication via the active directory (without entry of name and password, "single sign-on") was supplemented by the admission of active directory groups. These AD groups can be associated to authorisation groups in IDL Konsis providing for a control of the user authorisations already in the active directory.
For this purpose the table of user groups was supplemented by an attribute for an "Active directory group". This attribute can be displayed and modified by the applications "User groups" (BEN) and "User group authorisations" (BENDEF). This entry is customer specific, i.e. it is not updated during release upgrade for "IDL" user groups, too. However, you should pay attention for correct usage of upper and lower case letters.
You can determine separately per database alias in the configuration of the application server whether the check against the active directory shall be performed. If this check is activated IDL Konsis determines at login the groups the user is allocated. Then the user group for menu or object authorisation, respectively, allocated in IDL Konsis has to be one of the allocated groups in the active directory. Otherwise the login will be rejected. This even happens if no active directory group is allocated to the user group.
In addition, you have the possibility to insert a user newly defined in the active directory as a user in IDL Konsis automatically, too. For this purpose you have to define a user template in the user table (application USE) with the desired standard settings in IDL Konsis.
The user table (USE) was supplemented by an attribute "Template" for identification of these user templates. The entry 'X' in this attribute identifies a record as a user template which serves only as a copy master but must not be used for a login by itself. You may define several user templates, however, there may be only one template allocated to a certain active directory group providing that the determination of the template to be applied is unique. After successful determination of the user template it is used as the copy master for the user to be defined. In doing so the IDL Konsis user ID is derived from the user ID in the active directory.
For the ease of use the installation program for a new release now contains a drop down box for the entry of the database offering the databases allocated to the corresponding IDL Konsis Application Server.
The configuration of the databases is now checked more tightly. Thus it is no longer possible to save a database configuration which is invalid due to missing parameters.
The login check for configured databases now comprehends all connection paths. Thus e.g. it is now determined in this step if a defective OLEDB driver is present.
If two screens are connected with the computer and the application window had been dragged to the second screen, then now all associated dialogues (e.g. message windows, help text displays) are displayed on this screen, too. Up to now often these dialogues were displayed on the first screen and could easily be overlooked there.
Furthermore the application window can be maximized to the maximum size on the second screen even if the second screen has a higher resolution than the first screen.
The double arrow icon is now designated uniquely with the text "Refresh" as tooltip. Up to now in the table tool bars "Display" was output.
When printing tables with columns with a width of more than 70 characters (see below) now the dialogue for print options exhibits a second tab "print long texts" for setting of the options for printing these long texts. The following options are offered:
In addition, for the latter two options the column width can be set between 70 and 255 characters.
The module name is now displayed in the info dialogue for the new master data applications (without selection area, with wizard instead of single record application), too.
The pages of the wizards of the new master data applications ware now adjusted to a unique size. Thus some pages contain larger empty spaces, however, the navigation through the pages is simplified because the buttons <Next> and <Back> as well as the navigation area are always placed at the same position.
The representation of the number of the data records per table already practised in some applications (in brackets behind the description of the registry tab) is now performed in all master data applications of this type.
Combo boxes (entry fields with predefined entry possibilities) are now uniquely displayed in the way that the selection list displays at first the keys followed by the description. This corresponds to the representation in the tables. In addition, the fields are extended to the size required for representation of the complete descriptions.
Most of the complex master data applications (with leading and dependent tables) now allow for copying of dependent data to another object of the leading table. For this purpose you have to select the data to be copied in the respective table of the opened model, drag them with the mouse into the leading table and drop it on the destination object. Depending on the application this action may be restricted (e.g. to identical transaction development type for transaction development data), however, there is no complete validation of these data. If inconsistencies result they are displayed in the table of open tasks yet after opening the model of the destination object. This functionality is supported by the following applications:
If different modifications (insert, update and deletion of data) had been performed in one of the complex master data applications, then these modifications are persisted in the database yet when pressing the <Save> button. However, if a deletion provided for a foreign key violation in the database then no saving was performed and all modifications were lost. This is now omitted by performing the deletion of data in separate database transactions.
It is now possible to branch off into a table of the user groups authorised for a period by selection of the respective period and a corresponding entry in the context menu in the period table. This table is an additional table in the application "User group authorisations" (BENDEF).
A warning message is now output if a newly entered or updated period for a business year (period flag 'J') has a temporal distance of more or less than 12 months to the last preceding period for a business year.
The simultaneous drag-and-drop allocation of several companies to the group companies in one step was significantly accelerated.
The entry of a conversion factor in the wizard is now performed using a radio button group with the allowed values 1, 10, 100 and 1000.
In the style of other similar applications the former application "Charts of positions" (POP) was now renamed into "Chart of position definition / account allocation" and has received the new short word "POSDEF". For the time being the old short word "POP" can be used as well.
Periods not defined in the application "Periods" (ABR) can now be entered as periods for the display of the position account allocations valid in this period since these periods may be specified for the validity of accounts and positions and thus in case are inherited by the positions account allocations.
It is no longer permitted to define position account allocations for charts of positions for business ratios (chart of positions type 'K'). In this case the corresponding tables are no longer displayed. In addition, only positions with classification 'Ox' ( without account allocations) but no positions with classification 'Mx' (with account allocation) can be defined in these charts of positions. If an existing chart of positions violates these rules, this is reported in the table of open tasks.
The action "Position/account allocations" in the application "Positions" (POS) now branches off into the corresponding page of the application "Chart of position definition / account allocation" (POSDEF).
The list application POSKTOP offered in addition to the maintenance application POSDEF primarily serves for a period-comprehensive display of the data in the database. This application was now renamed into "Positions+accounts allocations - periodic display" emphasizing that it offers no ability to modify data. The possibility to call the single record application was discarded.
The action "Position/account allocations" in the applications "Positions+accounts allocations - periodic display" (POSKTOP) and "Changes of positions+accounts allocations -period-" (POSKTOPLOG) now branch off into the corresponding page of the application "Chart of position definition / account allocation" (POSDEF).
The display of the list "Accounts" (KTO) as well as the account selection dialogue used in many other applications was significantly accelerated by improvement of database accesses. The effect depends on the number of multi-language translations of the descriptions of the accounts.
The action "Position/account allocations" in the application "Chart of account definition" (KTODEF) now branches off into the corresponding page of the application "Chart of position definition / account allocation" (POSDEF).
Accounts and positions can now be provided with descriptions in a length of up to 255 characters. This way you can omit cryptic abbreviations, identical descriptions by truncated texts and text positions in reports. Up to now the maximum length of descriptions was 70 characters.
Before exploiting this possibility you should reflect whether successive systems working with data from IDL Konsis (e.g. OLAP reporting, XBRL reporting) can deal with these longer descriptions without any problems.
To assure that no problems arise from an accidental usage of the larger length the tables for charts of accounts and charts of positions were extended by the specification of the maximum length of the account or position descriptions, respectively. This information is initialised with the value of 70 valid up to now. Longer descriptions can only be entered if you specify a larger number here. You can specify a value between 70 and 255.
However, this maximum length can only be reduced again as long as no descriptions with a length exceeding the new value exist. Similarly copying of accounts and positions to another chart of accounts or positions, respectively, is only possible if the length of descriptions conform to the limit of the respective destination chart.
Longer descriptions in case are displayed abbreviated in the table columns. The column width set by default allows for the display of about 100 characters. If the text cannot be displayed completely it is truncated and represented with "..." at the end. However, the complete text can always be displayed as a tooltip if you remain with the mouse cursor for some time. The columns can be dragged wider or smaller by the double arrow in the header line on demand.
Fields with a length of 255 characters were supplemented in the export and import formats of accounts and positions to allow for the import of long descriptions. However, as long as the length of up to 70 characters is not exceeded the previous fields can be continued to be used.
The print output of long descriptions can be controlled in different ways: in full length, truncated or with line break. The latter two possibilities allow for the specification of the width by entry of the maximum number of characters. The line break is performed intelligently, i.e. using word wraps or special separation characters. A new page (registry tab "print long texts") in the print options dialogue serves for the entry of these settings.
The standard values of this print control even can be preset for IDL Konsis reports in the report header. Then the print dialogue is correspondingly preallocated.
The change log for master data was enhanced by a function for controlling objects. This logging can be activated, deactivated and reorganized in the usual way with the control application "Control of data change logging" (LOG) using the table key "K063". The change log can be viewed with the new list application "Changes of controlling objects" (CNTLOG). This function requires the licence for change log.
The runtime for construction of the display of the status values of the company financial statement monitor (EA) was reduced. This especially affects the usage of many transaction developments or development areas.
The representation of zero amounts from the database as zero amount or as empty amount in the maps of the single record applications was newly and uniquely managed.
The runtime of validation of reported data was reduced by introduction of a cache (temporary storage) for error messages. This especially affects the repeated determination of the same errors, e.g. due to a systematic error.
The comment now is displayed and can be entered directly in the table column, too, in the forms entry application for account balances (I-KTOSAL) with most of the column options. Excepted are the multi-column representations for periods ('P') or business units ('U'), respectively. For 'P' and 'U' the entry of the comment remains in the additional dialogue.
Just like before for development transactions, now one report can be designated as default report for forms entry for account balances, too (here report type 'E' instead of 'D'). Then this report is preselected when invoking the application 'I-KTOSAL'. Up to now the report of the start-up data (VOR) of the current user was used for this purpose. This report now can be specified independently from forms entry.
When entering intercompany account balances now amount and currency code of transaction currency always have to be entered simultaneously. However, the amount may represent 0.00, too.
When mass-copying postings internal origin entries are no longer copied along. As a consequence the copied postings now behave just like manually entered postings.
It is now possible to perform several transfer steps with one call. A fact sequence defining exactly the desired steps is presupposed for this function. Then the key of the fact sequence has to be specified as an additional parameter in the calling applications "Company financial statement monitor" (EA) and "Select transition to new fact" (GESABV). Example:
Just like for the group financial statement now for the company financial statement, too, deferred taxes can be calculated and posted on facts not affecting the result but affecting the equity capital. Excepted are postings for the result effect on the result account since this amount can be processed via the p&l postings.
The corresponding designation of "capital effective" vouchers with 'K' in the flag for result effect was already present. Now these vouchers and their postings can be provided with the flag 'LT' for calculation of deferred taxes.
When branching off from the deferred taxes header (LTK) into the postings list to see all postings to be considered for deferred taxes now all postings of the vouchers selected for deferred taxes are displayed.
If you branch off from the company financial statement monitor (EA) into the "IC clearing list" by a double mouse click into a column for IC reconciliation, then this subsequent application is displayed with the short word "EGESGES" (instead of "KGESGES"). These two short word variants differ in their menus. Thus e.g. the context menu item "IC fixed asset transactions" is missing in EGESGES and a double mouse click branches off into the intercompany account balances instead of the consolidation postings.
If postings on intercompany accounts with specification of an amount in transaction currency provide for a difference compensation by the currency conversion, then this transaction currency is now inserted into the compensation posting, too. Thus the exchange rate effects are considered correctly in the IC reconciliation. Up to now these postings provided for inconsistencies between both facts (status [red] in the lower fact, but status [green] after transition to the next fact).
Up to now the fact specified in the start-up data (VOR) of the user was used for preallocation of the fact in all list applications. Thus e.g. a fact on the level of the company charts of accounts was preallocated in applications which allowed only facts on the level of the group chart of accounts. Therefore now in a set of applications on group level the fact from the user's start-up data is no longer used for preallocation but rather a fact on the group level. This fact is determined by the following priorities:
This concerns the following applications:
Voucher classifications defined only as an alternative for another voucher classification for the purpose to avoid naming conflicts are now always allocated for consolidation reports in the same way as the leading voucher classification. This concerns the voucher classifications 'En', 'Fn', 'Kn', 'On', 'Pn', 'Rn' and 'Tn' ('n' = '0' to '9'). Deviations existing in case are corrected by the release migration program.
The action "Position/account allocations" in the application "Consolidation parameters" (KTKPAR) now branches off into the corresponding page of the application "Chart of position definition / account allocation" (POSDEF).
The "Automat for Consolidation Functions" was arranged more clearly and refreshed by the following actions:
To avoid a duplicate elimination of intercompany account balances no elimination postings are generated by the consolidations D&C and I&E (SK/AE) for checked transaction development areas without balance-relevance which are not activated.
After modification of an fixed asset consolidation posting at-cost now not only the depreciation is calculated automatically but rather the modified amounts in local currency are immediately converted into group currency without calling the function "Currency effect - Compensation temporary diff. from first cons.". This concerns modification in the dialogue (KONBUCH) as well as by an import (TXTKONBUCH).
Within status refresh now the status "KLW" (Exchange rate effects at compensation of the difference amount in local currency) are set to [red] only if the status had been empty before and there exists at least one consolidation posting with specification of a deviating local currency, e.g. if the processing could not be performed after a carry-forward due to missing exchange rates.
If several companies were simultaneously merged to the same absorbing company naming conflicts could occur for the vouchers for elimination of the facts from the elimination of IC-profits (fixed assets, voucher classifications 'ZA' or 'PX', respectively). To avoid these conflicts new voucher classifications 'Tn' ('n' = '0' to '9') were introduced which are used instead of 'PX' in these circumstances.
Checks for status refresh are no longer performed for merger vouchers manually entered or copied.
Only shareholding transactions chronologically situated before the merger date are now considered for calculation and posting of minority interests after merger of a company. Up to now always 100% minority interests were calculated and posted.
The currency conversion for data on group level (conversion of consolidation postings into parallel currency, compensation of temporary differences in local currency, calculation of exchange rate effects for elimination of current and fixed assets etc.) usually accesses the currency conversion parameters (WUM) and the associated data (account and posting key currency conversion rules) of the respective companies to determine the required information about exchange rate codes, currency conversion methods and rules. Within this it is a problem if no currency conversion parameter is defined for one company. This often applies for deconsolidated companies and for companies consolidated at-equity since no company financial statements to be converted exist, or even for companies with local currency equal to group currency but with compensation of temporary differences in a different local currency.
To avoid problems during the consolidation process resulting from missing company currency conversion parameters you can now define currency conversion parameters for groups. These are always used by the different consolidation functions if there doesn't exist a currency conversion parameter for the respective company.
For display and maintenance of these data the new list application "Group currency conversion parameters" (WUMK) with an associated single record application (WUMKE) is introduced. These differ from the currency conversion parameters for companies in the following items:
Amounts from neutralisation accounts yet are only considered for the total if you had uniquely selected for one account. This applies for the result account in the list "Account balances and consolidation postings" (KONSAL), too. The consideration of the neutralisation account for the sub-totals depends on the sort option.
Check rules can now be classified into "hard" check rules ('H') and "soft" check rules ('S'). This classification is specified in the check rule master data record in one of the applications "Check rule" (PRFE) or "Check rule definition" (PRFDEF). Check rules already existing are classified as hard check rules by default. 'H' is the default value, too, when importing check rules without classification. As long as no soft check rules are defined nothing changes from the user's point of view.
Background of this enhancement is the fact, that up to now unsatisfied check rules always were treated like an error and thus e.g. provided for a [red] status of the company financial statement. However, e.g. with respect to check rules for business ratios introduced recently, beside check rules which exhibit inconsistent data and can be corrected by modification of these data, there are check rules exhibiting not desired data which, however, cannot be corrected since they are as they are. Now these latter check rules can be classified as soft check rules.
If there exist hard as well as soft check rules now the monitor applications (EA, KTKGES) display two columns for the status of the check rule calculation results. Each column displays for itself whether the corresponding check rules are completely satisfied ([green]) or not ([red]). However, the status of the soft check rules has no influence on the total status of the company financial statement displayed at the beginning of the line. Just like before the status [yellow] indicates that reported data had changed and the check rule result has to be recalculated.
Like before a double mouse click on one of the check rule status columns provides for a branch into check rule result list (PRFERG or PRFERGK, respectively) but is supplemented by the transfer of an additional parameter of the check rule classification providing for the display of check rule results of only hard or soft check rules, respectively.
Like up to now the status colours displayed in the monitor applications are derived from the data of the processing control (VERARB or KVERARB, respectively). Now there are two new check point IDs, 'PRFERG-H' and 'PRFERG-S' which replace the former check point ID 'PERERG'.
Data of the leading table now can be modified (e.g. change of the description) if the corresponding model is not opened.
The action "Position/account allocations" in the application "Check rule / position" (PRFPOS) now branches off into the corresponding page of the application "Chart of position definition / account allocation" (POSDEF).
Logging of a planning now no longer can be switched on or off supplementary.
Except for the scenario settings the used ICGP profile is now displayed in the ICGP list, too. From there you can branch off immediately into the ICGP application providing for the display and editing of the correct profile.
The start of a scenario with cross-company IC planning was accelerated by optimisation of the database accesses.
In most cases the functions "Refresh balances" and "ICGP transfer" in the same forecast sequence do not provide for the desired result since the preceding companies have to repeat their ICGP transfer if the source balances of the successive companies are changed by "Refresh balances". Therefore the former message
was replaced by the more meaningful message
Similarly this message text was adjusted with respect to the function "Copy/Splash Balances".
The performance of forecast sequences was accelerated as the scenario list as well as the rule template tree are no longer determined and displayed at start of the planning application by a forecast sequence. Additionally the other information windows are no longer displayed, too.
Now the chart of accounts per company is displayed in the scenario list in the company entries below a scenario.
The date "Saved at" does no longer represent the last modification date with respect to the database (e.g. by migration at release upgrade) but rather the date of the last modification of the scenario contents.
It is now possible to control per company whether rules shall be applied only to existing balances. This setting can be performed for account and intercompany balances separately.
There is a new page "Scenario settings" in the scenario wizard. The settings from the first page (activate intercompany planning, activate plan aggregation accounts, etc.) were moved to this page followed by the flags "Rules on account balances" and "Rules on intercompany balances". There you can decide between the following settings:
The setting "Apply rules only on existing balances" can be set per company in the scenario settings on the page "Company settings".
Parameters are now provided with change information (when? who?). The display of the change information can be switched on or off.
Several new flags now serve for settings whether consistency checks (plan aggregation, account for retained earnings etc.) shall be performed at each start of the scenario. The start can be considerably accelerated by omitting these checks. However, these checks are always performed independently from these flags when saving the scenario for a company for the first time.
If an account is no longer used in a scenario then it is now removed from the IC preselection, too, when saving a company providing for the ability to delete this account subsequently.
The start of a scenario was considerably accelerated by optimisation of the determination of plan aggregation accounts and other activities.
There is a new button for hiding of empty accounts in the toolbar of the reports. This setting is applied only on the current report and is not saved. The accounts are automatically shown again if balances arise on formerly empty accounts by refresh of balances or application of rules.
The up to now shown internal dimension keys in brackets ('Q1', 'Q2, ... or 'M01', 'M02', ..., respectively) in the columns of the planner spreadsheet are no longer displayed.
By default quarter totals are hidden in years with monthly breakup.
Up to now the check boxes for filters in certain account types (e.g. intercompany accounts, third party accounts, aggregation accounts) were automatically selected if the planner spreadsheet did not contain any accounts of this type. Now in this case the check boxes are greyed emphasizing that these filters do not matter.
The action "Apply Template/Set (Selected Periods)" now can be performed, too, if the mouse cursor points to a cell of a position.
The dimension settings of a scenario are now saved separately for each user and no more global for all users.
The button "Reset" now resets the dimension settings to the standard. The old function of the button "Reset" (revoke the not yet applied changes on the dimension setting) now can be performed by the new button "Discard".
The list "Plausibility checks" now displays the reason in the second column. Up to now this had been the last column. Correspondingly the lines are now primarily ordered by reason.
Rule individual settings whether rules are to be applied only on existing balances are found on the last page of the respective wizard. The setting for account balances can only be modified if third party accounts are allocated. The setting for intercompany balances can only be modified if intercompany balances (IC account flag 'I' or 'J') are allocated. The default setting for account and intercompany balances is that the rule is applied on empty balances, too.
The default setting of all rules was changed from "Of account entry" to "From closing balance".
The posting record separation in the general rule now separates the posting records no longer only in the user interface but rather in the internal representation, too. If the rule contains posting records sited outside the scenario, this provides for the application of all posting records sited within the scenario. Up to now in this case the complete rule was not applied.
The base value rule, the sales rule, the income rule, the purchases rule and the expenses rule now can take the intercompany details of the base value. For this purpose you have to select the check box "Base value with IC details". If a statistical intercompany account (IC account flag 'I' or 'J') is present for the base value factor then the respective intercompany balance is used as base value factor. This rule enhancement will be supported for the financing rule, too, in the subsequent version 18.1.
All rules with payment, dissolution, sales tax dissolution or utilisation show the status [red] and report a message if an account is to be dissolved against itself.
The delete button now can be used in the list of applied rules, too.
When deleting business cases the request whether amounts shall be deleted, too, was dropped since only one of the offered options was meaningful. This option (delete only amounts created by the respective rule) is now performed by default. Therefore there remains only the request "Are you sure?".
The representation of the window for table storage was adjusted to other windows (scenarios, rule templates etc.).
The name of the table displayed in the foreground now is automatically selected in the table storage window. On the other hand a mouse click into the table storage window provides for the display of the corresponding table in the foreground.
MSAL formulae can be defined for intercompany accounts (IC account flag 'I' or J'). Then they are automatically applied on third party accounts.
On the other hand IC and MIC formulae are generally not permitted for third party accounts in scenarios without rules for IC relations. These rules now provide for a syntax error.
The third page "Restrictions" of the wizard for report line descriptions in the application "Report definition" (REPDEF) was redesigned. The selection boxes for transaction development columns and posting keys are now displayed as tables behind each other with registry tabs. Thus they are considerably larger and simplify the search for the desired keys.
The action "Position account allocation" in the applications "Report definition" (REPDEF) and "Report line descriptions" (REPZEI) now branches off into the respective page of the application "Chart of position definition / account allocation" (POSDEF).
Just like up to now already for development transactions you can now specify one report to be the default report for forms entry of account balances (I-KTOSAL). Therefore this designation now is permitted for reports of report type 'E' (b/s p&l report), too. Then this report is preselected when calling the application 'I-KTOSAL'.
If you use the possibility for long descriptions for accounts and/or positions (see above) you can control by new settings in the report header how these descriptions shall be printed by default. You have the following options for the field "Print long descriptions":
In addition, for the first two options you can specify the width of the column by specification of the "Print number of characters".
When printing a report the print option page for long descriptions is preselected with these settings, however they can be overwritten on demand.
The import/export formats were adjusted to the current database extensions.
The runtime of the import applications was reduced by the introduction of a cache (temporary storage) for error messages. This affects especially import jobs with repetitions of the same error messages e.g. due to a systematic error.
The action "Display list" for the lines "Chart of positions", "Positions" and "Position/account allocations" in the applications "Import" (IMPORT) and "Import/export job control" (IEJOB) now branches off into the respective pages of the application "Chart of position definition / account allocation" (POSDEF).
Since upgrade to Release 2017 the import of account master data took considerably more time if accounts were provided with modified validities since the period specific position/account allocations introduced with this release had to be adjusted to the modified validities. Now the import of accounts was significantly accelerated by optimisation of the database accesses. Nevertheless the validity of accounts should be restricted only in reasonable cases.
When importing account or position master data now descriptions with a length of more than 70 characters can be taken over (see above). For this purpose the fields K010-BENEL-KTO and K022-BENEL-AGG, respectively, were supplemented in the import/export formats. As far as the length of descriptions does not exceed the former maximum length of 70 characters the description fields already existing can continued to be used. The columns I105_BENE1_KTO_UC and I106_BENE1_AGG_UC in the import database tables I105 or I106, respectively, were extended to a length of 255 character providing that no adjustment of interfaces is required here.
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.
When unloading sub-group data it is now checked whether the unloaded currency conversion parameters refer to companies which are not contained in the sub-group. If this the case the currency conversion parameters of these companies are additionally unloaded to allow for a currency conversion of the transferred companies in the destination database.
When unloading group-wide data it is now checked whether there are check rule / positions referring to accounts or controlling objects from company charts of accounts or controlling objects, respectively. If this is the case these accounts and controlling objects are unloaded and transferred in addition to the group-wide data. This enhancement is especially useful if the data exchange is used to transfer group-wide as well as sub-group data from one source into the same destination database.
From Release 2016 on IDL offers a standard interface named "IDL Smart Connectivity for SAP" for the transfer of data relevant for consolidation from SAP to IDL.KONSIS. This interface is based on the Netweaver technology and thus on the most recent technology for unloading of data from SAP. IDL Smart Connectivity for SAP is available for the old general ledger as well as for the new general ledger. It is a proprietary development of IDL which allows our customers the highest flexibility and extensive automation of the transfer of structure (chart of accounts, companies, ...) and transactional data (account balances, intercompany balances, development transactions, ...) in interaction with the Microsoft Integration Services. Within this it is assured that the SAP system guidelines with respect to authorisations and CTS (Change and Transport System) are followed completely.
The solution has been certified by SAP.
Of course, Interfaces from SAP to IDL.KONSIS realised in the past at our customers which were implemented based on IDL.IMPORTER and SAP Connectivity can be used continuously. We emphasize our customers to check for migration to IDL Smart Connectivity for SAP.
If you are interested in the new SAP interface please contact the IDL hotline or your contact person in the IDL sales.
The Release 2018 contains the current edition of the DCW interface for DCW release 3.50.