This release IDL.KONSIS.FORECAST 2008.0 is a main maintenance and therfore must not be left out in the release sequence. Prerequisites for this release are the last main maintenance 2007.0 from September 17th 2007 as well as Update A for this release from October 16th 2007.
The supplements of the interim maintenance IDL.KONSIS.FORECAST 2007.1 as well as the corrections to these maintenances up to the release date are included in the main maintenance 2008.0.
This documentation describes the enhancements since the previous interim maintenance IDL.KONSIS.FORECAST 2007.1. If the last interim maintenance hasn't been installed yet you are recommended to catch up on the enhancements of the interim maintenance 2007.1.
Due to the enlargement of the IDL product family (see below) the topmost menu node is no longer "KONSIS" (or "WINKONS", respectively) but rather "IDL PLUS". The consequence is, that a user allocated to a customer specific authorisation group possesses no menu authorisations at all until his authorisation group is authorised for the menu item "IDL PLUS" (see below). Thus the allocation of the new menu items for the customer specific authorisation groups has to be performed by a user allocated to the standard authorisation group (IDLADMIN or IDLWINAD, respectively).
This procedure is not required, if the user specific authorisation group is allocated to a standard authorisation group as emphasized since release 2007.1.
Group transactions (fixed assets, capital and provisions) are no longer supported with this main maintenance 2008.0 (see below). These data are redundant to the consolidation postings and don't contain additional information. If not yet performed the users are challenged before installation of this release
As announced for more than one year the IDLCONNECTOR does no longer support the version MS Excel 97 with the current release, particularly since the hotline service was also ceased meanwhile for MS Excel 97 by Microsoft. Please upgrade to a newer Excel version.
Furthermore additional functions are planned for release 2009.0 that require at least MS Excel version 2003. Therefore we recommend an upgrade to MS Excel 2003 or, even better, MS Excel 2007.
The user interface was restyled more clearly and up to date by several effects described in the following. However, most of these effects can be deactivated. For this purpose a sliding bar was supplemented on page <View> of the options dialogue (Menu -> Options -> Options). At position "less effects" the user interface is presented widely like up to release 2007.1. The new check box "Panels relocatable" on this page serves for this purpose, too. It can be deactivated, if this feature (see below) is not to be used.
A more clear alternative to the ressource tree called "Quickstart" is now available for navigation in the menu tree. Quickstart displays only the currently selected level of the menu tree by buttons. In additions the top button provides a back step to the next upper level. Quickstart just like the ressource tree can be activated or suppressed by entries in the menu <View>.
Quickstart displays the components of the IDL product structure (see below) with new product symbols.
The side bars of the application window are wider than before. The application areas (selection area, list table, single record area etc.) can be dragged and dropped into the side bars with the mouse providing more screen space for other application areas (table e.g.). The opposite mouse movement recovers the displaced areas. A different arrangement of the areas (different order, beside each other e.g.) is possible, too.
The ressource tree as well as quickstart are displayed in the left border by default. These areas open at mouse click on them an close automatically at subsequent actions. On demand these areas can be displayed permanently in the application area, too.
In the same way other panels (selection area, table, single record map) can be dragged and dropped into the left or right border or to other areas of the window (above each other, beside each other, behind each other). The menu item <Reset desktop> in the menu <View> serves for relocation of all panels to their standard positions.
The backgroud of the different areas as well as table headers and other control elements were designed more pleasant colour gradients.
Fields belonging togehter (prompt text, input field and translation e.g.) are thinly underlined emphasizing the togetherness of the fields in the selection and single record areas.
The sizes of the input fields are adjusted to each other, so that most of the columns in the selection and single record areas exhibit the same width and therefore provide a more clear layout.
The buttons for activation of selection lists (arrow to the right) and drop down boxes (arrow down) are no longer displayed permanently in the input windows but rather only when positioning the cursor or the mouse pointer into this input field. This provides a more clear layout of the entry maps, too.
The short name input field in the line with the tool bar was set to an width appropriate to its input possibilities.
Multi line headers of table columns are comprehensed in the top lines, if the texts are identic. Thus in some cases more elaborate texts are possible. Up to now this control was only available for the print view.
The picture referenced by "Logo for Printing" on the page <Print> of the <Options> dialogue now is displayed in the right side of the selection area, too, just like in the print view.
Up to now the selection lists displayed only one line, if the key had been entered already uniquely in the calling map. The button <New Choice> had to be used for display of all possible antry values. Now all possible antry values are displayed at once while the table is positioned on the preselected value, so that the attributes of the preselected value can be seen at once.
The only exception is a partly qualified entry of the key using the wild cards '%' or '_'). Then like up to now only the subset suitable to the entry is displayed in the selection list.
The texts of the buttons for control of the processing ("OK", "Continue" etc.) in the message windows of several applications were replaced by meaningful texts. In some cases these texts are multiline.
The "project" is no longer displayed in the status line at the bottom of the application window since it was always equal to 'KON'.
The possibility to suppress message windows at mass processing (see "Release 2007.1 News") was supplemented for several other applications.
Further new control elements (Excel-like entry in a table, leaded dialogues for entry of data with allocation facilitiy, display of T accounts) were developed for the new product IDL.FORECAST.
Group transactions (transaction development changes by consolidation) have always been redundant to consolidation postings. They primarily served for a joint selection of development transactions from company and group financial statements. In the meantime a joint selection is available for company development transactions and consolidation postings, too, by the new application "Transactions and consolidation postings" (KONBEW).
Furthermore group transactions served for creation of transaction development reports on group level. With release 5.2.0 from 2003 the flag "ex KONBUCH" was introduced in the period master data (ABR) for control, whether consolidation postings are to be used instead of group transactions when creating reports.
Reports should result in the same values, if both data stocks really are redundant. However, this is not necessarily true. Group transactions and consolidation postings act different especially at period carry forward, e.g. if postings on development transaction accounts are contained in single-use vouchers. For this reason the period carry forward of single-use vouchers was revised with release 2007.0 (for this see chapter Period Carry Forward Group Financial Statements), too.
In addition the list applications for development transactions (ANLBEW, KAPBEW, RUEBEW) contained the extra function "Check group transactions / consolidation postings" since some time for determination, whether both data stocks were consistent or which differences existed. The usage of this function was recommended, since IDL had announced with release 5.4.0 from 2005 the intention to abolish group transactions.
After this long scheduling time group transactions are no longer supported with the current release. I.e. all consolidation function generate only consolidation postings but no more group transactions. However, at repetition of consolidation functions group transactions already existing furthermore are deleted. In addition new periods can be defined only if the flag "ex KONBUCH" is set on.
For closed periods whose flag "ex KONBUCH" had not been set no more data may be entered or changed. The period is locked against changes. Group transaction development reports cannot be created, too. Changing of data (company or group financial statement) is yet possible again after setting of the flag "ex KONBUCH". However, this setting is irreversable.
Group transactions are no longer carried forward, currency converted and processed by the sub-group data exchanged, too. Therefore it is recommended to proceed the group carry forward into the first period without group transactions yet with the current program. Exception is the archiving function of the data exchange (KONDAT). Here group transactions are still processed and deleted.
Intercompany fixed asset transactions are excluded from these changes, although they formally represent group transactions. However, they are required for elimination of fixed asset results (ZA).
A benefit of these changes exists with the fact, that the entry field for group/sub-grooup in the list applications for development transactions (used for selection of group transactions or, via input '*', of company transactions) is no longer required for its old purpose. Thus this field can be used for selection for group companies just like in the list applications for balances and postings. The entry of a group/sub-group restricts the displayed data to companies belonging to the group companies.
This change causes, that group companies no longer can be displayed in the usual transaction list applicatioins. Therefore three new list applications (Group fixed assets transactions/KONALNBEW, Group capital transactions/KONKAPBEW, Group provision transactions/KONRUEBEW) were realised to display the old group transactions. Here the function "Check group transactions / consolidation postings" is still available. Changing possibilities (single record, mass update, mass copy) are not provided.
A possibility to define hierarchies was realised for controlling objects of the first contolling dimension (usually cost centers) and business units (comprehensively named "objects" for simplification in the following). For this purpose an attribute "Flag of aggregation" was supplemented in both tables (CNT, UBR). Objects representing aggregations of elementary objects (without flag of aggregation) are designated with this flag of aggregation.
The new applications "Hierarchy of controlling objects"(CNTCNT) and "Hierarchy of business units" (UBRUBR) (contained in the branch <master data> of the ressource tree) serve for definition of the hierarchiy of the objects. You have to enter pairs of superordinate and subordinate objects. Objects without flag of aggregation may not be used as superordinate objects.
It is recommended to define one unique top node for each hierarchy that characterises the subordinate structure. Parallel structures with different top nodes can be defined for controlling objects as well als for business units.
With specification of a unique top node as superordinate object and without entry of a subordinate object (or entry '%') the selected list is displayed in a tree structure, where the superordinate object is the to node. The details result from the defined allocations. A check of the structure is included here: An error is reported
At all other selections the display is performed as a simple list sorted by superordinate and subordinate object id.
Reported data as well as company/business unit allocations may only be inserted for elementary objects. Thus only objects without flag of aggregation are offered in the selection list at data entry. In addition the flag of aggregation for an existing object may not be set subsequently if reported data already exist for it. On the other hand the flag of aggregation must not be deleted for an object, if it occurs as superordinate object in the hierarchy table.
The entry of business units or controlling objects with set flag of aggregation is allowed in the list applications for reported data. Then the list table is set up with a tree structure for each account or account/controlling object combination. This represents the hierarchy defined in UBRUBR or CNTCNT, respectively. The values are aggregated in the tree structure and total values are output in the lines for aggregations objects. However, in case no longer single data records are displayed but rather aggregated values, if there is more than one record per KTO/CNT combination. If there are no data, the corresponding branch is suppressed. This selection provides complete data only if you enter the top node of a hierarchy and all elemantary objects are contained in this structure.
In this first instance this functionality is supported in the following applications:
In addition the company has to be entered uniquely in all cases.
On demand the evaluation of hierarchy allocations can be supplemented in other applications, too (e.g. further list applications, report generation, MIS/OLAP preparation).
All list applications with the ability of adding help texts, i.e. master data as well as reported data, now display an additional column with header text 'H' (tooltip "Help text status"). This column indicates the existance of a help text for the object of a line by a green cell or a green check mark.
For reported data as well as for master data without multi-lingual descriptions (companies e.g.) there is only a distinction between "help text exists" and "no help text exists". For other master data <green> is only displayed, if a help text exists in the preselected language or the language of the user. If there is no help text in this language but rather in another language, then a <yellow> cell or a deviating symbol (reversed hook) is shown.
A double mouse click on these cells opens the help text display window for the respective help text, with status <green> in the preselcted language, with status <yellow> in another language.
The display of this column can be activated or deactivated by a new check box <show helptext infos> in the menu <view>. The deactivation may be useful for smaller response times of larger lists.
The option Print with help text (in tab <Print> of the options dialogue) now works for reported data, too. If reported data contain help texts, they are inserted into the printed table.
Similar to the master data the single record applications for reported data (e.g. Posting (BUCHE), Account balance (KTOSALE)) the information of the last modification (who and when) of the help text was supplemented. Thus the single record maps exhibit, too, whether a help text exists or not.
Furthermore a facility for linking to external documents (e.g. contracts, bills, specifications, calculations in excel, word or pdf format) belongig to a data record was supplemented. These links are saved in a special area of the help text.
Thus the help text editor was enhanced by a menu <external link> containing the two menu items <add link> and <delete link>. When activating <add link> a file dialogue opens, where you can select the file to be linked. Alternatively files files from other areas of the user interface (e.g. an opened Windows explorer) can be dragged with the mouse into the help text window and dropped there. This way you can add several links one after each other. The selected file(s) are displayed in the bottom of the edit window below the header "external links". After marking a link with the mouse it can be removed via menu <delete link> or using the delete key.
A list with links on external files is output in the help text display following the real help text. At mouse click on this link it is attempted to open the file with the appropriate application (behaviour just like Windows explorer).
The help text status column mentioned above does not distinguish between the real help text and links on external documents. However, a corresponding enhancement is planned for the next release.
It is important for application of this new feature, that the linked documents are available for all IDL.KONSIS.FORECAST users. I.e. the documents shouldn't be placed on local computers but rather on server directories, that all users access using the same drive identification.
The IDL product family was extended by the application IDL.FORECAST for planning tightly related to IDL.KONSIS.FORECAST and working with the same user interface. In addition in the medium term the integration of the OEM products IDL.IMPORTER and IDL.COCKPIT is planned.
For this reason the menu structure of IDL.KONSIS.FORECAST was newly designed. The top node was named IDL.KONSIS.FORECAST corresponding to the superordinate concept of IDL. Beyond this you find the following nodes:
The modified sequence of items is reflected by the sequence of the chapters of this documentation, too.
The application IDL.FORECAST requires a corresponding licence as well as a separate login for the database. For this purpose provided the licence exists an additional check box <Activate Forecast;gt; appears in the login dialogue (perhaps at the second start of the application). After marking this check box an additional entry field <database host:port> appears where you have to enter the name or IP address and separated by ':' the port number of your database server. The port number has to be entered inly if deviating frm the default of the database system. At unclarity please contact yout IT department.
The new application IDL.FORECAST can not be run with the standard edition of the database version IBM DB2 7.2. We recommend to upgrade to version IBM DB2 8.2 or 9 in this case.
IDL.FORECAST is a product of its own besides IDL.KONSIS.FORECAST in the IDL.KONSIS.FORECAST product family supporting planning activities. It has to be licensed separately. The change documentation in this text shall be provided for both products, since they run using the same user interface and share several data of the database. In addition releases and updates are scheduled für both products in the same cycle.
IDL.FORECAST is delivered with release 2008.0 in its first version. Users wishing to use IDL.FORECAST yield an introduction by IDL consultants. Therefore the scope of operation shall be outlined only roughly in this documentation.
In this first version IDL.FORECAST primarily consists of an application for entry and display of plan data for company financial statements, that can be invoked via short word PLAN. This application requires key values for a company, in case a business unit, and a scenario.
The term scenario is new. A scenario comprehenses an entry structure (corresponding to a report structure in IDL.KONSIS.FORECAST) as well as a collection of periods and facts that define,
As a rule you use different facts for the different types of values. In addition you can chose a time pattern for the plan values (yearly, quarterly, monthly).
The choice of the scenario builds an area of its own in the application window, that can be dragged and dropped due to the possibilities mentioned above. This area also allows the definition of a new scenario, that is supported by a guided dialogue ("wizard"), where you can enter the required parameters or allocate them by mouse operations.
The entry form is build an displayed when pressing the button <Display>. In the vertical it represents the report structure of the report ident allocated to the scenario displayed as a tree. Thus at start e.g. only the nodes "Assets" and "Liabilities" are displayed. These nodes can be opened until the amounts of the discrete accounts are shown. The position totals are automatically calculated from the account balances.
In the horizontal the periods are listed. Different value types (actual/forecast/plan) are characterized by different colours. If interim statements (quarterly, monthly) are selected by the scenario these can be opened or closed in the time pattern.
Now the values for the plan periods can be entered or modified. You can enter values for accounts as well as values for positions. Entries for accounts are automatically calculated into the superordinate positions. In addition entries for positions are automatically split to the subordinate positions and accounts. You can choose between different splashing rules (summarize, splash equallly or percentally). On the other hand you have facility to copy values, e.g. for usage of the actual values as a basis for plan values.
Furthermore special rules can be applied to describe dependencies between certain accounts or positions and calculate according values automatically. As a first rule the dependency between sales, receivables and taxes is supported. Further rules will be added in the following releases.
The effects of the application of these rules are stored to reconstruct the composition of a certain value. The composition is visualised in the form of T accounts. T accounts (for the cell currently selected) as well as rules are displayed as areas of their own in the application window, that are displayed below the table area by default and can be dragged and dropped due to the possibilities mentioned above.
For the time being the entered data are only held in the main memory. They are written into the database and thus become permanent when pressing the button <Save>. Thus an effective work is supported especially if using slow networks.
This first version is restricted to plans on the level of account balances, that are stored in the same database table as for IDL.KONSIS.FORECAST. Thus the actual data from IDL.KONSIS.FORECAST can be used. On the other hand you can process plan data with IDL.KONSIS.FORECAST functions (e.g. Create company closing / new fact, Currency conversion, Consolidation functions) licences for IDL.KONSIS.FORECAST and IDL.FORECAST provided. The support of other data stocks (intercompany account balances, controlling balances, development transactions) is scheduled for the next releases.
IDL.KONSIS.FORECAST can be run in a browser (MS Internet Explorer, Mozilla Firefox) with the current release 2008.0. Therefore you have to enter the address of the start page idl-applet.html from the directory ...\load of your IDL.KONSIS.FORECAST installation in your browser. In addition you have to enter name and port number of yout host (application server) when logging in.
The functionality of IDL.KONSIS.FORECAST is not restricted in this variant, thus representing an alternative to the usage of the internet client.
The displayed number of transferred table lines now is the same on the network client as well as on the standard client for the case that errors occurred during reading of table lines providing an abort of the transfer of table lines. Up to now the count on the network client stopped at a smaller number in this case.
The new application IDL.FORECAST can not be run with the standard edition of the database version IBM DB2 7.2. We recommend to upgrade to version IBM DB2 8.2 or 9 in this case.
The option <Merging table headers> in the tab <Print> of the options dialoge has been abolished. Rather the merging of identical lines of table headers is now performed always, since this also happens on the screen and several table headers have been configured for this purpose and would demand too much space otherwise.
For unification of online display and print coloured status cells are printed without black text ('E', 'W', 'X', ...) as performed for the screen display already. If you are printing on a black and white printer not differentiating between the colours you should switch off the option for colour print. Then the characters become visible again automatically.
The conversion program for this release performs the following conversions:
In addition all conversions of the interim maintenance 2007.1 are proceeded, if this interim maintenance had not been installed.
The calling programm "Release upgrade" (KONVERT) suppresses lines for previous release migrations no longer executable, if they haven't been performed. Thus migrations before first installation of IDL.KONSIS.FORECAST as well as migrations for skipped interim releases are invisible. Only migrations, that are executable or have a migration protocol, are displayed.
Furthermore a status colum was supplemented. This column displays the status <green> for migrations carried out and the status <red> for migrations not yet performed.
The following menu items are new with this release. If completely entered customer specific authorisation groups are used, authorisations (BENMEN) for these menu items have to be provided. As a rule the authorisations of the user groups IDLKON or IDLWIN may serve as a sample.
As an alternative solution to the complete definition of authorisations for all menu items the new procedure for simplified care of customer specific user groups is recommended. With this functionality the new authorisation level '0' can be entered for menu authorisations (BENMEN), too. It declares, that a menu authorisation issued for the reference user group is not issued for the given individual user group.
The logging of changes of master data (feature at the customer's expense) now is available for table A032 for user authorisations for objects (BENOBJ: groups, companies, facts), periods (BENABR), and menu items (BENMEN).
For the purpose of activation of the master data logging you enter the respective table name in the application "Control of Master Data Logging" (LOG) and select the action <Activate Master Data Logging>. The current state of the entered database table is copied into the log table by this action. Please mind that no other users are connected with the database when activating a master data logging. From then on all changes of this table are recorded in the log table.
New list applications provide for display and analysis of the logged data:
These list applications display the log records, allow selections for the important attributes (like the original allocation data list) and, in addition, questions for the kind (insert, modification, delete) and timestamp of the change. All changes after a certain timestamp can be selected as well as the state of the original table at a certain timestamp.
Advice: The table "Menu authorizations modifications" (BENMENLOG) contains only data modified by the user for individual authorisation groups (not beginning with 'IDL') or customer specific menu items (beginning with '$') but not data delivered by IDL with release upgrades.
The new extra authorisation level '3' can be assigned to the authorisation for companies in the application "Startup data + authorisation". Like authorisation level '2' authorisation level '3' restricts the user to companies allocated in "Object authorisations" (BENOBJ). However, when changing company master data (GESE, TXTGES) only the update of the company charts of controlling objects is permitted.
Working with IDL.KONSIS.FORECAST requires the definition of a set of startup data and authorisation (VORADMIN) for the user. Startup data in turn assume a set of master data (default values for group/sub-group, company, period, fact, currency code etc.). The construction of these data requires further master data to be previously defined (company xhart of accounts e.g.).
The new single record application "Data for first startup-data" (VORINITE) serves for the initialisation of an empty database, where the necessary master data including the startup data for the first user can be entered in one go. As far as possible the entry fields are preselected with standard values commonly used (e.g. consolidation fact = 'I4', group currency = 'EUR', group chart of accounts = 'KON001').
The new application VORINITE is started automatically instead of the standard single record application VORADMINE, if the list "Startup data + authorisation" (VORADMIN) determines at entry of <Edit data>, that there is no startup data and authorisation record yet.
This new function is only useful for new customers of IDL.KONSIS.FORECAST as well as for setup of a new empty database.
The inclusion of menu items for call of external applications (e.g. IDL.IMPORTER) into a workflow automat is now possible. However, please mind, that the external application runs independent from IDL.KONSIS.FORECAST. I.e. subsequent applications start at once without waiting for the termination of the external application. Therefore menu items for external applications should be placed to the end of a workflow automat as a rule.
Additional parameters were supplemented in the table for menu structures (MENMEN):
The first two parameters extend the possibilities for calls of import applications in a workflow automat. With hte aid of the other parameters further applications not supported until now can be included in a workflow automat, e.g.
The menu structure allocation (MENMENE) allows the new extra entry "#KTK-N" for the parameter company. "#KTK-N" like "#KTK"provides a multiplication of a line for all companies of the group companies as specified in the parameter group/sub-group. However, the value of the parameter group/sub-group itself is not transferred to the called application. This variant is required for calling of the creation of company reports or the calculation of check rule results, since these applications may be called with as well as without the parameter group/sub-group.
The application "Company financial statements + monitor" (EA) was modified to be callable with unique group/sub-group and company = '%' out of the workflow automat: If EA receives only group/sub-group as a parameter but no company, then company = '%' is substituted instead of reporting an error due to missing parameters.
The treatment of quoted companies potentially contained in a sub-group was completed in the function for creating a company financial statement out of a consolidated sub-group (KTK2GES). Consolidation postings for clearing of rounding differences (consolidation function 'QU') are reposted from accounts of the consolidation parameter 'QU' (with account flag 'Q') to reference accounts (without account flag 'Q') given in the consolidation parameter 'QU', too.
The licence file was extended by entries for the products IDL.FORECAST and IDL.IMPORTER. The entries for the SAP interface were differentiated (FI/CO and number of accounting areas.
The selection of the language used for user defined descriptions (e.g. descriptions for accounts, positions, facts) in list applications and selection lists was unified:
Up to now this solution was realised only for account descriptions.
An entry field "Language" for the display of descriptions in the selected language was supplemented in the list applications "Products" (PRO), "Currency codes" (WKZ) as well as for several lists of reported data.
The view "Charts of accounts / controlling object" (KTP) now exports the displayed lines in the standard format of the new import application for charts of accounts and controlling objects (see below). Individual formats can be chosen for export, too.
The fixed asset prefix may remain empty for pure charts of controlling objects (chart type = 'C').
The facilities of selection for allocated "Reference accounts for consolidation D&C" and "Accounts for result carry forward" were supplemented in the list application "Accounts" (KTO).
The selection for these accounts were pooled with the selections for allocated "Aggregated accounts" and "Accounts if D/C changed". You have to enter the allocation type beside the account number in the corresponding selection fields (5th line of the extended map). The selection for allocated group accounts remains a selection for its own, since her a deviating chart of accounts has to be entered.
The selection for allocated accounts supports the entry '*'. Then only accounts without allocation of a corresponding account are displayed.
The facility of selection for flags for allocation of an account to the (up to 10) controlling dimensions was supplemented in the list application "Accounts" (KTO). After the prompt text "ContrDimen" as many entry fields are dsiplayed as controlling dimensions have been defined by the user. The order of the entry fields corresponds to the order of the respective table columns.
The facility of changing the valid-until date was supplemented in the mass updatefunktion for accounts.
Restrictions of the validity of an account are inherited to all allocated fixed asset objects. Thus a fixed asset object cannot be valid in a period where its fixed asset account is not valid.
You now can allocate an account for result carry forward to capital accounts with account flag 2 = 'L'. This individual account for result carry forward superposes the common account for retained earnings with account flag 'X' used for 'L' accounts at period carry forward.
Up to now the action "Create allocations POSKTO for company accounts" (in action menu of list application "Accounts" (KTO)) provided only the creation of new position allocations due to the allocation of the allocated group account. From now on even changed allocations can be adopted. If the function determines that positin allocations already exist for a company account, then the user is alerted with "Existing entries account #1 will be deleted". If this message is accepted existing position allocations of this account are deleted and new allocations are created due to the allocated group account.
The check for Balance sheet/Profit & Loss code of positions and accounts for statistical amounts were revised. Only statistical accounts (Balance sheet/Profit & Loss code = '5', '6', '7', '8' or '9') may be allocated to a position with Balance sheet/Profit & Loss code = '5'.
An attribute "Flag of aggregation" was supplemented in the controlling object master data (see above), that designates aggregated controlling objects.
The hierarchy allocations required for aggregation are displayed and modified by the new applications "Hierarchy of controlling objects" (CNTNCT) and "Hierarchy of controlling objects" (CNTNCTE).
Restrictions of the validity of a fixed asset account are inherited to all allocated fixed asset objects automatically. Thus a fixed asset object cannot be valid in a period where its fixed asset account is not valid. Corresponding checks are performed when changing fixed asset object master data.
An attribute for another account number was supplemented in the fixed asset master data. This account ("Depr-AcBal", Account for accumulated depreciation) has to be a balance sheet and a fixed asset account. Depreciations are posted on this account separately so that only acquisition/production costs remain on the fixed asset account. The depreciated cost is calculated by the total of both accounts.
The new account is considered accordingly at automatic calculation of depreciations for consolidation postings (see below).
Because of unsolved problems at creation of company closings on a new fact in the present the entry of an account for accumulated depreciations is addmited only for group fixed asset objects (fixed asset card type 'B', 'K' or 'L').
The facility of selection for allocated group fixed asset objects was supplemented in the list applications "Fixed asset objects" (ANLOBJ) and "Intercompany fixed asset objects" (ICANLOBJ).
According to experience the depreciation type 'AD' (arithmetical declining depreciation) was barely used and even not supported automatically. Therefore it has been dropped. Fixed asset objects with this depreciation type are converted to depreciation type 'K' (no automatic depreciation) automatically by the release migration program, since depreciations had to be posted manually in both cases.
In addition the attribute "Net book value" had no meaning and therefore was removed from the maps and tables of "Fixed asset objects" (ANLOBJ, ANLOBJE) and "Intercompany fixed asset objects" (ICANLOBJ, ICANLOBJE) as well as from the corresponding import format.
An expenses account (Balance sheet/Profit & Loss code = '4') now may be entered as "Account for income" for intercompany fixed asset objects (ICANLOBJE).
The "Fixed asset origin card number" is automatically set to the key of fixed asset object itself for intercompany fixed asset objects with card type 'A' (intercompany disposal) if not set. The selection list offers only disposal objects for intercompany addition cards (card type 'Z'), too.
a language dependent attribute for a column header was supplemented in the table for posting keys. This text is used in the forms entry application for development transactions (see bleow). Existing posting keys yield a two-line table header consisting of the posting key in the first line and the short word in the second line via metadata delivered with this release (standard posting ekys) or the release migration (individual posting keys, see above). This text may be changed for customer specific posting keys. There the character '|' serves as control for line feed.
The facility to change the valid-from period, the development area, the development column, the posting key flag 1, and the debit/credit code was supplemented in the mass update function for posting keys.
User with the new extra authorisation '3' for companies in the "Startup data + authorisation" (VOR, VORADMIN) are allowed to modify only charts of controlling objects in the company master data.
The selectin list for companies now displays the company description immediately after the key before all other attributes.
An attribute "Flag of aggregation" was supplemented in the business unit master data (see above), that designates aggregated business units.
The hierarchy allocations required for aggregation are displayed and modified by the new applications "Hierarchy of business units" (CNTNCT) and "Hierarchy of business units" (CNTNCTE).
An attribute for a exclusion group for check rules was supplememted in the fact master data. It works like the already existing attributes in the period (ABR) and company (GES) master data.
An attribute for an account group for check was supplememted in the fact master data. It allows the restriction of the status display for check of the creation of a company closing on a new fact to certain groups of accounts (only balance sheet or only profit & loss).
The call of the calling application "Create closing of period new fact" (GESABV) was supplemented in the action menu of the "Company financial statement monitor" (EA) in the submenu "Lists".
The call of the list application "Deferred taxes header" (LTK) was supplemented in the action menu of the "Company financial statement monitor" (EA) in the submenu "Lists". Thus the calculation of deferred taxes in the company financial statements can be started out of the company financial statements monitor.
Special handlings of the status display for deviating companies were dropped, for complete and consistent company financial statements are required for deconsolidation since release 2006.1.
The action "Check & refresh status information" now in addition performs a check for simultaneaous data with and with out business units due to existing processing records (VERARB). In case an error message is output and the check is aborted. The check cannot be repeated until the incorrect processing records have been deleted.
The account descriptions in several single record applications were enlarged to 70 charcters.
An entry field for selection of accounts with certain accounting standards was supplemented in the list application "Account balances" (KTOSAL).
An aggregated business unit can be entered with sort option 'KG' and unique entry of the company. Then per account the balances are displayed in the tree structure defined in the business unit hierarchy.
The coloured status display in the columns for Balance sheet/profit & loss code and Account flag 1 and 2 for consistency of the details now is performed without unique specification of the business unit. However, the unique specification of the company is still required, since otherwise the response time might become inacceptable.
Account balances with account flag 'J' (incomplete intercompany details) are displayed white instead of green in the column for the account flag 1, if there are no intercompany account balances at all on this account.
An aggregated business unit can be entered with sort option 'KC' and unique entry of the company. Then per account/controlling object the balances are displayed in the tree structure defined in the business unit hierarchy.
An aggregated controlling object can be entered with sort option 'GK' and unique entry of the company. Then per account the balances are displayed in the tree structure defined in the controlling object hierarchy.
The columns for controlling flag 1 and account flag 1 and 2 are suppressed in the list application "Controlling balances" (CNTSAL), if they contain no data and the check box <hide empty columns> in the menu <View> is marked.
An entry field for selection of accounts with certain accounting standards was supplemented in the list application "Intercompany account balances" (KTOSAL).
The entry field for group/sub-group is no longer needed for selection of group transactions, since group transactions are no more supported (s.o.). However, this entry field has not been dropped but rather serves for selection of group cmpanies now. Thus it works just like the same field in the list applications for balances and postings.
The similar change for shareholding transactions had already been performed with release 2007.0.
An entry field for the language was supplemented in the list applications for capital, provision and individual development transactions (KAPBEW, RUEBEW, SPIBEW) used for the display of account descriptions in the specified language.
The list application "Fixed asset transaction" (ANLBEW) now allows a selection for allocated group account, position, intercompany and/or IC business unit.
The columns of the list application "Shareholdings/Participations" (GESGES) were newly arranged:
Attributes for the group/sub-group and the consolidation voucher have been supplemented in the table for shareholdings. The attributes are entered by the consolidation function corresponding to the change of the participation. Thus it can be determined, whether and in case how a shareholding transaction has been processed. The manual entry of these attributes is not supported as well as import, copy, carry forward etc.
The posting keys for shareholding transactions are divided in development areas for acquisition costs and allowances analogue to the posting keys for fixed asset transactions. The posting keys '05', '06' and '07' were allocated to the development area allowances. In addition new posting keys for automatic carry forward ('11') and currency rate effects ('14', '15') were defined for this development area. Thus the shareholding transaction can be held synchronous with fixed asset transactions even in cas of allowances. Shareholding transactions for allowances may not provide any percentual changes.
When entering a new voucher (BELE) the posting type controlling the carry forward now is preselected with 'WU' (Repetitive posting with transfer). Up to now this was 'E' (single use posting).
Like in several other functions fixed asset objects missing in the destination data are generated automatically with standard attributes when copying vouchers and postings to another company.
The company processing controls now contain separate records (check points) for transactions carried forward per transaction development. The names of these check points consist of the check point name of the respective transaction development + "VOR", e.g. "ANLBEWVOR", "SPIBEW9VOR". If specified for the fact this processing control record contains a check sum for the data carried forward. All transactions with posting keys, that are allocated to the same development column as the posting keys for automatic carry forward (usage tag 'V'), are concerned for this check sum. These records are used for the check of the company carry forward to a new period.
The first item in the action menu of form entry applications was named "Save" uniquely, since it designates the same function as the button <Save>. However, checking and saving of the entered data still runs via the import application running in the background.
An entry field "Display key column" was supplemented in the form entry applications for account balances (I-KTOSAL) and development transactions (I-ANLBEW, I-KAPBEW, I-RUEBEW, I-SPIBEW). By default it is preselected with 'X'. Like for the report result display (REPERG) the output of the key of the fixed asset object (at I-ANLBEW), the position or the account is suppressed, if "Display column key" is not 'X' and the column option equals 'F' or 'FS', respectively. Then the lines can be identified only by the descriptions.
In the form entry of account balances (I-KTOSAL) a line is protected against entry, if the corresponding account is designated with an account flag 2 for a transaction development automatically generating account balances (postion 'A' of the transaction development flag in the fact (FAC)). Up to now the entry was possible. However, after <Save> the original value generated from the development transactions was restored.
Account balances with account flag 'J' (incomplete intercompany details) are displayed white instead of green in the column for the account flag 1, if there are no intercompany account balances at all on this account.
The column headers (1st line: posting key + short word, 2nd line: "Amount LC", 3rd line: currency code LW) of form entry applications for transaction developments with column option 'FS' (Columns per posting key) were not significant, since the posting key short word has a maximum of 10 characters. However, the description with up to 70 characters normally is too long. Thus the posting key master data table (see above) was enhanced by an attribute "Column header", that is used for form entry from now on.
Exclusion groups for check rules now can be allocated to a fact (FAC), too (see above). The check rules allocated to an exclusion group are not processed, if the resprective fact is entered as parameter. Up to now this control was available for periods (ABR) and companies (GES) only.
If a check rule is defined with required parameters for previous period as well as comparison fact, then the parameter check is performed uniquely in the calling applications "Company financial statemtent monitor" (EA), "Group companies + monitor" (KTKGES) and "Check rule results" (PRFERG):
Up to now the company financial statement monitor required a deviating comparison fact.
The parameters for previous period and comparison fact of the last calculation run are written into the company processing control (VERARB) record for check rule results (check point "PRFERG"). Up to now this information was only saved in the check rule result records.
The sort and selection option 'W' (processed check rules with values) now is preselected in the list application "Check rule results" for company and group checks (PRFERG, PRFERGK). Up to now 'A' (all check rule results) was preselected.
The mandatory carry forward of single use vouchers (posting type 'E') if affecting net result or transaction developments introduced with release 2007.0 didn't prove itself and now is revoked. In practice too often situations occurred, where circumstances were subsequently posted in the first period, but are contained in the reported company financial statement in the following periods. Therefore no more postings are carried forward from single use vouchers. However, the warning message for postings affecting net result or transaction developments in single use vouchers in the voucher header (status <yellow>) as well as at carry forward is maintained, but doesn't result in the status <yellow> in the company financial statement monitor (EA).
Vouchers with posting type 'WX' (repetitive with reposting affecting net result of postings affecting net result) further on are carried forward like in release 2007.x. I.e. a reposting (carry forward vs. current changes) of postings on transaction development accounts is performed beside reposting affecting net result of postings affecting net result.
Vouchers with posting type 'WV' (repetitive variable postings) are carried forward like a single use voucher. I.e. only a voucher template with zero values is carried forward. If values of a 'WV' voucher are to be carried forward, you first have to copy the voucher and then modify the posting type of the copied voucher.
Postings on accounts for a transaction development for currency conversion with weighted monthly average exchange rates (posting key with usage tag 'M') now are carried forward with conversion rule 'VKW' or 'VPW', respectively, just like the corresponding development transactions. Thus the currency conversion of these postings results in a weighted monthly average exchange rate, too.
It is now checked at preiod carry forward, whether the headers for currency conversion or deferred taxes calculation carried forward refer to accounts, that are no longer valid in the destination period. A corresponding information is output if applicable. Nevertheless the carry forward is performed.
Report headers whose report ID is invalid in the destination period are no more carried forward.
Message windows output by the period carry forward yield a comprehensive message in the window footer. This message is different for general errors, warnings or hints for differing currency codes. The display of all message windows with the same comprehensive message can be suppressed at mass operations (e.g. marking several companies in the company financial statement monitor EA) by marking the check box <Don't show this message again>. Subsequently the same user response is assumed as for the first message window. The contents of all suppressed message windows are collected and displayed at the end of the mass operation in a total message window. The texts of the response buttons were designed more meaningful.
If an individual Account for result carry forward" is allocated to a capital account with account flag 'L', then the allocated individual account superposes the account for retained earnings with account flag 'X' used for carry forward for 'L' accounts else.
The company financial statement monitor (EA) status for the check of the period carry forward now is set to <->, if there are no data at all in the previous period. Up to now the status became <green> in this case.
This status is automatically set to <yellow> (result of the check is no longer up to date), if data carried forward were changed in the actual period. Up to now this control worked only for changes of data of the previous period. Additional records (check points) were introduced in the processings control (VERARB) for this purpose: a check point for carry forward for each defined transaction development. This record contains a check sum for data carried forward, i.e. all transactions with posting keys that are allocated to the same transaction column as the posting key for automatic carry forward (usage tag 'V'), corresponding control in the fact (FAC) provided. Any change of these check sums triggers the change of the status for the carry forwad check.
A check for accounting standards was supplemented in the company closing to the next period. This check compares the accounting standard of the source account with the accounting standard of the destination fact. A message window is output asking whether only data with consistent accounting standards are to be transferred, if both accounting standards are not empty and different. The answer is applied to all subsequent data with this constellation.
Message windows output by the company closing yield a comprehensive message in the window footer. This message is different for general errors and various warnings, that differ in their response facilities. The display of all message windows with the same comprehensive message can be suppressed at mass operations (e.g. marking several companies in the company financial statement monitor EA) by marking the check box <Don't show this message again>. Subsequently the same user response is assumed as for the first message window. The contents of all suppressed message windows are collected and displayed at the end of the mass operation in a total message window. The texts of the response buttons were designed more meaningful.
A new flag in the fact master data (FAC, see above) now controls, whether the status for carry forward new fact displayed in the "company financial statement monitor" (EA) is valid for all (non-statistical) accounts, only balance sheet accounts or only profit & loss accounts. However, the protocol of the check is not reduced.
An entry field for the language was supplemented in the list applications "Account balances origin list" (KTOHER) and "Controlling balances origin list" (CNTHER) for display of account and controlling object descriptions in the given language.
Single-use consolidation vouchers (posting type 'E') are carried forward like in release 2007.x. I.e. consolidation postings affecting net income or on transaction development accounts are carried forward and reposted as current change. Since this behaviour ist different from carry forward company financial statement single-use vouchers (see above) a new posting type 'EU' is introduced. The posting type 'E' is no longer valid for newly entered consolidation vouchers. However, there is no conversion of existing data, since updates for closed periods should be avoided and it cannot be determined, whether existing single-use vouchers had been carried forward due to the old rule (up to release 2006.1) or the new rule (from release 2007.0 on).
The rules for carry forward of consolidation vouchers with posting type 'WX' or 'WV' (repetitive with reposting affecting net result of postings affecting net result or repetitive variable postings, respectively) wre not changed.
If an individual Account for result carry forward" is allocated to a capital account with account flag 'L', then the allocated individual account superposes the account for retained earnings with account flag 'X' used for carry forward for 'L' accounts else. E.g. this can be used for carry forward of consolidation postings for minority interests.
Report headers whose report ident is invalid in the destination period are no longer carried forward with the group data.
In addition it is checked, whether control records for consolidation parameters (KTKPAR) contain accounts, that are no more valid in the destination period. If this applies a corresponding hint is output. However, thes data are carried forward nevertheless.
The "Group companies + monitor" (KTKGES) status for the check of the period carry forward now is set to <->, if there are no data at all in the previous period. Up to now the status became <green> in this case.
The classic depreciation methods for straight-line depreciation 'L' (in years) and 'M' (in months) always calculated the regular depreciation up to the end of the period due to acquisition date, acquisition and production cost, and number of depreciation periods. Thus extra depreciations provided for an intermission of regular depreciations until this amount was catched up.
Extra depreciations (current-value depreciations) are handled different with the new depreciation methods for straight-line depreciation 'SL' (in years) and 'SM' (in months):
I.e. the current depreciation is determined by residual book value and remaining maturity. All changes of the book value in the current period including increas or decrease of the acquisition/production costs or appreciations take effect on the amount of the current depreciation like extra depreciations while the remaining maturity is unchanged.
Automatically calculated depreciations are no longer posted on the fixed asset account but rather on the Account for accumulated depreciation if entered in the fixed asset object master data (see above). This function is only availabel in the group financial statement, i.e. for consolidation postings.
The adjustment of currency conversion difference affecting the operating result by setting the "Handle of currency conversion" to 'W' and entry of an "Account for B/S profit effectively" in the currency conversion header provided the posting of the cumulated difference from the previous period (out of the currency conversion header of the previous period) on the usual account for B/S difference, and posting of the difference from the current period on the "Account for B/S profit effectively".
This solution provided correct results in the first period. However, from the second period on the difference from the previous period was posted twice, on the account for retained earnings as well as on the account for B/S differences. Thus this method is no longer supported. The entry fields "Handle of currency conversion" and "Account for B/S profit effectively" were removed from the currency conversion header map (WUME).
As an alternative it is now admitted to transfer the complete B/S conversion difference affecting the operating result by entering a p&l account as "Account for B/S difference transfer". The release migration programm moves a previous "Account for B/S profit effectively" to the "Account for B/S difference transfer", if "Handle of currency conversion" was set to 'W' up to now.
An additional account was supplemented in the currency conversion header (WUME), so that p&l differences in parallel currency from currency conversion can be transferred on different account depending on the sign of the difference. Thus parallel currency conversion is analogue to group currency conversion in this respect, too.
The account for revenue reserv. transfer already had no more any use and was not enterable since release 5.2.1 from 2003. However, it still was displayed in the currency conversion header list (WUM) if contained in legacy data. This display now has been dropped.
Like fixed asset transactions for current depreciation postings on fixed asset accounts with posting keys for current depreciationare converted using the conversion rule of the depreciation p&l accounts (account flag 'D'). The same applies for postings on provision accounts with posting keys for releases and additions of provisions with respect to p&l accounts with account flag 'Y' or 'Z', respectively.
Development transactions with posting keys for currency conversion differences (usage tag 'K', 'U', 'SK', 'D', 'SD') now are maintained at currency conversion, if the amount in local currency is not 0,00. This control was introduced for data from the aggregation of a consolidated sub-group to a company financial statement (KTK2GES), where the sub-group currency is transferred to the local currency.
Capital transactions with posting key '19' (arising from carry forward of postings affecting net result) are converted with conversion rule 'PDK' (Currency rate average per period), if the converted net result also result like converted by 'PDK'. This applies, if the B/S as well as the p&l conversion difference are transferred to a B/S account and the conversion method is not 'RST' (Closing/current rate method).
The difference clearing for converted vouchers is now performed like a complete financial statement: The net result of the voucher is converted into group and parallel currency using the closing rate and the difference between this amount and the total of the converted postings on B/S or p&l accounts, respectively, is cleared by additional postings on the accounts for B/S or p&l conversion difference transfers, respectively.
Message windows output by the currency conversion yield a comprehensive message in the window footer (e.g. "Checkpoint WKZ is different to basic WKZ!"). The display of all message windows with the same comprehensive message can be suppressed at mass operations (e.g. marking several companies in the company financial statement monitor EA) by marking the check box <Don't show this message again>. Subsequently the same user response is assumed as for the first message window. The contents of all suppressed message windows are collected and displayed at the end of the mass operation in a total message window.
The texts of the buttons of the message mentioned above ("Checkpoint WKZ is different to basic WKZ!") are supplied with the respective currency codes (up to now <OK> or <Continue>, respectively).
Companies having only account balances with zero values up to now caused an error and the abort of the application "Change currency data GCurr <-> PCurr", since it was assumed that the currency conversion had not been performed if all accounts have the value zero in parallel currency. This check was now replaced by a request for the status of the processings control (VERARB) record for currency conversion (check point 'WUM').
The difference clearing for converted consolidation vouchers is now performed like for vouchers of a company financial statement: The net result of the consolidation voucher is converted into parallel currency using the closing rate and the difference between this amount and the total of the converted consolidation postings on B/S or p&l accounts, respectively, is cleared by additional postings on the accounts for B/S or p&l conversion difference transfers of the currenc conversion header (WUM), respectively.
If the check of a consolidation voucher results in differences in parallel currency while consistent in group company, then a message code is written into the group processings control (KVERARB) record for currency conversion (check point 'KTKWUM'). Thus the Status 'WU' of the group companies + monitor (KTKGES) becomes <red> designating, that the group currency conversion is missing or has to be repeated.
An entry field for the language was supplemented in the list applications "Exchange rates" (WKZWKA) and "Postin key conversion rules" (BSLUAW) for display of descriptions in the given language.
An authorisation check for the period was supplemented for updates of exchange rates (single record application and mass copy). The checked period is the month and year of the closing date.
Up to now the addition date to group companies enterable in the single record application "Group/sub-group consolidated company" (KTKGESE) served only as a comment. From now on this date is evaluated in several functions. Thus the following checks were supplemented in KTKGESE:
The status columns for the consolidation functions 'EF' (update equity), 'LT' (deferred taxes), 'ZA' and 'ZU' (elimination intercompany profits of fixed or current assets, respectively), 'SK' (consolidation of debts) and 'AE' (consolidation of costs and earnings) are now suppressed if they are empty and the check box <hide empty columns> in the menu <View> is marked. This control is supported by the "Calculation of status and participation" (see below) initialising these columns depending on the existance of correlated basic data.
Special handlings of the display of status 'EA' for deviating companies were dropped, for complete and consistent company financial statements are required for deconsolidation since release 2006.1.
The list application "Consolidation parameters" (KTKPAR) now (again) displays the threshold values in an additional column. Of course this applies only to consolidation functions working with threshold values (consolidation of debts, consolidation of costs and earinings).
At restriction to a single consolidation function still all specific accounts are displayed. The table headers were revised for this purpose.
Reference accounts without account flag 'Q' now can be allocated to the accounts for rounding differences at quoted conversion (with account flag 'Q') in the consolidation parameter 'QU'. These reference accounts are used at aggregation of a consolidated sub-group to a company (KTK2GES).
The calculation of status and participation now initialises the status columns of consolidation functions outside capital consolidation:
In addition the status 'EF' (update equity) becomes <empty> (up to now <->) for non-equity group companies. Thus this status column can be suppressed, too, if there are not group companies consolidatd at equity at all.
The calculation of status and participation evaluates the new entries for group/sub-group and consolidation voucher in the shareholding transactions (GESGES, s.o.). E.g. the status 'KK' (capital first consolidation) is set to <red>, if there are corresponding shareholding transactions without these entries althouch the capital consolidation has already been performed (after carry forward from the previous month e.g.).
The date of the last annual statement is used instead of the previous period for reading of data from a previous period at determination of the status for subsequent consolidation ('KF'). At evaluation of the transaction date of shareholding transactions for capital first consolidation ('KK') the distance from the last annual statement is concernd, too.
The consideration of currency conversion differences (equity capital on the accounts from the currency conversion headers) was newly adjusted with aid of the addition date of the group company (see above):
At capital first consolidation the current group/sub-group and the voucher number of the generated consolidation voucher are written into the processed shareholding transaction (GESGES, see above).
Minority interests on changes in the equity capital besides changes processed in the capital consolidation (disposals or additions) up to now were always posted, if there was no carry forward of minority interests ('KC' voucher), i.e. even for companies newly added to the group companies or after manual deletion of the 'KV' voucher. This is not correct, since only capital acquired during membership in the group/sub-group has to be considered. Now this processing depends on the existance of a shareholding transaction with posting key '04' (setting for begin of period) and the entry of an addition date (KTKGESE) before the beginning of the current period.
The list application "compensation of differences from first consolidation" (VUB) now displays the net difference amount <red>, if it is not equal to zero.
A double mouse click in the list VUB now works depending on the column. The single record application (e.g. "Disclosure of hidden reserves") is selected due to the respective column. A double mouse click on the status column provides a branch to the consolidation postings.
The total remaining difference is now preselected in all single record applications for compensation of the difference amount.
Since IFRS doesn't allow the passivation of difference amounts the correspoinding compensation function was renamed to "Clearing badwill". This also applies for the corresponding account in the consolidaiton parameters 'KK' and 'EK'.
If a difference amount on the liability side was compensated by provisions in the past, then at the point of time of the current consolidation parts of it might be released affecting net result and have to be posted towards retained earnings. Therefore an entry field Accumulated dissolution was supplemented in the single record map "Clearing badwill". The amount entered there is posted from the account for "Clearing badwill" to the account for retained earnings.
At capital deconsolidation the current group/sub-group and the voucher number of the generated consolidation voucher are written into the processed shareholding transaction (GESGES, see above).
A transaction development reposting is processed at capital first consolidation only if the company is new in the group companies. This now is determined by the addition date in the "Group/sub-group consolidated company" (KTKGESE) (addition date in or before the current period).
You now can call update equity (list and forms entry application) even if the group statement is already released/locked. However, you must not update any data but rather can display only data already entered.
Intercompany account balances of the parent company for the equity company as intercompany on the account for collected dividend are accumulated and displayed in the form entry map, if this account is entered in the consolidation parameter 'EF'. However, then a manual update of this amount is no longer possible. This amount (calculated from intercompany account balances or manually entered) is no longer posted at the child but rather at the parent company.
The company used for posting of currency rate effects determined at consolidation of debts (SK) or costs and earnings (AE) is defined by the following rules:
When entering a new voucher (KONBELE) the posting type controlling the carry forward now is preselected with 'WU' (Repetitive posting with transfer). Up to now this was 'E' (single use posting). 'E' is no longer supported for new consolidation vouchers. The new posting type 'EU' has to be used instead (see above).
An entry field for selection of accounts with certain accounting standards was supplemented in the list application "Consolidation Postings" (KONBUCH).
Automatic generated consolidation postings must not be changed without extra authorisation. However, the following exception has been introduced: If the account is invalid in the actual period (e.g. due to a consolidation parameter carried forward with disregard of the warning), see above), then the account number may be updated without extra authorisation.
At deletion of a consolidation voucher for capital first consolidation ('KK') or deconsolidation ('KS') the reference to this voucher is removed from the processed shareholding transactions (GESGES, see above).
The account for retained earnings of the consolidation parameter ('KK' or 'EK', respectively) may be used for manually entered capital consolidation postings on posting record number '03' (clearing badwill).
The segment flag classifies consolidation postings to be intra segmentary or inter segmentary. Normally this flag is determined by analysing all consolidation postings of one posting record number, whether they all are allocated to the same business unit or to different business units. This information is evaluated by the segment report. This procedure had the following gaps:
These problems now have been solved by no longer setting the segment flag automatically for the corresponding consolidation vouchers ('SU', 'VS', 'JU'). Rahter the applications generating these consolidation vouchers provide a correct setting of each single consolidation posting. The modification for 'SU' consolidation voucher has already been performed with release 2007.1.
Report headers must no longer be copied via mass copy to another period, if their report ident is invalid in the destination period.
The report result display (REPERG) now allows the simultaneaous display of several group reports, i.e. the same report for different groups/sub-groups. The key for group/sub-group can be entered with '%' or partially qualified while report ident and report version have to remain unique.
The action <Display help text> was supplemented in the report result display (REPERG). It displays the help text of the lowest order object allocated to a line. Depending on the type of the line this may be a position, an account, a group/sub-group, a company, a business unit or a controlling object.
A new value flag '8' (values from KTOSAL with account details but without position totals) was introduced in the report line descriptions (REPZEI). It describes a position detailed by several accounts but without aggregation. E.g. it can be used for comprehension of values from statistical amounts (balance sheet / profit & loss code = '5').
An attribute "Allocated chart + position olap" was supplemented in the table for report line descriptions. It is only evaluated in version '3' of the MIS preparation (see below).
The report option 'S' provides the entry of report results into the database table for position balances, where they can be evaluated by the IDLCONNECTOR e.g. However, for group reports only position balances for the total group are written.
The new report option 'P' for group reports provides the writing of position balances for the total group as well as for the company details. On demand this might spare a number of reports for consolidated company financial statements (key with group/sub-group and company).
Position balances with zero values are no longer written at all.
Reports with keys for previous period and comparison fact reported an error, if there were no data for a combination of period and fact and the report generation was cancelled. From now on the report is cancelled only if ther are no data for the combination of current period and current fact. For all other combinations this is only an information message.
An entry field "Language" for the display of position descriptions in the selected language was supplemented in the list application "Formula lines list" (FED).
An attribute for a default file name was supplemented in the table for "Import/Export formats" (IEF). A file with this name is used at import or export with this format, if no other file name is specified in the file dialogue.
This file name may contain path informationa. If no device is specified, the file name always is applied to the import/export path specified in the options dialogue (tab <Import/export>), that thus can be subdivided in subdirectories. If no suffix (characters after a ".") is specified in the file name, then the file name is automatically extended by ".TXT", ".CSV" or ".XML" depending on format type and separator of the import/export format.
The file name even may contain replacement characters for keys, so that e.g. import files for several companies might be held parallelly and the import accesses to the appropriate file. The replacement characters are constructed by '%' and the according application short word. This process is supported for the following keys:
The value "C:\IDL\BATCH\" for the import path in the options dialogue is assumed in the following examples:
Please mind that a default file name can be specified only for individual import/export formats, since the default file names of standard formats ('#TXT' e.g.) are delivered by IDL with each release. If a standard format is to be used in connection with an own default file name, then the standard format first has to be copied to an inidividual format.
The transformation of facts now can be applied for all import applications with referenc to a fact. Up to now this transformation was available only for data exchange.
The technique of transformation groups was enhanced ba the facility to transform an external key for a company in IDL.KONSIS.FORECAST simultaneously into a company number and a business unit. Corresponding entries are possible in the application "Transformation group allocation" (UMSOBJE). Thus e.g. a branch office defined as SAP accounting area can be imported as IDL.KONSIS.FORECAST business unit. This transformation works for intercompany entries, too. The transformation can also be used for export.
You now can specify a report ident as parameter for unload functions (action <select external data> with call of an external application specified for the menu item "UNL..."). The parameter fir the report ident is references by "%17" in the command line of the external call.
A new application (TXTKTK) was created for the import of groups/sub-groups (KTK). The format descriptions were enhanced in the tables for import/export formats (IEF, IEFDEF, IEFFEL). This application is invoked by the calling application "Data import and display" (IMPORT) and displayed in the branch "Import masterfiles".
A new application (TXTKTP) was created for the import of charts of accounts/controlling objects (KTP). The format descriptions were enhanced in the tables for import/export formats (IEF, IEFDEF, IEFFEL). This application is invoked by the calling application "Data import and display" (IMPORT) and displayed in the branch "Import masterfiles".
SAP supports the definition of cost center codes with different validity periods. Thus several records per cost center code result when unloading these data. Up to now the incidental last record for a cost center code overwrote data of previous records when overtaking these data. Now at import the data are sorted and comprehensed so that the cost center is valid for the maximum space of time in IDL.KONSIS.FORECAST. The remaining attributes are derived from the record with the lastest validity.
The texts of the lines for archiving were renamed to be better distinguishable from the lines for data exchange. However, the functionality is unchanged.
The sub-group data exchange was adapted to several database enhancements.
The group-wide data exchange was adapted to several database enhancements.
The following new table was supplemented in the group-wide data exchange:
The texts of the response buttons in the message window concerning the consideration of exchange rates were designed more meaningful.
The validity of allocated fixed asset objects is limited to the validity of the fixed asset account was changed at loading of accounts of the group chart of accounts.
Entry fields for the additional attributes for the control of checks in report results (background colour for values less, equal or greater zero) was supplemented in the export fuction for report line descriptions.
Entry fields for intercompany and IC business unit were supplemented in the export and the read function of capital, provision and individual development transactions.
A new version '03' was invented for the MIS/OLAP preparation with the following differences to versin '02':
An attribute for "allocated OLAP position" was supplemented in the report line descriptions (REPZEI). It is only used for version '03'. I.e. it is not evaluated by the MIS/OLAP preparation but rather has to be interpreted by IDL.IMPORTER at reading of master and structure data.
The tables K850 (balances), K852 (controlling details) and K853 (transaction development details) were enhanced by an attribute "thereof inter segmentary". This amount is determined with the aid of the segment flag of consolidation postings (see above). Thus now even segment reports can be produced with the OLAP system.
The preparated tables K851 (intercompany details) and K852 (controlling details) were enhanced by data of the additional 9 controlling dimensions introduced with Release 2007.0. This allows the evaluation of the additional controlling dimensions in the MIS/OLAP system.
The preparated table K853 (transaction development details) was enhanced by the redundant attribute transaction development column of the respective posting key.
It is now possible to use the new extended passwort rules. To enable please add
KennwortBauartNeu=yes
to the section [Connection] in your kcusap.ini file.
The SAP interface now supports the logon to SAP at a message server with load balancing.
The new SAP interface (based on IDL.IMPORTER) was enhanced so that grou/sub-group can be supplied as parameter with the designator "sGroup" for all imports. This parameter merely has to be defined in the import variables in the imd file for access in the scripts.
With this release the following English-speaking documentations in the "doku" directory are updated or completed: