This release IDL.KONSIS.FORECAST 2008.1 is an interim maintenance and therefore may be left out in the release sequence. Prerequisite for this release is the last main maintenance 2008.0 from September 3rd 2008.
The supplements and corrections to this main maintenance up to the release date are included in the interim maintenance 2008.1.
This documentation describes the enhancements since the previous maintenance IDL.KONSIS.FORECAST 2008.0.
The login dialogue was supplemented by an area above the entry fields, that displays an explanation of this window and the icon of the called application.
A check box <Long prompt texts> was supplemented in the options dialogue on page "View". When selecting this option all prompt texts in the maps (selection area, single record area etc.) are displayed with their long descriptions, that were only shown as a tool tip when resting with the mouse pointer on the prompttext, otherwise, if the long description is not longer than 35 characters. Of course, the maps get wider with this option. Therefore this option is recommended only for users with larger screens. In addition, this option works only, if the sliding bar is set to position "most effects" in this options pane.
The ability for changing your password when logging in into IDL.KONSIS.FORECAST is supported for ORACLE databases (from version 10g on) now even then, if the user doesn't have the authorisation "ALTER SESSION" in the database. In addition, the user id may be entered in lower case letters.
Several new indices were defined in the database for the purpose to reduce the response time of complex data selections in IDL.KONSIS.FORECAST as well as in IDLCONNECTOR. The indices take an effect particularly at selection for certain accounts or controlling objects without restriction for company or business unit.
The migration program for this release performs no conversions. However, it has to be invoked once to omit the advice due to missing conversion when logging in into IDL.KONSIS.FORECAST.
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.
You have to authorise an authorisation group for update in the menu items PRFERG and PRFERGK, if the user group shall be able to enter or modify comments of check rule results.
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 parameters for an entry of a workflow control (MENMENE) may be specified either as an explicit key value (company number e.g.) or by a special key ('#ALL' e.g.). Now two distinct entry fields serve for the entry of an explicit key value or a special key, respectively, like due to other reasons already before for the current and the previous period. The advantage is, that both entry fields have an independent selection support, so that the available special keys per parameter are visible. However, you may enter only one of both fields.
You now can use the applications for import of data with previous deletion of existing data (menu ids 'TXL...') in connection with the entry of an import/export format in a workflow control. Only application TXLAGGKTO (Delete and import position account allocations) is excluded, since the required unique specification of a chart of accounts is not possible by the available parameters.
The usage of the menu ids AESALAUTO and SKSALAUTO now provides an IC reconciliation of company financial statements without creation of consolidation postings independent from any parameters. In this case the "ex fact" for determination of the group companies structure is read from the startup data (VOR) just like in many other applications. Up to now the "ex fact" had to be specified in the parameter for a comparison fact. If this parameter was missing a complete D&C or I&E consolidation was performed.
The account master data were enhanced by an attribute for an allocated minority interest account. It can be defined for all capital accounts (account flag 2 = 'K' or 'L') in the single record application "Account" (KTOE) and is used at posting of minority interests instead of the minority interest account of the consolidation parameter 'KA'. You can select data with an allocated minority interest account by entering the account type 'F' in the selection area of the list application "Accounts" (KTO).
When changing attributes (account flags e.g.) of accounts of the group chart of accounts the attributes of the allocated accounts of the company chart of accounts are adjusted. This adjustment is documented in a message window. The repeated output of this message window at mass update (e.g. when assigning the account flag 2 'S9' for all accounts not allocated to a transaction development) can be suppressed now by marking the check box <Don't show this message again>.
The position master data were enhanced by an attribute "Column header", where a particular text for usage as column header in the list application "Report mirrored" (REPERGS) may be specified. This attribute already was created with release 2007.0 and initialized with the position description by the release migration program. However, it is empty for positions defined later.
A column for visualisation, whether a help text exists for a master data record, was supplemented in the lists "Description individual development transactions" (ISP), "Column descriptions individual development transactions" (ISS), "Description development areas" (ISB) and "Consolidation functions" (KVA).
The coloured background of the account flags for visualisation of the accordance of the corresponding details now differentiates between [red], [yellow] and [green]. [Yellow] (new) is now used instead of [red], if the corresponding status in the company financial statements monitor (EA) becomes [yellow], especially at differences in group or parallel currency, that can be cleared only by a currency conversion.
For account balances on statistical quantity accounts (B/S + P/L code '5') negative values now can be entered, stored and displayed. Up to now values entered negatively were displayed as positive debit values.
The selection list for business units now contains aggregated business units, too, if invoked from the list applications account balances (KTOSAL) or controlling balances (CNTSAL). The entry of an aggregated business unit is required for the purpose of display as a hierarchy.
At double mouse click on a B/S+P/L code or account flag coloured [red] in the list "Account balances" (KTOSAL) IDL.KONSIS.FORECAST branches into the corresponding detail list (CNTSAL, ICKTOSAL, GESGES, ANLBEW, KAPBEW, RUEBEW, SPIBEW) with restriction to one account. Then the difference amount between account balances and total of detail data is displayed with [red] background in an extra difference line. This line now can be selected. At double mouse click (or action "Edit data") the respective single record application is invoked with the remaining difference preselected as amount in local currency. Thus incomplete detail data can be completed easily.
The facility for mass update of the posting key, the currency conversion rule, the exchange rate and the closing rate date for conversion into group as well as into parallel currency was supplemented in all list applications for development transactions (GESGES, ANLBEW, KAPBEW, RUEBEW, SPIBEW). Prerequisite for the entry of an exchange rate and its closing date is the currency conversion rule 'VK' (predefined currency rate).
In addition, the possibiliy of selection for an allocated group account was supplemented in these list applications. This feature was available for fixed asset transactions already with release 2008.0.
When entering a new development transaction (KAPBEWE, RUEBEWE, SPIBEWE) now the transaction date is preselected with the ultimo of the actual period like already realised for fixed asset and shareholding transactions since some time. Please mind, that the transaction date is evaluated in capital consolidation and therefore in this case has to be adapted manually.
Fixed asset transactions on statistical accounts (B/S+P/L code '6') now are checked strictly. I.e. the company financial statements monitor (EA) and the list "account balances" (KTOSAL) display the status [red] at differences between account balance and total of fixed asset transactions and the difference is reported in the message window of the list "fixed asset transactions" (ANLBEW). Other transaction developments were already checked in this way before.
If a shareholding account (account flag 1 = 'B') is allocated to an automatic individual transaction development (e.g. account flag 2 = 'S9'), then the generated development transactions now yield an intercompany (in case an IC business unit, too) according to the intercompany of the shareholding transactions of this account. This method is analogously to intercompany accounts (account flag 1 = 'I') with respect to intercompany balances.
The entry of an elimination account for inventories IC stocks is optional. Unlike the procedure up to now at missing entry it is no longer checked, whether an elimination account is defined in the product master data or the consolidation parameter 'ZU', since thte definition of a consolidation parameter cannot be presumed at entry of company financial statement data. This applies for import, too.
The net result effect of a voucher is no longer determined for the postings of a voucher all in all but rather per posting record. I.e. a voucher is classified as affecting net result even if the net result effects of two (or more) posting records eliminate each other.
The amounts in group and parallel currency now remain at change of the posting key of a posting in the single record application BUCHE. Thus postings behave like the development transactions generated from these postings.
Check sums for company financial statement postings are now created just like check sums for consolidation postings if demanded by the respective fact. A check sum is calculated per voucher and currency, stored in the voucher header and displayed in the list application "Vouchers" (BEL). The check sum accounts for the following attributes: company number, business unit, account number, debit or credit amount with debit/credit flag, posting key, fixed asset object, controlling object, intercompany, IC business unit. These check sums are refreshed at each modification of postings. These check sums are evaluated particularly in reports.
The processing control records (VERARB) now can be attached with a comment, e.g. for documentation of a status. Like other reported data this comment cannot be held in different languages parallelly.
Thus the release (lock) of a company financial statement can be documented by a comment for the check point "EALOCK". However, a comment (help text) may only be entered or modified with extra authorisation '2', if a company financial statement is already locked.
The actions "Edit help text" and "Display help text" were supplemeted in the action menu of the list "Processing controls" (VERARB) for this purpose. The existance of a comment is visualised by symbols (check marks) or colours ([green]) in a new column ("H"/"Help text status") like in other list applications, if the option "Show helptext infos" is selected in the menu "View".
When using individual authorisation groups without reference for IDL standard authorisation groups please mind, that the modification of comments requires the update authorisation of the corresponding single record application VERARBE.
The ability to branch into the subsequent application "Company financial statement monitor" (EA) was supplemented in the form entry applications for company financial statement data (I-KTOSAL, I-ICKTOSAL, I-CNTSAL, I-ANLBEW, I-KAPBEW, I-RUEBEW, I-SPIBEW, I-BUCH).
The value flag '8' set in the report line descriptions (REPZEI) provides the suppression of a total value of the accounts (e.g. statistical quantities) allocated to a position . This suppression now works in the form entry for account balances (I-KTOSAL) with sort option 'F' (entry in report map), too.
The action menu was supplemented by a call of the form entry application for controlling balances (I-CNTSAL). This branch also proceeds at double mouse click in the column for the B/S + P/L code.
A new application (I-CNTSAL) provides af form entry of controlling balances. The first version of this application corresponds to the form entry of capital, provision and individual development transactions with column option 'LE'. I.e. the relevant accounts are preselected and ordered as a flat list (SortOption 'Kx') or in report structure (SortOption 'Fx').
In addition you can control, whether all accounts designated with controlling flags are preselected for entry (SortOption 'yK') or only those accounts, that have account balances (SortOption 'yS'). The combination of both variants results in the four offered sort options 'FK', 'FS', 'KK' and 'KS'.
You have an entry line per account, where you have to enter at least one controlling object and an amount. Controlling objects of furhter controlling dimensions can be entered in addition. However, a check for the accordance between controlling dimension and account is yet performed when saving the entered data. At the end of the entry of a line in case a new entry line is inserted automatically. In addition, lines with existing data are displayed per account, that may be modified at demand.
Except from this the handling is similar to other form entry applications. You can branch into the subsequent application for form entry of account balances (I-KTOSAL).
Further variants of this form, e.g. display of controlling objects in columns (especially for cost of sales accounting), shall be supplemented in following releases.
A new check rule operator provides a check, that only one of two possible accounts may yield a balance. Translated into check rule logic the rule is declared as: If one side is not equal zero, then the other side has to be zero. If you allocate more than one account to one side, then the rule applies to the total of these account balances as well as for postings on these accounts in case of an according data type. The operator of this rule is named "(L/R<>0)=>(R/L=0)".
Furthermore now check rules for intercompany account balances may be specified. You have to select the new value type 'I' for the left and/or for the right side in the check rule definition (PRFE) for this purpose.
When calculating check rule results for value type 'I' intercompany account balances are read instead of account balances or development transactions. Postings and consolidation postings are restricted at reading to accounts with account flag 'I' or 'J' and to postings with entry of an intercompany.
The check rule results now can be attached with a comment, e.g. for documentation of a status. The actions "Edit help text" and "Display help text" were supplemeted in the action menu of the check rule result lists (PRFERG, PRFERGK) for this purpose. Like other reported data these comments cannot be held in different languages parallelly.
The existance of a comment is visualised by symbols (check marks) or colours ([green]) in a new column ("H"/"Help text status") like in other list applications, if the option "Show helptext infos" is selected in the menu "View".
If check rule results are newly calculated, then check rule results existing before are deleted. Then attached comments are deleted, too. Thus they are no longer present even if the the check rule result is identical.
When using individual authorisation groups without reference for IDL standard authorisation groups please mind, that the modification of comments requires the update authorisation of the corresponding list application.
Consolidation postings now can optionally be cumulated at carry forward into the next period, if the essential attributes (account, posting key etc.) are identical. This way the number of consolidation postings carried forward can be reduced significantly.
The comprehension is controlled by the consolidation parameters and therefore is capable of being differentiated by consolidation function. Please mind, that the consolidation parameters themselves are carried forward, too, providing a cumulation of consolidation postings in the next period, too, if the cumulation flag is not reset explicitely.
Consolidation postings with zero values (e.g. from capital consolidation with shareholding book value 0,00) now are carried forward (i.e. copied) during the period. Thus consolidation vouchers are identical in all interim financial statements. In addition capital consolidation postings out of posting record '01' with zero values are carried forward from annual financial statements.
If using clearing accounts when copying consolidation postings for a report sub-group (REPKTK) clearing postings were generated for the company not allocated to the report sub-group. Now all postings are generated only for companies allocated to the report sub-group. Thus error messages at report generation are omitted.
When using this function for migration of consolidation postings to a new fact with an alternative group chart of accounts then the indicated fixed asset objects are converted into specified allocated group fixed asset objects.
The message window with advices for consolidation vouchers not copied into the report sub-group now can be suppressed at mass processing. However, in this case mass processing only can occur within a workflow automat.
The ability for mass update of the exchange rates and the closing rate dates (currency conversion rule 'VK', predefined currency rate, supposed) were supplemented in the application "Account currency conversion rules" (KTOUAW). This concerns the conversion into group currency as well as the conversion into parallel currency.
For the purpose of application of entries in the account or posting key conversion rules (KTOUAW, BSLUAW) the following sequence of conversion rules uniquely applies for currency conversion of development transactions and postings of company and group financial statements:
I.e. the currency conversion rules 'SK' and 'PDK' can no longer be used for an explicit specification per development transaction or posting, since it cannot be distinguished, whether it is a demand or an audit trail of the processed currency conversion. Alternatively you can use the conversion rules 'VK' or 'VKW'/'VPW' joined with an entry of the respective exchange rate or the resulting converted amount, respectively.
The group processing control records (KVERARB) now can be attached with a comment, e.g. for documentation of a status. Like other reported data this comment cannot be held in different languages parallelly.
Thus the release (lock) of a group financial statement can be documented by a comment for the check point "KALOCK". However, a comment (help text) may only be entered or modified with extra authorisation '2', if a group financial statement is already locked.
The actions "Edit help text" and "Display help text" were supplemeted in the action menu of the list "Group processing controls" (KVERARB) for this purpose. The existance of a comment is visualised by symbols (check marks) or colours ([green]) in a new column ("H"/"Help text status") like in other list applications, if the option "Show helptext infos" is selected in the menu "View".
When using individual authorisation groups without reference for IDL standard authorisation groups please mind, that the modification of comments requires the update authorisation of the corresponding single record application KVERARBE.
A flag "with/without accumulation of consolidation postings when carried forward" was supplemented in the consolidation parameters for the consolidation functions 'KK', 'EK', 'KA', 'ZA' and 'MB'. It is evaluated in the period carry forward. The list application "Consolidation parameters" (KTKPAR) displays this flag, too.
A first version of an automatic group consolidation control has been available since several years. It contained the essential automatic functions (SK, AE, KK and KS) for all group companies. Disadvantages of this solution was the missing determination, whether specific functions are required or already processed, missing subsequent manual steps (e.g. difference compensation for first consolidation) as well as the absence of further consolidation functions.
Now the enhancement of the "calculation of status and participation" for determination of status of all consolidation functions with release 2008.0 (see Release 2008.0 News) allowed the realisation of a consolidation automat containing all relevant steps. I.e. consolidation functions already processed or not required due to missing basic data are not offered. This automat contains all consolidation functions with a determined status in the required sequence. This includes manual steps like difference compensation or selection of postings affecting net result for minority interests or deferred taxes.
This function is called like its predecessor by the action "Automatic consolidation functions" in the submenu "Functions" of the list "Group companies + monitor" (KTKGES). The menu of the workflow automat is two-tiered. The upper level represents a node for each concerned consolidation function, while the explicit steps per company yet become visible when opening these nodes. Thus certain cnsolidation functions can be excluded on demand. The desired processings have to be marked and started by action "Execute marked application".
Please mind, that this automat is a mixture of automatic and manual functions. I.e. a list is displayed at the respective steps, where the user has to enter appropriate data. The automatic processing is continued after exiting the list application via button <Continue> or function key <F3>.
Up to now with accounting type 'I' (IFRS) only compensation methods allowed by IFRS (capitalisation of goodwill without depreciations, clearing badwill and other clearings) were offered for compensation. With all other accounting types only the "classic" capitalisation of goodwill (with depreciations, but without exchange rate effects) was supported. However, there are national accounting types, that specify the "classic" capitalisation of goodwill for historical data, but an IFRS conform processing for new circumstances. Therfore now the list "Compensation of differences from first consolidation" offers all compensation methods independent from the accounting type. Thus the user himself is repsonsible for the selection of a compensation method according to the accounting type.
Up to now posting key '21' was always used for posting of exchange rate effects on goodwill in local currency within capital consolidation, even if an impairment was performed on the goodwill. Thus the according exchange rate difference was posted in the area for acquisition and production costs. Now the determination of the posting key differentiates between acquisition and production costs and depreciations.
You now can specifiy an account specific account for minority interests for capital accounts in the account master data. If specified it is used for minority interest consolidation postings. If not specified the minority interest account from the consolidation parameter 'KA' is used like before.
Currency exchange rate effects on shareholdings of a child company on affiliated companies are no longer posted within the indirect minority interests of the affiliated companies but rather within direct minority interests of the child company. In case this also applies to other balance sheet accounts converted with historical exchange rates.
The setting of posting keys for the capital transaction development at posting of direct and indirect minority interests on consolidation postings affecting net result and equity capital as well as with changes of shareholdings was revised.
Necessary adjustments not affecting the net result now can be differentiated between revaluation reserve and other adjustments. For this purpose the account for necessary adjustments was renamed into "Other necessary adjustments" and another account "Necessary adjustment revaluation reserve" was supplemented in the consolidation parameter 'EF' (KTKPAREF). The form entry for update equity (I-FORTEQ) shows two distinct lines for these accounts for entry and display, if two different accounts have been specified in the consolidation parameter.
You now can enter a not intercompany account as account for "Collected dividend" in the consolidation parameter 'EF'. However, a warning is output suggesting that dividends have to be posted manually in this case, since they cannot be derived from the intercompany account balances.
Posting keys per account were supplemented in the consolidation parameter 'LT' (deferred taxes, KTKPARLT). Posting keys entered there are used for automatic posting of deferred taxes on these accounts in the company as well as in the group financial statement.
The net result effect of a consolidation voucher is no longer determined for the consolidation postings of a consolidation voucher all in all but rather per posting record. I.e. a consolidation voucher is classified as affecting net result even if the net result effects of two (or more) posting records eliminate each other.
When branching from the lists "Account balances and consolidation postings" (KONSAL) and "Transactions and consolidation postings" (KONBEW) into the subsequent list "Consolidation postings" (KONBUCH) then there is no more restriction for account number providing the display of the complete voucher instead of the single posting line.
When working with business units the minority interest postings of different business units (e.g. minority interest on net result) are comprehensed in one posting record (e.g. '01'). Since this posting record contained postings for different business units it was classified as intersegmentary, although it is only a collection of intrasegmentary circumstances. Now 'KA' consolidation postings are excluded from the automatic setting of the segment flag, since 'KA' consolidation vouchers principally do not contain any intersegmentary postings. Rather the application for calculation of minority interests by itself classifies these consolidation postings as intrasegmentary.
An action menu was supplemented in the application for entry of plan data (PLAN) providing a branch into the following subsequent applications: "New Scenario", Company financial statement monitor (EA), Form entry intercompany account balances (I-ICKTOSAL), "Sales planning rule", "Purchases rule", "General rule".
Furthermore a function was implemented that revokes the last modification ("Undo"). Then not only the modification itself is revoked but rather all distributions, aggregations and rule based calculations derived from the modification are revoked. However, this function is available only as long as the data are not saved. Another function provides the ability to repeat ("Redo") the revoked modification.
The state of the button <Save> now represents the state of the displayed data. If it is selectable, modifications have been performed, that have not been saved yet. After saving the data, the button becomes inselectable.
Facts on the level of company charts of accounts now can be specified in a plan scenario, too.
When editing a new scenario there is no more fact preselected in the pages for selection of facts, since the preselection with the alphabetic first fact provided up to now easily provoked missentries. Now the button <Next> becomes not selectable before explicit specification of a fact.
The periods of a scenario are allowed to overlap between the different facts. The last period for actual data may agree with the first period of the forecast fact. Plan periods are even completely arbitrary.
Posting record rules trigger automatic calculations within the entry schedule. On the one hand there are special rule types, that represent certain business transactions. A rule for purchases was supplemented beside the rule for sales planning. On the other hand user specific rules can be specified and added. A guided dialogue was implemented for this specification. The upper part allows the addition and configuration of correlation rules while you specifiy the allocation of accounts to the used variables in the lower part.
A posting record rule consists of a sequence of correlation rules. Correlation rules always combine three values by the formula a * b = c. The following enhancements have been provided for these rules:
The selection for positions and accounts for correlation rules was revised. Amongst other things a filter field was supplemented. The tree table expands and displays only those positions and accounts containing the specified character sequence if entered in its name. The usage of the wild cards '%' for several arbitrary characters and '_' for exactly one arbitrary character are supported. If an account is displayed, then all superordinate positions are displayed, too. The output of all other accounts and positions is suppressed. After deletion of the entry the complete tree is displayed again.
Reports processing postings (i.e. company reports and group transition reports, but no development transactions or cash flow reports) evaluate the new check sums for company financial statement postings. Then the check sums for all concerned vouchers are comprehensed to a total check sum (per currency) for postings, that is saved in the report header (REP). The report list (REP) compares the saved check sum with a check sum calculated in the same way out of the actual data and provides a corresponding status display ([green] at agreement, [red] at disagreement) like the check sum status for consolidation postings. In case the check sums for postings are displayed in the report result list (REPERG), too.
The combination of report type 'C' (controlling report) and report option 'S' (writing of position balances) is no longer admitted, since this report type cannot write values for consolidation postings into the position balances due to deviating usage of report result columns.
The maximum number of amount columns of the report result list (REPERG) was increased from 100 to 200. This particularly concerns the display of the objects of the first level details (sub-groups, companies, business units, or controlling objects depending on the report type) in columns by usage of a corresponding column option and in case an object sort definition.
When branching from a display with objects (companies e.g.) in columns to a subsequent list then no column object is provided as parameter. Up to now always the object of the last column was used.
The selection for an account number now is possible without specification of the chart of accounts.
The mirrored report result list (REPERGS) displays positions in columns. Up to now the position descriptions were used as column headers providing rather wide columns and no clear arrangement.
Thus an attribute "Column header" was supplemented in the application "Positions" (POS), where a special text for usage as text for column headers may be specified. This attribute was already defined in the database with release 2007.0 and initialised with the position description by the release migration program. However, for positions defined later this attribute is empty.
The mirrored report result list uses this text as column header if specified. If not specified the position description is displayed like up to now.
Additional formatting attributes can be specified for report lines:
The table for report line descriptions (REPZEI) was enhanced accordingly. The entry of these attributes is supported in the single record application (REPZEIE), where the colours can be specified by by a special colour choser dialogue. These data can be exported an reimported, too. However, an import from other data sources is hardly possible due to the special formats of the colour attributes.
In the standard sort/selection option 'L' (list display) the list REPZEI displays the attributes in the usual style. However in tree representation (sort/selection option 'B') these attributes are applied to the respective lines providing an impression of the report layout to be expected.
These formatting attributes are transferred into the report result at report generation. Thus the formatting of a report just like its structure remains unchanged even if the report line description is modified later.
Of course, this formatting is applied to the display of the report result, too, when printing as well as for display on the screen.
When specifying 'X' for the entry field "with/without carry forward" the function for unloading capital transactions from external systems (e.g. SAP) is supplied with parameter 42 = '/v'. Thus parameter 42 can be specified in the command line for the external call of the menu item UNLKAPBEW. Up to now this feature was available only for fixed asset and provision transactions.
Import via temporary database tables has been realised as a third way to transfer data to IDL.KONSIS.FORECAST besides the "classic" way via files ("txt" files, ASCII files) and direct import via program to program interfaces. This is particularly interesting for interfaces realised with IDL.IMPORTER, since this tool is sepcialised for reading data from database tables, converting them and writing into other database tables. Other tools may be used for this purpose, too, when observing the following rules.
For this purpose a special import table per data stock was defined in IDL.KONSIS.FORECAST. Besides the attributes of the data to be imported this table contains a prefix, that mainly consists of a job number. This job number specifies data belonging together. In some cases the attributes are longer than in the original table providing the facility of transformation from external keys into internal keys. The following fields (emphasized are required) are included in the import tables beside the attributes defined in the '#DB' format:
| Attribute | Short Description | Meaning |
|---|---|---|
| I1XX_JOBID | Number of the job | allocated job id in I001 |
| I1XX_RECORD_NR | Consecutive number | sequential number of the data record within the job |
| I1XX_IMP_ERROR | Error at import? (Y/N) | Flag designating, whether this record has been imported |
| I1XX_MODIFIER | User id of the last modification | |
| I1XX_DATETIME | Timestamp of the last modification | |
| I1XX_LOCKUSER | LOCK user identification | |
| I1XX_LOCKDATE | LOCK timestamp |
A new list application "IE job control" (short word IEJOB or via action menu of the calling application IMPORT) displays all jobs contained in the special import tables. You have to define a new job directly in the database table I001, before you can write data into the import table. The attributes of I001 have to be set as follows (emphasized are required):
| Attribute | Short Description | Meaning |
|---|---|---|
| I001_JOBID | Number of the job | The next subsequent job id has to be entered. The user is responsible for determination of this unique number. You can use the prepared table I000 for this purpose. There a sequence name (I000_SEQ_NAME) and a corresponding consecutive value (I000_ACT_VAL) can be entered. |
| I001_USERID | User id | User id in IDL.KONSIS.FORECAST that is to be used for execution of this job in IDL.KONSIS.FORECAST |
| I001_ENABLED | Release (Y/N) | The release of a job for execution can be controlled here. The execution is only allowed, if its value is 'Y'. |
| I001_FOLLOW_JOBID | Consecutive number of a aubsequent job | not yet implemented |
| I001_WITH_DELETE | Import with previous deletion (Y/N) | Flag, whether existing data are to be deleted before import |
| I001_START_FROM | Earliest import timestamp | Timestamp for the first possible execution of import |
| I001_JOB_START | Beginning | Start timestamp of the job |
| I001_JOB_END | End | End timestamp of the job |
| I001_JOB_SUCCESS | Success status of the job (Y/N) | Flag, whether success or failure |
| I001_IEF_PROJID | Project id | Project id of the job. You always have to enter the value 'KON' here. |
| I001_IEF_OBJID | Object type | Object type of the job. For import the value 'IEO' has to be entered here. |
| I001_IEF_OBJID | Object id | Data type of the job. You have to enter the name of the corresponding import/export format data type here, e.g. 'KTOSAL' for account balances. |
| I001_MODIFIER | User id of the last modification | |
| I001_DATETIME | Timestamp of the last modification | |
| I001_LOCKUSER | LOCK user identification | |
| I001_LOCKDATE | LOCK timestamp | |
| I001_JOB_CREATOR | Data provider | Text for identification of the origin of the data of this job |
| I001_JOB_CREATED | Timestamp of data delivery | When were the data inserted into the import table? |
The job number of the generated job has to be used for subsequent writing of data into the import table. The import into IDL.KONSIS.FORECAST can be started via application "IE job control" (IEJOB). Start and end of this processing as well as a processing status are recorded in the IE job control.
The new import/export format '#DB' is used for this type of import. It is designated with the new format type 'TABLE' in the table for import/export formats (IEF). The IEF definition contains the name of the import table in the attribute "Default filename / table".
Messages at loading of data into the temporary table as well as messages at the actual import are written into a database table, too, instead of a protocol file. This protocol can be viewed by the new list application "Import protocol", which can be called via object menu of "IE job control" (IEJOB). This protocol distinguishes betweeen messages from data delivery and messages from data import via parameter "Job step".
An import job can be deleted completely via action "Delete" in "IE job control" (IEJOB). Then the job control record itself is deleted as well as all corresponding records in the import table and the allocated protocol.
With this release this new feature supports the data stocks (object types) account balances (KTOSAL in table I100), intercompany account balances (ICKTOSAL in table I101) and controlling balances (CNTSAL in table I102). Further data stocks will be supplemented with the next release. With the current release this function is available only for local clients but nor for remote clients connected with the application server.
The sub-group data exchange was adapted to several database enhancements. In addition comments for the records for processing controls (VERARB), group processing controls (KVERARB) and check rule results (PERERG, PRFERGK) are transferred, too.
With respect to problems with file names reserved by the operating system ('CON' e.g.) file names for the sub-group data exchange now are built by concatenation of the prefix 'T_' and the sub-group key. This is analogeously to the file names for group-wide data (prefix 'K_') and company data (prefix 'G_'). Up to now only the sub-group key itself was used as file name. For the purpose of compatibility to older releases the program for loading of sub-group data looks for files due to the old naming convention if no files due to the new naming conventions are found.
The group-wide data exchange was adapted to several database enhancements.
Sub-group data now can be deleted after their archival storage even if the sub-group data contain locked company or group financial statements.
The response time of the read function of the IDLCONNECTOR could be reduced significantly in many cases by caching read data and optimisation of the database accesses.
The run time of the MIS/OLAP data preparation for master data could be reduced significantly by optimisation of the preparation of position account allocations.
The run time of the MIS/OLAP data preparation for reported data could be reduced by an optimisation of the database accesses. The test resulted in a reduction by 30% with version '03' of the MIS/OLAP data preparation.
A progress display now explains, in which phase the MIS/OLAP data preparation is running.
The IDL SAP interface (kcusap.jar) now supports the unload of capital transactions from the SAP system, too.
The SAP Logon Panel provides a radio button for the user to choose whether actual data (like up to now) or plan data (newly) are to be selected from the SAP system (cost of sales ledger).
Advice: These functions are only available for the solution using IDL.IMPORTER/Connectivity.
There was no mapping for SAP transaction type group 42 to a IDL.KONSIS.FORECAST posting key. Now the SAP transaction type group 42 is mapped to IDL.KONSIS.FORECAST posting key 'A01'.
With this release the following English-speaking documentations in the "doku" directory are updated or completed: