This release 2010.1 includes modifications and enhancements of the products IDL Konsis, IDL Forecast, and IDL Connector.
The release 2010.1 is an interim maintenance and therefore may be left out in the release sequence. Prerequisite for this release is the last main maintenance 2010.0 from July 27th 2010.
The supplements and corrections to the main maintenance 2010.0 up to the release date are included in this interim maintenance.
This documentation describes the enhancements since the main maintenance 2010.0.
A database backup has to be performed in principle before installing a new release. An advice for the necessary database backup is output by the installation program at the beginning of the installation to protect the user from data loss.
The release migration for IDL Konsis (see ch. 2.1) has to be principally performed as the first step after installation of a new release. Therefore a message box is output at the first call of IDL Konsis after installation reporting that the migration has not been performed yet. This message box was supplemented by a new button <Start migration now>. The migration is automatically started when pushing this button. IDL Konsis has no longer to be restarted after successful processing of the migration, but rather all application functions are available at once.
If the migration is not invoked this way, e.g. because of missing user authorisation, the call of other application functions is locked. Only applications for maintenance of authorisation data are exempted for the case, that the user has no authorisation for starting the release migration because of usage of individual authorisation groups. IDL Konsis has to be restarted after manual invocation of the release migration for having access to all application functions.
The html help rarely used according to experience is no longer contained on the release CD of release 2010.1 or in the directory prepared for download of the installation, respectively. However, you can request the html help at the IDL hotline if required. Of course, the help texts contained in the html help are furthermore accessible online in the application as usual.
Additional functions of the MS Excel connection IDL Connector of IDL Konsis are planned for future releases, which require at least MS Excel version 2003. Therefore we recommend an upgrade to MS Excel 2003 or, even better, MS Excel 2007.
A message box is output at the first call of IDL Konsis after installation reporting that the migration has not been performed yet. This message box was now supplemented by a new button <Start migration now>. The migration is automatically started when pushing this button. IDL Konsis has no longer to be restarted after successful processing of the migration, but rather all application functions are available at once.
The migration program for this release performs the following conversions in the database:
The following menu items are new with this release. If completely entered customer specific authorisation groups are used, authorisations (BENMEN) for these menu items have to be provided. As a rule the authorisations of the user groups IDLKON or IDLWIN may serve as a sample.
As an alternative solution to the complete definition of authorisations for all menu items the procedure for simplified care of customer specific user groups is recommended. With this functionality the new authorisation level '0' can be entered for menu authorisations (BENMENE), too. It declares, that a menu authorisation issued for the reference user group is not issued for the given individual user group.
The authorisation groups IDLADMIN and IDLWINAD have available extra authorisations for dialogue applications for development transactions for maintaining data with reserved posting keys. This extra authorisation was now extended to the form entry applications.
With some Oracle drivers it might occur that IDL Konsis aborts completely with activated JDBC connection (button <Options> in the login panel and setting "Oracle native"). This problem can be solved by setting '.;' at the beginning of the environment variable "Path". Therefore IDL Konsis now checks the environment variable "Path" for beginning with '.;', if the user selects <Options> in the login panel, then selects "Oracle native", and then looks for JDBC drivers. Otherwise a corresponding warning message is output. '.;' has to be inserted into the environment variable "Path" to omit this message.
Sometimes representation problems occurred caused by the concurrence of IDL Konsis, Java 1.6, and newer graphic card drivers. If a computer has representation problems with context menus or other user interface features, then you can activate the new option "Disable hardware acceleration" on the page "Graphic" of the options dialogue. Then at the next start of IDL Konsis no Direct3D is used and the graphic errors should not occur any more.
The find function (see Release 2010.0 News) integrated in the short name entry often detected results of the release documentations of several years old releases. Since this is not meaningful now only the release documentations of the last three releases are embraced in the search.
Some menu items are now represented by characteristic icons. These icons are displayed in the menu tree (Task tree, Quick start) as well as in the application specific action and object menu. The icons for global and semi-global actions (globe) are now displayed behind the menu text in the action and object menu.
The following menu items were provided with icons:
All icons displayed in the action menu (except the icons for "Cancel" and "Next...") are displayed in the title bar of the table area, too. The switch between "Edit data" and "Create new data" is done there, too, depending on the selection of lines. The tooltip of each icon shows the text of the action menu and a mouse click on the icons invokes the action corresponding to the action menu item. However, the toolbar only shows icons, which are unique for the application. If several menu items contain the same icon, then the display in the toolbar is suppressed.
This kind of toolbar is also displayed in the title bar of single record applications. Typically you find there the icons for the actions "Display comment/help-text" and "Edit comment/help-text".
If several tabs are opened with different applications, then their order can be modified. For this purpose you have to click with the mouse pointer onto the hanger of a tab and drag it with pressed mouse key to the desired position.
IDL Konsis now allows the revoke ("Undo") and the repetition ("Redo") of entries in the selection and in the single record area. For this purpose two icons (arrow to the left, arrow to the right) were supplemented in the title bar of the respective area. The undo-icon is activated at the first entry in the respective area. The last entry is revoked by a mouse click on this icon and the original field content is restored
At the first retraction the other icon for repetition of the change becomes active. The last revoked entry is automatically performed again at mouse click on this icon. Depending on the number of revoked entries this step can be performed several times.
Entry errors now can be better visualised by validators. On the one hand the deficient field is supplied with a red border. On the other hand the error message usually displayed in the message line is mow displayed in a "speech balloon" directly above the deficient field. This output is performed during data entry with some delay to avoid a permanent flashing of these speech balloons during data entry e.g. of period fields. The speech balloon vanishes at mouse click on it.
Errors recognised by an application specific check are reported after sending the entry (e.g. after pushing the button <Display>). However, errors that are detected by the user interface are reported immediately. This concerns the following types of checks:
You can activate or deactivate this feature by the option "On-the-fly validation of input fields" in the options dialogue "Graphic".
For improved readability text on red background (flash light colour) is now output in white instead of black colour. This concerns error messages in the message line as well as table cells branded as incorrect, e.g. account attributes for account balances with incorrect details.
The tables displayed in IDL Konsis now offer the facility to sort the lines in the order of the contents of arbitrary lines. For this purpose each cell of the table headers exhibits a sort icon that glows, if the mouse pointer points to the table header.
The table is sorted in ascending order of the contents of a column, if a mouse click is performed on this icon. The icon then becomes a triangle pointing to the bottom. A second mouse click on this icon inverts the order of the data. Then the icon mutates to a triangle pointing to the top. A third mouse click on the same icon switches the sorting for this column off.
You can select several columns for sorting of the data. Then the sorting for the second selected column superimposes the sorting by the first selected column etc.. When pushing the button <Display> all sortings are switched off and the table is displayed in the original order.
The sorting regards the type of the column. I.e. numerical columns are ordered by amount, date and time columns in chronological order. Otherwise the data are sorted alphabetically. Empty cell contents are always treated as the smallest values.
The sorting is interrupted by empty lines. Thus e.g. the reference block with the totals of assets, liabilities, income and expenses of the list "Account balances" (KTOSAL) is not merged with the account balances, since balances and reference lock are separated by an empty line. However, otherwise total lines are embraced in the sorting, too.
The node lines of a table in tree structure are not re-sorted. Rather only the lines on the lowest level of the tree structure are sorted within their branch. Thus header of the key column of a tree table does not contain a sort icon.
It was supplemented in the find function for table contents, that you can determine the direction of the search. Therefore the find dialogue box was enhanced by two radio buttons "Forward" and "Backward".
The find function now works cyclically. I.e. the search is continued at the top, if it reaches the end of a table. Searching "backward" works just the other way round.
The item "help-text" is from now on only used yet for master data. The corresponding functionality for reported data (company and group financial statements) was named "comment". Correspondingly the according column in the lists is titled with "C" instead of "H".
The existence of help-texts or comments, respectively, is now represented by a new icon in this column. A blue book with an "i" on the title page (like in the action menu) designates the existence of a text in the selected language instead of the green hook. A grey book represents a text in a deviating language.
The determination of this designation was accelerated considerably especially for the case, that no texts are present at all.
You can now navigate through tree structures (e.g. like in the Windows Explorer) using keys. The arrow keys (right/left) as well as the '+' and the '-' key can be used for expanding, collapsing and positioning in the tree table.
Beside bar and pie charts introduced with release 2010.0 now additional chart types are available: vertical bar chart, stacked bar chart, stacked vertical bar chart, line chart, area chart, stacked area chart, vertical and horizontal waterfall chart.
The tool bar of the table now contains yet only one chart icon, since these chart types no longer can be represented in the tool bar. When clicking on this icon a chart in the standard chart type is created. You can modify the chart type by a drop down box in the chart area. This drop down box contains the variants for 2D or 3D display, respectively, too, since these variants are not available for all chart types. Some chart types are only available for one-dimensional or two-dimensional data selection in the table.
You can preselect the standard chart type on the page "Common" of the options dialogue. If you don't have preselected a chart type (entry "Choose chart automatically") then the vertical-bar chart is used as the standard chart type in general.
You can now modify the colours of the pieces or bars of a chart via the legend of the chart. A mouse click into the corresponding entry opens a colour choice dialogue like in MS Excel. The selection of a colour automatically modifies the colours of the bars, pie pieces etc. of the displayed chart.
Some chart types allow a modification of the display of descriptions. E.g. a longer designation may be visible by putting the text into a skew position. In addition, the pie chart allows a rotation of the chart, the pulling out of the labels and an "explosion" of pieces above a selectable threshold.
A mouse click on a table icon in the title bar of the chart area generates a table with all values processed in the chart, which is displayed beneath the chart itself. This table allows the deletion of lines or columns and the merging of lines providing the display of the total of these lines.
The complete functionality of creation of charts is now available for the planner spreadsheet (IDL Forecast), too.
Enhancements for the print of charts are described in the following chapter.
If distinct lines and columns were selected via cell selection, then the print output is reduced to this block of data, too. However, for the time being no columns out of the area of fixed columns can be selected.
The display of tables in the print preview can be enlarged or reduced by a scroll bar "Preview zoom". This adjustment works similar to the scroll bar in the original table display and has no influence on the following print output. At reduction you can preview up to 16 print pages in one step.
Tables now can be continuously enlarged or reduced for the print output, too. A scroll bar "Table zoom" in the print preview serves for this purpose. Using this scroll bar the print preview dynamically displays, which lines and columns are printed on the respective page at the selected scale. This function is an enhancement of the previous control "Fit to page" (fit to the width of a page). If "Fit to page" is selected, then the table zoom cannot be used.
The icon "Fit to page" now works toggling. I.e. a repeated click on this icon revokes the selection "Fit to page".
Charts now can be printed, too. All created diagrams are taken for the print output following the print of the table itself. You can also print out of the chart view. Then exactly this one chart is printed without any table.
Charts can be turned in the print preview. I.e. you can control whether a page with a chart is to be printed horizontally or vertically. However, this concerns only the chart itself, head and foot lines are not affected. You have to skim through the print preview until the page with the chart for the purpose to turn it. There additional options for turning the chart appear in the print preview.
IDL Konsis is now available with a user interface in Spanish language (except for help-texts). Prerequisite for this selection is the purchase of the according licence. Beside Spanish the user interface is still available in German, English and French language.
Several checks of the validities of allocated master data were revised:
The entry of the XBRL concept in the application "Position" (POSE) was revised. There is only one entry field instead of three previous entry fields each 85 digits long. If the length of the entered data exceeds the length of the entry field, then the content scrolls within the entry field.
You can now modify the valid-until period via mass update.
You can now specify a separate account for value adjustment (allowances) for individually defined fixed asset objects for company financial statements as well as for intercompany fixed asset objects. Then fixed asset transactions for this object are allowed on the fixed asset account (acquisition or production costs) as well as on the account for value adjustment (depreciations). Automatically calculated depreciations are posted on the account for value adjustment. Up to now this function was only available for fixed asset objects of the group financial statement.
You can define "groups for account / posting key allocation" in a new table. Such a group is a classification providing restrictions for the allocation of posting keys and accounts in reported data. A typical application case is the usage of separate accounts for value adjustment in the fixed assets. Then generally only transactions of the area of acquisition and production costs should be entered for the fixed asset account, while only transactions of the area of depreciations should be entered for the account for value adjustment. In this case you have to define two groups for account / posting key allocation.
A list application (short word BSG) and a single record application (BSGE) serve for the definition of the allocation group itself. The key of each group is composed out of the transaction development and the actual group key with a maximum of three digits. You can define descriptions in several languages for this key. In addition a validity range has to be specified, especially the beginning of its effect.
For activation of this functionality an allocation group has to be assigned to the respective accounts as well as to the respective posting keys. Both tables were enhanced by a corresponding attribute, which can be supplied by the respective dialogue and import applications. Of course, the allocation group has to be convenient to the development of the account or the development of the posting key, respectively. The dialogue applications support a mass update.
The following check was supplemented in all applications for maintenance of reported data with posting key entry (development transactions, postings, consolidation postings): If the account as well as the posting key is allocated to an allocation group, then they have to agree. However, if one of both objects is not supplied with an allocation group, then the combination is allowed. The same check is performed for the entries for the consolidation parameters, too.
There is an additional condition for accounts: data transferred from the company chart of accounts to the group chart of accounts have to stay valid. Therefore the assignment of an allocation group to a group account is automatically inherited by all allocated company accounts. However, in the other way it is allowed, that a company account assigned to an allocation group is allocated to a group account without allocation group. Then the restriction is only valid in the company chart of accounts. After the effort of the first-time arrangement only new group accounts have to be provided with an allocation group.
The list "Columns of transaction development" (SSP) now allows a branch into the list "Posting keys" (BSL) for display of the posting keys allocated to this column.
The product master data were enhanced by an attribute for a controlling object. This controlling object is written into the consolidation postings of the elimination of current asset results (ZU), if they concern controlling accounts. Usually this applies to the elimination account. Therefore the controlling object has to be entered, if the elimination account is a controlling account.
Alternatively controlling objects can be specified in the consolidation parameter 'ZU' or in the inventories IC-Stocks (ICBEW), too. At simultaneous entries the values of the inventories IC-stocks have priority to the data in the product master data and these are prior to the entry in the consolidation parameter. The display in the list "Elimin. current assets results list" (ZWERGUV) is performed corresponding to this rule.
The company financial statements monitor (EA) now allows a branch into the form entry applications. A new sub-menu "Forms data entry" was supplemented for this purpose. Below you find the form entry applications for account balances and the diverse detail data.
The administration of the configuration for the drill through to preceding systems displaying the composition of the values held in IDL Konsis in the origin data was revised.
When calling this function (out of the applications "Account balances" or "IC-account balances") at first only the page with the selected origin data is displayed. You can invoke the function for administration of the configuration data via action "Drill through configuration".
The following display allows the maintenance of the configuration of the access to the remote database as well as the entry of the SQL query for reading the desired data. You can specify several configurations addressed by a key (connection id or query id, respectively). The configuration data for the database access are generally valid while the SQL query always refers to a data stock, either account balances or IC-account balances. One of each configuration has to be set active and then is used for reading of data at start of the drill through function.
The call of this function usually requires the entry of a password for login to the remote database. IDL Konsis remembers this password for the duration of this application. Thus the password entry is required only once for several consecutive drill through queries.
The IC-reconciliation in the company financial statements provides a clearing of the reported IC-account balances as a pre-stage of the D&C and I&E consolidation. However, opposite to the real consolidation there ist no opportunity to clear differences by manual postings.
Therefore now the facility was provided to supply the clearing groups manually with a release status. The IC clearing list (KGESGES) was enhanced by the two new actions "Commit IC-clearing reconciliation" and "Revoke IC-clearing reconciliation" for this purpose. These actions set a release status and user, date, and time of the modification are stored in the IC-clearing record. These data are displayed in the IC-clearing list, too.
The status display for IC-clearing of the company financial statements monitor (EA) considers the release status, too. If the release status is set, then the status is not displayed [red] despite of determined differences.
This release information is deleted at repetition of the IC-reconciliation or by proceding a consolidation on the same fact. In cases the manual release has to be repeated.
In addition the IC-clearing record can by annotated by a remark text or by a longer comment (see below). E.g. this comment might contain a dialogue between both involved companies. For a quick identification of comments modified by the partner company user, date, and time of the last modification of the comment are displayed beneath the book icon.
The function "Drill through" is now available for IC-account balances just like for account balances allowing the display of the constitution of the IC-account balances in the origin ERP system. You can branch from the list as well as from the form entry application via action menu into the application "Drill through" (SQLQUERY) where you can set up the configuration of the database access, too (see above).
The list "IC-account balances" (ICKTOSAL) now supports the entry '*' for selection by consolidation function (KVA). Thus you can select IC-account balances, that are not processed by the D&C and I&E consolidation because of the missing allocation to a consolidation function.
Sometimes development transactions are not maintained for reporting but only for historical currency conversion, e.g. for the equity capital. Up to now this situation had to be controlled by the flag position '0' in the period/development allocations (ABRSPI), which did not specify where development transactions are required and where not.
Now the flag position 'F' in the period/development allocations (ABRSPI) was provided for this purpose. 'F' determines that the development is required for companies with foreign currency (corresponding to flag position 'X'), while there is no relevance for companies with local currency equal to group currency (corresponding to flag position '-'). This meaning is applied when checking the data and setting the status colours as well as in diverse processing applications (carry forward, currency conversion etc.).
Since this control is only relevant for currency conversion of company financial statements, posting keys for this transactions development are not required for group data (consolidation postings) at all.
The action "Mass update" was supplemented in diverse transaction lists for the purpose to modify the transaction date.
The selection of transactions (except for fixed asset transactions) of several periods (data carried forward and data from interim periods are not displayed here) now displays the data in chronological order. In addition the account balance of the final period is displayed as comparison value.
A check for the validity of the combination account / posting key at usage of account/Posting key allocation groups (see above) was supplemented in several applications. However, shareholding transactions are excluded since the allocation group of the account always refers to the transaction development of the account.
Automatically generated development transactions are now supplied with the closing of the month as transaction date (up to now current date), if no other date had been entered manually.
The list "Fixed asset transactions" (ANLBEW) now only displays company financial statement data, that are allocated to a fixed asset object with fixed asset type 'M'. Thus the selection for fixed asset type and the display of the fixed asset type in a table column were discarded.
Fixed asset objects in the company financial statement usually represent gathering objects per fixed asset account. Therefore the specification of an acquisition date reveals no information. Thus the columns acquisition date and selling date are no longer output in the list of fixed asset transactions. Correspondingly the facilities for selection by acquisition or selling date were discarded, too.
Value adjustment accounts are now supported for company financial statement and intercompany fixed asset objects. Therefore fixed asset transactions may exist for the same object but for different accounts. Thus all fixed asset transactions are supplied with an account. The release migration program provides this for all existing data. If data are entered (or imported) without specification of an account it is furthermore presumed, that the data are allocated to the fixed asset account (for acquisition and production costs).
The facility for definition of unrealised losses discarded with release 2010.0 was reconstituted in the inventories IC-stocks. In some cases these data are required although an elimination of unrealised losses is not permitted.
The entries of the controlling objects in the list "Controlling balances" (CNTSAL) now can be modified via mass update. Similar extensions were realised for other data with entry of controlling objects (ICKTOSAL, BUCH, KONBUCH), too.
Company financial statement vouchers (BEL) now can be provided with a classification. E.g. this may be a classification by legal rules (e.g. "IAS 19", "IAS 21"). The applications for maintenance of vouchers (list, single record, import) were correspondingly enhanced.
The classification items can be individually defined. A new application "Voucher classifications" (BKL) serves for this purpose. You have to specify a key, designations in one or more languages, and a validity for such a voucher classification.
It is intended to evaluate the voucher classification in reports in a following release.
The display of non-effective postings was revised:
A check for permissibility of the combination account / posting key when using account / posting key allocation groups (see above) was supplemented in the concerned applications.
The mass update function of the list "Postings" (BUCH) was extended by the facility for update of the posting key and the posting remark.
The new application "Company financial stmts + monitor for entry" (I-EA) was created as a central application for calling forms entry applications. This application works in the same way as "Company financial statements + monitor" (EA) with one exception: At double mouse click on a status column the forms entry application is invoked instead of the respective list called otherwise.
You find the new application as the first menu item in the branch "Forms data entry" of the menu trees.
The forms entry applications for account and IC-account balances offer the facility to enter data for several periods or business units simultaneously. If you branch from this list via object menu (right mouse key) into the forms entry application for detail data or another subsequent application with reference to a period, then now the column of the selected line is evaluated so that the subsequent application is provided with the respective period or business unit, respectively, as a parameter.
The forms entry application for fixed asset transactions is subject to some restrictions caused by the introduction of accounts for value adjustment for the company financial statement (see above):
Therefore it is suggested to enter value adjustment accounts only for fixed asset objects individually defined in addition. The form entry application for fixed asset transactions should not be used for fixed asset objects with entry of a value adjustment account.
The master data table for report idents (RID) was extended by a "Flag report default". This flag can be set if it is the id of a transaction development report. This flag is evalueted by the entry forms for development transactions. If a report exists designated in this way for the selected development, then this report is automatically supplemented in the selection area. Then usually there is no more selection or entry of a suiting report id necessary.
The dialogue for additional data in the forms entry application for postings (I-BUCH) was supplemented by an entry field for the flag for deferred taxes. In particular you can designate balance sheet postings between tax and commercial balance sheet as permanent, temporary affecting net result, or temporary not affecting net result, respectively.
The entry of a posting key for postings (I-BUCH) and consolidation postings (I-KONBUCH) is now possible directly in the entry form (column before the debit amount). Up to now this entry was possible only in the additional data.
The following new check rule operators are available for check rules:
The first two check rules can be provided with margins.
The third check rule can substitute two check rules with the operator "(L<>0)=>(R<>0)" with interchanged allocations of left and right side, respectively.
Consolidation postings for deferred taxes now can be carried forward in different ways. Up to now vouchers for deferred taxes (e.g. 'LM') were merged with the original voucher (e.g. 'MB') to one carry forward voucher (e.g. 'VM'). From now on consolidation vouchers can alternatively be carried forward into a separate carry forward voucher (e.g. 'WM'). The character 'W' represents a set of new consolidation functions for separate carry forward of deferred taxes.
The user himself controls the carry forward of deferred taxes. For this purpose the table of consolidation functions (KVA) was supplemented by a "Reference consolidation function carry forward". This attribute is preset by the release migration program according to the carry forward rules valid up to now (e.g. 'VM' for 'MB', 'LM' and 'VM'). You may modify the KVA record for deferred taxes (e.g. 'WM' for 'LM').
If this new control is to be applied and you work with individual consolidation functions for manual vouchers ('M0', 'M1', 'M2' etc.), then you have to define new corresponding carry forward KVA records ('W0', 'W1', 'W2' etc.), since they are not automatically provided by IDL.
The automatic calculation of depreciations generates depreciation postings on a value adjustment account, if it is entered for the fixed asset object. This control up to now only available for group fixed asset objects now works for intercompany and company financial statement fixed asset objects, too.
The calculation depreciations considering of extra depreciations (depreciation kinds 'SL' or 'SM') was modified in the way, that extra depreciations do not reduce the automatic depreciation of the actual period, but rather are posted in addition to the current depreciation. Therefore only depreciations carried forward are considered for calculation of the residual book value but no other depreciations (without carry forward posting key).
A controlling object for conversion into group or parallel currency, respectively, was supplemented in the currency conversion header (WUM). This controlling object is allocated to the conversion differences cleared on the conversion difference accounts specified in the same record as far as the account is a controlling account. I.e. controlling balances for this controlling object are generated with the same amount as the account balances on these accounts. Until now an arbitrary controlling object was used for this purpose.
A profit or loss value in local currency defined in a shareholding transaction (GESGES) is now converted into group currency due to the currency conversion rule of the profit or loss account (up to now due to the currency conversion rule of the shareholding account).
The table for consolidation functions (KVA) was extended by two attributes each referencing another consolidation function:
The reference consolidation function for carry forward defines, in which consolidation voucher consolidation postings with the current consolidation function are to be carried forward. Thus this reference consolidation function serves as a proof of the carry forward method. This is supported by the new selection for reference consolidation function for carry forward in the list KVA. In addition you can control the way of deferred taxes carried forward (see above). Several new consolidation function beginning with 'W' serve for this purpose, some provided by IDL, some to be specified by the user.
The reference consolidation function for reports (report type 'V') defines, which report result column contains the amounts of the vouchers with the current consolidation function. In addition the referenced consolidation function has to specify the corresponding column number in another new attribute. Column numbers between 05 and 50 are allowed, since the report result contains a maximum of 50 result columns and the first four columns are occupied by the totals of balances and postings. Each column number may be assigned only once.
New consolidation functions generated automatically (e.g. 'K0', 'K1' etc. for purchase of a subsidiary in several charges) are provided with the attributes of the original consolidation function (e.g. 'KK') usually avoiding the demand for manual changes.
All three new attributes are preset by the release migration program due to the rules for carry forward and consolidation report valid until now. The more detailed variant for manual postings ('MB' as well as 'M0' to 'M9' in columns '19' to '29') is applied for the consolidation report, i.e. the column '18' up to now used for the total of all manual postings is not assigned. From now on you can modify these entries on your demand.
The up to now unconsidered consolidation functions 'FU' and 'QU' have to be considered, since the report column number is evaluated for transaction development reports, too. They are assigned to the columns '32' and '33', respectively, by the release migration.
The column options (SPO) for consolidation reports have to be maintained by the user from now on, too. Therefore the release migration transforms the column options '#KVA', '#KVAGE', and '#KVAMB' into new keys beginning with '$' instead of '#'.
The sorting of the companies by investment level introduced with release 2010.0 for the sort option 'A' is now valid for the sort options 'B' and 'K', too, i.e. for the display in a tree table.
The Check and refresh status information generally does no longer assign the status value [-]. This allows the suppression of the status of consolidation functions that are not used at all. The status [-] is set exclusively by the consolidation functions if they are started and determine, that there are no data to be processed. Then the status [-] is not updated by the "Check and refresh status information".
The maximum number of shareholding companies for display in the form entry for the first consolidation (I-ERSTKON) was incremented from 5 to 10.
Intercompany accounts allocated to a D&C consolidation function ('SK', 'S0', 'S1' etc.) are no longer processed by the capital first consolidation (forms entry or automatic), since the amounts already have been eliminated by the D&C consolidation. This especially concerns the dividend account. However, on demand you can manually enter values for these accounts in the forms entry application (I-ERSTKON).
Shareholding transactions for appreciations (participation posting key with usage tag 'B06') are now processed by the capital first consolidation, too. The amount is posted against the difference amount account. Correspondingly the status 'KK' becomes [red] even if only one shareholding transactions exists with this posting key.
The information fields for user, date, and time of the last modification of shareholding transactions are no longer updated at entry of the group/sub-group and the consolidation voucher number into the processed shareholding transactions. Thus the data of the user who lastly modified the contents of this record are preserved.
You can now calculate and post minority interests on capital that was posted in the capital consolidation vouchers for clearing of the difference amount. The vouchers now are provided with the position 'K' for the flag for affecting the net result or the capital and thus can be provided with the flag for calculation of minority interests.
You can now calculate and post indirect minority interests on changes on the equity capital. This function is performed for all capital transactions having a posting key assigned with new usage tag 'FF'. The update of the previous standard via files in the directory "LieferBatch" provides the capital posting keys '06', '07', and '08' with this usage tag. The counter-entry is posted on the corresponding minority interest account of the consolidation parameter 'FK'. For the purpose to generate these postings for historical capital consolidation (shareholding posting key with usage tag 'B04') in the year of the first consolidation accounting, too, you can in addition provide the capital posting keys for manual entry of carry forward ('09' and '10' in the previous standard) with usage tag 'FF'.
Indirect minority interests on dividends out of phase are now always posted at the subsidiary. Up to now these were posted at the shareholding company.
If one of the companies involved in a dividend consolidation ('SD') is quota-consolidated, then from now on the treatment is different:
These modifications apply for the D&C consolidation for dividends ('SD') as well as for the reposting of D&C consolidation ('SU') of SD vouchers and SD accounts. Other D&C consolidation functions ('SK', 'S0', 'S1', ...) are not changed for quota-consolidated companies.
The reposting of D&C consolidation now considers changes of the consolidation method compared to the previous period and in that case uses other posting keys instead of carry forward posting keys. This takes into account that development transactions carried forward are reposted within the reposting of first consolidation (KU) or reposting for quota-consolidated companies (QU).
The IC-clearing list (KGESGES) now allows the entry of remark texts (max. 70 characters) or arbitrary long comments for each displayed line. The remark text is to be entered via the single record application KGESGESE and is displayed directly in the list. The actions "Edit comment" and "Display comment" provide functions for entering and viewing the comment. In addition user, date, and time of the last modification of the comment are displayed in the single record map and in the list table.
Remarks and Comments are transferred within the sub-group data exchange. They are preserved at repetition of the respective consolidation function (SK, AE, or ZA). However, they are deleted, if the IC-clearing records themselves are deleted, e.g. at modification of the corresponding consolidation parameter.
Consolidation postings on capital accounts except for postings of capital consolidation vouchers (designated with the flag for affect on the net result = 'K') now can be selected for calculation and posting of deferred taxes just like the calculation of minority interests. In addition it is required for this function, that the new "Account for deferred taxes capital" is defined in the consolidation parameter 'LT' for deferred taxes.
A check for the validity of the combination account / posting key at usage of account/posting key allocation groups (see above) was supplemented in the diverse applications.
An account for deferred taxes on capital was supplemented in the consolidation parameter 'LT' (deferred taxes).
The consolidation function has no longer to be entered in the single record application "Consolidation voucher" KONBELE. It is rather automatically set according to the consolidation function of the voucher number.
The display of non-effective consolidation postings was revised:
A check for the validity of the combination account / posting key at usage of account/posting key allocation groups (see above) was supplemented in the applications for consolidation postings.
The facility for selection for the attribute "Reposting at carry forward" for capital accounts was supplemented in the list "Consolidation postings" (KONBUCH). The new selection field was placed beneath the selection field "Transaction development" without a prompt text for its own to keep the map size in reasonable limits. In addition you can now select data for two account flags (e.g. 'I' and 'J') simultaneously.
The list of consolidation postings now displays the posting record number in the area of fixed columns of the table to be always visible.
The mass update function of the list "Consolidation postings" (KONBUCH) was extended by the facility for update of the posting remark.
The lists "Account balances and consolidation postings" (KONSAL) and "Transactions and consolidation postings" (KONBEW) now displays data from consolidation postings with a coloured background for distinction from the values of the company financial statements.
The list "Account balances and consolidation postings" (KONSAL) was enhanced by the facility of representation in report structure. For this purpose an entry field for the report id was supplemented. In addition a selection for transaction development of the accounts was supplemented. Then positions without allocation of a corresponding development account are suppressed.
The function "Change value" was renamed to "Change balance".
A calculation statistic can be activated via the options dialogue, page "Planner spreadsheet". The same dialogue page also allows to activate or deactivate the differentiation between empty account balances and account balances of zero value.
Reports most frequently used in the past are preselected on the first page of the scenario wizard for a new scenario.
The settings for actual, forecast and plan keys are now performed on one common page of the scenario wizard.
The plan data area can now be turned off completely and offers a scrollbar for definition of the first period within the year just like the forecast data area before.
Existing but invalid periods are no longer removed from the selection list. They are rather greyed out in the scenario wizard and are not selectable.
The display of the chart of accounts can be optionally selected in the list of scenarios.
Up to now optional components (general allowance for doubtful debts, social expenses etc.) could be switched on or off on the first page of the rule wizard. Depending on this setting the respective page later was displayed or not. Now all pages of the wizard are always displayed and the options are switched on or off on the respective page. If an option is switched off the other elements of this page are greyed out.
All accounts already selected in the account tree are greyed out. The icon for identification of intercompany accounts now is displayed in fields with only one selectable account, too.
If you look for an account number using the filter function of the rule wizard and entering an account number and this number is unique, then this entry is selected at once and you can transfer the selected account into the list pushing the arrow button without selecting the account in the list.
If a rule is to be extended by an additional account allocation, then the last existing allocation is simply duplicated. These identical allocations are now provided with a red frame and a warning message is output. So you can see immediately where adjustments have to be performed.
If you start the wizard for a financing rule or an investment rule derived from a rule template containing a start period not existing in the loaded scenario, then the period is automatically set to "Please choose" in the wizard. In addition you receive an advice that the period has to be specified. The value "Please choose" is preselected at the first start of the wizard (without template), too.
If a template is loaded containing accounts not existing in the active scenario, then the accounts are automatically removed and a warning message is output. The removed accounts are listed in this warning message with their chart of accounts and the account number.
The dialogues "Save template" and "Load template" automatically select the templates lastly saved or loaded.
The sales rule now can calculate the sales amount depending on the balance of a base value account. The base value account can be specified on the first page of the wizard. The selection of the tax and the tax rate account were moved to the page for tax releases instead becoming a page for general tax parameters. This page was placed before the allocation page.
The facility to dissolve cumulated purchase and input taxes again was supplemented in the sales and purchases rules.
The investment rule was extended by further depreciation methods. Beside the straight-line depreciation the geometrical declining and the arithmetical declining depreciation are allowed. The depreciation parameters are firmly set to 2.5 times of the linear depreciation rate (max. 25%) for both declining depreciations.
Each account had to be dissolved separately in rules with dissolutions, even if all accounts are dissolved with the same reposting account and the same parameters. Now in this case several dissolution accounts can be selected simultaneously.
The calculation of social expenses in the personnel rule is now optional.
You can now specify the opening balance of a balance sheet account as base value of a generic rule.
You can now define single postings simultaneously for several periods instead of only one period. You can now open and modify single postings in a wizard like other rules. Furthermore single postings can be saved for later application just like rules.
When deleting rules in addition to the options <Delete values> and <Preserve values> you now have the option <Delete balance sheet values>. Then p&l values are preserved.
Up to now there were three icons for the three sort options in the tool bar of the rule template list. For the purpose of saving place there is only one icon left instead. The sorting changes cyclically when selecting this icon with the mouse.
Instaed icons for the actions <Expand all nodes> and <Collapse all nodes> were supplemented in the rule template list. The same applies for the template lists in the dialogues 'Save template' and 'Load template' in the rule wizards as well as the rule tree in the business case viewer.
A filter function is now available for the list of rule templates.
The function "Open in wizard" is now available for the dissolution rules, the transition rule, the generic rule, and single postings.
The menu items "... use ..." in the object menu of a rule template is now greyed out and cannot be selected, if the rule contains missing account allocations. Up to now a warning message occurred yet after using the menu items.
Rule templates can now be exported into a file and then be imported again on the same or another database provided that all referenced accounts exist in the destination database. You can start the export as well as the import via the object menu (right mouse key) of the rule templates.
After starting the export a file dialogue opens for specification of the file name of the export file. The export file has the extension ".rpt".
At import the template directory has to be selected first. After starting the import a file dialogue opens, where you have to select the export file previously exported. If rule templates with the same name already exist the user is requested, whether the existing data are to be overwritten or whether the rule templates are to be inserted with another name.
The tree table displayed in the business case viewer now allows an expansion and a collapse of the complete business case tree.
Generic rules are assigned to a business case group just like other rules and can be jointly deleted over all periods.
You have now the possibility to analyse complex calculations. For this purpose you have to activate the analysis tool. First you have to activate the option "Activate calculation statistic" on the page "Planner spreadsheet" of the options dialogue, then you have to activate it in the planner spreadsheet itself.
The application of this tool is emphasized only to very experienced users, since the features and evaluations are very complex. Furthermore please mind, that the analysis tool requires very much memory and therefore strong adversely affects the performance.
The tool displays different statistics about the calculations. There are general statistics like e.g.
as well as a detailed protocol of all modifications that were performed at the calculation.
The list "Report idents" (RID) no longer displays the columns Transaction development, Reference report identification, and the standard column options on company and group level, if these columns are empty and the user has selected the option "Hide empty columns" in the menu "View".
A report of the new report type 'W' (see below) may reference a report with report type 'F'.
A "Flag default report" was supplemented in the table for report idents. The flag designates development reports (report type 'D') and is evaluated by the forms entry applications for development transactions (see above).
The report option 'D' (Processing of controlling balances with representation of companies in detail level 1) may now be assigned to cash flow reports (report types 'F' and 'W'), too.
The total comprehensive income due to IAS 1 is now supported by the program for generation of group reports. This concerns the facility to combine the functions of the cash flow report (restriction of report lines to single transaction development columns, posting keys or consolidation functions) with the functions of a controlling report (processing of controlling balances instead of account balances including a detail level for controlling objects) and functions of the consolidation report (additional saving of the values per consolidation function in separate report result columns).
For this purpose a group cash flow report (report type 'F') now can be provided with report option 'D' for processing controlling balances for controlling accounts. Like the group b/s and p&l report (report type 'E') with report option 'D' the company is placed in detail level 1. The controlling object is placed in detail level 3 alternatively to the restrictions by posting key, transaction development column, or consolidation function.
The new report type 'W' serves for a combination of cash flow and consolidation report. Thus the report ident definition (RIDE) allows a report with report type 'W' to reference a report with report type 'F'. The report option 'D' is admitted for the report type 'W', too, so that both versions can be combined.
There are no additional column options delivered by IDL for these new reports. Since the report option 'D' does not affect the report result columns, the column options for cash flow reports can be continued to use. For report type 'W' the assignment of the report result columns is identical to the previous consolidation report (report type 'V'), so that the column options for the consolidation report (e.g. '$KVA') can be applied for reports with report type 'W', too.
The structure of the consolidation report now can be designed user specifically (see above). Thus e.g. you can control whether carry forward or deferred tax postings are displayed in columns of their own or allocated to the origin consolidation function.
This feature not only concerns the proper consolidation report (report types 'V' and 'W'), but the details of the group data in transaction development reports with report option 'F', too.
You can now define a transaction development report without restricting it to a single development. You have to define a report ident (RID) assigned to the report type 'D' (development report) without specification of a development required up to now. A warning message is output to avoid faulty operations.
Such a report in principal contains data for all transaction developments activated for the actual period and fact. A restriction to certain developments can be provided only via the report line description (REPZEI) by allocating only positions with the desired development accounts to the report.
Fixed asset transactions are processed, too. However, opposite to the fixed asset report there is no detail for the fixed asset object but only for data out of the company or group financial statement, respectively.
Since the development comprehensive report usually contains asset as well as liability positions, the sign representation applied for development reports otherwise (debit = '+', credit = '-', in case sign inversion via formulae editor) is not suitable. The sign representation rather is done like in b/s / p&l reports: for asset positions debit = '+', credit = '-', for liability positions debit = '-', credit = '+'.
The combination of report type = 'D' without entry of a transaction development is allowed for the columns options (SPO), too, for definition of suitable column options. A warning message is output to avoid faulty operations here, too.
No specific text can be output for the description and selection of the development columns at definition of formulae lines (FED) for these column options.
The development comprehensive report allocates the processed transactions to the report result columns corresponding to the development columns of the respective posting key. Thus the application of such a report requires a unique assignment of the development columns for all processed transaction developments.
A branch from the report result display into the development transactions is only possible if the development of the line is unique. Otherwise it is branched into the account balances instead.
The new detail-display option 'PK' is now available for the display of report results. This option provides that the account lines represent the lowest level of the tree table at full expansion. Further detail (e.g. by company) are not displayed. Especially this option avoids that the tree table shows the next detail level (e.g. companies) in one branch while another branch even does not display the accounts at successive expansion of levels for tree tables with branches of different depth.
In addition the display with report option 'PK' is faster, since the data of the following details are not read.
Further representation variants were supplemented for the output of midget graphics. For this you have to assign one of the following graphic types to the first value column included into die midget graphic:
The graphic types 'L' and 'LD' designated up to now as line charts are now designated as area charts.
The graphic types 'S' and 'SD' designated up to now as sparklines are now designated as bar charts.
Like before following value columns to be included into the midget graphic have to be assigned with graphic type 'D'.
A control field "flag display option report compare" was supplemented into the list "Report compare" (REPERGCOMP). The following two entries are supported:
The value 'D' corresponding to the display up to now is preset.
Some import applications ignore data of the source file (e.g. TXTICKONV ignores ic-account balances on b/s accounts) or generate several records to be processed out of one source data line (e.g. TXTPOSKTO with specification if intervals of account numbers). The statistics output at the end of an import were enhanced for these cases. Now in case the number of transferred, ignored and generated records is output beneath the number of processed, inserted, updated, unchanged, and faulty records.
The selection on the object type was reduced to the object types actually supported object types in the calling application "IE job controls" (IEJOB).
The error output and logging at call of an import job via command line was revised. You can now specify the parameter /logfile= with a log file in addition to the protocol. If this parameter contains no value, i.e. only "logfile=", then the output is written to the standard output (console). This log file is written in addition to the protocol including technical details for execution incl. a return code.
The return codes are defined as follows:
An example call for file import is:
java -jar import.jar /i=D://Konsis//system//idldb.ini /formatname=#TXT /modulname=TXTANLBEW /filename=c://tmp/anlbew_Import.txt /dbms=DB2 /dbname=IDLDB /username=... /pass=... /logfile=//C://TMP//import.log /UMS_GUI= MEINE_UMS
An example for the import of an existing job is:
java -jar import.jar /i=D://Konsis//system//idldb.ini /formatname=#DB /jobid=112 /dbms=mssql /dbname=IDLDB /username=... /pass=... /logfile=//C://TMP//import.log /UMS_GUI=MEINE_UMS
The return code can be output subsequently by the command "echo return code is %ERRORLEVEL%".
java -jar import.jar /help
displays help information listing all allowed parameters.
You have to increase the memory of the java VM for larger import jobs, especially if an OutOfMemoryError occurs. Then you have to supplement the parameter -Xmx<size> at the first place af the command. An example for a call with a memory of 512 MB is:
java -Xmx512M -jar import.jar ...
Up to now the action "Select external data" was not supported for all data stocks listed in the calling application "Data import and display" (IMPORT). This function now was completed by supplementing the missing menu items with the prefix 'UNL'. For application of these menu items you have to enter the specific external calls in the application "Menu items" (MEN) before usage.
The entry of the external call in the application "Menu item" (MENE) was revised. There is only one entry field instead of three previous entry fields each 85 digits long. If the length of the entered data exceeds the length of the entry field, then the content scrolls within the entry field.
The specification of a development column now is required at import of posting keys.
The import of posting keys for shareholding/participations with specification of a reference posting key (e.g. for the fixed asset development) is now supported. Up to now the import had to be started twice because the reference posting keys were not recognised when imported in the same import job (e.g. with the delivered files of the directory "LieferBatch").
The specification of a b/s p&l code is no longer required at import report column descriptions.
The action "Delete data & re-import" deletes only data for key spaces, which are imported, too. Amongst others this applies for data with business units: Only data for those business units are deleted, which are provided with newly imported data. A flag "Ignore business unit with delete" was supplemented in the maps of the calling applications "Data import and display" (IMPORT) and "IE job controls" (IEJOB). If this flag is switched on data of all business units are deleted, even if there are no new data for a business unit. For the time being this control affects only the import of account balances. On demand it can be extended to other data stocks.
A sub-directory "Ergaenzung_Standardspiegel_Verschmelzung" containing only definitons for transaction development columns and posting keys for merger was supplemented in the directory "LieferBatch" on the release CD. Especially you can apply these files if you have made individual modifications on the previous standard, which might be overwritten by a complete update of this standard.
The sub-group and the group-wide data exchange were adjusted to several table enhancements. Besides others the new tables "Voucher classifications" (BKL) and "Groups for account / posting key allocation" (BSG) were supplemented in the group-wide data exchange. Thus compatibility to deviant releases within the group of companies is not guaranteed.
The data entry form of the IDL Connector cannot be used with MS Office 2010. There are no restrictions with MS Office 2010 for the read and the export functions. There are no restrictions for other versions of MS Office (2000 - 2007), too.
For the time being there ist not ODBC driver available for Oracle for the operating system Win 7 - 64 bit. Thus the IDL Connector can be used for this operating system only with MS SQL Server.
The export functions for controlling balances and intercompany account balances were supplemented by the entry of controlling objects for the up to 10 controlling dimensions.
You can now select postings for the company financial statements by the flag for deferred taxes in the read function.
The dialogue window at export of the data entry form can be adjusted manually.
The allocation of controlling objects to companies introduced in IDL Konsis with release 2010.0 is now considered in the controlling balances of the data entry form.
A new configuration parameter "IgnoreKtopl4Anlbew=yes" (to be entered in the division [settings] of the file kcusap.ini) controls, that the chart of accounts is not written into the file KPANLBEW.TXT for transfer of fixed asset transactions. This is case required if data for different charts of accounts are simultaneously transferred.
The release 2010.1 contains a refreshed version of the DCW interface for DCW release 3.50.
With this release the following English-speaking documentations in the "doku" directory are updated or completed: