'Transaction development' and the posting keys being connected with that will company-wide forgive and belong to the group of the company-wide data (KONDAT) with that.
This application is used for the definition of transaction developments. The application ' SPI ' can be called by short word or about the menu tree. The already created texts are shown on this overview for transaction development. As long as no texts were entered so far, the display kept empty.
Image: Overview application 'SPI' with already created transaction developments
These data are no longer refreshed automatically by the meta data of the IDL Konsis releases. As an alternative templates for transaction development definitions are provided in the directory "LieferBatch" like already practised in the past for individual supplements to the standard transaction developments or the introduction of individual transaction developments. The user decides, whether he inherits these templates or creates his specific definitions.
Via the accompanying single record application 'transaction development ' (SPIE) these texts can be entered, changed or also deleted. The maintenance is possible in different languages.
Image: single record application 'SPIE'
Explanation of attributes:
[Trans.Dev.] : up to 3 character transaction development key
[Descrip.] : up to 70 character transaction development description
[ColmHeader] : Column header description for transaction development key. By the usage of the character '|' in the text you can control a multi-line table heading for a column.
[Shortname] : up to 10 characters description
[Development transaction flag]: designates the character of a development according to the previous standard developments with 'A' (fixed assets), 'B' (participations), 'K' (capital) or 'R' (provisions). Special processings (e.g. calculation of depreciations, consideration in capital consolidations) are derived from this classification. Thus from now on it is possible to name these transaction developments with different keys. The update of a development from or to flag 'A' to resp. from another type is only admitted, if no transactions exist for this development.
[Type of carry forward]: describes, how transactions and postings of a development are to be carried forward into the next period. It is differentiated by '-' (without carry forward), 'X' (usual carry forward with a carry forward posting key), and 'S' (carry forward in a sample accounting with simultaneous elimination of carry forward in a parallel detail for cash flow reporting). This attribute supports checks at definition of posting keys for a transaction development. It is now possible to define automatic transaction developments without a simultaneous carry forward. This means that automatic transaction developments can be defined for P&L accounts, for example.
[Currency rate average per month]: designates a transaction development, which is especially defined for currency conversion with a currency rate average per month. It can be specified for developments with usual carry forward as well as for developments with sample accounting. This attribute supports checks at definition of posting keys for a transaction development.
[Automatic calculation]: designates a transaction development, which is calculated automatically. The change in the actual period is set to the difference between account balance and carry forward. This attribute can be specified for a development with usual carry forward as well as for a development with sample accounting. It supports checks at definition of posting keys for a transaction development.
The button in the "period/transaction developments" (ABRSPI) table for an automatic transaction development can now be placed on the new value 'M'. This ensures that the automatic comparison between the development transactions and account balances is switched off and must be entered for differences in manual development transactions. This extension supports the ability to automatically offset transaction developments that are to be evaluated for cash flow statements in certain, but not all periods.
[Development areas]: controls, whether transactions and postings of this development are carried forward into distinct areas. Without setting this attribute no development areas may be defined for this development.
[Valid-from and valid-until period]: allow the entry of a space of time, where the transaction development is supported. The migration program initializes the valid-from period while the valid-until period remains empty. Reductions of the validity are automatically inherited by all allocated development columns, development areas and posting keys.
This application has to be understood as a subsequent application. For each transaction development which was defined in application 'SPI' you also have to define the used columns for transaction development 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 (applications 'BSL', 'FED').
Image: Overview application 'SSP' with already defined columns
The accompanying single record application 'transaction development column' (SSPE) contains the column number as a further key next to the key of the transaction development and the language.
Image: Overview application 'SSPE'
Explanation of attributes:
[Trans.Dev.] : Transaction development key for which the columns should be defined
[Dev.Column] : definition of development column number. The column number lies between '01' and '50'.
[Descrip.] : up to 70 character description
[ColmHeader] : a column headline can now also be entered in the single set application for transaction development columns. This is used initially in the overview "Transactions and consolidation postings" (KONBEW).
[Short name] : up to 10 character description
[Usage flag] : defines a dedicated role of the development column providing corresponding checks or processings. The following values are provided here: 'VOR' (column for carry forward; is determined from the definition of automatic carry forward posting keys und determines posting keys for manual carry forward), 'UMB' (column for reposting; provides a check for "total of all accounts is zero"), and 'GUV' (provides automatically a check for consistence between the total transactions for this column and p+l account balances with a dedicated account flag). Thus reposting columns can be defined for arbitrary developments.
The new development column usage tag 'MER' serves for specification of transaction development columns for mergers. These columns are automatically checked for a total of zero for all development transactions and consolidation postings similar to columns for repostings. However this check is not performed for single companies but rather for group financial statements at creation of group transaction development reports, since the disposal by mergers are posted at other companies than the additions.
[Account flag] : is an additional information to the usage flag 'GUV' and defines the account flag ('D', 'Y', 'Z') of those accounts, which have to be adjusted to the transactions of this column. Each account flag may only be allocated to one development. Thus the hitherto checks for current depreciations in the fixed asset development as well as for releases and additions of provisions receive a universal type of definition independent from the setting of column numbers.
[Valid-from and valid-until period] : allow the entry of a space of time, where the development column is supported. The migration program initializes the valid-from period while the valid-until period remains empty. Reductions of the validity are automatically inherited by all allocated posting keys.
The definition of development areas is carried out via the application 'development areas' 'SBE'.
Up to now only the fixed assets transaction development was differentiated in to areas, in this case for acquisition/production costs and for depreciations. An analogue classification now is possible for individual transactions as well as an extension of the areas of the fixed assets transaction development (e.g. for "impairment").
Since a mixture of posting keys with and without development areas makes no sense, an extension of the capital and the provision development is not supported.
This characteristic then can be assigned to the posting keys of the respective development transaction in the application 'posting keys' 'BSL'.
Image: Overview application 'SBEE'
The development area key consist of the development transaction key and a one digit development area key.
Image: Single record application 'SBEE'
Explanation of attributes:
[Trans.Dev.] : Transaction development key for which the development area should be defined
[Devel.Area] : 1 digit development area key
[Description] : up to 70 character description.
[ColmHeader] : a column headline can also be entered in the single set application for transaction development areas. This is of no use at the moment, however.
[Short name] : up to 10 character description
[Depreciation flag] : defines for the automatic calculation of depreciations, which development areas are to be considered for calculation of the production and acquisition costs ('AHK') and which development area is to be used for the calculation of the accumulated and current depreciations ('AFA').
[No Agree] : this flag specifies for development area whether it is to be with agreement to account balances or not ( see point 3.3)
[Consolid] : this flag specifies for development areas without account agreement, whether the according data are to be consolidated or not ( see point 3.3).
[Valid-from and valid-until period] : allow the entry of a space of time, where the development area is supported. The migration program initializes the valid-from period while the valid-until period remains empty. Reductions of the validity are automatically inherited by all allocated posting keys.
Development transaction areas can be used for automatic development transactions as well (with posting keys with use characteristics 'L').
You can define transaction development areas without agreement to account balances. For this purpose you have to set the new flag "Without account agreement" for this development area. Another flag specifies for development areas without account agreement, whether the according data are to be consolidated or not.
Even automatic generated transaction developments for cash flow reporting ("S9") may be enhanced by development areas without account agreement. Of course, the related data have to be manually provided. However, there still may be only one development area with account agreement for these transaction developments.
The specification of a transaction development area as "without account agreement" merely acts upon the posting keys allocated to this development area. Development transactions with these posting keys are not considered in the total to be compared with the account balance. Postings and consolidation postings with these posting keys are not considered at calculation of the totals of debit and credit amounts and the amount affecting net result.
Data with posting keys allocated to transaction development areas without account agreement principally can be carried forward as far as a posting key for automatic carry forward (usage tag 'V') is allocated to this development area, too.
The specification of a transaction development area without account agreement as "to be consolidated" or "not to be consolidated", respectively, affects the consolidation functions (especially the elimination of existing data) and the currency conversion. Data with posting keys allocated to not consolidated development areas are converted like statistical amounts, i.e. by a fixed exchange rate of 1, if not otherwise specified in the posting key conversion rules (BSLUAW), while data with posting keys allocated to a consolidated development area are converted like other data, i.e. e.g. by the closing date exchange rate.
Development transactions with posting keys allocated to development areas without account agreement are not considered in the total to be compared with the account balance. These transactions are not considered at automatic generation of account balances from development transactions, too. However, they contribute to the check sums. The transaction lists (ANLBEW, KAPBEW, RUEBEW, SPIBEW) do not integrate these transactions in the usual order of the table but rather display them in a separate block behind the effective data. Thus the displayed totals can be understood.
Postings with posting keys allocated to development areas without account agreement are not considered in the totals of debit and credit amounts and in the calculation of the amount affecting net result.
The posting keys are valid for the whole affiliated group and belong to enterprise-wide data of 'KONDAT'.
The overview posting key 'BSL' announces the data into tree structure. There are different variants for it which can be selected about the entry field 'Sort and Select Options BSL' 'sortselopt':
Image: Overview 'BSL' with 'SortSelOpt' : A
Image: Overview 'BSL' with 'SortSelOpt' : B
Image: Overview 'BSL' with 'SortSelOpt' : S
Posting keys are usable in all transaction applications. The posting keys display the development of a main account that is shown in a transaction application e.g. carry forward, additions or disposals.
With the mass update the following keys can be changed simultaneously for multiple marked lines: usage tag, development column and area, group for account / posting key allocation 'BSG', debit/credit-codes and valit-until-data.
Image: single record posting key (BSLE)
explanation of attributes
[Trans.devel.] : Selection of transaction development for which the posting key should be created.
[PostingKey] : 3 digit arbitrary posting key. The posting-key is not numerically, that means for example the posting-key '01' and '001' are different.
[Descript] : up to 70 character description.
[ColHeader.] : Column header for the application 'posting key'. By the usage of the character '|' in the text you can control a multi-line table heading for a column.
[Short name] : up to 10 character description
[D/C-codes] : The D/C characteristic is used for the identification of a positive or negative valency. E.g. the standard debit-/ credit characteristic of the posting key is taken at bookings as standard characteristics if no characteristic was included by the user at the recording/amendment of the booking.
[DevelArea:] : Provided that transaction development areas are defined in application 'SSP', you can assign the areas that appear in the selection.
[Dev.Column:] : you can assign the columns that appear in the selection.
[Usage tag] : The usage tag is set when a certain posting key shall be used for a certain processing. For detailed information please have look into GUIDE BSL-Usagetag ).
[RefPoKey] : This field is only be used for participations. As reference group posting keys for participations fixed asset posting keys are deposited which then are used for the postings at the capital consolidation on the participation account.
[Seq.PosKey] : This attribute of the table posting key is the "column order for the form recording". An entry in this attribute results in a value being able to be entered in the form recording for fixed asset transaction to this posting key. As of the next release this also applies to the planned form recordings for other transaction development transactions. This attribute works also for the recording forms of the IDL Connector. The numeric value determines the order of the entry fields.
[groupAccAl] : allow the entry of a group for account / posting key allocation.
[Valid-from and valid-until period] : allow the entry of a space of time, where the posting key is supported. The migration program initializes the valid-from period while the valid-until period remains empty.
You can define "groups for account / posting key allocation" in a new table. The application can be called by short word or about the menu tree. The already created texts are shown on this overview for groups for account / posting key allocation:
Image: Overview application groups for account / posting key allocation 'BSG'
Such a group is a classification providing restrictions for the allocation of posting keys and accounts in reported data. A typical application case is the usage of separate accounts for value adjustment in the fixed assets. Then generally only transactions of the area of acquisition and production costs should be entered for the fixed asset account, while only transactions of the area of depreciations should be entered for the account for value adjustment. In this case you have to define two groups for account / posting key allocation.
The single record application (BSGE) serves for the definition of the allocation group itself:
Image : single record application (BSGE)
The key of each group is composed out of the transaction development and the actual group key with a maximum of three digits. You can define descriptions in several languages for this key. In addition a validity range has to be specified, especially the beginning of its effect.
For activation of this functionality an allocation group has to be assigned to the respective accounts as well as to the respective posting keys. Both tables were enhanced by a corresponding attribute, which can be supplied by the respective dialogue and import applications. Of course, the allocation group has to be convenient to the development of the account or the development of the posting key, respectively. The dialogue applications support a mass update.
The following check was supplemented in all applications for maintenance of reported data with posting key entry (development transactions, postings, consolidation postings): If the account as well as the posting key is allocated to an allocation group, then they have to agree. However, if one of both objects is not supplied with an allocation group, then the combination is allowed. The same check is performed for the entries for the consolidation parameters, too.
There is an additional condition for accounts: data transferred from the company chart of accounts to the group chart of accounts have to stay valid. Therefore the assignment of an allocation group to a group account is automatically inherited by all allocated company accounts. However, in the other way it is allowed, that a company account assigned to an allocation group is allocated to a group account without allocation group. Then the restriction is only valid in the company chart of accounts. After the effort of the first-time arrangement only new group accounts have to be provided with an allocation group.