This release IDL Konsis 2009.1 is an interim maintenance and therefore may be be left out in the release sequence. Prerequisites for this release are the last main maintenance 2009.0 from August 19th 2009.
The supplements of the main maintenance IDL Konsis 2009.0 as well as the corrections to this maintenance up to the release date are included in this maintenance 2009.1.
This documentation describes the enhancements since the main maintenance IDL Konsis 2009.0.
A database backup has to be performed in principle before installing a new release. An advice for the necessary database backup now is output by the installation program at the beginning of the installation to protect the user from data loss.
The release migration (see below) has to be principally performed as the first step after installation of a new release. The call of other applications is inhibited before performing the migration.
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.
The so called "single sign on" (login at a database with the same user name and the same password as for login at the network) for an MS SQL Server database now is supported when working with the IDL Konsis application server / internet client. The maintenance of SQL Server authentifications is no longer required. This as well applies for the application IDL Forecast.
A function for "Preselections" was supplemented in the upper part of the page "Graphics" of the "Options" dialogue. Here several predefined combinations of selected and deselected graphic features are offered for the purpose to simplify the adjustment for the user. The selection <user defined> is always displayed, if the features were selected manually.
The Quickstart window now supports invoking the display of help texts. You have to select the feature <Enhanced quick starter> of the page "Graphics" of the "Options" dialogue for this purpose. Then a book icon is shown on the buttons corresponding to menu items referring to a help text. Clicking on this icon invokes the help text display.
In addition after selecting the feature <Enhanced quick starter> the short word entries of the callable applications are displayed.
You now can select the feature "Table zoom" on the page "Graphics" of the "Options" dialogue. In this case an additional slide control appears for alle tables called afterwards. The zoom feature is available for all kinds of tables, e.g. for IDL Forecast, allocation applications, forms, and selection panels, too.
If you pull this slider to the right, then the display of the table is scaled up, while pulling it to the left effects the opposite, e.g. providing a complete display of the table on the screen. A double mouse click on the sliders provides a reset to the standard scaling. Symbols displayed in the table are scaled, too.
If a cell or a line of the table is selected, then this cell or line is scrolled into the visible part of the table after a zoom operation, if is were invisible otherwise. At multiple selection this concerns only the focussed cell or line
The key combination <Cntl> + <Tab> now facilitates a change between the opened tabs without usage of the mouse. The key combination <Cntl> + <Shift> + <Tab> provides a change in the opposite order.
A single mouse click on a message displayed in the message line provides the display of the message in an additionally opened message box. This is especially helpful, if the message is not completely displayed and truncated in the message line due to a small application window or a longer message text.
The migration program for this release performs the following conversions:
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 new 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 (BENMEN), too. It declares, that a menu authorisation issued for the reference user group is not issued for the given individual user group.
The menu items 'EABVORxxx', 'LOEVORxxx' und 'PERGESxxx' ('xxx' = 'ANL', 'BET', 'KAP', 'RUE', 'SP0', 'SP1', ... 'SP9') as well as 'REPERGGxxx' and 'REPERGKxxx' ('xxx' = 'KAP', 'RUE', 'SP0', 'SP1', ... 'SP9') were already deactivated with release 2009.0 and have no longer any meaning. You have to delete all individual authorisations for these menu items before installation of this maintenance in order to delete these menu items when installing this subsequent release 2009.1. For each group only one menu item with 'xxx' = 'SPI' is remaining.
The SAP interface specific parameters "Variable of financial year" and "If month greater 12" were supplemented in table for menu structure allocations (MENMEN). These attributes can be entered with the single record (MENMENE) or import (TXTMENMEN) application. This enhancement serves for calling the SAP interface via the "UNL..." menu items within an automate control. The attributes are also displayed in the calling applications for workflow controls.
The sorting sequence of the periods in the list application "Period authorisations" (BENABR) is now selected chronologically downward instead of alphabetically.
The account master data (KTO) were enhanced by an entry flag per period type. I.e. there is each an entry flag for yearly, quarterly, or monthly financial statements. If a flag is set to 'X', then data may be entered on this account in periods of this type, otherwise the entry is rejected. The entry flags are preselected with 'X' by the release migration program (except for accounts with account flag 'E', 'Q', or 'U'), so that there is no change for the user for the beginning. For other accounts not scheduled for entry the 'X' have to be removed.
The definition of statistical capital accounts is now supported by allowing the allocation of a statistical account for minority interests to these accounts.
Intercompany accounts for dividends can obtain a special treatment (see below) by allocating them to the new consolidation function 'SD'.
A selection for "vaild within period" was supplemented in the allocation application for positions and acccounts (Z-POSKTO). At entry of a period in this field only those accounts and positions are displayed, that are valid within this period.
You can now allocate reference posting keys not belonging to a fixed asset transaction development (development type 'A') to a participation posting key. The previous condition of identical allocation of both posting keys to the same development area now is only applied if the transaction development of the reference posting key is subdivided into development areas.
Thus the combination of shareholding accounts with arbitrary transaction developments is further supported. However, the transaction development of all shareholding accounts should be unique throughout the system and consistent with the transaction development of the reference posting keys.
The deactivation (setting of a valid-until period) was revoked for the posting key '25' of the former standard capital transaction development via files of the LieferBatch directory, since this posting key is commonly required in the consolidation parameter 'JU'.
An attribute for exclusion groups for check rules (see below) was supplemented in the table for groups/sub-groups (KTK). This attribute can be entered via single record (KTKE) or import (TXTKTK) application.
The mass copy of accounting periods is now performed in two runs, one for the period itself and one for supplement of the previous period. Thus periods inserted in the first run can be entered as previous periods in the second run.
The sorting sequence of the periods in the list application "Period / developments" (ABRSPI) is now selected chronologically downward instead of alphabetically.
New forms applications (I-ABRSPI, I-FACSPI) were created for simplified entry of the maintenance of transactions developments per period or fact. The allocations can be displayed as a table (display 'N' = side by side) or as a list (display 'U' = one below the other) just like in the list applications (ABRSPI, FACSPI). Each cell allows the entry of an allocation flag. However, the deletion of a flag is not supported. You rather have to enter the value '-'. The entries are yet stored in the database after pushing the button <Save>.
The lock of intercompany account balances acts upon postings on intercompany accounts including the deletion of vouchers containing such postings, too, because of the incorporation of the postings into the intercompany clearing (see below).
At entry or manual update of reported data now the new entry flags of the account master data (see above) are evaluated. If the entry flag for the period flag of the actual period ('J', 'Q', or 'M') is not set, then an entry or update is not possible.
At mass copy of reported data (to another period, fact, company etc.) it is now generally checked, whether data already exist with the destination keys. In this case a warning message is output. Then the user has to decide, whether the copied data are to be added (or updated for account balances, respectively) or the copy processing shall be cancelled. This change concerns the list applications "Account balances" (KTOSAL), "Intercompany account balances" (ICKTOSAL), "Controlling balances" (CNTSAL), "Fixed asset transactions" (ANLBEW), "Capital transactions" (KAPBEW), "Provision transactions" (RUEBEW), "Development transactions" (SPIBEW), "Shareholdings/participations" (GESGES), "Inventories IC-stocks" (ICBEW), "Postings" (BUCH) and "Consolidation postings" (KONBUCH).
After locking them the intercompany account balances cannot be modified any more. However, the status of intercompany account balances depends on other data stocks, too, e.g. on account balances on intercompany accounts. Therefore now a check of the intercompany account balances is performed even if they are locked possibly providing a change of the status despite of the lock. This applies for the action "Check & refresh status information" in the company financial statements monitor (EA), too.
A new flag of the consolidation functions (KVA, see above) now determines, whether the entry of amounts in transaction currency is required, prohibited or arbitrary as before. This flag is evaluated by the single record applications as well as in forms and import applications. This control can be set differentiated per clearing group of the intercompany accounts.
The intercompany reconciliation (called from the company financial statements monitor EA, i.e. simulation of the consolidaition without generation of consolidation postings) now includes postings on intercompany accounts, too. This involves the implicit currency conversion, as far as postings exist with local currency amounts only. Please mind, that this control is always applied and cannot be deactivated.
The following enhancements were realised within this context:
You can now start the IC reconciliation even for the consolidation fact, if the corresponding consolidation function (b/s consolidation (SK) or I&E consolidation (AE)) has not been performed yet. This condition applies not only to the selected company/ies but for the other (inter)companies of the group companies as well. The company financial statement monitor (EA) displays only the status of an IC reconciliation but no status information ist provided for real consolidation.
At entry of a new development transaction (ANLBEWE, KAPBEWE, RUEBEWE, SPIBEWE) the transaction date is no longer preselected. However, it is an optional (white) entry field and has not to be entered. If it remains empty, it is set to a default value, namely
In addition it is checked, that the transaction day must not be younger than the last day of the actual period.
Up to now the current changes of automatically calculated development transactions were determined from the difference of the account balance and the amount carrie forward. In future development transactions with posting keys with usage tag 'E', 'F', or 'Q' are considered, too, that e.g. stem from the consolidation of a sub-group for creating an individual financial statement (KTK2GES).
In special cases (e.g. after several additions and proposals with large changes in currency exchange rates) it was possible, that the investment book value bacame zero or even less, although the participation percentage was positive, of course. The percentage was interpreted as a negative value providing subsequent errors. Therefore now the sign of the percentage was uncoupled from the debit/credit flag of the shareholding transaction. In future the percentages have to be entered with a sign, i.e. for participation disposals a negative percentage has to be entered. However, a warning is output if the sign of the percentage is not in agreement to the debit/credit flag of the shareholding amount. All existing shareholding transactions are correspondingly adjusted by the release migration program.
The check for reasonable total percentages of all shareholding transactions on a subsidiary was revised as follows:
The list "Shareholding / participations" (GESGES) provides the display of the development of the shareholding by entering a period interval. Then all transactions carried forward are suppressed and only the transactions in effect are visible. However, when working with interim financial statements the data of the corresponding periods were displayed, too, causing multiple display of changes. Therefore now the interim periods are suppressed in this display.
The list "Shareholding / participations" (GESGES) was enhanced by a new entry field for the language providing the display of translations of the displayed accounts and posting keys in the selected language.
At entry or manual update of reported data now the new entry flags of the account master data (see above) are evaluated. If the entry flag for the period flag of the actual period ('J', 'Q', or 'M') is not set, then an entry or update is not possible. If the entry flags are differently set it may happen for the multi period forms, that for these accounts values may be entered only in some columns.
A help text column was suppelemented in the entry form for account balances just like in several other lists. A [green] status (or hook, respectively) in this column indicates, that an help text for the account of this line exists. This help text is displayed by double mouse click on this cell. You can use this feature to specify which data are to be allocated to this account.
If the new flag "Transaction currency" (see below) is set to 'X' or 'L' for at least one relevant consolidation function (KVA) then the forms entry application for intercompany account balances (I-ICKTOSAL) offers additional entry columns for amount and currency of the transaction. In return the corresponding entry fields are suppressed in the dialogue for additional data.
The following new check rule operators were supplemented:
The percentage "X" in the latter four check rule operators has to be specified in a new attribute of the check rule definitions (PRF). The entry format allows up to three digits before and after the decimal point.
Check rule exclusion groups can now be allocated to groups/sub-groups (see above), too. At calculation of the checkrule results for the group financial statement the check rules contained in the exclusion group are not processed.
If a group/sub-group is stated in the list applications Currency conversion headers (WUM) and Account currency conversion rules (KTOUAW), then the selection box for companies is restricted to those companies belonging to the group companies.
Three new consolidation functions were introduced with respect to the enhancement of the b/s consolidation by extra functions for dividends (see below):
One new consolidation function was introduced with respect to the renaming of consolidation functions for minority interests (see Release 2009.0 News):
A flag for the entry of transaction currency values was supplemented in the table "Consolidation functions" (KVA). This flag controls for the consolidation functions concerning the intercompany clearing (b/s consolidation with 'SK', 'SD', 'S0', 'S1', ... 'S9' as well as I&E consolidation with 'AE', 'A0', 'A1', ... 'A9'), whether the entry of transaction currency values is required for intercompany balances on accounts allocated to these consolidation functions. The following entries are offered:
The allocation of this attribute to the consolidation function allows a differentiated control per clearing group of intercompany accounts. In addition, the setting of this flag to 'X' or 'L' is recommended for the splitting of transaction currency differences into non-cash differences and exchange rate differences (see below).
Now the entry of posting keys is required for all consolidation functions, if a stated account is allocated to a transaction development and this development is activated for the actual period (ABRSPI) and the actual fact (FACSPI). Only transaction developments for currency conversion by a currency rate average per month ('MDK') are excluded from this rule. The posting key with usage tag 'L' is admitted for automatically generated transaction development and inserted as a default value, if no posting key has been entered.
A flag for the treatment of transaction currency differences was supplemented in the consolidation parameters for b/s consolidation ('SK', 'SD', 'S0', 'S1', ... 'S9') and I&E consolidation ('AE', 'A0', 'A1', ... 'A9'). The only possible entry value is 'X' (splitting of transaction currency differences into non-cash differences and exchange rate differences, see below), while no entry corresponds to the processing up to now providing that nothing has to be changed, if the former processing is to be continued.
The list "Group companies + monitor" (KTKGES) now automatically performs a status determination before the display of the data providing the display of actual status columns with respect to this function. Thus an explicit call of the status calculation is no longer needed. Therefore the corresponding function was reduced and renamed to "Calculation participations".
The classification of a company to be the parent company of the selected group/sub-group companies is no longer displayed in a column of its own but rather as a coloured ([green]) background of the column for the participation level. In addition the level number '0' is always output for this company, even if no calculation of participations has been performed. This applies for ordinary parent companies (parent tag = 'X') als well as for equally ordered group parents (parent tag = 'G').
Up to now the status 'MB' for manual vouchers was only displayed in summary in the topmost node line for the complete group/sub-Group in the corresponding column. This status is now differentiated between the companies. Please mind, that a voucher is always assigned to the companies stated in the voucher number, i.e. independent from the companies stated in the single postings.
When setting the consolidation method of a company to 'K' (no consolidation) or entering a disposal date in the single record application (KTKGESE) for a subordinate sub-group the user is asked, whether this update shall be performed for the superordinate group levels, too. At answer [No] the update is performed only for the current sub-group like up to now. Answering [Yes] provides the analogue update (consolidation method or disposal date, respectively) to be performed for superordinate groups, too, prerequisited that the company had been stated there with the same consolidation method and without disposal date, respectively, as in the actual sub-group.
The list "Group companies + monitor" (KTKGES) provides a branch into the calling application "Data import & display" (IMPORT) in the sub-menu "Functions".
A branch from the list "Group companies + monitor" (KTKGES) into the list "Deferred taxes header" (LTK) in the sub-menu "Deferred taxes" has been supplemented, too.
The former application for determination of participations and status was reduced to a determination of participations (calculation of participation level and percentages). The sub-function for status determination runs now automatically at each call of the list "Group companies + monitor" (KTKGES) providing for dispensability of the explicit call.
The intercompany clearing group 'SD' was supplemented in the table of consolidation functions (KVA) within the b/s consolidation in addition to 'SK' and the individual clearing groups 'S1' to 'S9'. This function primarily serves for the consolidation of dividends.
The intercompany balances of the intercompany accounts allocated to this consolidation function are processed within the b/s consolidation just like other intercompany balances. The postings are written into consolidation voucher with function 'SD' in the voucher number.
However, deviating from other vouchers for the b/s consolidation this voucher receives the posting type 'WU' instead of 'WX', i.e. the postings are carried forward with one-time reposting of the postings affecting net result onto the account for retained earnings. 'SD vouchers are carried forward into a voucher with (also new) consolidation function 'VD' in the voucher number.
You can calculate deferred taxes on 'SD' vouchers. Then a voucher with the consolidation function 'LD' in the voucher number is generated.
A new procedure facilitates the split of a difference from the values in transaction currency into a currency rate difference and a non-cash difference. A new flag for "Handling of differences in transaction currency" was supplemented in the consolidation parameters 'SK' and 'AE' (incl. the individual clearing groups 'Sn' and 'An') for control of this procedure. In addition it is recommended, that all intercompany account balances are furnished with transaction currency values. This can be controlled by the (also new) flag for transaction currency in the consolidation function (KVA) (see above).
If the flag "Handling of differences in transaction currency" is set and a difference in transaction currency above the threshold value stated in the respective consolidation parameter occurs, then this difference is converted into group currency. For this purpose at least for one of both companies a currency conversion header (WUM) has to be definied to decide, whether p&l values are to be converted by the closing date exchange rate (SK) or the average exchange rate per period (PDK). B/s values are always converted by the closing date exchange rate. In addition exchange rates (WKZWKA) have to be provided for the respective transaction currency.
The amount resulting from the conversion into group currency is treated as a non-cash difference and compared to the group currency threshold value of the consolidation parameter. If it is below the threshold value this value is posted on the account for threshold value clearing and the posting status is set to '3' (automatically cleared via transaction currency). If the converted difference is greater than the threshold value it is posted to the difference amount interim account, if stated, or remains open and the posting status is set to '4' (automatically generated, manual supplements required).
The remaining difference (total difference in group currency minus this non-cash difference) is treated as exchange rate difference and posted on the account for exchange rate differences of the consolidation parameter just like transaction currency values in agreement.
Because of the enhancement of the intercompany reconciliation in the company financial statements for inclusion of postings (BUCH) on intercompany accounts (see above) columns for the contribution of the postings to the intercompany amounts of the company or the IC company, respectively, were supplemented in the IC clearing list (KGESGES). A double mouse click on these columns provides a branch in to the list "Postings" (BUCH) with preselection of company and IC company for display of the postings responsible for this amount.
At successive acquisition of a subsidiary within one period the capital consolidation generates several vouchers with consolidation function 'KK', 'K0', 'K1' etc. in the voucher number. If working with intermediate financial statements consolidation vouchers are copied from the previous period. For the actual period only shareholding changes are handled, that are not yet processed. This is recognized by the entry of a voucher number in the shareholding transaction. Thus e.g. a compensation of a difference amount entered in a previous period is maintained.
There is one exception from this rule, if already all shareholding transactions contain a voucher number. Then the automatic capital consolidation deletes all existing vouchers and generates new ones. If however only single vouchers shall be newly generated, then they have to be deleted in advance.
The capital consolidation (KK) now supports shareholding accounts allocated to another transaction development than a fixed asset transaction development, too.
The capital consolidation (KK) including the determination of direct minority interests on the capital now supports statistical capital accounts, too. The forms application (I-ERSTKON) doesn't consider amounts on statistical capital accounts in the totals for the difference amount or the minority interests, respectively. A posting for minority interests is generated only if a (also statistical) minority interest account is allocated to this account in the account master data. This applies for the posting of direct minority interests of later changes on these accounts in 'FF' vouchers, too.
Percentages now are written with up to 8 decimal digits into the posting remarks just like their entry.
The calculation of minority interests on increased or disposed equity capital is only performed, if capital transactions are provided, since otherwise real changes and currency exchange rate effects cannot be doubtlessly distinguished.
The consolidation vouchers for "Update Equity" (consolidation function 'EF') now yield the correct posting type 'WU' (repetitive posting with transfer). The 'EF' vouchers were already carried forward due to this rule before, but the stated posting type 'E' (single use posting) was misleading.
The new consolidation function 'LF' was introduced for deferred taxes on minority interest postings. These postings are carried forward into the voucher for minority interests ('FV').
The selection field for the processing tag of consolidation vouchers ('B' = into process, 'I' = information) is now preselected with 'B' in the list applications "Consolidation vouchers" (KONBEL) and "Consolidation postings" (KONBUCH) so that only active vouchers or postings, respectively, are displayed, if this preselection is not modified. The preselection has to be removed, if inactive vouchers or their postings, respectively, shall be displayed. However, then the total values contain the contributions of inactive vouchers, too.
The selection box for companies is restricted to those companies belonging to the group companies.
It was introduced with release 2009.0, that consolidation vouchers carried forward must not be manually deleted without extra authorisation. In order to support the deletion without definition of individual authorisation groups the extra authorisation was allocated to the standard authorisation groups IDLADMIN and IDLWINAD.
When deleting a consolidation voucher generated by the capital consolidation (KK, FK) the other simultaneously created vouchers of this task (i.e. e.g. all 'K3' and 'F3' vouchers for this company) are as well deleted automatically. In addition the entry of these voucher numbers is erased from the shareholding transactions. Otherwise the repetition of this consolidation function would not be performed correctly.
The list "Transactions and consolidation Postings" (KONBEW) does no longer include capital transactions on statistical accounts (b/s/p&l code '7') into the displayed totals.
The list "Shareholding/participations and progression of capital" (KONGESGES) can now be called for interim periods, too, and displays the relevant data.
The display of total columns was completed. A total for the fourth quarter is now displayed beside the total for the complete accounting year. In addition the quarterly totals are no longer output, if all 11 months (except for the accounting year period) have the period flag 'M' in the period master data (ABR).
You can now exchange values of several cells between IDL Forecast and other applications (e.g. MS Excel) using the functions <Copy> and <Paste>.
Accounts with account flag 'J' are now designated with the icon for intercompany accounts, too.
Accounts with account flag 'Q' are suppressed in the planning spreadsheet.
The icons for "Undo" and "Redo" function (revoke or repeat the last modification, respectively) were adapted to the windows standard (round instead of straight arrows).
Although a cell is empty, it may contain several entries (changes) in its details. Therefore 0,00 is displayed for empty cells if more than one change is present. In addition the empty/0,00 cell is designated by a green dot, if there is only an automatic change. However, if there is at least one manual change, then a blue dot is displayed. These dots are displayed only if there are no rules present.
Many rules currently work only correct, if the periods are defined completely and continuously. A scenario with monthly details requires twelve months per accounting year, a scenario with quarterly details requires four quarters with a distance of three months each. Accounting years, that do not meet these conditions are no longer offered in the scenario wizard to protect the user from defective scenarios.
You now can copy scenarios. If you select a scenario in the scenario manager, press the right mouse key and then select the menu item "Copy scenario" a dialogue window opens, where you have to enter the name of the new scenario. E.g. you can use this feature for creating a backup of a scenario. In addition you can select, that the scenario is not copied completely with all values but only its structure and rules are copied.
You now can rename a scenario.
The new menu item "Refresh reports" provides the update of the report structures of the scenario currently loaded. Then the report structure of the scenario are adjusted to the report definitions of IDL Konsis. New positions and accounts are supplemented in the scenario. However, no positions or accounts are deleted from the scenario or dislocated.
A check box was suppelemented in the sales rule wizard, that allows to activate the release of the general provisions for doubtful receivables. If it is activated, for each receivable of a period a posting between the general provisions account and the receivables account is inserted in the subsequent period, that releases the general provisions amounts of the general provisions posting.
The last page of the sales rule wizard was designed more intelligible by additional texts. In addition the period of the new payment component is automatically set to the next later available period when adding it. The table is sorted by periods.
The purchases rule wizard was enhanced by payment postings. The design of the wizard and the calculation of the postings are adjusted to the procedure of the sales rule wizard.
Similar to the sales rule wizard the personnel rule wizard was supplemented by payment postings, too. The postings are effected between the accounts payables wages, payables loan, payables social costs wages, and social costs loan on the one hand and a bank or cash account on the other hand. A payment is performed in the same month, the subsequent month or pro-rata between these months for all four payables. A check box was supplemented on the first page of the personnel rule wizard that activates this calculation of payment postings. If it is activated, then an additional page is appended to the wizard where a bank/cash account may be selected and a percentage for the current and the subsequent month can be entered for each of the four payable types.
The purchase and the personnel rule wizards allow the entry of percentages on the first page, that are used as a standard value for the corresponding fields in the account allocations on the following pages, but can be adjusted there again. In fact only the entries on the allocation page are relevant for the rule to be built. This was misleading especially when opening and adjusting a rule template. Therefore now a dialogue opens asking the user for update of all existing account allocations with the new value at entry on the first page of the wizard, if account allocations have been applied before.
On the page for payment conditions of the sales rule wizard at its first call a standard payment component is now automatically generated with 100% interest and 0% discount in the starting period.
Like already for the investment rule now there is a detail view for the rule viewer for personnel, sales, purchase business cases, that allows the display of all parameters of the business case (incl. payments, payment conditions, general provisions, retained security amounts etc.) on one view.
The account flag 'J' is now considered by the rules in the follwing way:
If a period is selected in the table area, then the rule wizards now preselect 'Apply rule only for selected period' instead of 'Apply rule for all periods'. Further options in this context are application of the rule to all plan periods or to all forecast periods, respectively.
You now can rename a rule template.
The name of a rule template originally opened is displayed as a tooltip on the template button in the rule wizard for the purpose of better orientation. If the rule is saved, then the name of the rule template is preselected for the name of the rule.
The account viewer now shows the fact and the period, too. Thus the user can see more easily which cell is displayed in the viewer.
There is a new facility for copying IDL Forecast data between two IDL Konsis installations (see below) within the data exchange functions. However, for the time being this facility can only be used one time to transfer data from one installation (e.g. test system) to another system (e.g. productive system), since all IDL Forecast data are deleted in the destination system before inserting the transferred data.
If a group/sub-group is stated in an online application for maintenance of the report definitions or report display, then the selection box for companies is restricted to those companies belonging to the group companies.
The dynamic replacement of report header texts (of report ident (RID) or report version description (REP)) by the specific report parameters has been extended. You can now supplement '!L' or '!K' to periods (parameter 'ABR') for replacement of the placeholder by the short or long description of the period. In addition the format specification 'yy' (opposite to 'yyyy') provides the output of the year number with two digits.
If you start a mass generation of reports by selecting all or many lines of the report list (REP, REPK) then the message about no generation for reports with entry of a reference version can be suppressed. Thus this mass processing can be run through without permanently committing messages, even if reports with entry of a reference version have been selected.
You can now lock a report against modifications, i.e. a locked report must not be newly generated. E.g. this is useful for reports that have been approved by a certified accountant.
The action "Lock report" has been supplemented in the report lists (REP, REPK) and the single record application (REPE) for the purpose of locking the displayed or selected report. The lists visualise the lock status with [green] in an additional column. An error is reported if you attempt to newly generate a locked report. The user having locked the report and the timestamp of the lock can be taken from the entries of the last modification since further modifications of the report are not possible.
Another action "Unlock report" serves for revoking the lock. This state is visualised by the status [yellow] in the report lists.
The lock is not analysed at the exchange of sub-group data. Here a locked report is replaced by the report delivered by the sub-group independent from ist lock state. Of course the delivered report may be locked, too, in the sub-group.
If you select a column option in the report result list (REPERG), that provides the display of the objects of detail level 1 (e.g. companies) in columns (e.g. '#ROHGE'), but no consistent detail option beginning with '1' is selected, then the detail option is automatically replaced by the corresponding detail option with '1' ('P' -> '1P', 'T' -> '1T', 'TA' -> '1TA').
If the objects of the first detail level (e.g. companies) are displayed in columns in the report result list, then you now can branch into the corresponding detail data. E.g. a double mouse click on a value for a company column branches into the list of account balances only for this company.
The facility of branching from the report result list (REPERG) into the list of "Column descriptions" (SPA) was supplemented. This action displays the columns of the column option (SPO) stated in the selection area independent from selected columns.
If branching from a report result list (REPERG, REPERGS) into the consolidation vouchers list (KONBUCH) the sort option 'KB' (sort by account number and posting key) is now preselected.
A new list application "Report compare" (REPERGCOMP) provides the comparison of two reports. The selection area contains entry fields for the keys of the reports (Group/sub-group, Company, Business unit, Actual period, Fact, Report ident, Report version), but only for the report version two entry fields are offered. I.e. the other keys have to be identical for both reports to be compared and you can only compare two versions of this report, that have to be supplied with the same report option, too. In addition you can specify a detail option and a language for the display.
The comparison always refers to only one value per line. This is the total of balances and postings for b/s, p&l and cash flow reports and the total value at the end of the period for transaction development reports each only for the actual period and fact. Therefore this list has no entry for a column option.
The list doesn't display the complete reports but only the lines that have different values displayed as well as in case their superordinate nodes, since this is required for a display in tree structure. Both value columns are neutrally designated with "Result report" and "Result comparison report".
You can call the list "report compare" from the report lists (REP, REPK), too. Then the keys of the selected report are transferred, while the version number of the comparison report has to be supplemented.
The main purpose of this function is the comparison of a locked report (see above) with a uniform report generated at a later timestamp for determination of the modifications performed in the meantime, e.g. if the locked report exhibits a [red] check sum status.
Check sums are now calculated and stored for multi period reports, too. However, these check sums always refer to the data of the actual (latest) period and fact, i.e. to the keys of the report header, whose modification is most probable, e.g. since the previous periods are usually locked.
Column options with allocation to an object type (e.g. 'CY' for the display of companies in columns) are limited to 20 columns. However, an exception was made for the object type 'CU' (currencies). There you can now define up to 50 columns just like for column options without allocation to an object type.
The choice dialogue for fields for the allocation of fields to import/export formats (IEFFEL) is now limited to the fields corresponding to the format type ('TABLE' or 'TXT' or 'XML', respectively). E.g. at definition of a TXT format the fields referring to import via IEJOB ('Ixxx-...') are no more offered.
When importing reported data the new entry flags of the account master data (see above) are evaluated. If the entry flag corresponding to the period flag of the actual period ('J', 'Q', or 'M') is not set, an import is not possible.
New import applications, that can be invoked by the calling application "Data import & display" (IMPORT ), were supplemented for the following data:
The import functions for these data support the insert of new data and the update of existing data. However, an import with deletion in advance is not supported.
Please view the according format specifications in the list "Allocations import/export fields to formats" (IEFFEL). The standard export formats of the according list applications have been adjusted to the corresponding import formats.
Furthermore the import applications for allocation if import/export fields to formats (TXTIEFFEL) and menu items (TXTMEN) already existing were supplemented in the branch "Import others" of the calling application "Data import & display" (IMPORT ). Up to now these import applications could be invoked only in the special calling application "Data import & display" (IARIMP) in the menu branch "Translations".
Account group provide the allocation of attributes to accounts, that cannot be extracted from the data source (e.g. accounting system), at the import of account master data. Up to now the allocation of the b/s p&l codes to account groups could be controlled. This procedure was now extended to account flags, transaction developments, and consolidation functions (SK/AE). You can assign these attributes to account groups in the corresponding applications (KTOGRP, KTOGRPE, TXTKTOGRP). This is evaluated at the import of account master data (TXTKTO).
The company and sub-group data exchange was adjusted with respect to several supplements in the processed database tables.
The group data exchange was adjusted with respect to several supplements in the processed database tables.
A facility for copying IDL Forecast data between two IDL Konsis installations was supplemented in the data exchange functions. The new functions were supplemented in the sub-menu for group-wide data, although only some data can be viewed as group-wide data while other data are rather sub-group data.
Two new menu items in the calling application "Group subgroup data exchange" (KONDAT) in the branch "Group data exchange" serve for unloading IDL Forecast data:
The loading of the unloaded data has to be performed with the corresponding load function ("Load group-wide data with forecast" or "Delete & re-load forecast data", respectively).
In addition please mind, that the entry of "from modification date" does not affect the unloading of IDL Forecast data. In principal all existing data are unloaded and inserted in the destination environment with previous deletion of all IDL Forecast data.
The deletion of sub-group data after their archiving (loading into an archive database) seemed to be possible only for single periods but not for intervals of periods, since an entry field for "from period" was missing in the window for control entry of the keys. However, this entry field was dependent from the position of the check box "Reduce number of fields" in the options dialogue (page "View"). The output of this field now takes place independently from this option.
The new entry flags of the account master data (see above) were supplemented in the export function.
In addition the entry flags as well are evaluated corresponding to their meaning in the entry form. I.e. accounts not scheduled for entry in the type of the actual period are suppressed.
SAP Interface with IDL Importer
You can now unload (indivdual) development transactions from the SAP system with the IDL Importer based SAP interface and import them into IDL Konsis.
The possibilities for calling the SAP interface within an workflow control were enlarged by the supplement of the SAP interface specific parameters "Variable of financial year" and "If month greater 12" in the menu structure (see above).
With this release the following English-speaking documentations in the "doku" directory are updated or completed: