Rule vouchers and postings (BUCHDEF)

Table of Contents

• 1 Introduction / disambiguation
• 2 Formulation of the requirement
• 3 Implementation in IDL Konsis
• 4 Voucher rule
• 5 Posting rule
• 6 Identification of the amount to be posted
• 7 Available posting keys (For mirror accounts)
• 8 Company financial statements + monitor: Creating the Rules-based vouchers and postings
• 9 Company financial statements + monitor: The rules-based vouchers and postings
• 10 Mark of origin
• 11 Carry-forward for a period
• 12 Specific case: Amount to be accounted is 0.00
• 13 Outlook

1 Introduction / disambiguation

The balances and transactions available in IDL KONSIS on a fact can be demonstrably changed on the next fact via vouchers (BEL) and postings (BUCH).

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 document rules and posting rules in the BUCHDEF application. The Document Rule Wizard queries all the information that is used as attributes on the voucher that you created later.

4 voucher rule

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

Picture 1: Document Rule Wizard / Page 1

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

Picture 2: Document Rule Wizard / Page 2

Picture 3: Document Rule Wizard / Page 3

Picture 4: Document Rule Wizard / Page 4

Picture 5: Document Rule Wizard / Page 5

5 posting rule

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

The vouchers created in this way are intended to make the work easier for the customer, since the customer can save himself the step of putting on the voucher first. Pos. 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 booked 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 booking 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 book the carry forward using rule-based posting rule, since this would get in the way with already existing carry forward postings.

Picture 6: Posting Rule Wizard / Page 1

Picture 7: Posting Rule Wizard / Page 2

Picture 8: Posting Rule Wizard / Page 3

Picture 9: Posting Rule Wizard / Page 4

6 Identification of the amount to be posted

Note: 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 booking 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 booked on partially tested IC accounts. Company For this purpose, it is then necessary to specify the respective IC-value in the booking rule. Alternatively, all development transactions can be booked on a specific posting key company, regardless of the IC-value.

7 Available posting keys (For mirror 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 mirror 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

Picture 10: Call from company financial statements + monitor

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

Note: A voucher to be created by a voucher rule may already exist. Either because the user has 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 present remains.

In a voucher, both manual postings (including carry-forward bookings) 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 document 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.

Picture 11: 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 document rule is shown in a new column within the overview BUCH. 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 bookings as such and thus resolve IDL-5463.

Picture 12: 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 a 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 booking 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 the user would possibly find it irritating if, for example, one or more document rules were apparently not executed in a continuous sequence of a plurality of document rules. Rule Probably the user would call up the overview of the voucher rules, open the seemingly unexecuted amount and check whether the amount to be booked is actually 0.00. This potentially time-consuming search action is to be spared the user.

Picture 13: Summary of postings in the specific case where the amount to be booked is 0,00.

13 outlook

The requirement to block the rule-based postings against modification or delete has not yet been implemented. This requirement is important for the user because it is to be protected from editing a rule-based posting. As a result of the processing of the posting, the posting loses its rule reference and is henceforth considered a manual posting. If "posting generation" is restarted, it can have unpredictable consequences that the user may not be aware of and may find irritating. For example, if only one line is edited, this posting is considered to be manual and the next time the postings are generated, the posting rule is re-generated from its original position. However, the edited posting remains stationary, since it is now considered a manual posting. As a result, the accounting voucher is no longer valid.

Therefore, rule-based postings should be locked against editing and delete. This should be delivered with Fixpack A.

Fixpack A will also contain next corrections for several minor issues:

• Currently, compaction objects can be selected for controlling objects
• For business units, you can currently select aggregation objects
• After "generating", a check module (updating status values) is called, but this also checks the state of any development transaction. It is expected that the "correct" test module KCUK068 will run faster
• There may still be a need to correct the combination of Transaction development and controlling.

The fixed pack A is to be published on 25.8. (status: 21.6.).