The database most recently connected to is now always offered even at webstart login to the IDL.KONSIS.FORECAST Application Server.
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 Update 1 of Release 2014.0 the migration program will complete the following transformations in the database:
In addition to the amendments of Update 1 of Release 2014.0 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 are new, too, however, they do not correspond to IDL.KONSIS.FORECAST applications but rather refer to web-services used by other products of the IDL CPM suite. They serve for control of the authorisation of users of other applications for usage of these web-services.
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 new 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.
The IDL.KONSIS.FORECAST Application Server requires a 64 bit environment. This comprehends a 64 bit JRE and a 64 bit database client for the JDBC connection to the database. However, parts of IDL.KONSIS are running as a 32 bit process. This process uses OLE DB for the database connection and requires a corresponding 32 bit database client.
In addition, the IDL.KONSIS.FORECAST Application Server requires the configuration of an internal user. One of both available authentication solutions (the definition of each user in the database without table access authorisation or the definition of the user and his password in the IDL.KONSIS.FORECAST table USE, respectively) can be specified at configuration of the databases for the IDL.KONSIS.FORECAST Application Server.
A navigation bar has been supplemented in the configuration program of IDL.KONSIS.FORECAST Application Server serving for a quick branch possibility to the page to be modified for supplementary configurations of single parameters.
This configuration program now adjusts individual JNLP files to the newly installed JAR files, too.
You can now import certificates and private keys on the page "SSL certificate key store" using the <Import> button. The format X.509 is supported for certificates. The formats PKCS#12, PKCS#8, MS PVK and OpenSSL are supported with the following properties:
The IDL PORTAL (usable after installation of IDL Workplace Server) now allows for a direct branch into the applications "Planning application" (PLAN) and "Company reports" (REP).
The option for hiding the tool bar is dropped since otherwise there would be no possibility for displaying the tool bar again.
Several familiar short words had been abolished in connection with the introduction of new comprehensive applications for master data maintenance. For the purpose to furthermore use these short words now an automatic redirection to the corresponding short words of the new applications is performed.
After deleting a help text or comment, respectively, via the context menu of the corresponding table line the table is now refreshed immediately. Several help texts / comments can be deleted with one call.
Just like for list applications before now the context menu (right mouse key) of single record applications was provided with a tool bar. Typically it contains icons for display, edit and deletion of help texts or comments, respectively, as well as application specific actions in case. On the other hand these icons were removed from the tool bar of the application window.
The new applications for administration of master data do not contain a selection area providing that the language of the displayed descriptions no longer can be set in this way. As an alternative now a drop down box was supplemented in the tool bar of the respective tables containing all active languages as possible values. This box is preset with the language set in the startup data (VOR). Changing the language in the box immediately affects the descriptions in the table. The language always concerns only this table.
The function key <F2> now serves for a switch into the edit mode of the selected cell just like Excel provided that the mode "Table lines editable" has been activated. The arrow keys can be used to switch from a selected cell to an adjoining cell before pressing <F2>.
If an IDL.KONSIS.FORECAST table shows icons in the table (e.g. status information, locks, comments), then icons are transferred into the Excel cells at "Export to Excel". Please note that this functionality is not supported for the transfer of table cells to Excel via copy and paste.
The application "User group authorisations" displays authorised and not authorised objects in the tables per object type. An additional table "Object authorisations" now allows for an overview of all authorised objects independent from the object type like in the former list application (BENOBJ). No changes are possible in this table. It rather serves for the export of data. However, the following data are not displayed in this table:
It is now possible to arrange facts to sequences. Usually a sequence defines the facts which are passed through the transition of company financial statements, e.g. 'I1' -> 'I2' -> 'I3' -> 'I4'. Such a sequence is comprehended under a key with a suitable description. The corresponding data are saved as pairs of predecessors and successors.
Entry and maintenance of fact sequences are performed with the application "Facts" (FAC). For this purpose the table area was divided. The table on the right hand shows the defined facts like before with their properties. A new table "Sequences" is display on the left hand displaying all defined sequences in tree representation. The sequences themselves represent the nodes, below of them the allocated fats are listed in the defined order.
The <New> icon (star) has to be used for definition of a new sequence. Then a wizard opens for the usual entry of key, validity and descriptions in several languages. The same way existing sequences can be modified.
The facts allocated to a sequence are dragged from the right hand table into the left hand table and dropped there on an edge. Please mind that the position where the fact is dropped decides the order of the fact in the sequence. The order can be modified within the table via drag and drop, too. The <Delete> icon can be used to remove a fact from a sequence.
Each fact may only occur once within a sequence. Another plausibility check at allocation is, that a fact on the level of the company chart of accounts must not be the successor of a fact on the level of the group chart of accounts. All changes are saved immediately in the database without using a <Save> button.
Fact sequences are evaluated at transition (see below) and at lock (see below) of company financial statement data.
A new application "Group definition" (KTKDEF) allows for the integrated maintenance of groups and sub-groups (former application KTK) and group structures (application KTKGES). However, the functionality of the application "Group monitor" (KTKGES) with respect to consolidation workflow and status monitoring is not included.
After invoking the application a list with all defined groups and sub-groups is displayed. Inserting of groups as well as modification of group properties is supported by a wizard. Changes in the table itself is possible in the mode "Table lines editable".
When opening one group / sub-group (double mouse click or <Open> icon) the group table is faded out and the group companies are displayed. Additionally a selection area opens on the left hand allowing for entry of the parameters for period and fact which is preset with the settings of the startup data (VOR).
The table area itself consists of two tables displayed behind each other with registry tabs. The first table "Group structure" shows the group companies in the familiar tree representation of the application "Group monitor" (KTKGES). I.e. the sub-groups represent sub-ordinate nodes for the allocated companies. This table contains only the columns key and description.
In opposite, the second table "Group companies" displays further attributes like addition and disposal date, consolidation method and shareholding percentages in columns. Here each sub-group of the group structure represents a node on the top level with all allocated companies as leaves. I.e. the companies allocated to sub-ordinate sub-groups are displayed several times. An appropriate filter serves for a comparison of the properties of one company in the different group structure levels. Companies with consolidation method 'K' (no consolidation) are hidden here by default.
On the right hand two resource tables with all defined groups or companies, respectively, are displayed serving for the construction and extension of new group structures via drag and drop. I.e. you can pick a group or company from the resource table with the mouse, drag it to the super-ordinate group in the tree table and drop it there. If a company is dropped on a sub-ordinate sub-group, then the company is inserted into the group companies of this sub-group as well as into all super-ordinate groups. A new company is provided with the most probable properties, amongst others addition date = day 1 of the actual period and consolidation method = 'V' (fully consolidated). The first company allocated to a group is designated as its holding. Drag and drop is supported within the table, too, for the purpose of moving companies or complete sub-groups.
The properties can be modified per group company with a wizard whích, however, is available only in the table "Group companies" since the properties may differ between the group levels. Editing in the table is supported, too. Within this the same plausibility checks are performed as in the single record application "Group/sub-group consolidated company" (KTKGESE). If required the modifications are propagated to the super- or sub-ordinate group levels.
The former list "Groups / sub-groups" (KTK) was disposed in this context.
An area "Open tasks" was supplemented in the application "Business units" (UBR). It contains indications of inconsistent data, e.g. multiple occurrence of a business unit in a scheme.
In addition, actions for display, edit and deletion of help texts / comments were supplemented in the context menu.
The hierarchy table now contains '+' and '-' icons for expanding and collapsing of all nodes.
The export function now allows for the export into two different import/export formats:
The flag whether a language contained in the language table is active is no longer updated by IDL at release migration. Thus you have the ability to configure the active languages permanently providing the reduction of the language selection box to the relevant languages.
The maintenance of controlling dimensions and controlling flags 1 were integrated into the application "Controlling definitions" (CTLDEF). Now three tables are displayed behind each other with registry tabs after starting the application: "Charts of controlling objects", "Controlling dimensions" and "Controlling flags".
The data of both new tables can be entered or modified using a wizard. An update in the table is also supported by the mode "Table lines editable". However, the display of controlling objects and their hierarchies is furthermore possible after selection of a chart of controlling objects. Then all of the three initial tables are hidden.in the left border.
The former list applications "Controlling dimensions" (CDM) and "Controlling flags 1" (CK1) were disposed in this context.
In addition, an area "Open tasks" was supplemented in the application "Controlling definitions". This area opens yet after opening of a chart of controlling objects. It contains indications of inconsistent data, e.g. multiple occurrence of a controlling object in a scheme, inconsistencies between the validities of controlling objects and charts of controlling objects or the allocation of allocated group controlling objects not belonging to the allocated group chart of controlling objects.
In addition, actions for display, edit and deletion of help texts / comments were supplemented in the context menu.
The hierarchy table now contains '+' and '-' icons for expanding and collapsing of all nodes.
The export function now allows for the export into two different import/export formats:
The context menu of the table of products / product groups now allows for a branch into the list "Product data" (application PRODAT).
The column header of transaction development areas is now a required entry. To avoid a complete maintenance of these texts at once a preset is performed by the release migration (see above). The column header is composed out of the development transaction short text, a word wrap and the transaction development area short text. It is recommended for later modifications to keep the first line identical with the name of the transaction development for all areas for the purpose to recognise them optically as associated.
Four new posting key usage tags are available for posting keys of the capital transaction development:
The associated posting keys are especially suited to designate dividends which are distributed to intercompanies and third parties with shares different from the shareholding partitions. The entry of an intercompany is not permitted for posting keys with usage tag 'FOI' or 'FMI'. The posting keys are considered at calculation of minority interests with respect to the designation of their usage tags (see below). Posting keys with these usage tags were supplemented in the LieferBatch files of the old as well as the new transaction development standard.
In this connection the former posting key usage tag 'DIV' is disposed. Posting keys with this usage tag are provided with the usage tag 'EOI' by the release migration.
The activation of transaction developments per period and fact is now differentiated into the level of transaction development areas. Correspondingly the former applications / tables "Fact / development" (FACSPI) and "Period / development" (ABRSPI) are replaced by new applications / tables "Fact / development area" (FACSBE) and "Period / development area" (ABRSBE). The former definitions in the database are suitably replaced by the release migration (see above).
Instead of the former applications for list, single record and forms entry now there is only a forms entry application per table which displays the data in matrix arrangement (column option 'M'). Then the development areas are represented in tree structure (developments as nodes) in the lines. In addition a list representation (column option 'L') is available which is merely required for export but doesn't allow for data entry.
The following rules have be followed when entering or modifying transaction development area controls:
The control of the development areas is evaluated instead of the former control per development in several other applications and functions.
The references for IDL Connector were removed from the Excel files of the LieferBatch directory since IDL Connector is no longer supported from release 2016 on. The transition of data is only possible with IDL.XLSLINK.
The files delivered in the directory "LieferBatch" with release 2016 for import of standard data were supplemented in the following items:
Locks of company financial statements now do not affect only the data of the respective fact but rather all preceding facts, too, as defined in fact sequences (see above). If e.g. the statement is locked for fact 'I4' and a sequence is defined using the facts 'I1' -> 'I2' -> 'I3' -> 'I4', then the company financial statements on the facts 'I3', 'I2' and 'I1' are locked, too.
The status for check rule results is now set to [yellow] (undefined) at modifications on postings, too, since postings are processed by the check rule result calculation, too.
The total of the (existing and) entered development transactions is now calculated at restriction to a not balance relevant development area, too. In addition, the differences to the account balances are calculated and displayed, too, if the development area is checked for agreement with the account balances.
Just like for other development transactions now for shareholding transactions (development 'B') transactions with posting keys for additional, not balance relevant development areas are displayed in a separate block providing that the calculation of the total and the check with the account balance can be understood more easily.
The function for mass update was supplemented in the list "Inventories IC-stocks" (ICVOR).
Like before for consolidation vouchers now the feature for locking vouchers due to the "4-eye principle" is available for company statement vouchers, too. For this feature it is a prerequisite that the licence for change logs is present.
Then a change log for company statement postings is usable. It can be activated and deactivated, too, via the application "Control of data change logging" (LOG).
The logged data can be viewed with the list "Changes of postings" (BUCHLOG). Besides for the keys (period, fact, company, business unit, voucher number, account number) here the selection for kind of change (insert, update, delete) and module (which application performed the change?) is supported. The table shows user name and timestamp of the change. Changed attributes are emphasized by a yellow background.
If change log for postings is activated, vouchers can be locked following the 4-eye principle. An action of the context menu (right mouse key) of the voucher list (BEL) serves for this purpose. "4-eye" means that the lock may only be set by a user who is not specified as the last modifier of one of the postings. After locking the voucher no modifications are allowed on its postings. Correspondingly the lock can be revoked again. The main goal of the log protocol is a retrace of all modifications performed between revocation and setting of a lock.
When transposing company financial statement data to the next fact it is now checked whether the transition is permitted due to the defined fact sequences (see above). If the specified destination fact exists in the sequence table as successor fact, then the specified source fact has to be one of the defined predecessor facts.
The specification of an intercompany in capital transactions with posting keys with one of the new usage tags 'EMI' or 'EOI' (see above) is suppressed at carry forward of company statement data into the next period providing that the transaction is not processed by "Consolidation D&C repostings" (SU) for a second time since the corresponding consolidation postings ('SD') are carried forward.
It is now possible to calculate and generate postings for deferred taxes on facts on the level of company charts of accounts. The accounts required for this (up to now only in the consolidation parameter 'LT') can be specified in the "Tax rate" record (LTK). With this opportunity the former "Account for deferred taxes - cost" for P&L postings was split into two separate accounts for cost and earnings.
The specification of these data in the "Tax rate" record allows for the specification of different accounts per company on the level of the group chart of accounts, too, just like it was already possible for the (average) tax percentage. Without specification of accounts in the "Tax rates" record like before the entries in the consolidation parameter 'LT' are applied.
The required transition of company financial statement data at merger of two companies now considers shareholdings of the disposing company on other subsidiaries. They automatically can be copied to the incorporating company and eliminated at the disposing company . This is performed when calling the functions "Merger: Company financial statements -total-" or "Merger of transaction developments". When calling the function "Merger of transaction developments: only disposals" only the shareholding transactions of the disposing company are eliminated.
The application "Group monitor" (KTKGES) is still available with its familiar functionality. However, construction and modification of a group structure now can be performed alternatively with the new application "Group definition" (KTKDEF, see above). It is especially suitable for the construction of new group structures.
When inserting a new voucher classification in the application KVA now the entry of the reference KVA for a consolidation report is preset with the most probable value, e.g. with 'SK' when inserting 'S1'. This entry can be overwritten. This way it is avoided that this entry accidentally remains empty and thus the report becomes incomplete.
The consolidation parameter 'AE' for consolidation I&E was enhanced by an entry field for an account for retained earnings (see below). Without this entry just like for other voucher classifications the account of the consolidation parameter 'KK' is used. In addition, the flag "Accumulation of carried forward" was supplemented in the consolidation parameter 'AE'.
The "Account for deferred taxes - cost" in the consolidation parameter 'LT' for postings for deferred taxes in the company financial statement was replaced by two separate accounts for cost and earnings. Previous entries in this account are copied into both new accounts by the release migration.
Vouchers from consolidation I&E ('AE' as well as 'A0' up to 'A9') are now carried forward. Usually with this the postings on the net result account are carried forward and reposted to the account for retained earnings (new entry field in the consolidation parameter 'AE') providing a correct carry forward check. The voucher classification of these carry forward vouchers is 'AV'. 'AV' vouchers as well as 'AE' vouchers yield the posting type 'WU'.
This supplement was necessary by the representation of the result shift in 'AE' vouchers which, however, can be suppressed by entry of a neutralisation account in the respective consolidation parameter.
Vouchers with the new voucher classifications 'PA' (see below), 'XA' and 'YA' (see below) for disposed companies are processed at carry forward analoguely to other deconsolidation vouchers.
Appreciations and depreciations of shareholdings (posting keys with usage tags 'B05' and 'B06') are now processed in a 'KK' voucher on its own (e.g. 'K0') even if they have the same transaction date as e.g. a capital increase or a participation addition.
"First consolidation" ('KK') and "Difference amount subsequent consolidation" do not process capital transactions with posting keys with one of the new usage tags 'EMI', 'EOI', 'FMI' or 'FOI' (see above).
Consolidation postings for the compensation of the difference amount as goodwill now receive the posting key specified for this account in the consolidation parameter 'KK'. The former posting key (reference posting key of the posting key of the actual shareholding transaction) is used if no posting key is specified in the consolidation parameter.
The application "Perform consolidation minority interests" (FF) evaluates the new posting key usage tags (see above): Capital transactions with 'FOI' und 'FMI' are considered as 100% minority interests, however, data with 'EOI' and 'EMI' are considered as 0% minority interests. Indirect minority interests are calculated only for data with 'EMI' and 'FMI'.
Vouchers from consolidation I&E (voucher classifications 'AE' and 'A0' up to 'A9') are now provided with the posting type 'WU' since in case they are carried forward (see above). Old vouchers which are still provided with posting type 'WX' are carried forward like posting type 'EU'.
The merger function now processes vouchers from consolidation I&E (voucher classifications 'AE', 'A0' up to 'A9' as well as 'AV'). Their elimination is performed in a voucher with the new voucher classification 'PA'.
The deconsolidation function now processes vouchers from consolidation I&E (voucher classifications 'AE', 'A0' up to 'A9' as well as 'AV'). Their elimination is performed in a voucher with the new voucher classification 'XA' (cash) or 'YA' (non-cash), respectively.
Rounding differences at deconsolidation of companies with minority interests (total of equity and minority interests vs. company financial statement) are now compensated.
If the intercompany or controlling details are missing when saving a scenario, then a corresponding message is output in the window for plausibility checks and the status "Balances exist" in the Forecast monitor (PM) becomes [red]. In addition, a warning icon which can be suppressed via a view option is displayed in the planner spreadsheet for incomplete controlling details.
The settings of the balance areas (ACTUAL/FORECAST/PLAN as well as balance sheet/p&l/statistics) are possible when saving a scenario via a Forecast sequence, too.
Parameter settings from now on have to be performed via the action menu (gear wheel icon in the global tool bar). The former setting opportunity via the scenario properties has been dropped.
Like before for the intercompany settings now the controlling details can be set per account, too. The available details can be limited to the details actually used via a new button "Use minimized controlling-settings".
The migration of existing scenarios as well as the loading of controlling balances from IDL.KONSIS pre-allocates this setting per account with the maximum of occurring controlling objects.
When writing balances to IDL.KONSIS it is now possible to control that only the balance sheet, only the p&l or only the statistical accounts are written. This distinction had already been supported when loading balances from IDL.KONSIS.
Intercompany account balances written by IDL.FORECAST are now especially designated for the purpose of maintaining data written by IDL.KONSIS when repeating the export. Thus it is provided, that intercompany balances supplied in IDL.KONSIS with information of controlling, transaction currency and/or clearing are not overwritten since IDL.FORECAST does not provide this information. Data written by IDL.FORECAST and deviating from the existing data are not supplied with this information. In case these attributes have to be entered manually.
The account detail display was revised since the former representation became easily confusing if there were very many rule entries for one account. The display can now be turned into a tree representation. You can select whether the entries are to be grouped by posting type or by contra-account. Then the posting type or the contra-account, respectively, are displayed as nodes. The selection of the grouping can be set via a choice button in the table header.
The splashing dialogue in its hitherto realisation was hard to understand. Therefore it shall be substituted by a new dialogue. Until then the former splashing dialogue was disabled. if it shall be used nevertheless it can be reactivated by inserting the entry "enableSplashingDialog=true" in the ini file.
The functions for revising or repeating the last change (undo/redo) can now be applied to changes on individual table sheets, too.
A wizard for the definition of formulae was supplemented for the purpose of an improved survey of the formulae available in the individual table sheets.
A new tax rule is now available for calculation of the tax on the result of a company. This rule allows for addition or subtraction of costs and/or earnings to/from the result to determine the assessment base of tax calculation. Tax prepayments can be considered, too. The tax expenses can be distributed over the periods of a year continuously or proportionally to the results. In addition, you can specify positions of account balances to be added or subtracted. The tax is calculated at the end of an accounting year without reduction of the basic profit. The rule wizard consists of 6 pages for the following entries:
Also new is a ratio rule. It serves for an indirect calculation of certain balance sheet amounts via ratios instead of the direct calculation from amounts at period begin plus transitions from p&l. The ratio rule allows for calculations similar to the base value rule. Within this the base value is a total of several base value accounts or of parts of them. A ratio can be defined as a firm amount, a parameter or a reference to a statistical account. In addition, a modifier can be specified in forms of a multiplier or a divisor. Depending on the debit/credit flag of the base value different destination accounts can be specified. For the purpose of consistent results all changes are posted against bank. The rule wizard consists of 5 pages for the following entries:
Monthly portions of payment conditions and dissolutions can now be specified as parameter or as reference to a statistical account. However, please mind that the value of parameters and statistical accounts is taken yet at the time of rule definition. To consider a modified value the rule has to be newly defined. The parameter dialogue can be opened out of the dissolution tables. This modification concerns the sales, income, purchases, expenses, provision, base value, dissolution and tax rule.
The setting of a transaction development report to be the standard report for forms entry is no longer performed by the wizard but rather by a separate action in the context menu (right mouse key). Using this action simultaneously provides for removal of this setting at the previous standard report.
The application "Report column definition" (SPADEF) now orders the column options in the way that the user defined options are displayed first followed by the IDL defined options characterised by the initial character '#', since a modification is only allowed for the user defined options.
After opening a column option now two tables are displayed as registry tabs behind each other. The first table shows the column definition like up to now. The second new table "Formulae" displays the calculation formulae of the different columns in the representation of the former list "Formulae editor". This table merely provides for an overview whether all of the desired result columns are referenced in the columns of the column option. However, updates are not possible in this table.
The wizard for modification of a column definition was simplified on the page "Formula". The lower part of the page now offers only the allocation of value columns in the standard view since this is sufficient in the majority of application cases. The additional entry options (positions, constants, functions, copy templates) are shown yet in the extended view after pushing the button "Extended functions". In addition the display of the position of the write cursor in the editor window was disposed.
When entering or updating a report header now a check is performed for consistency of the report option in relation to the report level (group or company) and the report type. Up to now inconsistent entries were allowed here but reported at report generation.
When creating a company report now a notification message is output if the processed company financial statement postings are partially locked (see above) and partially not locked.
With the aid of the new report option 'P' (plan account aggregation) you can now create reports on the level of plan aggregation accounts. This options was invented especially for plan/actual comparison reports and is admitted only for b/s or p&l reports (types 'E', 'P' or 'S').
With this option an aggregation to a plan aggregation account if specified in case is performed for the actual data. Plan data are already present in the aggregated form.
However, the allocation to positions is performed due to the position account allocation of the elementary accounts for the actual data providing that a plan aggregation account might occur below several positions in case. Therefore it is recommended to adjust the position account allocations of elementary and plan aggregation accounts.
The maximum limit of 200 columns for representation of detail levels in columns (e.g. companies of a group report, controlling objects of a controlling report) was cancelled. Due to technical reasons the new maximum number of columns is 440. However, please mind that the export of more than 256 columns to Excel may provide for Excel-related problems.
The application "Object Sort Definitions" (OSV) displays the objects in several tables per object type. In addition there is now another table "Overview" containing the data of all object types. This table does not allow for modifications. However, it can be used for the export function.
When calling an import via command line (e.g. via IDL.IMPORTER) the new parameter /additionalLibraries serves for the entry of an additional path with program files e.g. for the supplement of further jar files in the class path for database drivers.
There were problems with fields with fixed length in the import database tables (I1xx) especially in context with ORACLE databases. These problems can be solved by a conversion of these fields to fields with variable length. However, since this conversion with the release migration would provide for the deletion and new creation of the complete tables for this purpose only a script is offered which can be requested on demand from the technical support of IDL.
The applications for import of the transaction development controls (TXTFACSPI, TXTABRSPI) were replaced by applications for import of controls per transaction development area (TXTFACSBE, TXTABRSBE, see above)
A new import application (TXTBEN) allows for the import of user groups as displayed and exported by the lists "User groups" (BEN) and "User group authorisations" (BENDEF). Please use the already existing applications "Import period authorisation" (TXTBENABR), "Import menu authorisations" (TXTBENMEN) and "Import object authorisations" (TXTBENOBJ) for import of the authorised objects. However, an import of the authorisations for IDL.FORECAST objects (scenarios, rule templates) is not possible.
Another new import application (TXTUMS) allows for the import of the head records of transformation groups as displayed and exported by the application "Transformation groups" (UMS). Please use the already existing application "Import transformation group allocations" (TXTUMSOBJ) for import of the objects to be transformed.
A further new import application (TXTBSG) allows for the import of posting key groupings as displayed and exported by the list "Posting key groupings" (BSG) and the application "Transaction development definition" (SPIDEF).
The application "Transformation groups" (UMS) displays the transformed objects and the objects not to be transformed in several tables per object type. In addition there is now another table "Overview" containing the data of all object types. This table does not allow for modifications. However, it can be used for the export function.
The validity of an intercompany is now considered at import of accounts with firmly allocated intercompanies (mere IC accounts) without specification of the validity. Now the validity of the account is limited in the way that the account is not longer valid than the intercompany. In case, the same applies for the IC business unit.
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.
The limits for the maximum number (up to now 8) of reports, groups and facts associated to an MIS parameter were dropped for parameter version '04' (for adhoc and web reporting via IDL Datamart). Now an arbitrary number of objects can be associated with an MIS parameter.
The maintenance application MISPAR was correspondingly extended. The specification of reports, groups and facts is no longer performed in distinct fields. Rather the wizard contains a page on its own for each of these object types with a container with the associated objects on the left hand and a list of allocatable objects on the right hand. The objects from the list can be supplemented in the container. However, for the parameter versions '01', '02' and '03' the number of objects in the container is still limited to 8 for each object type.
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 automatisation 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.
Currently the solution is in the certification process of 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 2016 contains the current edition of the DCW interface for DCW release 3.50.