The 2011.1 release includes changes and enhancements to the products IDL Konsis , IDL Forecast and IDL Connector .
The IDL Konsis 2011.1 release is an interim release; therefore it may be left out of the release sequence. The minimum requirement for this release is the last IDL Konsis 2011.0 major release dated August 8, 2011.
The amendments and corrections that have taken place up until the release closure for the major release IDL Konsis 2011.0 are contained in this interim release.
You should always perform a database backup before you install a new release. To prevent a user from losing data, a notice on the necessity of backing up data will be issued by the installation program at the start of installation.
You must always perform release migration (see ch. 2.1) first after a new release has been installed. For this reason, a message will be issued when you start IDL Konsis for the first time to let you know that migration has not yet taken place. This message box has now been expanded to include the button 'Start migration now'. If you press this button, migration will start automatically. Following successful completion of migration, IDL Konsis does not need to be restarted again. All of the applications will be available immediately.
If migration is not started in this manner, for instance because the logged in user does not have access rights, all other applications will be locked. The only exceptions are the applications that are used to maintain authorization data, in case the logged-in user is not authorized to carry out migration, due to the use of individual authorization groups. Following manual completion of migration, you will need to start IDL Konsis again to ensure that all of the application functions are available again.
Group development transactions used until release IDL Konsis 2007.1 (data in the development transaction table redundant to consolidation postings) are no longer available with the standard IDL authorisation groups since the authorisation for the corresponding menu items (KONANLBEW, KONKAPBEW, KONRUEBEW) had been withdrawn. On demand you can grant this authorisation to individual authorisation groups.
The application IDL Forecast requires a main storage of 1 GB. However, in many cases only 256 MB or 512 MB are adjusted. Please check your adjustment for the parameter "-Xmx" in the link of your IDL Konsis icon.
The html assistance that we know from experience wasn’t used very often is no longer included in the release CD or the installation directory provided for downloading since the 2010.1 release. If necessary, however, it can be ordered from the IDL hotline or downloaded from the service area of the IDL website. As usual, the help texts contained in the html assistance are still available online inside the application.
Additional functions that require at least the MS Excel 2003 version are available in the development for the Excel interface IDL Connector of IDL Konsis . For this reason, we recommend upgrading to MS Excel 2003 or, even better, MS Excel 2007.
The import table I106 for positions (POS) and column descriptions (SPA) has to be completely dropped and newly defined due to database updates (see below). Thus please assure before installation of this release that no unprocessed data exist in this table.
When you start IDL Konsis 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 has now been expanded to include the button ‘Start migration now’. Migration will start automatically if you press this button. Following successful completion of migration, IDL Konsis does not need to be restarted again. Instead, all of the applications will be available immediately.
The migration program will also complete the following transformations in the database:
The following menu IDs are new or include new authorized actions in this release. If completely maintained customer-specific authorization groups are used, you might need to enter access rights for these menu items (BENMEN). In most cases, the menu authorizations of the user group IDLKON and/or IDLWIN can be used as a template.
The Simplified Procedure for Administration of Customer Specific User Groups is recommended as an alternative to complete maintenance of authorizations for all menu items. For this functionality, the new authorization level '0' can also be specified for menu authorization (BENMENE). This says that an authorization available for a reference user group should not be issued for the user group that has been entered.
Older release documentations "Release ... News" (older than 2008.1) have been removed from the menu tree. On demand you can catch up these documentations in the list "Menu items" (MEN) with the menu IDs "RELxx.y".
The parameter for "ex fact" supplemented in Release 2011.0 in the application "Menu structure allocation" (MENMENE) now is also evaluated if a company related processing is to be replicated for all group companies, i.e. if the company parameter is specified as '#KTK' or '#KTKN'. Then the "ex fact" is used for determination of the group companies. For all other entries for the company "ex fact" is transferred as a parameter for the respective application like before.
The function for copying table contents to Excel or other applications (copy and paste via clipboard of the operating system) now maintains the follwing formattings:
In addition selected table contents now can be directly exported into an Excel file. A new icon in the toolbar as well as a new menu item <Export to Excel> in the menu <File> serve for this purpose.
After starting this function a file dialogue opens where you can specify path and name of the Excel file. A new Excel file is created with these specifications and all selected table contents are automatically inserted into the first page of this file. This Excel table contains all formatting of the copy/paste (see above) and in addition:
All entry masks for selection areas of lists as well as for single record applications contain a sequence of buttons at the bottom. The last of these buttons displayed up to now the text <Continue> or <End> depending on the position in a sequence of chained applications. Now this button can be labelled with <Back>, too. The text has the following meaning:
Newer applications (e.g. SPIDEF) do not have a selection area with the display of these buttons. Therefore corresponding buttons with icons had been supplemented being displayed right-aligned in the menu line:
These buttons can be used alternatively to the previous buttons in other applications, too, and display the respective texts as tooltips.
A new icon with a crossed out funnel is now displayed next to the icon with the funnel symbol for switching the filtering row on or off. Pushing the new button erases all entries in the filtering row providing the display of all data originally selected. Opposite to this button all entries in the filtering row are maintained when switching the filtering row off and on again.
The summation function can now be applied on additional tables and columns, even data without allocation to a debit/credit flag (e.g. differences in the IC clearing list). However, the report result table is furthermore excluded since the displayed values with positive or negatvie signs cannot be reasonably added up without a debit/credit flag.
The colour of the parting lines of tables can now be determined with the colour dialogue of the options, too, e.g. for replacing the striking black by a brighter shade of grey.
An attribute for the "ex fact" was supplemented in the table for facts (FAC). This allows to allocate an "ex fact" for each fact if group statements are produced on different facts (e.g. HGB statement on 'I4', IFRS statement on 'I6', plan statement on 'P4'). The entry of an "ex fact" in the fact master data has priority compared with the hitherto existing entry in the user specific start-up data (VOR) at selection of reported data for all group companies on upstream facts.
The selection boxes for entry of an "ex fact" in several applications now offers only facts with the chart of accounts flag 'K' (facts on the level of the group chart of accounts).
If you enter a merger date in the company master data (GES) then automatically the valid-until period of the company is set (to the end of the following year). This control is now active for later updates of the merger date, too.
A new account flag 'T' has been invented for designation of difference amount interim accounts. Only accounts with this account flag may be entered as a difference amount account in the consolidation parameters. The release migration program provides all accounts already specified as a difference amount interim account in a consolidation parameter with this flag.
The account flag 'J' means that the account balance contains partly IC issues and therefore is only partly explained by intercompany account balances. Therefore you can allocate accounts of a company chart of accounts with account flag 'I', 'J' or without account flag to a 'J' account of the group chart of accounts. Independent from this it is now possible to inherit the update of an account flag to 'J' to all allocated company accounts. To this end the user is requested whether an adjustment has to be provided. When committing this request all allocated company accounts are provided with account flag 'J', too. Only mere intercompany accounts (accounts with fixed intercompany) are excluded and keep the account flag 'I'. When rejecting this request the account flags of the company accounts remain unchanged.
The repetition of this request can be suppressed for mass operations. The answer entered for the first request then is valid for all subsequent accounts.
Up to now the controlling flags 1 were data firmly defined and delivered as meta data by IDL. Starting with the classical subdivision into acquisition/production costs ('H'), selling ('V') and administration expenses ('A') further categories were supplemented in the course of time: Research & development ('F'), Remaining expenses ('S'), Allocation of costs ('U') and finally 9 further individually usable categories ('Z1' bis 'Z9') not specifically descripted. This rigid standard hat the following disadvantages:
From now on the maintenance of the controlling flags 1 is subject to the user. For this purpose the flags are transferred into a new table by the release migration program. In this process only those flags are transferred, which are actually used by the user. If e.g. the user had restricted himself on the three classical categories 'H', 'V' and 'A', then only these are transferred into the new table.
The new list "Controlling flag 1" (CK1) and the corresponding single record application (CK1E) serve for administration of the new table. Except for multilingual descriptions you can specify a validity there. Beside the flags used up to now you can define new individual flags with a key length of up to three digits. Please note, that a maximum of 23 controlling flags in total may be defined because of the relation to the function of expense report. These applications are only available for users with the licence for the module "Controlling".
The usages of the controlling flag in other tables (controlling objects / CNT, position account allocations / POSKTO) point to the new table CK1 including their selection boxes. The corresponding import formats had to be extended accordingly (see below). The programs for generation of reports for the function of expense method (see below) and the MIS data preparation (see below) were adapted accordingly.
The application "Transaction development definitions" (SPIDEF) was supplemented by several functions:
Furthermore several improvements and adjustments to other IDL Konsis applications were made at the user interface.
You can now designate a special posting key for dividends with the new usage tag 'DIV'. This tag is evaluated at carry forward of company statements and at difference amount subsequent consolidation.
When entering an IC disposal card (fixed asset type 'A') the origin card fixed asset object is automatically completed from the key like the origin card company already before.
The entry for an interim result has been removed since this amount was not used for the consolidation at all and thus was confusing.
You can restrict the display of company financial statement data to the display of data of defined group companies. An "ex fact" is required for determination of the group companies since the group companies are defined on a deviating fact. Up to now this "ex fact" was always read in the start-up data (VOR) of the user. From now on you can also specify an "ex fact" per fact in the fact master data (see above), which takes priority over the specification in the start-up data.
If the flag for maintenance of amounts in transaction currency in the consolidation function master data (KVA) is set to 'L' (transaction currency is required, but use local currency if local currency equals group currency), then already up to now the amount in local currency was inserted as amount in transaction currency for group currency companies, if no deviating data were entered. This automatic was now completed in the way, that the transaction currency amount is updated, too, at update of the local currency amount, if the values already matched before.
When entering an aggregation controlling object in the list "controlling balances" (CNTSAL) the data are displayed in tree structure. Now in this case the totals of all selected data is displayed at the end of the table, too.
The "transaction" for automatically calculated depreciations on the (p&l) depreciation account is no longer displayed in the list of intercompany fixed asset transactions (ICANLBEW). Thus the displayed total corresponds to the residual book value of the fixed asset object. However, this record still exists in the database and therefore basis of the 'ZA' consolidation postings generated from these transactions.
The table for vouchers (BEL) was enhanced by the entry of a reference voucher for deferred taxes. Here you can enter a voucher number, which receives the postings of the deferred taxes of this voucher.
In addition this table was enhanced by a flag for accumulation of carry forward. This flag has the following positions:
The feature for suppression of repeated messages was supplemented in the functions for deletion of balances and origin lists (called from the company financial statement monitor EA). This is especially helpful at mass processing for several companies.
When transferring intercompany account balances to the next fact the entries for reference voucher number and date remained unchanged up to now. Then no aggregation of these data was possible. However, the consequences were a large number of IC account balances on the consolidation fact, a corresponding large number of 'SK' and 'AE' consolidation postings and long run times at generation of group reports. Now IC account balances are aggregated independent from reference voucher number and date if the aggregation flag ist set for the destination fact. Please note that there is no aggregation for the clearing flag. I.e. a manual clearing performed on the basis of reference voucher data is maintained.
The head line of the journal was arranged more clearly providing non-ambiguous identification of source and destination fact.
Postings with identical attributes now can be aggregated to one carry forward posting at carry forward of vouchers. This behaviour is controlled by a new accumulation flag in the voucher header.
Vouchers with set flag for deferred taxes (LT flag) maintain this flag after carry forward provided they continue to affect net result. Depreciations automatically newly calculated after carry forward are considered in the determination of the net result effect. If several origin vouchers are aggregated to one carry forward voucher it is sufficient for providing the destination voucher with the LT flag, that one of the origin vouchers had the LT flag switched on. Postings on p&l accounts then receive the LT flag, too.
If capital transactions with a posting key with the new usage tag 'DIV' (see above) are carried forward then no intercompany is written into the carry forward transaction as far as no reposting to another account takes place. Furthermore it is required that the account has the account flag 'J' since differences to intercompany account balances would appear otherwise.
The head line of the journal was arranged more clearly providing non-ambiguous identification of source and destination period.
If depreciations are calculated in a voucher supplied with the flag for calculation of deferred taxes (LT flag) then a newly created depreciation posting on the p&l account is automatically supplied with the LT flag, too. This applies for a manually invoked "automatic calculation of depreciations" (action in "Postings"/BUCH, e.g. after modification of the depreciation parameters of the fixed asset object) as well as for an automatic calculation of depreciations (e.g. after carry forward into the actual period). It is strongly emphasized to split the voucher now if it contains several instances which are differently handled with respect to deferred taxes.
The currency conversion of postings was adjusted to a large extent to the currency conversion of the data generated out of postings on the next fact, especially development transactions. If a posting on a transaction development account is converted divergent from the conversion rule of the account then now a compensation posting is generated on the same account with the posting key for exchange rate effects (for postings carried forward) or conversion difference. Remaining differences in the voucher are cleared by postings on the accounts of the currency conversion parameter (WUM) like before.
Capital transactions on the accounts of the currency conversion parameter (WUM) with entry of an origin voucher and an origin fact are no more deleted. Rather a remaining difference between account balance and capital transactions is considered at generation of capital transactions. Thus differences from the original account balances and differences from the added postings can be distinguished.
The intercompany reconciliation of the company financial statements required the authorisation for the entered group companies just like the later D&C/P&L consolidation. However, thus company financial statement users would have the ability to view group reports and the complete financial statements of other companies. Therefore the IC reconciliation in the company financial statements is now possible without authorisation for the group companies. Like before the authorisation for the respective company is still required.
If depreciations are calculated in a voucher supplied with the flag for deferred taxes (LT-Flag) then a newly generated depreciation posting on a p&l account is automatically supplied with the LT flag, too. This applies for a manually invoked "automatic calculation of depreciations" (action in "Postings"/BUCH, e.g. after modification of the depreciation parameters of the fixed asset object) as well as for an automatic calculation of depreciations (e.g. after carry forward into the actual period). It is strongly emphasized to split the voucher now if it contains several instances which are differently handled with respect to deferred taxes.
If a voucher with postings selected for deferred taxes is supplied with a reference voucher number for deferred taxes (see above) then the corresponding deferred taxes are posted in this separate voucher. This way deferred taxes can be allocated to an origin voucher more easily. Deferred taxes of vouchers without entry of a reference voucher number for deferred taxes are written into a voucher with voucher number 'LATSTEU' like before.
If the flag for the maintenance of transaction currency amounts in the consolidation function master data (KVA) is switched to 'L' (transaction currency is required, but local currency is alternatively used if local currency equals group currency) then the forms application for intercompany account balances always offers an entry column for the amount in transaction currency even if local currency equals group currency and the local currency amount is used as a default. The multi-period form is excluded from this like before, i.e. here transaction currency amounts have to be entered in the additional dialogue.
A new forms application is now available for the table Margin of products (PROMAR) invented with release 2011.0. This application has different variants:
Only accounts with the new account flag 'T' may be entered as difference amount interim accounts. This concerns the consolidation parameters 'KK', 'FK', 'EK', 'SK' (incl. 'S0' ... 'S9') and 'AE' (incl. 'A0' ... 'A9'). The release migration program provides all accounts already used as difference amount interim account with this flag.
When selecting a consolidation voucher for consideration at calculation of minority interests or deferred taxes all postings on p&l accounts and on capital accounts are labelled as well. Within this accounts with account flags 'E' (result), 'G' (group result). 'N' (neutralisation account), and 'T' (difference amount interim account, new, see above) are excluded since these accounts are neither to be considered at calculation of minority interests nor at calculation of deferred taxes.
Vouchers with set flag for deferred taxes (LT flag) and/or minority interests (FF flag) maintain these flags after carry forward provided they continue to affect net result. Depreciations automatically newly calculated after carry forward are considered in the determination of the net result effect. If several origin vouchers are aggregated to one carry forward voucher it is sufficient for providing the destination voucher with the LT and/or FF flag, that one of the origin vouchers had the LT or FF flag switched on. Postings on p&l accounts then receive the respective flag(s), too.
When carrying forward postings with posting type 'WX' the elimination of carry forward postings on transaction development accounts is performed with the posting key of the origin posting. Up to now a general posting key for changes in the actual period (usage tag 'L' or 'N') was used.
If it is determined that a voucher cannot be carried forward because the consolidation function master record doesn't refer to a carry forward consolidation function then this issue is now reported. This especially may concern outdated consolidation functions no longer used (e.g. 'VA', 'VL'). In this case you either have to complete a reference consolidation function for this consolidation function (KVA) or you copy the voucher to a voucher with a different consolidation function.
The head line of the journal was arranged more clearly providing non-ambiguous identification of source and destination period.
If depreciations are calculated in a consolidation voucher supplied with the flag for calculation of deferred taxes (LT flag) or the flag for minority interests (FF flag) then a newly created depreciation posting on the p&l account is automatically supplied with the respective flag(s), too. This applies for a manually invoked "automatic calculation of depreciations" (action in "Consolidation postings"/KONBUCH, e.g. after modification of the depreciation parameters of the fixed asset object) as well as for an automatic calculation of depreciations (e.g. after carry forward into the current period). It is strongly emphasized to split the voucher now if it contains several instances which are differently handled with respect to deferred taxes or minority interests.
The function "Check & refresh participations" now reports a note if shareholding transactions (GESGES) had been defined for a subsidiary with a transaction date outside the interval between previous period and current period. It is also reported if a disposal date from or an addition date to the group / sub-group is entered and the transaction date of the shareholding transaction is outside the correspondingly reduced time interval.
The function "Check & refresh status information" now can be called per company in the group companies & monitor (KTKGES). To this end the respective companies have to be selected in the table before invoking the function. Without selection of lines the status refresh is performed for all group companies like before.
Some consolidation functions eliminate company financial statement transactions on development accounts. Up to now this elimination was performed in group currency only while the corresponding amounts in parallel currency were yet determined by the currency conversion. However, when using a parallel currency with changing exchange rates differences in parallel currency occurred since development transactions carried forward are always inserted with the parallel currency amount of the previous period and the currency conversion rule 'VPW' (Predefined amount parallel currency).
Now the amount in parallel currency as well as the currency conversion rule 'VPW' is inserted into the consolidation posting for elimination of development transactions with currency conversion rule 'VPW'. In addition the original currency conversion rule and the exchange rate are inserted for a consolidation posting eliminating a development transaction with parallel currency conversion rule 'VK' (predefined currency rate). These values are not modified by the currency conversion. This concerns the following consolidation functions:
This modification had already been performed for the repostings after elimination IC account balances (SU) within updates for the last releases.
The currency conversion for consolidation postings had been adjusted to the currency conversion of company financial statement data by converting postings on transaction development accounts with a posting key for carry forward with the exchange rate of the previous period if defined.
Indirect minority interests for dividends in phase are now posted within the 'FF' voucher with two companies (subsidiary/parent) in the voucher number (up to now in an 'FF' voucher with only the subsidiary in the voucher number). Amongst others this provides a more correct representation of the minority interests in the list "Capital and minority interests" (KONKKFF).
Capital transactions with a posting key with the new usage tag 'DIV' (see above) are excluded at posting of difference amounts in subsequent consolidation. This in case avoids double postings if a processing by another consolidation function ('SD', 'SU') is present.
Consolidation postings generated by the function "Settle the difference" now are provided with booking line status '5' (manually created) and thus may be modified manually. Up to now these postings received the booking line status '1' (automatically created) and thus were locked against manual updates.
A message is reported by the automatic IC consolidation if no consolidation parameter is defined for a D&C or I&E clearing group (consolidation function) in a certain period and fact. Now the user can decide whether he wants to process the consolidation without these clearing groups or to cancel processing.
This is considered by the "Repostings after elimination IC acc." (AU/SU), too: Accounts allocated to a consolidation function (clearing group) without a consolidation parameter are no longer processed.
A controlling object for the result was supplemented in the table for IC fixed asset objects. It can be entered for the disposal object in connection with the result account. Both entries are used together for the result posting at consolidation. If no result account is specified for the disposal object then the result account as well as the corresponding controlling object are fetched from the consolidation parameter 'ZA'.
Now it can be set whether an entered account balance is splashed to potentially existing controlling balances or not. Conversely it can be set whether adding or changing a controlling balance changes the corresponding account balance or not. Therefore it is possible to divide an existing account balance into controlling balances afterwards (top down planning) as well as creating an account balance by entering controlling balances (bottom up planning). The option can be set via a button in the toolbar of the table area.
The action menu entries for refreshing FORECAST and PLAN balances have been divided into "all accounts", "only P/L accounts" and "only balance sheet accounts". The action menu entries for leading over can no longer be found under "Refresh balances" but under the new menu entry "Lead over".
If a window of IDLFORECAST is reduced in size, it is possible that some of the icons in the tool bar will no longer fit in the window title. In this case an arrow button will appear with which the icons that aren't shown can be temporarily displayed.
Controlling balances planning (separate licence required) can now be disabled in the options dialog. This improves performance in cases when controlling balances exist but the planning process should not use controlling balances.
A comment can now be added to scenarios. The comment can either be edited via a text area on the last page of the scenario wizard or a new context menu entry for existing scenarios. The comments will be displayed as a tooltip on the entries in the Scenario Manager. Comment length is limited to 500 characters.
The scenario manager now has a properties window which can be displayed via an entry in the context menu. The properties window shows information about the scenario which cannot be found in the scenario table, such as "Last modified by/on" or the company/business unit combinations for which data has been entered into the scenario.
The information about the creator and the creation time of a scenario is now preserved when a scenario is migrated to the current release.
The release migration is now significantly faster if a scenario doesn't contain any data that needs to be migrated.
The "Version" column is no longer displayed in the Scenario Manager, since this information is always identical for all scenarios and non-migrated scenarios can be identified by a warning icon next to the scenario name.
The set of standard rules has been extended by a general Income Rule and a general Expenses Rule. The new rules are essentially identical to the existing Sales Rule and Purchases Rule.
The Transition Rule now allows accounts with different BS/PL codes on the right side. The error message has been replaced by a warning.
The Transition Rule wizard has been changed: Accounts are no longer selected in list boxes, but via a selection dialog which opens by clicking on the account field.
The Manual Posting wizard has been changed: Selection of account, amount and D/C code for the posting component is now done directly in the table instead of additional input fields above the table. Two default posting components are added automatically when the wizard is opened.
It often happens that the same (or a small number of different) descriptions are used in the functions "Account entry", "Manual posting" and "Convert auto adjustment". To simplify this the input field for the description text now has a list box which displays the recently used description texts.
The Leasing Rule has been modified:
When using a Leasing Rule with capitalisation:
A comment can now be added to rule templates. The comment can either be edited via a text area on the last page of the rule wizard or a new context menu entry for existing rule templates. The comments will be displayed as a tooltip on the entries in the Rule Template Tree. Comment length is limited to 500 characters. The comment of a rule template is transferred to all business cases created from that rule template if the template is used. If the comment of a rule template is edited, all business cases created from that template also get the new comment.
The Rule Template Tree now has a properties window which can be displayed via an entry in the context menu. The properties window shows information about the scenario which cannot be found in the template tree, such as "Created by/on" or "Last modified by/on".
The properties window of a Used Template shows the time at which the template has been used, how many existing business cases have been created from the template and whether the business cases still exist unmodified.
It is now possible to enable or disable rule templates and rule template sets in the rule template tree via the context menu.
A rule template is now immediately removed from the tree of used templates if all business cases are deleted or Undo is used after using the template.
The context menu entry "Delete all business cases" can now be applied to several rule templates as well as template sets.
If a rule template cannot be used because it references to periods which do not exist in the current scenario or the period restriction results in no business cases being created from it, the user is notified of this fact.
If IDL Forecast is invoked on a data base for the first time then a rule folder with the name "Standard set" was automatically created since rules cannot be defined outside a rule folder. This folder is now named "Rule templates" because the old name was confusing since it contained no rules.
The behaviour of the windows for Used Templates, Business Cases and Account Entries when selecting elements in these windows has been changed. When selecting an entry in one window, the selection in the other windows is changed as well:
A comment can now be added to business cases. The comment can either be edited via the corresponding used rule template. The comment is displayed in a new tab in the details window of the business case viewer. Comment length is limited to 500 characters.
An active filter in the balance difference viewer can now be quickly deleted by a new button in the tool bar.
The balanced check for manual postings now correctly ignores statistical accounts.
The table of report line descriptions was enhanced by a number uniquely identifying a line and which is permanently preserved (e.g. by the function "Renumber lines"). This number remains invisible for the IDL Konsis user. However, it can be used by external applications (e.g. MIS/OLAP, IDL Publisher) for comparison of two reports generated with different versions of the report line descriptions and allocation of their lines.
Controlling reports by the function of expense method (report type 'C') have a special distribution of the columns of the report result. The first four columns contain totals of balances and consolidation postings while from column number five on each couple of colums is allocated to balances and consolidation postings per controlling flag 1. Because of the transition to individual controlling flags 1 (see above) now additional columns can be occupied such that the column options (see below) have to be enlarged, too. However, the total number of controlling flags 1 is limited to 23 since the report result is limited to 50 result columns.
Because of the transition to individual controlling flags 1 (s.o.) the column options for the function of expense method (report type 'C') become individual, too. The release migration transforms these column options (incl. their column descriptions and formulae lines) up to now firmly defined as meta data by IDL, '#CALT', '#CBUC', '#CKON', '#CKTK', '#CNEU' and '#CSUM', into individually maintained column options with a '$' instead of the '#'. If you continue to work with the hitherto controlling flags 1 you don't have to do anything.
However, if you want to use the facility of defining new controlling flags 1 then the column options have to be extended accordingly. New controlling flags 1 are automatically adjusted to vacant report result columns. The allocation becomes visible in the formulae lines list (FED) and the single record application (FEDE) as well as in the selection box for the operand position of the formulae editor.
New import applications have been supplemented for the tables of "Business units" (UBR) and "Product margins" (PROMAR). The calling application "Data Import and Display" (IMPORT) contains the corresponding calls in the sections <Import master files> / <Company & group data> and <Import company financial statement data>, respectively.
Corresponding import/export format definitions '#TXT' and '#DB' were defined in the tables of "Import/Export Format IDs" (IEF), "Fields for Import/Export formats" (IEFDEF) und "Allocations Import/Export fields to formats" (IEFFEL). An export from the lists "Business units (UBR) and "Product margins" (PROMAR) is proceeded in the '#TXT' formats if no other format is specified. The new tables I120 (business units) and I161 (product margins) were supplemented for the import of these data via import tables.
The import table I106 for positions (POS) and column descriptions (SPA) has to be completely dropped and newly defined due to database changes (see below). Therefore please assure that no unprocessed data exist in this table before installing this release.
Import processes via database tables (Ixxx) now can be invoked by a workflow automate. However, you have to specify the job number as a fixed parameter or as an entry field at run time.
Reported intercompany account balances on balance sheet accounts are ignored instead of being issued as an error at import of IC-P/L-thereof-account balances if the data origin "CODA" is specified.
You can decide that the update of the account flag of an account of the group chart of accounts to 'J' is inherited by all allocated accounts of the company charts of accounts just like in the single record application (see above).
The import formats for controlling objects (KST) and position account allocations (POSKTO) had to be enhanced for the individualisation of the controlling flag 1 (see above), since the controlling flag 1 now demands a length of more than one character. New extended fields were provided for the import: K063-K075-CK1, I103-CK1, K023-K075-CK1, I107-CK1. However, for the time being the former one-digit fields (K063-KST-KNZ1, I103-KST-KNZ1, K023-ENDE-KNZ, I107-ENDE-KNZ) may be used alternatively as far as their length is sufficient.
The specification of a valid-from period is now optional at import of column descriptions (TXTSPA). The previous value of existing records is maintained if no modified value is specified. For new data records the valid-from period of the column option (SPO) is used as a default value.
The same applies to the import of positions (TXTPOS) with the difference, that the default value for new records is taken from the valid-from period of the chart of positions (POP). In addition the b/s p/l code is now optional, too. The previous value of existing records is maintained here, too, if no modified value is specified. For new data records the b/s p/l flag is set to the invalid value '0' if not specified otherwise. Thus the position cannot be used until a valid b/s p/l flag is provided.
Financial accounting systems (sources for import) sometimes do not distinguish between intercompany accounts and shareholding accounts. Then shareholding transactions are imported with the intercompany account balances and rejected by IDL Konsis as incorrect data. Now intercompany account balances on shareholding accounts are no longer reported as error but rather counted as "ignored data records" in the final log file.
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.
When loading group-wide data you can decide that the update of the account flag of an account of the group chart of accounts to 'J' is inherited by all allocated accounts of the company charts of accounts just like in the single record application (see above). However, this request is output only once and the response is applied to all accordant group accounts.
The OLAP data preparation had to be adjusted with respect to the individualisation of the controlling flag 1 (see above). The attributes Kxxx_KST_KNZ1 in the tables K836 for controlling flags 1 and K827 for position account allocations now have 20 digits instead of 1. However, the table K832 for controlling objects was not newly defined since the column for controlling flag 1 already had a length of 20 digits here. K836 is now supplied with the data of the new table CK1. All views depending on this table were newly defined, too.
The approved taxonomy HGB 5.0 was integrated in IDL Konsis with the key "HBGV52011".
The taxonomies supplied by IDL were supplemented by the additional bank module of the HGB taxonomy. This especially concerns the allocation of the taxonomy concepts to positions (Z-POSXBRL).
The read function as well as the write function of the IDL Connector were supplemented by an application for country codes and an application for business units.
The functions for transfer of the position master data (POS) and the position account allocations (POSKTO) are now supported for the new general ledger. These functions are also contained in the new standard IMD template for selecting data with the IDL Importer.
The ledger version now can be modified in the SAP login window.
You can designate certain accounts as 'E' accounts (result accounts) now again when unloading accounts.
The release 2011.1 contains a current version of the DCW Interface for the DCW release 3.50.
The following English language documentations have been updated or enhanced in the documentation directory together with this release: