Skip to main content
insightsoftware Documentation insightsoftware Documentation
{%article.title%}
Published:
Was this article helpful?
0 out of 0 found this helpful

Transaction Development Definitions

1 Transaction Development (TRNDEVDFN)

The application is used for the creation and care of transaction developments. You can open it via the short word TRNDEVDFN or via the resource tree in the master and control data.

When the application is launched, a table appears with the defined transaction developments and their attributes.

1.1 Setting Up Transaction Developments

Create a new transaction development using the asterisk icon in the top menu bar or the menu bar at the top right. This opens a wizard consisting of three pages. Green check marks or red stop signs indicate whether the page is filled correctly. If certain key fields have not been filled correctly, you cannot switch to another page. Clicking 'Finish' is equivalent to 'Save'. A corresponding entry of the 'last modification' takes place only after a refresh.

The three pages of the wizard are:

Page 1 Description:

  • Transaction development: Input of the three-digit, alphanumeric key, detectable only during creation and copying. The entries are automatically converted from lowercase to uppercase. Immediately prevents the entry of illegal special characters ('%', '_', single '*').
  • Validity from/until: The validity period of the transaction development is defined here.
  • Description: An individual description must be entered (max. 70 digits).
  • Column header: An individual description must be entered (max. 70 digits). Multiline input is supported for the column header. This is the headline for the transaction development's status line in the CFSMNR monitor.
  • Short text: Optionally, an individual description can be entered (max. 10 digits).

Figure: Page 1 of Change transaction development wizard

Page 2 Properties:

This page provides input for the table-specific attributes by selecting a transaction development type. The transaction development type "B" can only be selected for transaction development "B" and therefore cannot be used for any next transaction development.

Figure: Page 2 of Change transaction development wizard

Page 3 Descriptions (multi language:

This page allows you to maintain your descriptions in all enabled languages, as in other root applications.

Figure: Page 3 of Change transaction development wizard

1.2 Opening Subsequent Applications

When you double-click on a row of the transaction development table or select the eye icon in the context menu, four tabs appear, in which the associated data for transaction development areas, transaction development columns, posting key groupings, and posting keys are displayed.

2 Maintaining Subsequent Applications

When you select a row and click the pencil icon, or double-click a row in these tables, or click the asterisk icon to open a wizard to edit or entry the data:

2.1 Transaction Development Areas tab

Differentiation within a transaction development is affected by the provision of transaction development areas.

The first page of the transaction development area wizard contains the same dialog as the transaction development configuration. This is where the validity and the descriptions are maintained.

On the second page of the wizard, the transaction development area attributes are maintained:

Figure: Page 2 of Change transaction development area wizard

Other options

  • Balance relevant: The account balance results from the balance-relevant transaction development areas.
  • Without account agreement: The marking of a transaction development area ‘without account agreement' has a particular effect on the posting keys assigned to that transaction development area. Development transactions with these posting keys are not included in the total to be compared with the account balance. Postings and consolidation postings with these posting keys are not included in the sum of debit and credit values and in the calculation of the result effectiveness. Therefore, it is not possible to activate the options "balance relevant" and "without trial" in a transaction development area. Development transactions with posting keys that are assigned to unsampled transaction development areas are not included in the totals for reconciliation with the account balance. They are also not taken into account when generating account balances from the sum of the development transactions. But they flow into the control values. In the transaction overviews (FATRN, CAPTRN, PRVTRN, DEVTRN) these transactions are not sorted into the table in the usual order, but in a separate block behind the effective data, so that the displayed totals can be traced. Postings with posting keys that are assigned to untested transaction development areas are not included in the debit and credit totals, nor are they included in the calculation of the result effectiveness per posting record.
  • Consolidation: This attribute is available for a transaction development area "without account agreement". Labeling an untested transaction development area as "to be consolidated" affects the consolidation functions (especially with respect to eliminating existing data) as well as the currency conversion. While data with consolidated transaction development area posting keys are converted normally, e.g. by closing rate, posting keys with unconsolidated transaction development areas are treated analogously to statistical sets, i.e. converted at a fixed rate of 1, unless otherwise stated in the data set or in the posting key conversion rule.
  • Currency rate average per month: This attribute characterizes a transaction development that is specifically defined for currency conversion with monthly average rates. This can be specified for both transaction developments with normal carry forward and transaction developments with sample accounting. This attribute helps checks define the posting keys to a transaction development.
  • Autom. calcul. changes act. period: Transaction development with automatic calculation of the current change characterizes a transaction development in which the current change is automatically determined and set from the difference between account balance and carry forward. This can be specified for transaction developments with normal carry forward and must be specified for transaction developments with sample accounting. This attribute helps checks define the posting keys to a transaction development. The switch in the Period/Transaction development area application (PRDDEV) for an auto transaction development can be set to the value 'M'. As a result, the automatic compensation between development transactions and account balances is switched off and for which differences have to be recorded manually development transactions. This supports the ability to automatically balance transaction developments that are evaluated for cashflow statement in some periods, but not in all. With this control option it is useful to mark all available transaction developments for "automatic calculation". This marking is only not permitted for the holding level. This option is also available in the Fact/Transaction development area table (FCTDEV). The adjustment can be made per fact in the application.

Carry-forward type

The carry forward type describes how the transactions and postings are presented in the transaction development area.

  • without carry forward: no carry forward.
  • with standard carry forward: Carry forward with the carry forward posting key.
  • with carry forward over sample accounting: Carry forward only in the form of a sample accounting with simultaneous cancellation of the carry forward to support the Cashflow statement. This attribute is only available to earlier databases where this feature was set up a long time ago.

Automatic depreciation

This option is only available in transaction developments for fixed assets.

For automatic depreciation, the setting determines whether the transaction development area should be used to determine cost or accumulated and current amortization current year.

On the third page of the wizard, as in other root applications, the descriptions are maintained in all activated languages.

2.2 Transaction Columns tab

This tab defines the transaction development columns for the previously set up transaction development.

The first page in the wizard is used to assign, describe, and validate the transaction development column:

  • Transaction development and transaction development column: The transaction development column is composed of the transaction development and the column number, whereby the transaction development is already predefined and cannot be changed.
  • Validity from/until: The period of validity of the transaction development column is defined here.
  • Description: An individual description must be entered (max. 70 digits).
  • Column header: An individual description must be entered (max. 70 digits). Multiline input is supported for the column header.
  • Short text: Optionally, an individual description can be entered (max. 10 digits).

On the second page of the wizard, you can specify the following attributes for the transaction development column:

Usage flag

  • Carry forward: Presentation column; is determined from the carry forward BSL and indirectly defines posting keys for manual carry forward.
  • Reposting: Transfer column; automatically triggers check for zero across all accounts.
  • Reconciliation of account balances: automatically triggers a check for compliance with profit and loss account balances according to account identifier.
  • Addition and disposal from merger: These transaction development columns are automatically checked for zero transactions and consolidation postings, similar to the transfer columns. Because the upstream merger disposals are performed on companies other than the additions, this check is performed not on company financial statements, but only on group financial statements, when the group transaction development reports are created.
  • None: No predefined use of the transaction development column.

Identifier transaction development and income statement reconciliation

Available only in transaction developments for fixed assets and provisions.

Aligns existing transactions in the transaction development column with specific account balances.

The following votes are possible:

  • Reconciliation with accounts with account identifier 'D' (continuous. DPN)
  • Reconciliation with accounts with account identifier 'Y' (resolution provisions)
  • Reconciliation with accounts with account identifier 'Z' (supply of provisions)
  • Without

On the third page of the wizard, as in other root applications, the descriptions are maintained in all activated languages.

2.3 posting Key Groupings tab

Such a group is a classification that can limit the assignment of posting keys to accounts. A typical use is the use of separate allowance accounts in fixed assets. As a rule, it should be ensured that only fixed asset transaction acquisition/production cost for the range of the value are recorded in the acquisition account, whereas only fixed asset transaction amortization current year for the range of the value are recorded in the value adjustment account. In this case, two accounting key groupings would be defined.

The posting key group consists of the transaction development and the maximum three-digit group key. Multilingual descriptions can also be defined.

To activate this functionality, a posting key group must be assigned to the respective accounts on the one hand, and an account group must be assigned to the respective posting keys on the other hand. The assignment group must match the transaction development of the account or posting key.

In all applications for maintaining report data with posting key specification (development transactions, postings, consolidation postings), the following test is built in: If both the account and posting key are associated with a posting key group, they must be the same. However, if one of the two objects does not have a posting key group, the combination is allowed. The same verification shall be carried out for the information provided in the consolidation parameters.

For accounts, the additional condition applies that the data must remain valid even when they are transferred from the company to the group chart of accounts. Therefore, the specification of a group of accounting codes to a group account is automatically inherited to all associated company accounts. Conversely, however, it is possible to assign a company account with a posting key group to a group account without a posting key group. The restriction then applies only in the company chart of accounts.

2.4 Posting Keys tab

The final tab defines the posting keys. These are awarded group-wide.

The first page in the wizard is used to assign, describe, and validate the posting key:

  • Transaction developments and posting key: The posting key is composed of the transaction development and the posting key number, the transaction development already being predefined and cannot be changed.
  • Validity from/until: The validity period of the posting key is defined here.
  • Description: An individual description must be entered (max. 70 digits).
  • Column header: An individual description must be entered (max. 70 digits). Multiline input is supported for the column header.
  • Short text: Optionally, an individual description can be entered (max. 10 digits).

On the second page of the wizard, the properties for the posting key are specified:

  • Transaction development area: Mapping to a previously created transaction development area.
  • Transaction development column: Associate the posting key with a previously created
  • Usage tag: The usage tag is always set if a specific posting key is to be used for a specific processing (for more information, see Posting Key Usage Tag).
  • Debit/credit codes: The C/D mark serves to indicate a positive or negative value. The standard debit/credit identifier of the posting key is used as a standard identifier, for example, during the entry or modification of postings.
  • Form data entry: This attribute of the posting keys table is the "form entry column order". An entry in this attribute allows a value to be entered for this posting key in the development transaction form entry. The numerical value determines the order of the input fields.
  • Plan posting key: In IDL Forecast, scenarios can also be planned with development transactions. To do this, Forecast needs at least one default posting key that is used for the variations in the rules.
    With this check mark, you can select the posting keys that are to be displayed for selection in Forecast.
    When planning, you usually does not need all the posting keys that have been created in the system for each development transactions.

On the third page of the wizard, as in other root applications, you can maintain the descriptions in all activated languages.
Published:

Transaction Development Definitions

1 Transaction Development (TRNDEVDFN)

The application is used for the creation and care of transaction developments. You can open it via the short word TRNDEVDFN or via the resource tree in the master and control data.

When the application is launched, a table appears with the defined transaction developments and their attributes.

1.1 Setting Up Transaction Developments

Create a new transaction development using the asterisk icon in the top menu bar or the menu bar at the top right. This opens a wizard consisting of three pages. Green check marks or red stop signs indicate whether the page is filled correctly. If certain key fields have not been filled correctly, you cannot switch to another page. Clicking 'Finish' is equivalent to 'Save'. A corresponding entry of the 'last modification' takes place only after a refresh.

The three pages of the wizard are:

Page 1 Description:

  • Transaction development: Input of the three-digit, alphanumeric key, detectable only during creation and copying. The entries are automatically converted from lowercase to uppercase. Immediately prevents the entry of illegal special characters ('%', '_', single '*').
  • Validity from/until: The validity period of the transaction development is defined here.
  • Description: An individual description must be entered (max. 70 digits).
  • Column header: An individual description must be entered (max. 70 digits). Multiline input is supported for the column header. This is the headline for the transaction development's status line in the CFSMNR monitor.
  • Short text: Optionally, an individual description can be entered (max. 10 digits).

Figure: Page 1 of Change transaction development wizard

Page 2 Properties:

This page provides input for the table-specific attributes by selecting a transaction development type. The transaction development type "B" can only be selected for transaction development "B" and therefore cannot be used for any next transaction development.

Figure: Page 2 of Change transaction development wizard

Page 3 Descriptions (multi language:

This page allows you to maintain your descriptions in all enabled languages, as in other root applications.

Figure: Page 3 of Change transaction development wizard

1.2 Opening Subsequent Applications

When you double-click on a row of the transaction development table or select the eye icon in the context menu, four tabs appear, in which the associated data for transaction development areas, transaction development columns, posting key groupings, and posting keys are displayed.

2 Maintaining Subsequent Applications

When you select a row and click the pencil icon, or double-click a row in these tables, or click the asterisk icon to open a wizard to edit or entry the data:

2.1 Transaction Development Areas tab

Differentiation within a transaction development is affected by the provision of transaction development areas.

The first page of the transaction development area wizard contains the same dialog as the transaction development configuration. This is where the validity and the descriptions are maintained.

On the second page of the wizard, the transaction development area attributes are maintained:

Figure: Page 2 of Change transaction development area wizard

Other options

  • Balance relevant: The account balance results from the balance-relevant transaction development areas.
  • Without account agreement: The marking of a transaction development area ‘without account agreement' has a particular effect on the posting keys assigned to that transaction development area. Development transactions with these posting keys are not included in the total to be compared with the account balance. Postings and consolidation postings with these posting keys are not included in the sum of debit and credit values and in the calculation of the result effectiveness. Therefore, it is not possible to activate the options "balance relevant" and "without trial" in a transaction development area. Development transactions with posting keys that are assigned to unsampled transaction development areas are not included in the totals for reconciliation with the account balance. They are also not taken into account when generating account balances from the sum of the development transactions. But they flow into the control values. In the transaction overviews (FATRN, CAPTRN, PRVTRN, DEVTRN) these transactions are not sorted into the table in the usual order, but in a separate block behind the effective data, so that the displayed totals can be traced. Postings with posting keys that are assigned to untested transaction development areas are not included in the debit and credit totals, nor are they included in the calculation of the result effectiveness per posting record.
  • Consolidation: This attribute is available for a transaction development area "without account agreement". Labeling an untested transaction development area as "to be consolidated" affects the consolidation functions (especially with respect to eliminating existing data) as well as the currency conversion. While data with consolidated transaction development area posting keys are converted normally, e.g. by closing rate, posting keys with unconsolidated transaction development areas are treated analogously to statistical sets, i.e. converted at a fixed rate of 1, unless otherwise stated in the data set or in the posting key conversion rule.
  • Currency rate average per month: This attribute characterizes a transaction development that is specifically defined for currency conversion with monthly average rates. This can be specified for both transaction developments with normal carry forward and transaction developments with sample accounting. This attribute helps checks define the posting keys to a transaction development.
  • Autom. calcul. changes act. period: Transaction development with automatic calculation of the current change characterizes a transaction development in which the current change is automatically determined and set from the difference between account balance and carry forward. This can be specified for transaction developments with normal carry forward and must be specified for transaction developments with sample accounting. This attribute helps checks define the posting keys to a transaction development. The switch in the Period/Transaction development area application (PRDDEV) for an auto transaction development can be set to the value 'M'. As a result, the automatic compensation between development transactions and account balances is switched off and for which differences have to be recorded manually development transactions. This supports the ability to automatically balance transaction developments that are evaluated for cashflow statement in some periods, but not in all. With this control option it is useful to mark all available transaction developments for "automatic calculation". This marking is only not permitted for the holding level. This option is also available in the Fact/Transaction development area table (FCTDEV). The adjustment can be made per fact in the application.

Carry-forward type

The carry forward type describes how the transactions and postings are presented in the transaction development area.

  • without carry forward: no carry forward.
  • with standard carry forward: Carry forward with the carry forward posting key.
  • with carry forward over sample accounting: Carry forward only in the form of a sample accounting with simultaneous cancellation of the carry forward to support the Cashflow statement. This attribute is only available to earlier databases where this feature was set up a long time ago.

Automatic depreciation

This option is only available in transaction developments for fixed assets.

For automatic depreciation, the setting determines whether the transaction development area should be used to determine cost or accumulated and current amortization current year.

On the third page of the wizard, as in other root applications, the descriptions are maintained in all activated languages.

2.2 Transaction Columns tab

This tab defines the transaction development columns for the previously set up transaction development.

The first page in the wizard is used to assign, describe, and validate the transaction development column:

  • Transaction development and transaction development column: The transaction development column is composed of the transaction development and the column number, whereby the transaction development is already predefined and cannot be changed.
  • Validity from/until: The period of validity of the transaction development column is defined here.
  • Description: An individual description must be entered (max. 70 digits).
  • Column header: An individual description must be entered (max. 70 digits). Multiline input is supported for the column header.
  • Short text: Optionally, an individual description can be entered (max. 10 digits).

On the second page of the wizard, you can specify the following attributes for the transaction development column:

Usage flag

  • Carry forward: Presentation column; is determined from the carry forward BSL and indirectly defines posting keys for manual carry forward.
  • Reposting: Transfer column; automatically triggers check for zero across all accounts.
  • Reconciliation of account balances: automatically triggers a check for compliance with profit and loss account balances according to account identifier.
  • Addition and disposal from merger: These transaction development columns are automatically checked for zero transactions and consolidation postings, similar to the transfer columns. Because the upstream merger disposals are performed on companies other than the additions, this check is performed not on company financial statements, but only on group financial statements, when the group transaction development reports are created.
  • None: No predefined use of the transaction development column.

Identifier transaction development and income statement reconciliation

Available only in transaction developments for fixed assets and provisions.

Aligns existing transactions in the transaction development column with specific account balances.

The following votes are possible:

  • Reconciliation with accounts with account identifier 'D' (continuous. DPN)
  • Reconciliation with accounts with account identifier 'Y' (resolution provisions)
  • Reconciliation with accounts with account identifier 'Z' (supply of provisions)
  • Without

On the third page of the wizard, as in other root applications, the descriptions are maintained in all activated languages.

2.3 posting Key Groupings tab

Such a group is a classification that can limit the assignment of posting keys to accounts. A typical use is the use of separate allowance accounts in fixed assets. As a rule, it should be ensured that only fixed asset transaction acquisition/production cost for the range of the value are recorded in the acquisition account, whereas only fixed asset transaction amortization current year for the range of the value are recorded in the value adjustment account. In this case, two accounting key groupings would be defined.

The posting key group consists of the transaction development and the maximum three-digit group key. Multilingual descriptions can also be defined.

To activate this functionality, a posting key group must be assigned to the respective accounts on the one hand, and an account group must be assigned to the respective posting keys on the other hand. The assignment group must match the transaction development of the account or posting key.

In all applications for maintaining report data with posting key specification (development transactions, postings, consolidation postings), the following test is built in: If both the account and posting key are associated with a posting key group, they must be the same. However, if one of the two objects does not have a posting key group, the combination is allowed. The same verification shall be carried out for the information provided in the consolidation parameters.

For accounts, the additional condition applies that the data must remain valid even when they are transferred from the company to the group chart of accounts. Therefore, the specification of a group of accounting codes to a group account is automatically inherited to all associated company accounts. Conversely, however, it is possible to assign a company account with a posting key group to a group account without a posting key group. The restriction then applies only in the company chart of accounts.

2.4 Posting Keys tab

The final tab defines the posting keys. These are awarded group-wide.

The first page in the wizard is used to assign, describe, and validate the posting key:

  • Transaction developments and posting key: The posting key is composed of the transaction development and the posting key number, the transaction development already being predefined and cannot be changed.
  • Validity from/until: The validity period of the posting key is defined here.
  • Description: An individual description must be entered (max. 70 digits).
  • Column header: An individual description must be entered (max. 70 digits). Multiline input is supported for the column header.
  • Short text: Optionally, an individual description can be entered (max. 10 digits).

On the second page of the wizard, the properties for the posting key are specified:

  • Transaction development area: Mapping to a previously created transaction development area.
  • Transaction development column: Associate the posting key with a previously created
  • Usage tag: The usage tag is always set if a specific posting key is to be used for a specific processing (for more information, see Posting Key Usage Tag).
  • Debit/credit codes: The C/D mark serves to indicate a positive or negative value. The standard debit/credit identifier of the posting key is used as a standard identifier, for example, during the entry or modification of postings.
  • Form data entry: This attribute of the posting keys table is the "form entry column order". An entry in this attribute allows a value to be entered for this posting key in the development transaction form entry. The numerical value determines the order of the input fields.
  • Plan posting key: In IDL Forecast, scenarios can also be planned with development transactions. To do this, Forecast needs at least one default posting key that is used for the variations in the rules.
    With this check mark, you can select the posting keys that are to be displayed for selection in Forecast.
    When planning, you usually does not need all the posting keys that have been created in the system for each development transactions.

On the third page of the wizard, as in other root applications, you can maintain the descriptions in all activated languages.
For an optimal Community experience, Please view on Desktop
Powered by Zendesk