The release 2014.0 includes changes and enhancements to the products IDL.KONSIS.FORECAST, IDL Connector (old), IDL.XLSLINK (new name for IDL Connector (new)), IDL.PUBLISHER, IDL.EBILANZ and IDL.FINREP. The product IDL.DESIGNER for adhoc and web reporting is new. The installation of the products depends on the corresponding licence.
The 2014.0 release is a major release and therefore it must not be left out of the release sequence. The minimum requirement for this release is the last major release 2013.0 dated September 3rd, 2013.
The amendments and corrections that have taken place up until the release closure for the major release 2013.0 are contained in this major release, too.
Due to changes in the nomenclature of the consolidation function codes (KVA) for deconsolidation the release 2014.0 should not be installed during a running group financial statement, especially not at occurrence of disposals from the group companies.
Please note for statements over the cast of the year that deconsolidation events in previous periods that generated consolidation vouchers with the consolidation functions 'KS' or 'NF' have to be repeated in the current period after release update.
You should always perform a database backup before you install a new release. To prevent a user from losing data, a notice on the necessity of backing up data will be issued by the installation program at the start of installation.
A JDBC connection to the database emphasized since several releases has now become obligatory. A usage of IDL products without this connection is no longer possible. The former ability to suppress this connection in the login dialogue is dropped.
For MS SQL Server databases besides the JTDS JDBC driver delivered by IDL the JDBC4 driver offered by Microsoft can be used, too. This driver is delivered by IDL, too, and can be selected in the login dialogue on demand.
You must always perform the release migration (see ch. 2.2) first, after a new release has been installed. For this reason, a message will be issued when you start IDL.KONSIS.FORECAST for the first time after installation of this release to let you know that migration has not yet taken place. This message box has now been expanded to include the button 'Start migration now'. If you click this button, migration will start automatically. Following successful completion of the migration on this way, IDL.KONSIS.FORECAST does not need to be restarted again. All of the applications will be available immediately.
If migration is not started in this manner, for instance because the logged in user does not have access rights, all other applications will be locked. The only exceptions are the applications that are used to maintain authorization data, in case the logged-in user is not authorized to carry out migration, due to the use of individual authorization groups. Following manual completion of migration, you will need to start IDL.KONSIS.FORECAST again to ensure that all of the application functions are available again.
The release 2014.0 uses version 1.7 of Java. For all local installations as well as for an IDL.KONSIS.FORECAST Application Server IDL delivers the corresponding JRE (Java Runtime Environment) in the installation directory. This does not apply for remote internet clients connected to the IDL.KONSIS.FORECAST Application Server via web-start. There the JRE has to be updated by the users themselves (Java update to the most recent version due to automatic proposal).
The database management system DB2 from IBM is ultimately supported with release 2014.0. Please change to another DBMS before installing the subsequent release 2015.0. The new product "Adhoc and Web Reporting" (see below) already does not support DB2 any more.
The operating system MS Windows Vista is ultimately supported with release 2014.0. Please change to a more recent operating system before installing the subsequent release 2015.0.
The read and write functions of IDL Connector (old) are ultimately delivered with release 2014.0 and not further developed afterwards. From release 2015.0 on only the newly developed product IDL.XLSLINK (up to now IDL Connector (new)) is available for these purposes. IDL.XLSLINK requires at least the version MS Excel 2007.
Furthermore it is intended to support only IDL.KONSIS.FORECAST installations with an IDL.KONSIS.FORECAST Application Server from release 2015.0 on. Other installation configurations will no longer be supported. The IDL.KONSIS.FORECAST Application Server is already now presupposed by the products IDL.DESIGNER and IDL.CONSOLIDATION.MONITOR.
A JDBC connection to the database emphasized since several releases has now become obligatory. A usage of IDL products without this connection is no longer possible. The former ability to suppress this connection in the login dialogue is dropped.
For MS SQL Server databases besides the JTDS JDBC driver delivered by IDL the JDBC4 driver offered by Microsoft can be used, too. This driver is delivered by IDL, too, and can be selected in the login dialogue on demand.
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 will complete the following transformations in the database:
The supply of business unit records (UBR) representing the top node (root) of a hierarchy (UBRUBR) with the new aggregation flag '0' invented for this purpose (see below) is not performed by the release migration program but rather already by the release installation.
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:
Furthermore please pay attention to the newly designed applications callable by the continuously existing menu IDs MISPAR and UMS which comprehend the functionality of the former single record applications MISPARE or UMSE, respectively. In case additional authorisations for update, insert, delete and copy have to be supplemented.
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 log lists for master data changes (additional component with an own licence) is now available for users with the authorisation groups IDLKON, IDLKON1 and IDLVIEW (or IDLWIN, IDLWIN1 and IDLWINVW, respectively, for IDL.WINKONS).
When deleting a user from the user table (USE) the startup data (VOR, VORADMIN) for this user are automatically deleted, too. This deletion is now registered in the log table for startup data (VORLOG).
User groups are now differentiated between usages for menu authorisations (BENMEN) or object authorisations (BENOBJ, BENABR, BENDEF). A mixed usage is furthermore supported. The new flags are set by the release migration due to the existing data.
A new integrated application "User group authorisations" (BENDEF) has been implemented for maintenance of object authorisations allowing for the definition of the user groups themselves as well as the grant and drop of authorisations for the different master data objects (periods, facts, groups, companies, charts of accounts, charts of positions, report definitions).
When invoking this application it displays all defined user groups in one table. New user groups can be inserted (star icon) with aid of a wizard or existing groups can be modified (pencil icon), copied or deleted. Copying and deleting comprehends the allocated object authorisations, too.
After selection of a user group for data in the leading table (double mouse click or "Open" / eye icon) further tables are displayed as one tab per object type available for authorisation administration. The title of each tab shows the object type and the number of authorised objects. The leading table is automatically faded out and the key of the selected user group is displayed in the navigation bar.
The tables per object type display the authorised objects on the top of the table and afterwards all objects not authorised. You can grant authorisations for the latter ones via object menu. Two actions are distinguished: grant only read authorisations and grant all authorisations. More differentiated authorisations (e.g. update allowed, deletion not allowed) can be granted or revoked in a wizard. The withdrawal of all authorisations is supported via the object menu, too.
This application also allows for the grant of authorisations for IDL.FORECAST objects (scenarios, rule templates) where the actions "Display", "Delete" and "Update" can be assigned to scenarios while additionally the new action "Execute" can be granted to rule templates. The authorisations for rule templates can be assigned to the rule template sets of IDL.FORECAST, too. Then these authorisation are inherited by the sub-ordinate sets and templates if no deviations are specified there. Inherited authorisations are represented by a grey hook.
For the purpose of controlling the application of these authorisations for a user two new authorisation flags for the object types "scenario" and "rule template" were supplemented in the "Startup data + authorisation" (VORADMIN). These flags are initialised with '1' (authorisation for all objects) by the release migration providing the maintenance of the previous state.
The object authorisation for copying has been generally dropped. It is replaced by checks for authorisation for reading of the source keys and for inserting of the destination keys.
The IDL.KONSIS.FORECAST Application Server requires a 64 bit environment from release 2014.0 on. 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.
When using the IDL.KONSIS.FORECAST Application Server the configuration of an internal user is required. 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.
The IDL.KONSIS.FORECAST Application Server is prerequisite for usage of the new products IDL.DESIGNER (basis for "Adhoc and web reporting") and the app IDL.CONSOLIDATION.MONITOR. Additionally, adhoc and web reporting requires the IDL Workplace Server.
The chapters 3.1 up to 3.12 refer to the user interface of IDL.KONSIS.FORECAST.
The ability of switching between different "Looks & Feels" in the options dialogue has been dropped. The representation now is always performed in the look & feel "Modern UI".
The icons <Cut>, <Copy>, <Paste> and <Delete> were removed from the main toolbar. Their usage had been very limited since they referred only to single field contents. Furthermore the icons for expanding and collapsing of tree structures were removed from the main toolbar. Instead of they are displayed in the toolbars of the tables providing a unique allocation.
Different icons were redesigned for improved clarification of their meaning and differentiation to other icons.
Deactivated icons are now greyed out in a different style for a better distinction to other activated icons. Clickable icons of the toolbar are coloured red when moving the mouse over them signalling that a mouse click invokes a function.
In many cases actions are only offered yet in one place avoiding redundancy between action menu, context menu and toolbar.
The look of several dialogues (info display, licence info, mass update, mass copy, find, wizards etc.) as well as the progress bar were adjusted to the look & feel of "Modern UI". This applies to the buttons contained there, too.
The background of table lines changes between brighter and darker shades of grey now yet only for flat tables. Lines of tree tables uniquely receive a brighter grey background.
Selected table lines and cells are now emphasized only yet light by background colour (red shade) but rather by a red frame. When selecting single cells the selected cells in case merge to blocks.
Application windows lying above each other are now displayed with aid of tabs allowing for a more simplified navigation to these pages. The former representation and navigation via a drop down box is omitted. For very many tabs the navigation is supplemented by a scroll bar.
The head texts of the tabs are no longer underlined but rather written in fat letters.
Scrollbars now again contains buttons with arrows at their ends. Furthermore the colour of the scrollbar changes when the mouse moves over it.
The navigation bar (display of the calling sequence in the first line of an application tab) was supplemented by the entry "Start". A mouse click on "Start" closes the current application incl. all applications in the sequence and displays the resource tree (see below) in the application area.
The entries <Cancel> and <End> being displayed at the end of each action and context menu up to now were removed. Instead of the button <End> you can now click the left arrow or the preceding entry in the navigation bar with the mouse for displaying a refreshed view of the preceding list. As an alternative to the button <Cancel> (display of the preceding list without refresh) you can use the <Esc> key.
The essential keys of the selection area of the application currently visible are displayed behind the final application entry in the navigation bar. The selection area automatically fades out or in, respectively, when clicking on these parameters with the mouse.
The clickable entries of the navigation bar are coloured red when the mouse moves over them signalling that a mouse click invokes a function.
The drop down box at the short word entry field ("History") does no longer display any icons for the applications lastly called since the application names are shown. The only exception is a book icon for documentations for distinction to executable applications.
The former representations "Resource tree" and "Quick start" for selection of menu items (applications) which could be faded in from the side borders of the application window have been dropped in favour of a new representation. This new representation uses the complete application area as far as no application is active in IDL.KONSIS.FORECAST or in the application tab currently opened, respectively, e.g. after opening an new tab.
This new representation displays either only the executable applications or only the documentations. The interchange between both displays is achieved by a new icon in the global toolbar which shows an info icon for switch into the documentation view or a gear-wheel for switch into the application view depending on the current view.
The display itself is organised like the previous structure, however, a representation as list has been chosen instead of a tree view. The different blocks are displayed one beneath the other below the respective node header. You can shift the display with the pressed mouse key to the left or right.
A more quick navigation can be achieved using the icons displayed in the bottom of the window. Each icon represents a main node of the resource tree and provides the display of the respective section. Another additional icon in the global toolbar showing either one or three dots controls that only the menu of the selected section is displayed or that the other sections are displayed, too.
A single mouse click on an entry provides the call of the corresponding application or documentation, respectively.
The contents of the resource tree have been modified in the following items:
This new representation of the resource tree requires Java components contained in the Java Runtime Environment delivered by IDL as well as in the version Java 1.8. Thus it does not work for users using IDL.KONSIS.FORECAST via web-start in connection with Java 1.7. In this case the resource tree is displayed in the previous representation.
Selection areas providing the key entries for list applications are no longer displayed above the table but rather on the left side beneath the table. The labels of the entry fields are located above the entry fields to avoid an unnecessary width of these areas. Translations of the entered keys as well as other output fields are omitted. Entry fields with identical length provide a smooth view. The essential advantage is the visibility of more lines of the table.
The distinction of the selection area into a reduced and an extended part was maintained. A triangle icon with a circle around displayed in the bottom of the selection area replaces the former buttons named <Reduced> and <Extended>.
If a selection area is faded out (i.e. shifted into the left border) by clicking on the respective button in the top right corner of the window for the purpose of having more space for the data displayed in the table, then the selection area of subsequently called lists is automatically faded out, too, as soon as the <Refresh> button is clicked. Then even more columns are visible in the table.
The entry in the left border is provided with a button for re-display of the selection area. However, a mouse click on the text "Selection" fades the selection area in the window and it disappears again after its usage.
The essential keys are now listed as parameters in the navigation bar since the keys entered in the selection area are no longer visible if the selection area is hidden.
Due to the displacement of the selection area there is no longer a place for a customer specific logo which therefore had to be disposed on the screen. However, the display of the logo in the print output was maintained.
The selection of table lines and cells with the mouse in the IDL.KONSIS lists was adjusted to the behaviour of IDL.FORECAST. A mouse click into the scrollable area no longer selects complete lines but rather only single cells. Only a mouse click into the fixed area (keys) selects complete lines.
The find function, too, only selects single cells. The button <Find next> in the find dialogue was removed. Instead of the find function always determines the next place of finding.
Like until now a mouse click in combination with the <Cntl> key allows for selection of several cells which, however, are no longer completed to blocks. The previous icon for switching the selection mode between cell and line selection is disposed.
The call of subsequent applications is furthermore possible in both selection modes. The summation function can now be applied to arbitrarily collected selections. The diagram function automatically complements the executed cell selection to complete blocks.
Up to now the summation function was only allowed on columns with doubtless assignment of a sign or a debit/credit flag providing for a correct result in terms of accounting if amounts from different columns were added. Now summation is supported on all other columns, too, e.g. in the report result list. Then the amounts are simply added as they are displayed. However, in this case the user is responsible by himself that only totals of comparable summands are added.
The filter line is now switched off by default at start of IDL.KONSIS.FORECAST but can be switched on on demand. This setting then applies for all newly opened tabs.
The list of existing values in the filter line now shows icons if icons are displayed instead of internal coding in the respective column. E.g. this concerns the status columns of the monitor applications or the help text/comment columns in several lists.
With aid of the filter line you now not only filter for contents of the respective column but for background colours, too, in addition, e.g. for status colour [red] in the column "Transaction development" of the list "Account balances" (KTOSAL).
If a filter is already applied for a column then the drop down boxes of the filter cells are restricted to those values that remain after application of the first filter.
For the purpose to arrange the context menus of the tables more clearly it was decided that there should be no redundancy between the context menu and the table specific toolbar. I.e. all actions or subsequent applications available via an icon in the toolbar (amongst others "Create new data", "Edit data", "Mass update", "Mass copy", "Display comment") are no longer displayed in the context menu.
The confirmation message "Object has been modified" after successful performance of mass copy was disposed.
The mass delete request "Delete records without confirmation?" was replaced by the request "Do you really want to delete ... record(s)?". Answering <No> provides for the display of the single record display like up to now.
The options dialogue <Colours> now offers only two predefined colour sets, the standard colour set with stepped shades of blue and a new colour set with stepped shades of grey.
The background of the help text and comment editor is no longer displayed dependent on the length of the text lines but rather shown in unique white.
The ability to distinguish between a productive and a test system using different colour settings is no longer available in the look & feel "Modern UI". As an alternative you can now provide the test system with a watermark. For this purpose you have to add the following entries (for instance) in the area [DISPLAY] of your ini file (accessible via menu bar <File> -> <Help> -> <Info> -> <Open ini file>):
The text assigned to the first parameter (e.g. "TestDB") is displayed in large letters in the application window. The numerical value of the second parameter is a measure for the transparency of the text and may not exceed the range between 0 and 100. If missing the default value is 20.
As far as the new "Adhoc and web reporting" (see below) is used a "Portal" web application allows for branching off and navigation into the different IDL solutions and products.
A <Home> button (house icon) was supplemented in the global toolbar of IDL.KONSIS.FORECAST for branching off into the "Portal". However, this <Home> button is only visible if the parameter "homePath" is specified in the ini file and supplied with a valid URL. Missing entries of "http://" are automatically supplemented.
Several newly designed applications for maintenance of master data contain a wizard where, amongst others, the descriptions of the objects can be entered and updated. This page now allows only for entry of the descriptions in the language of the current user. The wizards contain an additional page allowing for the maintenance of texts in foreign languages displaying all descriptions in all languages.
Newly designed master data applications with dependent tables (e.g. "Transaction development definition") now display the key of the selected and opened object (e.g. the transaction development) in the navigation line. In addition, now for the dependent tables, too, a column exhibits the existence of a help text. Help texts can be viewed and updated here.
A flag specifying the fact as a fact for financial planning (for the PLAN or FORECAST area in IDL.FORECAST) was supplemented in the fact master data. This flag is evaluated at carry forward of company statement data (see below) into the next period with a deviant source fact. The intermediate distinction between usage as PLAN or FORECAST fact, respectively, has been disposed.
A flag specifying the fact as a fact with maintenance of account balances was supplemented in the fact master data. This flag is initialised by the release migration program due to the existence of account balances on the respective fact. The purpose this flag is the ability to define facts which serve only for intercompany clearing without providing the intercompany account balances with a [red] status because of missing agreement with account balances (see below).
The selection box for companies in several other applications reduces the displayed companies to the companies allocated to a group as far as a group has been declared. In this case the group companies now always refer to the "ex fact" assigned to the actual fact.
When changing the validity of companies in case the validity is inherited by mere intercompany accounts (accounts with a fixed intercompany). The message box stating the updated mere intercompany accounts now can be suppressed at mass update of companies.
A new value '0' (scheme) was invented for the aggregation flag of business units beside 'X' (aggregation). '0' identifies UBR records used as the top node of a hierarchy of business units. UBR records which occur only as super-ordinate object in the business unit hierarchies (UBRUBR) but not as sub-ordinate object are automatically provided with '0' during release installation. '0' must not be assigned if the UBR record occurs as sub-ordinate object in the business unit hierarchies of if already reported data for this business unit are present.
The former applications "Charts of positions" (POP) and "Positions" (POS) were comprehended to a new integrated application "Charts of positions" (POP). After start of this application all defined charts of positions are displayed at once. Here you can also insert new charts of positions. This is supported by a wizard offering a first page for entry of descriptions and validity and a second page for entry of further attributes. A third page optionally allows for the entry of descriptions in other languages.
When selecting of a chart of positions by double mouse click or clicking on the <Open> button (eye icon) the related positions are displayed in a second table. The leading table is automatically hidden in the left border and the key of the selected chart of positions is displayed in the navigation bar.
Positions can be inserted or modified with aid of a wizard, too. Again the first page serves for entry of descriptions and validity, a second page for entry of further attributes and a third page optionally allows for the entry of descriptions in other languages.
In addition, updates are possible directly in the table. For this purpose you have to select "Tablecells editable" from the context menu (right mouse key) of the table. Then all editable columns are displayed in blue colour. In the leading table only the line with the selected chart of positions can be edited.
Of course it is possible, too, to delete single positions as well as a deleting or copying a complete chart of positions. All changes are not immediately written into the database but rather yet when pressing the <Save> button (disc icon).
The former application "Positions" (POS) is still available e.g. for copying of selected positions to another chart of positions.
The descriptions of the account flags 'C', 'W' and 'X' were modified with respect to their usage in IDL.KONSIS.FORECAST:
You can now allocate an account with a deviating balance sheet / p&l flag if both accounts are located either in the balance sheet or in the p&l and it is not a mixture of effective and statistical accounts.
A flag "Default for consolidation" was supplemented in the controlling object master data. With the aid of this flag you can specify one controlling object per chart of controlling objects which is automatically entered in consolidation postings if no object is present for the respective controlling dimension although it is required due to the account definition.
The table for products / product groups was enhanced by fields for controlling objects of the controlling dimensions 2 to 10. These fields are connected to the elimination account and have to be entered if this account is a controlling account for the respective dimension. The fields are hidden if the corresponding controlling dimension is not activated. The entries are evaluated by the elimination of current assets result (ZU, see below).
Transaction developments are now always provided with development areas. I.e. even a simple development now has at least one area. The release migration program (see above) generates such a development area with the key '0' and the description "Standard" for all transaction developments without development areas. This generated transaction area is balance relevant. Its properties can be modified on demand. The attribute "with development areas" disappears.
The former transaction development properties "Carry-forward type", "Automatic calculation of changes" and "Transaction development with currency rate average per month" are no longer specified for the complete transaction development but rather per development area. These properties have to identical for all balance relevant development areas (e.g. in the fixed asset development). The transition of these properties is performed by the release migration program (see above), too.
Note: If a development area for (e.g.) durations, e.g. for a liabilities development, was provided with a posting key with usage tag 'L' only because of a parallel development area for cash flow reporting and thus the transaction development was declared as automatically generated development, this is not recognised by the release migration program. In this case you have to modify posting key and development area manually (setting of a valid-until period, removing the usage tag, deleting the flag for automatic calculation).
When selecting a transaction development by double mouse click in the application "Transaction development definition" (SPIDEF) the leading table of transaction developments is automatically hidden in the left border. The key of the selected transaction development is shown in the navigation bar.
The dependent tables displayed then (Development areas, Development columns, Groups for account / posting key allocation, Posting keys) show a column for the definition of comments. Displaying and editing these comments is now supported, too.
In addition, updates are possible directly in the tables. For this purpose you have to select "Tablecells editable" from the context menu (right mouse key) of the table. Then all editable columns are displayed in blue colour. In the leading table only the line with the selected transaction development can be edited.
The <View> menu option "Show internal info columns" now controls the output of the reservation tag (automatically set depending on the usage tag) in the table of posting keys of the application "Transaction development definition" (SPIDEF). The reservation flag controls whether a posting may be used in manually entered data.
The former application "Transaction developments" (SPI) is disposed since its functionality is contained in the application "Transaction development definition" (SPIDEF).
The files delivered in the directory "LieferBatch" with release 2014.0 for import of standard data were supplemented in the following items:
The new flag for account balances in the fact master data (see above) is evaluated. If this flag is switched off then no error state [red] with respect to missing agreement with account balances is displayed for intercompany account balances (and other detail data). A new icon (blue ball) or the status colour [blue], respectively, is displayed instead indicating the existence of data which cannot be compared to other data.
When refreshing the status in case the company financial statement monitor (EA) reports a note if there are data with and without business units simultaneously for a company. This message now can be suppressed at mass-refresh for several companies.
The context menu (right mouse key) of the table was revised. Several actions callable via toolbar or double mouse click (e.g. status refresh, lock company financial statement) were removed from the context menu. A call for "Company financial statements + monitor for entry" (I-EA) now replaces the former calls of the various forms entry applications. The former sub-menus "B/s reconciliation" and "I&E reconciliation" were comprehended to the sub-menu "IC reconciliation". This sub-menu also contains the menu items "Lock intercompany account balances" and "Unlock intercompany account balances". The sub-menu "Processings" was split into the new sub-menus "Carry forward into new period", "Transition to new fact", "Currency conversion", "Deferred taxes" and "More functions...". These new sub-menus also contain the corresponding calling and parameter applications as well as check functions.
A double mouse click into a column without specific function now no longer provides the call of a subsequent application. The formerly practiced branch into the list "Account balances" (KTOSAL) is yet performed on double mouse click into the respective status column.
A new action in the sub-menu "Lists" allows for a direct branch into the "Adhoc and web reporting" (see below) with transfer of parameters as far as the corresponding licence is present.
The status values of the company financial statement monitor and other essential information are displayed within the mobile app IDL.CONSOLIDATION.MONITOR, too. This app is available for Windows 8.1 and iOS from the respective app stores. The installation of the IDL.KONSIS.FORECAST Application Server is preconditioned for usage of this app.
Just like the list for group processing controls (KVERARB) now the company financial statements list of processing controls (VERARB) translates message numbers with the long message texts. This applies for the log list (VERARBLOG), too.
Several entry fields have been removed from the selection area since the corresponding restrictions can be entered in the filter line as well.
If data stocks for balances or development transactions exhibit differences in group or parallel currency then these differences are no longer reported in details per account. Rather one global message with reference to a missing currency conversion is output since these differences generally can be cleared by a (in case repeated) currency conversion. This item concerns account, intercompany and controlling balances as well as all development transactions.
The context menu of the application "Company financial statements + monitor for entry" (I-EA) was revised analogously to the company financial statement monitor (EA) (see above).
When double clicking into a red status cell of the column "Transaction development" in the form entry application for account balances (I-KTOSAL) then the system branches off into the forms entry application for development transactions (I-ANLBEW, I-KAPBEW, I-RUEBEW or I-SPIBEW, respectively). In this case now the account number is transferred as a parameter and the sort option 'K' is preset providing only the display of data for this single account. However, if you wish to enter data for the complete transaction development in one report form then you have to branch off via the action menu (from the menu bar) without selection of lines.
After entering data for single accounts (or data sets restricted otherwise) the information concerning the complete data stock is no longer displayed. Besides development transactions this concerns the entry of account, controlling and intercompany balances, too.
The forms entry application for fixed asset transactions (I-ANLBEW) was redesigned now providing for the entry of data per account instead of entry per fixed asset object (allowing only for the entry of data for the standard fixed asset object per account). Thus additionally defined fixed asset objects like the ones generated by the merger function are considered, too. When entering data the usage of the standard fixed asset object (prefix + account number) is assumed. Deviating fixed asset objects have to be specified in the additional dialogue.
The transaction date of participations / shareholding transactions (GESGES) is now a required entry field without initialisation with the actual period. Thus the user is pointed to being very careful with this entry since the transaction date has an essential influence on carry-forward (see below) and capital consolidation.
If several shareholding transactions are provided with the same transaction data, this might cause problems at capital first consolidation. Therefore now a corresponding warning is output at "Check & refresh participations".
The table of participations / shareholding transactions was enhanced by an attribute for the assimilating company at side stream merger (see below). It has to be entered for additions from merger (new posting key usage tag 'B19').
The entries for group and consolidation voucher number are deleted if attributes relevant for consolidation are modified in an intercompany fixed asset transaction. Then the group status 'ZA' becomes [red] at status refresh.
Columns for controlling objects for the controlling dimensions 2 to 10 were supplemented in the table for inventories IC-Stocks. These attributes are related to the elimination account and have to be entered if this account is a controlling account with allocation to the respective dimension. The corresponding fields are hidden without activation of the respective controlling dimensions. The entries are evaluated at elimination of current assets (ZU, see below ).
As the description already tells the posting type 'EP' (Single use posting for periods of less than a year) now no longer must be used in periods for annual statements.
You can now copy postings to another posting record number within the same voucher.
Like already up to now for consolidation postings now parallel transaction development areas are supported for company statement postings. If a development area is defined to be automatic but not balance relevant and a posting is entered with a posting key of the balance relevant development area, then automatically a posting with the same amount and the posting key for automatic actual changes (usage tag 'L') is generated. This way you can create a cash flow report including postings on this fact which agrees with the report on the next fact (without postings).
Up to now a check rule was set to invalid and thus was not evaluated if a check rule position referred to an account whose chart of accounts did not match to the current keys (fact, company). Now this happens only yet if all accounts declared in the check rule positions belong to deviating charts of accounts. Thus you don't have to define separate check rules per chart of accounts. Rather it is possible to define a check rule referring to accounts from different charts of accounts. Then the positions with accounts from deviating charts of accounts simply are ignored.
The exchange rate code 'E' (EMS central rate) now may only be used in connection with the currency conversion method 'RST' (Closing/current rate method). The conversion was yet already performed independently from the currency conversion method with the closing date exchange rate.
When calling the list "Exchange rates" (WKZWKA) out of the list or the single record application "Currency conversion parameter" (WUM), then the currency code of the parallel currency is now transferred as a parameter if the selected company has local currency equal to group currency.
The lists "Account currency conversion rules" (KTOUAW) and "Account currency conversion audit trail" (KTOUMR) now allow for a group companies selection (display of all companies of the group companies) with respect to the group companies definition in the "ex fact". In addition, you now can specify the language of the account descriptions in the list KTOUMR.
The entry of the consolidation voucher number as a proof of a performed capital first consolidation is now maintained at carry-forward (copying) of shareholding transactions (GESGES) over the cast of the year. Thus the group status 'KK' remains [green] if the group statement had been carried forward (copied) over the cast of the year, too, and no new facts are present. Only shareholding transactions with a transaction date less than the destination period are overwritten in the destination period.
When carrying forward data of transaction developments with several checked development areas the not balance-relevant development areas are always adjusted to the balance-relevant development area providing the consistency of the data carried forward even if there were differences in the previous period.
If a source fact different from the destination fact is specified for carry-forward and the destination fact is declared as a fact for FORECAST or PLAN data (see above) then in case the data are comprehended to a plan aggregation account declared in the account master data.
The functions "Check carry-forward into new period" and "Check transition to new fact" now report yet only differences between the expected and the existing data in the message window. No message window at all is output if the data agree. Then the result of the check is only visible by the [green] status in the respective column of the company financial statement.
In addition, the function "Check transition to new fact" now reports yet only differences in local currency. Differences in group or parallel currency can have different reasons (e.g. no currency conversion in the lower fact, rounding differences by comprehension of balances and postings) which are independent from the transition.
At the end the currency conversion for company financial statement data performs a check of all converted data stocks, amongst others for exhibition of the actual status in the company financial statements monitor (EA) and for calculation of actual check sums. However, errors determined by this check (e.g. differences between account balances and detail data are no longer reported since in general there is no connection with the currency conversion.
The repeated output of error messages from the currency conversion (e.g. "No account balances existing", "No currency conversion header found") now can be suppressed in the check box. Thus a mass-processing in the company financial statement monitor (EA), the list "Currency conversion parameter" (WUM) or a workflow automat is no longer interrupted.
An automatic compensation of differences between the balance sheet result and the p&l result is performed using the account with account flag 'U' for companies differentiated into business units only for the p&l while the balance sheet is specified only for the total company. The total of the balances of this account over all business units has to be zero. The currency conversion now provides for this requirement not only in local but in group and parallel currency, too. Rounding differences are cleared in the balance sheet business unit.
The flag "Balancing of deferred taxes" in the consolidation parameter 'LT' is now evaluated when posting deferred taxes in the company financial statement. I.e. deferred taxes on assets and liabilities are disclosed separately if this flag is switched off.
Messages with respect to missing parameters are output more specifically when invoking the calculation of deferred taxes in the company financial statements monitor (EA).
The calculation of deferred taxes now can be invoked within a workflow automat as far as only one fact is required as parameter.
The merger of two companies with respect to vouchers and postings is supported by a function simply copying the vouchers of the perishing company to the assimilating company. Up to now then the original voucher for the perishing company was set to inactive. From now on these vouchers remain active and all postings are explicitely eliminated by elimination postings. These postings are deleted and newly created at repetition of this function.
Development transactions (for development areas with carry-forward) of the perishing company are now completely eliminated with the respective posting key for "Disposal merger" (usage tag 'MF') and in case inserted for the assimilating company with the posting key "Addition merger" (usage tag 'ME'). Up to now only carry-forward transactions were transferred this way.
The description of the application "Group companies + monitor" (KTKGES) was shortened to "Group monitor".
The display of the group companies is now always performed in tree structure. The previous sort options for flat list display are no longer applicable. Exceptions: The table is displayed as a flat list independent from the chosen sort option if
The empty line before the line with the total of the shareholding values is no longer output.
The status [orange] invented yet with release 2013.0 was disestablished again. In case of a message in a voucher header now the status [yellow] is displayed, too. However, a distinction still is made between actions performed when double clicking on a [yellow] state. On messages in the voucher header the corresponding consolidation vouchers are displayed, otherwise the application to be performed for changing the status to [green] (Compensation temporary difference from first consolidation, IC-clearing list) is called.
The information messages KON1967 (Postings affecting result in single use vouchers) and KON1968 (Development postings in single use voucher) in consolidation voucher headers are no longer transferred into the group processing control (KVERARB) and thus no longer provide the status [yellow] in the group monitor (KTKGES).
The context menu (right mouse key) was tightened. Amongst others the actions "Company financial statements monitor", "Shareholding/participations", "Check rule results", "Group processing controls" and "IC clearing list" are omitted since they can be reached via double mouse click on the respective column. "Account balances" and "Capital transactions" no longer can be called directly, rather they can be called in two steps via the company financial statement monitor. The sub-menus "Processings" and "Locks" were removed, since actions dispose which can be called via the toolbar. In addition, several menu items were renamed more concisely.
A new action in the sub-menu "Lists" allows for a direct branch into the "Adhoc and web reporting" (see below) with transfer of parameters as far as the corresponding licence is present.
The status values of the group monitor and other essential information are displayed within the mobile app IDL.CONSOLIDATION.MONITOR, too. This app is available for Windows 8.1 and iOS from the respective app stores. The installation of the IDL.KONSIS.FORECAST Application Server is preconditioned for usage of this app.
Entries for a validity interval ("valid from", "valid until") were supplemented in the table for consolidation function codes (KVA). The entry for "valid from" is initialised by the release migration program for all KVA codes with the first period defined in ABR. The entry of "valid until" is set to the last period defined in ABR for all disabled KVA codes and these codes are designated as "internal". In addition, disabled KVA codes are deleted if they are neither used in consolidation voucher numbers nor as reference KVA for reporting. Disabled KVA codes are: 'AO', 'EE', 'EM', 'GA', 'JU', 'KA', 'KE', 'KL', 'KM', 'KS', 'KV', 'KX', 'KY', 'LA', 'NF', 'NX', 'NY', 'VA' and 'VL'. These lines are no longer displayed in the KVA list and the KVA selection dialogue if the flag "Hide data with valid-until entry" is set in the start-up data (VOR).
The nomenclature of consolidation functions codes (KVA) for deconsolidation (cash and non-cash) was revised. The former codes 'KS', 'KX', 'KY', 'NF', 'NX' and 'NY' are no longer valid. They are replaced by new KVA codes starting with 'X' for cash disposals and 'Y' for non-cash disposals, respectively. The second character (replacing 'Y') refers to the eliminated original voucher (analogue to merger):
In addition, the new KVA code 'PD' was invented for elimination or reposting, respectively, of dividends for a merger. However, a code for processing of vouchers from consolidation of debts by the deconsolidation (e.g. 'XS') was not inserted since vouchers with posting type 'WX' are not processed by deconsolidation.
In addition there are new consolidation function codes 'On' ('n' = '0' to '9') which are used for several simultaneous mergers onto the same assimilating company to omit double use of the same voucher number. These KVA codes are automatically generated on demand.
The new codes 'XK' and 'YK' are used instead of 'KS' and 'NF', respectively, as reference consolidation function (see below), for consolidation parameters, check points of the group processing control (KVERARB) and the status columns in the group monitor (KTKGES). This transformation is performed by the release migration program even for existing data. However, existing consolidation vouchers and postings are not modified by the release migration. The dropped KVA codes receive a "valid until" entry with respect to their last usage.
A consolidation parameter 'KB' on its own was introduced for the function "Difference amount subsequent consolidation" (KB).This parameter contains accounts for difference amount subsequent consolidation, retained earnings and neutralisation and is generated by the release migration according to the respective entries in the consolidation parameter 'KK' as far as the account "Difference amount subsequent consolidation" had been entered there.
In return the account "Difference amount subsequent consolidation" was removed from the consolidation parameter 'KK'.
An account "Appreciation participation" for posting of appreciations (see below) was supplemented in the consolidation parameters 'KK' and 'EK'.
The display and selection for the consolidation function (KVA) of the vouchers were replaced by the display and selection of the reference consolidation function defined in the KVA master data. Like before this reference refers to the function responsible for creation of these vouchers and allows for a corresponding selection when branching off from the group monitor (KTKGES) via double mouse click on a green status cell. This new interpretation has the advantage that changes of the reference KVA affect old and new vouchers in the same way avoiding a disruption.
Each consolidation voucher should contain only postings for companies named in the voucher number. Otherwise differences might occur at disposal from the group companies (deconsolidation) as well as in report sub-groups. Therefore now a warning is output when entering a consolidation posting for a third company.
As the description already tells the posting type 'EP' (Single use posting for periods of less than a year) now no longer must be used in periods for annual statements.
The list "Consolidation postings" (KONBUCH) now exhibits missing entries of required controlling objects in the table with [red] background just like already for missing posting keys and fixed asset objects.
The designation of missing entries is now applied to automatically generated consolidation postings (depreciations, neutralisation, result etc.), too.
You can now specify one controlling object per chart of controlling objects to be the default object for consolidation (see above). Then this controlling object is automatically written into the respective dimension of the consolidation postings if this entry is required with respect to the account definition. This especially concerns consolidation postings on accounts from the consolidation parameters at activation of more than one controlling dimension since the consolidation parameters only allow for the entry of a controlling object for the first controlling dimension.
The data displayed in the list "Transactions and consolidation postings" (KONBEW) now can be exported. For this purpose a standard export format was defined containing columns for key, description, position, account, development column, posting key, group companies, amount and debit/credit flag. You can supplement additional individual export formats in the applications "Import/export format IDs" (IEF) and "Allocations import/export fields to formats" (IEFFEL).
Records from the table "Group processing controls" (KVERARB) now can be deleted with the rights of the authorisation groups IDLADMIN and IDLWINAD. E.g. this can be used to suppress the status display of a consolidation function started accidentally. The deletion is logged (application KVERARBLOG).
Several fields have been removed from the selection area of the IC clearing list (KGESGES) since the corresponding restrictions can be performed using the filter line.
Status values except for 'KF' and 'VK' (carry-forward from the last annual statement) are no longer copied at carry-forward of group statement data over the cast of the year. Rather the status of consolidation functions for the copied vouchers is newly determined in the destination period. In addition, the vouchers of the consolidation functions 'EF' (Update equity), 'FF' (Update minority interests) and 'KB' (Difference amount subsequent consolidation) are no more copied since they generally are based on monthly changing data.
Only consolidation vouchers which had been generated by the carry-forward over the cast of the year in the destination period and now are newly copied are deleted at repetition of the carry-forward over the cast of the year. Thus vouchers newly generated in the destination period are maintained.
The entries for group and voucher number of shareholding transactions (GESGES) are maintained at carry-forward over the cast of the year providing that the status 'KK' remains [green] at simultaneous carry-forward of consolidation vouchers. However, if shareholding transactions are kept in foreign local currency leading to a different amount in group currency, then the entries for group and voucher number are deleted providing that the status 'KK' becomes [red].
At carry-forward of postings for transaction developments with several checked development areas the data of the non-balance-relevant development area is adjusted to the data of the balance-relevant development area providing that postings carried forward are consistent for a transaction development even if there had been differences in the previous period.
Plan aggregation accounts are now considered in the carry-forward of group statement data just like for company financial statement data before. It is required for this consideration that carry-forward is performed with specification of a deviating source fact and that the destination fact is declared as fact for PLAN/FORECAST data (see above).
The message with respect to 'KF' vouchers carried forward in the sub-group in connection with status [T] is no longer output at carry-forward in the superordinate group.
The function "Check carry-forward" now displays yet only differences between expected and existing data in a message window. If, however, the data agree no message is output any more. The result is only visible by the status [green] in the respective column of the group monitor (KTKGES).
Appreciations in shareholding (transactions with the posting key with usage tag 'B06') are now treated like depreciations (usage tag 'B05') by the capital first consolidation. The account for the cross entry can be specified in the consolidation parameters 'KK' (for full and quoted consolidation) and 'EK' (for consolidation at equity). Without an entry of this account appreciations are not considered like before.
The elimination of current assets (ZU) now provides the postings on the elimination account with controlling objects of all 10 controlling dimensions provided that the account is allocated to these dimensions and corresponding entries exist in the inventories IC-stocks (ICVOR, see above) or in the product / product group master data (PRO, see above). If entries exist in both data tables the entries in the inventories IC-stocks are preferred. Without these entries the elimination account of the consolidation parameter 'ZU' is used but controlling objects (except for dimension 1) are determined from the standard controlling objects per chart of controlling objects (see above). Controlling objects used or to be used are displayed in "List for elimination of current assets results" (ZWERGUV), too.
Companies with consolidation type 'E' (at equity) are excluded from this processing.
The "List for elimination of current assets results" (ZWERGUV) now allows for a modification of the parameters for group, period, fact and company, e.g. for display of data of a sub-ordinate sub-group or the previous period with selection of the corresponding group companies before. Especially you now can chose '%' for the company providing for the display of inventories IC-stocks for the complete group companies.
The "List for elimination of current assets results" (ZWERGUV) now exhibits missing entries for consolidation (elimination account, overhead/direct percentage or amount) with a red background colour. This representation is not possible in the company financial statement but only from the group point of view since only this list gathers data from different sources (inventories IC-stocks (ICVOR), product margins (PRO), products / product groups (PRO), consolidation parameters (KTKPAR)).
The consolidation function "Cash flow repostings" (FU) now generates one voucher per company instead of one voucher per group since a consolidation voucher should only contain postings for the companies named in the voucher number (see above). Thus you can now invoke this function per company for refresh of single vouchers. Accordingly the status 'FU' in the group monitor (KTKGES) is shown per company.
If a company is added simultaneously to a sub-group and the superordinate group companies, then the carry-forward development transactions may be reposted only in the sub-group even if additional participations are held in the superordinate group. Therefore the status 'KU' is displayed as [T] in this case.
The merger functionality now supports a sidestream merger, too. For this function it is required that both, the assimilating and the perishing company, belong to the same shareholding company with a share of 100%.
The entry of the merger parameter (date and assimilating company) in the company master data are required for this instance, too. In addition, the merger function for the company financial statement can be applied just like for upstream merger.
The merger is represented with two shareholding transactions (using the merger date as transaction date) for the shareholding company: disposal of the perishing company with a share of -100% with the existing posting key for merger (usage tag 'B16') and addition of the shareholding value with a share of 0% and the new posting key for merger addition (usage tag 'B19'). The perishing company has to be entered in the addition transaction for the purpose to distinguish several simultaneous merger actions.
The consolidation function now generates the following vouchers:
Carry-forward transactions of exchange rate effects on the net result posted without effect on the net result are now exhibited below "Other changes not affecting net income".
The deconsolidation function (cash and non-cash) now eliminates all consolidation vouchers of the disposing company. The only exceptions are vouchers with the posting type 'WX' (e.g. from consolidation of debts). The new consolidation function codes (see above) are applied for the elimination vouchers.
A monitor for IDL.FORECAST has been realised as an application on its own callable via short word 'PM'. This "Forecast monitor" displays several status values per company and business unit for a selected scenario provided that the scenario had been defined for the company / business unit. In addition, a group can be entered for selection of companies allocated to the group companies. This first version of the monitor displays the following states:
The status values are visualised by the traffic light colours or icons [red] (rhomb), [yellow] (triangle), [green] (hook) or [dash] just like in the IDL.KONSIS monitors. In addition, the user and the timestamp of the last modification of the scenario are displayed.
A new separate application "Forecast sequences" callable via short word 'PA' serves for the definition and processing of planning sequences. With this application you can determine a set of companies and which steps have to be processed within the sequence. Possible processing steps are here:
Another new application "Forecast sequence parameters" callable via short word PAPAR allows for the specification of parameters for forecast sequences. Parameters are:
A forecast sequence parameter is allocated when starting a forecast sequence in the forecast monitor (PM).
You can now assign authorisations for the object types "Scenario" and "Rule template" to users and user groups. Provided that the entry '2' (control via user group authorisations) has been entered in the new flags of the user startup data (VORADMIN) you can grant authorisations for viewing, changing and deleting of scenarios and rule templates in the new application "User group authorisations" (BENDEF, see above). In addition, you can grant a right for execution of rule templates.
The authorisations are correspondingly evaluated in the scenario list and the display of rule templates.
You can now determine the configuration of the displayed table columns in the scenario list, the list of rule templates, the list of applied templates and the balance differences list using the object menu (right mouse key) of the respective table header. Up to now an icon in the toolbar of the respective window had been used for this purpose.
The functions "Undo" and "Redo" now work on entry, modification and deletion of comments, too.
A column was supplemented in the scenario table exhibiting by an icon (book) whether a comment has been stored for the scenario. Another new column shows the names of additional individual tables and liquidity reports.
A warning message is output if it is specified for a scenario that plan account aggregation is applied without classification of the facts for the PLAN or the FORECAST area as PLAN/FORECAST fact. For this purpose the classification of the facts as ACTUAL or PLAN/FORECAST facts is displayed in the selection list of facts.
The setting of "Decumulation of ACTUAL/PLAN" can be determined for the complete scenario with the scenario wizard.
Certain rarely used settings are no longer displayed in the scenario wizard. They rather can be set in a separate window which can be reached via the button "Advanced settings". This concerns the options "With null/empty differentiation", "Apply rules on ic balances" and "Rules across data areas".
From now on automatically all intercompanies present in the scenario because of existing data (ACTUAL, FORECAST, PLAN) are displayed in the scenario. Further intercompanies can be added each via context menu.
Within this you can select several intercompanies. Then the new intercompanies are valid for all accounts. The filter for intercompany accounts has been supplemented by new check boxes ('I', 'J', others).
The dialogue for the intercompany settings is only required for adding intercompanies to the scenario or removing intercompanies from the scenario. Existing settings of intercompanies for all accounts are no longer considered. In case the action "Use minimized IC-Settings" can be used.
You have now the ability to transfer account, controlling and intercompany balances from IDL.KONSIS independent from each other. Corresponding flags have been supplemented in the load-balances dialogue. If account and controlling balances are imported simultaneously then the splashing and summation flags for controlling are switched off. If account and intercompany balances are imported simultaneously then the splashing and summation flags for intercompany are switched off.
The data of the areas FORECAST and PLAN now can be written independent from each other into the IDL.KONSIS tables (e.g. KTOSAL).
The refresh of statistical data now no longer refers only to statistical amounts (b/s p&l flag '5') but rather to all statistical data (b/s p&l flag '5' to '9').
The setting for the display of the check block of the planner spreadsheet (cumulated / decumulated) is now entered via the menu <View>. The setting is emphasized by adding the texts "cumulated" or "decumulated", respectively, to the entries for "Income" and "Expenses".
A comparison between the data of the scenario and the IDL.KONSIS account balances is now even possible if the account balances are stored on a deviating fact.
The windows for account, controlling and intercompany details were comprehended to one window where you can switch between the different views. Thus the details can be moved or hidden in one step instead of each window separately.
You can delete manual changes for an account balance via a new action "Delete account entry (modify balance)". Then the account balance is adjusted corresponding to the automatic account changes. However, another new action "Delete account entry (keep balance)" turns all manual changes into automatic changes providing for their usability in rules.
The wizard for liquidity reports was enhanced by a button which opens a window displaying the existing liquidity reports. If you select one of them this report can be edited in the wizard. Clicking <Change> replaces the existing report while clicking <Ready> (like before) inserts an additional report.
Diagrams which can be displayed in additional individual tables now can be provided with a caption. A new button labelled "Add caption" serves for this purpose. This caption is even printed. Without a caption the name of the application module is output like before.
Formulae of additional individual tables now can use the character '$' in the line or column specification of references to other cells just like in MS Excel. These references are not modified when copying the formula.
The usage of rules can now be restricted to certain companies. This restriction can be specified in all rules on an additional page just like the restriction to certain periods.
If a new account is supplemented belatedly on the page of account allocations in a rule wizard, then there is a new button serving for the automatic definition of the missing allocations just like for the first definition of the rule.
The entries for "Third party", "Intercompanies" and "As per scenario" had become superfluous by the enhanced account allocations and thus have been removed. The adjustment of the rules is done automatically during release migration.
The account allocations of a rule are now displayed in a defined order at repeated loading of a rule into the wizard. The list starts with the base value account followed by the account from the corresponding rule and finally the respective credit account.
The general base value rule now allows for the transfer of the closing balance for intercompany balances, too. Up to now this was only supported for accounts with account flag 'J'. You can now specify separate accounts for the intercompany portion and the third party portion, respectively, in an allocation for accounts with account flag 'J'.
A dissolution component was supplemented in the general base value rule. The dissolution can be defined on an additional page of the rule wizard which is analogue to the terms of payment of the sales rule.
A function for automatic calculation of payment components was supplemented in the dissolution rule. The calculation (just like already in other rules) can be performed in days.
A page for "utilisation" was supplemented in the wizard of the provision rule. The utilisation can be activated in a check box. In addition, a credit account has to be entered for dissolution of the utilisation. Furthermore there is a table similar to the dissolution/payment components. You can determine timestamps in this table specifying e.g. "January, year 1" or "February, year 0".
Up to now a term of payment had been interpreted as "payment in exactly x days" in the sales, purchases, income, expenses, dissolution and base value rules. Now optionally this entry can be interpreted as "payment within x days".
The personnel rule allowed for the entry of two wages/salaries accounts (e.g. for wages and salaries). This option is no longer available since two account allocations can be defined as well if two accounts are desired.
Besides the automatically calculated amortisation table and a complete manual entry of the repayment the investment rule now offers the ability for entry of special repayments. Interest rates and interest payments can be entered separately, too, providing for an automatic adjustment of the amortisation table. In addition, it can be differentiated whether following repayments or the duration shall be adjusted. The following constraints have to be considered:
The investment rule now allows for the specification of the investment amount in a statistical account and use it from there. Similarly the amortisation duration can be specified in an account for statistical quantities (b/s p&l flag '5'). The statistical account is locked against changes after application of its value in a rule. The specification of a start period is optional for the purpose to use the rule in different periods. Furthermore the investment rule can be provided with an own contribution (absolute amount or percentage value) which, however, neither may exceed the investment amount nor be negative.
Investment and financing rules now no longer possess a description on their own. Rather they are displayed in the business case list with the name of the rule template.
The dialogue for finding double or missing rules was supplemented by the following features:
If a rule template with a period restriction containing periods not present in the opened scenario is opened, then the missing periods are displayed in a separate list on the very right side of the period control page of the rule wizard. The periods are still saved along with the rule template. However, they can be deleted from the list by selecting them and pressing the <Del> key if this is not desired.
A message is output if a rule generates no business cases. This message now specifies more detailed why it could not be applied e.g. by specification of accounts or periods or by notes on locks.
The properties "period control", "intercompany planning" and "usage of parameters" displayed in the list of rule templates are now inherited by the superordinate nodes and displayed there in case.
A new tool named "Adhoc and Web Reporting" for generation (IDL.DESIGNER) and display (within a browser) of reports is offered for the first time with this release. Installation and usage require additional licences. In addition, the licence for the MIS OLAP component is preconditioned.
The adhoc and web reporting allows for a quick and intuitional generation of reports with data from IDL.KONSIS (incl. the account structure of the tab "OLAP" of the application REPDEF) which can be consumed independently from your device (e.g. web, tablet). The report definition and layout are flexible. Graphics and captions can be arbitrarily supplemented. Predefined templates are offered for the layout.
Opposite to the already existing standard reporting historiography and archiving is not supported for these reports.
The adhoc and web reporting is based on data in an OLAP cube (IDL Data Mart) which is filled with data from IDL.KONSIS. Thus the Analysis Services of the MS SQL Server (not contained in the express edition!) is required for this component. The relational databases Microsoft SQLServer and ORACLE are supported, however, IBM DB2 is not supported. In addition, an IDL.KONSIS.FORECAST installation with an IDL.KONSIS.FORECAST Application Server is preconditioned.
The adhoc and web reporting consists of the desktop application IDL.DESIGNER for design and generation of reports and the ability to view the created reports in the web. The reports can be accessed with touch usage as far as the user uses a touch-capable device. The reports are stored in a folder structure (report catalogue).
Each user has to identify himself at the system. A corresponding user and role administration is provided. In addition, the required connections to databases have to be configured. The object authorisation defined in IDL.KONSIS.FORECAST is considered when granting authorisations.
The IDL portal (see above) provides the possibility to branch off to IDL.KONSIS.FORECAST. Likewise the IDL.KONSIS.FORECAST monitor applications EA (see above) and KTKGES (see above) contain branches into the adhoc and web reporting.
The former application "Report idents" (RID) is no longer present since its functionality is contained in the application "Report definition" (REPDEF).
The applications "Company reports", "Group reports" (REPK), "Report header" (REPK) and "Report" (REPERG) now offer only report idents in the selection box which are valid in the specified actual period.
After opening of one of the displayed report definitions now the leading table of defined reports is automatically shifted into the left border and the key of the selected report is displayed in the navigation bar.
Changes are now allowed directly in the tab "Tree", too. For this purpose you have to select "tablecells editable" from the context menu (right mouse key) of the table. All columns which allow modifications are displayed in blue foreground colour. The leading table "Reports" only allows for modifications of the line of the report currently opened.
The possibility to define new positions within the application "Report definition" (REPDEF) was extended by functions for changing and deleting positions, e.g. to correct accidentally or wrongly defined positions immediately. Changes on positions are immediately and independently from the usage of the save button saved in the database.
For an improved visibility of the possibilities for position maintenance the position table is displayed at once when opening a report description. Up to now a special button had to be pressed for this purpose. Positions already contained in the report are now displayed grey instead of coloured. A filter line was supplemented for the position table.
A new function "Set default allocation" is available on the tab "OLAP". This function generates an OLAP allocation for evaluation of the report structure in IDL Data Mart or individual BI interfaces. Allocated positions (nodes in the usual tree structure of the tab "Tree") and In/Ex addition stores (total lines without tree structure) are evaluated for this generation. However, this allocation should always be checked once more.
Due to the changes of the nomenclature of the consolidation function codes (KVA) for deconsolidation (see above) the existing definitions for cash flow reports have to be checked for references to the expired consolidation function codes ('KS', 'KX', 'KY', 'NF', 'NX', 'NY') and in case be replaced by references to the new KVA codes ('Xx', 'Yx').
The applications for maintenance of "Report column options" (SPO), "Report column descriptions" (SPA) and the associated "Formulae editor" (FED) were comprehended to a new integrated application "Report column definition" (SPADEF).
When invoking this application a list of all defined report column options is displayed without any selection. For restrictions the filter line can be used.
The star icon ("Create column option") has to be clicked for entry of a new column option. Then a wizard opens for entry of the basic properties of the option. This wizard is similar to other new wizards (e.g. in the applications SPIDEF and REPDEF).
Alternatively an existing column option can be opened by double mouse click or selection of the line and clicking the eye icon ("Show report columns"). Then the table of report column options is automatically shifted into the left border and the key of the selected column option is displayed in the navigation bar.
Now a second table is opened in the application area and displays the defined report columns for the selected option. Beneath the properties of the columns (like in the previous application SPA) the allocated formula is shown in text form as comprehensible as possible. If the formula length exceeds the columns width it is abbreviated with "..." at the end. The complete formula in a multi-line format is shown as a tooltip on the cells.
For entering or editing of the properties of the column a wizard can be opened here, too, by clicking on the star icon ("Create report column ...") or the pencil icon ("Edit report column ..."), respectively. The wizard consists of three pages (pages 1, 2 and 4) for administration of the attributes previously maintained by the application "Report column descriptions" (SPA). Entry fields without meaning with respect to the column option are automatically deactivated.
The column number is no entry field in the wizard. New columns are automatically provided with the next free number. The order of the columns can easily be modified by drag & drop with the mouse in the table (picking with the mouse, dragging to the desired position and then dropping).
An additional page (page 3) in the wizard serves for the definition of the formula of the column. It contains a window in the upper part of the page where the current formula is displayed. A direct editing in this window is possible, however, it is emphasized only for skilled users. This editing is supported by an auto-complete function. Alternatively the formula can be built by mouse clicks on several buttons for operators and drop-down boxes for the available operands. When clicking on one of the star icons ("insert ...") the corresponding operand is inserted into the formula.
The last two lines in this window ("Column option" and "Report column") allow for copying of a complete formula from one of the other column options providing that especially complicate formulae (e.g. for longer totals or relative deviations) do not have to be newly constructed.
Updates are possible directly in the table, too. For this purpose you have to select "table lines editable" from the context menu (right mouse key) of the table. All columns which allow modifications are displayed in blue foreground colour. The leading table "Report column options" only allows for modifications of the line for the column option currently opened.
All changes have to be committed by clicking on the disc icon ("Save column definition") before the data are saved in the database. A warning message is output when leaving the application without saving modified data.
The icon "Delete column option" serves for the complete deletion of a report column option including all columns and formulae. In addition, a complete column option can be copied including all columns and formulae, too.
The previous application "Report column options" (SPO) is no longer present since its functionality is contained in the application "Report column definition" (SPADEF). However, the application "Report column descriptions" (SPA) is still usable e.g. for comparison of column descriptions between several report column options. The application "Formula editor" (FED) is still required for formulae of business ratios.
Data from the list "Report" (REPERG) now can be exported. For this purpose a standard export format was defined containing columns for key, description, group, company, business unit, period and fact (keys of the complete report) as well as position, account, keys of the detail level 1 to 3 and value columns 1 to 4. You can supplement additional individual export formats in the applications "Import/export format IDs" (IEF) and "Allocations import/export fields to formats" (IEFFEL).
Note: The standard export format '#TXT' for the time being only contains a small number of columns as required for simple data exports. Since later extensions are to be expected it is not emphasized to use this format for continuous data preparation. Rather it is recommended to work with additional formats defined by the user.
A new integrated application allows for the maintenance of object sort definitions for the allocated objects. It replaces the former lists "Object sort definitions list" (OBJSORT) and "Object sort definitions column reference list" (OBJSORTSP) and the appended single record applications. The new application is called via short word OSV.
When invoking the application it displays a table with all defined object sort definitions without any selection. New object sort definitions can be added when clicking the star icon. A wizard serves for the entry of key, descriptions and validity. This wizard also serves for updates of existing object sort definitions (pencil icon). Updates are possible in the table, too. For this purpose you have to select "tablecells editable" from the context menu (right mouse key) of the table. All columns which allow modifications are displayed in blue foreground colour.
A double mouse click in the table or the eye icon provide the opening of the selected object sort definition. Then the leading table is automatically shifted into the left border and the key of the selected definition is displayed in the navigation bar.
Further tables showing the sorted objects are displayed instead. There is one table per object type. The tables are displayed as tabs and the tabs are labelled with the object types. In addition, in brackets the number of allocated objects is shown if not zero.
For the object type placed in the foreground an additional table is displayed on the right showing all other objects of this object type. You can insert one of them into the object sort list at the desired position by selecting, dragging and dropping the object with the mouse. The same technique can be used for changing the order of the allocated objects in the sort definition. The deletion is performed using the toolbar of the table.
All changes have to be committed by clicking on the disc icon ("Save column definition") before the data are saved in the database. A warning message is output when leaving the application without saving modified data.
The description of the calling application for import processing has been shortened to "Import".
The table now displays only those menu items (data stocks) which can be imported by the user with respect to his authorisation. The authorisations of the user groups IDLEA and IDLWINEA were revised in this context.
The export/import formats (IEFDEF, IEFFEL) and tables (I1nn) for CNT, PRO, KVA, SBE and ICVOR were extended by the respective new columns due to the descriptions above.
New export formats have been defined for the lists Report (REPERG) and Transactions and consolidation postings (KONBEW).
A new integrated application allows for the maintenance of transformation groups and the allocated objects. It replaces the former lists "transformation groups" (UMS) and "Transformation group objects" (UMSOBJ) and the appended single record applications. The new application is called via short word UMS, too.
When invoking the application it displays a table with all defined transformation groups without any selection. New transformation groups can be added when clicking the star icon. A wizard serves for the entry of key, descriptions and validity. This wizard also serves for updates of existing transformation groups (pencil icon). Updates are possible in the table, too. For this purpose you have to select "table lines editable" from the context menu (right mouse key) of the table. All columns which allow modifications are displayed in blue foreground colour.
A double mouse click in the table or the eye icon provide the opening of the selected transformation group. Then the leading table is automatically shifted into the left border and the key of the selected group is displayed in the navigation bar.
Further tables showing the transformed objects are displayed instead. There is one table per object type. The tables are displayed as tabs and the tabs are labelled with the object types. In addition, in brackets the number of allocated objects is shown if not zero.
These tables show on the top the defined transformations and below all objects of the respective object type. The latter can be distinguished by the missing entry of the external object ID. These objects can be supplemented to the transformation group with a double mouse click. Then a wizard opens allowing for the entry of the external object ID as well as additional parameters for companies and business units.
Updating the existing transformations (pencil icon) is possible, too. However, the wizard allows only changes on the additional entries for companies and business units. The update of the external object ID is only possible via delete and insert. Deletion is performed using the delete icon.
An additional table on the right side displays all transformations defined in other transformation groups for the object type placed in the foreground. This allows for a simple copy of transformations from other transformation groups by selecting the items and performing drag and drop with the mouse to the table on the left.
All changes have to be committed by clicking on the disc icon ("Save column definition") before the data are saved in the database. A warning message is output when leaving the application without saving modified data.
The application "Import IC-p/l-thereof-account balances" possibly generates new accounts and position/account allocations for the new accounts. If the user has no authorisation for inserting position/account allocations for a chart of accounts then now this generation is simply not performed. Up to now the processing of the intercompany account balance had been aborted with an error possibly leading to inconsistent data. The message "Authorization problem while duplicating POSKTO-entry for aggr.acc." (KON2828E) is output for information. In the same way the message "Authorization problem while inserting account-duplicate with suffix I" (KON2827E) is output if the authorisation for insert into the chart of accounts is missing.
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 grid lines of tables are now no longer displayed in white (like in IDL.KONSIS.FORECAST). Rather the standard grid line colour of MS Excel is used for xlsx files while black is used for xls files.
For table columns represented as a check box in IDL.KONSIS.FORECAST now a green hook is output in the column of the Excel file for activated check boxes.
If the automatically generated name of the Excel file contains prohibited characters (e.g. "/", "\", ":", "?"), then these characters are replaced by an underscore character ("_").
The read and write functions of IDL Connector (old) are ultimately delivered with release 2014.0 and not further developed afterwards. From release 2015.0 on only the newly developed product IDL.XLSLINK (up to now IDL Connector (new)) is available for these purposes. Therefore it is recommended to migrate to IDL.XLSLINK before installation of the subsequent release 2015.0.
This does not apply for the Excel entry sheet which is not available within IDL.XLSLINK.
Due to changes in the nomenclature of consolidation function codes (KVA) for deconsolidation (see above) the existing connector references have to be checked for usage of the deactivated consolidation function codes ('KS', 'KX', 'KY', 'NF', 'NX', 'NY') and adjusted to the new KVA codes ('Xx', 'Yx') if applying.
| MS Office Version | Read and Export Function (central) | Entry Form with activated Connector (central) | Entry Form without activated Connector (decentral) |
|---|---|---|---|
| 2003 | OK | OK | OK |
| 2007 | OK | OK | OK |
| 2012 32-Bit | OK | OK | OK |
| 2012 64-Bit | OK | not released 2) | not released 4) |
| 2013 32-Bit | OK | OK | OK |
| 2013 64-Bit | not released 1) | not released 3) | not released 4) |
Reasons for missing release:
The product name IDL.XLSLINK replaces the former designation IDL Connector (new). IDL.XLSLINK requires at least the version MS Excel 2007.
If IDL.XLSLINK already has been used with the release 2013.0 the following steps are required for migration to release 2014.0:
IDL.XLSLINK now is available in the installation variant with web-start, too. For this purpose the IDL.KONSIS.FORECAST start mode has to be set to 'N' in the settings. This setting is saved in the ini file but can be overwritten by a parameter named in the command in the icon (e.g. "/KONSISMODE:J") providing that different configurations can be distinguished by several icons.
The installation (or deinstallation) of the IDL.XLSLINK Addin is not possible if an Excel process is running. In this case a note is output reporting that Excel is active and has to be stopped. If this is not provided in a reasonable time a question is output whether Excel shall be cancelled. Answering "Yes" provides the end of all Excel processes while "No" provides an abort of the installation/deinstallation.
The user interface of IDL.XLSLINK was adjusted to the look & feel of "Modern UI" (see above) of IDL.KONSIS.FORECAST.
The functionality of IDL.XLSLINK was completed with respect to the possibilities of IDL Connector (old). Especially all read and write functions with the corresponding fields are provided in the XLSLINK references.
This applies for the migration of existing Excel maps, too, including the protection by a connector password. Opposite to IDL Connector (old) IDL.XLSLINK can provide each sheet with a password on its own (menu "Tools").
IDL Connector (old) maps provided with a connector password can be migrated immediately. The migration of files protected only with an Excel password is supported by an additional Excel map which contains an empty sheet per password used which is protected with this password as IDL.XLSLINK password and Excel password. Before migration this map has to be loaded using the IDL.XLSLINK menu item "Excel -> Extras" -> "Connector Password (file name)".
The references of IDL Connector (old) allowed for the selection of the entry <REF> in the drop down boxes of all entry fields. Afterwards you could navigate through your Excel map to the respective cell and use its address as reference. Because of the different architecture of IDL.XLSLINK this handling cannot be offered in this way.
Instead of the context menu of Excel was extended with the entry "IDL clipboard". Using this menu item the address of the selected cell is intermediately stored. You also can select several cells for the purpose of storing the addresses of all of them. The entry fields of the IDL.XLSLINK references contain a new item, too, allowing for a copy of a stored address into the field.
IDL.XLSLINK allows for multiple entry values per entry field corresponding to the <LIST> function of IDL Connector (old). For this purpose the selection lists contain an additional column where a hook can be entered for the selected values. Then all values selected this way are considered for reading of data.
If a cell contains several formulae combined e.g. with '+' then the results of the single formulae can be output on a separate work sheet using the mode 'M'.
If a cell contains a formula with several connector references then you are asked whether all of these references shall be modified via mass-update when opening this reference. Answering with 'Yes' provides for opening of a dialogue where general parameters like "System" or "Mode" con be modified. Answering with 'No' provides for an abort of the action.
References with fields dependent from each other (e.g. chart of accounts / account number, transaction development / posting key) contain separate entry fields. To avoid misentries now the value of the dependent field (e.g. account number, posting key) is automatically cleared when changing the value of the leading field (e.g. chart of accounts, transaction development).
Some entry fields in the reference maps are now activated or deactivated dependent from the entries in other fields. So e.g. the fields "Voucher no." and "Posting affecting net result" in the read function "Account balances" (EAKTOSAL) are only activated if 'BUCH' (only postings) had been specified for the balance option.
The entry of total positions (positions without direct allocation of accounts) in the read functions is supported by IDL.XLSLINK only in connection with the specification of an origin report.
The software for IDL.PUBLISHER comprehends the functions of the product IDL.EBILANZ, too, for the last time. From the subsequent release on these products will be separated. The software of these products is installed in the installation path in the subdirectory "Components" depending on the user licence. If you have installed a product in a different location you have to copy the installed directory to this location.
The new version number '04' was introduced for MIS parameters to support the new component IDL Data Mart (Basis of the Adhoc and web reporting). MIS parameters with version number '04' can be used exclusively for IDL Data Mart but nor for the function "Create MIS data tables". On the other hand the previous version numbers '01' to '03' must not be used for IDL Data Mart.
The version '04' is different from the other version in the following items:
The database tables K056 and K057 represent the group structure in a style which can be evaluated by SQL statements. They are used by IDL Data Mart as well as in individual MIS interfaces with MIS parameter version '03'. These tables are now supplied with the group structure data of all group companies (groups, periods, facts) by the release migration program and kept in an actual state for all changes independent from the keys of the active MIS parameter. This comprehends the generation of group companies by carry-forward, too.
The application "MIS parameter" was redesigned. When invoking the application a complete list of all defined MIS parameters is displayed at once without any selection. Entry and modification of MIS parameters are performed with aid of a wizard containing several pages. The first page serves for the entry of a key and descriptions. The second page contains the essential parameters as well as the keys of the different dimensions. The third page contains the flags for consideration of business units and controlling dimensions in IDL Data Mart.
All existing interfaces to SAP delivered or configured by IDL are furthermore executable. If modifications and/or updates are planned for the SAP system then each case has to be analysed whether the interface still meets the requirements.
The first version (V1) of the IDL SAP interface (with kcusap.exe and ABAP function modules) is functioning for the old general ledger. However, it is not developed further any more.
The current version (V2) of the IDL SAP connection with the aid of IDL.IMPORTER and IDL.CONNECTIVITY for SAP (called in IDL.KONSIS.FORECAST via kcusap.jar or pluginlauncher.jar) can be used for the old and the new general ledger. This version is successfully used by many customers for a long time. In this version the ABAP code is dynamically generated and executed in SAP.
A new version of the IDL SAP interface (V3) has been developed, is currently tested in pilot projects and will be available at the end of 2014. This version conforms to the principles of CTS (change and transport system) of SAP by using predefined reports (so called extractors of IDL.IMPORTER which are transferred to the development system via IDL.CONNECTIVITY for SAP). If you are interested in this version please contact the IDL technical support or your IDL BI consultant.
The release 2014.0 CD contains the current edition of the DCW interface for DCW release 3.50.
The Elster interface for the transmission of the E-balance sheet was refreshed. Now the version 19.5.2.0 of the ERiC client from 03/2014 is used.
A plausibility check is now performed before transmitting the E-balance sheet data to the corresponding tax authority. If the check fails the transmission is aborted and the reason of the failure is displayed.
The current project package is exported in XML format and stored in the temporary application path if errors occur during the processing by ERiC.
The following English language documentations have been updated or enhanced in the documentation directory together with this release:
*) For a current version of the hardware and software requirements please refer to the service centre of the IDL web page (www.idl.eu).