This Release IDL KONSIS 2007.0 (or IDL Winkons 2007.0 or PP Consis 2007.0 or CS.KON 2007.0, respectively) is a main maintenance and therefore must not be left out in the release sequence. Prerequisite for this release is the last main maintenance 2006.0 from Sept. 17th 2006.
The supplements of the interim maintenance IDL KONSIS 2006.1 (or IDL Winkons 2006.1 or PP Consis 2006.1 or CS.KON 2006.1, respectively) as well as the corrections to these maintenances up to the release date are included in the main maintenance 2007.0.
This documentation describes the enhancements since the previous interim maintenance IDL KONSIS 2006.1 (or IDL WinKons 2006.1 or PP Consis 2006.1 or CS.KON 2006.1, respectively). If the last interim maintenance hasn't been installed yet you are recommended to catch up on the enhancements of the interim maintenance 2006.1.
Group transaction development reports and group cash flow reports containing disposing companies do not yield the same report result compared to releases before 2006.1 due to the proposition of the deconsolidation modified in 2006.1 (a balance sheet for the disposing company has to be delivered, that is included in group financial statement). In these cases group reports should be generated newly only for periods, where the deconsolidation has been processed at least with the release 2006.1.
I.e. you sholdn't generate group transaction development reports or group cash flow reports for closed periods, if they contain disposing companies. However, this change has no influence on b/s or p&l group reports since these reports already considered account balances of disposing companies (with entry of a disposal date in the group companies (KTKGES)).
The development planning of IDL provides that group transactions (fixed assets, capital and provisions) are no longer supported with the next main maintenance 2008.0. These data are redundant to the consolidation postings and don't contain additional information. Therefore the users are challenged
Due to miscellaneous enhancements (e.g. Unicode, Controlling) several import/export formats were enlarged or field lengths changed. Please check your individual import/export formats (IEFFEL), whether they are still compatible to the current definitions (IEFDEF).
The menu item for unloading of controlling balances out of a remote system was renamed from "UNLKSTSAL" to "UNLCNTSAL" in relation to the enhancements of the controlling component (see below). If you use this menu item and have entered a customer specific external call there, you have to copy this external call to the new menu item.
Furthermore the object type for import/export formats for controlling balances was renamed from "KSTSAL" to "CNTSAL". If you have defined customer specific import/export formats for this object type, you have to copy them to the new object type. In addition the field IDs for the new format have to contain the prefix "K041-" instead of the old prefix "K064-".
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.
The old application server (only solution up to release 5.3.1) will no longer be supported with the current maintenance. Only the new application server (available since release 5.4.0, standard solution since release 5.4.1) will be supported. Please update to the new application server if you are still using the old application server.
Up to now reported data (balances, transactions, postings etc.) could be documented by a 35 character remark only, which was insufficiant in many cases. However, no other reasonable length for this text could be defined. Therefore it now has been implemented, that a text with arbitrary length can be stored beside this remark text.
This description is performed like help texts for master data (accounts, positions, e.g.). Unlike most of the master data texts for reported data it cannot be entered in different languages. I.e. there exists at most one description per data record.
This enhancement concerns the following data:
The actions <Display Help Text> and <Edit Help Text> were supplemented in the action menus of the corresponding list and single record applications.
Please regard that these texts for automatic created data are not preserved at repetition of the automatic application, e.g. at carry forward of group data, but have to be entered again.
This release 2007.0 provides a method for clearing of intercompany account balances. Clearing means here, that couples or larger groups of intercompany account balances between two companies can be marked manually or automatically to represent corresponding issues. Thus it is easier to determine intercompany account balances without corresponding balance at the partner company.
Table enhancements
The database table for intercompany account balances was enhanced by three attributes:
Both, reference voucher number and reference voucher date, may be entered in the single record application (ICKTOSALE) as well as in the form entry (I-ICKTOSAL). In addition, the clearing flag may be imported by the import applications (TXTICSALD, TXTICKONV), too. However, the entry of the flag '01' for automatic clearing may not be imported.
Manual Clearing
The manual clearing of intercompany account balances is performed by the action <mass update>. After marking the intercompany account balances to be cleared and starting the action a number between '02' and '99' has to be entered in the dialog box for the clearing flag.
It is reasonable to perform the manual clearing in the couple view, so that intercompany account balances of both companies can be cleared in one go. For this purpose a special clearing view (see below) has been created.
The manual clearing affects the D&C and I&E consolidation only in the following case:
Beside this case the manual clearing only serves for view control for determination of unilateral reported intercompany account balances.
Automatic clearing
The clearing flag of intercompany account balances may be set automatically to '01', if it isn't set manually yet. This doesn't happen by a special clearing function but rather by the D&C/I&E consolidation or the D&C/I&E reconciliation (on facts below the consolidation level) callable out of the company financial statements monitor (EA), respectively. This is done due to the following rules:
At deletion of a D&C/I&E consolidation (via delete in the "IC Clearing List" (KGESGES) or via update of the consolidation parameter) the automatic clearing flag ('01') is removed from the concerned intercompany account balances.
Visualisation of clearing
A special view was supplemented in the intercompany account balances list (ICKTOSAL) for the purpose of optimized selection of cleared or not cleared intercompany account balances. This view is enabled by "IC Selection Option" 'AZ'. Furthermore the company as well as the intercompany have to be entered uniquely, since the data aren't ordered by company. Additional selections reducing the data displayed (e.g. account number) aren't allowed except for a selection for the clearing flag. All intercompany account balances not cleared yet can be selected by entry of '*' in the field for the clearing flag, all intercompany account balances already cleared by entry of '%'.
The display of these data is ordered by
This special sorting provides a distinction of data already cleared or not yet cleared as well as an aid for manual clearing, e.g. of data with identical amount but different debit/credit flags.
The controlling component (liable to pay costs) was considerably enhanced with release 2007.0. In particular it now is possible to supply the controlling data with up to 10 simultaneous controlling informations (= dimensions).
Master Data
A user wanting to use the additional facilities at first has to specify which dimensions shall be used with which meaning. For this purpose entries in the new application "Controlling Dimensions" (CDM) are required. Up to 10 dimensions may be inserted and provided with descriptions (in case multilingual), that explain the displays and entry possibilities in other applications. If controlling details are used already the first dimension is already created by the release specific converting program with the description "cost center". Without definition of additional dimensions you have no additional entry fields in other applications.
New charts of controlling objects have to be defined for the additional controlling dimensions. As familiar this is done by the application "Chart of accounts/cost center codes" (KTP). Now you have to specifiy newly the dimension for which the chart is intended. Charts of controlling objects already defined are allocated to the first controlling dimension (cost center) by the release specific converting program. Charts of controlling objects for additional dimensions may not be a chart of accounts simultaneously. The controlling dimension allocation may not be changed, if the chart of controlling objects already is allocated to a fact or a company (see below).
Of course, controlling objects have to be declared for each chart of controlling objects. As familiar this is done by the application "Controlling Objects", whose short word has been changed from 'KST' to 'CNT'.
If additional controlling dimensions are used, the facts (FAC) on level of the group chart of accounts have to refer to the respective charts of controlling objects. Corresponding entries are required in the company (GES) master data for the level of company chart of controlling objects. It is admitted just for the first controlling dimension, that the chart of controlling objects is (FAC) or may be (GES) identical to the chart of accounts.
You have to specify in the account master data (KTO) which controlling dimension is applied to which account (e.g. sales accounts are detailed by regions, stock accounts are detailed by product groups). This specification provides an obligatory entry in the corresponding reported data. Accordant flags have been supplemented in the account master data. The flag for the first dimension is set by the release specific converting program for all accounts for which at least one controlling balance exists in the database. These flags are inherited by the allocated company accounts automatically.
The differentiation between balance sheet and profit/loss accounts has been dropped. I.e. b/s accounts may be provided with controlling details, too. In addition (at previous position '0' of the flag for controlling details in the fact (FAC) master data) you now can specify exactly which p&l accounts are provided with controlling details and which not, even if the additional controlling dimensions are not used. The FAC flag position '0' is dropped. '0' and '1' are converted into 'X' by the release specific converting program.
Reported Data
A new database table (K041) was defined for the controlling balances. The data are transferred from the previous table (K064) to the new table for controlling balances by the release specific converting program. Beside other differences you now can define several records for each combination of account and controlling object(s). The short word of the list application has been changed from 'KSTSAL' to 'CNTSAL'.
At entry or import of controlling balances now controlling objects have to be specified for each dimension activated in the account master data. Controlling objects for other dimensions may not be specified. The controlling objects have to be defined in the chart of controlling objects allocated to the relative controlling dimension.
The database tables for intercompany account balances (ICKTOSAL), postings (BUCH) and consolidation postings (KONBUCH) were enhanced by attributes for the additional controlling dimensions. The list applications display them and the single record applications allow (and require) their entry dependent from the controlling dimensions specified and the account master data flags set.
The intercompany account balances with entry of controlling objects are validated against controlling balances like up to now with the only difference, that the additional controlling dimensions are considered in the same way. I.e. incomplete entries in the intercompany account balances are reported as a difference.
Import
In practice this enhancement will be used only, if the data can be taken over from a foreign system, since the data entry of multidimensional data is very laborious.
The import/export formats of the relevant object types (master and reported data) were adjusted. The new attributes were appended in the standard formats '#TXT' allowing existing interfaces to work as they are. At definition of new interfaces we recommend the use of individual formats to be independent from these successively developed formats.
The charts of controlling objects are defined uniquely by the definitions of facts (FAC) and companies (GES) and therefore needn't to be stated in the import data. They are completed automatically.
The particular application for import of p&l-thereof-intercompany-account-balances (TXTICKONV) does not support the enhancements. Especially the automatic split of the controlling balances between original account and intercompany account is no longer possible, if there exists more than one record per controlling object, since it is not unique which data record to split.
The database table increments are considered in the group-wide as well as in the subgroup data exchange.
Processings
The currency conversion performs a clearing between intercompany account and controlling balances like before, if the intercompany account balances are provided with controlling objects. This clearing now considers all controlling dimensions used.
The function for generation of controlling balances out of intercompany account balances was enhanced accordingly. The function for deletion of controlling balances was converted to the new database table.
The carry forward applications consider the additional controlling dimensions, too. This concerns the period carry forward of postings and consolidation postings as well as the closing of company statements with controlling and intercompany account balances and the generation of these data out of postings. However, the controlling balances origin list (KSTHER) created by closing of company statements remains restricted to the first controlling dimension.
The D&C and the I&E consolidation are the only consolidation functions considering the enhancement of up to 10 controlling dimensions, provided that the intercompany account balances processed are held with allocation of controlling objects. Then these entries are transferred to the generated consolidation postings. Thus essential aspects of the P&L, the main field of application of controlling details, are covered.
Further applications do not support the additional controlling dimensions for a start. This especially concerns the form entry, further consolidation functions and the MIS preparation.
The entry of up to 9 additional controlling objects per account in the consolidation parameters is not feasable, too. However, now it is checked whether an entered account requires the entry of a controlling object for the first dimension due to the new flags in the account master data. Therefore some consolidation postings might result, where missing controlling objects have to be supplemented manually.
Reporting is not adapted, too, particularly because the limited structure of the report result table would support at most two controlling dimensions, and even this only in special cases. Therefore controlling reports still are limited to the first controlling dimension. A multidimensional evaluation is provided by an OLAP database.
The MIS preparation function for transfer of IDL.KONSIS.FORECAST data into an OLAP database was not supplemented by the additional controlling dimensions, too, since a new function is in development allowing to fetch the data directly into the OLAP database with aid of the IDL importer.
A facility for definition of customer specific plausibilities in company financial statements has been invented by new database tables and applications. The compliance of these plausibilities is visualised by an additional status column in the company financial statements monitor (EA).
Definition of Check Rules
The first new database table for check rules contains an up to 20 digit key and several attributes for description of the data on the left and the right side of the check rule. A list (PRF), single record (PRFE), and import application (TXTPRF) are provided.
The second new database table contains the allocation of positions and accounts to a check rule, differentiated for the left and the right side of the check rule, i.e. the data to be compared. This comprehends a possibility to restrict a position or an account to a transaction development column or a posting key. A list (PRFPOS), single record (PRFPOSE), and import application (TXTPRFPOS) are provided.
Determine Check Results
A new application determines a check result per company, period and fact due to the check rules defined. Because of performance this function is not started automatically, when data have changed. Rather this function has to be started by an action of the company financial statements monitor (EA, submenu <Processings>) or of the new list "Check rule results" (PRFERG, see below).
The result of each check is written into another new database table. In addition a total result of all check rules is subsumed in a new record of the processings table (VERARB, Checkpoint PRFERG).
It might happen, that a chart of accounts given in the check rules is not valid for a fact or a company. In this case a special message is set for this check rule, that doesn't affect the total check result, since this check rule then is considered as not existent.
The sign of an amount is just set due to its debit/credit flag, since positions and accounts may be mixed arbitraryly in a check rule, while the report considers the balance sheet/profit&loss code of the positions for sign determination, which is unknown or undefined at usage of accounts in check rules.
The check result for a single check rule is determined per currency code (dependent from the flag for currency conversion in the fact/FAC). However, for the total result only one record is written into the processings table, which is only clean, if all check rules have been faultless in each checked currency code.
Visualisation of Check Results
A new list application (PRFERG) provides the display of all determined check results.
The total result of all check rules per company due to the message in the new processings record (VERARB) is displayed in the company financial statements monitor (EA) in a new status column. Double mouse click into this column branches into the new list for check results (PRFERG).
The message in the processings record (VERARB) is set to a message "check result not up-to-date" at any change of relevant company financial statements data providing the status <yellow> in the company financial statements monitor (EA). However, this control requires the activation of check sums (flag for the fact/FAC).
From the beginning there was the problem in IDL.KONSIS.FORECAST, that transaction development data of consolidation postings were not carried forward for single use vouchers (posting type 'E'). The information was only carried forward in the group development transactions held parallelly, however it resulted a discrepancy between group transactions and consolidation postings (see protocol of action <Check grp.transact./consolid.post.> in the list applications for group development transactions). Furthermore group development transactions shall be abolished completely (see above) to omit redundant data. These postings not carried forward were missing in cash flow report, too.
The same problem occurs for postings affecting net income in single use vouchers. Here the reposting to the account for retained earnings was missing, too.
For these reasons the rules for carry forward were revised with the aim to carry forward transaction development information independent from the posting type of the voucher. Consolidation postings on accounts allocated to a transaction development with carry forward (posting key with usage flag 'V' is defined) and postings affecting net income are always carried forward. If they are contained in a single use voucher (posting type 'E' or in some cases 'WX'), then in addition a posting is created, that eliminates the forwarded amount with a posting key for current changes. For an automatic transaction development this is the key with usage flag 'L', for other developments a posting key with the new usage flag 'N' has to be defined. New posting keys for the standard developments (fixed assets, equity capital and provisions) are delivered with this release.
Vouchers for debts consolidation (SK) are excluded from this carry forward rule, since they eliminate values of the company's financial statements per period. The corresponding carry forward is contained in the company financial statement carry forward in the next period. This only applies for postings on intercompany accounts. Postings for difference clearing or interim values as well as manual postings are carried forward due to the new rule. The exception is only applied for accounts for postings on accounts with entry of a consolidation function ('S1' e.g.) in the account master data (KTO).
For clarification of the facts several consolidation functions were modified in a way, that the created consolidation vouchers yield a posting type according to their carry forward rule. E.g. consolidation vouchers from capital consolidation now have the posting type 'WU' instead of 'E'.
The posting type 'WV' (carry forward without amounts just as posting template) occurs for manual vouchers ('Mx') only. The postings carried forward according to the new rules explained above are written into a carry forward voucher with consolidation function 'Vx'. To avoid confusion the postings for the template with zero amounts are written into a new 'Mx' voucher.
The subsequent carry forward clearing for automatic transaction developments ('FU' voucher) becomes superfluous by these carry forward rules. However, the corresponding function <Cash flow repostings> is not abolished at once but provides a validation function for a transition period.
This carry forward rule described up to now for consolidation vouchers is applied to the carry forward of postings (BUCH) of the company financial statements similarly.
Two new list applications provide the joint display of company and group financial statement data:
These lists serve for the analysis and clearing of report results (e.g. with selection criteria due to a selected line after call from the report result display (REPERG)). In some cases they might substitute a report for ad-hoc analyses.
You find entries for both lists in the menu tree in the branch "Group consolidation". They also can be called as subsequent applications by action menu from the group company monitor (KTKGES) and the report result display (REPERG).
Both applications allow the selection of data for group (with option for inclusion of subordinate subgroups like KONBUCH), company, in case business unit, period, fact, position and account. In addition KONBEW allows a selection for transaction development column and posting key. The entered language acts upon the descriptions of positions, accounts etc. like in other applications. By entry of a currency code ('KW' for group currency, 'PW' for parallel currency) you can control in which currency amounts are displayed.
The following sort options are available:
The display of the data is performed in tree structure due to the selected sort option. The amounts are added to the nodes of the tree. Keys with unique selection entry aren't displayed in the tree structure. In addition at the end of the table the total of company and group financial statement and their sum are displayed.
The data records read (account balances, company transactions, consolidation postings) are displayed at the lowest level of the tree structure and are designated by the voucher number or a suitable text (e.g. "account balance").
The tables contain only one column for amounts and one column for debit/credit flags beside the key (position number, account number, company, business unit, development column or posting key) and its description. In addition the modify information for each data line can be displayed.
The update equity was enhanced by a number of entry possibilities. The enlarged map now has the style of a form entry where the entered values are calculated into subtotals and totals automatically. The entered data are transferred into the database by pressing the button <Save>.
The entry map for update equity consists of three groups:
Transfer/Carry forward
The group for Transfer/Carry forward is divided in two parts:
The development of the cumulated update of asset values consists of the following positions:
The position "Other of transfer/carry forward" displays postings from previous equity updates, that were not posted on one of the accounts of the new consolidation parameter 'EF'.
The correction of a negative value consists of the following positions:
Actual modifications
The group for actual modifications provides the following entry possibilities or values (out of 'EK' or 'KF' voucher) displayed:
The output data are read from the 'KF' voucher. In case they have to be entered there manually.
Clearing of negative value
The group for clearing of negative value is divided in two parts:
At appearance or increase of a negative asset you have the following entry lines:
At reduction of a negative asset you have the following entry lines:
At entry into the third group you have to mind the following restrictions:
Others
The accounts (and posting keys) required for update equity have to be entered in two new consolidation parameters: 'EF' (update equity actual modifications) and 'EN' (update equity clearing of negative values). If optional accounts (or posting keys) are not entered in a consolidation parameter, then the corresponding entry lines are missing in the entry form.
A previous period can be entered beside the actual period. Then additional columns are displayed in the entry map for the periods for annual financial statements contained in the period interval. These columns show the corresponding values of the previous years, but without allowance for entry.
Several report functions have been supplemented. Beside others these are
Up to now IDL.KONSIS.FORECAST supported only characters of the Western European standard codepage (Windows codepage 1252). Characters of Eastern European languages as well as other codepages (Greek, Cyrillic, Hebrew, Japanese etc.) couldn't be used in IDL.KONSIS.FORECAST. This has changed with the present release.
Up to now one byte was sufficient for the encoding of one character. Encodings for international codepages realised by the Unicode standard require more than one byte per character.
Consequence for the Database
It was determined to support Unicode characters not in the complete IDL.KONSIS.FORECAST database but only in the tables for multilingual descriptions and help texts, that are defined centrally. The tables were defined newly (new data types for the respective columns). This means that key columns (e.g. account numbers, company numbers) still only may consist of characters valid up to now.
Descriptions, that were contained in the respective database table, have to be transferred into the central description table. Beside some master data (fixed asset objects) this concerns remarks and texts of reported data (balances, transactions, vouchers and postings). However, these texts still are not supported multilingually.
The conversion of the meta data delivered by IDL is performed by the input of the meta data of this release. The conversion of customer specific data is performed by the release specific converting program, that might take some time due to the amount of customer data.
The database systems support Unicode codepages differently. Thus you have to distinguish between the database systems for the abilitiy to use this enhancement:
Import and Export
The fields of the table for descriptions, description or short word for accounts (format type KTO) e.g., were marked with data type "UNICODE" in the table "Fields for Import/Export Formats" (IEFDEF). This provides, that these field may contain characters of international character sets.
The standard import formats '#TXT' remain unchanged (except for some application specific supplements), so that existing interfaces can be used without modifications.
For the purpose of importing data with characters not supported up to now the complete import file has to be written in a respective encoding (UTF-8 e.g.). The definition of the encoding is effected by a special byte sequence at the beginning of the file (supported for UTF-8 and UTF-16), via control parameter "$$ CODEPAGE" in the file header or by allocation of an encoding to the import/export format (IEF). The latter entry is required for creation of export files in a deviating character set. Without specification of an encoding the standard Windows codepage 1252 is assumed.
If non-Unicode columns (key fields e.g.) of an import file contain characters not convertable into the standard codepage (Windows 1252), they are replaced by question marks. This might provide subsequent errors.
Creation and reading of import files with deviating encodings requires an editor, that handles these codepages.
A conflict arises for the protocol output, since the output of the faulty data records and the output of error information might require different encodings. Thus it can't be read simultaneously. Therefore the protocol output was split up:
The version 9 of the database IBM DB2 is supported now.
Pictures contained in the online documentation are no longer stored in the database but rather in files of their own. This shortens the time for installation of a new release considerably.
The facility for changing your password (button <Extended ...> in the login box) now is availible for MS SQL Server databases, too.
In context with the Unicode conversion the central table for multilingual descriptions was redesigned. Beside others the former "Description 2" has been dropped, if it had no other relevance (as table column header e.g.). Customer specific data with a description 2 have been transferred into the help text of the object by the release specific converting program, so that it isn't lost. This concerns the company master data e.g. You should check, whether this information is required in the help text.
If a list displays a table in tree structure, then the expansion state is maintained after changing the keys (e.g. at change of currency or company in the report result display), if possible.
For the purpose of better legibility of error messages account numbers are now output without preceeding chart of accounts. Usually the corresponding chart of accounts can be derived from the context (fact, company).
The conversion program for this release performs the following conversions:
In addition all conversions of the interim maintenance 2006.1 are proceeded, if this interim maintenance had not been installed.
The following menu items are new with this release. If 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 an sample.
A new standard user group IDLEE (or IDLWINEE for IDL WinKons, respectively) was defined for the role of a company financial statement decider. A user allocated to this group may only display all company financial statement data, but not modifiy. In addition he may release a company financial statement. However, he may not revoke this release by himself.
A new sub-menu <Check Rules> was supplemented in the menu branch <Master Files>. Below this you find the new applications for individual plausibilities.
A new sub-menu <Master Data Logging> was supplemented in the menu branch <Master Files>. Below this you find the old and new applications for logging of master data changes. You can see this sub-menu only if you have licensed the component "Master data logging" (see next chapter).
The licensed features (controlling, master data logging) are now considered at contruction of the menu tree. Menu items for unlicenced features are suppressed. The corresponding applications can be called neither from the menu tree nor via short word entry.
Furthermore now a check for licensing of foreign-language user interfaces (English, French) is performed. At attempt to login with adjustment of a non-licensed foreign language IDL.KONSIS.FORECAST aborts after output of a corresponding error message. At problems please contact the IDL hotline.
With aid of the new application "Controlling Dimensions" (short word 'CDM') you can specify, whether you want to use additional dimensions for your controlling details. The descriptions allocated to the controlling dimensions are used in other applications. You find this application in the menu tree in the branch "Master Files" -> "Accounts & Positions".
The table for the charts of accounts / controlling objects (KTP) was enhanced by an attribute for the controlling dimension. This attribute has to be entered for charts of controlling objects (chart type 'C' or 'M').
The table for accounts (KTO) was enhanced by an array of flags that define, which controlling details are required for an account and which are not admitted. This flag array replaces in some kind the former account flag 2 = 'C' and provides a control for each account. This flag array is inherited from the group account to the allocated company accounts.
Balance sheet or p&l accounts, respectively, now can be allocated as aggregation account to each other arbitrarily (asset to liability account, income to expenses account, e.g.) without change of the balance sheet/profit & loss code. Up to now always the balance sheet/profit & loss code of the aggregation account was inherited by the account.
The short word of the application "Controlling Objects" was renamed from KST to CNT.
The controlling flag 1 for allocation of controlling objects to cost types for the cost of sales accounting (COS) was extended by 9 individual usable cost types with the keys 'Z1' to 'Z9'. These may be used, if the former standard classifications ('A' = general administration expenses, 'F' = research & development expenses, 'H' = acquisition/production costs, 'V' = selling expenses, 'U' = allocation of costs, 'S' = remaining expenses) were not sufficient. However, there is no ability for inidvidual description of these cost types.
Like the old ones the new cost types can be used in the account + position allocation (POSKTO) for a differentiated allocation of the balances to different positions. They are displayed in separate columns in the COS report (report type 'C'), too.
The entry field "Reference position" has been dropped from the single record map "Position" (POSE), since this attribute had no meaning any more.
Like other master data fixed assets objects (ANLOBJ) now can be provided with a longer description (= help text). However, these texts cannot be entered in different languages. This also applies for intercompany fixed assets objects.
The new posting keys '18' and '36' with the usage flag 'N' have been supplemented for the equity capital and the provision transaction development. These posting keys are used for elimination of carry forward postings from single use vouchers.
The new posting key '30' was supplemented for fixed assets transaction development. It has the usage flag 'U' (currency conversion difference) for the development area 'B' (depreciations).
Attributes for charts of controlling objects for additional controlling dimensions were supplemented in the table for companies (GES). An entry is required dependent from the controlling dimensions (CDM) defined and the flag for controlling details.
Attributes for charts of controlling objects for additional controlling dimensions were supplemented in the table for facts (FAC). An entry is required dependent from the controlling dimensions (CDM) defined and the flag for controlling details.
The flag for controlling details now only distinguishes between '-' (without controlling balances) and 'X' (with controlling balances). A differentiated control proceeds per account.
The logging of changes of master data (feature at the customer's expense) now is available for the following tables:
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.
A new list application per table provides for display and analysis of the logged data:
These list applications display the log records, allow selections for the important attributes (like the master 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.
The status for "Check carry-forward new Period" now is set to <yellow> automatically, if data relevant for carry forward (development transactions, shareholdings, postings) have been changed in the previous period, presumed
The status of the check becomes <red> or <green> due to the kind of change at repetition of the check.
A new status column "Check carry-forward new Fact" shows the result of the action <Check carry-forward account balances>. The status is refreshed at each call of this action.
A new status column "Check Rule Result" shows the result of the check of customer individual plausibility rules (see above). A double mouse click in this column proceeds to the new list application PRFERG for check rule results. This status is refreshed by call of the action <Calculation of check rule result> in the sub-menu <Functions ...>.
It is no longer possible to revoke a release of a company financial statement (function of the monitor EA), if a group financial statement for a group, where the company is allocated to, is already released (function of the group companies monitor KTKGES).
Longer descriptions ("help texts") can be entered for all reported data (balances, transactions, vouchers, postings) (see above).
At selection for a subgroup (e.g. after proceeding from a group report) the list application "Account balances" (KTOSAL) now displays a list of companies, for which account balances exist, but the particular user has no display authorisation, so that they aren't shown, in the message window. In case this explains differences between report result and the balances total.
The actions "Display help text" (or <F1>, respectively) and "Edit help text" (or <Cntl-F1>, respectively) no longer refer to the help text of the relative account but rather to the (newly invented) help text for the account balance (see above).
If you select a single account in a list application for detail data (controlling balances / CNTSAL, intercompany account balances / ICKTOSAL, fixed assets transactions / ANLBEW, capital transactions / KAPBEW, provision transactions / RUEBEW, individual development transactions / SPIBEW, shareholdings / GESGES), e.g. via double mouse click on the account flag in account balances (KTOSAL), then the difference between the sum of the detail data and the account balance is displayed in the empty line between detail data and compared account balance. This amount is displayed with red background. The display is performed in all currencies. This amount has to be used for a new detail record to clear the open difference.
The database table for controlling balances was newly defined (new short word: CNTSAL), so that up to 10 controlling objects for different controlling dimensions can be entered simultaneously. These entries are required due to the new flags in the Accounts (KTO). In addition, several controlling balances can be held per controlling object (or combination of controlling objects, respectively).
At selection for a subgroup the list application "Controlling balances" (CNTSAL) now displays a list of companies, for which controlling balances exist, but the particular user has no display authorisation, so that they aren't shown, in the message window.
Attributes for the new clearing facility were supplemented in the table for intercompany account balances. The new attributes "Reference voucher number" and "Reference voucher date" are displayed and may be entered (ICKTOSALE). The new action <Mass Update> of the list (ICKTOSAL) serves for setting of the clearing flag.
Like the controlling balances the table for intercompany account balances was supplemented by further controlling objects. Under certain conditions in the single record application (ICKTOSALE) up to 10 controlling objects for different controlling dimensions may be entered simultaneously.
The intercompany balances list in the clearing view (couple display) like after proceeding from the "IC Clearing List" (KGESGES) performs an implicit currency conversion for the displayed data. Up to now this was a simple conversion by the closing rate (SK). Now the implicit currency conversion converts p&l intercompany balances by the currency rate average per period (PDK), if a currency conversion header (WUM) exists with a conversion method different from closing/current rate method (RST). This also applies for the intercompany reconciliation of the company financial statements.
The intercompany now is descripted by the description instead of the short word in the description column of the list intercompany account balances (ICKTOSAL).
The check of the current depreciations with the p&l account balances for accounts with account flag 'D' now is only performed for non-statistical accounts. This correspondingly also applies for the check for releases and additions of provisions (account flags 'Y' and 'Z') as well as for the transaction columns for reposting (total of all transactions equals zero). No checks are performed for transactions on statistical accounts.
The check for plausible percent values (participation between 0% and 100%) now takes place not only for the end of the actual period, but for all interim dates, too (date of group companies disposal, e.g.).
Furthermore it is excluded, that two shareholding transactions with different posting keys refer to the same transaction date, since then the sequence of processing of these operations is not unique. The only exception is a deconsolidation of a company, whose parent company is disposing from the group companies. Then a disposal and an addition of participation with the same transaction date have to be entered.
The new posting key '13' was introduced for shareholdings (GESGES). It represents currency rate effects for the case, that a participation is held in foreign currency (asset of shares in a fond e.g.). The user has to report these currency rate effects each year on the shareholding account with this posting key in the company financial statement. A record with posting key '13' must not contain percent values.
An action to proceed to the list "fixed assets transactions" (ANLBEW) was supplemented in the "shareholdings/participations" list.
By input of negative values now inventories IC-stocks may be entered as debit as well as credit values.
Like the controlling balances the table for postings was supplemented by further controlling objects. Under certain conditions in the single record application (BUCHE) up to 10 controlling objects for different controlling dimensions may be entered simultaneously. Corresponding controlling balances, and in case intercompany account balances, too, are generated out of these postings by the carry-forward to the next fact.
At selection for a subgroup the list applications "Vouchers" (BEL) and "Postings" (BUCH) now display a list of companies, for which vouchers/postings exist, but the particular user has no display authorisation, so that they aren't shown, in the message window.
The message indicating, that a voucher contains postings on statistical accounts, has been dropped without substitution.
The list "Postings" (BUCH) now displays the column for the posting keys on the first page like for consolidation postings (KONBUCH).
The posting key for current changes (usage key 'L') is set automatically at entry of a posting on an account for automatic transaction developments ('S9' e.g.).
Incomplete months now are considered fully in the calculation of depreciations in the actual period. I.e. the depreciation of a fixed assets object is calculated for the acquisition month independent from the day of acquisition. Up to now the month was considered only, if the 1st of the month was set as acquisition date. This concerns the company financial statement as well as the group financial statement.
At entry of a fixed depreciation per year (depreciation method = 'F') the acquisition date is considered now. If the acquisition date is newer than the end of the actual period, then no depreciation for the actual period is calculated and posted.
The entered data are checked after saving them. The result of the check now is displayed in a message window, if differences had occurred.
It is now possible to enter account balances for several business units or several periods (plan data e.g.) in one map. The new column options 'U' (for business units) and 'P' (for periods) serve for this purpose.
With column option 'U' for each business unit an entry column for its own is output. The set of business units is determined from the table "Company / Business Unit Allocations" (GESUBR). An entry in the entry field "Business Unit" is not considered.
With column option 'P' a previous period as well as a period distance (in months) have to be entered. Like in the period report from these entries the enterable periods are determined. Of course, these periods have to be defined in the table of periods (ABR).
The entry of development transactions (fixed assets, capital, provision and individual development transactions) with column option 'FS' (one column per posting key) now is possible, even if more than one transaction per account and posting key is existing. The according cell displays the balanced value of these transactions. However, this value may not be changed, since there is no unique allocation to a transaction.
The functions "Quick insert" contained in the list applications "Account balances" (KTOSAL), "Intercompany account balances" (ICKTOSAL) and "Controlling balances" (CNTSAL) up to now were deactivated, since this functionality is provided by the form entry applications.
Due to the redesign of the central table for descriptions the following import formats were changed (possibilities with respect to fields in IEFDEF as well as the standard format '#TXT' in IEFFEL):
The list "Transformation group allocations" (UMSOBJ) now allows a selection for "from modification date".
The calling application "Data Import and Display" (IMPORT) now displays only those lines, where the user is authorised to start the respective import application. Up to now an authority check was performed for the tree nodes only.
Due to the Unicode Restructuring the error logging output for the import was redesigned:
The import of account balances without preceding delete now principally works in "update mode". I.e. the import of account balances for a company is possible even if account balances for this period and fact exist. Thus it is possible to import e.g. account balances for balance sheet, profit & loss and appendix from three different sources independent from each other. If an account balance already exists, it is updated.
The only potential problem of this procedure is, that existing account balances are not deleted, if an account balance is missing at a repeated import. However, in this case (multiple import of the same data) you should work with the action "Delete data & re-import ..." like it was required up to now.
You now can enter '-' (without carry-forward) in the entry field "with/without carry forward" of the calling application "Data Import and Display" (IMPORT). If you enter '-', then the records for automatic carry forward (posting key with usage flag 'V', 'SV', 'M' or 'SM') contained in the import file are not processed. Thus a period carry-forward performed by IDL.KONSIS.FORECAST cannot be modified by imported data. This concerns all import applications for transactions (shareholdings, fixed assets, capital, provision and individual development transactions).
The other flag positions ('X' = "with carry forward" or space = "without carry forward") work like before only on the deletion of data with the action "Delete data & re-import ...": With 'X' all data are deleted, with space data for automatic carry forward are excluded from deletion and are maintained.
The automatic setting of a business unit, if it is missing in the import data, was redesigned for all applications, that process business units:
The automatic setting of an intercompany business unit, if it is missing in the import data, was redesigned for all applications, that process intercompany business units:
Postings on transaction development accounts (only accounts with automatic carry-forward) and postings affecting net income now even are carried forward with posting type 'E' (single use voucher) (see above). In addition an elimination posting is generated on the same account with the posting key for current changes (usage flag 'L' or 'N').
Postings are no longer provided with currency conversion rule 'VKW' (predefined amount group currency) in general, but only if they were provided with 'VKW' in the previous period.
At carry forward to the next fact it is checked, whether data are already existing in the destination fact. If the respective warning message is accepted all data were deleted including data from automatic period carry forward data. Now the user is asked, whether existing period carry-forwards (from transaction development) shall be maintained. Then you have to select one of the following answers:
At carry forward of intercompany account balances (besides reference voucher number and date) the new clearing flag is transferred to the next fact. I.e. a manual or automatic clearing flag from the intercompany reconciliation in the company financial statements remains valid for the group financial statement.
The application "Check carry-forward account balances" (callable from the company financial statements monitor EA) creates a processings (VERARB) record with the check point "SIMVOR" for the result of the check. The message code entered there provides a corresponding status display in EA.
The global deletion of account balances (action of the company financial statements monitor EA) now deletes a corresponding origin list, too, since the origin list has no meaning without its result.
Consolidation postings on transaction development accounts (only accounts with automatic carry-forward) and consolidation postings affecting net income now even are carried forward with posting type 'E' (single use voucher) (see above). In addition an elimination posting is generated on the same account with the posting key for current changes (usage flag 'L' or 'N').
You can label consolidation postings with the new posting type 'EP' (single use in this interim period), that shall not be copied into the next period at carry forward from an interim financial statement (month, quarter).
At copy of consolidation postings for a report subgroup (calling application REPKTK) now also consolidation postings for companies not consolidated (consolidation type 'K' in report subgroup) are copied. If you do not want this behaviour you have to delete these companies from the report subgroup.
A double mouse click on the columns for conversion differences in the list "Currency conversion GCurr+PCurr" (WUM) now proceeds to the list "Account currency conversion audit trail" (KTOUMR) directly. This list is reduced to balance sheet or p & l accounts depending from the clicked column, in case also for the previous period.
At mass copy of currency conversion headers to a new period now the previous period is determined and set to the latest annual closing date (period flag = 'J') before the actual period. This applies for copying in the single record application (WUME), too.
At copying of currency conversion headers (list and single record application) now the allocated account currency conversion rules (KTOUAW) are copied, too.
The update of the account currency conversion rules is performed sophisticated at modification of the conversion method. At modification of the conversion method for group currency conversion only group currency conversion rules are updated, at modification of the conversion method for parallel currency conversion only parallel currency conversion rules.
A deviating previous fact now can be entered optionally for currency conversion. The previous fact is entered in the currency conversion header (WUM) like a previous period and is saved in the according processings record (VERARB for check point WUM). It is also entered there automatically at period carry forward with a deviating previous fact. The currency conversion as well as the list of account currency conversion audit trail (KTOUMR) use this previous fact for determination of values for the previous period.
A currency conversion now is allowed, even if there are no account balances for a company but only detail data, that add up to zero per account. Like before for all accounts with detail data an account balance with zero amount is generated. No currency conversion is allowed furthermore, if the account balances are incorrect (status <red>).
The currency conversion for shareholding transactions (GESGES) on accounts with historical conversion rule (FDK) now is performed differentiated by intercompany due to parallel details for fixed assets transactions (ANLBEW), presumed the fixed assets transactions are provided with intercompanies completely and consistently to the shareholding transactions. Up to now any conversion difference for shareholding transactions was allocated to the first intercompany.
If a shareholding account is not converted historically (FDK), then the currency rate effects on the amount carried forward now is determined and saved differentiated by intercompany, too.
The historical conversion of a shareholding account now is supported, even if this account is allocated to an individual transaction development instead of a fixed assets transaction development as usual. Then the historical conversion (FDK) is applied for the individual transaction development. The user has to care for consistency between sahreholdings and individual transactions in local currency.
The adjustment of the converted amounts of intercompany balances and controlling balances was extended for the additional controlling dimensions.
The account for net result (account flag = 'E') is provided with the currency conversion rule 'PDK' only, if p&l differences are allocated to balance sheet accounts and all p&l accounts are converted with the currency rate average per period (PDK).
Conversion differences for p&l accounts with conversion rule not equal to 'SK' (closing rate) now are written into the account currency conversion audit trail (KTOUMR) just like differences for historical converted (rule 'FDK') account balances. Thus the total p&l conversion difference can be split into contributions per account, too. A double mouse click on the columns for conversion differences in the list "Currency conversion GCurr+PCurr" (WUM) now proceeds to the list "Account currency conversion audit trail" (KTOUMR) directly.
If an account for conversion differences (currency conversion header / WUM) is allocated to an automatic individual transaction development ('S9' e.g.), then a suitable development transaction correspnding to the account balance is generated. This transaction yields the posting key for currency conversion differences (usage flag 'U').
Transactions generated for the conversion difference accounts now yield a posting remark ("Diff. b/s current period", "Diff. b/s previous period", or "Diff. p&l current period").
Currency conversion differences (difference between currency rate average per period (PDK) and closing rate (SK)) determined for p&l accounts (see above) now are displayed in the account currency conversion audit trail (KTOUMR). However, for p&l accounts no differences from the previous period are displayed.
If a consolidation posting carried forward contains the currency conversion rule 'VPW' (predefined amount parallel currency), but the account shall be converted into parallel currency by 'SK' (closing rate), then an additional consolidation posting is generated for this account with the difference in parallel currency like in the company financial statement's conversion. The amount in group currency of the posting remains zero. These postings can be identified by their posting text ("PC exchange rate diff carry forward").
The posting key for exchange rate effects (usage flag 'K') or, if not present, the posting key for conversion differences (usage flag 'U') is allocated to this posting. The posting key '30' was supplemented in the fixed assets development for development area 'B' (depreciations) for this purpose. For transaction developments with automatic elimination (for cash flow reporting) the posting key is distinguished by the origin posting key: Posting key with usage flag 'U' for the intrinsic development, posting key with usage flag 'K' or 'D' for the parallel cash flow view, posting key with usage flag 'SK' or 'SD' for the elimination of the parallel cash flow view.
The relevant carry forward postings are identified by the allocated carry forward voucher (consolidation function = 'KF', 'KV', 'KW' oder 'Vx') and posting status '1' (automatic generated posting). The total of these postings per posting record is eliminated by one posting for the account for parallel currency conversion differences due to the currency conversion header (WUM) of the company or reference company, respectively.
Consolidation postings for exchange rate effects generated this way are comprehended with the original postings at carry forward into the next period so that the number of postings is not increased year by year.
The new application "Account balances and consolidation postings" (KONSAL) was supplemented in the action menu of the list "Group companies + monitor" (KTKGES) in the sub-menu <Lists> (see above).
Up to now not-consolidated companies (consolidation type 'K') always were allocated to the world group (top level) of a multi-level group. This served for the constellation, that the company is allocated to several subgroups and cannot be assigned to one branch. Now the company is assigned to one branch, if it is unambiguous.
The status 'T' (consolidation function in subgroup) now (at choice of status colours) is no longer displayed on green but rather on white background, since the status 'T' only tells, that a function has to be performed in the subgroup, but not whether it really has been performed.
The current group/subgroup is transferred as parameter to the subsequent application "Account balances" (KTOSAL), so that the account balances are displayed with quoted values at selection of a quoted company.
The revised function Update Equity requires two new consolidation parameters 'EF' (Update Equity changes in actual period) and 'EN' (Update Equity clearing of negative value) with corresponding accounts (for a detailed description see above). The consolidation parameter 'EK' contains only accounts required for first consolidation ('EK'), sequent consolidation ('KF') and Deconsolidation ('KS').
By supplement of more consolidation parameters ('EF' and 'EN' with this release e.g.) it is no longer useful to display all accounts of all consolidation parameters in separated columns in the list of consolidation parameters (KTKPAR). Thus this list is reduced to a few accounts, that are used in several consolidation parameters, i.e. the account for retained earnings and the interim account for differences, if you select without restriction of the consolidation function (space or '%').
However, at unique entry of the consolidation function all up to 18 accounts and other attributes are displayed with specific table headers. This also applies in the case, that the entry of the consolidation function ('SK' e.g.) is interpreted as a reference consolidation function and several consolidation parameters with the same account meaning ('S1', 'S2' ... e.g.) are displayed. Partially qualified entries for the consolidation function ('S%' e.g.) are no longer supported. However, you can select 'SK' instead of 'S%'. Further on posting keys and controlling objects are not displayed in the list.
An account for "Currency conversion diff. on participations" was supplemented in the consolidation parameter 'KK' (see below).
The controlling parameter 'EK' (first consolidation at equity) now allows the entry of controlling objects like other consolidation parameters.
The calculation of participation and layers now checks not only, whether the shareholdings are the same in world and subgroup, but rather whether the prerequisites for a capital consolidation (by respective shareholding transactions in GESGES e.g.) exist. If this is the case, then like up to now the status <T> is set. However, the status is set to <-> if due to missing prerequisites no processing is required in the subgroup, too.
The status 'KA' (minority interests) for a company is set to <->, if the company has only indirect minority interests and the flag "without indirect minority interests" is set in "Group/Subgroup consolidated co." (KTKGESE).
If a company has yielded the 'KA' status <->, because no relevant data exist and thus no voucher was created, then this status is no longer modified by a repeated calculation of participation and layers.
The 'KA' status is set to <red>, even if no minority interests exist on the actual group level, if minority interests exist in a subordinate subgroup, that have to be eliminated on the current group level.
The new posting key '13' was introduced for shareholding transactions (GESGES). It describes currency rate effects for the case, that the shareholding is held in foreign currency (asset of shares in a fond e.g.). The user has to report these currency rate effect in each year on the shareholding account with this posting key in the company financial statement. A record with posting key '13' must not contain percent values.
A shareholding transaction with this posting key provides a <red> 'KK' status by the calculation of participition and layers. An account for "Currency conversion diff. on participations" was supplemented in the consolidation parameter 'KK'.
If a shareholding transaction exists with this posting key and the new account is entered in the consolidation parameter 'KK', then the first consolidation creates a couple of postings in posting record '01' of the 'KK' voucher. One posting eliminates the shareholding transaction with posting key '13', the cross entry is posted on the new account in the consolidation parameter 'KK'. This applies for the automatic first consolidation as well as for the manual capital consolidation, the latter allowing to modify the amounts.
The KK-reposting (reposting of the carry forward of the company financial statements into the column for group companies addition) is no longer performed, if the actual period contains a shareholding transaction (GESGES) with posting key '04' (setting for the begin of period = manual entry of carry forward), since then the company is not new in the group companies.
The update equity (EF) was enhanced by several additional entry possibilities and redesigned (see above).
The D&C and I&E Consolidation (SK/AE) now is no longer operable, if for companies with deviating local currency no faultless currency conversion has been performed. A corresponding message is written into the IC clearing record (KGESGES). The check is performed for the selected company as well as for all intercompanies named in the intercompany account balances.
The clearing flag is set automatically (see above) for coherent data at D&C and I&E consolidation as well as at IC reconciliation of company financial statements. Furthermore all differences in group currency of intercompany balances with the same manual clearing flag are treated as exchange rate differences, if both concerned companies have different local currencies, even if the intercompany balances do not contain values for transaction currency.
If for an intercompany account balance the currency code for the local currency of the company and the intercompany, the group currency and a specified transaction currency are the same and the amount in local/group currency is equal to the amount in transaction currency, then the amount in transaction currency is no longer considered. Thus intercompany balances can be cleared, if one company reports them with and the other without transaction currency values. Differences always are handled as real differences, since no currency differences are possible in this case.
The D&C and I&E Consolidation transfers the entries for controlling objects for the additional controlling dimensions from the intercompany balances to the generated consolidation postings.
Like the controlling balances the table for consolidation postings was supplemented by further controlling objects. Under certain conditions in the single record application (KONBUCHE) up to 10 controlling objects for different controlling dimensions may be entered simultaneously.
Now at validation of consolidation postings it is checked, whether the consolidation postings contain entries for controlling objects required due to the flags in the account master data (KTO). If not, this is reported and a message number is entered in the voucher header. Vouchers for development repostings (consolidation functions KU, SU, FU, QU, see below) are excluded from this check.
The information message for a consolidation voucher containing postings on statistical accounts has been dropped without substitution.
The posting type 'EP' (single use in interim period) already available for vouchers (BEL) of the company financial statements now can be applied for manual consolidation vouchers (KONBEL), too. These vouchers are not copied from an interim period (month or quarter) into the next period at group carry forward.
Longer descriptions ("help texts") can be entered for consolidation vouchers and postings (see above).
The "column order for details level 1" (for display of companies in columns e.g.) enterable in the report result display (REPERG) now can be preset by an according entry in the report header (REPE).
Another new entry field of the report header (REPE) serves for the control of generation of reports with decumulated amounts (see below).
At this opportunity the single record map (REPE) was redesigned. Beside others the entry fields for "Restriction StatementOAcc/Consolid" and "Display key column" now have a prompt text of their own.
The entry fields for "Detail-display options for report", "Display key column" and "Column option for report" have been removed from the selection area of the report lists (REP, REPK). These fields provided a preset of the respective fields when proceeding to the report result display. However, this now is commonly provided by attributes of the respective report header.
The columns for group and parallel currency (currency codes, check sums, etc.) are no longer displayed in these lists (REP, REPK), if the currency conversion into these currencies is deactivated due to the flag for the fact (FAC). Here as well as in the generation of reports corresponding indication messages are suppressed.
The function "Generate report header for company" generated report headers for all companies of a group out of a group report header. This function has been modified, so that no report headers are generated for companies with consolidation type 'K' (not consolidated) or 'E' (at equity).
On the other hand now report headers are generated for all subordinate subgroups, too (therefore new function description "Generate Report Header for Companies and Subgroups").
Both report result displays "Report" (REPERG) and "Report mirrored" (REPERGS) now can call themselves mutually via action menu.
The action "Zoom balances & transactions + postings" was supplemented in the action menu of both applications. This action proceeds into one of the new list applications "Account balances and consolidation postings" (KONSAL) or "Transactions and consolidation postings" (KONBEW) (see above) due to the report type for analysis of the values of the respective row.
If you call the action "IC-net book value" for a line for an account for inventories IC-stocks (account flag 1 = 'V'), then you proceed to the list "Inventories IC-stocks" (ICBEW). These account balances aren't cleared completely by the elimination of current assets results (ZU), but conflicts with other subsequent applications (Intercompany account balances/ICKTOSAL, Shareholdings/participations/GESGES) cannot occur, since these alternatives for "IC-net book value" depend on account flag 1 ('I'/'J' or 'B', respectively), too.
Report results occupy quite a lot of storage in the database. It might be useful to delete report results of earlier periods for the purpose to reduce the occupied storage. A new function callable from the report header lists (REP, REPK, REPSTR) serves for this. The report result is deleted while the report header is maintained. Thus the report can be generated newly if required. Attention: The same result is achieved only if the basic structures (report line definitions, position account allocation) haven't changed in the meantime. Please also mind the Advice for Group Reports.
It may happen, that one report generation overwrites position balances written by another report, if both reports have the report option 'S' (writing of position balances) and contain the same position. Dependent from the report definition the values may be different. To omit at least, that a real value is replaced by a zero value, position balances now are written no longer for positions with line type 'E', 'F' or 'R', but only for positions on report lines with line type 'P' or 'S'.
Now a report display is supported, where a comparison of plan and actual data per month (e.g. plan value / actual value / absolute deviation / relative deviation) is displayed for several months. The new report type 'S' serves for this purpose. Report IDs of this report type may refer (application RID) to other reports (e.g. with report type 'E') to avoid redundant report line definitions.
The report type 'S' supports up to 12 periods. For each period the data of both, the actual and the comparison fact are processed and written into the report result separated for balances and postings (i.e. up to 48 value columns per line). The comparison fact 2 has no meaning for this report. In other respects the processing is performed like the multi-period report (report type 'P').
The new standard column options #ALTS, #BUCS, #KONS, #KTKS, #NEUS and #SUMS were introduced for the display of this kind of report.
Up to now only amounts accumulated from the beginning of the fiscal year were written into the report result table. A display of decumulated values (amount of a single month e.g.) was provided by special column options, that subtract the amount of a previous month from the amount of the relative month. This procedure has the disadvantage, that column options always require the same number of periods and the same position of the year-end in the sequence of periods.
Now it is possible to create report results with decumulated amounts at report generation. A new entry field "Control of reverse accumulation" in the report headers (REP/REPK) serves for this purpose. The following entries are allowed:
This control for decumulation can be entered for period reports (report types 'P' and 'S') as well as for b/s/p&l reports (report type 'E'). In addition for b/s/p&l reports a distance of periods has to be entered, that defines the distance between a period and its decumulation period.
If the previous period of a period is a year-end, then the amounts are not subtracted, since the accumulation always starts at the beginning of the fiscal year. The year-end period is identified by the period flag in the period master data (ABR). A 'J' designates the year-end period and thus the final period of a fiscal year. Companies with deviating fiscal years shouldn't cause any problem, since their amounts have to be accumulated due to the fiscal year of the group for creating a group-wide financial statement.
The decumulation is processed independent from the balance sheet/profit & loss code of the account or position, i.e. for the balance sheet as well as for profit and loss, although a decumulated view is required only for profit and loss in general.
For b/s/p&l reports the decumulated amounts are written into the report result columns 01 to 24. In addition the accumulated amounts are written into the report result columns 25 to 48 providing the facility to display decumulated and accumulated amounts simultaneously. Corresponding column options are required for this presentation.
Group balance sheet/profit & loss reports now can process both, company postings (BUCH) and consolidation postings (KONBUCH), simultaneously provided that these postings are located at different facts, e.g. company postings at fact I3, consolidation postings at fact I4.
If both kinds of postings occur on the same fact, then only consolidation postings are processed. I.e. company postings are processed only if there are no consolidation postings for this fact.
The new controlling flags 1 (see above) can be displayed in reports for cost of sales reports (report type 'C') in columns of their own. The standard column options for COS reports ('#CALT', '#CBUC', '#CKON', '#CKTK', '#CNEU', '#CSUM') were enhanced accordingly.
Balance sheet/profit & loss reports now no longer consider consolidation postings of the consolidation functions for transaction development repostings (KU, SU, FU, QU). These vouchers contain only couples of postings on the same account and therefore have no effect for balance sheet/profit & loss reports. Particularly this concerns controlling reports (based on controlling balances and consolidation postings with entry of controlling objects), because normally the entry of a controlling object is missing in these postings, since they are generated based on company financial statement's transactions, providing nonessential error messages at report generation.
The data exchange (both, group-wide and subgroup) is not compatible between IDL.KONSIS.FORECAST 2007.0 and earlier releases. This is documented by an appropriate error message.
The <Options> dialogue (page "Import/Export") now allows the entry of a separate path for the files for data exchange (both, group-wide and subgroup data). Up to now the path for data exchange was linked to the import path.
The tables for account balance origin list and controlling balance origin list (display via applications KTOHER or KSTHER, respectively) were supplemented in the subgroup data exchange. However, these data are not transferred, if the origin fact is on the level of company charts of accounts while the fact(s) for data exchange is/are on the level of the group chart of accounts so that the company charts of accounts aren't transferred.
In addition the table for position balances (display via application POSSAL) was supplemented in the subgroup data exchange. The transfer of position balances is dependent from the transfer of report results (interrogation at unload of subgroup data). Then the position balances of the respective subgroup, all its subordinate subgroups and all companies allocated to the subgroup are transferred.
Furthermore the new table for check rule results (PRFERG, see above) were supplemented in the subgroup data exchange. Thus the plausibilities haven't to be checked in the head office again.
Foreign key violations (due to missing master data e.g.) now are reported and written into the log file more detailled at loading of subgroup data.
The new tables for check rules (PRF and PRFPOS, see above) were supplemented in the group-wide data exchange. I.e. the check rules should be applied throughout the group.
The position account allocations (POSKTO) are always transferred completely at group-wide data exchange independent from an entered "from modification date". The allocations are deleted in the destination database to ensure, that allocations deleted in the origin database are not maintained in the destination database. Up to now this deletion was performed per chart of accounts contained in the unloaded data. From now on the deletion is restricted to the chart of positions contained in the unloaded data, too. Thus allocations for a subgroup specific chart of positions, that is not maintained in the head office, are preserved.
Exchange rates (WKZWKA) are attached to the group-wide data in data exchange, because the data exchange conception assumes, that the exchage rates are maintained centrally to be unique throughout the group. However, there might be subgroups with deviating group currency containing companies with other foreign currencies. Then the exchange rates of the world group refer to a different group currency and the exchange rates may not be imported in the subgroup. Therefore unloading of exchange rates now has become optional and is interrogated in an own message window at start of the export. If you have set <Suppress message box> in the <Options> dialogue (page "Import/export") this interrogation is suppressed and exchange rates are unload like up to now.
The transfer of user definitions (tables "Users"/USE and "Start up data"/VOR) has been supplemented optionally in the group-wide data exchange. At unloading of the group-wide data the user is interrogated by a message window. Thus it is possible to define users and maintain their authorisations centrally and distribute them to the subgroups. If you have set <Suppress message box> in the <Options> dialogue (page "Import/export") this interrogation is suppressed and user definitions are not unloaded like up to now.
An additional dialogue has been supplemented in the function "Delete archived subgroup". There you have to repeat the entry of the keys deletion (group/subgroup, period, fact) for to ensure, that no data are deleted accidentally.
The extensions at the IDLCONNECTOR are documented separately.
A function for unloading of capital transactions (KAPBEW) was supplemented in the IDL SAP interface. The respective call with option /f=KAPBEW has to be entered at the menu item UNLKAPBEW. This function uses the function constituent Z_GET_ACCRUALS_TRANSACTIONS, that has been modified in the meantime to read all transaction data from the table GLT3 without restrictions. The parameter PrefixKapbewBwasl= can be entered in the kcusap.ini file in the section [Settings] to identify capital transaction for the purpose to reduce the number of complained import records. The transformation of the SAP transaction type group into an IDL.KONSIS.FORECAST posting key is performed by transaction groups (UMSOBJ).
For the topic
a cross-application documentation was created. For the first instance this documentation is only available in German language and obtainable in the menu tree in the respective branch of the application function ("Masterfiles" -> "Check rules"). It isn't contained in the "doku" directory of the CD as separate pdf document. However, it can be generated any time via the symbol <Export as pdf> in the online help text viewer when required. The application help of the accompanying applications (<F2>) contains a reference on this cross-application documentation.
With this release the following English-speaking documentations in the "doku" directory are updated or completed: