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 2018 Update 1 the migration program will complete the following transformations in the database:
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 can be used as a template.
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:
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 following menu idents are finally deleted with Release 2019:
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.
The check for the number of users per licence class was revised in the way that unexploited licence places for full users can be calculated with the number of user places for other licence classes. E.g. if you have the licence for 10 full users and 20 light users you can define 5 full users and 25 light users, too.
Entries for the licence user types FORECAST or XLSLINK, respectively, are now reported as an error if no licence for IDL.FORECAST or IDL.XLSLINK, respectively, is present.
The action "Mass-update" was supplemented in the application "Users"(USE). It is especially helpful for the update of licence classifications which can be deleted by the entry of '*', too.
The standard user groups for the former IDL.KONSIS product variant IDL.WINKONS were dropped, i.e. they are replaced by the corresponding IDL.KONSIS standard user group:
| WINKONS | KONSIS |
|---|---|
| IDLWIN | IDLKON |
| IDLWIN1 | IDLKON1 |
| IDLWINAD | IDLADMIN |
| IDLWINEA | IDLEA |
| IDLWINEE | IDLEE |
| IDLWINSA | IDLSYS |
| IDLWINVW | IDLVIEW |
In case that an IDL.WINKONS user group has been used as user group for data authorisation, too, and the corresponding IDL.KONSIS user groups were used as user groups for data authorisation, too, new user groups are generated which can be distinguished from the IDL.KONSIS user groups by a preceding '$' character, e.g. 'IDLWINEA' -> '$IDLEA'.
The allocations in the user table (USE) as well as in individual user groups (BENDEF) are adjusted correspondingly.
Just like in IDL.FORECAST (see below) and already for rule templates scenarios are now represented in the tables for user group authorisations as a tree table with folders. Correspondingly changes on the authorisations for folders (nodes of the tree structure) are inherited by the sub-ordinate scenarios.
The display option "Hide empty columns" no longer has an effect on columns without content if cells in this columns are provided with a coloured background. Beside others this can apply for missing parameters (intercompany, posting key, controlling objects) in postings.
If you select several cells in a displayed table, then the footer line of the application window shows the total of the selected amounts. This functionality is now supported for values with more than 2 decimal digits, too, e.g. for percentages in shareholding transactions.
You can now select the printer in a dialogue on its own without immediate start of printing. This dialogue has the button "Page setup" which allows for a branch into this dialogue. There you can configure further properties (e.g. size, alignment) for the selected printer which were not available for the preselected printer.
For the purpose to distinguish Excel files generated for different parameters, e.g. account balance lists for different companies, the file name proposed in the file dialogue of Excel export was supplemented by the indication of the keys each separated by an '_' (underscore). Thereby all entries in the selection areas (except empty) are treated as keys. Characters not allowed for file names (e.g. '%') are replaced by '_'.
When exporting data of a table to Excel now the entries in the selection area (if present) can be exported along providing for an allocation of the table data to the respective keys. For this feature it is required that the new flag "Export selection area" on the page "Import/Export" of the "Options" dialogue is set. Then the data of the selection area are output on a separate sheet of the Excel file.
Complex master data applications with a leading and one or more dependant tables now offer the opportunity to display data of several objects of the leading table (e.g. accounts of several charts of accounts, posting keys of several transaction developments) simultaneously and to edit them. For this purpose you have to select several lines in the leading table before triggering the "Open" action (eye icon). This enhancement provides for the following changes:
In Release 2019 this extension is available in the following applications:
Further applications are planned for the following Release.
Messages in the lists of Open tasks are now distinguished between errors and notes. Errors are displayed in red colour at the beginning of the list and prevent saving. However, if only notes (black colour) are present saving is possible.
A double mouse click in the line of a table with master data usually provides for opening of the wizard for changing the data record. Now additionally the column is evaluated at double mouse click providing that the corresponding wizard page containing the entry element for the column is displayed and this entry element is focussed.
The fact master data were extended by a flag for carry forward of intercompany account balances (see below). This flag can be set on the page "Options for Balances and Details" of the wizard.
Furthermore the fact master data were extended by the entry opportunity of currency codes for group and parallel currency (see below).
The check for compliance of the licence limits for the number of historical companies was dropped since no licence is required for historical companies as far as no more data are entered for this company and no processings are performed for this company.
The check for the number of companies per licence class was revised in the way that unexploited licence places for full companies can be calculated with the number of company places for other licence classes. E.g. if you have the licence for 30 full companies and 10 reporting companies you can define 20 full companies and 20 reporting companies, too.
Now numbers of up to 50 can be specified in the field "Column for forms data entry" for posting keys (see below).
At least one transaction development column and one posting key for carry forward have to be defined for classified transaction developments (fixed assets, capital, provisions, shareholdings). Otherwise a message in the list of open tasks is output.
The period in the selection area of the page "Position account allocations" is no longer preselected with "Actual period" of the startup data (VOR) but rather with the "Valid from" period of the startup data as far as it is provided with a different value. Correspondingly the prompt text of the field was changed into "Valid from / in".
If an allocation is inserted per drag&drop in a period and the same allocation (position, account, D/C flag and controlling flag) valid up to the preceding month already exists, then no new data record is inserted. Rather the existing record is updated by removing the valid-until specification und thus omitting double data lines.
Selected node lines (positions) are now ignored at mass-update, e.g. for adding a debit/credit control, providing that now greater amounts of lines can be selected incl. their node lines.
Double allocations of one account to the same position in the same period provide for the output of double amounts in report results. Therefore double allocations are now reported as a strong error in the list of open tasks and prevent saving this state.
It is now reported in the list of open tasks if a position with position type 'OS' or 'OP' (without account allocation) has allocated accounts.
The resource table on the right hand side shows accounts in different font colour: [black] for accounts not yet allocated, [grey] for accounts uniquely allocated, [red] for accounts ambiguously allocated. A new button in the toolbar of the table provides for a filter by colour. Mouse clicks on the button set this filter one by one to "only black lines", "only red lines" and "all lines". Thereby the icon (stylised table) changes its colour correspondingly.
The column K010_KONS_VERARB for the consolidation function / voucher classification was replaced by the column "K010_K047_KVA in the database table for accounts (K010) (see below). The software delivered by IDL (e.g. IDL.FORECAST, IDL.XLSLINK, IDL Datamart views) were adjusted to this replacement. However, customer specific interfaces have to be adjusted by the customer.
The list "Accounts" (KTO) with the sort option 'K' now displays the columns "IC detail type" and "IC detail check" for the allocated group account. On the other hand the allocations to controlling dimensions of the allocated group account are no longer output since they are always identical to the allocations of the company account. In addition, the order of the columns was revised providing that all attributes of the group accounts are positioned behind each other. Further attributes of the group account can be displayed using the display option "show internal info columns". If using the sort option 'Z' all displayed attributes are output for the company account as well as for the group account.
It is now possible to specify dates for the submission of company financial statements. A new application "Submission dates" (short word: ABG) serves for the administration of these dates. Without additional restrictions this application shows the specified dates for the preselected parameters (period, fact). These dates apply for all companies.
Beneath a general submission date for all data it is possible to specify deviating dates for single data stocks, e.g. earlier dates for intercompany account balances for the purpose of premature IC clearing. In addition to the proper data stocks you can select the checkpoint "Hard check rule results" (PRFERG-H) to specify a date on which these check rules have to be fulfilled.
In addition to the submission date you can specify a warning time in terms of a number of days before the submission date when the user shall be pointed out to the imminent date. You have the choice to define a number of calendar days or a number of working days. In the latter case weekends (Saturday and Sunday) are not calculated. This is useful, if the data are carried forward into the next period. However, holidays are not considered since they are different in countries and regions.
The application ABG has a selection area where the preselected parameters for period and fact can be modified. You can select data of an interval of periods by entry of a "from period". On the other hand you can leave all parameters empty to select all defined submission dates.
For the purpose of monitoring the submission dates the "Company financial statements monitor" (EA) or the "Company financial statements monitor for entry" (I-EA) were extended by a column showing the submission state. This column is displayed only if submission dates have been specified for the current period and fact and the first warning time has been reached. For this submission status for all displayed columns relevant for a submission check with data status not equal to [green] or [-] the submission date and the warning time are determined and compared with the current date. If the submission date is exceeded then the submission status becomes [red]. If the current date is equal or less than the number of days before the submission date, then the submission status becomes [yellow]. The total status is the worst status of all data stocks.
An exception was made for account balances since (except for facts without account balances) these data always have to be present. Therefore the check of account balances is performed at data status [-], too. Excepted form this are companies with a merger date not situated in the future as well as companies consolidated at equity. However, the latter can only be determined if the companies are selected by specification of a group/sub-group.
A double mouse click on the column for the submission status provides for a branch-off into the new list "Company closing dates stmts + monitor" (EAABG) or "Company closing dates stmts + monitor for entry" (I-EAABG). Here the submission date is displayed per data stock as well as its submission status by a background colour so you can see which data are missing or have to be delivered in a short-term. A double mouse click on one of these columns provides for a branch-off into the corresponding list (at EAABG) or forms entry (at I-EAABG) application, respectively.
The lists for detail data of account balances no longer display error lists for errors which can be visualised by coloured table cells. However, other applications which check the data but don't display them (e.g. after import of these data) continue to report these errors in a message list. Deviations from this rule have been cleaned up.
The lists for detail data show data for companies consolidated by quota with their proportional amounts as well as the corresponding account balances providing that a difference is displayed with its proportional amount, too. A double mouse click on the difference amount opens the single record application to clear this difference. However, in this case only the proportional difference is offered for clearing and thus does not provide for clearing of the total difference. Therefore it is recommended to use the 100% representation for clearing of differences without specification of a group.
When inserting the first data for a new data space [period, fact, company] the currencies (local, group and parallel) are determined and recorded in the processing control (VERARB). For this purpose up to now the local currency was evaluated from the company master data (GES) as well as the group and parallel currency from the group master data (KTKDEF, as far as a group had been specified) or from the user's startup data (VOR), respectively. Group and parallel currency now can be specified alternatively for the fact (FAC). Then this entry has priority in front of group and startup data. This allows for the following advantages:
Because of these advantages the entries of group and parallel currency code in the group master data (KTKDEF) and in the startup data per user (VOR) will be dropped in one of the following releases. Therefore it is recommended to maintain the currencies per fact now even if they are unique in your group.
Totals of statistical amounts (b/s p&l code '%') which e.g. are displayed using the sort options 'GZ', 'VG' or 'ZG' are usually provided with a debit/credit flag. However, if there is at least one account balance without debit/credit flag then the total is displayed without debit/credit flag, too. Thereby debit amounts are calculated as positive values while credit amounts are calculated as negative values.
The entry of an amount 0.00 in transaction currency now is permitted again since this amount can result by rounding of very small amounts in local currency. In addition the amount 0.00 had been permitted for postings providing for corresponding intercompany account balances at transfer to the next fact. However, this amount may not remain empty if a transaction currency code has been specified.
You have now the opportunity to carry forward intercompany account balances into the next period, i.e. to copyy them. Thereby especially the statement for clearing (reference voucher number and date, clearing flag greater than 1) are copied along providing that unchanged issues don not have to be cleared again. This functionality is useful for customers which transfer intercompany account balances on the level of single vouchers and clear them accordingly so that a clearing for the repeated data has not to be repeated.
This functionality is controlled by a flag in the fact master data (FAC). If a deviating source fact is specified, the carry-forward is performed only if the flag is set for both facts. A new column in the list "Intercompany account balances" (ICKTOSAL) shows a flag which specifies data carried forward.
Carry forward of intercompany account balances is performed within the regular carry-forward function of company financial statement data over the cast of the year as well as starting from an annual statement, however, the latter only for b/s data. When carrying forward starting from an annual statement intercompany account balances are aggregated per reference voucher number. No data are written if the total per reference voucher number is zero since it is assumed that the issue is closed. Intercompany account balances already carried forward before are overwritten at repetition of the carry-forward while data supplemented in the actual period are preserved. You can invoke an isolated carry-forward of intercompany account balances using the calling application "Select carry-forward into new period" (PERGES). If you want to invoke this step in an automate control you have to specify the menu ID 'PERGESICK'.
The function for import of intercompany account balances with previous deletion of existing data (TXLICSALD) evaluates the carry-forward flag in FAC, too. If the parameter "with carry forward" is not set, then only data are deleted which were not written by carry forward.
The same applies for the transfer from a source fact. When transferring data to a fact with the carry-forward flag set the intercompany account balances carried forward are only deleted if the flag is set in the source flag, too, and if the function variant "Delete and create carry-forward" had been used. If the transfer is performed using the option 'maintain carry-forward' the intercompany account balances carried forward on the source fact as well as in the destination fact are excluded from execution.
The previous branch off into the dropped application "Controlling objects" was replaced by a branch off into the application "Controlling definitions" (CTLDEF). There the model for the respective chart of controlling objects is automatically opened and the line for the respective controlling object is focussed. This applies for the list "Controlling balances" (CNTSAL) as well as for the joint forms entry application (I-CNTSAL).
Missing controlling objects (account is allocated to more controlling dimensions than specified in the controlling balance record) are now represented with a red background colour of the cell.
If the fixed asset transaction development is defined as an automatic transaction development and a fixed asset account simultaneously is a participation account, then now fixed asset transactions for changes in the actual period are automatically generated if participation transactions have changed. This analogously applies for other automatic transaction developments. Up to now the generation of the development transactions was yet performed within a later status refresh.
Now up to 50 columns with different posting keys can be displayed and entered in the forms entry applications for development transactions (I-xxxBEW). For this purpose you have to provide the posting keys of the respective transaction development in the application "Transaction development definition" (SPIDEF) or "Posting keys" (BSL) with a number between 1 and 50. Up to now a maximum of only 30 posting keys could be designated for entry.
Check sums were supplemented for shareholding transactions. Similar to other check sums there is one check sum per company, business unit and currency. Beneath the keys (company, business unit, intercompany, IC business unit, account number, posting key) and the amounts (local, group or parallel currency, respectively) some attributes relevant for consolidation (transaction date, shareholding percentages, disposal information) are considered for calculation of the check sums. Check sums are displayed at the end of the list "Participations / shareholding transactions" (GESGES).
Check sums for shareholding transactions carried forward are calculated, too, which are displayed in the list "Processing control" (VERARB) just like other check sums for carry forward. The checkpoint 'VOR-B' has been established for this purpose.
Just like for other data stocks changes of these check sums affect the status displays for check of carry forward to new period, check transition to new fact, check rule results and currency conversion. If applicable, thus these status information changes even if only percent values are modified in the shareholding transactions.
The previous "Processing tag" was abolished since the information about the consolidation of the data record can be recognised by the entries of group and consolidation voucher number.
Missing controlling objects (account is allocated to more controlling dimensions than specified in the posting record) are now represented with a red background colour of the cell.
The function variants for transition were extended due to the usual use and differently named. Henceforth the following three variants are available:
These variants can be selected after the action "Select transition to new fact" (application GESABV), too.
Some extensions of the data model provide for the preconditions to define consolidation function keys with more than two characters in the future. Currently there is only the effect that the consolidation function entries in the account master data (KTO, see above), in the consolidation parameters (KTKPAR) and in the IC clearing records (KGESGES) yield a foreign key reference to the KVA master data. I.e. a KVA record no longer can be deleted if the KVA key is still used in one of these tables.
It is now possible to enter a percent value for the multiple capital participation manually which superimposes the percentage calculated by the function "Check & refresh participations". The wizard of the application KTKDEF as well as the single record map KTKGESE were extended by a corresponding entry field. This entry especially helps in constellations, where the calculation of participations does not yield plausible values, like e.g. in case of recursive shareholdings (up to now here a percentage of 0.00 resulted), to gain correct minority interests.
A percentage manually entered this way not only modifies the multiple capital percentage of the company itself but rather is used for calculation of multiple capital percentages of associated companies, too.
The group monitor (KTKGES) continues to display only one amount for the multiple participation percentage exhibiting the effective amount used for calculation of minority interests. In addition, the values are designated as follows:
Because of this modification now a new calculation of the participations is automatically performed at each call of the group monitor providing for always actually calculated percentages. However, problems (like recursive shareholdings) are not reported in this automatic run. This only happens in explicit calls of the participation calculation clicking on the percent icon.
Because of this automatic it may happen that a user is registered as the user of the last modification with a current timestamp when starting the group monitor (KTKGES) if e.g. a shareholding transaction for a company had been changed.
The additive capital percentages for quota-consolidated companies are now displayed in the same way as the multiple capital percentages in case that the calculated value has been superimposed by a manual entry. Thus there is no longer a separate column for the manually entered quota percentage. Rather a manually entered value is displayed in the column for the additive capital percentage and represented with a yellow background for distinction.
However, the table "Group companies" of the application KTKDEF continues to display separate columns for the manually enterable percentages providing for a direct comparison of calculated and entered values.
Theshold values henceforth can be entered as percent values, too. This specification can be entered alternatively to the threshold value amounts in the respective consolidation parameters. Separate entries are provided for group and transaction currency.
The following formula is applied per clearing group for the evaluation at consolidation D&C and P&L:
Both amounts result from the summation of all debit or credit, respectively, amounts of a clearing group. A clearing group consists of the data per voucher classification (KVA) and if applicable per combination business unit / IC business unit and per transaction currency. In addition the setting of the flag "Cumulate differences" is considered. Attention: These amounts are not the amounts displayed in the "IC clearing list" (KGESGES)!
Apart from this the consolidation D&C and P&L act like for specification of threshold values as amount: Differences below the threshold amount are eliminated by a posting on the threshold value account, however, larger differences are eliminated by a posting on the difference account if defined or remain for later clearing.
As far as intercompany account balances are specified detailed by original vouchers and contain a reference voucher number, then the reference voucher number is saved in the eliminating consolidation posting and displayed in the list KONBUCH as well as in the log list KONBUCHLOG if applicable.
If two companies with the same local currency report intercompany account balances matching in local currency but exhibiting a difference in group currency, then this difference is no longer treated as difference but rather as an exchange rate effect and eliminated correspondingly. However, opposite to difference clearing via transaction currency no threshold values are considered here but local currency amounts have to match exactly.
It is now checked whether the currency calculation has been performed successfully for all considered companies before one of the actions "Rerun consolidation I&E" (Group monitor), "Rerun consolidation D&C" (Group monitor) or "Refresh ic-clearing" (IC clearing list) is performed. Existing data are only deleted and newly generated if this check was successful.
The closing balance sheet of the disposing company is eliminated at deconsolidation providing that all balance sheet account balances as well as their transaction development details (posting keys) result to zero from the group's point of view. Now additionally controlling details of balance sheet account balances are considered.
Since the company financial statement data do not contain a link between transaction development and controlling details, this consideration is performed by additional postings which effect no change to the totals per account and posting key:
Without usage of controlling details in the balance sheet nothing changes.
Since consolidation vouchers from the consolidation P&L ('AE') have to be carried forward ('AV') with respect to the result contribution of each company (as far as no neutralisation account is specified), a deconsolidation of these vouchers is required, too, even if the voucher contains only postings on P&L accounts or on the carry-forward account with account flag 'X' which are not directly eliminated. By the way this applies for other voucher classifications (e.g. manual vouchers), too.
In these cases now the deconsolidation continuously does not eliminate any consolidation postings but rather the result contribution per company by postings on the result account of the consolidation parameter 'XK' or 'YK', respectively.
If postings or consolidation postings for the first entry or carry forward of at-cost transactions contain specifications of controlling objects, then these specifications are entered into the generated depreciation postings on the fixed asset account or the account for accumulated depreciation. Up to now this was performed only for the first controlling dimension. Controlling objects for the dimensions 2 to 10 are transferred into the counter posting on the depreciation account, too, as far as it is allocated to these dimensions. However, for the first dimension a controlling object specified in the fixed asset master data or in the corresponding consolidation parameter is used with priority.
For check rules with the clause "per intercompany" you can now distinguish whether the data for third parties (data without specification of an intercompany) shall be considered (up-to-now solution) in the check rule result calculation or not. This especially applies for intercompany balances on accounts with IC detail check 'A' or '-', since (opposite to e.g. development transactions) no data without intercompany exist.
If the check shall be performed without third party data, then an additional check box in the wizard of the check rule definition (PRFDEF) can be selected. In the check rule application PRF the flag "per intercompany" has to be set to 'O' instead of 'X'.
The authorisations within the planning application now consider the classification of the user for IDL.FORECAST in the user administration (USE). Thus e.g. a user classified as "Light user" must not create, modify, rename or delete scenarios, rule templates or individual tables, save any rules or create a liquidity report.
A larger dialogue has been developed for the entry of descriptions which allows for the display of longer texts. This concerns the creation and renaming of scenarios, rules, copy profiles, folders for scenarios, rule templates and table storages as well as profiles for cross-company IC-planning.
Just like rule templates now scenarios can be administrated in a folder structure, too. I.e. you can define scenario folders and allocate scenarios to these folders. The structure may consist of several levels. The scenarios are correspondingly displayed in the scenario window in tree structure. Therefore the tool bar of this window now contains buttons for expanding and collapsing of all nodes.
A new function in the context menu of a scenario or a folder allows for hiding the subordinate details (companies / scenarios / sub-folders) if they shall not be edited for a longer range of time. Then the data still exist yet, however, they are visualised only by a placeholder. An item of the context menu and a double mouse click on the placeholder serve for the display of the hidden elements.
The action menu contains a new menu entry for the export of account changes into separate database tables (see below).
Now locks are set when changing, moving or deleting tables, folders or reports in the table storage which provide that these data are not parallelly edited by another company. This prevents that different companies (users) simultaneously modify company comprehensive tables of the scenario and thus mutually overwrite their modifications. Then individual table sheets which are not specific for a company are not editable until they are explicitly unlocked. Unlocking is only successful if the table is not yet edited by another company. Locks are reset when closing the scenario.
Like already up to now for account balances it is now supported to provide intercompany account balances and controlling balances with a comment. In addition, the context menu (right mouse key) offers the opportunity to provide the cells with a coloured background. The colour can be individually selected in a colour chooser dialogue for several cells in one step. For locked cells this colour is displayed slightly darker.
For account cells, which are locked because of the entry flag of the account per period type ('M', 'Q', 'J'), the b/s carry-forward is no longer eliminated by an automatic change. Furthermore no rules may be applied for these cells and MSAL or MIC formulae on these cells provide for an error message.
The account with the account flag 'U' (result compensation per business unit) now always is inserted into the planner spreadsheet although the entry flags per period type are not set. However, balances on this account are only transferred for the ACTUAL providing for a check block without differences.
You can now call the function "Drill through" (SQLQUERY) out of the planner spreadsheet via the context menu. "Drill through" serves for the display of data from an external relational SQL database. For display of the desired data (available are account balances and intercompany account balances) a corresponding "Drill through configuration" (SQLCONF) has to be defined.
The wizard for copy profiles now offers the possibility to distribute source balances to the destination periods using a predefined distribution. This distribution either can be entered directly in the wizard or can be specified in a referenced parameter. The amounts can alternatively be specified as percentages or as weighted portions.
Like up to now already for companies it is now possible to restrict rules to certain combinations of company and business unit. For this purpose now additionally you have to enter the business units in the company control.
For rules with the setting "Apply rule only to existing IC balances" without corresponding intercompany balances no longer a message due to missing IC preselection is output but rather a message due to missing intercompany balances.
Plan parameters now can be exported and also re-imported again. The export is performed in a csv format providing that the export file can be edited, e.g. with MS Excel, and then can be re-imported to IDL.FORECAST.
Similar to the solution for the cross-company IC planning overview now there is an icon in the tool bar for the results of the plausibility checks providing for a copy of the table into the clipboard. Then e.g. you can copy the table into an Excel sheet.
The representation of the changes of an account and its details was revised:
The context menu of the Forecast monitor contains a new menu entry for the export of account changes into separate database tables (see below). This export can be inserted as astep in a Forecast sequence, too.
Usually the allocation of report lines for addition into a total line is performed on page 2 of the wizard for report lines. This can be cumbersome especially if the lines to be allocated are distributed over a great range of the report. Therefore you now have the opportunity to specify the entry "Amount into memory" when editing in the table or to change it, respectively. Hereby you can select all memory numbers which are used as "Amount ex memory" behind the current line. Mass-update of "Amount into memory" is supported this way, too.
The action mass-update is now available for the restriction attributes, too. If you apply this action on this column, then the third page of the wizard opens. Then the restrictions entered there are applied to all selected lines. This extension is especially interesting for cash flow reports where the same restrictions by transaction development column or posting key have to be applied to a great number of report lines.
Now at mass-pdf-Export of report results the print format (portrait or landscape) specified in the report header for the respective report is applied. Up to now all reports were printed in the print format preselected in the print preview.
Similar to mass-pdf-export you can now use a new functionality for mass-Excel-export of report results. For this purpose you have to select several lines in the report list (REP or REPK) and call the new action "Mass-Excel-export". Then for each selected report the report result list is opened in the background with the preselected standard view settings and a corresponding Excel file is generated. The usage of the keys (report ID, version number, company or group, period, fact, details option, column option) for the file name provides that the Excel files do not overwrite each other.
The "Account for capital consolidation" in the selection area of the application "Split for group/sub-group report" (REPKTK) has been dropped. It had to be assumed that this account was not used since it did not work correctly since Release 2014.
New import applications were established for the following data stocks:
The corresponding list applications (RPG, REP/REPK, BKL, CK1, PRODAT, BSLUAW, LTK or OSV, respectively) export data in the respective standard TXT format, providing that these data can be re-imported directly. An import variant with previous deletion of exiting data is only available for object sort settings column allocations (TXLOSVSP). For the time being no import tables ('I1xx', format type '#DB') were established but can be supplemented on demand.
For facts (FAC) and periods (ABR) each an import/export format (#TXT) was defined used by the applications FAC and ABR, respectively, for export as a standard. These formats will be used by future import applications for these data, too.
The import/export formats were adjusted to the actual database extensions:
The import of position account allocations (TXTPOSKTO) was modified to work like the dialogue function POSDEF (see above) such that without specification of a "valid-from period" in the data record itself the period specified in the selection area is used instead. If this field is empty the valid-from period of the user's startup data (VOR) is used with priority to the actual period of the startup data. If only a "valid-until period" is specified, then an existing record is restricted in its validity, if applicable. Since the actual period is preselected in the selection area of the application IMPORT and then is transferred to the import application as a parameter by standard, this modification merely concerns automatic interfaces.
The action "Delete + Import..." for import of position account allocations (TXLPOSKTO) now requires the unique specification of a chart of positions and a chart of accounts. Then all allocations between accounts and positions of these two charts are deleted from the period specified as parameter on. I.e. all existing data yield the entry of a valid-until period one month before the specified period (like in the dialogue application POSDEF) providing that all historic allocations are maintained. If applicable already existing allocations but valid only in the future are deleted completely.
When inserting the import data they yield a validity from the specified period on. If the allocation is identical to an allocation already existing but with a limited validity due to the previous delete action, then data records are combined to one record with a correspondingly longer validity. As far as no valid-until specification is contained in the data record the allocation is unlimitedly valid. This applies as well for import without previous deletion.
The action mass-update was supplemented in the application "IE Job Control". This can provide for modification e.g. of the setting of the delete option or the specification of the origin for several jobs in one step. Earliest start timestamp and origin can be deleted, too, by entry of '*'.
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.
Up to now IDL.FORECAST data could be exported only via IDL.KONSIS. Thus only account balances and their detail data were available for the access by BI interfaces.
Now it is additionally possible to access IDL.FORECAST specific data, namely the account changes. For this purpose the database view K87181 has been established in the IDL.KONSIS.FORECAST database.
The data are exported using a new menu item in the action menu of the planning application (PLAN). In addition, account changes can be exported using the context menu of the Forecast monitor (PM) or a sequence step of a Forecast sequence (PA), too. Basically this action exports all data not empty and not equal to 0.00 of all FORECAST and PLAN periods. Changes with the amount 0.00 are exported, too, if the null/empty differentiation is activated. Please note, that this table always contains only data of exactly one scenario. I.e. the export for one scenario overwrites the data of another scenario exported before.
Two additional database views allow for the selection of account changes in connection with the account balances (view K87182) or the intercompany account balances (view K87183), respectively.
Parameters of version '04' (IDL Datamart) now offer an additional setting "Sign control" which controls the positive or negative representation of amount in reports depending on the b/s p&l flag of accounts and positions and the debit/credit flag of the data. This setting also controls the debit/credit flag of amounts entered in IDL.DESIGNER and exported to IDL.KONSIS. Three variants are available with variant 1 being the setting valid up to now and preselected by the release migration:
| B/s p&l code | Variant 1 | Variant 2 | Variant 3 |
|---|---|---|---|
| Assets (1/6) | D positive, C negative | D negative, C positive | D positive, C negative |
| Liabilities (2/7) | D negative, C positive | D negative, C positive | D positive, C negative |
| Income (3/8) | D negative, C positive | D negative, C positive | D positive, C negative |
| Expenses (4/9) | D positive, C negative; opposite for data entry | D negative, C positive | D positive, C negative |
In some cases not yet identified the database tables K056 and K057 for representation of the group structure and the group companies for processing by IDL Datamart and transfer into the OLAP cube of IDL.DESIGNER are not correctly filled. Now a workaround for this problem has been established. The action "Generate Datamart tables for all group companies" was supplemented as the last entry in the action and context menus of the application "Group monitor" (KTKGES). This action provides for a complete refresh of these database tables independent from the current selection.
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.
You find the documentation of the changes on "IDL Smart Connectivity for SAP" in a separate document in doku \ Interfaces \ SAP \ Neu_im_Release_2019_deu.pdf.
The Release 2019 contains the current edition of the DCW interface for DCW release 3.50.