This release IDL.KONSIS.FORECAST 2009.0 is a main maintenance and therefore must not be left out in the release sequence. Prerequisites for this release are the last main maintenance 2008.0 from September 3rd 2008.
The supplements of the interim maintenance IDL.KONSIS.FORECAST 2008.1 as well as the corrections to these maintenances up to the release date are included in this main maintenance 2009.0.
This documentation describes the enhancements since the previous interim maintenance IDL.KONSIS.FORECAST 2008.1. If the last interim maintenance hasn't been installed yet you are recommended to catch up on the enhancements of the interim maintenance 2008.1.
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 has to be performed as the first step after installation of a new release. Caused by the substantial transpositions within this release (see chapter 4.1) this is strongly required with 2009.0. The migration may take some time depending on the size of the database.
User working with historical conversion of fixed assets (currency conversion rule 'FDA' or conversion method 'MZB') up to now have to define a kindred control via posting key conversion rules (BSLUAW). You find detailed advices for this subject in chapters 2.1 and 10.1.
Because of the transposition of the functions for capital consolidation and minority interests the release 2009.0 should not be installed during the group financial statement. The carry forward into the actual period may be performed with release 2009.0, even if the previous period was closed with former releases. However, all subsequent consolidation functions for the new group financial statement should be performed exclusively with release 2009.0.
Because of the substantial transpositions in the database the data exchange formats of release 2009.0 and older releases are not compatible with each other. It is required, that the unloaded database as well as the loading database is on level 2009.0. This concerns the group-wide data exchange as well as the sub-group data exchange.
The current version 11g of the database Oracle is supported with this release 2009.0.
Additional functions of the MS Excel connection IDLCONNECTOR of IDL.KONSIS.FORECAST 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.
New Tables and Applications for Transaction Development Definitions
With this release there are separate database tables for the definition of transaction developments, development columns and development areas and correlated applications (overview, single record and import for each with the short words SPI (transaction developments), SSP (development columns), and SBE (development areas). The previous standard developments (fixed assets, participations, capital, provisions) as well as the previous individual transaction developments are defined here. Instead of the previous applications ISP (description indiv. development transactions), ISS (column descript. indiv. development transactions), and ISB (descriptions development areas) disappear.
An essential difference to the hitherto solution is the ability to supply these master data with specific attributes. For transaction developments (SPI) these are:
The key of a development column (SSP) is composed of the key of the transaction development and the column number (like up to now at most 50). There are the following attributes for development columns:
The key of a development area (SBE) is composed of the key of the transaction development and the one digit area key. There are the following attributes for development areas:
This three new tables are filled with the data of the transaction developments already defined (individual as well as standard transaction developments) supplemented with some allocations hardly coded up to now by the release migration program. Within this process the attributes of the allocated posting keys are evaluated, too, producing a complete specification of the developments previous consistent definitions provided.
All three new tables were supplemented in the group-wide data exchange. I.e. the transaction development definitions should be maintained exclusively in the central instance.
Modifications of Existing Master Data Tables
Posting keys (BSL): The attributes "Development column" and "Development area" now refer to the new tables described above (SSP or SBE respectively). According to the definitions of the transaction developments the allocated posting keys have to follow certain rules due to the used usage flags.
The previous posting key flag 1 (for distinction of posting keys on the levels of company and group financial statements, for fixed assets even separate posting keys for intercompany additions and disposals) was disabled and suppressed for the previous standard developments ('A', 'K', 'R'). It never was supported for the previous individual transaction developments. Thus there exist a lot of redundant posting keys (e.g. 'A01', 'A41', 'A80', and 'A91' in the fixed asset development), where only one of them is required yet. Posting keys no longer required can be made invalid by setting a valid-until period.
The previous entry of a reference group posting key in the posting key master data has become extensively dispensable, since functions like the transaction development repostings (e.g. 'SU') now can use the same posting keys on group level as found in the company financial statements. Thus this attribute is removed by the release migration program. However, reference posting keys for participations are excluded from this step, since they refer to another development (generally the fixed asset development). If you intend to disable one of the former posting keys for group level, please check whether it is still used as a reference posting key for participations. In this case update the reference posting key to another posting key still valid.
Accounts (KTO): The attribute "Account flag 2" was replaced by the new attribute "Transaction development" with reference to the new table (SPI), which represents the same issue with the following exceptions:
The simultaneous selection for two "Account flags 2" supported by several list applications had been primarily invented for the simultaneous selection for 'K' and 'L'. The second entry field (now for transaction development instead of account flag 2) has been removed, since 'L' has dropped.
The remaining "Account flag 1" now is designated only as "Account flag".
The supplements of the account master data are considered in the change log, too. The list "Changes of accounts" (KTOLOG) was enhanced accordingly.
Check rules/positions: The "account flag 2" is replaced by a new attribute "Transaction development" with reference to the new table (SPI), too. The account flag 2 = 'L' is replaced by the transaction development 'K'. Thus check rules exclusively referring exclusively to accounts with account flag 2 = 'L' are no longer supported. As an alternative check rules with explicit allocation of accounts or positions can be defined.
Report idents (RID) and Column options (SPO): These tables were supplemented by an attribute "Transaction development" with reference to the new table "Transaction developments" (SPI). The release migration program sets this attribute to the transaction development, which had been specified by the report type up to now. Instead of the report types 'A', 'K', and 'R' as well as 'S1' to 'S9' are replaced by the new report type 'D' (development). A transaction development may only be entered with report type 'D'.
Report line descriptions (REPZEI): Development columns entered for cash flow reports are transposed into a new attribute with reference to the new table (SSP). There is nearly no reorientation for the user.
Report results (REPERG): The table for report results was supplemented by an attribute "Transaction development", too, which is set instead of the former account flag 2 for newly generated reports. However, a conversion of existing data is not performed by the release migration program with respect to the possibly very large data volume. Instead of the list application in case still displays the account flag 2.
Complete Individualisation of Posting Keys
Up to now there was a distinction between data, which IDL had cared for and had delivered with each release with the meta data, and data, which had to be provided by the user (supplements to the standard transaction developments as well as all individual transaction developments). From now on the user is responsible for all transaction development definitions. This covers
These data are no longer refreshed automatically by the meta data of the IDL.KONSIS.FORECAST releases. As an alternative templates for transaction development definitions are provided in the directory "LieferBatch" like already practised in the past for individual supplements to the standard transaction developments or the introduction of individual transaction developments. The user decides, whether he inherits these templates or creates his specific definitions.
As another consequence the posting keys as well as the new tables for transaction development definitions (SPI, SSP, SBE) now are completely transferred with the group-wide data at data exchange between different sub-group installations.
The user now is able to convert the previous standard transaction developments to an own taxonomy for the posting keys. For this purpose you have to define new posting keys parallelly to the existing posting keys, where the new posting keys yield a valid-from period (e.g. "01.2010") while the old posting keys yield a previously located valid-until period (e.g. "12.2009"). Then the transfer to the new carry forward posting key proceeds with the carry forward into the next year. Only valid posting keys are offered in the selection lists of the applications for entry of corresponding data.
Posting keys can be deleted only, if they are not used at all. In addition, it is not recommended to provide existing posting keys with a new meaning, since the posting keys are still used with their old meaning in existing data. However, you can now define new numeric posting keys with three digits. Thus old posting keys (two digits) can easily be distinguished from new posting keys (three digits). Please mind that the posting keys themselves are not numeric, i.e. the posting keys '01' and '001' are different e.g.
The IDL.KONSIS.FORECAST application programs had to be modified with the intention, that no posting key may be assigned explicitly. Posting keys of automatically generated transactions and postings rather have to be uniquely determined on another way. This is generally achieved by the allocation of usage flags to special posting keys, which have to be set carefully at the individual maintenance of the posting keys.
Since more posting key usage flags are required now the length of the usage flag was enlarged up to three digits. Besides the usage flags 'D', 'E', 'F', 'K', 'L', 'M', 'N', 'Q', 'SD', 'SE', 'SF', 'SK', 'SL', SM', 'SQ', 'SV', 'U', 'V', and 'X' already existing the following new usage flags are introduced:
Further automatically used posting keys are determined from other attributes of the development definitions, e.g. the development column usage flag 'UMB' for repostings.
If no special posting key can be determined for some cases, then generally a posting key for changes in current period is used. For automatically generated developments this is the posting key with usage flag 'L', for other developments a posting key with usage flag 'N'. If no such posting key is defined it remains empty and has to be supplemented manually.
In general posting keys with usage flags are reserved an may not be used in manually entered transactions and postings. Posting keys with the usage flags 'AHK', 'Bnn', 'KM', and 'N' are excepted from this rule.
A distinction of the selected posting keys for direction of the transaction (debit or credit) is generally supported just like the setting of the result is performed with different posting keys in case of profit ('K05') or loss ('K16'). For this control it is required, that you define two posting keys with the same usage flag, but different debit/credit flags. This control is especially required, if both posting keys are allocated to different development columns.
Advice for Currency Conversion with Time Correlated Exchange Rates
The currency conversion rule 'FDA' (time correlated method for fixed assets) is no longer supported explicitly. Up to now this conversion rule was automatically applied to all fixed asset accounts with currency conversion method 'MZB' (modified temporal principle method) set in the currency conversion header (WUM). Alternatively a direct allocation to an account via account currency conversion rules (KTOUAW) was possible. With currency conversion rule the following extra handlings were performed:
The specially treated development columns no longer can be identified inhibiting a processing in this way. Alternatively you can achieve the same result by corresponding entries in the posting key currency conversion rules (BSLUAW):
You can continue to enter the currency conversion rule 'FDA' in the account currency conversion rules (KTOUAW) and is set as a default conversion rule for fixed assets at currency conversion method 'MZB' (modified temporal principle method), however, there is no difference to the currency conversions rule 'FDK' (sliding average exchange rate).
Enlargement of Development Keys and Individualisation of Development Definitions
Just like posting keys the transaction development themselves, the development areas and the development columns can be completely defined user specific. The processing is exclusively controlled by the attributes of the new tables for development definitions (SPI, SSP, SBE). Please mind, that the keys of the development areas for fixed asset and participation developments have be identical, if an adjustment between both data stocks is desired at currency conversion.
The key of transaction developments now may consist of up to three digits. This is utilised by the release migration program for the former individual transaction developments, whose development key (or account flag 2 or report type, resp.) was displayed as 'S1', 'S2' etc. on the user interface, but was stored as '1', '2' etc. in the database. This especially had to be considered for import formats. Now 'S1', 'S2' etc. is written into the database, too. This conversion is performed by the release migration program.
The enlargement of the transaction development key not only concerns the development definitions themselves but also all applications, where development keys may be entered, besides others at posting keys (BSL), accounts (KTO), report idents (RID), report column options (SPO), report line descriptions (REPZEI), check rule positions (PEFPOS), account currency conversion rules (KTOUAW), transactions and consolidation postings (KONBEW), and development transactions (SPIBEW).
An almost unlimited number of transaction developments now can be defined by the enlargement of the development key. This affects the control of the keeping of development transactions per fact (FAC) and period (ABR), the status display of the company financial statement monitor (EA), the differentiated carry forward of single developments into the next period (PERGES) or fact (GESABV), respectively, as well as the checkpoint IDs of the processing control (VERARB).
The keys of the checkpoint IDs of transaction developments in the processing control no longer can be determined fix. They rather are composed of a fix prefix ("SPI-" for the development in total, "VOR-" for the values carried forward) and the development key. The release migration program converts the previous checkpoint IDs (e.g. "ANLBEW", "SPIBEW9", "KAPBEWVOR") as well as their usage in the processing control records into the new names (e.g. "SPI-A", "SPI-S9", "VOR-K"). The checkpoint IDs of other data stocks (e.g. "KTOSAL" remain unchanged.
The company financial statements monitor (EA) now displays an arbitrary number of status columns for transaction developments. The column headers are set to the column descriptions of the development definitions (SPI). The selection box for selection for the status of specific data stocks was adjusted accordingly.
The calling applications "Create closing of period new fact" (GESABV) and "Create Co. carry-forward > new period" (PERGES) display one line for each development like before, on the one hand for status display, on the other hand for triggering an isolated carry forward of this development as a line action. The lines for the transaction developments are dynamically determined from the developments defined in the application SPI. The checkpoint ID is used as a substitution of the menu id displayed in other lines. Transaction developments without carry forward are suppressed in PERGES.
A new database table controls, which transaction developments are kept in which period or on which fact, respectively. It can be displayed and maintained by the applications "Period / development" (ABRSPI) or Fact /development (FACSPI), respectively. A flag is defined per combination period/development or fact/development, respectively, which may be set to 'X' (with this development) or to '0' (partly with this development) for periods or to 'A' (generation of account balances from this development) for facts, respectively. The previous flag position '-' (without this development) needs no longer to be entered, since no record is required in this case.
This table is initialised by the release migration program due to the former settings in the period (ABR) and fact (FAC) master data for the transaction developments. The user is responsible for further maintenance. Generally the list applications display the table contents in matrix display, i.e. one line per period or fact and one column per development. Alternatively a simple list may be selected.
The list applications "Periods" (ABR) and "Facts" (FAC) continue to display the flags for keeping of transaction developments from the new table (ABRSPI or FACSPI, resp.). In addition these data are always copied at copying of periods or flags. However, a double mouse click into the columns for the development flags provides the call of the new applications.
Within the data exchange (KONDAT) between distinct sub-group installations the new table (K074) is part of the group-wide data. Therefore the allocations should be maintained only in the central installation.
A deviating calculation of check sums is caused by the modified database format of posting keys and the transposition of the keys for individual transaction developments. Therefore check sums now are internally provided with a version number intending not to modify existing check sums. Then the recalculation of old check sums is performed due to the old data structures, if the restrictions up to now (two digit posting key) are followed. New check sums always are calculated due to the current data structures.
The definition of transformation groups for posting keys has been arranged more clearly by providing two separate entry fields for the development and the posting key number. Therefore the object type has to be uniquely entered in the list application "Transformation group allocations" (UMSOBJ) before calling the single record application.
It is no longer possible to define commonly valid standard report column options (SPO) for development reports, since development columns now are maintained individually, too. Therefore the previous standard column options for development reports (e.g. '#ANLG', '#KAPK') including their columns descriptions (SPA) and formulae lines (FED) as well as their usage as default column option in the report headers (REP) are converted into individual column options by the release migration program by replacing the leading '#' by '$'. From now on these column options have to be maintained by the user, too.
Updating the Former Standard Transaction Development by Batch Files
User, who do not want to maintain the former standard transaction developments (fixed assets, capital, provisions) by themselves, have the possibility of updating the according definitions by IDL. For this purpose IDL provides sample solutions in the directory LieferBatch on the release CD with each release. The import files for posting keys, development definitions and report column options (beginning with '$') contained there may be imported at demand.
This step should be processed with each release, since the import files are based on each other. Thus e.g. with this release 2009.0 all posting keys becoming redundant by the disappearance of the posting key flag 1 are provided with a valid-until period (12.2009). The batch files of following releases will not contain these posting keys any more enabling new users to work with a reduced number of posting keys.
A description of the modifications caused by the batch files is contained in each LieferBatch sub-directory.
Capital consolidation and calculation of minority interests on the company's capital now are processed in joint applications. The essential advantages are
New Consolidation Functions
This enhancement requires a new taxonomy of consolidation functions. From now on all consolidation functions for minority interests start with 'F' (previously 'KA', 'KV'):
The list applications "Consolidation vouchers" (KONBEL) and "Consolidation postings" (KONBUCH) now contain two entry fields for consolidation functions providing the ability of simultaneously selecting vouchers or postings of different consolidation functions. Up to now this could only be achieved by entries like 'K%'. The entry fields for the voucher number were divided into three fields for the 1st company, the 2nd company and the consolidation function in this context just like already in the single record application "Consolidation voucher" (KONBELE).
Capital Consolidation and Minority Interests
The calculation and posting of direct minority interests on the company's capital now is proceeded within the capital consolidation. This applies to the automatic capital consolidation as well as the manual capital consolidation.
The capital consolidation of a company with minority interests generates a 'KK' voucher as well as a 'FK' voucher. If more than one modification of the participation relations happens within an accounting period, then the second modification generates a 'K0' and an 'F0' voucher, the next an 'K1' and an 'F1' voucher etc.
A new feature of the capital consolidation is the processing of participation disposals (partial disposals), if the child company doesn't dispose from the group companies. I.e. the function "Deconsolidation" ('KS' vouchers) now only processes disposals from the group companies, which are designated by a disposal date in the allocation of the company to a sub-group (KTKGESE). The 'KS' status of the "Group companies + monitor" (KTKGES) has been modified in this way, too. The new minority interest vouchers are correspondingly considered by the deconsolidation.
As mentioned above the automatic capital consolidation determines and posts the direct minority interests on the company's capital. With several participation modifications like successive acquisition the development of minority interests is represented by different vouchers. In total all capital accounts of the child company are cleared.
The manual capital consolidation including direct minority interests occurs in a new form entry application "Forms first consolidation KK,FK,EK,KU", which can be called for a child company from the application "Group companies + monitor" (KTKGES) in the sub-menu "Capital consolidation".
The entry form contains one block per participation modification in the regarded accounting period. Each block contains (at least) one line for the participation modification as well as one line per capital account and posting key corresponding to account balances or capital transactions of the company financial statement. Additional lines allow the entry of postings for accounts or posting keys, which were not comprised in the company financial statement. The following value columns are displayed:
The net result is only considered for the group participations, since here only the result of the time space before addition to the group companies is to be eliminated, while the result during the affiliation to the group is entitled to the group. However, the minority interests on the result are not only to be considered for participation modifications but rather in every period and thus are processed in the function "Update minority interests" (see below).
While the horizontal calculation determines the residual value per capital account the vertical calculation determines the difference amount or the minority interest, respectively, by the total of the elimination postings. All debit values are displayed with a positive sign, all credit values are displayed with a negative sign, and all values have to be entered in this way, so that these calculations can be easily followed.
At the end of data entry the button <Save> has to be pushed for saving of the displayed or entered data.
When working with business units there is a separate entry block for each combination of business units of parent and child company. Then the values are stored in postings for posting record numbers '01', '11', '21' etc. like before.
The elimination of postings from subordinate sub-groups is performed within the automatic and manual capital consolidation, if deviant participation relations exist there (e.g. minority interest in the sub-group becomes a group interest in the world group). Like before these postings are written into posting record number '10'.
This application is to be used for the first consolidation of companies consolidated at equity, too. However, no minority interests are posted there. The amounts and posting keys for the capital accounts have to be entered complete manually, since no usable company financial statement exists.
Update Minority Interests
The function for calculation and posting of minority interests now is named "Update minority interests". It mainly contains the functions of the former application "Minority interests (KA)" with exception of the elimination of the company's capital in case of participation modifications, amongst others
Opposite to the capital consolidation this function has to be invoked in each period even if the participation relations remain unchanged. The function generates postings for direct and indirect minority interests in different vouchers (one or two, respectively, company numbers in the voucher number). It has been supplemented, that all indirect minority interests (including on the net result) are distributed to several parent companies.
Formatting of Report Columns
You now are able to define the formatting of report columns. The characteristics of font style (bold, italics), font size, font and background colour as well as a separator line between the column 8i.e. in front of each value column) can be individually determined.
Furthermore you can define bar graphs in a report column. The graph shows a bar representing the respective amount in green (with positive values) or red (with negative values) colour per line. The additional entry "Value display" controls, whether a value is to be output beside the bar or not. This value can be output as a complete amount, rounded whole numbers or rounded for 1,000 or 1,000,000 currency units. A minimum column width in mm can be specified for the print output, if the standard width is too narrow.
The definition of these attributes proceeds in the application "Report column descriptions". The single record application "Report column description" (SPAE) was supplemented by corresponding entry fields. The font colour and the background colour are selected with a special colour dialogue.
The import format of the column descriptions were supplemented by corresponding attributes. Font and background colour have to be specified as numeric RGB values in this context. This concerns the export format, too.
Report columns delivered by IDL as metadata with each release (column options starting with '#') generally do not use these formatting. For supplying such column options with formatting specifications at first you have to copy the delivered column options (SPO) including the referenced column descriptions (SPA) and formulae lines (FED) to an individual column option (not beginning with '#'). Then you can assign formatting features to the column descriptions of the individual column options.
Column options with columns for representation of relative deviations (#ALTD, #BUCD, #KOND, #KTKD, #NEUD, and #SUMD) are excepted from this rule. A new column option with suffix 'G' (e.g. #ALTDG) is defined for each, where the relative difference calculated in the original column option in percent is replaced by a bar graph.
Advice: Simultaneous formatting of report lines (supported since release 2008.1) and report columns both formatting are combined in the cell if possible. However, the column formatting is preferred in case of conflicting formatting.
Formatting of the Print Output
The texts of the header lines of printed reports now can be flexibly configured by specification of one or more of the following parameters in the description of the report ID or the report version:
The corresponding key is printed instead of this parameter, if only this parameter is specified. However, you can print the description of the object, too, by appending a formatting suffix (e.g. '{GES!L}') to this parameter. You can use
The accounting period (ABR) can be configured by specification of a formatting, e.g. '{ABR!yyyy-MM-uu}'. If no formatting is entered the output is performed according the language specific conventions. The formatting description uses the following syntax:
The following attributes controlling the print output were supplemented in the report header, if no diverging parameters are specified in the print dialogue. These attributes are displayed in the list applications (REP, REPK) and can be entered in the single record applications (REPE).
The foot lines contain the check sums, if the selection area is not printed.
A new feature allows the release of consolidation vouchers and thus a lock of the contained consolidation postings against further modifications due to the four-eyes principle. I.e. the user locking a voucher may not be the modifier of its contained consolidation postings at the same time.
The "Lock consolidation voucher" is performed by a new action callable in the list "Consolidation vouchers" (KONBEL) or the single record application "Consolidation voucher" (KONBEL). A release status in the voucher header is set by this action and the respective user as well as current date and time are written into the database. This information is displayed in KONBEL as well as in KONBELE. In addition the list KONBEL facilitates a selection for release status.
Another new action "Unlock consolidation voucher" revokes the release of the consolidation voucher. The status of the voucher is set to "unlocked". The status "Locked" is presumed for this action.
All applications inserting, modifying or deleting consolidation vouchers and postings check this release status. Locked vouchers even may not be deleted, if they contain any postings. Excepted from this rule are the sub-group data exchange (KONDAT), the currency conversion of consolidation postings into parallel currency, and the exchange of currency data (WKZEXCH).
Both of the new actions require the usual menu authorisation. The user groups IDLADMIN and IDLKON or IDLWINAD or IDLWIN, respectively, yield this authorisation by standard.
This new functionality is interlinked with the Change log of consolidation postings providing the traceability of all modifications after revoking the release of a consolidation voucher. Without activation of this change log the new functions are not activated and the additional attributes are not displayed. For users without activated change log for consolidation postings nothing changes, especially if the required licence for change logs is missing.
The change log for consolidation postings is activated in the list application "Control of master data logging" (LOG) just like other change logs, even if consolidation postings are no master data. The change log can be viewed with the new list application "Changes of consolidation postings" (KONBUCHLOG). This list provides selections for the essential attributes of consolidation postings as well as special requests for state of the data at a defined timestamp or changes within a defined time space.
Another modification in this context is, that the complete lock of an accounting period (action "Lock accounting period" in the list application "Periods" (ABR)) is only allowed, if all consolidation vouchers of this period are released presumed the voucher release is applied, which can be determined by the activated change log of table K049 (consolidation postings).
At creation of group reports a message is output, if they simultaneously contain consolidation postings of released and not released vouchers.
There are a lot of enhancements of the planning application IDL.FORECAST, which are described in detail in chapter IDL FORECAST.
The splash screen output before the login dialogue appears now contains the text IDL.KONSIS.FORECAST instead of IDL.KONSIS.FORECAST, since this login serves for the start of several IDL applications.
The login dialogue now contains a drop-down box for selection of the database. It contains the names of all databases, which the user was able to login successfully from the time of the installation of this release on. Like before the database most recently logged in is preselected. Thus nothing changes for users working with only one database.
The positions of the menu tree and the quickstart (visible or in the border bar) are stored in the ini file when finishing IDL.KONSIS.FORECAST. Thus the display of these elements is performed exactly in this assembly. Up to now at restart these elements were always in the border.
Some configurations of the user interface had to be configured by a slide control. However, the effects of this slide control were hardly comprehended. Thus the slice control now was replaced by an own page "Graphic" in the options dialogue. There you now can separately switch the features on or off. If all features are switched off, the former classic GUI remains.
You now can define the background colours of the periods for different value types in the entry form of IDL.FORECAST (actual, planned, forecast) on the page "Colours" of the options dialogue.
In addition the page "Graphic" of the option dialogue contains another check box "Tabs". The selection of this checkbox requires the selection of the check box "Panels relocatable".
If the check box "Tabs" is selected, then tabs appear at the bottom border of the window: One with the short word of the current application and one with a symbol for a new tab. A mouse click on this symbol moves the second tab (at the beginning without started application) into the foreground. Here you can start a new application by entering a short word or by selection from the menu tree or from the quickstart. Simultaneously a new tab appears at the bottom with the symbol for a new tab.
If applications have started in several tabs you can switch between them. In many cases the starting of a second IDL.KONSIS.FORECAST session is no longer required.
Pleas regard the following constraint: A switch between two tabs is not possible, while a processing has been started in the active tab, which has not yet been finished. Thus this technique cannot be used to work in one application while a long term process (e.g. generation of a group report) is still running in another tab.
When copying data with the aid of a single record application (entry with template) up to now always all associated descriptions and help texts in all languages were copied. However, you can see only the descriptions of the selected language in the map and are demanded to adjust them, while descriptions in other languages as well as help texts are not visible and easily overlooked to adjust.
Therefore at copying of data with single record applications now it is checked, whether there exist descriptions in other languages or help texts to be copied. In this case the user is asked with a warning message, whether these data are to be copied or not. At <OK> these data are copied as before. However, at <Cancel> only the data visible in the map are stored while descriptions in other languages and help texts are not copied.
The conversion program for this release performs the following conversions:
In addition all conversions of the interim maintenance 2008.1 are proceeded, if this interim maintenance had not been installed.
Caused by the substantial transpositions within this release the migration may take some time depending on the size of the database.
The following menu items are new with this release. If completely entered customer specific authorisation groups are used, authorisations (BENMEN) for these menu items have to be provided. As a rule the authorisations of the user groups IDLKON or IDLWIN may serve as a sample.
Please regard, that delete authorisation for the menu items PRFERG or PRFERGK, respectively, is required in addition for deletion of check rule results (see below).
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 deactivated and have no longer any meaning. Please delete all individual authorisations for these menu items, in order that these menu items can be deleted when installing the subsequent release 2009.1 or 2010.0, respectively. For each group only one menu item with 'xxx' = 'SPI' is remaining.
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 list application "Startup data+authorization" (VORADMIN) now enables you via object or action menu to branch into a subsequent list for object authorisations (BENOBJ) or period authorisations (BENABR), respectively. The object authorisation group of the user is preselected in the corresponding maps.
The logging of changes of master data (feature at the customer's expense) now is available for table K049 (consolidation postings). This change log is required and closely connected the release of consolidation vouchers due to the four-eyes principle (see above).
For the purpose of activation of the modification logging you enter the table name K049 in the application "Control of Master Data Logging" (LOG) and select the action <Activate Master Data Logging>. The current state of the entered database table is copied into the log table by this action. Please mind that no other users are connected with the database when activating a master data logging. From then on all changes of this table are recorded in the log table.
A new list applications "Consolidation postings modifications" (KONBUCHLOG) provides for display and analysis of the logged data. This list application displays the log records, allows selections for the important attributes (like the original consolidation postings list) and, in addition, questions for the kind (insert, modification, delete) and timestamp of the change. All changes after a certain timestamp can be selected as well as the state of the original table at a certain timestamp.
The list application "Menu items" (MEN) now enables you via object or action menu to branch into the subsequent list for menu authorisations (BENMEN). The respective menu item is preselected there.
The master data table for positions was supplemented by a column for a XBRL concept (key for an entry in an XBRL document). This entry is evaluated by the XBRL export. The new attribute is displayed in the list application (POS) and can be entered in the single record application (POSE).
The account flag 2 of the account master data was replaced by the new attribute "Transaction development" with reference to the table SPI (see above). Just like the reference table this attribute consists of three digits. Exceptions:
The simultaneous selection for two "account flags 2" has been dropped for the account master data and other list applications, since it mainly served for the simultaneous selection for 'K' and 'L'. Now only selections for one development are allowed.
The previous "Account flag 1" was renamed into only "Account flag".
The enhancement by the new attributes "Transaction development" and "Reposting at carry forward" were considered in the change log and the list "Account modifications" (KTOLOG).
An account with account flag 'X' now can be allocated to the account for retained earnings (account flag 'W') of the company chart of accounts as allocated group account.
The new account flag 'F' can be used to designate the account "Net result participation of minority interests". It allows diverging position allocations for the report (see below).
A new application (short word Z-POSKTO) was developed for the maintenance of the position account allocations applying a drag & drop technique. This application is a template for further allocation application planned in the next time.
For maintenance of the position account allocations the selection parameters chart of positions and chart of account have to be uniquely specified. A limitation for position or account numbers is not provided. The restriction to single b/s p&l codes is supported. A restriction for accounts and positions valid in a specified period is planned but not yet supported. The optional entry field "Language" forces the display of position and account descriptions in the specified language.
After pushing the button <Display> two tables are displayed in the lower part of the window. The left-hand table contains a complete list of all positions of the specified chart of positions. If accounts are already allocated, they are displayed in a tree structure as branches of the positions. The right-hand table contains a list of all accounts not yet allocated to the chart of positions. Thus this applications provides an easy control of a complete allocation of the accounts.
To define new allocations you select one or more accounts of the right-hand table, pick up these accounts with the left mouse button, drag it with pressed mouse button to the desired position in the left-hand table, and drop it there by releasing the mouse key. The permissibility of this allocation due to b/s p&l codes is checked. If the allocation is not permitted, the account(s) cannot be dropped on a position. This is visualised by a stopping restriction symbol instead of the mouse pointer when moving the mouse.
For deletion of an allocation you select the account in the left-hand tree table. Via object menu (right mouse key) you can select the action "Delete". Then the allocation is removed from the left-hand tree table and the account is supplemented in the right-hand table of unallocated accounts.
Multiple allocations of an account are allowed, if the additional positions are there-of positions. Then an account can be picked up in the left-hand table and dragged and dropped onto another position. The line is copied within this. However, if the account is picked from a substantial position and dropped on another substantial position, then it is not copied but rather moved.
Multiple allocation are possible with respect to a debit/credit control, too. For this purpose you can enter a debit/credit flag for an account (allocated without debit credit flag) by selecting 'Debit' or 'Credit' in the drop-down box of the respective cell. In doing so all additional allocations to there-of positions automatically yield the same restriction to this debit/credit flag. In addition, the account is re-supplemented in the right-hand table, however limited to the opposite debit/credit flag. Thus a simple control for complete allocation for the debit/credit control is provided, too. However, a mixture of allocations with and without debit/credit flag is not supported.
Multiple allocations of one account with respect to the differentiation by controlling flags used for cost of sales accounting are not yet supported. This will be supplemented in another release.
Just like in the form entry applications the performed modifications are not stored in the database at once but rather explicit push of the button <Save> or the respective action from the action menu. If you quit the application or modify the keys without saving entered data, then a control request occurs, whether the previously entered data are to be stored at first.
In general the allocation is only permitted for accounts and positions with related b/s p&l codes, e.g. '1' (assets) can be combined with '2' (liabilities) but not with '3' (income). One exception is made for the net result account (account flag = 'E'), which is a liability account and may be allocated to an income position. A further similar exception now has been supplemented for the account "net result participation of minority interests, which is designated by the new account flag 'F'.
The facility to modify the aggregation flag of controlling objects was supplemented in the action "Mass update" of the list "Controlling objects" (CNT).
The action "Mass copy" was supplemented in the list "Hierarchy of controlling objects" (CNTCNT) for easy copying of a defined hierarchy from one chart of controlling objects to another.
There are now special database tables for the definition of transaction developments (SPI), development columns (SSP), and development areas (SBE) as well as related new applications for list, single record and import. The new tables are described above in detail. Especially the following circumstances are modified:
The new tables are initialised by the release migration program with respect to the previous program logic as well as the posting key and development definitions. The previous applications for development definitions and enhancements (ISP, ISS, ISB) are dispensed.
Posting keys now can consist of more digits: up to three digits for the development and up three further digits for the posting key number. Existing posting keys are transposed to the new format without modifications regarding their content by the release migration program.
The attributes development column (now with reference to the new table SSP), development are (now with reference to the new table SBE) and usage flag received enlarged formats, too. This is adjusted by the release migration program, too.
Posting keys just like other transaction development definitions now have to be completely maintained by the user. No meta data are delivered by IDL with each release. Therefore the application programs must no longer contain any firm posting keys. Thus more posting keys than before are supplied with usage flags and there are several now usage flags (see above).
The posting key flag 1 (used for distinction between posting keys on the level of company financial statements and posting keys for group consolidation) has been disposed. I.e. now all posting keys may be used for the company as well as for the group financial statement. Thus the reference (group) posting key is required only for participation posting keys, which refer to another development.
The number of available posting keys can be reduced by setting the valid-until period for posting keys no longer required. In addition, by definition of new three digit posting keys a development can be converted to a new nomenclature.
The list application "Posting keys" (BSL) now in addition displays a column with the reservation flag. This flag serves for the check, which posting keys may be used in a manually entered posting or transaction or are offered in selection boxes. The reservation flag cannot be set explicitly but rather is set automatically for certain usage tags. This applied up to now, too. However, you can understand some behaviours more easily, if you can see, whether the reservation flag is set.
The master data table for groups/sub-groups was supplemented by a column for a URL (internet address of the homepage). This entry is evaluated by the XBRL export. The new attribute is displayed in the list (KTK) and can be entered in the single record application (KTKE) in the form of "http://www....".
The master data table for companies was supplemented by a column for a URL (internet address of the homepage). This entry is evaluated by the XBRL export. The new attribute is displayed in the list (GES) and can be entered in the single record application (GESE) in the form of "http://www....".
The list application "Periods" (ABR) was supplemented by the action "Mass copy". It allows to copy selected lines (periods) from year to another. E.g. you can create data for all 12 months of a new accounting year in one step. All flag positions (e.g. for detail data) are copied from the corresponding month of the source period. The number of the year is replaced in all descriptions, too. Periods already existing are not overwritten.
Since the number of transaction developments is now arbitrary (see above), the flags for keeping these developments per period are no longer maintained in the period master data (ABRE). Rather a new application "Period / developments" (ABRSPI) has been invented for this purpose.
If the change log for consolidation postings and thus the four-eyes principle for the release of consolidation vouchers is activated (see above), then a period may only be locked (action "Lock period"), if all consolidation vouchers of this period are released.
Since the number of transaction developments is now arbitrary (see above), the flags for keeping these developments per fact are no longer maintained in the fact master data (FACE). Rather a new application "Fact / developments" (FACSPI) has been invented for this purpose.
The list for (multilingual) descriptions and help texts of master data (TXT) was supplemented by a selection for "from modification date". With sort option 'T' (with help texts) this selection is applied to the last modification of the help text, otherwise to the last modification of the descriptions.
A new sort option 'E' allows sorting of the selected data by external key (just like description with 'B', short text with 'K', or column header with 'C').
A double mouse click on the column with the type of the help text opens the help text editor for this help text. This applies for the display of a second language, too.
The export of this list was adjusted to the format of the new import application for descriptions. Exception: With sort option 'T' the export is performed with the import/export format of help texts.
You can now enter a help text for a company financial statement via action "Edit help text" and display it via action "Display help text" directly in the application "Company financial statements monitor" (EA). A previous lock of the company financial statement is no longer required. However, the help text may only be inserted or modified with extra authorisation, if the company financial statement is locked. The existence of the help text is indicated in the column with head text 'H'. Up to now these help texts had to be maintained via the application "Company processing controls" (VERARB).
The number of status columns for transaction development now is arbitrary corresponding to the number of developments defined (with the new application SPI, see above) and activated (with the new applications ABRSPI und FACSPI). The column headers for the developments are set to the column header text of the development definition (SPI).
The selection for status of specified data stocks has been designed variably, too. The keys of the transaction developments may be entered alternatively to the firm short words of the other data stocks.
The values of statistical quantities (B/S p&l code = '5') generally cannot be classified into debit and credit. Thus they are generally stored without debit/credit flag. As a consequence these data may receive negative values. Up to now the entry of a negative value was transformed to a positive value with an arbitrary debit/credit flag. This modification applies for imported data or data entered with a forms application, too.
At entry or modification of account balances on mere intercompany accounts (accounts with firmly allocated intercompany) now it is checked, whether the intercompany is valid in the actual period. Otherwise an error message is output.
The facility for suppressing protocol outputs was supplemented in the functions for generation of account balances from controlling balances as well as the generation of controlling balances from intercompany balances. Thus these functions can be started as mass processing in the company financial statement monitor (EA) or in an execution automat without the need to commit each processed company.
The list applications "Fixed assets transactions" (ANLBEW), "Participations/shareholdings" (GESGES), "Capital transactions" (KAPBEW), "Provision transactions" (RUEBEW), and "Development transactions" (SPIBEW) allow a selection of companies by group companies since release 2008.0. Now in this case the amounts of quota consolidated companies are displayed as pro-rata values just like already done for balances and postings.
When entering a new voucher in the single record application "Voucher" (BEL) the voucher data is no longer initialised with the first day of the month of the actual period but rather with the last day of this month.
The list application "Vouchers" (BEL) now allows a branch into the form entry for postings (I-BUCH). This action can be selected as a line action for a specific voucher as well as a global action for all vouchers of a company financial statement.
The entry '*' is permitted in the first entry field of the posting key (transaction development) of the list application "Postings" (BUCH). Then all postings without entry of a posting key are selected.
Depreciations are automatically recalculated and posted, if the elementary postings are modified. However, if depreciation parameters of the fixed asset master data are modified, the depreciations already posted remain unchanged. The elementary postings had to be modified and reset to initiate a recalculation of the depreciations.
This laborious procedure now is simplified by supplement of the action "Automatic generation of depreciations" in the list "Postings" (BUCH) providing a recalculation of depreciations. For this action you have to select a line with the modified fixed asset object. If only lines without fixed asset accounts or fixed asset objects are selected nothing happens. This can be used to recalculate depreciations after modification of several fixed asset objects by marking all postings of a voucher before starting this action.
The processing control records for transaction developments con no longer be assigned with a fixed checkpoint ID, since their number is arbitrary (see above). The checkpoint ID now is composed of a fixed prefix ("SPI-" for the development in general, "VOR-" for the carry forward check sums) and the key of the development.
Form data entry applications now even can be invoked if there is only display authorisation for the selected keys (period, fact, company). However, columns assigned to non-authorised keys are disabled for data entry. This especially concerns the multi-period data entry, if the selected some of the periods are locked and some are changeable.
Just like for account balances the form data entry for intercompany account balances is now available for several periods in one form. The selection area therefore was supplemented by entry fields for column option, previous period, period distance and comparison fact.
The column option 'K' (default value when calling the application directly) provides the entry view just like before. In addition a previous period and/or a comparison fact may be entered. Then a column with comparison values is displayed beneath the entry column. Existing data are displayed in this comparison column but may not be modified. This facility provides a preallocation of the entry lines with intercompanies, which had been addressed in the comparison environment.
With column option 'P' previous period and period distance have to be specified. Then just like in the form data entry for account balances (I-KTOSAL) you have an entry column per specified period. Each intercompany is comprehended to one line in this layout. If there exists more than one data record for an intercompany, then their total is displayed, but this value may not be modified.
If in addition a comparison fact is entered with column option 'P' (possibly the same fact as in the previous entry field), then both features are combined. The first column for the previous period becomes a display column for comparison data without entry feasibility. E.g. this can be used to enter plan data for four quarters of a new year compared to the actual data of the previous year.
A warning message is output after saving entered postings, if they cause a voucher with debit/credit differences.
A new application was invented for the form data entry of intercompany inventories. It can be called from the branch "Forms data entry" of the menu tree or by entering the short word I-ICBEW.
The key values for company, business unit, period, and fact have to be entered uniquely. Only facts on the level of the group chart of accounts are admitted. Additional restrictions for intercompany, IC business unit, account (only accounts for IC-stocks, account flag = 'V'), and product group/no. are optionally possible.
The entry of a previous period is optional. However, with entry of a previous period the determined values from the previous period are output as totals per product group/no. or account, since the transactions cannot be uniquely allocated.
The entry of a sort option controls, whether the displayed data are grouped by product group/no. ('P') or by account ('K'). Total lines are output correspondingly. The sort option is preselected with 'P'.
All IC-stocks transactions already entered are displayed. These data may be modified but not deleted. In addition, there is an empty line per product for the entry of new data as well as a sub-total line containing the total of all existing and entered IC-stocks transactions.
You have direct entry cells for intercompany, IC business unit, amount in local currency, and overhead/direct values in percent or as absolute amount. A selection box (selection button or <F4>) supports the entry of intercompany and IC business unit. Just like the form data entry for account balances there is no entry feasibility for the debit/credit flag. It rather is determined from the b/s p&l code of the account. Deviating debit/credit flags are achieved by entering negative values.
An additional dialogue opened by double mouse click in the column "Additional data" allows the entry of a comment, amounts in group and parallel currency, an elimination account and, in case, controlling objects.
The action menu provides branches into the subsequent applications "Company financial statements monitor" (EA), "Inventories IC-stocks" (ICBEW), "Products/product groups" (PRO, also at double mouse click in the column "Product group/product"), "Forms account balances" (I-KTOSAL, also at double mouse click in the column "Account flag"), and "Forms IC-account balances" (I-ICKTOSAL).
This application can be started as a subsequent application of the form data entry of account balances (I-KTOSAL), too.
The new check rule operators "L EXIST" and "L NOT EXIST" define new kinds of check rules. They check whether a balance for an account (specified on the left-hand side) exists or does not exist. The balance even may be equal to zero. If more than one account is specified in the check rule positions then at least one of these accounts has to exhibit a balance or none of these accounts may exhibit a balance, respectively.
Like in the account master data (see above) the previous "Account flag 2" is replaced by the attribute "Transaction development" with reference to the new table SPI. Thus check rules with respect to the disposed account flag 'L' are no longer supported and replaced by transaction development 'K' by the release migration program. If only accounts with the former account flag 'L' are to be checked by a check rule, the accounts have to be specified explicitly in the check rule positions.
The message KON2053W ("Check rule not processed, because chart of positions without accounts") is written into the check rule result, if one side of a check rule is allocated to a position, but no account of the chart of account relevant for the respective fact is allocated to any position of the specified chart of positions. Like for the message "Check rule not processed, because of account outside chart of accounts" the check rule status of the company financial monitor (EA) becomes [green]. Up to now the check rule calculation aborted with an error.
The list applications for check rule results of the company or group financial statements (PRFERG/PRFERGK), respectively, were supplemented by a delete function. The function "Delete check rule results" always deletes all results of the company or group financial statement, respectively, as if check rule results never were calculated. However, the allocated processing record (VERARB/KVERARB) is not deleted but rather is supplied with the message KON1894W ("Check rule results not up to date - data have changed"), which provides the status [yellow] in the company or group monitor (EA/KTKGES).
The calling application "Create Co.carry-forward > new period" (PERGES) continues to display one line per transaction development for the purposes of status display and invocation of a discrete carry forward of this development as a line action. However, the lines for the developments are dynamically determined from the developments defined in the application SPI (see above). Instead of the menu id the respective checkpoint ID ("SPI-" + development key, see above) are output. Developments without carry forward due to its definition in SPI are suppressed.
The period flag of the origin period is evaluated now for the carry forward of report headers with specification of a previous period. Thus a previous period representing an annual accounting period remains unchanged, if the actual period of the origin data doesn't represent an annual accounting period, or is increased by 3, if the actual period is carried forward from an annual account period to a quarterly or monthly statement. Accordingly previous periods representing a quarterly statement remain unchanged, if the actual period represents a monthly statement, or is increased by 3, if the actual period is carried forward from an annual accounting period or a quarterly statement to a monthly statement. Up to now the previous period was always increased by the difference between destination and origin period. Now only all other cases apply to this rule.
The function of checking the period carry forward of a company financial statement was enhanced by the facility to suppress the immediate output of protocol messages. Thus this function can be started as mass processing in the company financial statement monitor (EA) or in an execution automat without the need to commit each processed company. The collected protocols are output at the end of the processing of all companies.
The calling application "Create Closing of period new fact" (GESABV) continues to display one line per transaction development for the purposes of status display and invocation of a discrete transition of this development as a line action. However, the lines for the developments are dynamically determined from the developments defined in the application SPI (see above). Instead of the menu id the respective checkpoint ID ("SPI-" + development key, see above) are output.
The aggregation tag of the fact master data (FAC) now affects controlling balances, too. Controlling balances are only aggregated to an aggregation controlling object, if the aggregation tag is set.
The splitting of account balances into several business units generally processed with controlling balances now is performed even if the flag for keeping of controlling balances is not set for the origin fact. Then controlling balances are not considered and the transition is performed only due to business units specified and the account and chart of accounts master data.
The "Company + business-unit allocations" (GESUBR) are evaluated for the splitting into business units:
The function of checking the company financial statement's closing to the next fact was enhanced by the facility to suppress the immediate output of protocol messages. Thus this function can be started as mass processing in the company financial statement monitor (EA) or in an execution automat without the need to commit each processed company. The collected protocols are output at the end of the processing of all companies.
The consolidation postings of the new minority interest vouchers with consolidation functions 'FF', 'FK', 'F0', 'F1' etc. (see above) are carried forward just like the previous 'KA' postings into consolidation vouchers with consolidation function 'FV' (previously 'KV'). The relevant parameters are extracted from the new consolidation parameter 'FK' (previously 'KA').
The period flag of the previous period is evaluated at carry forward of group report headers with specification of a previous period just like at carry forward of company financial statements (see above).
The list application "Deferred taxes headers" (LTK) now displays the country code per company from the company master data (GES). Thus it is easier to determine, which tax rate has to be specified for which company.
The new currency conversion rule 'VPK' (previous period rate) provides the conversion of a development transaction by the average exchange rate of the previous period of the account balance. This average exchange rate is calculated per intercompany for transactions on intercompany accounts. The currency conversion rule 'VPK' can be assigned to development transactions and postings on development accounts via "Posting key conversion rules" (BSLUAW) but not to the total account (KTOUAW).
The direct allocation of 'VPK' to a transaction or posting is possible; however, (just like 'SK' and 'PDK') it is superposed by controls via BSLUAW or KTOUAW, so that it rather serves as an audit trail for the performed conversion but not as presetting.
The currency conversion rule 'VPK' replaces the control, which was performed via (account) currency conversion rule 'FDA' (time correlated average rate for fixed assets), which was the standard for fixed asset accounts at currency conversion method 'MZB'). It now can be flexibly applied to arbitrary posting keys and to other developments, too. Furthermore in addition to transactions it is effective for postings, too.
The second extra function of the currency conversion rule 'FDA', the conversion of the actual depreciations with the same currency conversion rule as the actual depreciations, is dropped, too. This control has to be replaced by respective entries in the posting key conversion rules (BSLUAW), too. Thus there is no more difference between the currency conversion rules 'FDA' and 'FDK' (sliding average currency rate).
The list application "Account currency conversion audit trail" (KTOUMR) now displays currency conversion differences even if the group or parallel currency is not unique. This is designated be the currency code '%' in the column headers.
This list was rearranged more clearly by grouping of column headers of group and parallel currency amounts.
If the total of the currency conversion differences per account and the total difference (balance sheet or profit & loss) of the currency conversion header exhibited a difference, then this rounding difference is output in an additional line providing consistent totals.
The list application "Account currency conversion rules" (KTOUAW) previously displayed two columns for each, group and parallel currency: one with the currency conversion rule and one with a colour signalising, whether the currency conversion rule is according to the standard due to the currency conversion method. These columns now were comprehended, so that the column with the currency conversion rule is coloured by itself.
Furthermore this list was rearranged more clearly by grouping of column headers of group and parallel currency amounts.
The parameter "Reporting date of exchange rate" is now a mandatory entry in the list application "Exchange rates" (WKZWKA). It is preselected with the last day of the month of the actual period of the startup data (VOR) when calling the list directly via short word entry or selection from the menu tree. This applies to a subsequent call from applications independent from periods (e.g. "Currency codes (WKZ)), too.
If the application is called from the list "Currency conversion GCurr + PCurr" (WUM) the previous period is preselected as a parameter, too. Then the list displays the exchange rates of the previous period, too, which are also used at currency conversion.
The status of the check rule result calculation displayed in "Group companies + monitor" (KTKGES) now is automatically set to [yellow] (warning), if consolidation postings are modified subsequently, provided that the status was [green] before. The corresponding group processing control record (KVERARB, checkpoint 'PRFERG') is supplied with the message KON1894W ("Check rule results not up to date - data have changed").
The status of "Repostings group result" ('JU') displayed in "Group companies + monitor" (KTKGES) now is automatically set to [yellow] (warning), if consolidation postings are modified subsequently, provided that the status was [green] before. The corresponding group processing control record (KVERARB, checkpoint 'KTKERGV') is supplied with the message KON2123W ("Voucher of net income/net loss has been changed").
The modification of consolidation postings is determined from the change of the check sum of a consolidation voucher. Thus the keeping of check sums is required for this automatic operation.
If you have defined additional individual consolidation functions for manual postings ('M0', 'M1', etc.), then you now can define a consolidation parameter for each. I.e. you can define different accounts for retained earnings or different controls for aggregation of carry forward postings. Without definition of a special consolidation parameter the entries of the consolidation parameter 'MB' are applied.
If the consolidation function 'MB' is entered in the list application "Consolidation parameters" (KTKPAR), then the consolidation parameters for the individual manual consolidation functions are displayed, too, provided they are defined.
Accounts and other parameters for calculation and posting of minority interests now are kept in a consolidation parameter 'FK' (see above). It replaces the previous consolidation parameter 'KA'.
The accounts (and controlling objects) for elimination of the net result and consolidation postings affecting the net result now can be differentiated into direct and indirect minority interests in the consolidation parameter 'FK'. In addition the entry of a posting key was supplemented for all accounts of this consolidation parameter (except for the accounts for deconsolidation and retained earnings).
The selection boxes for the accounts of the minority interest consolidation parameter 'FK' are now controlled to offer only accounts, which generally are functional reasonable. However, the checks for entries were not modified. I.e. diverging entries are still allowed, if they were previously permitted.
The account "Retained earnings clearing" of the consolidation parameter 'KK' now is an optional entry, since it is not required for IFRS accounting.
The account for "Clearing badwill" of the consolidation parameter 'KK' now can be supplied with a posting key, if it is allocated to a transaction development. Then this posting key is automatically set for postings on this account.
A profit & loss account may be entered for the account for "Clearing badwill" of the consolidation parameter 'KK' providing a compensation of badwills affecting the net result in posting record number '03'. Up to now posting record number '08' (other compensations) had to be used for this kind of compensation.
Due to the modified function of deconsolidation (see below) the status 'KS' is now only set to [red], if the company disposes from the group companies. However, if the participation on a child company is reduced but the company remains in the group companies, then the 'KS' status is not affected. Rather the status 'KK' for capital consolidation is set to [red] in this case.
The status 'FF' (update minority interests) now is set to [red] for pro-rata consolidated companies with indirect minority interests.
The capital consolidation functions now process not only the equity ratios but in addition the direct minority interests on the capital (see above). Furthermore these functions process reductions of the equity ratios, too, as far as the child company does not dispose form the group companies.
The capital consolidation does no longer consider the previous period entered in the calling application "Group companies + monitor" (KTKGES), but rather determines the previous annual accounting period from the period flags of the period master data (ABR). The previous logic sometimes caused a wrong determination of the pro-rata net result, if the previous interim accounting period was entered.
If capital consolidation vouchers are carried forward from an interim accounting period, they remain unchanged. Only participation changes which have not yet been processed in a previous interim period are newly consolidated (and in case deleted before). If further vouchers are to be created newly, they have to be manually deleted before.
The specification of participation percent values in posting remarks now is performed with 8 instead of 2 decimal digits.
The difference between elimination of participations and equity capital on the difference compensation account is now posted only if it is not zero.
The calculation and posting of minority interests was newly designed and structured (see above). Especially the posting of the direct minority interests on the company's capital is performed within capital consolidation, while the posting of other minority interests is processed by the new function "Update minority interests".
The calculation of minority interests does no longer consider the previous period entered in the calling application "Group companies + monitor" (KTKGES), but rather determines the previous annual accounting period from the period flags of the period master data (ABR).
An extension of the consolidation parameters now provides the ability to differentiate between direct and indirect minority interests on the net result and on consolidation postings affecting net result.
The consolidation parameter 'FK' was supplemented by the optional accounts for "Minority interests on currency conversion difference" and "Minority interests on currency conversion difference indirect". If you enter an account there it is used instead of the general minority interests account in the consolidation postings for exchange rate effects.
The calculation of indirect minority interests provides the posting of the minority interest on the difference amount from capital consolidation. Now the pro-rata compensation of the difference amount from capital consolidation is posted, too. In addition the 'FF' status is no longer set to [yellow] but rather immediately to [green]. Thus in general there is no more action required for compensation of the minority interest on the difference amount.
The calculation of indirect minority interests is now supported for quotally consolidated companies, too.
The specification of participation percent values in posting remarks now is performed with 8 instead of 2 decimal digits.
The depreciation type of fixed asset objects newly generated for the difference compensation now is proposed with depreciation type 'K' (no automatic depreciation). The previous presetting (depreciation type = 'L', period of depreciation = 10 years) was arbitrary, too, and more laborious to modify.
The capitalisation of a goodwill in local currency at a selectable company is now supported independent from the accounting type of the fact (up to now only with accounting type 'I' = IFRS). However, opposite to IFRS a scheduled depreciation of the goodwill is possible in local currency.
The posting remark for the generated consolidation postings now can be entered in a length of up to 70 characters.
The function "Deconsolidation" now processed only disposals from the group companies (entry of a disposal date in "Group/Sub-group consolidated Co." (KTKGESE). However, participation reductions are now processed like participation increases within the capital first consolidation including the increase of the minority interests.
The deconsolidation of quota consolidated companies now considers the indirect minority interests on them, too.
The elimination of fixed assets results is no longer possible for companies with consolidation type 'K' (not consolidated) or 'E' (consolidated at equity).
Some consolidation functions only serve for repostings of transaction developments and do not affect the balance sheet or profit & loss at all. Thus for the purpose of runtime optimisation these vouchers are not considered at generation of b/s and p&l reports. In the past this caused some problems, if users appended manual postings to these reposting vouchers affecting balance sheet or profit & loss, which were not processed. In order to avoid such problems now these reposting vouchers are checked, if the totals per company, business unit, and account equal zero. If this is not the case a corresponding message number is written into the voucher header.
For the purpose of clear arrangement the consolidation vouchers for reposting of the debt and profit & loss consolidation ('SU', 'AU') used one posting record number per transaction development ('01' = fixed assets, ..., '04' = individual transaction development 'S1', ...; '12' = individual transaction development 'S9'). This arrangement cannot be retained since the number of transaction developments has become arbitrary. Thus from now on only one posting record number per transaction development type (due to development definition SPI) will be used: '01' = fixed assets, '02' = capital, '03' = provisions, '04' = other developments.
The execution automat for all consolidation functions of a sub-group was completed by supplement of the following consolidation functions:
The list application "Consolidation vouchers" (KONBEL) and "Consolidation postings" (KONBUCH) now contain two entry fields for consolidation functions in order to simultaneously display vouchers of different functions.
The selection field for the voucher number was divided into three entry fields for 1st company, 2nd company, and consolidation function in these list applications just like it was arranged in the single record application "Consolidation voucher" (KONBELE) before. Vouchers with only one company in the voucher number can be selected by entering '*' into the field for the 2nd company.
The deletion of consolidation vouchers carried forward with the single record application "Consolidation voucher" (KONBELE) now is only permitted with extra authorisation just like the deletion of automatically generated consolidation postings in KONBUCHE. This extra authorisation is not granted to any standard user group.
The list application "Consolidation vouchers" (KONBEL) now supports a branch into the forms data entry for consolidation postings (I-KONBUCH). This action can be selected as a line action for a specific voucher as well as a global action for all vouchers of a company financial statement.
Further new actions of the list "Consolidation vouchers" (KONBEL) as well as the single record application "Consolidation voucher" (KONBELE) allow the release or revoking the release, respectively, of a consolidation voucher according to the four-eyes principle (see above). The release status as well as the corresponding user and timestamp of the last action are displayed after calling this action. The activation of the change log for consolidation postings is required for these actions and displays.
Diverse outdated consolidation functions (e.g. 'EE', 'KE', 'KM') no longer can be used for the entry of new consolidation vouchers and postings. However, existing vouchers still are displayed.
The entry '*' in the first entry field for the posting key (transaction development) in the list "Consolidation postings" (KONBUCH) provides the selection of all consolidation postings without entry of a posting key.
The consolidation postings of a voucher are no longer checked for equal debit and credit totals in parallel currency, if the currency conversion flag of the actual fact (FAC) is not set to 'P' (conversion into parallel currency). Up to now this check sometimes caused error message at the creation of reports.
Depreciations are automatically recalculated and posted, if the elementary consolidation postings are modified. However, if depreciation parameters of the fixed asset master data are modified, the depreciations already posted remain unchanged. The elementary consolidation postings had to be modified and reset to initiate a recalculation of the depreciations.
This laborious procedure now is simplified by supplement of the action "Automatic generation of depreciations" in the list "Consolidation Postings" (KONBUCH) providing a recalculation of depreciations. For this action you have to select a line with the modified fixed asset object. If only lines without fixed asset accounts or fixed asset objects are selected nothing happens. This can be used to recalculate depreciations after modification of several fixed asset objects by marking all postings of a consolidation voucher before starting this action.
The list applications "Account balances and consolidation postings" (KONSAL) and "Transactions and consolidation postings" (KONBEW) now display consolidation postings for non-consolidated companies (consolidation method 'K'), too, since these consolidation postings are processed in group reports. However, consolidation postings of subordinate sub-groups with voucher posting type 'ET' (single use posting only in sub-group) are no longer displayed, since these postings are not considered by group reports.
The list "Transactions and consolidation postings" (KONBEW) now allows a selection for development area especially interesting for the fixed asset development.
A selected scenario now is stored in the start-up data (VOR) of the user and is preselected at the next call of the application "Planner spreadsheet" (PLAN).
The action menu as well as several context menus of the application PLAN were enhanced and arranged more clearly by separation lines and sub-menus.
Beside the direct entry in the cells and the definition of rules the facility of directly entry of a single posting has been supplemented. It is restricted to a single period and the amount is fixed, i.e. neither changeable by the user in the 'T' account or the rule viewer nor does it participate in the automatic splashing. For this purpose the menu item 'Posting' was supplemented in the object menu of a cell. The selection of this menu item opens a window, where you can select the debit and the credit account. The debit account is preselected with the account of the selected cell. Furthermore you can enter the posting amount. You can add additional accounts on both sides, if the posting affects more than two accounts. In addition a name for the posting can be determined, which is displayed in the 'T' account. A "Ready" button is activated if all accounts, all amounts, and the posting name are defined and the totals of both sides agree.
The context menu (right mouse button) of a cell now contains an entry specifying, whether a cell is locked or not. If a cell is locked, no entries in this cell are allowed and it is never modified automatically, too. The position account splashing treats this line as if it were not existent. Rules causing a modification of this cell are automatically locked, too, providing all cells attached to these rules to be locked, too. The locking of a position automatically locks as subordinate accounts.
An "Undo" button enables the user to revoke all changes applied to the planning spreadsheet including modifications of values, rules, and rule templates. This can be performed for up to 100 steps. Modifications revoked accidently too much can be repeated by pushing the "Redo" button. However, after <Saving> the modifications in the database these changes can no longer be revoked.
You can now arbitrarily specify the background colours for the columns for actual, planned, and forecast values in the <Options> dialogue.
You can now select several periods and copy the values of these periods automatically to other periods. For this purpose the destination periods are allocated to the source periods (e.g. actual data) in pairs. Optionally the values of the source periods can be multiplied by a factor before writing the results into the destination periods. A wizard guides you through these steps. Only account balances but no position balances are copied, since position balances are calculated from the account balances.
Final balances of actual data can be transferred (carried forward) into the plan and forecast area by actions of the action menu, sub-menu "Refresh account balances". However, there is no automatic adjustment.
Account balances from the application KTOSAL can be reloaded separately for the areas for actual, forecast, and plan data.
The plan application is based on the administration of scenarios. A scenario is the comprehension of all parameters for a planning schedule. These consist of the basic parameters for the used facts and periods, opening and closing balances, as well as rules and changes on accounts within one period.
In order to present a view over all currently existing scenarios they are displayed in a list with their names and short descriptions.
A new scenario can be defined using the object (right mouse key) or action menu item "new scenario" or the icon "new scenario". Then a wizard guiding you through the steps for creation of a new scenario opens.
You can activate a scenario by double mouse click, object (right mouse key) or action menu "Load scenario", or pressing of <Enter>. An activated scenario is designated with an arrow.
You can delete a scenario by the <Delete> key, the object (right mosue key) or action menu item "Delete actual scenario", or the icon "delete".
The display of rules was revised. All rules affecting a selected account are displayed clearly in a tree structure. With this you can reduce the display to exactly one rule or components of this rule.
The guided dialogues ("wizards") for the creation of rules were unified and enhanced. Now the dialogue consists of two pages.
The sales rule was supplemented in the following:
A new rule type was invented for personnel investment. The according guided dialogue (wizard) lets you enter the allocated accounts. This wizard can be started by a new symbol in the title bar of the rule area or via action menu.
A new rule type was invented for provisions. The according guided dialogue (wizard) lets you enter the allocated accounts for provisions and expenses. This wizard can be started by a new symbol in the title bar of the rule area or via action menu.
A new rule type was invented for investments. The acquisition may be specified in terms of fixed assets to cash or fixed assets to liabilities. Durations of depreciations, interest rates, and repayment may be specified as well as the allocated accounts. These specifications provide corresponding postings in the subsequent periods.
You can now define rules, which affect values in subsequent periods. This especially applies to general rules. E.g. you can define the payback of a receivable with respect to the receivable in the previous period.
If you specify a rule being an assignment rule, this rule always calculates the left-hand side value from the values defined on the right-hand side. The value on the left-hand side may not be manually modified.
A new rule list was defined for the display of all rules, which affects one cell. The new rule viewer contains a window divided into two parts: The left-hand part displays an ordered short list of all rules applying to the selected cell using one line for each rule. Here you can select one or more rules, for which detailed information shall be displayed in the right-hand part.
All defined rules can now be stored as a template for other scenarios. Thus rule templates are independent from scenarios, companies, or business objects.
The saving of a rule template proceeds within the respective rule wizard when editing the rule. It is allowed to save incompletely defined rules as a template, which has to be completed when being applied to another scenario. E.g. the rules might differ only in special accounts or factors (e.g. county specific tax rate). Rules already applied in a scenario may be saved as a template, too.
On the other hand a scenario can apply saved rule templates, i.e. turn them to rules (action "Apply template"), if the template is completely specified. However, if some specifications are missing these entries can be supplemented after loading the template into a rule wizard by the action "Open in wizard".
Rule templates can be comprehended to template sets. This serves for a more clear arrangement as well as for the application of all templates of a template set to the scenario in one step. The template manger display template sets and templates in a tree structure.
Rule templates may be deletes if the user is authorised to do it.
Account balances and modifications on this account can be displayed in form of an 'T' account or as a simple list.
The texts for the account modifications have been revised.
If a modification resulted from the application of a rule, then the value can be modified directly in the account representation. The concerned rules are automatically calculated.
It is now possible to display selected values in a bar chart. You first have to select a number of cells (horizontal, vertical, arbitrary) with the mouse and then select the action "Bar chart" from the action menu. Then the selected values are displayed as a bar chart in an extra area of the application window. Depending on the type of selection the bars are designated with short texts of positions, accounts, or periods. This area may be arranged or dragged into the border just like all other areas of the application window.
Bar charts may be used for the entry of plan values by dragging the height of the columns with the mouse.
The attribute "Report type" of the master data for report idents (RID) is uniquely set to the new value 'D' (transaction development) for all development reports by the release migration program. The information about the development is relocated to the new attribute "Transaction development" with reference to the new table SPI (see above).
The attribute "Development column" of the report line descriptions (REPZEI) was replaced by a new attribute with the same name with reference to the new table SSP (see above).
The following attributes were supplemented in the report headers (REP, REPK) (see above) for control of the print output as far as no diverging parameters are specified in the print dialogue. These attributes are displayed in the list applications (REP, REPK) and can be entered in the single record application.
The descriptions of the report ID and the report header now can be provided with placeholders (see above), which are replaced by the respective keys or designations when printing.
The list applications for report headers (REP, REPK) now facilitate a selection for message. For this purpose two entry fields, project ('IAR' or 'KON) and four digit message number, were supplemented. Partly qualified entries (usage of '%' and '_') are supported. In order to select all report headers supplied with a message you have to enter '%' in the first entry field, while the entry '*' in this field provides the selection of all report headers without a message.
The previous attribute "Account flag 2" of the report result lines is replaced by a new attribute "Transaction development". However, the "Account flag 2" still is displayed for reports already existing.
Group reports (balance sheet, profit & loss, cash flow, developments) are now supplied with a message, if they simultaneously contain consolidation postings from released and not released vouchers (for release of consolidation vouchers see above).
Controlling reports (report type 'C' or report options 'C', 'D' or 'Y') now process account balances, too, if the report structure contains accounts without controlling details. The details for controlling objects are supported by a new dummy controlling object '******NOCO', which is used for all data based on account balances. For report type 'C' (cost of sales report) only the balance column is provided for accounts without controlling details. The error message KON1030 (Report postings without cost center entries) is output only, if there are consolidation postings on controlling accounts without entry of a controlling object. The difference check (line type 'S', value flag '2') is reactivated for controlling reports except for report type 'C'. The error message "No data exist" now is output only, if neither controlling balances nor account balances were processed for a report. If only account balances were processed, now the new information message "No controlling balances exist" is output.
The consolidation postings of the new consolidation functions 'FK', 'F0', ... 'F9' (First capital consolidation minority interests) und 'FK' (Update minority interests) (see above) are allocated to the column "Minority interests" of the consolidation report.
The attribute "Report type" of the master data for column options (SPO) is uniquely set to the new value 'D' (transaction development) for all development reports by the release migration program. The information about the development is relocated to the new attribute "Transaction development" with reference to the new table SPI (see above).
Since all development definitions have to be individually performed (s.o.) the column options for development reports have to be individually maintained, too. Thus the previous standard column options (SPO) for development reports beginning with '#' (e.g. '#ANLG', '#KAPK') are transposed into individual column options including their column desriptions (SPA) and formulae lines (FED) as well as their usage in the report headers (REP) by the release migration program by replacing the '#' by a '$'. If a column option with this new name already exists, then a column option with another special character in the 1st position is defined.
An additional column option with suffix 'G' (e.g. '#ALTDG') was defined for all column options for display of relative deviations (#ALTD, #BUCD, #KOND, #KTKD, #NEUD und #SUMD), which displays the relative deviation in percent calculated in the original culumn option as a bar chart.
You now can specify the formatting of report columns (see above). The according attributes have to be entered in the application "Report column descriptions" (SPA). The single record application was supplemented by entry field for the corresponding attributes.
The font style (bold, italic), font size, font colour, background colour and a separation line between the columns (i.e. before each value column) can be individually defined for report columns. A separation line in front of the key column is automatically supplemented. The colours are defined with a special colour choser dialogue with different variants. The font style "normal" is used to overlay the standard formatting with bold or italic lettering.
Furthermore you can define bar graphs in a report column. The graph shows a bar representing the respective amount in green (with positive values) or red (with negative values) colour per line. The additional entry "Value display" controls, whether a value is to be output beside the bar or not. This value can be output as a complete amount, rounded whole numbers or rounded for 1,000 or 1,000,000 currency units. A minimum column width in mm can be specified for the print output, if the standard width is too narrow.
The list application "Position balances" (POSSAL) serves for calling the action XBRL export. A corresponding item was supplemented in the action menu.
XBRL is an international standard for transmission of accounting results. Because of the XML format the generated instance filed are not readable, but have to be evaluated and displayed by special soft ware.
There are several taxonomies for different accounting standards (IFRS, HGB, US-GAAP etc.) within the XBRL standard, which are subject to permanent modifications and enhancements. Each taxonomy consists of an xml definition (xsd), which contains the specific terms to be allocated to positions as so called concepts.
The conjunction between the IDL.KONSIS.FORECAST data and the XBRL taxonomies is defined in the position master data (POS). There each position can be allocated to an XBRL concept. If you want to create XBRL files for different taxonomies, then you have to define a chart of positions for each accounting type.
The amounts for the XBRL export are extracted from the position balances, too. Thus the generation of a report with specification of creation of position balances (report option = 'S' or 'P') is required for XBRL export. Otherwise the XBRL export contains no values.
The report can be a group report as well as a company report, since XBRL instance files are possible on both levels. The identification of this key in the XBRL instance file is exhibited by an URL (internet address). For this purpose the group/sub-group master data (KTK) as well as the company master data (GES) were enhanced by an attribute "URL", which has to be maintained for the XBRL export.
An XBRL instance file is created by the new action "XBRL export" of the list "Position balances" (POSSAL). Unique entries of the group/sub-group ('*' if empty), company, business unit ('*' if empty), and chart of positions in the selection area are required. Period and fact always have to be entered uniquely. Further restriction (e.g. position number, origin report or b/s p&l code have no influence on the exported data. Name and path of the file to be created are requested by a file dialogue. All further steps are automatically performed.
The support of the following XBRL taxonomies is planned with one of the next releases by allocating the concepts to the positions with an allocation dialogue:
The import/export format definitions for development transactions, postings and consolidation postings contain (historically grown) up to three different entry fields for posting keys: the original three digit field (one character for the development, two characters of the posting key) ...-K037-BSL, a field enlarged to four digits for transformation of the (three digit) SAP transaction type groups ...-K037-BSLEG, as well as a 20 character (6 characters development + 14 characters posting key) field for the enlargements allowed with this release. These fields may be used in the following way:
Development transactions with reserved posting keys (e.g. automatic carry forward, exchange rate effects) now can be imported, if these data were created by an export from IDL.KONSIS.FORECAST providing an IDL.KONSIS.FORECAST-to-IDL.KONSIS.FORECAST data transfer. Data from external sources (e.g. interfaces to accounting systems) still may not contain data for reserved posting keys.
The facility for import of data without files in the file system by temporary storage of these data in special database tables (s. Release 2008.1 News) was enhanced for the import of the following data stocks:
The list application "IE job control" (IEJOB) displays the jobs now decreasingly sorted by job number. The menu item "Delete data & Import" was dispensed in the action menu, since the processing mode (with or without deletion) is already defined in the job itself.
The start date "Import from" can be deleted in the application "IE job control" (IEJOBE) in order to define that the job can be started at once.
There is a possibility to copy data of a job to a new job. The selection of only with error marked records is implemented.
The usage of transformation groups for posting keys has been arranged more clearly by offering two distinct entry fields for the development and the proper posting key now. For this purpose the object type has to be uniquely specified in the list "Transformation group allocations" (UMSOBJ) before calling the single record application.
New import applications have been implemented for the import of the new tables for the definition of transaction developments (SPI), development columns (SSP), and development areas (SBE) (see above). The assigned standard formats can be viewed in the list "Export/Import Format IDs" (IEF) and its subsequent applications "Fields for import/export formats" (IEFDEF) and "Allocations import/export fields to formats" (IEFDEF). The call of the new applications was supplemented in the branch "Import master data" of the calling application "Data import and display" (IMPORT). These applications can be used to import the template development definitions supplied by IDL on the release CD in the directory "Liefer Batch".
New import applications have been implemented for the import of hierarchies of controlling objects (CNTCNT) and hierarchies of business units (UBRUBR). The assigned standard formats can be viewed in the list "Export/Import Format IDs" (IEF) and its subsequent applications "Fields for import/export formats" (IEFDEF) and "Allocations import/export fields to formats" (IEFDEF). The call of the new applications was supplemented in the branch "Import master data" of the calling application "Data import and display" (IMPORT).
Another new import program enables the import of descriptions independent from the corresponding master data. This way e.g. translations of the account descriptions of a chart of accounts performed outside of IDL.KONSIS.FORECAST can be imported. The assigned standard format can be viewed in the list "Export/Import Format IDs" (IEF) and its subsequent applications "Fields for import/export formats" (IEFDEF) and "Allocations import/export fields to formats" (IEFDEF). This format is designed for the maximum length of these texts, which however is not supported by the applications programs. Thus for practical reasons individual formats are recommended. The call of the new applications was supplemented in the branch "Import others" of the calling application "Data import and display" (IMPORT).
The import format for column descriptions was supplemented by the new attributes for column formatting (s.o.). Please mind, that font and background colour have to be specified as numerical RGB values here. The same applies for the export of column descriptions.
Because of the substantial transpositions in the database the data exchange formats of release 2009.0 and older releases are not compatible with each other. It is required, that the unloaded database as well as the loading database is on level 2009.0. This concerns the group-wide data exchange as well as the sub-group data exchange.
As a legacy of the former operating system DOS certain file names are reserved in some versions of MS Windows and thus cannot be used unrestricted. This e.g. the attempt to create a file with the name "CON.L_E" when unloading sub-group data from the sub-group 'CON' caused an error message due to unauthorised file access. Therefore the file names of the sub-group data exchange are now composed of a prefix ('T_') and the key of the sub-group like for the group-wide data exchange (prefix 'K_' before the key of the group) and the company data exchange (prefix 'G_' before the key of the company).
The new tables (see above) for transaction developments (SPI), development columns (SSP), development areas (SBE), periods / developments (ABRSPI), and facts / developments (FACSPI) were supplemented in the group-wide data exchange.
The protocol output (log files) of the applications for data exchange was revised in order to contain the information less technical.
The number of the current IDL.KONSIS.FORECAST release was supplemented in the protocols of the unload applications providing a check for consistent releases before loading the data.
The field extensions of IDL.KONSIS.FORECAST were mostly transferred to the IDLCONNECTOR. The new transaction developments were integrated in reading functions and export formats.
In the IDLCONNECTOR Acquisition Form the changed logic of retained earnings and the extensions of transaction development and posting keys were implemented.
Up to 8 instead of former 4 groups/sub-groups now can be specified on the MIS parameter (MISPAR). The additional groups/sub-groups are processed like the 4 groups/sub-groups up to now.
SAP Interface with Function Modules (kcusap.dll)
The SAP interface now can perform a logging in into the SAP system including a login to a message server with load balancing.
A unicode-variant "kcusapu.exe" of the SAP interface was supplemented, which processes descriptions with characters outside the western European codepages correctly.
SAP Interface with IDL.IMPORTER
Up to now the connection data for login into the SAP system were only kept in the kcusap.ini file. In some cases this file had to exist on the client as well as on the interface server with synchronised maintenance. Now the connection data can be centrally defined in the IDL.KONSIS.FORECAST database, if this mode is selected by the entry
UseK9xxx=yes
in the section [Connection] of the kcusap.ini file. Without this entry the control remains in the file mode.
In order to unload data for several companies from SAP in one step a list of accounting areas had to be built in a file CompanyCodes.txt on the server. Now this file can be replaced by a script in the IMD file, which identifies the list for accounting areas to be unloaded from the group companies defined in IDL.KONSIS.FORECAST evaluating the parameters sGroup, sExFaxt, iPeriodTo, and sUmsGrp transferred by the module kcusap.jar.
You can modify the scripts of all established job in a way, that all write operations are no longer proceeded with a file destination but rather with the destination of a database table. Thus you can use the procedure for import via temporary data in database tables introduced with release 2008.1 and enhanced with this release for the SAP interface, too. For this purpose an ODBC data source for the IDL.KONSIS.FORECAST database has to be set up for the interface server.
The intercompany of fixed asset transactions is now transferred from the interface data structure into the destination file/table. Advice: The script used in this connection has to be modified in order to provide the intercompany in the interface data structure.
With this release the following English-speaking documentations in the "doku" directory are updated or completed: