The 2011.0 release includes changes and enhancements to the products IDL Konsis , IDL Forecast and IDL Connector .
The IDL Konsis 2011.0 release is a major release; therefore it cannot be left out of the release sequence. The minimum requirement for this release is the last IDL Konsis 2010.0 major release dated July 27, 2010. It can also be installed after installation of the interim release IDL Konsis 2010.1 dated November 23, 2010, however.
The amendments and corrections that have taken place up until the release closure for the major release IDL Konsis 2010.0 as well as the interim release IDL Konsis 2010.1 are contained in this interim release.
This documentation describes the enhancements that have been made since the IDL Konsis 2010.1 interim release. To learn more about the enhancements that have taken place since the 2010.0 major release, please also refer to the documentation "Release 2010.1 News".
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.
The masters for periods (ABR) and facts (FAC) were extended by a flag for maintenance of the basic data for the elimination of each, fixed asset results an current asset results, IC fixed asset transactions (ICANLBEW) resp. IC stocks in inventories (ICBEW). These flags have to be switched to on for the relevant periods and facts to process these data in functions (currency conversion, company closing, period carry forward) and to provide a status display by the company financial statements monitor (EA).
Furthermore the current depreciations for IC fixed asset objects (fixed asset objects with fixed asset type 'A' or 'Z') are no longer calculated on the basis of consolidation postings (KONBUCH) but rather on the basis of IC fixed asset transactions (ICANLBEW); the corresponding consolidation postings can be generated from these by calling up the function "Elimination of fixed asset results" (ZA). In the event that 'ZA' consolidation postings had been entered directly manually the current depreciations also have to be entered manually for each period from now on. As an alternative the missing corresponding IC fixed asset transactions can be added supplementaryly.
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.
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.
Besides the conversions for the 2010.1 interim release, the migration program will also complete the following transformations in the database:
The following menu IDs in this release are new (in addition to the new menu items contained in the Interim Release 2010.1) or include new authorized actions. If completely maintained customer-specific authorization groups are to be 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.
The command line for external call ups on the menu items UNL... that can be specified in the application "menu item" (MENE) has now been extended to include up to 510 characters, due to the fact that listing the path to the server already takes up the space previously available.
This and other call ups of external applications (in individual menu items) will usually now take place in a synchronized manner. This means that IDL Konsis applications will not start until the external application has been ended. To ensure that existing call ups continue to take place in an asynchronous manner, this is done by setting the parameter "start" with the help of the migration program. The exceptions are the call ups from the SAP interface (kcusap.jar) that have already taken place in a synchronous manner. You might need to enter "start" for newly defined menu items if these are to take place asynchronously.
Sorting of the applications called up can be preset for menu items that represent the hub of an automatic control (see below). The MENE mask includes a new input field entitled "Sort option".
Some IDL Konsis programs can be called up using different abbreviations and then have different functionalities (e.g. KAPBEW, RUEBEW, SPIBEW). Users are then able to set up additional menu items on these types of programs in order to be able to give them specific names inside a customized menu or automated control system. The question of which of the functionalities the program should perform will then be unclear, however.
The "menu items" (MEN) table has been expanded to include the attribute "reference menu ID" to help you achieve a clear functionality. An individual menu item can thus point to a standard menu item. Previous special treatments of certain menu keys (such as "$KAPBEW") are no longer included in the applications, therefore maintenance of a "reference menu ID" is strongly recommended for individual menu items.
Other parameters for use in an automated control system, especially for import applications that offer all of the control options, have been added to the application "menu structures" (MENMEN):
In addition to entering an explicit value for these parameters, the special entries "#KEY' and '#OPT' are possible in generating a (mandatory or optional) entry field in the mask of the automatic control system. By making the special entry '#VOR', the value from the respective field of the preset user-specific setting can be referenced for "Chart of controlling objects", "Chart of positions" and "Ex-Fact".
Up to the 2009.2 release, the arrangement of the application call ups listed in the automate control in the event that multiple applications were run for several companies was done in such a way that they were sorted by company to start with. It was thus easier to select and carry out all of the applications for a company. This was impractical with certain applications, however, reconciliation of IC balances with the next fact that was then followed by IC clearing, for instance. In this case, an application must be run first for all of the companies before the next application can be started in a way that makes sense. For this reason, the arrangement had been changed starting with the 2010.0 release to allow for sorting by menu items first. However, due to the fact that both versions have a right to exist, depending on the constellation, the mask of the automate control system had been extended to include a sorting option in the 2010.1 release (addendum B). Here, you might enter whether sorting should take place by companies ('G') or by menu items ('M') to start with. The standard setting for sorting by companies used to be 'G'.
This sorting option has now been discontinued. Instead, it is now possible to set the sorting of the call ups for the hub of an automate control system under the (customer-specific) menu item (MENE). As in the sorting option that has been discontinued, the values 'G' (sorting by companies) and 'M' (sorting by menu items) are now possible. It is no longer necessary to explicitly enter this in the mask of the control system.
The overview "Exchange rates" (WKZWKA) has been modified to meet the standard with respect to its keys, therefore a call up is now possible as part of automate control.
It is now possible to branch off into the applications "Menu items" (MEN) and "Menu structure allocations" (MENMEN) via the context menu contained in the lines of the table in order to be able to examine the definitions responsible for the respective line.
The table of user-specific startup data (VOR) has been extended to include an entry possibility for "Control of display of valid master data". If this is switched to on, all of the data that contains a valid until period will be filtered out automatically in the various overviews via the master data with validity entry. This means the only data that will be displayed is the data that is valid for an unlimited period of time.
When using the IDL Konsis application server, it is now possible to encrypt the transfer of data between the client and the server. If necessary, please contact the technical hotline at IDL .
The texts of the quick starter are no longer displayed in bold type but rather in normal type.
Analogous to the resource tree, the quick starter shows a tool tip if the cursor remains positioned on a button. The tool tip shows the term and the abbreviation for use in gaining direct access to the application behind it in parentheses.
A toolbar that features buttons for opening and closing one ([+], [-]) or all ([++], [--]) of the levels of detail located beneath the hub you have selected, just like the toolbar for tables that have the tree structure, has been added to the resource tree.
The icons for "Create new data" (star) and "Edit data" (pencil) have always been shown on an alternative basis in the past, with regard to whether lines had been selected in the table or not. Now, both symbols can be shown next to each other. This offers an advantage in that "Create new data" can be selected even when lines of the table have been selected.
For activation of the simultaneous display of both icons you have to select the option <Create new data / Edit data> in the tab <Graphic> of the menu <Options>. As a result, the object and the action menu then contain both entries. If no line has been selected then "process data" is deactivated, while "set up new data" is always activated. As in the past, double clicking onto a line activates the action "process data", even when this is no longer indicated in the first position of the menu.
An icon (open padlock) for the action ‘unlock’ is now also made available for the action in the application-specific toolbar analogous to the icon for the action ‘lock’. This also applies for the applications
There is also a new icon for the actions "Display report" (writing pad) and "Create report" (writing pad with pencil). These icons are displayed in the toolbar of the applications that enable these actions (REP, REPK, REPERG).
Furthermore, there is a new icon (percentage sign) for the action "Check & refresh participations" that is displayed in the application "group companies + monitor" (KTKGES).
The tool tips for the tabs are now displayed in an offset manner. In the past, the tool tip covered up the tabs so that these were difficult to use, especially when the status bar was switched off.
The functionality for revoking (undoing) and repeating (redoing) changes is now also available for form entry. Please note that these functions can only take effect if the changes have not been stored yet in the database.
Input fields in which the contents of a field are displayed on a rolling basis and can be entered have been made available for extremely long data in the 2010.1 release. As a result, it was no longer possible to view the complete contents of a field all at once.
As an alternative, entries that contain multiple lines are now being made available for these fields. This applies for the
In the past, it was only possible to expand and collapse trees using the keyboard (arrow keys) if you had clicked into the fixed table area with the mouse before. If, on the other hand, the focus was on the sliding table area, expanding and collapsing was no longer possible, due to the fact that the arrow keys were then used to move the focus between the cells. Expansion and collapsing of trees is therefore now also possible by using the key combinations ‘CNTL’ + ‘arrow right’ or ‘CNTL’ + ‘arrow left’ completely independently of the table area.
The toolbar now features an additional filtering icon for tables (funnel). A click of the mouse onto this icon shows an additional line underneath the table headline that differs from the other lines in terms of its colour. Filtering instructions can be entered into this line. Activating the filtering line will also have an effect on other tabs as in logging into IDL Konsis once again.
The filtering instructions always specify a portion of the data selected before. All of the lines in a table that do not match the filter setting will be blended out automatically. In tables that have a tree structure, the filter will only have an effect on the bottom level of the tree. Parent nodes will always be displayed if subordinate data is displayed or hidden if no subordinate data exists.
The entry possibilities for the filtering instructions depend on the types of values in the columns. Basically, all columns (numbers also) can be given respective character strings as filtering instructions. This means a character combination (letters, numerals, special characters) will be entered in the filter entry and all of the table lines that contain the substring in any position of this column will be displayed. All of the other lines will be hidden. Here, no distinction will be made between lowercase and uppercase letters.
It is also possible to enter more than one substring. In this case, all of the substrings with a "|" (pipe sign) will be separated. In this way, all of the lines that contain at least one of these substrings (or-link) will be admitted.
Substrings will basically be issued with a completion icon "%" in front and in back. If the "%" is entered into the filter directly, this automatism will be turned off. "%" at the beginning of a filtering entry means that only lines that end with the filtering entry will be displayed (in other words, "%ger" means that only terms like "hamburger", "trigger" or "tiger" will be able to pass through). Analogous to this, the "%" can also be at the end of the filtering entry to thus mark the beginning of the lines that are being sought. "%" can also be in the middle of the filtering entry and thus be filled with any characters. Using "_" allows you to make sure that any number of characters can be entered in this specific place. These filtering entries can also be linked by using the "|" (pipe sign).
If numerical values are contained in the column (these also include periods, complete dates or times), then mathematical formulas for use in filtering can be developed. Mathematical formulas use the relational operators "=" (equal), ">" (greater than), ">=" (greater than or equal), "<" (less than), "<=" (less than or equal) and "<>" (unequal). Simple application possibilities are the display of values that are greater than a specified value, e.g. by ">1000", or lines that were changed after a specific date, for instance by ">=1/1/2011".
Any type of formulas with "+", "-", "*" and "/" can also be entered for purely numerical values. If the variable x is used in the formula, then the respective value is entered in the table for x. For instance, "x*3<=3000" will filter out all of the data that are larger than 1000.
The special characters "&", "|", "(" and ")" can be used to link several partial expressions for information on figures and times. If "&" is used between two or more expressions, then all of the partial expressions must be fulfilled to make sure that a line isn’t filtered out. With "|", on the other hand, only at least one partial printout must be met. "&" and "|" can be combined by using parenthesis.
If filtering instructions are issued in multiple columns, only the exact lines that match all of the filtering instructions will be listed. A line will already be deleted even if only one of the filtering instructions filters out the line.
Please note that the filtering instructions will remain intact even if the selection criteria and repeated display of data have changed, therefore, perhaps no data will be shown although data stored in the database was actually read. Entering the number of selected sets in the message line always refers to the data read in the database according to the selection criteria, regardless of filtering.
A "show/hide internal columns" checkbox has been added to the menu 'View'. This is not activated on a standard basis. When activated, several overviews show additional columns that serve to help the IDL hotline determine the causes in the event of failures.
The search dialogue now also supports the special characters '%' and '_' as in other IDL Konsis applications:
These special characters do not work in this way if the check box for ‘regular expressions’ has been activated.
In conjunction with ad hoc diagrams, the possibility of marking individual cells contained in a table had been created. A table icon in the toolbar can be used to switch over to this cell mode. This cell-oriented selection will now also be evaluated in copying (e.g. to Excel), which means that only the marked cells will be exported. For technical reasons, however, this selection is only limited to the sliding area of the table, therefore cells cannot be copied from the fixed columns.
With the help of the cell mode, a new function for summing operation can now be used. The values of all marked cells with numerical contents will be added up and will be displayed in a new entry in the footer. Here, a debit/credit code that is possibly contained in the line will be evaluated and displayed next to the value. Values that have different debit/credit codes will be subtracted.
When using this function, please note that this is a largely application-independent traits of the user interface. For instance, if appropriate selections are made, values will be netted in various currencies.
It is now possible to prevent footers from being printed in printouts. For this purpose, the print preview now offers yet another icon "show/hide footer" in the toolbar next to the icon "fit to page". This means that the printout of multiple report results can be attached to each other without always having the page numbering from the start again. This setting cannot be stored, which means that a successive printout takes place with a footer on a standard basis.
The file dialogues from various IDL Konsis functions have now been standardized.
It is now possible to decouple windows from the desktop and position them independently on the screen of the monitor. This is especially helpful when a user uses multiple monitor screens in that a longer table can be transferred over completely to one of the monitor screens.
To activate this function, all of the detachable windows contain an icon with an open rhomb on the toolbar. A single mouse click on this icon will decouple this window from the desktop. Afterwards, the window can be positioned freely and adjusted with respect to its size. The icon then changes into a rhomb that is folded together. Clicking onto the icon you were using links the window together with the desktop once again, as before.
All of the actions that have taken place during decoupling, such as new selections will also take effect on the decoupled window.
With changes in the colour dialogue (‘extras’ – ‘options’ – ‘colours’), the changed colours will now be displayed immediately on the current desktop so that the effects of this change can be assessed immediately.
The "desktop background colour", in other words the colour between the application areas, and the "common selection colour", in other words the shading with which the selected table lines can be distinguished from the non-selected lines, can now also be set in the option dialogue ‘colours’. The common colour for selection applies to both IDL Konsis and IDL Forecast tables. A transparent black that makes the selected lines appear darker is the standard setting.
For the main selection (of the desktop background colour), a set of matching colours will be offered as "designer colours" in addition to the range of colours.
It is now possible to set the system in such a way that the various overviews of master data with validity entries automatically filter out all of the data that contains a valid until period entry, in other words only display data that is valid on an unlimited basis. The new "Control of display of valid master data" switch in the table of the user-specific startup data (VOR) must be set to 'X' in order to achieve this. This applies for the overviews
The selection possibility based on valid from and valid until periods that was contained in some overviews in the past has been discontinued instead, especially considering the fact that these types of selections can now be made via the filter line (see above). The filter line also allows for limitations including greater than and less than entries, as well as entries on the intervals, etc. The overviews affected by this change are
The short name used to be a mandatory entry for many of the master data applications although it was used only very rarely on the surface to transform the respective keys. The short name was optional in some of the other applications and thus could remain empty, a condition that possibly resulted in a lack of translation.
The following uniform solution has now been introduced for this reason:
Similar controls were already available in some of the importing applications.
The master tables for periods (ABR) and facts (FAC) have been expanded by adding another button each for maintaining IC fixed asset transactions (ICANLBEW) and IC stock in inventories (ICBEW). To process the data completely (e.g. display status in EA, carry forward, currency conversion), the button for the current period and the button for the respective fact both need to be switched to "active".
Selections based on the check rule exclusion group are possible inside the period master by including an appropriate input field.
All of the companies that are to be consolidated in a group of companies can now be selected in the overview entitled "companies" (GES). Nonconsolidated companies (consolidation method 'K') are not taken into consideration.
For this reason, input fields for group/sub-group, period and fact have been added to the selection mask. If only one group/sub-group is entered, the period and the fact from the user’s startup data will be added automatically.
Furthermore, it is now possible to select according to the check rule exclusion group by filling out an appropriate input field.
In the list "Company+business unit allocations" (GESUBR), data on multiple facts (entry '%' or partially qualified) and/or periods (additional input field "From period" for specifying an interval) can now be selected. This extension is mainly designed to make exporting and importing data from multiple periods or different facts easier.
Mass copying for multiple periods, similar to the overview "periods" (ABR), is also possible. Here, instead of entering a target period, a target year must be entered. The monthly figures contained in the source data will then be saved. If a set already exists in the target period, no claim will be issued, instead this will be ignored.
The table on the chart of positions has been extended to include an attribute for XBRL taxonomy. This attribute can be entered in the single record mask (POPE). Only the entries that are displayed in the selection box in this field are allowed. These are the standard taxonomies that are currently supported by IDL Konsis . With the 2011.0 release, these are:
IDL will be introducing additional taxonomies as they are approved or if they are needed.
The XBRL taxonomy specified for the chart of positions will be evaluated when the XBRL concepts are assigned to the positions of the chart of positions.
In addition, the overview of the position balances from which the XBRL export is started allows for a limitation based on the XBRL taxonomy. To avoid having XBRL concepts from different taxonomies mix inside an XBRL instance document, this entry is a prerequisite for an XBRL export.
An allocation dialogue with drag&drop functionality is now available to allocate XBRL concepts to positions. This application can also be called up using the abbreviation Z-POSXBRL.
Once you have started the application, you will see a table of the defined charts of positions one of which can be opened by double clicking or marking the lines and confirming the magnifying glass icon in the toolbar. Two additional tables will then appear underneath the first table:
The XBRL concepts can now be assigned from the right table to the positions in the left table with the help of the drag&drop technique. Each XBRL concept can only be assigned once. For this reason, it will disappear from the right table once it has been assigned. Only one XBRL concept can be assigned to each position. Therefore, an XBRL concept cannot be dropped onto a position that is already occupied.
It is also possible to delete an (incorrect) allocation. To do so, the XBRL concept will either be pulled out of the position table and back into the table that contains the available XBRL concepts with the mouse or you must mark this position and use the delete icon in the toolbar.
The changes made will not be stored immediately in the database, but rather after the floppy disk icon in the toolbar or <Save> has been used. As yet another action or function of the toolbar, the chart of positions that is still open can be closed again.
Accounts for statistical volumes (balance sheet/P&L code '5') will no longer be shown in the overview "accounts" (KTO) with the selection/sorting option 'F' (display accounts that have no positions allocated) if these have been assigned to a thereof position.
During automatic generation of position/account allocations for the accounts of the company chart of accounts in accordance with the allocated account of the group chart of accounts, the entry of an aggregation account will also now be evaluated. In this case, the allocation of the assigned group account from the aggregation account will be adopted.
If a P&L account without the account flag 'D' is entered for the depreciation of a fixed asset object, then all of the depreciation methods are allowed just like with the account flag 'D'. Limiting these to the depreciation methods 'K' (no depreciation) and 'F' (fixed depreciation amount) is only done if the depreciation account is a balance sheet account.
The terms for entries on the business value in local currency have been generalized (see below).
An integrated application is now available to simplify and make maintenance of the transaction development definitions more intuitive. This can be called up using the abbreviation "SPIDEF" and allows for maintenance of the data stored in the applications "transaction developments" (SPI), "transaction development areas" (SBE), "transaction development columns" (SSP), "posting keys" (BSL) and "account/posting key allocation groups" (BSG).
A list of all of the defined transaction developments and their attributes will appear in an initial window on the left side after the application has been started. A dialogue in which the entries for this transaction development can be maintained can be seen already on the right side. This dialogue becomes active as soon as a transaction development has been opened by double-clicking onto the line or marking and confirming the magnifying glass icon.
The dialogue on the right side consists of two tabs. The first one enables entry of the validity of the transaction development as well as the terms, whereby the terminology box displays the languages that terms already exist in and allows for terms to be entered in additional languages. Entry of the column headline can include more than one lines, in other words exactly how it is then displayed, without having to specify the previous line break symbol '|'.
The second tab offers entry possibilities for table-specific attributes. Unlike the entry masks used in the past, multiple entry alternatives are not shown by a drop-down box, but rather by radio buttons or checkboxes if only the alternative answers "yes" and "no" are available. This prevents combinations of entries that make no sense by deactivating individual elements in a context sensitive manner. You can only leave the mask after you have entered consistent data.
Clicking onto the star icon indicates that a new transaction development is to be recorded. In this case a wizard for definition of the development opens which corresponds to the dialogue with two tabs described above.
After you have opened a (new or existing) transaction development, two additional windows will also appear in the lower section of the application. The lower window shows a list of "open tasks" that were determined by rechecking all of the transaction development definitions. This will show whether a required posting key with a specific usage tag required for this type of transaction development has not been defined yet for this transaction development, for example.
The window at the top consists of three or four tabs, in which the respective data for transaction development areas (depending on the activation for this transaction development), transaction development columns, posting key allocation groups and posting keys are displayed. Marking a line and clicking onto the pencil icon, double clicking onto a line in this table or clicking the mouse on the star icon will open an assistant for processing or entering the respective data. Much like the dialogue on transaction development attributes, these assistants contain two pages for maintaining the validity and descriptions, but also other attributes. Here, too, elements might be deactivated depending on the type of transaction development.
The changes made here will not be stored in the database immediately, but rather only after you have explicitly pressed <Save> in the menu or by clicking the mouse on the floppy disk icon in the toolbar of the transaction development table. The other icons contained in this toolbar make it possible to either copy or delete an entire transaction development, in both cases including all of the dependent data. Furthermore, the open transaction development can be closed again and the transaction development table can be updated in case other users have made any changes. All of the functions available in the toolbar can also be started via the action menu.
It is now possible to define automatic transaction developments without a simultaneous carry forward. This means that automatic transaction developments can be defined for P&L accounts, for example.
A column headline can now also be entered in the single set application for transaction development columns (SSPE). This is used initially in the overview "Transactions and consolidation postings" (KONBEW) (see below).
A column headline can also be entered in the single record application for transaction development areas (SBEE). This is of no use at the moment, however.
Posting keys with the usage tag 'U' can no longer be entered for non-audited and nonconsolidated transaction development areas.
The button in the "period/transaction developments" (ABRSPI) table for an automatic transaction development can now be placed on the new value 'M'. This ensures that the automatic comparison between the development transactions and account balances is switched off and must be entered for differences in manual development transactions. This extension supports the ability to automatically offset transaction developments that are to be evaluated for cash flow statements in certain, but not all periods.
You can branch off from the overview of check rule exclusion groups (PRFGRP) for each object menu (right mouse button) into the company (GES) or period master (ABR). Then, all of the companies or periods that this check rule exclusion group has been assigned to will be selected.
The company financial statement monitor (EA) now also shows (between controlling balances and development transactions) a status column for each set of IC stock in inventories (ICBEW) and IC fixed asset transactions (ICANLBEW). The prerequisite for displaying the status is that maintenance of IC stock levels or IC fixed asset transactions for the respective period and current fact must be activated in the new buttons of the respective master tables. By double clicking onto these columns, you can branch off into the overview "IC stock inventories " (ICBEW) or "IC fixed asset transactions" (ICANLBEW), the latter by using the sorting option 'GA'.
These status displays are based on entries in processing controls on the new checkpoints "ICBEW" resp. "ICANLBEW". These entries will be updated with each change in data. Due to the fact that no comparison takes place between IC fixed asset transactions and account balances, the checkpoint "ICANLBEW" does not usually deliver any error messages. For IC stocks, on the other hand, the system will check (analogous to IC account balances with the account flag 'J') to make sure that the sum of IC stocks is no larger than the account balance. Otherwise, a warning message will be entered into the checkpoint "ICBEW" and cause a yellow status to be shown in the monitor. In addition, control values will be calculated for both sets of data and stored inside the processing control set.
When branching off into an overview of development transactions from the company financial statement monitor, the sorting option 'KG' will always be set to show a sum for each account.
When branching off from the company financial statement monitor into the overview of check rule results, the parameters for the previous period and comparative fact will be passed on to ensure that the check rule calculation can be repeated without having to enter additional parameters.
The action "unlock company financial statement" can now also be triggered with the click of the mouse onto the respective icon in the toolbar.
The status of currency conversion will automatically be set to [red] if it is determined that it is consistent in the local currency for a data pool (in itself or with respect to other data), while this is not the case in the group or parallel currency. The case in which multiple sets of data whose KW and PW amounts add up to zero are added, modified or deleted all at once was taken into consideration.
Yet another method that automatically sets the status of currency conversion to [red] as soon as values in local currency change has been introduced to close this gap. This method is based on the change in the control values in local currency, in other words, only takes effect if maintenance of control values for the respective fact has been activated.
Under the prerequisite that a chart of positions has been entered as the standard setting, the controlling balances will be checked for whether the respective account with the controlling tag of the respective controlling objects is contained in the position account allocation (POSKTO) of a position so that the balance will also be contained in the report. This check is now also performed for IC account balances that include entries of controlling objects.
In development transactions generated from postings from an upstream fact, the original voucher number and fact in which this voucher was entered will now be noted (when the data is transferred over to the next fact). This information will also be saved in other facts despite any reconciliations that follow, in other words even if there is a change in the chart of accounts or in aggregation of business units.
These entries not only serve in tracking the data, but also for the differentiated display of development transactions in the overview "transactions and consolidation postings" (KONBEW) and in reports on results. Classification of the vouchers that are therefore also displayed in the transaction overviews represents yet another prerequisite here. Selection based on voucher classification is also possible.
The overviews on development transactions (SPIBEW, ANLBEW, KAPBEW, RUEBEW) have been enhanced to include the possibility of sorting data by IC company. A new sorting option 'IG' has been introduced for this purpose.
Automatic transaction developments were already introduced to support calculation of a cash flow statement. On the other hand, it was also possible to attach sample accounting to transaction developments that (like a transaction development payable based on maturity, for example) do not show any development in an account. All of the other (non-automated) transaction developments had to be explicitly maintained for the cash flow statement for every period.
Now, for instance, it is possible to do without having to perform extensive maintenance to these transaction developments over the course of the year if this level of accuracy is not needed for cash flow reports produced during the course of the year. The following two steps are all that need to be taken:
This extension is also available for transaction developments with transaction development areas like the fixed asset transaction development, for example. The posting key with the usage tag 'L' must then be assigned to either the transaction development area for acquisitions/production costs or the transaction development area for amortization.
Depreciations of IC fixed asset objects (types of cards 'A' and 'Z') will now be calculated on the basis of IC fixed asset transactions and entered as additional fixed asset transactions. If the values of the cumulated depreciation are entered in local currency the current depreciation will also be calculated in local currency, otherwise it will be calculated in group currency as in the past. As a consequence the "counter posting" on the depreciation p&l account will also be written as an IC fixed asset transaction. Currency conversion also generates additional IC fixed asset transactions for currency conversion effects and other currency differences.
You will no longer find the previous display of a minus sign behind the debit/credit tag of the fixed asset transactions for disposal cards (card type 'Z') in the overview (ICANLBEW). With the call up of external applications from the "IC clearing overview" (KGESGES), the parameters for disposals and additions of companies will be assumed so that the exact IC fixed asset transactions for the respective 'ZA' consolidation voucher will be shown.
The entry possibilities that pertain to IC company, IC business unit and offsetting fixed asset objects have now been removed in the single record application (ICANLBEWE) due to the fact that the IC company is already defined by the fixed asset object. The other attributes had no functions anyway.
In IC transactions, the ability to record interim losses that had been omitted has now been introduced once again with the 2010.0 release. Although elimination of interim losses is not allowed, there are cases in which this type of information is required.
A new table is used to enter the interim result in inventories from the perspective of the supplying company. Until now, this entry was only made in conjunction with the IC stocks in the inventories of the receiving company or independent of the company in the "product data" (PRODAT) allocated to the master data. Now, both companies can eliminate interim results in current assets independently of each other (original value and/or premium percentage).
The new overview application "product margins" can be found in the menu tree in the branch "company financial statement transactions" and can also be activated by using the abbreviation "PROMAR".
Under the prerequisite that a chart of positions is listed in the standard setting, the controlling balances will be checked for whether the respective account with the controlling tag of the appropriate controlling object has been assigned in the position account allocation (POSKTO) for a position so that the balance is also included in the report. Now, this check will also be performed for postings that include controlling objects.
The overview "postings" (BUCH) allows for additional selections based on the group account that has been assigned as well as voucher classification. The voucher classification will also be displayed in a new column of the table.
A new overview is designed to help you analyze check rule results. This overview cannot be accessed directly, but rather only as a line action from the check rule result overview (PRFERG resp. PRFERGK).
As a result, this display is only shown for one check rule result each. All of the single data sets that have contributed to calculation of the values for the left or the right side of the check rule will be shown. The parameters for previous periods and comparison facts will be evaluated; therefore you need to make sure that the entries made are correct. Display takes place in a three-level tree structure:
Besides the keys for the lines of data, the source of the data will also be included in the form of the respective overview abbreviation (e.g. 'KTOSAL', 'BUCH', 'SPIBEW'). The values (in local, group and parallel currency) will be netted via the tree structure.
Various functions support the user with the changes in data that are necessary in conjunction with an upstream merger. There is a shared call up application entitled "upstream merger company financial statement" that is included in the menu tree in the "company financial statement" branch for use with these functions that can also be called up as an action that follows "company financial statement monitor" (EA) or by entering the abbreviation "MERGES".
MERGES expects to receive clear entries of the period, fact and merged company. Companies that do not include the data for "merged on" and "merged with" will not be accepted. MERGES shows the accessible sub functions in the table:
The source keys will be stored in all copied or modified data and also be displayed in the respective overviews. This allows for changes to be tracked and repetition without doubt with changes in the source data, particularly also with simultaneous upstream mergers of more than one company. Nevertheless, these source keys will not be passed on during either a carry forward into the next period or during a transfer to the next fact.
When working with business units, it is assumed that the business units of the merged company will also be continued for the receiving company. When performing this function at the level of the company chart of accounts, it is assumed that the merged and the receiving company have the same company chart of accounts.
The application generates a log report that can be viewed in the MERGES application by taking the action "display protocol". Furthermore, the status of the sub-functions will be noted in the other lines of the processing control system (VERARB).
It is now possible to repeat IC balance reconciliation for individual pairs of companies and coordination groups (KVA) if it becomes known that the IC balances have only changed in terms of this particular coordination group. The respective function is started from out of the "IC clearing list" (KGESGES) using the new line action "Refresh IC clearing". In this case, only this one line in the IC clearing list will be updated.
The voucher number and origin fact are now noted in the transactions generated during generation of development transactions from postings. This information will be retained even with transfer to other facts, if the chart of accounts changes, for instance.
Note: This information can only be evaluated using other applications (e.g. report, "transactions and consolidation postings") if no other comparison keys (company, business unit, period) besides the comparison of the fact were entered during transfer.
The transfer of IC fixed asset transactions to the next fact will now depend on whether maintenance of IC fixed asset transactions has been activated for both the current period (ABR) and the respective fact (FAC).
During transfer of data to the next fact, the data from the new table "product margins" (PROMAR, see above) will now be processed too. With the help of the appropriate new line in the table in the call up application "Create Closing of period new fact" (GESABV), this data can also be reconciled in an isolated manner.
A new separate (transaction development-dependent) line is now available in the table for IC fixed asset transactions for calling up the application "Create Closing of period new fact" (GESABV) so that this data can be transferred in itself and independent of the actual fixed asset transactions.
With a carry forward of development transactions during the course of the year, the switch for the period/transaction development table (ABRSPI) will be evaluated. If this is set to 'M' (Switch off automatic comparison between transactions and account balances) for the target period, transactions with the posting key that have the usage tag 'L' will not be copied from the source period. The difference will have to be explained manually (therefore 'M').
Please note that no carry forward values that make sense result for transaction developments with transaction development areas if the source period is an annual financial statements and is controlled by the ABRSPI switch 'X', while the target period is controlled by the ABRSPI switch 'M'. In this case, carry forward values will result in the wrong transaction development area.
The entries of original voucher numbers and the respective fact that are made when transactions are generated during transfer to the next fact will be noted by the carry forward for the period. In other words, multiple carry forward transactions will be generated if it originated from different vouchers. The reference on the source voucher will then be forwarded to the carry forward voucher as if the transaction had been generated during reconciliation from the original fact from the carry forward posting.
The carry forward of IC fixed asset transactions now depends on whether maintenance of IC fixed asset transactions (ICANLBEW) has been activated for both the previous and the current period (ABR) but also for the respective fact (FAC).
With the carry forward of shareholding transactions (GESGES), no message will be issued anymore if the carry forward shows a positive value, but only if it has changed from debit to credit or vice versa. Therefore, value adjustment accounts can be set up without having to receive any annoying messages.
For fixed asset objects of the card type 'A' (IC disposal) or 'Z' (IC addition) automatic calculation of depreciation will no longer be performed in group currency on the basis of consolidation postings, but rather (if specified) in local currency on the basis of the IC fixed asset transactions. Calculation will therefore be triggered by all changes in IC fixed asset transactions (manual entries, imports, carry forwards).
In case old data that does not contain any information on the values in local currency still needs to be maintained, calculation will continue to be performed in group currency. It is possible, however, to add local currency values in the IC fixed asset transactions later on so that henceforth calculation will be performed in the local currency to ensure that currency conversion effects can be detected and posted.
The overview "currency conversion parameters" (WUM) now makes it possible to make the entries '*' and '%' while selecting a reference company:
When selecting a unique reference company, the parameter set of the company referenced will also be shown in addition to the data sets of the referencing companies.
With currency conversion of development transactions, compensation for differences now also takes place for non-audited, yet consolidated transaction development areas. The reconciliation of value is always the sum of the development transactions of this transaction development area that are to be converted according to the conversion rule of the account balance. Deviations will be compensated for by additional development transactions that have the posting key with the usage tag 'U', if one such has been defined. If the sum of the development transactions from this transaction development area in local currency matched the account balance, this will also result in a match in the group and parallel currency.
The currency conversion of IC fixed asset transactions (ICANLBEW) and IC stocks in inventories (ICBEW) now depends on whether maintenance of these data pools has been activated for both the current period (ABR) and the respective fact (FAC).
With the conversion of IC fixed asset transactions, currency conversion effects will now be determined and compensated for by additional transactions. Currency conversion effects on the carry forwards result from the difference between the closing date rates of the previous and current period and will be compensated for by transactions with the posting key that has the usage tag 'K'. Currency conversion effects on the ongoing changes arise for each transaction development area from comparing the sum of converted transactions with the sum of transactions converted at the closing date rate and will be compensated for by the posting key that has the usage tag 'U'.
By double clicking onto the status column for postings in the table in the application "Company financial statements + monitor for entry" (I-EA) you will now branch off into "Form entry postings" (I-BUCH).
Calling up the form entry for postings has also been enhanced in the action menu (sub-menu "Form entry") in the "company financial statement monitor" (EA) application.
In the past, only reports with report type 'E' were allowed to be used for form entry ('D' as well for development transactions). In the future, reports of the report types 'C' (controlling report), 'P' (multi-period balance sheet/P&L report), 'S' (periodical result of reports for target/actual comparison), 'T' (sub-group report) and 'V' (consolidation report) are allowed, due to the fact that these only differ from the report type 'E' (balance sheet/P&L report) in terms of deviating occupation of columns while the relevant line structure is quite similar for form entries.
Reports that are inappropriate for form entry can now be labeled accordingly. To do so, the "Flag default report" must be placed on the new value 'N' (not suited for entry) in the respective report ID (RID). Then, this report will also no longer be shown in the selection of report IDs in the form entry applications. If this type of report is still shown, it will be rejected by an error message that is issued.
If a report ID is entered that does not have a structure of its own (REPZEI), but rather refers to a reference report ID, then the reference report ID will now also be used to display the form entry.
Entry cells in form entry applications can be locked for various reasons, including lack of authorization, a lock on the company financial statement, the validity of an account, the display of netted values. If you activate the checkbox "display internal info columns" in the menu ‘View’ (see above), yet another column will be offered that shows a key for the cause of the lock. The causes can vary depending on the application. The following values can be displayed:
Now, the changes made in form entry can be saved on an alternative basis by using the key combination ‘Strg’-S instead of pressing the ‘Save’ button.
The completion message from a form entry that is issued after it has been saved and includes the number of records stored will now no longer be issued as a message dialogue, but rather only shown in the message line so that this message no longer needs to be confirmed.
The limitation of form entry of capital and provision transactions to passive positions and accounts has been done away with. One disadvantage, however, is that now all of the balance sheet positions will also be shown if a balance sheet report is used. This can be avoided by marking the report ID (RID) from a specific capital resp. provision transaction development as a default report for form entry.
The structure of the table of the overview "group companies + group monitor" (KTKGES) has now been overhauled, including the table headlines:
With release 2010.1, the sorting of companies in the group companies monitor (KTKGES) has been changed so that the participation level will be used as the first criteria for sorting, therefore the parent company will be shown first. In the past, sortation took place alphabetically by company number. With the new method of sortation it was difficult to find a company in a large group of companies. Therefore, additional sorting options have been introduced so that both alphabetical sorting according to company number and sorting according to participation level can be performed. As in the past, default values can be set for the sorting option in the user-specific startup data (VOR).
The possibility of branching off into the respective detail views by double-clicking has now been extended and harmonized. To prevent processing functions from being started unintentionally, it is still impossible to start these by double-clicking. Branching off depends largely on the status shown in the cell:
Double-clicking onto the check rule results overview (PRFERGK) will allow you to branch off into the check rule status column.
The valuation method is now an optional input field in the single set mask KTKGESE. When entering a new company for group companies, 'N' (Purchase method of accounting) will automatically be entered if the user has not selected any other entry, due to the fact that this is considered to be a mandatory process by both HGB and IFRS.
The entry on a previous period will only be forwarded for processing by the "Group companies + monitor" (KTKGES) list if the actions in submenu "Carry forward ..." and "Automat for consolidation functions" are taken. All of the other types of processing that follow identify a previous period that might have been needed earlier as the last preceding annual period based on the information in the period master (ABR).
The actions "Check & refresh participations" and "Unlock consolidated financial statement" can now also be performed by clicking the mouse on an appropriate icon in the toolbar.
The graphic display of the group structure as a diagram has been completely revised.
Now, the graphic display can be reduced in size or expanded not only by using the slide control you are already familiar with, but also by pulling the marked section into the overview component.
The graphic view of the group structure can now be printed out too. The print and print preview icon from the toolbar will enable you to do this. These are used just like the other printouts featured in IDL Konsis .
In addition, it is now also possible to save the manually configured layout of the group structure display. Technically speaking, this takes place in the help text of the record of group processing controls on the new checkpoint KTKGRAPHLA. This layout will also be copied over to the next period during a carry forward so that the display will only change if the group structure itself has changed.
The action "Unlock voucher" can now also be performed by clicking the mouse onto an appropriate icon in the toolbar.
The overviews "Account balances and consolidation postings" (KONSAL) and "Transactions and consolidation postings" (KONBEW) have been expanded to include the entry of a balance option. Similar to IDL Connector , you can specify here as to whether only company financial statement data (SUM), only consolidation postings (KON) or the sum of both (KTK) should be displayed. This information extends the previous specification with/without consolidation postings from the sub-group (KONO) and can therefore be found in the same non-labelled input field behind Group/Subg in the first line of the mask.
If you select (only) company financial statement data, you can now specify that the values should be shown in local currency in both applications by entering "LW" in the input field entitled "Currency type". Then, consolidation postings will not be processed, not even with the other balance options. If you select multiple companies with local currency, sorting must take place for the most part based on companies so that no interim sums need to be formed using various currencies.
A selection possibility based on account flag has been added to the overview "Account balances and consolidation postings" (KONSAL). As in all of the other applications, two input fields are available to allow you to select simultaneously according to the account flags 'I' and 'J'.
The list "Transactions and consolidation postings" (KONBEW) has now been extended to allow for a transaction development (of the posting key) to also be entered using '%'. This is also the preset value. In this case, data for all of the defined and active transaction developments will be displayed.
A new input field entitled "Display" allows for an alternative display of the data in both a tree structure ('B') and list structure ('L'). All of the hub lines are deleted when it is displayed in the list structure. Instead, the keys for the hub lines will be repeated in additional columns in every line.
Furthermore, the application KONBEW allows for additional detail on their origin to be added to the data, namely
The sums of the postings will still be detailed according to voucher classification (if this has been specified and transferred over to the next fact with release 2011.0). The sums of the consolidation postings will still be detailed after consolidation function (in accordance with classification for the consolidation report). This detailing is triggered by the new balance options "SUM+" (transactions with voucher classification) and "KTK+" (consolidated financial statement with voucher classification).
The sorting options featured in the application KONBEW have been issued three digit keys:
In addition, the following two digit sorting options (without 'S') have now been re-introduced:
With these sorting options, the structural levels transaction development column and posting key in a tree are no longer necessary. Instead, the values are displayed for each transaction development column, similar to the transaction development reports in the table columns. If a column option (new input field) is entered, the display columns from the sums of the individual transaction development columns or other calculations can be formed in accordance with the formulas of the column options. If a column option is not mentioned, then the transaction development columns will be shown as in the past, but in columns instead, not as details. For this version, table headlines should be issued for the transaction development columns in the "transaction development columns" (SSP) application. Lines for individual data records are no longer used in this display version.
Note: The combination of the entry transaction development = '%' and the sorting options 'GK' and 'KG' only makes sense if the transaction development column numbers were issued in a uniform manner across all of the transaction developments.
Among other things, these extensions allow for the report entitled "Grand Livre" that is so popular in France to be presented.
A new overview entitled "Capital and Minority Interests" provides you with an overview of all of the data that has been processed during consolidation of equity and minority interests. This overview can be found in the menu tree in the branch "Consolidation / Group consolidation" and can also be called up as a follow-up action in the "Group companies + monitor" list (KTKGES, Sub-menu "Lists") or by using the short name "KONKKFF".
The overview requests clear specification of the keys group/sub-group, (subsidiary) company, period and fact. A business unit can be entered on an optional basis. The selection area also contains a switch "Including sub-group", that is activated on a standard basis so that the data from subordinate sub-groups can also be taken into consideration.
This overview shows the following in the table:
A multi-level tree structure will be shown in the lines. The top hubs of this tree form the following specialized blocks:
Amounts from the company financial statement of the company will be shown for the respective accounts and from consolidation postings from the consolidation processing types KK, KF, FK, FF, KS, KX and SD that are displayed respectively in the proper columns. With quota companies, the quota shares of the company financial statement values, but the full posting amounts will be displayed. The values will be shown without debit/credit tags with plus and minus values (S=+, H=-).
Records for the new checkpoint KTKGRAPHLA are also displayed in the group processing controls. The only purpose of this is to allow for the layout of the group structure diagram to be saved in the help text assigned. Due to the fact that viewing or editing this information really makes no sense, the call up of the commentary functions will take you to the graphic display of the group structure (KTKGRAPH).
The function "Check & refresh participation" now issues a warning if there are carry forward transactions in the shareholding (entered either in an automated or manual manner) whose transaction date does not match the first day of the current period (first day after the last annual financial statement). Deviating entries can result in false interpretations of the shareholding relationships at some point in the future.
To avoid consolidation vouchers in which business units are not entered in their entirety, the decision was made that no consolidation processing is possible on facts in which the switch for maintaining the data with a business unit entry has been set to 'M' (mixed). Either an 'X' (consistent with the business units) or an '-' (consistent without business units) must be entered here.
The functionality of the method "Goodwill IFRS" for compensation of the difference from first consolidation, especially the entry of goodwills in local currency, is now available for all types of compensation. No new functions were created for this. Instead, the old functions have been extended. The masks now include additional input fields for company, business unit, currency code and value in local currency. Entries in these fields are only allowed if they are posted to fixed assets. This is possible in all types of compensation except for liabilities and retained earnings.
The action "Curr.conv.diff. goodwill IFRS" that can also be activated from out of the application "Group companies + monitor" (KTKGES) has now been given the somewhat broader name "Currency effect - Compensation temporary diff. from first cons." and is called up for the first time immediately after the differences that have been compensated have been entered.
In the event that the difference in local currency is to be compensated with the company to be consolidated, a posting pair will be formed with the consolidated company, namely from the compensation account from KTKPAR or the account entered in VUBE against the KTKPAR account "Difference amount". The KTKPAR account "Compens. diff. amount in local curr" (formerly "Reserve goodwill IFRS") is not necessary.
If "compensation difference from first cons." in local currency is performed with a different company, two posting pairs will be formed: the first posting pair from the KTKPAR account "Compens. diff. amount in local curr" against the KTKPAR account "difference amount" with the company to be consolidated; the second posting pair from the compensation account from KTKPAR or the account entered in VUBE against the KTKPAR account "Compens. diff. amount in local curr" with the company that differs.
The "Capitalise Goodwill IFRS" function that used to be separate has now been discontinued as a result of this change. Its functionality has been integrated into the general function "Capitalise Goodwill". The checks for accounting treatment 'I' (IFRS) have also been discontinued. The terms used for the respective attributes in the fixed asset object master have been made to be more general.
When calculating the difference that results from ‘Difference amount subsequent consolidation’ (KB), vouchers from dividend payments (SD) and the respective development repostings (SU) will now be taken into consideration, in addition to the vouchers from capital consolidation.
It is now possible to repeat consolidation of debt or consolidation of income and expenses and consolidation processing for individual pairs of companies if it is learned that the IC balances have only changed in terms of this one coordination group. The respective function can be performed from out of the "IC Clearing list" (KGESGES) using the new line action "Refresh IC clearing". Only this specific consolidation voucher will then be updated. Depending on the type of IC clearing that took place before, SK or AE balance reconciliation in the company financial statement (starts from the company financial statement monitor EA) or SK or AE Consolidation (starts from the Group Companies Monitor KTKGES) can be repeated for the pair of companies that has been chosen.
Differences that exceed the threshold values entered in the consolidation parameters can now be posted automatically. To this end, the action entitled "Post non-cash difference" has been added in the "IC Clearing list" (KGESGES). When this function is selected, the amount that appears in the column entitled "Non-cash difference" but has not yet been posted will be reposted to the threshold value account specified in the consolidation parameter. Here, a distinction is made between differences that appear in the difference account and open differences. In the first case, they will be reposted from the difference account to the account listed. In the second case, the open differences will be posted unilaterally to the account listed.
Currency conversion effects that occur during elimination of interim results in fixed assets can now be calculated and posted. The main prerequisites here are that
In contrast to the methods used earlier, the elimination of interim results in fixed assets no longer needs to be performed during the first period, but also in all of the following periods until the depreciation duration has come to an end to ensure that the depreciations and currency exchange rate effects are posted into a new 'ZA' voucher, which is summarized during the carry forward with the existing 'VX' voucher. The 'ZA' status in the Group Monitor (KTKGES) is entered accordingly with the status refresh.
Entries in the new table "Product Margins" (PROMAR, see above) are evaluated during elimination of interim results in current assets. If no overhead/direct percentage or amount is specified in an IC stock inventory (ICBEW), then the overhead/direct percentage values on the respective keys (supplying company, receiving company, product/product group) from the "Product Margins" table will be used. This allows for the data to be maintained separately for the supplying and the receiving company.
The controlling objects that can be entered on the accounts for differences from the currency conversion in the currency conversion parameter (WUM) since release 2010.1 will now also be put to use in currency conversion for compensation postings, but also by other applications (capital consolidation, minority interests) if this data generates in difference accounts with controlling switches that have been placed.
The Balance Differences viewer, a new application component that can be activated in the Options dialog (page “Planner Spreadsheet”), displays a list of all account, controlling and intercompany balances, which differ between the table area of the current scenario and KTOSAL/CNTSAL/ICKTOSAL. Additionally the table cells with differing balances can be marked by an icon. The list allows updating single balances in the scenario. A filter allows restricting the displayed balances (and thus the balances to update) to specific periods, positions and accounts.
Whether balances are automatically loaded from KTOSAL/CNTSAL/ICKTOSAL into the scenario for company/business unit combinations that have never been used in new scenarios can now be switched on or off in the Options dialog. If the option is switched off, the table area of new scenarios is always empty and can optionally be updated for specific periods or cells.
“Paste structure” now also pastes all controlling balances of the previously copied cells.
If scenarios exist after updating to a new release that haven’t been converted to the new version, a dialog appears at each start of FORECAST asking if the scenarios should be converted.
The Leasing Rule was introduced as a new rule type. It enables planning and calculating leasing business cases (with/without input tax, with/without leasing object capitalization, with/without depreciation, calculation based on leasing payment or effective interest).
Until this release all standard rules (Sales, Purchases, Personnel etc.) calculated in both directions, i.e. changing the account entry created by the rule in a profit and loss account will result in a changed account entry in the balance sheet account and changing an account entry in the balance sheet will change the profit and loss statement. Since this release each rule has a leading account entry (e.g. the one in the sales account for a sales rule). Only changing this account entry will cause a recalculation of the rule.
Each time a rule template is used, a copy of the rule template is created and displayed in the new application window “Used Templates”. A click on a rule template copy in this window shows a list of all business cases created from this rule template in the business case viewer. A click on a business case in the business case viewer selects the rule template in the “Used Templates” window from which the business case was created.
A new menu entry in the rule templates tree “Only Show This Set” will hide the rest of the rule template tree except the selected rule template set.
Clicking on a business case in the business case viewer will highlight the account entries for that business case in the account viewer and vice versa. Additionally, the number of the business case can optionally be displayed after the name of the account entry in the account viewer.
In the business case viewer, multiple business cases can now be deleted at the same time.
You have now the possibility to analyse complex calculations. For this purpose you have to activate the analysis tool. First you have to activate the option "Activate calculation statistic" on the page "Planner spreadsheet" of the options dialogue, then you have to activate it in the planner spreadsheet itself.
The application of this tool is emphasized only to very experienced users, since the features and evaluations are very complex. Furthermore please mind, that the analysis tool requires very much memory and therefore strong adversely affects the performance.
The tool displays different statistics about the calculations. There are general statistics like e.g.
as well as a detailed protocol of all modifications that were performed at the calculation.
The rules for assigning a reference report ID have been loosened. For instance, another different type of transaction development report, a transaction development report that covers more than one transaction developments (report type 'D' without a transaction development ) or also a balance/P&L report (report type 'E') can now be assigned to a transaction development report (report type 'D' + Transaction development ) as a reference.
The table of report line descriptions (REPZEI) has now been extended by adding two attributes:
"The number of expanded details" specifies a number of levels that should open up automatically in order to display the report result the very first time that the report result is displayed. This value is entered in the report result and evaluated during display of the report results. This means that subsequent changes in the report line descriptions will have no impact on the display of existing reports.
"The number of expanded details" can only be entered for 'P1'and 'P6' positions. In addition, with 'P6', no value higher than 1 may be entered due to the fact that the detail for the subordinate positions has to be specified separately.
"Restriction of data origin" can only be entered for transaction development reports (report type 'D'). This attribute can accept the following values:
With entry of a restriction based on origin, the report will only process data that comes from the respective origin for this position. The development transactions will be analyzed for whether they contain the entry "Posting from fact".
A new report option 'E' that has the meaning "Transaction development report with BKL and KVA details" has now been introduced. This report option can only be entered for transaction development reports (report type 'D'). The functionality of this option can be used mainly when the new entry "Restriction of data origin" is used in the report line description (see above).
When this report option is entered, the report program will generate the report result with the following special features:
The prerequisite to structuring based on voucher classification (BKL) is that the respective company financial statement vouchers have been issued with a voucher classification. In addition, this option can never be used for data processed with a release version older than 2011.0 (that means transferred over from previous facts).
The action "Disable report lock" can now also be carried out by clicking onto the respective symbol in the toolbar with the mouse.
The multi-period reports for the cash flow statement (report type 'Q') now also allow for these to be generated with decumulated data (for each period, the difference to the previous period is displayed). The decumulation switch in the report header (REPE) can also be used for this purpose with this type of report.
The combination of a cash flow report (report type 'F') and a controlling report (details of the controlling accounts by controlling object) is now also available for company reports. This is controlled via the report option 'C'. This also applies for the types of reports that were previously controlled using the report option 'D'.
It is now possible to generate transaction development reports that also take postings to the transaction development accounts to the same fact into consideration, in addition to development transactions. To do so, you must enter the new entry value 'B' (company / sum total with postings) in the field entitled "restriction" of the respective report header (REPE). The sum of transactions and postings will be then displayed as a hub for each account. After you've opened up this hub, a line that contains the (previous) data from transactions and the second line that contains the values from postings will be shown.
In response to the many different demands, a new database table for report results has been created that offers additional possibilities, with respect to additional detail levels, for instance. In most cases, the user will not even notice this change. If a report is generated again using release 2011.0, the result will always appear only in the new table. Any other result that may have appeared in the old table will be deleted.
Due to the huge volume of existing data, the decision was made not to transfer over data from the previous result table to the new table by way of conversion. Rather, the programs for displaying the report results (REPERG, REPERGS, REPERGV) were given the ability to display either data from the old or the new result table on an alternative basis, depending on the report.
It is impossible to display data from the old and the new report result table simultaneously, however. This applies to displaying multiple company reports by entering company = '%' as well as to comparing reports (REPERGCOMP). An error message will result if this type of selection has been made.
The new report result table is processed together with the old table on an optional basis as part of the sub-group data exchange.
The new detail option 'B1K' is now available for displaying report results. When this detail option is entered, the first detail level of the respective report will always be shown beneath the position. The accounts will be shown underneath it and then any additional detail levels, if there are any. Which of these is the first detail level will depend on the type of report, the report option and other parameters.
The detail option 'B1K' can be entered as a default value for a report in the report header (REP/REPK) just like other detail options.
The key column will now be issued inside the permanent section of the report results display (assuming the option "display key column" has not been blended out). The main advantage of this change is that the key column will be repeated on every page when the report results are printed out. In the past, this information was only contained in the first part.
With respect to branching off from the mirrored report results display (REPERGS) into the normal view (REPERG), the detail option 'BK' (previously 'P') will now be preset as long as the report header does not show any other standard value.
The list "Report compare" (REPERGCOMP) now makes it possible to also display multiple columns contained in the two reports that are to be compared. To do so, a column option (new input field) is to be entered in the selection area. The columns for the main report will be labelled as described in the column option. Two columns each that show the value of the comparative report and/or the difference between the two reports will follow after them.
As a way of reducing the size of the database that has grown over the years, deleting old report results often makes sense. Now, this is also possible for periods in which the ABR switch "ex KonBuch" has not been activated. Report results from these periods, but also all of the other report data, can be deleted now.
With release 2010.1, the column options for consolidation reports (formerly '#KVA', '#KVAMB' and '#KVAGE') have been individualized and renamed '$KVA', '$KVAMB' or '$KVAGE'. For this reason, these options will no longer be available to customers who installed release 2010.1 as their first version of IDL Konsis . A dedicated directory entitled "Spaltenoptionen_Konsolidierungsreport" has been set up in the path "LieferBatch" on the release CD so that they will also be able to use these options (at least as a template). This contains TXT files for use in importing this data.
The terms "column option" and "column" have been replaced by the terms "formula group" and "formula" in the formula editor (FED), due to the fact that formulas can be entered not only for column options, but also for performance indicators.
To further extend importing to include the possibility of having an import file with an individual import format include commentary lines, the table "Import/Export Formats" (IEF) has been extended to include the following attributes:
As part of these changes, previous testing for permanent issuing of the first two positions of an '#TXT' format with 'KP' has been discontinued.
Two additional columns have been added to the table of Importing/Exporting Formats:
During importing via the special importing database tables (Ixxx), the importing log report will also be written in a database table. Therefore, it can be viewed not only by the current user, but also by everyone else who uses the database. This possibility now also exists for conventional importing via files (.txt, .csv etc.).
A checkbox entitled "Import Log in Database" has been added to the options dialogue, tab ‘Import/Export’ for this purpose. If this is activated, a job number will be issued for the importing transaction and the importing log report will be written in the database. If an import is called up via the command line, the new parameter "/WITHIMPORTJOB" has to be entered.
Importing jobs produced in this way are issued with the value "#FILEIMP" as a tag in the supplier field and "File: ‘File path’" in comments. The respective job login report is now stored in the login report table and can be accessed by the respective job as usual. This contains the following additional (language-dependent) entries:
These additional log report entries are now also contained in the file log report.
After copying an importing job that has already been completed, the call up application "IE Job Controls" (IEJOB) will issue a notice in case the user of the original job is not the current user. After all, the copy job that includes the current selection limitation might otherwise not appear in the table after copying.
If a job that has already been started is to be reset and performed once again, the log report of the new instance of execution will now be added to the one that already exists. The ongoing line number will increase accordingly.
The following additional tables and importing formats (Format type '#DB') have now been introduced for importing via special database tables ("I tables") instead of files:
Like the "I tables" defined earlier, the new "I tables" also contain columns for all of the fields listed in import format. These tables can be filled using tools like IDL Importer by entering a job number.
With respect to importing positions/account allocations, the chart of accounts no longer needs to be specified clearly; therefore data for multiple charts of accounts can be imported in a single step. However, even if a chart of accounts is specified, only data for this chart of accounts will be processed. If the action "Delete + Import ..." is performed, the limit to one chart of accounts will remain.
During external call ups aimed at reading in data from foreign systems (Menu items "UNL..."), the Ex-fact can now also be set as parameter 44. This can be used for later direct importation, for instance, using the IDL Importer .
It is now possible to enter the table captions and commentary lines in individual exporting formats. In the past, this was only possible with exporting in the standard format '#TXT'. Commentary lines include all table lines that do not represent modifiable data lines, in other words sum lines or hub lines of tree tables, for example.
For this reason, the table "Importing/Exporting Formats" (IEF) has been extended to include the following attributes:
As part of this change, the previous fixed assignment of the first two positions of a '#TXT' format with 'KP' has been discontinued.
The group-wide and group/sub-group exchange of data has been modified to include various database enhancements. For this reason, they are not compatible with previous release versions.
The SAP Interface that includes the use of IDL Importer (kcusap.jar) can now also be used in configurations with an application server.
Transaction data can now also be read on an individual basis for each evaluation area. To do so, the SAP option dialogue has been extended to include its own tabs for fixed assets, capital, provisions and other types of development transactions. A default assessment area that can still be written over in the registration window can be entered here. This parameter is passed on as an importing definition variable (sAfabe) in the IMD file and must be taken into consideration accordingly in the scripts when SELECT is called.
The release 2011.0 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: