Voucher and Posting Rules (VCHPSTR)

1 Introduction / disambiguation

The balances and transactions available in IDL Konsis on a fact can be demonstrably changed on the next fact via vouchers (VCH) and postings (PST).

Until now, unlike the consolidation postings, only manually created vouchers and postings exist. The application described below makes it possible to generate rule-based vouchers and postings.

2 Formulation of the requirement

There are both voucher rules and posting rules. For the latter, there currently exists only a single type of rule which could be colloquially referred to as a clearing rule.

The reason for this is that we assume that in the balances and transactions of a company financial statement there are already certain facts booked which are to be canceled again for the purposes of the HB II or the group. The event to be canceled can be used, for example, as a development transaction (e.g. delivery to a provision). This is described in the Source rule assistant. The counterpart to the transaction to be canceled is the account described as destination (e.g. other operating expenses).

3 Implementation in IDL Konsis

You can define voucher rules and posting rules in the VCHPSTR application. The Voucher Rule Wizard queries all the information that is used as attributes on the voucher that you create later.

4 voucher rule

The first page of the Voucher Rule Wizard looks the same as it does in many other wizards. Enter a unique identifier, a description, and an effective date.

Figure: Voucher Rule Wizard / Page 1

On the second wizard page of the voucher rule, the voucher number of the voucher to be created must be specified, among other things. A check should be added here to prevent the same voucher number from being generated twice.

Figure: Voucher Rule Wizard / Page 2

You can define the voucher number dynamically by using the placeholders MM and YYYY anywhere in the voucher number, which will be replaced by the month and year of the period when generating vouchers. For example, define a voucher number as YYYY-MM-001, whereas YYYY-MM is a placeholder for the period. In the period 12.2022, the rule will generate a voucher number 2022-12-001.

Currently, vouchers with transaction type WU or WX can be generated. After a change of year, WU vouchers retain the WU mark, while vouchers originally posted with WX become EU vouchers. Since a voucher rule can only generate vouchers with the same voucher number, if WX is used, the newly generated postings would be appended to the existing European Union voucher in the second period. Although the postings are still correct in the second period, the carry forward from the second to the third period takes place in accordance with European Union logic instead of WX logic. This means that the reversal of the earnings effect from the second period is missing in the third period. Therefore, the use of WX is not recommended for affecting net result postings. There is no problem with balance-sheet only postings, as the carry forward of balance-sheet only postings at WX is the same as in the EU. The same applies to pure P&L postings: Here, too, the formation of lectures at WX and EU is identical. Since profit and loss accounts are usually not mirrored, WX does not have any carry forward at all (as does EU).

Figure: Voucher Rule Wizard / Page 3

Figure: Voucher Rule Wizard / Page 4

Figure: Voucher Rule Wizard / Page 5

5 posting rule

Creating a posting rule is optional. If there is only one voucher rule without posting rules, this voucher rule creates blank vouchers. The French colleagues explicitly wanted this kind of program behavior.

The vouchers created in this way are intended to make your work easier, since you can save yourself the step of putting on the voucher first. Vouchers that are not needed can be deleted or set to inactive again, otherwise the state of the vouchers and postings will remain yellow in the Company financial statements + monitor.

In the posting rule, the source and destination are defined. The source shall be the account (with posting key, business unit, and controlling information if applicable) on which the balance or development transaction to be posted is found. At the same time, the source indicates the account which is "cleared" by the posting.

In a mirror-guided account, you can never set the account balance to be taken into account, but only the development transactions. In the following example, we recorded a posting rule that should cancel the contribution (BSL 110) in the 39260 accrual account. The target is the profit and loss account 67020.

If, by way of derogation from the following example, we wanted to set the complete account balance of account 39260 to zero, we would have to create next posting rules for the other posting keys, which could also be filled. However, the carry forward posting key is not available here, since it makes little sense to post the carry forward using rule-based posting rule, since this would get in the way with already existing carry forward postings.

Figure: Posting Rule Wizard / Page 1

Figure: Posting Rule Wizard / Page 2

Figure: Posting Rule Wizard / Page 3

Figure: Posting Rule Wizard / Page 4

6 Identification of the amount to be posted

If development transaction is conducted on partially tested IC accounts with and without IC-company, it is currently not possible to rely on development transaction company without IC-mark. This is planned for one of the next expansion stages of the posting rules, for this purpose one would have to filter on IC-Ges * (without).

Also, the % placeholder is not available. Only the development transactions of certain IC companies can be posted on partially tested IC accounts. For this purpose, it is then necessary to specify the respective IC-value in the posting rule. Alternatively, all development transactions can be posted on a specific posting key company, regardless of the IC-value.

7 Available posting keys (For transaction development accounts)

Carry forward posting keys are generally not available here, since it makes no economic sense to directly carry forward an account make a posting within a company financial statement 1, since the balance sheet relationship could then no longer be established.

Since the rule-defined vouchers and posting rule are always carried forward, it is never necessary to write off a complete account balance by means of an elimination carry forward. Rather, it is sufficient to write off the current changes in each financial statement, since the transaction development carryforward is set to zero by the postings already carried forward.

All posting keys without reservation markings are available.

8 Company financial statements + monitor: Creating the Rules-based vouchers and postings

Figure: Call from Company financial statements + monitor

9 Company financial statements + monitor: The rules-based vouchers and postings

A voucher to be created by a voucher rule may already exist. Either because you have already created this voucher manually, or because the voucher has already been created for the period carried forward. In either case, the voucher cannot be re-applied and the voucher already remains.

In a voucher, both manual postings (including carry-forward postings) and rule-based postings can co-exist.

When generating the vouchers, it is checked whether the attributes of the already existing voucher match the details in the voucher rule. If it does not, its posting rules are not executed and the following message is returned. Nothing is changed in the voucher that already exists.

Figure: The voucher to be generated already exists with different attributes

10 mark of origin

The rule-based postings are recognizable as such, since the number of the voucher rule is shown in a new column within the overview PST. For non-rule-based postings (for example, for manually entered postings or carry-forward transactions), this column is blank.

In the future, this flag could also be used to identify carry-forward postings as such and thus resolve IDL-5463.

Figure: Overview of postings

11 carry-forward for a period

For the subject period carry-forward, a distinction is made between carry forward of the year and carry forward with the turn of the year. If the source period is an annual period (identifier = J), we are talking about a carry forward with a change of year, otherwise we are talking about an underyear carry forward.

For year-end period carryforwards, rule-based postings are carried forward in the same way as manually entered postings. In the target period, they do not bear an origin mark, since they have now no longer been generated from rules, but have already been generated by the carry forward.

In the case of the year-old carry forward, all game movements and manually recorded postings are copied one-to-one from the source period to the target period. However, the rule-based postings are left out of this process, since in the target period the generation of the rule-based postings has to be started again anyway, since the amounts to be posted could also have changed.

When the rule-based vouchers and postings are (re-)generated, any rule-based postings that exist are deleted again.

12 Specific case: Amount to be accounted is 0.00

In the special case that the amount to be posted is 0.00, the respective posting rules are nevertheless executed and corresponding postings are generated with an amount of 0.00 in each case. This is done mainly for reasons of completeness and clarity, since you would possibly find it irritating if, for example, one or more voucher rules were apparently not executed in a continuous sequence of a plurality of voucher rules. Probably you would call up the overview of the voucher rules, open the seemingly unexecuted amount and check whether the amount to be posted is actually 0.00. This potentially time-consuming search action is to be spared.

Figure: Summary of postings in the specific case where the amount to be posted is 0,00.

13 Release 23.3 Enhancements

Postings created from rules can no longer be edited or deleted manually. This was introduced because manual editing would cause the source identifier to be lost and the journal line would be considered a manually created posting. If the rule-based vouchers and postings were run again, the journal line would have stopped (possibly as a one-page posting) and the state of the postings would have been red. A deleted posting would have been regenerated when the rules-based vouchers and postings were run again. You might not have understood this or at least not expected it and would have found this irritating. Moreover, it would have meant a disconnect between the rules and the actual postings.

Instead of editing the posting line, edit the posting rule accordingly.

Corrections were also made, including:

• Sequence numbers could be assigned more than once
• Up to now, compaction objects could also be selected for controlling objects
• The selection of controlling objects is now only allowed if the controlling module is also switched on in the previously selected fact.
• For business units, aggregation objects could also be selected
• The COBUALC test of target IC-company / GB is done incorrectly against target GB, not target IC-GB
• After the "generation", a check module (update status values) is called, but this also checks the state of any development transaction. The examination therefore took an unnecessarily long time.
• The new test module KCUK068 runs much faster.
• Correcting SQL Errors and Java Exception

14 outlook

The VCHPSTR data is to be integrated into GRPSUBEX so that GRPSUBEX is complete again and there is a possibility to exchange voucher and accounting rules between two databases.

It is envisaged to use "*" and "%" as placeholders for IC company in order to reclassify amounts to third parties ("*") or to any IC-type ("%").

A next posting rule based on the reference value rule from IDL Forecast may be added to VCHPSTR. There is no clear timetable for this yet.