With the help of this application it is possible to define and evaluate individual check rules at company and group level. The result of the checks can be seen in an extra column in the Companies financial statements+monitor or in the Group companies+monitor. The defining of individual check rules is described in the following:
Via the short name 'PRF' or via the resource tree in the master and control data you can reach the application 'Check rules' (PRF) in which a check rule is defined.
Image: Calling up the application 'PRF'
Image: Calling up the application 'PRF' via the quickstart
In the application itself you can edit or delete data in the usual manner via the menu item 'Action', as well as branch off into the follow-on application 'Check rules/Positions'(PRFPOS).
Image: Actions in 'PRF'
When a check rule is deleted, all of the check rule results produced with it are automatically deleted as well.
The check rule is defined in the individual record. Every check rule consists of an arithmetic operation which is defined separately on the left and right side of the check rule, i.e. the data which is to be compared.
Image: Check rule
In the field 'Operator' the arithmetic operation which is to be performed is defined. 30 arithmetic operations are available:
Image: Arithmetic operators
These operators are arranged in six rule types:
1) Check both sides
This rule type makes it possible to check that only one of two possible accounts has a balance. By allocating several accounts to one side, this rule then applies for the total of the balances and where applicable also for postings to these accounts.
(L/R <> 0) => (R/L = 0)
If one side does not equal zero, then the other side equals zero.
(L <> 0) => (|R| <= |L|)
If the left side does not equal 0, then the absolute value of the right side has to be less than or equal to the absolute value of the left side.
(L <> 0) => (|R| >= |L|)
If the left side does not equal 0, then the absolute value of the right side has to be greater than or equal to the absolute value of the left side.
(L <> 0) => (R = L)
If the left side does not equal 0, then the right side has to be equal to the left side.
(L <> 0) => (|R| = |L|)
If the left side does not equal 0, then the absolute values of both sides have to agree.
(L=0) => (R=0)
If the left side is = 0, then the right side also has to be = 0. This check rule can also be defined with tolerances.
2) Check the absolute values
|L| <=|R|
The absolute value of the left side has to be less than the value on the right side.
|L|=|R|
The absolute values of both sides have to agree.
|L| > =|R|
The absolute value of the left side has to be greater than the value on the right side.
3) Check the percentage deviation
L <= R + X%
The left side has to be less than or equal to the right side plus X per cent.
L <= R - X%
The left side has to be less than or equal to the right side minus X per cent.
L >= R + X%
The left side has to be greater than or equal to the right side plus X per cent.
L >= R - X%
The left side has to be greater than or equal to the right side minus X per cent.
The percentage "X" has to be specified in the check rule (PRF). The format allows up to three digits before and after the decimal point.
4) Existence check
L EXIST
L NOT EXIST
These operators work in a similar manner to the comparison with zero. However, the specific value is not observed, but it is only considered whether (at least) a value exists. If several accounts are specified, at least one account has to or none of these accounts are allowed to show a balance.
5) Mandatory comments for balances in certain accounts
It is possible to designate certain accounts (e.g. "Miscellaneous") which have to include a comment.
L: C EXIST
All data specified for the left side has to have a remark/comment (e.g. in KTOSALE as a remark, in SPIBEWE as a posting text).
L: H EXIST
All of the data specified for the left side has to have an explanation in help-text.
For these operators only a left side may be defined in PRFPOS (similar to "L EXIST"). Several accounts and/or positions may be specified. With the calculation of check rule results, the comments for all of the specified data have to be present. If only one of the balances concerned or one of the transactions concerned do not have a comment with a help—text or a remark, the check rule is not satisfied and the appropriate status is displayed [red]. If there is no such data, the check rule is satisfied.
6) Check one side
It is also possible to only check one side:
L <= 0
L <= R
L <> 0
L <0
In the next step it now has to be defined which data (I=IC sub-account balances, K=account balances or S=development transactions) and which value type (B=posting, S=balance or S+B=balance+postings) are to be validated where applicable with data from the previous period or an upstream fact. This has to be entered for the left and right side.
Check rules can be applied to values in local, group and parallel currency. However, it is possible that values which agree in local currency may show rounding differences after the currency conversion in group and/or parallel currency. In order to prevent the check rules from showing an error status here, it is possible to define tolerances for check rules. For each currency a tolerance can be entered (e.g. 0.00 for local currency, but 1.00 for group and parallel currency).
When tolerance values are specified for check rules which require values to be equal, the check result is still [green] if both sides have a difference less than or equal to the specified tolerance. With check rules with operators other than “equal to”, e.g. "L>=R", this check rule is also satisfied if the left side is smaller than the right side and the difference is less than the specified tolerance.
With a check rule it can be controlled whether a check rule is only used for the company financial statement “G” or only for the group financial statement “K” (if the box is empty the check rule is applied to both levels).
The checks at group level are started by the action "Calculation of check rule result" in the application "Group companies+monitor" (KTKGES). As well as the company financial statement data, the consolidation postings are also processed. The company financial statement data of partially consolidated companies is only considered on a pro-rata basis, in addition to the balances in accounts with the account flag 'Q'. This is a global action, i.e. the entire group financial statement is always validated.
The company financial statement data of companies with the consolidation type 'K' (not consolidated) or 'E' (at equity) is not included in the group check rule result. Consolidation postings for these companies are still included though (in agreement with group reports, the overviews "Account balances and consolidation postings" (KONSAL) and "Transactions and consolidation postings" (KONBEW) and the subgroup data exchange).
Via 'Action' + 'Positions/Accounts' you can reach the application 'PRFPOS', in which in extended mode first of all the left side of the check rule and then the right side of the check rule can be allocated the accounts and positions.
Image: Selecting the left or right side
Image: Individual record 'PRFPOSE'
The input block is to be understood as follows: For the selection of certain accounts or positions which are to be used for the check, the following selection criteria is available: Chart + Position, Chart + Account, B/S+P/L code, Account flag and Transaction development. Here any number of criteria may be defined. If the fact ‘I= IC sub-account balances’ or 'K=Account balances' was defined in the application 'PRF', input in the fields posting key and transaction development column is not possible (error message: KON1861E Check rule data type prohibits posting key and development column).
If the fact 'S=Development transactions' was selected in the application 'PRF', any number of criteria may be defined here.
If duplicate criteria were specified, a warning appears in the overview 'PRFPOS' that there are duplicate entries in the allocated check rules (Warning:KON1862W Double entries in check rule assignments).
The check rule results can be calculated in the Companies financial statements+monitor (Action – Function + 'Calculation of check rule result'), in the Group companies+monitor (within the 'final functions') and in the applications 'PRFERG'/'PRFERGK'. No new check rule results can be calculated for locked company or group financial statements (in order to prevent the check rule status from changing from 'green' to 'red' if new check rules are defined or because data in a comparison period or comparison fact has changed while the data in the current financial statement has not changed).
Image: Calculation of check rule result
In the Companies financial statements+monitor this action can be performed for all companies, and in the application 'PRFERG' only for the selected company. If a calculation has not yet been performed, the overview in 'PRFERG' is empty for the time being. The result only appears in the overview after the action 'Calculation of the check rule result' is performed; this is always done globally for all of the check rules defined.
The check rules produce a check result for each company, period and fact. The overall result is displayed as a record in Processing controls (VERARB). The result of the group check rules is stored in a record in Group processing controls (KVERARB).
The status of the result in the group check rules (type of notification entered) is displayed in a column in the Group companies+monitor (KTKGES) in the group row. Via the Action menu - Lists, the resource tree ("group financial statement") or the short name PRFERGK you can reach the new list "Group check rule results" in which the results of the individual check rules are displayed similar to the company check rule results.
If, when accounts are used in the check rules, the associated accounts chart is not valid for the fact or company to be checked, a special notification is set for the check rule. This then does not affect the overall result of the check. (The check rule is considered to be non-existent.)
As positions and accounts might be mixed in a check rule, when defining the sign before a value only the debit/credit sign is considered, as in the report the B/S+P/L code of the positions is always used and this is not known or not clear when individual accounts are specified in the check rule. Misunderstandings are also possible when a comparison is made with a report with a position structure in which the top position always defines the B/S+P/L code of the positions below it.
The check result for an individual check rule is calculated for each currency (depending on the WUM control in FAC). Only a single record for the overall result is registered in Processing controls; this record is only error-free if the check rules for all of the currencies were error-free.
The overviews for check rule results in the company or group financial statement (PRFERG/PRFERGK) include a delete function. With the action "Delete check rule results" all of the results of the company or group financial statement are always deleted so that it is as if the check rules had never been calculated. The record for this in Processing controls (VERARB/KVERARB) is not deleted though, but receives the notification KON1894W (Check rule result not current), resulting in the status being 'yellow' in the Companies financial statements+monitor or in the Group companies+monitor.
Via the menu item 'Action' or by double clicking on the column 'Check rule' or a result column the system either branches off into the application 'PRF' or into 'PRFPOS'.
The list allows four different sorting and selection options; the default sorting option is 'V' (Processed check rules with values).
Image: Selection options
The overall result of the check of all rules for a company is displayed in the Companies financial statements+monitor for each company with the column ‘Check rule result’. By double clicking on this column or via 'Action'-'Check rule results’ you can branch off into the application to display the check rule results (PRFERG).
Image: Displaying the column 'Check rule result', branching off into the application 'PRFERG'
Status '-': no check rules are to be used e.g. due to the definition and allocation a check rule exclusion group.
Status 'green': all of the check rules for the company are error-free.
If one side of a check rule is allocated a position, but the associated position plan is not allocated an account in the accounts chart relevant for the respective fact, the message KON2053W ("Check rule not processed, because chart of positions without accounts") appears in the check rule result and the check rule status in the Companies financial statements+monitor is 'green'.
Status 'yellow': the data has changed for the existing check rules and the check rule result has to be re-calculated (KON1894W Check rule results not current – data has changed). This status only functions error-free if in the application 'FAC' 'X' is set in the field 'With control value calculation', as any changes to the basic data ('KTOSAL', 'ANLBEW','BUCH', ...) results in a change in the respective record in Processing controls, and this change in turn triggers the status 'yellow' for the check rule results.
Status 'red': at least one of the defined check rules shows up an error.
Check rule results can be provided with comments, e.g. to document a status. The action "Edit help-text" is available for this purpose in the check rule result overviews (PRFERG and PRFERGK). Like with the report data, it is not possible for these texts to be parallel in different languages.
The existence of a comment is shown as in other overviews by a column ("H"/"Status of the help-text") by symbols (ticks) or coloured areas (green), provided the option "Display help-text info" has been activated in the "View" menu item. By double clicking on this column you branch off into the help-text display. Please note that these texts are not retained for automatically generated data (help-text) when the automatic application is repeated, e.g. with the group carry-forward, but have to be re-recorded.
If check rule results have to be re-calculated, first of all the previous check rule results are deleted. The associated comments are deleted as well. They are therefore no longer available, even if the check rule result has not changed.
When using individual authorisation groups without reference to the IDL standard authorisation groups, it should be noted that the amendment of comments requires amendment authorisation for the respective application.
The running of check rules can be restricted by specifying their validity ('PRFE'). In order not to run certain check rules depending on the (sub)group (KTK), the company (GES), the fact (FAC) and the period (monthly or annual statement) (ABR), an additional option is required.
The application 'Exclusion groups for check rules' (PRFGRP), in which the exclusion group is defined, serves this purpose. The application can either be reached via the resource tree or via the short name by entering 'PRFGRP'. Via 'Action', 'Edit data' you can reach the individual record in which the exclusion group is defined.
Image: Overview and individual record 'PRFGRP'
If an exclusion group has been defined, via 'Action' or the right mouse button you can branch off directly into the follow-on application 'Exclusion groups/ Check rules' (PRFZUO) and the desired check rules (defined in the application 'PRFPOS') can be allocated to the defined exclusion group.
Image: Branching off into the follow-up application 'PRFZUO'
Image: Overview and individual record for the application 'PRFZUO'
With the applications 'PRFGRP' and 'PRFZUO' groups are therefore formed and the check rules included in them are not run. This has the advantage that there are mostly less check rules in a group and that difference exclusion groups for company, fact and period can be better combined. A check rule is not run if it is included in the exclusion for the company or the period. As in each case only one exclusion group can be allocated, where applicable several similar exclusion groups have to be defined, if e.g. companies differ in the check rules to be applied.
In order for the exclusion groups defined in this way to now be able to take effect for (sub)groups, companies, facts or for periods, these exclusion groups have to be specified there (KTKE, GESE, FACE or ABRE).
Image: Allocation of exclusion group to the group
Image: Allocation of exclusion group to the company
Image: Allocation of exclusion group to the period
Image: Allocation of exclusion group to a fact
A user who always wants to run all check rules does not have to change anything.
These applications were also considered in other functions such as data exchange (KONDAT), import and changes of company data (TXTGES, GESLOG).