The usage of single sign on (transfer of the login to the network to the login to IDL.KONSIS.FORECAST) now is only yet supported with installation of the application server if the function "Interal user" is activated simultaneously.
The login to IDL.PORTAL now is transferred when branching off to IDL.KONSIS.FORECAST providing that a separate login is no longer required.
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 controlling object records (CNT) representing the top node (root) of a hierarchy (CNTCNT) with the new aggregation flag '0' (scheme) 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.
Please pay attention to the newly designed applications callable by the continuously existing menu IDs FAC, GES, KVA, LKZ, PRO, SPR, UBR and WKZ which comprehend the functionality of the former single record applications FACE, GESE, KVAE, LKZE, PROE, SPRE, UBRE or WKZE, respectively. In case additional authorisations for update, insert, delete and copy have to be supplemented.
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:
The Simplified Procedure for Administration of Customer Specific User Groups is recommended as an alternative to complete maintenance of authorisations for all menu items. For this functionality, the new authorisation level '0' can also be specified for menu authorisation (BENMENE). This states that an authorisation available for a reference user group should not be issued for the user group that has been entered.
The IDL.KONSIS.FORECAST Application Server requires a 64 bit environment. This comprehends a 64 bit JRE and a 64 bit database client for the JDBC connection to the database. However, parts of IDL.KONSIS are running as a 32 bit process. This process uses OLE DB for the database connection and requires a corresponding 32 bit database client.
In addition, the IDL.KONSIS.FORECAST Application Server requires the configuration of an internal user. One of both available authentication solutions (the definition of each user in the database without table access authorisation or the definition of the user and his password in the IDL.KONSIS.FORECAST table USE, respectively) can be specified at configuration of the databases for the IDL.KONSIS.FORECAST Application Server.
The IDL.KONSIS.FORECAST Application Server (Jetty) can now be connected to several hosts (URLs) in parallel. The hosts have to be specified comma-separated in the configuration program.
The former main menu had been located behind a folder icon in release 2014.0. This folder icon now has been removed. The functions contained there were newly located:
Several icons were revised or unified. Amongst others the coloured status information (green for locked, yellow for re-unlocked) was removed from the lock icons. The icons now show only an opened or a closed padlock. The icon for "Display report" now shows only an eye capable of being differentiated from the icon for "Create report".
The resource tree (display of callable applications if no application is active) now displays the control applications "Import" (IMPORT), "Forecast monitor" (PM) and "Startup data" (VOR) in an emphasized style and in the first position of the respective branch.
The former <Continue> icon (right arrow) was replaced by a down arrow in the navigation bar providing to proceed to the next of several lines marked in a preceding list application. In front of this icon a progress information "x/y" is displayed where 'y' represents the number of previously marked lines and 'x' the number of the currently used line.
In addition, an icon <Cancel> (stopping restriction> was supplemented beneath the icon <Back> (left arrow). The new icon provides for leaving subsequent applications without refreshing the display of the calling application on return. Alternatively the key <Esc> can be used for this purpose.
The <Continue> button or the <Back> button (if <Continue> is deactivated) now gain the focus. I.e. these buttons are triggered when pushing the <Enter> key as far as no other actions have dislocated the focus.
The buttons of the navigation bar are now coloured red when moving the mouse pointer over them indicating that these buttons can be pushed.
The short word (enterable in the short word entry field) of the application currently active is displayed in the short word entry field in grey letters.
The assignment of function keys was revised due to conventions used in many other applications.
The function key <F1> no longer invokes the context help but rather the application help formerly assigned to <F2> which is no longer in use. The key combination <Cntl-F1> for calling the help text editor is not supported any more.
The function key <F3> causes the return to a preceding application in a subsequent application. If several lines had been marked in the preceding application then <F3> provides for proceeding to the next line. After return the display will be refreshed.
The function key <F12> was disabled. You can use <Esc> instead to cancel an activity or a calling sequence or to return into the preceding list without refresh of the table.
The function key <F5> now can be used for refresh of the display.
The key combination <Cntl-F> invokes the <Find> function.
The key combinations <Cntl-Z> and <Cntl-Y>, respectively, can be used for the functions "Undo" (revoke the last modification) or "Redo" (repeat the revoked modification) in single record applications. However, these keys only work as far as the data are not saved in the database.
Printing is now only yet possible via print preview (see above).
The print preview for help texts was adapted to the print preview for application data as far as this is meaningful.
The option "Long field descriptions" in the <Options> dialogue now provides the display of all field descriptions in the long variant. Up to now there was a border of up to 35 characters providing the display of the (often incomprehensibly abbreviated) short text.
Many selection fields allow for the entry of '*' beneath the entry of the items shown in combo boxes or choice dialogues to select data where the referenced column is empty. The entry '*' is now offered with the text "empty" in addition to other possible entries in combo boxes. After selection or direct entry of '*' and leaving the field "empty" is displayed in the corresponding entry field. Mass-update dialogues behave similar where '*' can be used to delete contents of columns.
The button for refresh of the table was moved from the top to the bottom of the selection area beneath the button <Enhanced>/<Reduced>.
A selection area minimised to the left border is now always fixated in the application area when clicking into the left border. The possibility to expand the selection area temporarily which existed in the meantime is dropped.
Table headers are now always aligned like the column contents (left/centered/right). Table headers for several lines are always centered.
The state of the filter line is now saved (again) and thus applied at restart of IDL.KONSIS.FORECAST.
The behaviour of marks introduced already with release 2014.0 is now adapted by the master data applications of the new kind, too. Now only a mouse click into the fixed table area marks the complete line while a mouse click into the scrollable area marks only the respective cell, too.
The essential actions on the objects displayed in the table represented by an icon are now displayed in a new icon bar in the top of the context menu invoked by the right mouse key. Typically you find here "Edit data", "Delete", "Mass-update", "Mass copy" as well as the help text / comment actions. In exchange the actions displayed in the context menu are missing in the tool bar of the table.
The actions for displaying and editing a help text are disabled if several lines are marked since these actions can be issued only for one line at a time. A new icon in this place serves for a function for deleting a help text / comment. This action can be performed with change authorisation on the object. A confirmation request is issued.
The icon for inserting a new record is no longer located in the global tool bar but rather in the tool bar of the respective table for all applications.
The display in the footer was redesigned. The number of marked lines is no longer shown in the message but in case rather in connection with the total display. If complete lines are marked, "Number: x / y Data: z" is displayed there with 'x' representing the number of marked lines, 'y' the total number of lines in the table and 'z' for the number of lines to be processed in case (e.g. without counting empty lines). If no numeric column is marked only "Number: x" is shown. If numerical columns are marked the display changes to "Number: x / Total: zzz.zz D" where 'zzz.zz' is the total amount and 'D' the debit/credit flag.
Please mind that the number of displayed lines in the footer display (y) may be different from the number of read lines specified in the message. The number in the message represents the number of data read from the database while the table may show additional lines (e.g. total lines).
When deleting data in a list application the confirmation request was changed to "Do you really want to delete n records?". Within this the former ability to switch to the single record application by entering <No> is removed.
The colours of special lines in list applications (e.g. total lines, difference lines) are now independent from the colours for the detail levels of reports defined in the "Options" dialogue. The colours of these special lines are now firmly defined. The following line types are distinguished:
The red background colour for difference amounts was dispensed due to the colour of the complete line.
The text of the water mark (e.g. for distinction of several databases) can now be determined in the options dialogue (up to now only in the ini file).
For the purpose of easier manual entry of master data a field "Default master data valid from period" has been supplemented to the "Startup data" (VOR). If a period is defined here, it will be preset as "Valid from" period when entering new master data.
Entries for the validity of objects on the first page of wizards of master data maintenance applications of the new kind are now validated during their entry and transformed into the correct format after a short delay without leaving the field. This applies for other date or period entry fields accordingly.
The last page of the wizards of these new applications for master data maintenance has been redesigned. For the goal of a more compact view the display now depends on the type of descriptions (long text, short text, table header text) maintained in the application.
For the goal to support file export for all displayed data (e.g. posting key groupings, facts) new import/export formats (IEF) were defined for several tables even if there is not yet any import ability. The application "User group authorisations" (BENDEF) now comprehends the data of different object tables to one export file.
The option for maintenance of check sums now is always enabled since there is an increasing number of functionalities in IDL.KONSIS.FORECAST (e.g. change log, status setting) which require the existence of check sums. The flag for enabling or disabling this option per fact was removed.
Since it is not possible to distinguish during the transition time, whether an existing check sum of zero was caused by the absence of data or the deactivation of check sums, it is now possible that the first newly entered or modified data of a data stock do not provide the status for currency conversion to become [red] although a repetition of the currency conversion is required.
Modifications of data in closed periods on facts defined up to now without maintenance of check sums may provide that check sums are calculated for old data stocks for the first time. In addition, this can provide that the check sum status of according reports becomes [red]. Therefore it is strongly emphasized to lock old periods or the according company and group financial statements for preventing data from modifications.
The application "Facts" (FAC) was redesigned. When invoking the application a complete list of all defined facts is displayed without any selection. Entering of new facts as well as modifications of existing facts are supported by a wizard consisting of five pages. The first page "Description" serves for the entry of the key, the descriptions and the validity. The second page "General" specifies the basic properties. On page three "Options for Balances and Details" you can define which data are expected on this fact. The fourth page "Controlling" serves for the entry of charts of controlling objects per dimension and is activated depending on the presence of the licence for controlling. Page five shows the descriptions in all active languages. Modifications directly in the table are supported, too (context menu "Table lines editable"). All changeable columns are then displayed with blue letters.
The automatic generation of transaction development details (compensation of the difference between transactions and account balance by a transaction with posting key with usage tag 'L') up to now could be deactivated only in dependence on the period. The setting 'M' in the table "Period / development" (ABRSPI) served for this purpose. This control is now supported in dependence on the fact, too, by setting the flag of the table "Fact / development" (FACSPI) to 'M'.
In this context the following new rule was established: The automatic generation of development transactions is deactivated only if both flags, "period / development" as well as "fact / development", are set to 'M'. Thus the combination of both flags provides the following results:
| ABRSPI \ FACSPI | - | A | M | X |
|---|---|---|---|---|
| - | no development maintenance | no development maintenance | no development maintenance | no development maintenance |
| 0 (no transactions) | no development maintenance | not permitted | not permitted | no development maintenance |
| 0 (transactions present) | no development maintenance | not permitted | not permitted | regular development maintenance |
| F (group currency) | no development maintenance | not permitted | no development maintenance | no development maintenance |
| F (foreign currency) | no development maintenance | not permitted | regular development maintenance | regular development maintenance |
| M | no development maintenance | not permitted | development without automatic generation | regular development maintenance |
| X | no development maintenance | generated balances | regular development maintenance | regular development maintenance |
Please note: If you already used the ABRSPI flag 'M', then you now have to set the FACSPI flags for the relevant facts to 'M', too.
The application "Companies" (GES) was redesigned. When invoking the application a complete list of all defined companies is displayed without any selection. Entering of new companies as well as modifications of existing companies are supported by a wizard consisting of three pages. The first page "Description" serves for the entry of the key, the descriptions and the validity. The second page "Contact" contains fields for address, language and country. On page three "Properties" you can define the relevant attributes of the company. Modifications directly in the table are supported, too (context menu "Table lines editable"). All changeable columns are then displayed with blue letters.
A new application "Business units" (UBR) comprehends the former applications "Business units" (UBR) and "Hierarchy of business units" (UBRUBR). The former applications are disposed in this context.
When invoking the application two tables are displayed with registry tabs behind each other and filled with all defined data. The table in the foreground shows the elementary business units, the table in the background displays the aggregates (aggregations of business units).
As far as aggregates are defined a third table is displayed on the left hand of the other tables representing the top nodes of business unit hierarchies (schemata) as well as the defined hierarchies in tree structure.
Like in other new master data applications entry of new and modification of existing business units is performed using a wizard. The first page allows for the entry of the key, descriptions and the validity. A second page supports the maintenance of descriptions in all active languages. Alternatively you can modify data directly in the table using the function (context menu) "Table lines editable". The former aggregation flag is no longer displayed and modifiable since the different types of business units are displayed in different tables.
The construction of hierarchies is performed by fetching objects from the tables on the right hand side with the mouse and dragging and dropping them on a node in the table on the left hand side. Please mind, that allocations can become effective in several schemata at once if aggregates are allocated in several hierarchies. The revocation of allocations is performed using the delete function. The required restrictions are checked while allocating or deleting objects.
An additional function "Display hierarchies" allows for the display of the appearance of the objects of the right hand tables in the hierarchies in the left hand table.
The application "Country codes" (LKZ) was redesigned. When invoking the application a complete list of all defined country codes is displayed without any selection. Entering of new country codes as well as modifications of existing country codes are supported by a wizard consisting of two pages. The first page serves for the entry of the key, the descriptions and the validity. The second page shows the descriptions in all active languages. Modifications directly in the table are supported, too (context menu "Table lines editable"). All changeable columns are displayed then with blue letters.
The application "Currency codes" (WKZ) was redesigned. When invoking the application a complete list of all defined currency codes is displayed without any selection. Entering of new currency codes as well as modifications of existing currency codes are supported by a wizard consisting of three pages. The first page serves for the entry of the key, the descriptions and the validity. The second page "Properties" specifies the currency code specific attributes. Page three shows the descriptions in all active languages. Modifications directly in the table are supported, too (context menu "Table lines editable"). All changeable columns are displayed then with blue letters.
The application "Languages" (SPR) was redesigned. When invoking the application a complete list of all defined languages is displayed without any selection showing the active languages above the inactive languages. Entering of new languages as well as modifications of existing languages are supported by a wizard consisting of only one page which serves for the entry of the key, the description and the active flag. Modifications directly in the table are supported, too (context menu "Table lines editable"). All changeable columns are displayed then with blue letters.
Positions can now be classified by a position type with respect to their purpose. This classification serves for an easier specification of reports (application REPDEF) as well as for the avoidance of wrong allocations of accounts to positions.
The position type is determined by a two character abbreviation. The first character specifies whether this position is intended to be with ('M') or without ('O') allocation of accounts. The second character defines the role of the position in reports: 'T' = only text, 'S' = total or sub-total line, 'P' = position with basic amounts.
The entry of the position type is possible in the applications "Charts of positions" (POP) and "Positions" (POS). For existing positions the position type is set by the release migration as far as the usage of the position in the position/account allocations and reports is not contradictory. A subsequent modification of the position type is only possible if it is not contradicting to its usage.
Positions with the classification "without account allocation" (position types 'OP', 'OS', 'OT') no longer can be used for allocations in the position/account allocations (applications POSKTO and Z-POSKTO).
The identification for the function "Difference amount subsequent consolidation" is no longer allowed for intercompany accounts with IC account flag 'I'.
The fixed asset master data were enhanced by an entry of a business unit for depreciations. This entry provides that the counter-posting of an automatically calculated depreciation on a p&l account is allocated to the named business unit. This is especially helpful if only the p&l is divided into several business units but not the balance sheet. This enhancement concerns company financial statements (requirement: business unit comprehensive vouchers) and group financial statements (consolidation vouchers) as well as intercompany fixed asset objects
A new application "Controlling definitions" (CTLDEF) comprehends the existing applications "Charts of controlling objects" (CTP), "Controlling objects" (CNT) and "Hierarchy of controlling objects" (CNTCNT). For the time being the former applications are still available.
When invoking the application a complete list of all defined charts of controlling objects is displayed without any selection. Entering of a new chart of controlling objects as well as modifications of existing charts of controlling objects are supported by a wizard consisting of three pages. The first page serves for the entry of the key, the descriptions and the validity. The second page "Properties" specifies object specific attributes like the chart of controlling objects type and the controlling dimension. Page three shows the descriptions in all active languages. Modifications directly in the table are supported, too (context menu "Table lines editable"). All changeable columns are then displayed with blue letters.
When opening a chart of controlling objects (double mouse click on the chart or mouse click on the eye icon) two additional tables are displayed with registry tabs behind each other and filled with the defined data while the table with the charts of controlling objects is faded out. The table in the foreground shows the elementary controlling objects, the table in the background displays the aggregates (aggregations of controlling objects).
As far as aggregates are defined a third table is displayed on the left hand of the other tables representing the top nodes of controlling object hierarchies (schemata) as well as the defined hierarchies in tree structure.
Entry of new and modification of existing business units is performed using a wizard, too. The first page allows for the entry of the key, descriptions and the validity. A second page "Properties" provides for the entry of object specific attributes like the controlling flag or the allocated group controlling object. The third page supports the maintenance of descriptions in all active languages. Alternatively you can modify data directly in the table using the function (context menu) "Table lines editable". The former aggregation flag is no longer displayed and modifiable since the different types of controlling objects are displayed in different tables.
The construction of hierarchies is performed by fetching objects from the tables on the right hand side with the mouse and dragging and dropping them on a node in the table on the left hand side. Please mind, that allocations can become effective in several schemata at once if aggregates are allocated in several hierarchies. The revocation of allocations is performed using the delete function. The required restrictions are checked while allocating or deleting objects.
An additional function "Display hierarchies" allows for the display of the appearance of the objects of the right hand tables in the hierarchies in the left hand table.
A further window with the title "Open tasks" is displayed in case in the bottom of the application area. Here inconsistencies of the opened chart of controlling objects are reported, e.g. if allocated group controlling objects are not assigned to the allocated group chart of controlling objects or the validity of controlling objects extends the validity of the chart of controlling objects.
The application "Products / product groups" (PRO) was redesigned. When invoking the application a complete list of all defined product groups is displayed without any selection. Entering of new product groups as well as modifications of existing product groups are supported by a wizard consisting of four pages. The first page serves for the entry of the key, the descriptions and the validity. The second page "Accounts" specifies product account and in case the elimination account. The third page "Controlling" serves for the entry of controlling objects per dimension in case that the elimination account is a controlling account. Page four shows the descriptions in all active languages. Modifications directly in the table are supported, too (context menu "Table lines editable"). All changeable columns are then displayed with blue letters.
It is now possible to save a transaction development definition despite of the display of open tasks. I.e. the user himself is responsible for working on the open tasks later.
The posting key usage tag 'B07' (accumulated depreciation period begin) is replaced by the usage tag 'B04' (setting for begin of period) by the release migration program.
For support of value adjustments additional posting keys with the posting key usage tags 'B03' (disposal deconsolidation), 'B16' (disposal merger) and 'B17' (disposal by internal sale) and allocation to the transaction development area with deprecation control 'AFA' (value adjustment) can be defined.
The development areas of the transaction development 'B' for participations are provided with the depreciation control 'AHK' or 'AFA', respectively, by the release migration (see above). This classification is required for a correct processing of value adjustments. Certain posting key usage tags ('Bxx') now may be assigned only for posting keys allocated to development areas with a defined depreciation control.
In addition, the new posting key usage tag 'UMB' was exclusively supplemented for the participation development 'B'. The corresponding posting keys can be used for repostings in the shareholdings, e.g. for repostings with respect to a modification of the consolidation method. These repostings are processed within capital first consolidation (see below).
The files delivered in the directory "LieferBatch" with update 1 of release 2014.0 for import of standard data were supplemented in the following items:
As far as the LieferBatch files are provided as Excel files with references to IDL.XLSLINK and IDL Connector these references are now packed. You have to unpack these files before applying the export references. Instead of other adjustment activities before application are no longer required.
The handling of choice dialogues was simplified. The former entry field for search terms or new key parts was removed as well as the buttons <Find> and <New choice> and the check box <Ignore case>. Since the filter line now is always available instead of, the icon for activating or deactivating of the filter line was dropped, too.
Choice dialogues now display all enterable data independent from the system configuration even if a unique key already had is given in the entry field. Up to now in an application server installation only one line for this key was output. The complete display had to be invoked using the key <New choice>.
Choice dialogues have been implemented for master data applications of the new type (e.g. GES), too. The tables shown there can be displayed with a different number of columns. The short version shows only key and description, the medium version supplements other essential columns while the long version displays all attributes. You can switch between these representations using buttons for <Reduced> or <Extended>.
A new check point 'BEL' for the company financial statement vouchers was supplemented in the processing control (VERARB). This check point especially serves for the maintenance of a total check sum for postings of all vouchers for registration of changes. This check point is not used for postings status display in the company financial statements monitor (EA).
Forms entry of development transactions for developments with several areas are now improved supported:
Shareholding transactions with posting keys allocated to the development area with depreciation control 'AFA' must not contain percentages and entries for result from deconsolidation. The representation of missing percentages in the table occurs with 0.00 % for posting keys of the area with depreciation control 'AHK' but with spaces for posting keys of the area with depreciation control 'AFA'.
Shareholding transactions with posting keys with the same posting key usage tag but allocation to different development areas (depreciation control 'AHK' or 'AFA', respectively) can be defined using the same transaction date.
It is now checked that the total of shareholding transactions with posting keys with the new usage tag 'UMB' (see above) and the same transaction date is always zero per intercompany. If not the status of shareholding transactions becomes [yellow].
It is now possible to enter postings for different business units within one voucher. For this purpose the entry of a business unit in the voucher header is now optional even on facts with required business units. On the other hand an attribute for the business unit was supplemented in the postings which is set to the business unit of the voucher if it is not empty. However, for business unit comprehensive vouchers the business unit of the posting has to be entered. This attribute is automatically set by the release migration program (see above).
For the definition of business unit comprehensive vouchers it is required that a business unit compensation account (account flag 'U') is defined in the chart of accounts. The constellation with complete business units over balance sheet and p&l is supported as well as the subdivision into business units only for p&l and specification of account groups in the company / business unit allocations (GESUBR).
If postings for different business units are entered within one voucher then postings on the account with account flag 'U' are automatically generated providing for consistency of the balance sheet and p&l results per business unit. Then there is a result posting per business unit, too. Just like result postings postings on the 'U' account are shown below the total line in the list "Postings" (BUCH). All effective postings except for those on 'E' and 'U' accounts have to total to zero, otherwise the voucher is designated as erroneous.
If an erroneous business unit comprehensive voucher exists, then the status "Postings" is set to erroneous ([red]) for each business unit if business units are shown separately in the company financial statements monitor (EA) (entry for business unit = '%'). At double mouse click on such a status business unit specific as well as business unit comprehensive vouchers are displayed.
If a processing attempts to generate a posting on a balance sheet account for a business unit restricted to p&l data (GESUBR account group = 'G') in a business unit comprehensive voucher, then this posting is automatically allocated to the balance sheet business unit. This concerns retained earnings in carry forward, compensation of currency conversion differences and accumulated deficits of deferred taxes.
In addition, you can control in business unit comprehensive vouchers that the counter-posting for automatically generated depreciations in the p&l is posted in one of the p&l business units. This business unit has to be defined in the fixed asset object master data (see above). Incorrect entries of business units due to the company / business unit allocations (GESUBR) are designated coloured.
With respect to a unique determination of the origin of development transactions business unit comprehensive vouchers and business unit specific vouchers must not be labelled with the same voucher number. If business unit comprehensive vouchers exist, then carry forward into the next period always has to be performed for the complete company. Carry forward of single business units is no longer possible.
Information messages (message type 'I' or 'H') now provide neither the message "Please correct voucher(s) with message no." in the voucher list (BEL) nor a yellow status display in the company financial statements monitor (EA).
In case retained earnings of business unit comprehensive vouchers (see above) are automatically transcoded to the balance sheet business unit if account groups are defined in the company / business unit allocations (GESUBR).
Company / business unit allocations (GESUBR) are now carried forward by the group carry forward, too (see below). Therefore the message for company / business unit allocations already existing in the destination period is no longer output.
The function "Check transition to new fact" now performs a check for all vested data stocks (up to now only for account balances) and in case reports differences. Depending on the data stock beneath amounts in local currency amounts in transaction currency (intercompany account balances, shareholding transitions) and percentages (shareholding transitions, intercompany stocks, product margins) are compared per account or fixed asset object or product group as well as in case intercompany, IC business unit, posting key and controlling object.
After successful processing of the action "(Delete and) Perform transition to new fact" a record without message is written into the processing control (VERARB) for the check point "SIMVOR" providing a corresponding [green] status in the company financial statement monitor (EA). Then all changes of data (incl. postings) in the origin fact provide for a message in this record which causes the display of status [yellow] (status not up to date). Processing the check function then confirms this deviation (status [red]) or not (status [green]).
A business unit comprehensive voucher for deferred taxes is generated at calculation of deferred taxes on business unit comprehensive vouchers (see above). The postings consider the account groups of the company / business unit allocations (GESUBR).
Business unit comprehensive vouchers (see above) are generated, too, for the accumulated deficit of deferred taxes. The postings consider the account groups of the company / business unit allocations (GESUBR). In the case that the business unit for a p&l posting is not clear it is recommended to declare the desired business unit in the chart of accounts.
To avoid name conflicts business unit comprehensive vouchers for deferred taxes yield the voucher number 'LATSTEUX xx-yy' and for accumulated deficits of deferred taxes 'LTVVX xx-yy' ('xx' and 'yy' are replaced by the involved facts).
The application "Voucher classifications / consolidation functions" (KVA) was redesigned. When invoking the application a complete list of all defined consolidation functions is displayed without any selection. Entering of new consolidation functions as well as modifications of existing consolidation functions are supported by a wizard consisting of four pages. The first page serves for the entry of the key, the descriptions and the validity. The second page "Usage" shows where this key is used. This page allows for no modifications. The third page "Options" contains controls for carry forward, IC clearing and reporting. Page four shows the descriptions in all active languages. Modifications directly in the table are supported, too (context menu "Table lines editable"). All changeable columns are then displayed with blue letters.
Because of problems in the data exchange (KONDAT) now the consolidation functions 'En', 'Fn', Kn', 'On' and 'Pn' ('n' = '0', ... , '9') for processing of several instances within one period are generally defined and cannot be modified by the user except for the allocation for the consolidation report. Up to now these consolidation functions were yet generated on demand.
Entry fields for posting keys are now available for the accounts for depreciation, depreciation goodwill, depreciation participation and appreciation participation in the consolidation parameters 'EK' and 'KK'. These posting keys are used for the first consolidation (depreciation participation, appreciation participation) and postings for automatically calculated depreciations (depreciation and depreciation goodwill).
You can now control for consolidation vouchers that the counter-posting of automatically calculated depreciations on the p&l account is assigned to a different business unit. This business unit has to be defined in the fixed asset object master data (see above). Incorrect entries of business units due to the company / business unit allocations (GESUBR) are designated coloured.
Information messages (message type 'I' or 'H') now provide neither the message "Please correct voucher(s) with message no." in the consolidation voucher list (KONBEL) nor a yellow status display in the group monitor (KTKGES).
If the fact is defined to contain data with business units and the company / business unit allocations (GESUBR) are defined with specification of account groups (separated business units for balance sheet and p&l), then the retained earnings of consolidation vouchers affecting the net result are re-posted to the balance sheet business unit if unique.
In this context the company / business unit allocations (GESUBR) are copied into the destination period by the group carry forward function if not yet present. Since now these data are processed by the company as well as by the group carry forward function the notification message about data already existing in the destination period is no longer reported.
Because of the transformation of the posting key usage tag 'B07' to 'B04' (see above) it is now possible to process two shareholding transactions with the same transaction date within one consolidation voucher. One transaction is allocated to the development area with depreciation control 'AHK' and provided with percentages while the other transaction allocated to the development area with deprecation control 'AFA' must not contain percentages.
Repostings (shareholding transactions with posting keys with the new usage tag 'UMB (see above)) are processed by the capital first consolidation in a 'KK' voucher on its own. Within this consolidation voucher only the shareholding transactions are eliminated. If another shareholding transactions exists with the same transaction date (e.g. non cash addition to group companies) then it is processsed in a separate Consolidation voucher (e.g. 'NE'). The corresponding applies for a non cash disposal ('YK').
The forms entry application (I-ERSTKON) no longer reports an error if a fixed asset object to be generated already existed with different properties. Now in this case another new fixed asset object is generated just like already by the automatic first consolidation. New naming conventions for generated fixed asset objects were introduced for this purpose.
The capital first consolidation ('KK') and the function "Difference amount from subsequent consolidation" ('KB') were revised and unified with respect to the treatment of intercompany accounts for the purpose to avoid conflicts with the consolidation D&C ('SK') and its development repostings ('SU'):
If a business unit for depreciations is defined in the intercompany fixed asset object, then this business unit is used for the generated consolidation posting on the p&l depreciation account.
Shareholding transactions with posting keys with usage tag 'B16' (disposal merger) assigned to development areas with depreciation control 'AHK' or 'AFA' and the same transaction date are processed together at merger. However, the addition from merger is represented by only one shareholding transaction with the posting key with usage tag 'B19' and the net book value and processed correspondingly.
Shareholding transactions with posting keys with usage tag 'B17' (intercompany sale disposal) assigned to development areas with depreciation control 'AHK' or 'AFA' and the same transaction date are processed together at internal sale. However, the addition from internal sale is represented by only one shareholding transaction with the posting key with usage tag 'B18' and the net book value and processed correspondingly.
Shareholding transactions with posting keys with usage tag 'B3' (disposal deconsolidation) assigned to development areas with depreciation control 'AHK' or 'AFA' and the same transaction date are processed together at deconsolidation . However, the value adjustment is only considered if the account "Depreciation participation" is specified in the consolidation parameter. Then the counter-posting for the value adjustment is assigned to this account.
Detail information about the selected scenario is displayed below the selection area.
The column for business units now can be hidden if business units are not used at all.
Balance differences now can be manually released just like it had been possible for an incorrect rule plausibility before. Amongst others this is useful in the case that only p&l data are available on the source fact and are transferred for planning.
'Export balances' was supplemented as an additionally possible step in a forecast sequence.
A warning message indicating that the execution of a forecast sequence has no effect (no data are saved) is output when executing a forecast sequence which contains neither the step 'Save scenario' nor the step 'Export balances'.
A log application (short word 'PLANLOG') shows information about all forecast sequences executed for a scenario with specification of user, timestamp und duration as well as information about errors and warnings. In addition, this application allows for the recall of all displayed procedure logs displayed during execution of the sequence.
In addition, on demand this application also logs the actions directly executed by the user in the planning application (PLAN) between loading and saving a scenario, however, only the actions themselves but not their details.
The forecast log application can be invoked out of the "Forecast monitor" (PM). The latest logs are placed on the top of the list. Forecast logs can be deleted again. When deleting a scenario the according logs are deleted, too.
Menu and object authorisations are now continuously respected in "Forecast monitor", "Forecast sequences" and "Forecast sequence parameters".
Scenarios and rule templates without display authorisation are no longer visible.
When creating a new scenario all object authorisations on this scenario are automatically granted to the user group of the creator.
When creating, copying or moving a rule template or a template folder the authorisations of the super-ordinate template folder are inherited for all user groups.
The transfer of authorisations when changing the authorisation of a super-ordinate rule template folder or a sub-ordinate rule template in the application "User group authorisations" (BENDEF) was revised, too.
The main application for financial planning was renamed from "IDL.FORECAST" to "Planning application" (PLAN).
When loading a scenario it is now checked whether the chart of accounts used contains a valid result account and an account for retained earnings. If not, a message is output since the check block cannot be consistent.
When loading a scenario with planning account aggregation an aggregation check is performed. This check now outputs only warnings while info messages are only output if the aggregation check had been invoked manually.
The deletion of a scenario is now possible only at selection of the scenario itself in the scenario list but no longer at selection of a company. In addition, a scenario cannot be deleted if it is opened for work by another user. When deleting a scenario a warning is output indicating that corresponding forecast logs are deleted, too.
The "Write balances" dialogue now shows a warning if the plausibility check had registered an error.
The account filter in the filter function of the planner spreadsheet offers now the facility to filter the planner spreadsheet in the way that only plan aggregation accounts are displayed.
The "Balance difference" display is now ordered by account number.
The liquidity report now supports a debit/credit control. I.e. you can allocate an account to the block "Cash in" as well as to the block "Cash out" with the additional specification of the debit/credit flag 'D' or 'C', respectively.
After generation of a liquidity report it is displayed at once.
Liquidity reports no longer contain a check block.
The warning message indicating that the report does not contain accounts for amounts at the beginning of the period was dropped. Instead of it is only reported if no accounts are allocated to the report at all.
You can now transfer the balance of a position into the individual table sheet using the new formula POS just like before referencing account balances using the formula SAL.
Using the new formula WHEN you can now define cell contents with conditions in individual table sheets.
You can now define cells with financially rounded amounts in individual table sheets using the new formula RND. The first parameter of this formula represents the original amount, the second the number of decimal digits to be left. Specifying a negative value for the second parameter provides for rounding with respect to the digits before the decimal point.
A find function as well as "Find and replace" are now available for individual tables. The corresponding dialogue opens on mouse click on the find icon (magnifying glass) or the key combinations <Cntl-F> (Find) and <Cntl-H> (Find and replace).
Formats of empty cells were modified in a way that they can be used in formulae.
An individual table can be selected in the table storage. When pressing the right mouse key a context menu appears offering the items "Display", "Copy", "Rename", "Delete", "Export" and "Import". At "Export" a file dialogue opens for specification of the export file. This file analogously can be imported in another scenario via "Import" as a new individual table.
The sales, income, purchases, expenses, personnel and provision rules now cannot only use the change of an account but also the closing balance of the account as its base amount. For this purpose you have to select the item "without base value, from closing balance" on the first page of the corresponding rule wizard. The former option "without base value" now is named "without base value, from entry".
In this context the possibility to define in provision rules for each allocation separately whether it shall work with or without base value has been dropped. Existing rules are automatically converted when opened or applied as far as this is unique. For provision rules with mixed usage of base values the user himself has to define two new rules, one with and one without base value. These rules are designated as faulty in the rule template tree.
A new rule type 'reposting rule' allows for the reposting of an account balance or of parts of it at the end of a period to one or more other accounts. Amongst others this allows for the representation of a cash pool or the distribution of a third party balance to several intercompany balances. On the first page of the wizard you can enter a percentage representing the portion of the balance to be reposted. In addition, you can define a set of source and destination accounts as well as "with deviating intercompany". The second page then contains the account allocations with the percentages of the distribution.
A new rule type 'interest rule' allows for the calculation of interests on the closing balance of an account. You can specify different p&l accounts and interest rates for interest income and interest expenses. The German interest method 30/360 is applied in this rule.
Some columns and buttons were renamed in amortisation tables. The button "Special repayments adjust following repayments" was removed. The button "Special repayments adjust duration" was renamed to only "Special repayments".
The period control now allows to restrict a rule to the first period of the planning area, i.e. the first period after the ACTUAL area.
By selection of a position the transition rule now offers the facility to automatically generate allocations for each account below this position.
A new button in the account selection component of rule wizards serves for an immediate reset of the account filter.
The calculation mode of terms of payment is now saved along with the rule template. Similarly the term of payment in days is saved along with a rule template for a dissolution rule.
The function 'Cut' (key combination <Cntl-X>) was supplemented in the rule template window.
A column for comments was supplemented in the tables for rule templates and applied rules.
Two new icons (single and double top arrow) were supplemented in the title bar of the rule template table behind the icon for "Display only this folder" providing for return to the super-ordinate folder or the complete list, respectively.
It is now possible to save a report definition despite of the display of open tasks. I.e. the user himself is responsible for working on the open tasks later.
The short description of report idents is now an obligatory entry since in case this text is used as designation of registry tabs in IDL.FORECAST.
Positions provided with a position type (see above) now can yield only those combinations of line type and value flag which are scheduled for this type. When dragging a new position into a report then line type and value flag are preselected due to the following table:
| Position Type | Line Type / Value Flag |
|---|---|
| OT | T5 |
| OP | P6 |
| OS | S0 |
| MP | P1 |
| MS | S2 |
In addition a probable indention is performed automatically. Then the user only has to take actions if these default setting are not suitable.
A new colour chooser dialogue is now available for colour settings of report lines.
It is now possible to save a report column definition despite of the display of open tasks. I.e. the user himself is responsible for working on the open tasks later.
A new colour chooser dialogue is now available for colour settings of report columns.
When deleting a report column option a warning notification is output if it is yet referenced by any report header.
The status column for intercompany account balances was removed from the table of report headers (REP) since these data did not contribute to the report results.
The export/import formats (IEFDEF, IEFFEL) and tables (I1nn) for positions, fixed asset objects, intercompany fixed asset objects and postings were extended by the respective new columns due to the descriptions above.
The new parameter IMPORT_WARNING_IGNORE was supplemented for calls of the import interface via command line, e.g. by IDL.IMPORTER. The entry "IMPORT_WARNING_IGNORE=true" provides that all warning messages reported by the import application are automatically answered with <Ignore>, i.e. data are written into the database despite of the warnings. Without this parameter (or with setting it to "false") warnings are treated as errors like before.
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.
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.
The standard imd template for IDL.IMPORTER was modified for a correct unload of currencies without decimal digits (e.g. HUF).
The update 1 of release 2014.0 contains the current edition of the DCW interface for DCW release 3.50.