When you start IDL.KONSIS.FORECAST for the first time after it has been installed, a message will be issued to inform you that migration has not yet taken place. This message box includes the button <Start migration now>. Migration will start automatically if you press this button.
In addition to the conversions of Release 2016 Update 1 the migration program will complete the following transformations in the database:
In addition to the amendments of Release 2016 Update 1 the following menu IDs are new or include new authorised actions in this release. If completely maintained customer-specific authorisation groups are used, you might need to enter access rights for these menu items (BENMEN). In most cases, the menu authorisations of the user group IDLKON and/or IDLWIN can be used as a template.
The following menu items are new, too, however, they do not correspond to IDL.KONSIS.FORECAST applications but rather refer to web-services used by other products of the IDL CPM suite. They serve for control of the authorisation of users of other applications for usage of these web-services.
The following menu items were deactivated with this release. They will be deleted in one of the subsequent releases. Please remove all individual usages (authorisations, menu structures) of these menu items until then:
The menu item Z-POSKTO (Position/account allocations drag&drop) does no longer provide for the previous application but rather is used for granting of authorisations for the analogous function within the application "Charts of positions" (POP).
As far as these applications could be invoked directly via short word entry now an automatic switch to the short word of the new application as substituted is performed when entering one of the disposed short words.
The Simplified Procedure for Administration of Customer Specific User Groups is recommended as an alternative to complete maintenance of authorisations for all menu items. For this functionality, the authorisation level '0' can also be specified for menu authorisation (BENMENE). This states that an authorisation available for a reference user group should not be issued for the user group that has been entered.
Opposite to the usage of authorisation level '0' described in the previous paragraph it was implemented in many applications that the authorisation entries per menu item for the user group assigned to the user were completely valid and overlaid the corresponding entries of the reference user group. I.e. there was no authorisation, too, if the authorisation level was empty instead of '0'. This was unified and corrected with this release. All concerned empty authorisation levels are converted into '0' by the release migration program (see above) providing that nothing is changed for the user. Nevertheless it is recommended to control the settings whether they correspond to the desired behaviour.
The applications invoked by a workflow automate are no longer checked by the workflow control for authorisation for inserting data but rather only for the authorisation for displaying data. Thus e.g. now you can call forms entry applications only for the display of data. An insert authorisation check is furthermore performed by the application itself.
If the option '#ALL' is specified for a key (group, company) and simultaneously a period is preselected, then now a check for validity of the groups or companies, respectively, in this period is performed. If a key is not valid, then no functions are generated for this key. This avoids annoying error messages when processing the automate workflow.
The invocation of a web service of the IDL.KONSIS.FORECAST Application Server is now possible even if no default database had been specified for the application server. Then the database has to be specified at login.
If the versions of client and server do not agree when connecting the client with the server, then now meaningful advices are output.
The program for configuration of the IDL.KONSIS.FORECAST Application Server was revised. Among others the page for configuration of databases was newly designed:
In addition, a possibility to set the session timeout for automatic separation of inactive connections was supplemented. For this purpose the parameter "session.timeout" has to be set to the desired value in the file "appserver.properties". The standard value was increased from 50 to 90 minutes.
On the page "SSL certificate key store" the following changes happened:
Different actions now provide for that the log files of the IDL.KONSIS.FORECAST Application Server do not claim too much memory space.
The client setup is now provided by the IDL.KONSIS.FORECAST Application Server. Corresponding links are contained in the app catalogue of the portal as well as in the mini-portal.
The list of selectable applications displayed in the application window if no other application has been started up to now suppressed headlines (tree nodes) if only one single menu item was arranged below this node. This control now has been removed. If clarity suffers from this modification the menu structure has to be adjusted.
IDL.KONSIS.FORECAST now supports the e-mail distribution of the displayed data. An additional button in the print dialogue provides for the generation of the displayed contents as a pdf document which is supplied to the e-mail as an appendix. When you push the button the e-mail client is invoked and only address and subject have to be supplemented.
An e-mail button was supplemented, too, in error dialogues (after pushing the button <Details>) and other message dialogues. It allows for the transmission of the error information from the user to the IDL hotline or other recipients. In case of error dialogues a copy of the info dialogue is generated, too, and appended to the e-mail. An e-mail button was supplemented in the info dialogue itself, too, for easier transmission of this information to the IDL hotline.
Since e-mail programs are different you have to specify your e-mail program in the options dialogue of the user. For the time being MS Outlook and Lotus Notes are supported. For other programs (e.g. Mozilla Thunderbird) the installation of plugins may be required.
The data transfer of table data to MS Excel, via copy and paste as well as by the function "Export to Excel", was sincerely accelerated, especially for large amounts of data.
For the purpose of opening the additional dialogue (entry of additional parameters) of forms entry applications now the function key <F2> can be used. Up to Release 2014 Update 1 this was supported by the function key <F5> which is used for refresh of the display since Release 2016. Please note that the function key only works if the cursor is placed to the cell for the additional dialogue.
A function for copying single periods (entry with template) was supplemented in the application "Periods" (ABR). However, for copying of all periods of a business year into a new business year still the function "Mass-copy" is recommended.
One of the important modifications within this release was performed for the position/account allocations. The data were provided with entries for validity (valid from, valid until) providing for a historical establishment of these allocations. Thus you now can generate a report for a previous period or even an actual report with the allocations valid at that time.
For this representation the hitherto database table K023 for position/account allocations was replaced by the new database table K020. The data are converted from K023 to K020 by the release migration program (see above). The validity of the allocation is set to the intersection of the validities of position and account.
In addition, provided by a different primary key definition of the table it is now supported to allocate an account with the restriction to different controlling flags 1 to the same position for a report by the function of expense method.
The maintenance of the new allocation table is performed within the application "Charts of positions" (POP). After selection of a chart of position (double mouse click or eye icon) now two dependent tables are displayed as registry tabs behind each other, beside the table of positions a table of position/account allocation representing positions and accounts in tree structure.
In addition, on the left hand a selection area opens exhibiting entry fields for a period and a chart of accounts. The entry of a chart of accounts provides for the display of a list of accounts of this chart on the right hand as resource table. Partially qualified entries or '%' are admitted as values for the chart of accounts, too. Then the resource table becomes a tree table, too, with the charts of accounts as nodes and the allocation table gains an additional node level for the charts of accounts between positions and accounts.
The account table exhibits accounts in three different font colours: Grey writing represents correctly allocated accounts, accounts not yet allocated are displayed in black colour and red letters designate accounts which are multiply allocated. The latter is reported in the open task list in the footer of the application window, too. However, allocation to thereof-positions are not counted in this context.
New allocations are simply defined by selecting one or more accounts in the right hand table followed by dragging and dropping them on the desired position. You can change the allocation of an account by a drag and drop action in the allocation table itself, too. In these actions the permissibility of the allocation with respect to the b/s p&l code of positions and accounts is respected. Existing allocations are deleted using the delete icon or the <Del> key.
The entry of a period in the selection area provides for the display of only those allocations which are valid in this period. Correspondingly the font colours in the account table always refer only to the state in this period.
All new allocations are valid from the selected period on but not in the past. If the account had been allocated to another position before, then this allocation is provided with a valid-until period of one month before the selected period providing that no multiple allocations arise. If the account is already allocated in a later period then the validity of a new allocation is limited correspondingly. However, if it is the same position allocation as currently defined, then both records are comprehended with a correspondingly longer validity. Excepted from this mechanism are allocations to thereof-positions here, too. In Addition, the validities of position and account are considered.
Allocations can be modified by a wizard or in the mode "Table cells editable", too. However, only both attributes, "Debit/credit flag" and "Controlling flag 1", can be changed. The wizard also allows for the entry of new allocations. Then position and account number have to be entered.
As known from the previous application "Position/account allocations drag&drop" (Z-POSKTO) the entry of a debit/credit flag provides that the account in combination with the opposite debit/credit flag is again displayed in the account table in black colour indicating that the user yet has to allocate this constellation to another position.
A corresponding control was established now for the controlling flag 1. The entry of a controlling flag 1 provides that the account is multiply displayed in the account list in black colour combined with all other defined controlling flags 1 for the purpose of complete allocation without any gaps. However, as already mentioned above now you can allocate the one account with different controlling flags 1 to the same position.
In addition, there is a new list application "Positions+accounts allocations - period -" (POSKTOP) which serves for an overview of all data contained in Table K020 independent from their validity and on demand simultaneously for several charts of positions corresponding to the previous application "Positions+accounts allocations" (POSKTO). However, modification of the data is not supported by this application.
The previous applications "Positions+accounts allocations" (POSKTO) and "Position/account allocations drag&drop" (Z-POSKTO) for the table K023 have been dropped.
It may happen in release migration, that existing position/account allocations are not transferred into the new table if the validities of position and account do not overlap. These data are branded at conversion and can be viewed by the new list application "Position/account allocation list for conversion" (POSKTOKONV) along with the validities of positions and accounts. If you recognise that these validities are not correct you can modify them and then repeat the migration for these allocations by the action "Conversion by line". However, this is only possible as far as no other modifications have been performed for the new allocation table yet. The action "Delete by line" provides for removal of the brand and thus removal from this list for more clarity, if it is correct that no new allocations were generated.
As far as the change log is activated for position/account allocations changes on the new allocation table K020 are logged, too. However, these data are written into a new log table. The display of these data is performed with the new list application "Changes of positions+accounts allocations -period-" (POSKTOPLOG). The list about changes on the previous allocation table (POSKTOLOG) is maintained for an audit trail over all historical periods.
The possibilities of this enhancement are especially exploited by reporting (see below), while the ordinary data displays by position or in report structure evaluate only the allocations of the actual period. This especially applies for the display and entry forms over several periods like in forms entry (I-KTOSAL) and in IDL.FORECAST where this period can be set (see below).
Attention! The restriction of the validity of an account automatically provides for the restriction of the validities of all corresponding position/account allocations. As a consequence data on invalid accounts are no longer contained in reports. If applying (e.g. if data on invalid accounts are continuously carried forward) it is therefore suggested to leave the account unlimited vaild while the entry flags of the account are set to '-'.
A flag "Planning account" was supplemented in the account master data. This flag designates accounts which are exclusively used for IDL. FORECAST, e.g. as parameter for rules. Accounts designated this way may only be used in facts which are designated as "plan fact". The account choice dialogues for other facts suppress the display of these accounts.
The list application "Accounts" (KTO) allows for the display of accounts allocated to a specified position. From now on a period is required for this determination (see above). For this purpose an entry field for the actual period was supplemented in the extended part of the selection area. Without entry the actual period from the start-up data (VOR) is applied. This period (entry or start-up data) is evaluated, too, when copying account and by the action "Create allocation POSKTO for company account no.". There the valid-from period of newly created allocation records is provided with this period.
A new application "Chart of account definition" (KTODEF) comprehends the previous applications "Charts of accounts" (KTP) and "Account" (KTO) incl. their single record applications in one integrated application. In addition, it is intended to integrate the application "Account groups" (KTOGRP), too. The previous applications mentioned above are still present in release 2017, however, they will be deactivated in one of the following versions.
After invoking the application a table of all defined charts of accounts is displayed at once without any selection, i.e. pure charts of accounts as well as charts of accounts simultaneously used as charts of controlling objects, but no pure charts of controlling objects. If you wish to us a chart of controlling objects as a chart of account you have to set the respective flag for the chart of controlling objects in the application "Controlling definitions" (CTLDEF).
Using the context menu you can branch off into the list application "Account groups" (KTOGRP). A double mouse click as well as a click on the eye icon provides for opening of the chart of accounts and a table with all accounts of the chart of accounts is displayed while the table with chart of account is automatically faded out.
Modifications of the data of the chart of accounts header are performed using a wizard which is opened with aid of the pencil icon of the global tool bar. The wizard serves for new entry and copying of a chart of accounts, too, where copying includes copying of all accounts of the chart of accounts. The wizard consists of three pages:
The table of accounts shows all account attributes in columns. Opposite to the application "Accounts" (KTO) no attributes of the allocated group account are displayed for company charts of accounts.
A wizard serves for new entry, change and copying of accounts with entry fields distributed to seven pages:
In principle plausibility checks are performed in the same way as in the single record application "Account" (KTOE). Generally, dependencies between the fields are checked in the way that an error in case is reported for the attribute located on a rear page. Thus the wizard can be edited from front to end without back steps.
Editing of table cells is supported, too. However, due to many dependencies of the attributes with each other faulty entries either are immediately rejected or are written as an open task (list in the bottom of the application window). As far as this list contains open tasks saving of the changes is not possible. Pushing the <Save> button provides for the output of a corresponding message.
A posting key for the capitalisation of interests from foreign capital (requirement of BilRUG) was supplemented in the "Lieferbatch" files for fixed asset transaction development. For the old standard ("Fortschreibung der alten Standardspiegel") the posting key '40' is used, in the new standard the posting key '111'. Please assure that this number is not yet used for other purposes before exporting the new key with IDL.XLSLINK.
The "Lieferbatch" file POP_KTP_RID.xlsm for a capital transaction development report was supplemented by XLSLINK references for the new export functions for charts of positions and report IDs and thus now can be exported completely without manual entries.
When entering data in report structure (I-KTOSAL, I-CNTSAL, I-xxxBEW) now the data are displayed with respect to the position/account allocations valid in the actual period. Please note that the new table K020 (see above) contains a validity range. Accounts without allocation in the actual period due to validity restrictions are no longer present in the form.
Values on accounts for statistical amounts (b/s p&l code '5') can be maintained with and without debit/credit flag. However, there were some discrepancies for data without debit/credit flag in the comparison of account balances with their details (development transactions, intercompany account balances, controlling balances). These discrepancies now have been cleared. Data with positive amounts without debit/credit flag are now always treated like data in debit, data with negative amounts like the corresponding values in credit.
When entering inventories IC-Stocks (ICVOR) the overhead or direct percentages of the delivering (inter-)company are not always known. Therefore these margins can be specified for the delivering company in an application on its own (PROMAR).
This correlation is now accommodated in the way that the roles of company and intercompany as parameter are interchanged in these applications when each other calling. This applies for the forms entry applications (I-ICVOR, I-PROMAR), too.
The data of the IC clearing list (KGESGES) are provided with a check sum from now on. This check sum is composed out of all intercompany account balances and postings on intercompany accounts for the respective combination of company, intercompany and voucher classification (KVA). All data relevant for intercompany clearing are considered in the check sum, among others amount in group company, amount and currency code in transaction currency, business unit, intercompany business unit, account number and controlling objects. This check sum is determined and saved at creation of an intercompany clearing record by intercompany reconciliation or consolidation D&C ('SK') or I&E ('AE'). However, this check sum is only output by the IC clearing list if the view option "Display internal info columns" is set.
When repeating the intercompany reconciliation it is checked whether the newly determined check sum agrees with the saved check sum. If this applies the existing intercompany clearing record remains and thus also a manual release, if granted, remains.
It is now possible to convert company financial statements with result differences, e.g. account balances only for p&l. However, in this case differences are not compensated by postings on the currency conversion clearing accounts.
The number of consolidated companies of the group companies is now restrictively checked against the number of licenced companies. When exceeding this number an error message is output instead of the warning message up to now and no consolidation functions can be performed.
When branching off from the group monitor (KTKGES) into the company financial statement monitor (EA) now the group key is transferred as a parameter. The group key is required for processing and status display of IC reconciliation.
The account for shareholding result was removed from the consolidation parameter 'SK' (incl. 'S0' to 'S9') since it had no function because of other modifications.
Only p&l accounts may be yet specified as neutralisation accounts in 'AE' consolidation parameters. Otherwise the desired effect of neutralisation is not reached.
The function "Make postings for differences" compensates the determined open difference in the threshold value account even if the difference is greater than the threshold amount. Within this now the flag "Accumulation of differences" is evaluated. If this flag is ot set then e.g. at first incomes of one company are compared with costs of the other company and then the other way round. Both differences are compensated separately.
The "List for elimination of current assets results" (ZWERGUV) now displays the elimination amounts as negative amounts if they are current asset losses. It is considered, too, if the current assets represent credit amounts (separate value adjustment accounts). Thus the balanced interim result can easily be calculated as the total of the displayed amounts.
The new posting type 'WT' (repetitive, only sub-groups) has been introduced for consolidation vouchers. On the one hand this posting type works like the posting type 'ET' (single-use posting, only sub-groups) in the way that the allocated postings are only considered in group reports of the respective sub-group but not on higher levels of the group structure. This applies for other report-like lists, too. On the other hand vouchers with posting type 'WT' are carried forward like the posting type 'WU' (repetitive posting with transfer) and maintain their posting type 'WT'.
The list application "Consolidation postings" (KONBUCH) now (again) allows for the selection by the flag "Inter/intra segment key". The entry '*' selects data without the inter-segmentary flag. Up to now it was yet possible to set a filter on the corresponding table column, however, this had no effect on the displayed total amounts.
Consolidation postings affecting the net result from vouchers with the posting type 'ET' or 'WT' no longer must be designated for the calculation of minority interests or deferred taxes.
For entry and maintenance of check rules a new integrated application "Check rule definition" is introduced. This application comprehends the functionality of the following previous applications (incl. their single record applications):
The previous applications listed above are furthermore activated and applicable in release 2017, however they will be deactivated in one of the subsequent versions.
After Invocation of the application without any selection three tables are displayed: on the left hand there are two tree tables, "Check rule groups" and "Check rule exclusion groups", as registry tabs behind each other, on the right hand there is the flat table "Check rules" with an alphabetically ordered list of all defined check rules.
"Check rule groups" corresponds to the representation of the previous application "Check rules" (PRF) with the difference that check rules without allocation to a check rule group are not displayed. Therefore these not allocated check rules are represented with a brighter background in the right-hand table as a note that these rules should be allocated to a group, too.
This allocation is performed by selecting and dragging with the mouse and dropping on the desired destination group. The movement of the allocation to another group within the left-hand table is performed in the same way. Allocations can be revoked by the opposite action or via the action "Delete" from the context menu. Each check rule may be allocated only once in this structure.
In the same way check rule groups can be subordinated to other check rule groups within the tree. However, the action "Delete" provides here for a complete removal of a check rule group incl. all allocation of check rules so that these check rules change their background colour in the right-hand table.
In the same way check rules can be allocated to check rule exclusion groups in the second table. Here a check rule can be allocated multiply. Therefore the allocations to check rule exclusion groups have no effect on the representation in the table "Check rules". In addition, check rule exclusion groups cannot be allocated to each other so that this tree table has only one level.
The selection in these three tables is synchronised. I.e. the selection of a check rule in one of the tree tables provides for the selection of this check rule in the table "Check rules", however, this does not apply the other way round.
All of these tables have a wizard for new entry, change and copying of a record. For check rule groups and check rule exclusion groups this wizard consists of only two pages which, according to the standard, allow for entry of key and descriptions on the first page as well as of multi-language descriptions on the second page.
In addition, the wizard for check rules contains entry fields for validity on the first page as well as two pages "Properties" and "Additional entries". The operator, the check level (group/company) and the base settings for the left and the right side of the rule are defined in "Properties" while tolerances and "per" flags are specified in "Additional entries". Opposite to the application "Check rules" (PRF) the assigned check rule positions are copied along when copying a check rule.
However, changing a check rule is yet possible after opening of the rule (double mouse click or eye icon). Then another table "Check rules / positions" opens displaying the positions of this check rule. Then the three tables displayed in the beginning are automatically faded out.
Creating, changing and copying of check rule positions is performed using a wizard, too. This wizard consists of four pages:
Plausibility checks are performed analogously to the previous applications for check rule definitions mentioned above. Changes can be performed in the table directly, too, after setting of the flag "Table cells editable" in the context menu. All modifications are persisted in the database yet after pushing the <Save> icon with the mouse.
Up to now only positions with directly allocated positions (position types 'MP' or 'MS') could be evaluated in check rules. From now on aggregated positions (position types 'OP', 'OS' and 'OT') can be used, too.
A report is required for determination of sub-ordinate positions to be evaluated for calculation. This report ID has to be specified in the check rule / position (PRFPOSE or page "Account selection" of the wizard for check rules / positions). This entry corresponds to the entry of on "Origin report" in IDL.CONNECTOR or IDL.XLSLINK. Then, depending on the position type, the settings of allocated positions or In- and Ex-memories in the report line descriptions are evaluated.
The "Check rule result analysis list" (PRFERGANA) shows in this case the determined sub-ordinate accounts immediately below the total position without exhibiting the positions arranged in between.
You can now use business ratio positions (chart of position type 'K') in check rules, too. These are evaluated due to the assigned formula (FED). If the formula contains total positions then, in addition, the specification of a report ID (see above) is required, too. Comparison values for a business ratio check rule (e.g. equity ratio > 20%) have to be provided in forms of values on statistical accounts and thus can be specified depending on company and period.
The "Check rule result analysis list" (PRFERGANA) shows the complete formula for business ratios with their operators and operands (incl. constants) and the determined value of the business ratio providing for a detailed retrace of the check rule result.
Like other 'per' flags the definition of check rules was supplemented by a flag "per company". This flag only affects check rule result calculations on group level und provides for the calculation of the rule for each company of the group companies on its own. On company level this flag has no effect since only one company is processed.
If the flag is set for a check rule the "Check rule result analysis list" (PRFERGANA) groups the data by company, too, so that deviations can directly be assigned to a company.
The calculation of the check rule result for a company or a group now requires the authorisation for update of data of this company or group, respectively.
If a check rule specifies the check rule value type 'S+B' (balances + postings) on both sides of the rule, then now the "Check rule result analysis list" (PRFERGANA) separately exhibits and compares balances and postings with each other. This simplifies the analysis whether a possible difference arises from balances or postings. However, the check rule result itself is continuously calculated from the total of balances and postings.
In addition, the "Check rule results analysis" list (PRFERGANA) was revised and enhanced in the following items:
The new feature "Cross-company IC planning" provides for consistently planned intercompany data of a company (e.g. IC sales) versus the data of the trading partner (e.g. IC expenses). As far as corresponding rules are defined the corresponding data are automatically issued for the intercompany and considered there. This requires the following steps:
For the time being the cross-company IC planning is limited to p&l accounts on the group chart of accounts. Balance sheet intercompany balances are generated by the application of rules. For consistent balance sheet intercompany balances the rules have to be defined consistently, e.g. by the agreement of unique payment arrangements.
Furthermore intercompany balances are always transferred only in one direction specified by the profile. I.e. for each issue one company is leading and determines the intercompany balances for the partner company. These data must no more be modified by the partner company for the purpose of sending them back to the origin company.
Please mind with respect to the currency conversion that IDL.FORECAST keeps decumulated amounts and converts them with the average exchange rate specified for this month. Since IDL.KONSIS converts cumulated amounts by the exchange rate average per period differences (exchange rate effects) may result.
For maintenance of the profiles specified in item 1. there is a new application "Cross-company IC planning" (short word: ICGP). It consists of two windows: One window serves for the administration of profiles while the other allows for the specification of account allocations of an opened profile. The window for profile administration is placed on the left hand just like the window with scenarios in the planning application. If a profile is opened then the bigger window on ther right hand displays a list with all account allocations defined for this profile.
A profile is the collection of all allocations required for a cross-company IC planning. It is identified by a unique name which has to be specified in scenarios with cross-company IC planning. The assigned account allocations are restricted to one chart of accounts. A profile can only be deleted as long as it has not been allocated to a scenario.
For each allocation defined in a profile you have to specify source and destination of companies and accounts. Each allocation is valid for an amount of specified source and destination companies. These entries may be performed in the form "all companies except for ...". One source account can be allocated to several destination accounts with defined percentages of their portions of the amount. Source and destination accounts have to be assigned to the same voucher classification (KVA) providing for a correct processing by consolidation I&E (AE).
Each allocation of the profile is uniquely designated by a running number. This number ist displayed in error messages or other lists (e.g. cross-company IC planning list, see below) for easier finding and, in case, modification of the allocation in the profile.
The acceptance of intercompany balances from the scenarios of other companies (see above) as well as the functions of the new "Splashing Dialogue" (see below) can be integrated in a forecast sequence and thus be executed from the forecast monitor (PM).
The new flag for distinction between zero balances and empty data (see below) can now be specified as parameter of a forecast sequence.
A column "Parameter" was supplemented in the Forecast sequences. I.e. you can now allocate a separate parameter to each step of the sequence which superposes the general parameter of the sequence per company. Thus e.g. it is supported that the same step (e.g. "Refresh balances") is executed twice in different places of the sequence, once for refreshing intercompany balances and once for refreshing account balances.
The forecast monitor shows a new status for scenarios with activated cross-company IC planning:
The runtime for setup of the table of the forecast monitor was significantly reduced especially for scenarios with many periods and many companies.
The number of companies is now restrictively checked against the number of licenced companies. No additional companies may be allocated to a scenario.
At definition of a new scenario now a new flag controls that intercompany balances planned in the scenario provide for a cross-company IC planning at the partner companies (see above). Then a profile has to be entered specifying the account allocations. In addition, you can specify with the flag "Accepted IC balances modify account balances of 'J' accounts" that the planned third party portion on accounts with account flag 'J' is not modified when accepting the cross-company IC planning.
The required entry of a group for a scenario with activated cross-company IC planning is new, too, for determination of the group currency. In addition, it serves for the preselection of the group parameter when branching off into the forecast monitor.
When creating a new scenario the period selection page now shows a combo box in the right bottom corner providing for selection of a reference period for position/account allocations from the periods contained in the scenario. Standard setting is the first period after the ACTUAL area. This entry cannot be modified after creation of the scenario.
Saving of a scenario, especially after deleting of many business cases, was significantly accelerated.
The entry of plan data is performed in report structure. For this purpose now the accounts are displayed with respect of the position/account allocations valid in a certain period. This period can be determined at definition of the scenario on the period selection page. The last period of the ACTUAL space of time is the default value. This is the setting for existing scenarios, too.
Please note that the new position/account allocation table K020 (see above) contains a validity range. Accounts without allocation due to validity restrictions in the period selected for structure definition are no longer present in the spreadsheet.
Intercompany balances accepted from the cross-company IC planning are locked in the scenario against splashing and modifications by the user. The account balance is locked for accounts with account flag 'I', too. Manual changes and single postings must not be applied. However, rules can be applied nevertheless. The locked accounts have the tooltip "Destination account of cross-company IC planning".
You can now distinguish between zero balances and empty values when refreshing balances. This is controlled by a new flag specified in the dialogue which is set to the method applied up to now (no distinction) by default. When setting this flag zero balances are loaded, too, and overwrite existing balances if present. This flag can be set as a planning parameter in Forecast sequences, too.
If balances are refreshed using the dialogue "Balance differences" then now manually locked cells are reported and the use can decide whether they shall be refreshed, too, or not. However, cells locked by a period or account lock are always refreshed without any request. For an additional automatisation of this refresh you can now lock or unlock cells already provided with a period or account lock.
The cross-company IC planning list is a view on all intercompany balances accepted or to be accepted by the company. It is a kind of balance difference list for the cross-company IC planning. This list is placed between the balance difference list and the plausibility check for scenarios with activated cross-company IC planning.
The table shows only allocations which provide for amounts for the actual company. Especially those allocations are not displayed which provide for intercompany amount from this company at other companies.
The follwing plausibility checks were supplemented with respect for the cross-company IC planning:
The dialogue for copying and distribution of amounts was built completely new. The new dialogue now offers the following features:
Settings of this dialogue can be saved similar to rule templates.
Functions for copying and distribution can be started by a Forecast sequence.
You can now choose for individual table sheet whether they are valid for all companies of a scenario or only for the company currently opened. A new check box in the menu item "configure" of the window "Table storage" serves for this purpose. If "Only for current company" is selected then this table is displayed for other companies with a corresponding icon and cannot be used. However, on demand a copy can be generated as a further table sheet.
A ratio rule now can be applied per intercompany analogously to the sales rule. For this purpose the intercompany details of the base value now offers the following options:
Except for "Account balance without IC details" the respective intercompany balance is used as ratio instead of the account balance. An additional page "Intercompany" of the rule wizard works like this page in other rule wizards.
The representation of positions with restrictions of a cash flow report was mistakable with respect to the value tag ('1' or '-'). This indication always referred to the value tag of the first entry in the restriction formula. Changes of the value tag on the first wizard page had no effect. Therefore now the radio buttons for 'P1' and 'P-' are disabled if a restriction formula exists. Lines with formulae containing plus as well as minus operators are displayed in the table with 'P1/-'.
A column for a b/s p&l code was supplemented in the table of report line descriptions. Here the b/s p&l code responsive for the sign of the displayed amounts inherited from superordinate nodes is automatically registered. This is performed at all changes by the applications "Report definition" (REPDEF) and "Report line descriptions" (REPZEI). A direct modification is not supported. This column is evaluated at construction of the OLAP cube (IDL.Datamart, see below).
Two new attributes were supplemented in the report headers (REP, REPK) controlling which position/account allocations are to be applied for report (see below). A period entry field serves for the specification of a period different from the actual period which is decisive for the valid allocations. A flag (entry 'X') controls whether the allocations valid in each period are to be applied for the respective period.
The standard reporting evaluates the new table for position/account allocations (K020, see above) for the construction of the report structure. You now have three variants:
The setting of the variant to be applied is controlled by new entry fields in the report header (REP). Without entries in these fields and thus all report headers already existing, too, remain in the "like up to now" variant.
Even (newly generated) cash flow reports are now provided with check sums. For this purpose check sums for account balances and development transactions as well as in case consolidation postings and controlling balances are calculated and save in the report header (REP/REPK). These check sums each comprehend all data independent from their consideration at report generation. Therefore it may happen that differences (status [red]) are reported although only data have changed which were not included in the report result.
In this connection it was required to introduce separate check sums for controlling balances and intercompany account balances (up to now save alternatively to the check sum for development transactions). However, a version number in the report headers provides for the display of old reports in the familiar way. Since intercompany account balances and controlling balances are never processed together, these check sums are displayed in a mixed column.
Group reports now can be generated for arbitrary facts on the level of the group chart of accounts provided an "ex fact" is specified (in the fact master data FAC or the start-up data VOR) and both facts refer to the same group chart of accounts. Then the group structure is always determined from the fact specified as "ex fact". A redundant maintenance of the group structure for report purposes is no longer required.
When mass-pdf-exporting report results now, in addition to report ID and version number, the further report keys (group, company, period, fact, detail option) are part of the generated file names. This not only facilitates the allocation of the generated export files but rather avoids that the files overwrite each other at export.
The import of position/account allocations was converted to the new database table K020 (see above). For distinction between old (table K023) and new formats the format definitions for the new table are registered with the import/export type "POSKTOP". The import table I117 replaces the previous table I107 for the import via database tables.
In usual interfaces the processing of delivered data is performed like in the dialogue function "Chart of positions" (POP). Already existing data remain, new data are inserted but a period as required for the valid-from entry. This can be specified explicitly as a parameter (e.g. in the calling application IMPORT), alternatively the actual period of the start-up data (VOR) of the user is applied. If allocations of the account to the position already exist but are valid yet from a later period on then the inserted allocation is limited accordingly.
The function variant "Delete + import ..." does not delete existing records (except for the record is yet valid from the actual period) but in case provides them with a valid-until period (actual period minus 1 month).
For copying of data 1:1 from one IDL.KONSIS database to another the explicit specification of valid-from and valid-until periods is possible, too, in the import file or the import table, respectively.
The application "Import IC-P/L-thereof-account balances" (TXTICKONV) in some cases generates position/account allocations for the newly generated accounts (with suffix 'I' in the account number). These allocations are provided with the actual period as valid-from period. In case a valid-until period is copied from the origin account.
The group-wide and the group/sub-group exchange of data have been modified to include various database enhancements. For this reason, they are not compatible with previous release versions.
To avoid foreign key violations due to missing fixed asset objects at loading of sub-group data the program for unloading recently had been modified in the way that group fixed asset objects (card type 'K') were always unloaded completely. In some cases this caused very long response times at unloading and loading of sub-group data. Now only those group fixed asset objects are unloaded which are referenced in the unloaded consolidation postings.
The MIS data preparation ("Create MIS data tables") was converted to the new table K020 for position/account allocations (see above). Here always the structure is applied which is valid in the leading period. This is the same period which is applied for determination of the group structure, too.
The interface to IDL.DESIGNER (IDL.Datamart) was converted to the new table K020 for position/account allocations (see above). Here always the structure is applied which is valid in the leading period. This is the same period which is applied for determination of the group structure, too. A historical view of the reports is not supported for the present.
The database views for unloading of consolidation postings were supplemented by a column for the flag of effect on the net result from the consolidation voucher (K048).
The construction of the data cube (IDL.Datamart) was accelerated by evaluation of the b/s p&l code of the report line descriptions (see above).
From release 2016 on IDL offers a standard interface named "IDL Smart Connectivity for SAP" for the transfer of data relevant for consolidation from SAP to IDL.KONSIS. This interface is based on the Netweaver technology and thus on the most recent technology for unloading of data from SAP. IDL Smart Connectivity for SAP is available for the old general ledger as well as for the new general ledger. It is a proprietary development of IDL which allows our customers the highest flexibility and extensive automation of the transfer of structure (chart of accounts, companies, ...) and transactional data (account balances, intercompany balances, development transactions, ...) in interaction with the Microsoft Integration Services. Within this it is assured that the SAP system guidelines with respect to authorisations and CTS (Change and Transport System) are followed completely.
The solution has been certified by SAP.
Of course, Interfaces from SAP to IDL.KONSIS realised in the past at our customers which were implemented based on IDL.IMPORTER and SAP Connectivity can be used continuously. We emphasize our customers to check for migration to IDL Smart Connectivity for SAP.
If you are interested in the new SAP interface please contact the IDL hotline or your contact person in the IDL sales.
The release 2017 contains the current edition of the DCW interface for DCW release 3.50.