The release IDL KONSIS 5.4.1 (analogue IDL Winkons 3.1 and PPconsis 4.2) is an interim maintenance and therefore can be left out in the release sequence. Prerequisite for this release is the last main maintenance (IDL KONSIS 5.4.0 or IDL Winkons 3.0 or PP consis 4.01) of the Sept. 15th 9th 2005. The supplements and corrections to the main maintenance are contained in the current interim maintenance.
Users who work with individual transaction developments, have to define custom-designed texts (description see below) with this release for the used transaction developments. They otherwise cannot work with these individual transaction developments any more.
Beside the report display a number of further lists also contain multi-line headings from this release on. If the display of single-line and multi-line column headings is given with a different font (bold or not bold), this is caused by the selected font in the menu item <Options> -> <Options>-> <View>. Fonts representing a combination of font and style (e.g. <Arial bold>) shouldn't be used here. Rather font (e.g. <Arial>) and style (e.g. <bold>) should be stated separately.
The development planning provides that group transactions (fixed assets, capital and provisions) aren't supported with one of the next releases any more since this data are redundant to the consolidation postings and don't contain additional information. The users are therefore challanged
The evaluation of the formulae for column options and ratios (cared with the application <Formula lines list> (FED)) calculated wrong at a leading '-' in the first formula line. Instead of negating the first operand, the final result was negated. Customer individual column options and ratios are delivering perhaps wrong values after the correction of this error now if they were adjusted to the faulty formula calculation by 'Trial and error'.
The IDL Connector supports the version MS Excel 97 for the last time with this release as advised for over one year. Later releases will be no longer compatible. Please therefore opgrade to a more current Excel version on time particularly since the hotline service was also ceased meanwhile for MS Excel 97 by Microsoft.
The dialog control for the single record applications was revised completely. The new control provides more clarity at the concluded actions and in many cases for a simpler serviceability, too.
The actions <Display>, <Update> and <Insert> for branching from a list application to the respective single record application were comprehensed to one action <Edit data>. I.e. the action to be executed is not defined a priori but within the single record application. Merely <Delete> remains as an action of the list application, at which the single record map analoguely to <Mass update> only is displayed in the error case. Since <Edit data> also is the default action, which in general is triggered at double mouse click on a line, this simplifies changing a data record since e.g. the action <Update> no longer has to be selected by the object menu (right mouse button) or action menu but rather is executable after double mouse click.
The single record map distinguishes no more modes, i.e. all entry fields (keys and attributes) are input capable any time. Therefore all selection and drop down boxes are available without having to change to the insert or update mode. A small distance was inserted between keys and attributes so that these two field groups can be distinguished better by each other.
The single record map contains up to 6 buttons now. Besides <Next> and <Cancel> these are <Display>, <Update>, <Insert> and <Delete>, that were obtainable up to now by the object or action menu actions. Each button is suppressed completely, if it isn't supported by the application or if the user is not authorized for this action. In applications, that don't have a unique primary key (e.g. postings), the button <Display> is no more available. At mouse click on a button the corresponding function is executed in the database, i.e. <Update> and <Insert> replace the previous button <Save>.
Buttons whithout meaning in the current context are deactivated. Thus e.g. the button <Insert> is only active if a key field was changed, the button <Update> only after change of an attribute field. <Delete> after key change is only possible after the record to be deleted is displayed. <Next> and <Cancel> are always active.
One of the displayed buttons is the default button, that also can be triggered by the <Enter> key, recognizable at the thicker border. The default button is context sensitively indicated as the button, which most probably shall be chosen because of the inputs having been carried out. E.g. after Update having been carried out this is the button <Next> to edit the next marked line.
After processing of the last line marked in the list the text of the <Next> buttons changes to <End>. The pushing of <End> leads back into the list in which the displayed table is refreshed automatically. Unlike this the button <Cancel> terminates the processing sequence and returns into the list application without the table being refreshed. The unprocessed lines are further highlighted. If data were changed in the single record map without storage before, at <Next>/<End> the user is questioned, whether the data shall be updated or inserted, respectively. At <Cancel> this control query ceases.
The button <Next>/<End> can be triggered alternatively also on the key <F3>, the button <Cancel> like till now also by <F12> or <Esc>, <Delete> also by <Del>.
The maintenance of the company financial statements divided into business units is supported considerably more extensively as of this release. On the one hand, a new structure table "GESUBR" provides this purpose, on the other hand, the flag for the usage of business units at the facts.
The flag "Business unit layer" n the facts isn't new, but has considerably more meaning now, however. It is an obligatory attribute now and distinguishes the following values:
If data are maintained with business units, the permitted combinations must be defined in the new structure table "GESUBR" of company and business unit. The new application <company+business-unit allocation> (GESUBR) serves for it. For each company the allocated business units have to be defined here.
Further keys of the table "GESUBR" are the period and the fact. I.e. the business units allowed for a company can be defined differently per period and fact. By these keys the table also can be included in the period carry forward of company data so that the table must be only updated at change of the permitted business units.
When entering online, import or carry forward company financial statement data it is checked now, that the rules defined by the fact flag "Business unit layer" and the table "GESUBR" are followed. When forwarding company data to the next fact now processing control records are genereted only for the permitted business units (till now all).
When importing company statements, furthermore a default business unit is supplemented, if in accordance with "GESUBR" only one business unit is allowed for this company. This spares to indicate this business unit at the data entry.
The fact flag "Business unit layer" as well as the table "GESUBR" (for all facts and periods already defined) are set by the release specific conversion program due to the existing company statements so that in general no manual care of the data is required. You should nevertheless check the created data whether these meet the expectations.
The previous standard texts for individual transaction developments and their transaction development columns are replaced by custom-designed texts in future. A control was completed simultaneously, that only those transaction developments are displayed in different maps and selection lists, for which custom-designed texts were created. In this respect custom-designed texts have to be provided for the used individual transaction developments.
For the maintenance of the custom-designed texts for individual transaction developments serves the new application <description indiv. develpment trans> (ISP), that you cannot call by short word or menu tree inputs but only as a subsequent application of the list <facts> (FAC). The texts for individual transaction developments already inserted are displayed in this list.
Via the accompanying single record application <description indiv. develpment trans> (ISPE) these texts can be entered, changed or also deleted. The maintenance is possible in different languages. The key ('S1' to 'S9') used for individual transaction developments too serves as a key. The texts are distinguished into short text and long text for prompt texts and the representation in selection lists as well as the "expression for ABR, FAC, EA etc.", which is used as a table heading. By the usage of the character '|' in the text you can control a multi-line table heading for an column.
For each thus defined individual transaction development you get from ISP into the subsequent application <column description indiv. development transactions> (ISS), where you also have to define the used transaction development columns (report result values) and provide eloquent texts for them. These texts are used for the maintenance of posting keys as well as for the definition of report column options. Without these data you won't get any values in the corresponding choice boxes of these applications (BSL, FED).
The accompanying single record application <column description indiv. development transaction> contains the column number as a further key next to the key of the transaction development and the language. The column number lies between '01' and '20'. A long text (up to 35 characters) and a short text (up to 10 characters) as well as a text for column headings (by use of the character '|' multi-line) can be inserted here.
Coloured backgrounds are displayed in the columns for the account flags 1 and 2 as well as for the b/s/p&l flag (for controlling account details) per account in the list <account balances> (KTOSAL) and in the form entry application for account balances (I-KTOSAL). The colour oints out whether the detailed data are neat and consistent or not. Prerequisite for this colouring is the unique entry of company and business unit.
Two new form entry applications for the full-screen entry and update of inter company account balances (I-ICKTOSAL, see below ) and consolidation postings (I-KONBUCH , see below ) are available now.
A currency conversion (of p&l) at weighted monthly average rates is facilitated by IDL Konsis now. For this purpose an individual transaction development has to be created which must contain two posting keys: one for monthly carry forwards (new usage flag 'M') and one for the cuurent monthly changes (usage flag 'L'). All (p&l) accounts concerned have to be assigned to this transaction development via the account flag 2.
Analogue the transaction developments for cash flow reporting also the transactions to this transaction development are generated automatically. However, the usage flag 'M' causes a divergent treatment at the carry forward: At the carry forward from a financial year the forwarded value is set to zero, at the carry forward from an intermediate period however the pre-period values are summarized to a carry-forward transaction, which correspondingly contains the sum of the previous months of the financial year. The transaction for the current change is generated at change of the account balances from the difference between account balance and carry-forward transaction.
The currency conversion of the current change must be performed using the monthly average exchange rate. The new conversion rule 'MDK' for transactions as well as the new period reference 'MDK' with which the corresponding rate can be entered into the exchange rate table (WKZWKA) serve this prupose. This conversion rule most simply is assigned to the posting key about the application <posting key conversion rule> (BSLUAW) for the current change so that all current changes are converted with this exchange rate.
If the accounts are allocated to the conversion rule 'FDK' (sliding average currency rate) in the application <account conversion rules >, then a conversion results in the account balance at weighted monthly average rates.
Deferred taxes in the company financial statements can be charged analoguely to the group statements now also based on postings affecting the net income. For this purpose the table for vouchers (BEL) was extended by an attribute "LT status" with which all vouchers affecting the net income can be marked for the consideration at the calculation of deferred taxes. All contained postings are marked correspondingly ('with X') in the already available attribute for the LT status on p&l accounts automatically. When required the LT status of the postings also can be reset again.
The accompanying calculation is invoked by the action <Deferred taxes (LT)> in the application <deferred taxes headers> (LTK). This function is distinguished from the previous calculation of deferred taxes based on balance sheets difference to a tax fact by the fact that the tax fact isn't entered.
There also is the new action <Mark vouchers for LT> in LTK. If chose a call of the list <Vouchers> (BEL) is performed with selection according to vouchers affecting the net income. There vouchers can be marked for the calculation of deferred taxes by 'X' also by the action <Mass-Update> or be demarked by input of '*', respectively. These changes have an immediate effect on all contained postings.
The functionality of cash flow reporting after the enhancemants of the extension of the report functionality with release 5.3.1 and the introduction of generated transaction developments with release 5.4.0 is now completed by a function <Cash flow repostings> (FU), with which these automatically generated transaction developments also are adjusted on group level with the correct details (carry-forward and current change).
By suitable actions the perfomance of some applications could be improved considerably. In list applications storing texts for the individual lines intermediately instead of repeated reading leads to a shortening of the response time paicularly for selections with ambiguous keys (e.g. reading data and display for several companies). This concerns particularly
The password change at the logon to IDL Konsis for Oracle databases is also possible now if the password starts with a number.
The IDL Konsis application server already available new in the release 5.4.0 is now declared as standard. The conversion of the old to the new application server is documented in the installation instruction for this release. Users who don't use the application server aren't affected by this change.
The dialog control for single record applications was redesigned completely (see above.)
A changed order of the columns of lists with tree representation remains now when opening and closing branches now, too. However, to this columns, which contain values only in the state opened up, must be shown now, too. These columns were suppressed with empty column suppression till now.
The display of data in list applications requires mainly two steps which have an effect on the response time at larger amounts of data: reading the data from the database and the processing of the data lines for the user interface. A progress display is already spent on the second step in the footer line of the window. During the first step, in future, a progress display is also provided. This starts, however, only when the number of lines is larger than 1000.
As a rule in IDL Konsis data are locked against changes, if a lock date isn't older than 60 minutes. It then is assumed that the lock couldn't be reset because of a system error (e.g. net interruption). This period of suspension has proved to be too short when editing help texts since this process takes up perhaps for some time. A period of suspension from 24 hours therefore is applied to editing help texts in future before another user may edit a text if a lock is still registered. The same user may continue to work on locked data any time.
At the start of IDL Konsis a check of the version of the used Java runtime system is carried out now. If the version is smaller than 1.4 the application stops with an error message since 1.4 represents the minimum precondition. If the version is smaller than the Java version which is recommended (and included in the respective installation CD), a warning is output.
The conversion program for this release performs the following conversions in the database:
The following menu IDs are new in this release. If custom-specific autorization groups are used, authorizations must for these menu items (BENMEN ) be supplemented if necessary. As a sample the menu authorizations of the user groups IDLKON or IDLWIN can serve in general.
For the form entry of the applications account balances (I-KTOSAL) and postings (I-BUCH) the authorizations were changed. Adjustments if necessary have to be carried out also here for custom-designed authorization groups.
Till now, the entry of an aggregated account wasn't allowed for fixed asset accounts since no entry of an allocated aggregated fixed asset object was possible for the fact carry forward. Since this problem is solved now in the fact carry forward (see below) this restriction could be abolished.
The debt consolidation for statistical accounts was difficult since the validation of consolidation vouchers was carried out only for the non-statistical accounts when the voucher contained postings both on statistical and on non-statistical accounts. A matching by view control then wasn't possible. Therefore now the rule was introduced that either only statistical or only non-statistical accounts may be assigned to an inter company validation group ('A0' to 'A9' or 'S0' to 'S9'). This is examined in the account applications (KTOE, TXTKTO).
If an account couldn't be allocated to a group account in the action <Set group account allocations> due to the lack of a group account of the same name, the processing interrupted till now. A warning which makes a continuation of the allocation possible is distributed now.
The action <Delete group contr.obj. allocations> in the list application <controlling object> has been dropped. This function can alternatively be obtained by the input of '*' in mass-update of the attribute "Assigned group controlling object".
If an controlling object couldn't be allocated to a group controlling object in the action <Set group controlling object allocations> due to the lack of a group controllingobject of the same name, the processing interrupted till now. A warning which makes a continuation of the allocation possible is distributed now.
An attribute for a controlling object which can be entered as an additional detail of the depreciation account was supplemented in the fixed asset object table. At the calculation of the current depreciation this controlling object is used along with the depreciation account into the generated posting.
The standard fixed asset objects for the company financial statements per account (naming convention: Prefix+ account code) no longer have to be created by the action <Create fixed asset objects p/acc.no>, since they are created at the online input, at the import and at the fact carry forward automatically when required (see below.).
The flag "Business unit layer" at the fact is not new, but has considerably more meaning now. It is an obligatory attribute now and distinguishes the following values:
The flag is adjusted by the converting programme in accordance with existing data.
The flags "origin list account balances", "origin list controlling balances", and "with control-value calculation" are now always hald with values. Previous empty values are replaced by '-' now so that all switch positions can be explained by a translation. The conversion is made by the converting program automatically.
A new usage flag 'M' for automatic carry forward from intermediate periods is new availlable particularly for the Currency conversion at weighted monthly average exchange rates.
The output format of the export function was adapted to the standard import format of the new import function TXTBSL.
At the maintenance of custom-designed consolidation functions ('A0 'till 'A9', ' S0 'till 'S9', ' M0' to 'M9') no more attributes have to be entered in future. These are rather entered automatically since they must accord to the following rules:
An attribute for an e-mail address was supplementted in the company table. For this the previous entry field for a telex number has been dropped.
If data are held with business units, the permitted combinations of companies and business unit must be defined in the new structure table "GESUBR". The new application <company+business unit allocation"> (GESUBR) provides for it. For every company the assigned business units have to be defined here.
Further keys of the table "GESUBR" are the period and the fact. I.e. the business units allowed for a company can be defined differently per period and fact. Because of these keys the table also can be included in the period carry forward for company financial statements so that the table must only ba maintained at change of the permitted business units.
The table is initialized with the allocations due to the existing company statements by the release specific converting program. It is activated by the option "business unit layer" per fact in the table facts (FAC).
With the installation of IDL Konsis import files are for the tables <currency flags> (WKZ) and <country flags> (LKZ) are delivered in the directory Liefer_Batch so that the necessary master data don't have to be entered manually by the customer and the keys correspond to the ISO norm. However, the corresponding selections panels showed much more data than really used. Till now, the not required master data had to be deleted to omit their display. However, they had to be entered manually again if they then should be used anyway. Now a mass-update for the "valid-till-period" was supplemented in the two applications (WKZ and LKZ) so that all unused keys can be deactivated and aren't offered in the selections any more as long as applications with period reference (e.g. < Company financial statements monitor >, EA) are concerned.
The action <Create fixed asset objects p/acc.no> for the generation fixed asset objects per account (key = Prefix + account code) is no longer necessary. When importing fixed asset transactions as well as entering or copying online fixed asset objects of this kind are generated if they don't exist.
A new subsequent application of the <Company financial statements monitor> is the import call application IMPORT to more simply be able to import missing data.
When entering or importing data for company statements it is now checked that the data accord to the fact flag "business unit layer" and the table "GESUBR". The selection for the business units is limited to the permitted values.
If for an account there was no account balance but detailed data (inter company balances, fixed asset transactions etc.) that balanced to zero, then a note which had to be confirmed was output in the corresponding list application. This note is now omitted since the constellation is correct.
Account balances, controlling balances and postings on accounts for statistical quanitities (balance sheet/p&l flag '5') are shown in the respective lists without a currency flag.
The account flags displayed per line receive an account-related status representation concerning the coherence of the according details. Prerequisite is the unique entry of company and business unit. <Red> background colour of a flag designates missing or differing details, however <green> point out complete details. Without a colour flags are shown which aren't required (in accordance with switch position of fact and period) or don't have any balance value. The branch into the corresponding detail list already was possibel by mouse double-click on the cell before.
The list application <account balances> (KTOSAL) now allowa a branch to >fixed asset transactions> (ANLBEW) for accounts with the account flag 'D' (depreciation accounts). Then all fixed asset transactions are displayed for the transaction development column '13' (current depreciation) there. This way a check of the accordance is possible between fixed asset transactions of current depreciation and p&l account balances for depreciations.
There is an analogue function for accounts with the account flags 'Y' and 'Z' related to provision transactions (RUEBEW) for the transaction development columns '03' (resolution) and '04' (supply).
The list <account balances> usually displays a sum block with the sum of the assets, liabilities, yields and charges of the displayed balances, at the end of the table (per company/business unit). The balance on the net income/loss of the year account isn't contained in it since it is the result at complete selection of the difference between assets and liability items or yields and charges. Divergent to this only a total line is output, incl. the balance of the net income/loss of the year account, in future when the display is reduced on capital accounts (account flag 2 = 'K', 'L' or 'K and L'). The complete capital more simply can be determined now with that.
The size of amount values in IDL Konsis is limited to 13 digits in front of the comma because of the database definition. Even if this limit is adhered by the account balances and the resulting annual surplus, it can occur that one of the calculation sums for assets, liabilities, yields or charges has more than 13 digits in front of the comma. Since these are onla calculated amounts it was allowed that these may be larger up to 15 digits in front of the comma. A wrong calculation of the annual surplus resulted till now in this case.
The selection for position number is superfluous if the account code is provided uniquely. The list <account balances> (KTOSAL) therefore submits the item number no longer as parameter to the subsequent applications for detailed data.
Inter company account balances on accounts with account flags 1 = 'J' now are validated, too. The sum of inter company balances on this account mustn't be larger than the corresponding account balance.
The sorting of the data isn't performed due to posting key now any more but rather due to the assigned transaction development column (report result value). The transaction development column correspondingly is shown and also translated in front of the posting key.
The action menus of the transaction list applications <fixed asset transactions> (ANLBEW), <share holding transactions> (GESGES), <capital transactions> (KAPBEW) <provisions transactions > (RUEBEW), and <individual development transactions> (SPIBEW) were standardized with regard to the available actions.
The description columns of the list <fixed asset transactions> (ANLBEW) were comprehensed. The name of the fixed asset object account is displayed only once in the total line. The description of the transaction development column is dropped as a separate column and is output in the common description column where the name of the fixed asset object account stood till now.
When copying and entering fixed asset transactions on the standard fixed asset objects per account (key = Prefix+ account code) for the company financial statements it is no more necessary now that the fixed asset object was defined before. A fixed asset object is generated due to the rules of the function <Create fixed asset objects p/acc.no> of the <Company financial statements monitor> (EA).
The action <Check grp.transact./consolid.post.> is no longer available for individual transaction developments (SPIBEW) since for individual transaction developments no group transactions at all are held. The information also for the transaction development reports always is taken from the consolidation postings.
The column "posting key flag 1" is no longer displayed in the list <individual development transactions> since it is always empty for individual transaction developments.
Automatically generated transaction development transactions can be deleted with special authorization. E.g. this is necessary then if the account flag 2 of an account was changed afterwards.
The table for vouchers (BEL) (analoguely the consolidation vouchers) was extended by an attribute "LT status" which can be displayed in the list application and be changed via action <Edit data> as well as <mass-update>. The only valid value (unless empty) is 'X'. Setting 'X' is only allowed for vouchers affecting net income. The LT status in the voucher is also put on all postings on p&l accounts contained. The LT status of the postings is also removed at remove of the LT status of the voucher.
The LT status of the postings (BUCH) also can accept the value 'X' now, supposed the LT status of the voucher is set to 'X'. Based on this the Calculation of deferred taxes in the company financial statements is performed.
A total line is displayed in the list <voucher> (BEL) with the sum of values affecting net income of all selected vouchers now. The sum of the amounts affecting net income of all displayed postings in the list <postings> (BUCH) is displayed independent from the sorting option.
A mouse double-click in one of the columns "E" (posting affecting net income), "Affecting net income", "Mes#" (message number) and "short word" (short text of the message) int the list <Vouchers> (BEL) leads directly into the list <postings> (BUCH) for the corresponding voucher. Till now a call of the single record application <Voucher> (BELE) was carried out at mouse double-click.
In the list <Postings> (BUCH) analogue the balance lists an entry field for the language was inserted. At entry the descriptions (e.g. account description) in the table are displayed in this language with priority. A display in the language of the user or another language is only performed when no description was established in this language.
At the display of the <Postings> (BUCH) with sorting according to vouchers a subtotal is calculated per posting record number and displayed in a separate line now.
The entry of a controlling object is allowed now for postings on accounts for statistical quantities (balance sheets/p&l flag '5'), too. The entry of a controlling object is obligatory in postings on p&l accounts, if the flag for controlling balances of the fact is '1' (complete p&l). This also applies to the form entry and the import.
The message numbers listed in the <Processing> records (VERARB) yield a background colour according to their message type analogue to the <company financial statements monitor> (EA): error messages <red>, warning messages <yellow>, information messages <white>, without message <green>.
In the forms entry applications the authorization control was switched more restricted. The input of data is only possible when the authorization for update or insert is given. This also applies to the integrated entry of voucher heads in the form entry for postings. The authorization check was performed only at <Save> till now.
The forms entry of account balances (I-KTOSAL) was adapted to the column standard of the report result display. The description is in the fixed area now in front of the key. Position and account lines are displayed in tree structure with plus/minus buttons to open and close nodes for the display of account lines. Thus a balance list can be displayed and printed also in shortened form on position level without a report having to be created.
The account flags displayed per line receive an account-related status representation concerning the coherence of the according details. Prerequisite is the unique entry of company and business unit. <Red> background colour of a flag designates missing or differing details, however <green> point out complete details. Without a colour flags are shown which aren't required (in accordance with switch position of fact and period) or don't have any balance value. The branch into the corresponding detail list already was possibel by mouse double-click on the cell before.
In the forms and complete entry of account balances an inter company allocated to the account is displayed behind the account flags now, too.
A new entry field was completed for a "column option" in the key area. There are the following input possibilities:
The new application <forms IC-account balances> provides a simplified entry of inter company account balances. The application can be invoked directly by short word (I-ICKTOSAL) or out of the menu tree. Like the forms entry of account balances, the keys company and business unit have to be provided uniquely.
Per inter company account for which there are account balances all already entered inter company account balances are displayed. For these the data can be changed. In addition for each account there is an empty input line in which new data records can be entered as well as a total line in which the sum of all entered values as well as the control value of the corresponding account balance are displayed. The control value is given also in the empty input line and can be used as entry value if there is only an inter company balance to an account balance.
Direct input possibilities exist for inter company, ic business unit and value in local currency. Analogue to account balances (I-KTOSAL) there is no input possibility for the debit/credit flag. This is rather assumed as default value in accordance with the b/s/p&l flag of the account. Divergent debit/credit flags can be obtained by the input of negative values.
An additional dialog opens at mouse double-click in the column <additional data> and allows the entry of a remark text, a controlling object, or the value in transaction currency with the accompanying currency flag.
In other respects the operation of this application corresponds to the operation of other forms data entry applications.
There is a new forms entry application for consolidation postings. It works analoguely to the forms entry application for postings (I-BUCH):
The application can be invoked by the short word I-KONBUCH or by the menu tree in the branch <forms data entry>. In addition, it can be invoked as a subsequent application from the application <consolidation postings> (KONBUCH).
The columns for the message number and its short text have been dropped. The message numbers can be viewed in the list <processings> (VERARB) and are visualized by a colour representation in the <Company financial statements monitor> (EA), if required.
Since the entry of period and fact is not necessary e.g. for the import of master data, these are no more required entry fields. However, they are needed for company statements data and therefore are preallocated furthermore.
At the call of the subsequent applications for transaction lists (fixed assets, capital, provisions) the parameter "group/subgroup" is preallocated with '*', so that only the company financial statements transactions are displayed only in future. On the one hand, only these data are also imported in general, on the other hand, the group transactions will anyway be taken off by the consolidation postings over the medium term and therefore be dropped.
The separate calling application for the import of metadata IARIMP (in the menu branch <System administration>) was adapted to IMPORT. An entry field for the language of the import of master data with multilingual descriptions (see below) was supplemented.
Several import applications were revised so that they can work in two different modes now. The conventional mode "BATCH" is used for the normal call from the application IMPORT or from a process automaton. The new mode "ONLINE" supports the so-called direct import by a divergent way of the error return. The mode "ONLINE" is used by the applications for the forms entry, at the direct import from the Connector, and at the direct import from the SAP interface.
There is a new application for the import of data of the new table "GESUBR". You find it in IMPORT after opening up the branch <Import master data>. The format description for the standard TXT format is shown to you in the application <Allocations import/export fields to format> (IEFFEL) to the keys "GESUBR" and "#TXT".
There is a new application for the import of posting keys (BSL), particularly for posting keys to individual transaction developments. E.g. this application can be used to take data from a test database into the production database. You find this application in IMPORT after opening up the branch <master data>. The format description for the standard TXT format is shown to you in the application <Allocations import/export fields to format> (IEFFEL) to the keys "BSL" and "#TXT".
A further new application provides for the import of account groups (KTOGRP), that provide for default values of the b/s/p&l flag at the import of accounts. You also find this application in IMPORT after opening up the branch <Import master data>. The format description for the standard TXT format is shown to you in the application <Allocations import/export fields to format> (IEFFEL) to the keys "KTOGRP" and "#TXT".
The format for the company import was extended by the new attribute "e-mail address".
The format for the fixed asset object import was extended by the new attribute "controlling object for depreciations".
For the import of positions and report column names the import application TXTAGG got partitioned analoguely the dialog applications (POS and SPA) in two import applications: TXTPOS for the import of positions, TXTSPA for the import of report column desriptions. The default file name KPAGGXXX was kept for TXTPOS for the purpose of compatibility to existing interfaces. On the other hand, the default file name is KPSPAXXX at TXTSPA.
A new import application (TXTFED) for the import of formula lines for report columns and ratios, that till now could be maintained only by the dialog application <formula editor> (FED). You find this application in import IMPORT after opening up the branch <master data>. The format description for the standard TXT format is shown to you in the application <Allocations import/export fields to format> (IEFFEL) to the keys "FED" and "#TXT".
The language key is now an optional field in import applications for master data with multilingual names (e.g. accounts, positions, controlling objects). If the language is missing in the import record, the language entered in the call application IMPORT is used as a key. If no language is entered there either, the user language adjusted in the startup-data (VOR) is used.
When importing company statements it is checked now that the rules given by the fact flag "business unit layer" and the new table "GESUBR" are observed. Furthermore a default value of the business unit is supplemented if in accordance with "GESUBR" only one business unit is allowed for the company. This spares to enter this business unit at the recording.
At the import of fixed asset transactions on the standard fixed asset objects per account (key = Prefix + account code) it is no longer necessary now that the fixed asset object was defined before. A fixed asset object per account is rather created in accordance with the conventions of the function <Create fixed asset objects p/acc.no> of the company financial statements monitor (EA).
At the import of transactions, postings and consolidation postings a conversion of the posting key is possible now. With the key of a transformation group which has to be provided at the import in the IMPORT map you have to define a transformation table from external posting keys into the IDL Konsis posting keys in the application <Transformation group allocations> to this. This is particularly helpful at the take-over of transaction data from foreign systems.
The transformation of the company and the business unit in several import applications was completed.
At the import of transactions (fixed assets, capital, provisions) no more advice is given due to data with debit/credit flag differing from the standard debit/credit flag of the posting key. The analogue message had been dropped in the dialog already some time ago.
A new import application provides the import of Import format descriptions. Complete format descriptions are always inserted and deleted before if necessary. An update isn't scheduled. In connection with the export function of IEFFEL so e.g. format descriptions can be transferred from a test to the productive database.
The list application <Allocations import/export fields to formats> (IEFFEL) was revised as follows:
Besides the format type 'TXT' (fix column structure or column separation by special characters) now the support of format type 'XML' at the import is prepared, too. To this on the one hand an IDL standard XML format ('#XML') was defined for several data stocks, on the other hand files can be processed in strange XML formats. The table <Import/export format Ident> was extended by an attribute "XML-Prefix" to this. Based on the current release a XML interface shall get prototyped for the take-over of data from the Coda the accounting system.
At the fact carry forward, in future only processing records become created for the business units, that are authorized in accordance with the new table "GESUBR". Till now processing records were created for all defined business units. Such superfluous records are deleted by the release-conversion programme.
Till now, the entry of an aggregation account wasn't allowed for fixed asset accounts since no naming of an assigned aggregation fixed asset object was possible. This is possible in future and is supported in the fact carry forward in the way that the default fixed asset object for the target account (Prefix+ account code) is always used like it is created also in the application <Create fixed asset objects p/acc.no> of the company financial statements monitor (EA). If this doesn't exist yet, it is created automatically.
The new table "GESUBR" was supplemented in the period carry forward per company. A maintenance of this table is therefore only necessary at changes to the pre-period.
The new posting type 'WX' (see below ) can also be allocated for vouchers of the company financial statements. Also here p&l postings on these vouchers are reposted to the account for retained earnings, the reversing entries is done on the original p&l account.
If for an individual transaction development instead of the standard carry forward posting key (with usage flag 'V ') a posting key with use flags 'M' is defined, transactions for this transaction development (to the support Currency conversion at weighted monthly average rates) carry forward is performed according to the following rules:
The entries of a controlling object remained unchanged at transcoding to another account till now. This detail is dropped in future if the target account (e.g. account for retained eranings) is a balance sheet account and therefore needs no controlling details leads.
Postings affecting net income resulting from debt consolidation (SK vouchers) or the elimination of current assets results (ZU voucher) are carried forward in a special way: The p&l posting is reposted to the account for retained earnings, the reversing entry is posted on the original p&l account. To be able to use this posting rule also for other (manual) consolidation postings, the new posting kind of 'WX' which can be allocated for MB vouchers was introduced. For the purpose of a uniform representation SK and ZU vouchers also get the posting kind of 'WX'.
VS and VZ vouchers, till now, weren't further carried forward since a posting pair eliminating each other (retained earnings to retained earnings) would be the result. Since the group capital transaction was, however, carried forward for the posting on the account for retained earnings, a discrepancy between group transactions and consolidation postings was produced. This problem is now solved by carrying forward VZ- and VS-vouchers once resulting in two postings on the account for retained earnings and corresponding group capital transactions.
Differences are only expelled in detail in local currency in the protocol for the <Check carry-forward account balanc.> now. Differences in group or parallel currency are only reported flatly. Values in currencies without fractional digits are represented correctly now.
The calculation of deferred taxes in the company financial statements is possible without entry of a tax fact now, too. Deferred taxes are then charged for the postings which are marked on the same fact by the LT status 'X' and written as postings on the same fact. The calculation is made in the application <Deferred taxes headerf> (LTK) by the action <Deferred taxes (LT)>.
In the application <Deferred taxes headers> (LTK) there is a new action <Marks voucher LT>. This action leads to the list <Vouchers > with selection of postings affecting net income in which the new attribute "LT status" then can be set or reset.
The application <Create postings> (GENBUCH) for the generation of postings out of the difference between tax balance sheet and current company financial statements for the calculation of deferred taxes beed adapteded so that it is executable in the process automaton. The fact of the tax balance sheet has to be entered in the parameter for the comparison fact to this.
In the single record application <Currency conversion header G/PCurr> (WUME) the group/sub group as an entry field has been dropped. It was only used to check the agreement of the used currencies with the details for the group/sub group. Group/sub group entered in the list <Currency conversion GCurr + PCurr> (WUM) is used for this check now.
The action <Mass-update> is available again in the list "account currency conversion rules" now. Group and parallel currency conversion rules can be changed independently by each other.
The conversion rule 'FDK' (Sliding average currency rate) can be entered now for all accounts with transaction details (due to account flag 2).
An input of the conversion rule for the parallel currency was only possible till now if a conversion rule was also entered for the group currency. The parallel currency conversion rule can be entered also without group currency conversion rule now.
The new conversion rule 'MDK' (monthly average course) can be assigned to a posting key besides 'SK' (closing rate) and 'PDK' (currency rate average per period) now, too. This is required for conversion at weighted monthly average rates.
The new conversion rule 'MDK' (for conversion at weighted monthly average rates) is supported for individual development transactions. The conversion is then carried out at the currency rate given for the current period with the time reference 'MDK'.
Capital transactions with the posting keys '04' or '15' (setting net income/loss of the previous year) are converted with the closing rate (SK) of the previous period since release 5.4.0. In future, you can control also for these transactions by the table <posting key currency conversion rules>, whether the conversion shall be carried out at the closing rate or at the currency rate average per period (PDK). In any case, however, the exchange rate of the previous period is used.
The month end of the current period is adjusted as a transaction date in the generated transactions (fixed assets, capital etc.) in extra transactions for clearing of differences to the account balance in future. This was the first of the month till now.
In the generated postings for the clearing of differences between debit and credit in group or parallel currency on one of the difference accounts indicated in the currency conversion header the posting key for conversion differences ('01') now is entered, if it is an capital account.
If data with business units are converted, then a created difference transaction is provided with an inter company business unit for the share holding now, too. The first business unit which is found in the converted data as an inter company business unit is used.
If the parallel currency conversion is omitted by setting the currency code equal to the currency code of the group currency, all parallel currency values of the converted data are put on zero now.
The control of the currency conversion via the table <Posting key conversion rules> (BSLUAW) is working for the currency conversion in the group now, too.
The entry of the conversion rules into consolidation postings represents an initial setting (e.g. 'VPW' for postings carried forward) as well as a unite proof of the exchange rate used for the conversion. This had the consequence for consolidation postings without a predefined currency conversion rule that the rule used at the first currency conversion (in accordance with conversion of the company financial statements) also was used at following conversions even if the preconditions (for the company financial statements) had been changed in the meantime. To avoid this effect, only the value 'VPW' is taken into account at the currency conversion of the consolidation postings in future. On the other hand, the values 'SK' or 'PDK' are ignored so that the currency conversion of the company financial statements or a control by the table BSLUAW gets effective also at repeated conversion.
The group currency conversion performs an automatic comparison between the p&l postings on depreciation accounts (account flag 'D') and fixed asset postings for the transaction development column '13' (current depreciation) now, analoguely to the currency conversion for company financial statements. It is made sure that both data stocks are converted with the same rule ('SK' or 'PDK') so that only rounding differences can arise also in parallel currency. There also is an analogue control for p&l accounts with the account flags 'Y' and 'Z' related to postings on provision accounts for the transaction development columns '03' (reverse) or '04' (provision).
Consolidation postings for compensation of differences on p&l accounts are provided with a controlling object (presupposed a corresponding control via the flags of the period and the fact) now. To this the first controlling object which occurs in the same posting record is used.
In the application <Account currency conv. audit trail> (KTOUMR) the difference to the pre-period is expelled now even if there is no account balance in the current period because it would be zero.
In the consolidation parameter for deferred taxes (KTKPARLT) accounts are also allowed for individual transaction developments ('S0' - 'S9') for all account inputs. For accounts for transaction developments without posting key with the usage flag 'L' or with a posting key with usage flag 'SL' a warning is output, because later postings on these accounts don't contain any posting keys and must be updated afterwards.
The subsequent applications <Consolidation vouchers> and <Consolidation postings> are now available only as a local (line related) action, i.e. related to the company marked. The previous global calls led to long response times because of the perhaps very large amount of data from.
Several functions which must be performed following the real consolidation were comprehensed in a new Submenu <Final functions> in the action menu. Here you find now
In the single record application <Group/Sub-group consolidated Co.> (KTKGESE) the entry field "net inclusion of the fixed assets" is displayed one line up now close to the access date to clarify the relevant join with the access to the group companies.
A condition for setting of the status 'T' for the capital consolidation processings till now was that all parent companies of this company (see KGESGES) with consolidation method not equal to 'K' (no consolidation) in the group (see KTKGES), also are contained in the subordinate sub group with a consolidation method not equal to 'K'. In addition in future it is checked whether these parent companies are available in the sub group with an investment book value greater than 0.
In most consolidation functions in postings on accounts for individual transaction developments the posting key for current changes (usage flag = 'L') is supplemented in the record now provided that there is no eliminating posting key (usage flag = 'SL'). All other postings for which no posting key can be found out are created without posting keys. An indication is distributed, though, that the posting key must be suuplemented afterwards.
The debts and profit/loss consolidation (SK/AE) for quoted companies weren't correct till now if the quota only applied to a sub group. In future, this case is treated analoguely to other consolidation functions as follows:
At the check of the status for SK/AE consolidation some gaps were closed so that the status display in the lists <Group companies + monitor> (KTKGES) and <IC-clearing list> (KGESGES) is always correct after updating the >Consolidation postings< (KONBUCH), too.
For the purpose of the uniform representation SK vouchers always get the new posting kind of 'WX' now (see above).
If for a SK or AE voucher a calculated difference was credited on the interim account so that the voucher had debit/credit equality, then this in no more diaplayed as an error <(red)>, but only as a warning <(yellow)>.
The <repostings after elimination of intercompany accounts> (SU) didn't contain any special treatment for quoted companies till now. Although only the quoted amount booked at the debt consolidation was eliminated, the complete company financial statements transactions were booked. In future the quoted amount only from the transactions of the company financial statements are booked here, too.
The <repostings after elimination of intercompany accounts> (SU) considers accounts now, which weren't processed in the debt consolidation (SK), because of no inter company balances in the current period, but yielded inter company balances in the previous period, so that transactions exist (carry forward and current change) that sum up to zero.
The <repostings after elimination of intercompany accounts> (SU) now processes only transaction developments which are designated by the flags for the current period and fact.
If the capital is defined by capital transactions in the company financial statements, the capital first consolidation (KE) evaluates these data so that the postings eliminate the company financial statements also suitably for columns for the capital report. The same is valid for the action <Pre-calculation of shared capital> at the manual first consolidation (KM). The from calculation of minority interests (KA) was already performed on this basis.
This change requires a new layout of the manual capital consolidation (KONKTO). Till now, one line was displayed per capital account. Now if necessary several lines are to be displayed for one account if there are postings to this with different posting keys. In the single record application (UBMAN) the posting key becomes a new obligatory entry field. <Update> and <Insert> are distinguished now. At <Update> the posting key of a posting can be changed, at <Insert> a second posting line is created with another posting key.
The <repostings after change of the company group> (KU voucher) contains no longer postings on capital accounts now since the capital accounts are already eliminated completely and suitably for columns by the first consolidation at maintenance of capital transactions.
In the single record application "UBMAN" for manual capital first consolidation (KM), in addition, an input possibility for a posting text was supplemented. This posting text is taken into the generated consolidation posting on the capital account.
At investment book value = 0 in the share holdings (GESGES) a consolidation posting with zero value is created at the associated company now. A consolidation posting otherwise is missing for the parent company for the determination of business units for segment reporting.
The input of a previous period is now allowed settle in the list application <Compensation diff.fr.first consol.> (VUB). Then the VUB data are shown for all periods of the given interval so that the development of the capital consolidation can be seen for a subsidiary.
The single record application for the settling of the difference as goodwill (BUCHSATZ02) allows the entry of a new fixed asset object which then is created if necessary too now. E.g. this is helpful if a fixed asset object of one's own is needed at capital consolidation with business units per business unit with different depreciation rules.
From the single record processings for the compensation of the difference from first consolidation (BUCHSATZ02 -- BUCHSATZ08) a branch is possible into the list <fixed asset objects> for maintenance of the attributes of the used fixed asset object now, too.
For facts with the accounting type of 'I' (IFRS) this the application is proposing a fixed asset object for goodwill without depreciation (depreciation type = 'K') now since this is in accordance with IFRS standard.
Deconsolidation of capital eliminates an existing EF voucher (update equity) analoguely to the KF voucher at the Deconsolidation (KS) of an Equity company now.
At the compensation of the difference from first consolidation for companies at equity as goodwill, hidden reserves or other fixed assets it is now distinguished between real new entries and setting of historical participations. The postings on the fixed asset account are adjusted as either an entry (posting key '41') or as setting carry forward (posting key '62'). This distinction is necessary for a correct cash flow report.
For companies with 100% minority interests it is now distinguished whether 100% of the capital are to be booked as minority interests or not. If a share holding record of (application GESGES) with zero values exists, the KA status is set to <red> at the calculation of participations and layers so that the calculation of minority interest is performed. Without share holding record the KA status remains <empty> and no minority interests calculation is performed.
Minority interest postings in subordinate sub groups are cancelled and calculated newly at the superordinate group level. If e.g. a difference is compensated as goodwill in the subordinate sub group, then the fixed asset object is assigned to only the subordinate sub group. A problem arises in the context of the cancellation in the superior group. Till now, the value of the fixed asset object therefore remained empty in the superordinate group level resulting in an incomplete fixed asset transaction development. In future, the fixed asset object is nevertheless typed in. This has the consequence, that the fixed asset transaction development is not correct in the subordinate sub group, because the fixed asset transaction from the superior group is included, however, this can be avoided by setting that the flag "ex KONBUCH" for the current period (application ABR) so that the group transaction development reports are created based on the consolidation postings. The allocation of a fixed asset object to a group level then plays no more role.
At the group carry forward, till now, the currency rate effects for minority interests on the direct and indirect annual surplus that were booked on an account for currency differences in the pre-period were rebooked to the account for compensation of minority interests (KTKPARKK). When booking minority interests all of the exchange rate effects (difference between closing rate and historical value) for the from outside quotas on the direct and indirect annual surplus in the current period were newly calculated and booked on the account for currenca conversion effects. In future these exchange rate effects are no longer rebooked at the group carry forward and at caldulation of minority interests these effects are eliminated.
The elimination of fixed asset results (ZA) is now available in the option <delete+...>, too, so that it can be repeated arbitrarily.
During the processing the validity of the fixed asset objects involved is checked now. If the fixed asset objects are no longer valid in the current period, no more postings are created either. This way the ZA facts can be limited from the point of view of time.
The elimination of current assets results also considers quoted enterprises now. The quoted amount of the intermediate profit is only eliminated now.
For the purpose of uniform representation ZU vouchers always get the posting kind of 'WX' now (see above).
The application for the calculation of quoted compensation values (QU) was enhanced, that also rounding differences of controlling balances are compensated (prerequisite: Control of the controllingbalances in the fact (FAC) with flag = '1'). A controllingbalance which eliminates the difference between quoted net income/loss of the year and the sum of the quoted controlling balances is created on the accounts and controlling objects of the consolidation parameter QU. This controllingbalance can be assigned to a position in the report so that also reports based on the controlling balances (turnover cost proceedings via report option 'C') can be created without difference for quoted companies.
With release 5.4.0 generated transaction developments had been introduced for the purpose of cash flow reporting (with posting keys with usage flags 'V' and 'L', if necessary also 'SV' and 'SL') with automatic maintenance. The automatic maintenance was carried out only in the company financial statements till now, however.
A new function now provides a correct partitioning between carry forward and current changes also on group level. For this purpose all consolidation postings of the previous period are added up per account and company to a desired carry forward value. On the other hand the actual postings with carry forward posting key are also added. The difference from this is booked as a remaining carry forward. The reverse posting is booked on the same account with the posting key for current changes. So it is a pure transaction development transfer.
These posting couples are combined in a voucher with the new consolidation processing 'FU'. Per group/sub group there is only one voucher. The voucher number contains analoguely the JU voucher only a company number, that one of the parent company of the group.
The function <Reposting of automatic generated transaction developments (FU)> is called as subsequent application of the list <Group companies + monitor> (KTKGES), where the action is contained in the new submenu <Final functions>.
The application <Compensation for the result of the group companies (JU)> is interrupting with an error message now if no consolidation parameter JU is defined. The status then isn't set to >green< any more either.
A total line was supplemented in the list <Consolidation vouchers> (KONBEL) displaying the sum of the postings affecting net income of all selected consolidation vouchers now. The sum of the postings affecting net income of all displayed postings is displayed list <Consolidation postings> (KONBUCH) independent from the sorting option.
In the list application <Consolidation vouchers> (KONBEL) mouse-double-click in one of the columns "E" (flag for a voucher affecting net income), "Affecting net income", "Mes#" (message number), and "short name" (short text of the message) directly branches into the list <Consolidation postings> (KONBUCH) for the respective voucher. Mouse-double-click into the column "D" (status for deferred taxes) is branching to consolidation postings analoguely to the action <consolidation postings LT >. Mouse-double-click into the column "MI" (status for minority interests) corresponds to the action <consolidation postings for KA>. A call of the single record application <consolidation voucher> (KONBELE) always was performed at mouse-double-click till now.
In the list <Consolidation postings> (KONBUCH) analogue the balance lists an entry field for the language was supplemented. At entry the descriptions (e.g. account description) displayed in the table are displayed with priority in this language. A display with the language of the user or another language is only carried out when no description exisits in this language.
In the list <Consolidation postings> (KONBUCH) the columns for the posting record number and the posting key now are shown further ehead so that they are visible without scrolling: the posting record number in front of the account description, the posting key after the debit and credit values in group currency.
At the display of the <Consolidation postings> (KONBUCH) with sorting according to vouchers numbers a subtotal is calculated per posting record and displayed in a separate line now.
The entry of a controlling object is allowed now for consolidation postings on accounts for statistical quantities (b/s/p&l flag '5'), too.
At the insert or update of a consolidation posting on an account for an automatically generated transaction development (e.g. for cash flow reporting) the posting key is with usage flags 'L' now is adjusted automatically if otherwise there is no entry.
It also is checked at the validation of the consolidation vouchers now whether the entry of posting keys is complete in the consolidation postings for individual transaction developments.
The table for report headers was extended by an attribute for a second comparisons fact. This allows reports with the comparison of three facts.
At the mass-update in the applications <company reports> (REP) and <group reports> (REPK) the comparison period can be deleted by entry of '*' for the highlighted reports now.
Column options without type allocation, (i.e. without display of detail levels like company, business unit, sub group in columns) can be defined with up to 50 columns (till now 20) now. E.g. such a transaction development report can be defined with 20 value columns and further 7 sum columns. The number of value columns within the report result table remains limited on 20 further, though.
The evaluation of the formulae (for column options and ratios) calculated wrong at leading '-' (i.e. '-' in the first formula line of the formula). Instead of negating the first operand, the final result was negated. Attention! Customer individual column options and ratios are delivering perhaps wrong values after the correction of this error if they were adjusted to the faulty formula calculation by 'Trial and error'. The application <formula editor> (FED) should be invoked once and the formulae analysed by visual inspection to this.
The amount of data created at the construction of group reports was reduced by it, that first of all it is checked, whether there are balances or consolidation postings for a company. If this isn't the case, no detail data are created either for these companies. They then don't appear at the representation of the companies in columns either.
In the report for the turnover cost proceedings (UKV) with help of the report option 'C' the controlling object is adjusted as the first detail level except for to position and account. It therefore isn't possible to display this report with companies in columns. There is the new report option 'D' for it now which is only different from the report option 'C' by the fact that the companies are written in detail level 1 so that a display of the companies in columns is possible at a corresponding column option.
At entry of a second comparison fact in the report header record (REP) the report is created for three facts in comparison. The extended column occupancy is documented in the help text for the internal position plan #REP#. You reach this documentation via the help text of the application <formula editor> (FED).
The new table "GESUBR" was Supplemented in the group-wide data exchange. I.e. the maintenance of this table should be performed in the world group.
The extensions at the IDL Connector are documented separately.
A new function constituent serves selecting the GLT3 table of the SAP system from provision transactions. This function constituent, incl. the take-over to IDL Konsis, will be prototyped with the current release.
The language provided in the call application <IMPORT> or the standard language of the user also is used for the logon at the SAP system now so that descriptions (e.g. position texts) are selected also in this language. The SAP system otherwise doesn't take into account the user language but rather uses the default language assigned in the table T011 for a b/s/p&l structure.
For the take-over of cost centres from the SAP system the parameter 3 (business unit) is submitted in addition now. By the entry of <business unit = '*'> you can achieve, that the master data are taken on without the value for the business unit. The corresponding extension of the external call in the menu item UNLKST is made automatically by the release conversion program.
The object names were always provided only in the language which was adjusted in the MIS parameter as Cube language in the MIK-Olap interfaces for the respective dimensions. In future, the names are provided also in the other languages which are specified in the application <MIS languages> (MISSPR).
To the topics
newly revised and cross-application documentations were created (as for the topic "user and entitlements" before). These documentations are in German and English at the disposal and are obtainable in the resource tree by menu items of their own in the respective branches. They aren't contained in the doku directory of the CD as separate pdf documents, however, these 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>) now contains only a reference to this cross-application documentation.
With this release the following English-speaking documentations in the doku directory are updated or completed: