This release IDL Konsis 2009.2 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. However, it also can be installed following the installation of the interim release 2009.1 from November 26th 2009.
The supplements and corrections to the main maintenance IDL Konsis 2009.0 as well as the interim maintenance 2009.1 up to the release date are included in this interim maintenance.
This documentation describes the enhancements since the interim maintenance IDL Konsis 2009.1.
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.
It is now checked for the consolidation of D&C (SK) and I&E (AE), whether all relevant intercompany balances are stamped with a consolidation voucher number as an evidance of their processing by the respective consolidation function just like already before the shareholding transactions with respect to the status of capital consolidation. if not all intercompany balances arre stamped the respective status is set to [red].
It is strongly recommended to lock all closed periods, if the group financial statements are not locked yet, to avoid a status update by this check. The activation of object authorisation for periods for all users is prerequisited for this. The lock of group financial statements is only possible before installation of this release, since the status update is performed before setting the lock with the new release.
a group financial statement should be performed either completely with the previous release or completely with the new release incl. carry forward but without the function "Reposting group result" (JU) with respect to the introduction of the new method for representation of the effect of consolidation vouchers on the net result (see below).
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. Only applications for maintenance of authorisation data are excluded from this rule for the case, that the user has no authorisation for invoking the migration program due to the usage of individual authorisation groups.
Due to technical reasons the migration of IDL Forecast data cannot be performed within the general release migration. The migration of IDL Forecast data has to be started separately. A new entry in the action menu of the application "Planner spreadsheet" (PLAN) serves for this purpose.
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 problems with the Look & Feel setting "Nimbus" were solved.
Up to now "traffic light" representation was used for the status display of locks: green hook = locked, yellow warning triangle = lock revoked. These lock status are now represented by icons of their own: locked padlock with a green hook or opened padlock with a yellow warning triangle, respectively. This concerns the monitor applications(EA, KTKGES) as well as the report lists (REP, REPK) and consolidation vouchers list (KONBUCH).
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.
Accounts generally serve for the entry of reported data. Therefore the entry flags per period type introduced with Release 2009.1 now are preset at entry of a new account, so that they no longer have to be specified explicitely.
In addition it is assumed at import, too, that set entry flags are the normal case. If these attributes are empty in the entry data, then they are set at insert of a new data record. For the purpose of creation of accounts without entry flags you have to specify explicitely the deletion character '*'. Only special accounts with account flags 'E' or 'Q', where the setting of these flags is not allowed at all, are excluded from this rule.
A modification of the entry flags of a group account was already inherited by the allocated company accounts up to now. Now this inheritance is extended to the modification of the allocated group account of a company account. This concerns the usual maintenance of the account master data as well as the loading of the group-wide data (KONDAT) in a sub-group database.
The selection box for accounts was revised with respect of the entry flags as follows: Not enterable accounts are not offered in the selection boxes of applications for entry of reported data (single record, form entry), hoever, all other applications (lists, parameter applications) offer all accounts again for selection of data.
Selection fields for account flag, transaction development and accounting type of the accounts were supplemented in the list "Postions & accounts allocations".
The sort option 'P' (only accounts with deviating position allocation of the allocated group account) now allows an additional facility for selection for error status ('1' = different debit/credit allocation, '2' = no position allocation of the group account, '3' = no position allocation of the company account, '4' = simultaneous entry of account if D/C changed and debit/credit allocation, '5' = missing position allocation for group account with account if D/C changed, '6' = superfluous position allocation of the group account).
It is now assured for accounts with firmly allocated intercompanies (mere main balance sheet accounts), that the account is not longer valid than the intercompany, since invalid data may be generated otherwise. The extension of the validity of the account causes an error. The reduction of the validity of the company is inherited by the account.
The reduction of the validity of a group account is now automatically inherited by the allocated company accounts. This concerns the usual maintenance of the account master data as well as the loading of group-wide data in a sub-group (KONDAT).
Hierarchies of controlling objects can now be built for all definied controlling dimensions. Up to now this was supported for the first controlling dimension only. This concerns the setting of the flag of aggregation in the controlling object master data (CNT) and the allocation in the allocation table (CNTCNT) as well as the display in the list of controlling balances (CNTSAL).
The list "Hierarchy of controlling objects" now additionally displays the hierarchy level. This in case may be required for the control of reports (see below).
The (former standard) capital posting key '05' was supplied with the usage tag 'JU' by the release migration program of release 2009.0, but it was not not supplied with the reservation flag although it was concurrently defined, that posting keys with usage tag 'JU' are reserved, i.e. they may not be used for manual entry of data. Thus a manual usage was possible. However, an arbitrary modification of the posting key master record (e.g. update of its description) caused the setting of the reservation flag and the posting key could no longer be used freely. For the purpose of a uniform behaviour for all users the migration program for this release 2009.2 sets the reservation flag for posting keys with the usage tag 'JU'. If you have demand for a posting key for manual postings in this transaction development column, then you can define another posting key for this purpose or you use the posting key '16', that was not automatically supplied with the usage tag 'JU'.
An action for mass update was supplemented in the list "Company & business unit allocations. There you can modifiy the attribute "Account group".
The mass update function of the list "Closing date actual periods" was enhanced. You now can modfiy the attributes "Period flag" and "Exclusion group for check rules" for several selected periods.
The column for the attribute "Exclusion group for check rules" is now displayed in front of the flags for detail data in the list.
A completely new function faciliates an access ("Drill through") to foregoing systems for determination, how data held in IDL Konsis are composed of data of the origination system. For the time being this function is provided for account balances and can be invoked by an action menu item of the list "Account balances" (KTOSAL) or the form entry "Forms account balances" (I-KTOSAL).
The key parameters for period, fact, company, business unit, and account number are transferred to the new application and displayed in the selection area there. If a configuration for the query is already defined you can push the button <Display> and the table displays data selected from the origination database.
If no configuration is defined yet, the you have to activate the second tab "Configuration" of the selection area. On the left hand side you find there entry fields (URL of the connection, Java class of the driver, User name for login) for the connection to the external database. On the right hand side you find an entry field for the SQL command for querying of the data. Entries in these fields are saved in the database, if the button <Save> is pushed, and are available for following calls of this function.
For reasons of data security only the user name but not the password for the login is saved in the IDL Konsis database. Thus the password has to be entered in a login panel at each display of data.
Technical Advice: The access to the external database is performed via JDBC. A suitable JDBC driver for this database system has to be provided by the user.
The status for locks of company financial statements and intercompany account balances are now represented by new icons (see above).
It is now possible to enter data in mere main balance sheet accounts with the firmly allocated intercompany as a key company, if in addition an IC business unit is allocated to this account, that is different from the key business unit. In the same way it was already up to now possible to enter (e.g.) intercompany account balances with identical company and intercompany, if business unit and IC business unit were different.
A column for the attribute "Reposting at carry forward" from the account master data was supplemented in the table of the list "Account balances".
The list "Controlling balances" now allows a selection for controlling objects of arbitrary controlling dimensions. For this purpose you have to enter at least the chart of controlling objects of the respective controlling dimension. Then the controlling objects of this dimension are displayed in the fixed area of the table. This applies to the tree representation at definition of hierarchies of controlling objects, too.
A second function for Generation of controlling balances out of intercompany account balances with entry of controlling objects is now available in the list "IC-account balances" (ICKTOSAL). This function generates controlling balances on accounts with account flag 'J', too. If applying this function please mind, that the total of the generated controlling balances not equals the account balance, if the total if the intercompany account balances not equals the account balance, since the account also represents connections to third parties.
When branching from the "IC clearing list" (KGESGES) into the list of intercompany account balances (i.e. in the couple view with unique specification of a consolidation function) as well as with set flag "Handling difference of transaction currency" in the respective consolidation parameter additional columns are displayed: the amount in transaction currency converted into group currency and the difference between this amount and the original amount in group currency (converted from the amount in local currency). Thus the values posted by this method can be directly reproduced. In this case the (otherwise usual) grouping by transaction currency is not applied.
The attribute "profit or loss value" to be entered at group companies disposal was defined with only 9 decimal places in the database. Thus amounts exceeding 1,000,000,000.00 could not be specified. A new database attribute had to be defined to allow 13 decimal places like for other amounts. This new attribut is supplied with the amounts of the old attribute by the release migration program. The user interface remains unchanged.
An additional posting representing the amount of the result effect is now generated automatically on the result account (with account flag 'E') for vouchers affecting net result. Of course, this posting is not used for calculation of the debit/credit identity and the result effect. In addition it is not used for the calculation of check sums, too.
The generation of this additional posting proceeds at each check of the vouchers, i.e. at display of the postings as well as at each modification. However, these postings are not generated for locked periods and locked company financial statements.
Postings on the result account are ignored at import of postings (e.g. after export from another IDL Konsis installation) without reporting. However, after import these postings are newly generated.
Postings on the result account are ignored at carry forward into the next period, too. Thus the carry forward voucher is created independent from the generation of postings on the result account in the previous period.
These postings are not processed by the currency conversion, too. They rather are newly generated by the subsequent check in all three currencies (local, group, and parallel currency).
These postings are ignored at transfer to the next fact, too. Like before the result effect is represented by a modification of the account balance of the result account.
The form entry for postings (I-BUCH) displays these postings on the result account, but they cannot be modified. Of course, the are not used for calculation of differences.
The programs for report generation were not modified, since the consideration of postings on the result account is the scope of the introduction of these postings. Especially cash flow reports on facts below the level of consolidation lead to the correct result, if these postings are regarded. In addition reports with origin audit trail are improved, too.
Another advantage of these postings on the result account is the possibility of adjustment of carry forward an other checks for consistency on facts with postings with the aid of check rules.
The selection of postings for calculation of deferred taxes is now admitted without extra authorisation (e.g. with respect to the modification of postings with reserved posting keys) for all automatically generated postings (e.g. automatic calculation of depreciations).
The applications for form entry of reported data (account balances, intercompany balances) now evaluate the attribute "account group" of the "company + business-unit allocation" (GESUBR). E.g. if a business unit is designated with 'G' (only p&l) for a company then no balance sheet accounts are offered for entry.
The forms application for account balances now allows simultaneously the display of a non-enterable column with comparison values (e.g. actual balances of the latest annual statement) adn the entry of several periods (e.g. planned data of the quarters of the current year) besides each other. For this purpose the entry field "previous period" in the selection area was replaced by two entry fields "From period" for the beginning of the entry interval (entry only allowed with column option 'P') and "Closing date previous/comparative period" (entry allowed with column options 'P' and 'D').
The possibilities for entry and update of development transactions with reserved posting keys were adjusted to the rules of the single record applications. If extra authorisation for the actions "Update" and "Insert" is present, then these data may be entered and updated in the forms application, too.
Postings for all business units now can be entered within one form on facts with data differentiated by business units. For this purpose the selection field for business units allows the entry '%' for simultaneous selection of all business units or a corresponding partially qualified entry.
The following new check rule operator was supplemented:
This check rule can be amended with tolerances.
Tolerances now can be specified for further check rules, especially for check rules for unequal-operators, too, e.g. "L>=R". Then this check rule is complied even if the left hand side is less than the right hand side as far as the difference is less than the specified tolerance. Up to now tolerances could be applied only for equal-operators.
The deletion of check rules (e.g. defined for test purposes only) was difficult, if check rule results for these check rules alreads existed. The deletion is now simplified by an automatic co-deletion of all check rule results created for this check rule. However, the depending check rule status values are not updated.
If no check rules were to be applied for a company or group financial statement at all (e.g. with respect to the definition of a check rule exclusion group), then the corresponding status is set to [-]. Hitherto the check rule status was set to [green] (all ceck rules complied).
New check rule results now can no longer be calculated for locked company and group financial statements. Up to now this was possible and in case caused a change of the check rule status from [green] to [red] because of newly defined check rules or the update of data from a comparison period or fact, while the data of the actual statement remained unchanged.
The company financial statements of companies with consolidation method 'K' (no consolidation) or 'E' (equity-consolidation) are no longer comprised into the group check rule result. However, consolidation postings for these companies are still considered (in accordance with the group reports, the lists "Account balances and consolidation postings" (KONSAL) and "Transactions and consolidation postings" (KONBEW) as well as the sub-group data exchange).
The creation of company carry forwards to a new period during the year now provides postings with currency conversion rule 'MDK' with the currency conversion rule 'VKW' or 'VPW', respectively. These postings are no longer deleted at calculation of current depreciations providing a new calculation of depreciations only for the last month. Carry-forward postings and transaction converted by monthly average exchange rates are considered correspondingly at transfer to the next fact.
It is possible to consolidate companies whose shareholding residual value and shareholding percentages are zero. The associated shareholding transaction (GESGES) is now carried forward, although all values are zero, providing a correct shareholding calculation in the supsequent period. However, no carry forward record is created, if a shareholding transaction carried forward is eliminated by a disposal.
The carry forward of group financial statements reports a warning message if data for group companies definition already exist in the destination environment. The repetition of this message now can be suppressed for a contingent mass processing via an automate control.
The status determination of the group companies monitor checks ampongst others, whether a consolidation voucher number is already entered in the company financial statement data (intercompany balances, shareholding transactions) as an evidance for the processed consolidation function. The entry now is maintained at repeated transfer of the company financial statement data from the previous fact as far as these data are unchanged at all providing the preservation of the status [green] of the corresponding consolidation functions ('SK', 'AE', 'KK'). The message "After carry forward repetition of SK and AE consolidation is required" now is reported only if consolidation voucher numbers had been present in the former data and the new data do not exactly agree.
The currency conversion rule 'FDK' (sliding average currency rate) has to be assigned to all concerned accounts in the "Account currency conversion rules" (KTOUAW) for the conversion of (p&l) accounts with monthly weighted average exchange rates. A new currency conversion method 'MMW' (modified monthly weighted rate method) to be entered in the currency conversion headers has been introduced for the purpose to avoid a manual maintenance of the account currency conversion rules for all new p&l accounts. If selected by default the currency conversion rule 'SK' (closing rate) is applied to all balance sheet accounts and the currency conversion rule 'FDK' ist applied for all p&l accounts without explicit specification in the account currency conversion rules.
Exchange rate effects are now calculated and posted for intercompany fixed asset transactions although there is no account balances for adjustment. The total of all intercompany fixed asset transactions converted with the closing rate from local into group currency is used instead.
It is now checked for the consolidation of D&C (SK) and I&E (AE), whether all relevant intercompany balances are stamped with a consolidation voucher number as an evidance of their processing by the respective consolidation function just like already before the shareholding transactions with respect to the status of capital consolidation. If not all intercompany balances are stamped the respective status is set to [red].
Advice: It is strongly recommended to lock all closed periods, if the group financial statements are not locked yet, to avoid a status update by this check. The activation of object authorisation for periods for all users is prerequisited for this.
The status for locks of group financial statements are now represented by new icons (see above).
Associated vouchers for transaction development reposting are co-deleted and the status 'ZU' is set to [red] at deletion of the vouchers for consolidation D&C (SK) by opdate of the associated consolidation parameter or by deletion of a line of the IC clearing list (KGESGES).
The consolidation D&C and I&E with set flag for "Handling difference of transaction currency" as a non-cash difference in the respective consolidation parameter was modified to generate a posting for non-cash difference calculated from the differences of the values in transactions currency per company instead of a posting per transaction currency code. I.e. up to 4 postings for non-cash difference are created since the classification in debit and credit amounts per company was maintained. The classification into posting records per transaction currency code was dropped.
If intercompany balances without declaration of transaction currency are reported in this method, then group currency is simply used as transactions currency.
In addition the comparison of transaction currency differences with the transaction currency threshold value is no longer performed. Therefore it is checked at update of the consolidation parameter, that no threshold value may be entered with set flag for "Handling difference of transaction currency" as a non-cash difference.
The consolidation D&C and I&E with set flag for "Handling difference of transaction currency" as a non-cash difference performs a currency conversion of the transaction currency values into the group currency. The adjustments of the currency conversion headers of both companies are used for this purpose. However, if both companies have the group company as the local company there might be no currency conversion header at all. In this case up to now all conversions were performed with the closing rate ('SK'). Now the conversion of p&l data is performed applying the currency rate average per period ('PDK') since this is much more convenient.
The lines for "Difference amount" and "Minority interests" were combined to one line "Sum" in the form entry application for capital first consolidation (I-ERSTKON).
In addition, it is now supported that there exists more than one consolidation postings on the same account with the same posting key. These postings can be entered, are separately saved, are displayed again at repeated call and can be updated indiviually. However, for interpretation of the column "Residual value" several lines have to be reviewed together.
The consolidation function 'AO' is no longer admitted for entry of new vouchers. Alternatively you can use the consolidation functions 'MB' as well as 'M0' to 'M9'.
The status for locks of consolidation vouchers are now represented by new icons (see above).
The settings for the last modification (user, date, time) are no longer updated when setting or resetting the lock of a consolidation voucher, since the information of the last setting or resetting of a lock is stored independent from this in separate columns.
An additional consolidation posting representing the amount of the result effect is now generated automatically on the result account (with account flag 'E') for consolidation vouchers affecting net result. One posting is generated per posting record, per company and, in case, per business unit. Of course, this posting is not used for calculation of the debit/credit identity and the result effect. In addition it is not used for the calculation of check sums, too.
The list "Consolidation postings" (KONBUCH) does not consider these consolidation postings at calculation of totals. This also applies for the display of remaining differences in the single record application KONBUCHE. A manual maintenance of these postings is not supported (no branch into the single record application). The form entry for consolidation postings (I-KONBUCH) displays these postings on the result account, but they cannot be modified. Of course, the are not used for calculation of differences.
Ist das Ergebniskonto einem Kapitalspiegel zugeordnet, so werden die neuen Konsolidierungsbuchungen mit dem Buchungsschlüssel mit dem Verwendungskennzeichen 'JU' versehen. Ist das Konto einem anderen Spiegel zugeordnet, so wird der Buchungsschlüssel für Änderungen in der laufenden Periode (Verwendungskennzeichen 'L' oder 'N') verwendet.
The generation of these additional consolidation postings proceeds at each check of the consolidation vouchers, i.e. at display of the consolidation postings as well as at each modification. However, these consolidation postings are not generated for locked periods, locked group financial statements and locked consolidation vouchers.
The new consolidation postings replace the mere function of the application "Repostings group result" ('JU'). Therefore the consolidation postings on the result account are not generated, if a 'JU' voucher already exists. The "Repostings group result" is only required, if the accounts for charging balance sheet and prifit & loss are specified. However, the function for the account for result is no longer available.
Consolidation postings on the result account are ignored at import of consolidation postings (e.g. after export from another IDL Konsis installation) without reporting. However, after import these postings are newly generated. Correspondingly these consolidation postings can not be selected for calculation of minority interests or deferred taxes.
These consolidation postings on the result account are ignored in several other applications (carry forward to next period, currency conversion, copy group postings for sub-group report as well as all consolidation functions based on other consolidation postings), too, providing the same generated consolidation vouchers as before. These consolidation postings are rather newly generated by the subsequent consolidation voucher check.
The programs for report generation were not modified, since either the result account is not contained in the report at all or the consideration of these consolidation postings provides the desired report result. Another advantage of these consolidation postings on the result account is the ability of carry forward checks and other consistency checks with the aid of check rules.
Due to technical reasons the release migration of IDL Forecast data cannot be proceeded within the general release migration. Therefore the migration has to be invoked separately for IDL Forecast data. A new action menu item of the application "Planner spreadsheet" (PLAN) serves for this.
The opening of a scenario not migrated is prevented with a corresponding error message.
The values in total columns (quarters, years) now can be modified, too. Each modification is automatically splashed to the allocated months either commensurate to the existing values or equally distributed, if no values existed yet.
The modification of an account balance is now distributed commensurate (up to now equally) to the values already existing to the changes.
A cell is now designated by an icon (hand), if a manual modification is appended to the cell. This even applies, if the total of all manual modifications is zero. However, if the opening balance and a manual modification result in a total of zero, then the cell is designated with a green dot. This dot specifies, that at least one automatic modification exists in the T account, i.e. the T account is not empty.
All automatic modifications can now be transformed into manual modifications for selected lines. This may be particularly interesting, if the automatic modifications shall not be charged automatically. For this purpose you have to apply the icon with the robot hand after selection of the cells. Then all automatic modifications of the selected cells are transformed. The transformation is performed for all allocated accounts, if positions were selected. A description for the manual modification is requested in a dialogue. Afterwards the transformed automatic modifications are manual modifications with the new text.
A new action menu item "Delete postings" serves for the release of thte selected cells from manual postings. The similar action menu item "Delete account modification" deletes account modifications from the selected cells.
A new button in the title bar of the table area now controls, whether the rule icons are to be displayed in the table or not, since the table area becomes slightly confusing with many rules within a scenario.
A check for consistency of the net result of balance sheet and profit & loss is now performed for the entered plan values. Differences are displayed in a total block at the end of the table just like in the list "Account balances" (KTOSAL).
If an account is allocated to two positions via debit and credit restriction in the "position & account allocations" (POSKTO), the it is displayed twice in the planner spreadsheet. However, depending on the debit/credit flag its balance is displayed only in one of both cells. The other cell displays no value bout an icon indicating the debit/credit dependency.
The actualisation of the data by refresh from the account balances from IDL Konsis now can be performed differentiated. A new function, that can be called from the action menu as well as from the object menu, was created providing a refresh only of the selected regions. In addition there is an action "Refresh account balances" replacing all former refresh functions of the action menu. There you can enter the periods to be refreshed for the respective scenario instead af specifiying one of the regions (actual, forecast, plan).
The saving of the scenario was separated from the saving of the account balances. Therefore a new button <Save account balances> was supplemented in the selection area providing the saving of the account balances and the scenario. The old button <Save> stores only the scenario without writing account balances.
It is now supported to perform a planning on the level of controlling objects. Therefore the selection area exhibits a second tab "Controlling filter" after loading of a scenario. There you can specify single controlling objects for the defined controlling dimensions.
After having selected a value for each dimension and pressing the button <Use> the table is interchanged. You can now see only controlling balances for the selected objects. If you enter or modifiy values, then these modifications are displayed in a parallel T account in an additional panel.
You don't have to specify all controlling dimensions. If you select controlling objects only for a subset of controlling dimensions, then the total of all characteristics is displayed in the table.
IDL Konsis controlling balances are generated, updated or can be loaded just like account balances if planning is performed on the level of controlling objects.
The scenario manager now displays the creator of the scenario in addition.
It is now possible to close a scenario without closing the application "Planner spreadsheet" (PLAN).
The call of subsequent applications (e.g. Account balances, Company financial statements + monitor) is now restricted to the case, that the scenario may not contain any unsaved data. Otherwise the respective tab might be closed without return to the planner spreadsheet and the unsaved modifications were lost.
The descriptions of the buttons of the wizards for definition of rules were revised for better clarification of their functions:
The sort of the rule templates can now be specified ba the user. Options are sort by modification date (like up to now), sort by rule type, and alphabetical by rule name.
Rules receive the name of the rule template when applying them from a set of rule templates.
A progress bar is output at application of a set of rule templates since this step may take some time.
The sizes of the pages of the wizards were unified providing a fix location of the buttons on the screen.
The wizard for investment rules now allows liability accounts as well as asset accounts for the payment account.
The entry of a negative base value factor was obciated for the purchase, personnel, and provision rules and rules with base value, since it would be without a functional meaning.
Business cases now receive a unique number beside their descriptions. This number is displayed in the business case viewer behind each business case.
A dialogue "Delete this rule? Yes/no" was output upt to now at deletion of a rule. This dialogue was enhanced by "Delete values of this rule? Yes/No/Cancel". By answering <No> the values of the rule on the referenced accounts are transferred into automatic modifications. By answering <Yes> the rule is deleted like before. No action is performed when answering <Cancel>.
If rules are applied from a rule template, then you can control, that the rules are only to be applied to specific periods (only plan, only forecast) just like at definition of the rule in the respective rule wizard already up to now.
Rules are now uniquely identified by a serial number. Please mind, that different numbers are assigned if the rule is applied to several accounts or several periods.
You can now select, copy and insert the values of the T-account representation into other applications (e.g. MS Excel).
A new business case viewer provides the facility to represent the correlation of modifications and rules within one business case. For this purpose the account display now additionally displays the posting or the business case of each modification. If you push the mouse key on the business case name, then the complete business case is displayed in the business case viewer. For identification a unique number is displayed for each posting and each business case. All modifications belonging to a business case are displayed grouped.
The detail area of the business case viewer is divided into three tabs: "Overview", "Postings", and "Table". The tab "Overview" displays general informations. The tab "Postings" displays all postings directly correlated with the business case. The tab "Table" displays all important numbers of the rule in a table format.
The account number is now displayed in addition to the account description in the rule viewer and in the business case viewer.
The report type 'Q' (multi-period cash flow report) is now treated like report type 'F' (common cash flow report) at maintenance of the report line descriptions. Thus separate report line descriptions can be defined for multi-period reports without reference to a common cash flow report.
The value flag '-' (negation of value formation with respect to POSKTO) had been introduced for cash flow reports to be able to calculate differences (e.g. balance - carry forward = change in actual period). This value flag is now supported in all report types and can be specified in the report line descriptions. The accounts of a position are are added as usual but displayed with the opposite sign. This sign inversion is effective for the aggregation to the superordinate positions.
An attribute for the controlling dimension was supplemented in the table of report headers providing a differentiated control of controlling reports.
Attributes for a controlling object and a business unit were supplemented in the table of report headers providing the support of reports for aggregations of controlling objects and business units.
The status for locks of reports are now represented by new icons (see above).
Controlling reports on company and group level can now be created for all defined controlling dimensions (CDM). A parameter for the controlling dimension was supplemented in the report header for control. There you can enter a value between 'CD01' and 'CD10' for controlling reports. Then all accounts detailed by this controlling dimension (declaration in the account master data KTO) are subdivided into the corresponding controlling objects at report generation. All other controlling dimensions are no longer concerned.
Without entry of a controlling dimension each account is subdivided into the controlling objects of the first controlling dimension allocated to this account. In case these might be different controlling dimensions.
A simultaneous subdivision into mare than one controlling dimension is not supported. The controlling balances origin report is still supported only with respect to the first controlling dimension.
Hierarchies (aggregation levels) can be definied for controlling objects ans business units already since release 2008.0. These heriarchies can now be evaluated in reports containing controlling objects or business units, respectively. Therefore the superior node (aggregation object) and a level have to be specified in the report header (REP):
A representation of the complete hierarchy in the report is not yet possible due to technical reasons.
The new report option 'F' provides that the contribution of consolidation postings is broken down into the contributions per consolidation function in group development reports. The consolidation functions are listed in alphabetical order on the same level as the contribution of the company financial statements (key 'G'). The report option 'F' may not be specified for other reports. This concerns the group fixed asset development report, too, where the respective detail level is occupied by the key fixed asset object.
The subdivision by consolidation functions is performed due to the consolidation function entry in the respective consolidation voucher headers. however, it is scheduled for one of the next releases to support an individual classification for report purposes.
The branch into the "IC net book value" of intercompany balances is now supported for accounts with account flag 'J', too.
A new standard column option with the key "HB1/2" was provided for the display of transfer reports with columns for the original company statement, postings, the resulting company statement, consolidation postings, and group statement.
Account balances with differences in the results of balance sheet and profit & loss are generated by the function "Consolidation subgroup for creating indiv. financial statements", if business units are used and inter segmentary postings exist. This problem can be solved by specification of the account group 'M' in the "Company + business-unit allocations" (GESUBR). Then these differences are cleared using the clearing account with account flag 'U'. Therefore newly created GESUBR allocations for the destination company are supplied with the account group 'M' by this function.
In addition a check was supplemented in this application, whether the processed consolidation vouchers are balanced in debit and credit. A message window listing all unbalanced vouchers is output if this is not the case for at least one voucher. Then the user can decide, whether the processing is to be continued or cancelled. In this case a company financial statement with different results of balance sheet and profit & loss would result, too.
The new parameter '%UI' can be specified in menu items (MEN) with external calls. This parameter is replaced by the current user id (maximum 8 digits), that is used in IDL Konsis e.g. as entry of the user of the last modification, when performing this call.
This enhancement especially concerns individual menu items used in automate controls as well as the menu items "UNL..." callable via action "Select external data" from the calling application "Data import and display" (IMPORT). E.g. the invoked process can use this parameter for determination of a job id for subsequent writing into the import tables (I1xx).
A warning message "You are about to read data for all companies" is output at call of the subsequent application for unloading of account balances (KTOSAL), intercompany balances (UNLICKTOSAL, UNLICKONV), and controlling balances (UNLCNTSAL) if both entry fields, "Company" and "Variable of financial year", are empty.
An entry field for the "Transaction development" id was supplemented in the maps of the calling applications "Data import and display" (IMPORT) and "IE job controls" (IEJOB). A value entered here is transferred to the called application expecially at call of unloading development transactions from a remote system or the list of development transactions.
The SAP interface (kcusap.jar) was extended by the evaluation of this parameter providing the ability to unload data for different transaction developments controlled by this parameter.
A new import application supports the import of import/exports definitions e.g. exported from a test database. You find the required format descriptions in the lists "Fields for import/export formats" (IEFDEF) and "Allocations import/export fields to formats" (IEFFEL). The now import application can be called from the common calling application "Data import and display" (IMPORT) als well as the specific application IARIMP (for authorised users only).
The descriptions of the key fields were renamed from "Object id" and "Origin object id" to "Internal object id" and "external object id". The terms "Origin" and "Destination" were missleading, if the transformation group was used for export, too.
Two attributes were supplemented in the table IEJOB for control of imports and exports via special database table avoiding TXT files:
Two additional columns of the list display the database table of the data to be imported and the number of records in this table.
Furthermore the list parses the data records saved for the displayed jobs for uniqueness of the keys relevant for the respective object type. Unique keys are displayed in corresponding columns (period, fact, company, chart of accounts, chart of positions) of the list IEJOB an thus facilitate the orientation which data are contained in which job.
In addition a list "Overview import-table data" was supplemented to view the contents of the records of a job to be imported. This application is invoked by selecting a line of the list IEJOB and pick from the action or object (right mouse key) menu or ba double muse click on the column with the number of records. You can branch from this new list to the "Import protocol" display.
Advice if working with transformation groups: The database tables contain the original data (with external object ids) and are displayed by the list "Overview import-table data" with these values. You can determine the IDL Konsis keys only via transformation group allocations (UMSOBJ).
A security request "Are you sure ..." is now output when starting the function "Delete + re-load sub-group data". This security request names the data of the found protocol file from data unload. Thus it can be assured that no outdated data are loaded.
In addition the name of the database, that was used for unloading the data, is written into the protocol file of the unload and the load function to reduce the risk of loading wrong data. The security request at start of "Delete + re-load sub-group data" displays this database name, too.
The processing is no longer aborted at once but rather proceeds up to the end of the data of the respective table and then reports the collected messages, if foreign key violations had occurred. These message now explicitely specify the missing foreign key. Thus it is easier to identify systematically missing data and errors can be repaired more rapidly.
The name of the database, that was used for unloading the data, is written into the protocol file of the unload and the load function to reduce the risk of loading wrong data.
The validity of a group account is inherited by all allocated company accounts, if the group account is limited in its validity.
The database access of the KONDAT programs cannot distinguish zero values and empty contents of numeric fields. Therefore IDL Forecast data written by KONDAT were not compatible, since this distinction is essential for IDL Forecast data. The transferred and loaded scenarios could not be opened any more. Since a short-term elimination of this problem was not possible, for now these functions had to be eliminated from the menu of the calling application "Group subgroup data exchange" (KONDAT).
The call of the function "Export sub-group balances + details" was reenabled in the calling application "Group subgroup data exchange" (KONDAT). The export format was not modified. Rather the unloaded data are reduced to this length, i.e. the transaction development key is truncated after one digit and the posting key number after two digits. Users that apply this interface should avoid corresponding enlargements of their transaction development definitions.
The functionality of the read function of the group financial statement for intercompany account balances was enhanced. Now you can select the intercompany data of the unconsolidated group financial statements, the consolidation postings or the consolidated group financial statements, respectively, for the specified group, sub-group or report-technical sub-group.
SAP Interface with IDL Importer
The parameter "Transaction development" supported in the calling application "Data import and display" (IMPORT) can now be used by the SAP interface to unload data for special transactin developments.
A set of views on the database was defined for supporting the display of data with the tool Power OLAP from PARIS Technologies providing a preparation of data without any preparation function to be explicitely invoked. You need additional licences for this function.
With this release the following English-speaking documentations in the "doku" directory are updated or completed: