This document explains what accounting rules are and provides an overview of the configuration workflow.
After reading this document you understand the purpose and structure of accounting rules and will be able to configure accounting rules on an overall level.
Use the information to define accounting rules in 'Accounting Rule. Set' (CRS395).
An accounting rule is a definition of which accounting string M3 will use when account entries are automatically created in a financial activity. Most of the integration between the financial system and other M3 applications is managed by the use of accounting rules.
Many financial activities in M3 result in the creation of at least two balancing account entries: one credit and one debit. Sometimes the account to use is entered manually during transaction entry, for example, when recording supplier invoices. However, in most cases the account is selected automatically based on an accounting rule. Thus, the complete set of accounting rules is a fairly complete reflection of the company's chart of accounts.
Once accounting rules are configured, they reduce manual transaction entry to a minimum, speeding entry and minimizing key-in errors.
M3 provides a standard set of accounting rules. They are downloaded and configured in 'Accounting Rule. Set' (CRS395). Each accounting rule consists of the following building blocks:
Both accounting events and accounting types are predefined in M3 Business Engine.
What Is an Accounting Event?
An accounting event is a financial activity in which account entries are created to reflect an increase or decrease in the company's assets and liabilities. Examples of accounting events are reporting received goods, recording customer payments, and depreciating fixed assets.
What Is an Accounting Type?
An accounting type represents a specific category of account entries that are automatically created during an accounting event. Examples are cash discounts and specific types of VAT. The same accounting type can be used in several accounting events.
The ID of an accounting rule consists of the combined IDs of the accounting event and accounting type. For example, accounting rule AR30-130 creates account entries for cash discounts after manual entry of customer payments in 'Payment Received. Record' (ARS110). AR30 is the accounting event for manually recorded payments and 130 is the accounting type for cash discounts.
Download Accounting Events and Accounting Types
Download accounting events by pressing F14 in 'Accounting Event. Open' (CRS375). Download accounting types by pressing F14 in 'Accounting Type. Open' (CRS385).
For both accounting events and accounting types, you can delete records that you are not going to use in order to have fewer combinations to maintain. For example, if you are not paying your suppliers by check, delete the corresponding accounting event, AP30. Or, if the accounting types for VAT receivable 2 and VAT payable 2 are not applicable, delete them. If you delete an accounting event or accounting type that is in use, M3 will create an account entry with an error account, stating the missing accounting event and accounting type.
Download Accounting Rules
Download the predefined but empty accounting rules for all remaining combinations of accounting events and accounting types by pressing F14 in 'Accounting Rule. Set' (CRS395).
Download Dynamic Objects
If dynamic objects were not already downloaded, download the objects to use in the accounting strings by pressing F14 in 'Field Group. Open' (CRS108). You can remove any fields from the CRACC field group that you do not want to be available as dynamic objects. Dynamic objects enable you to follow up and analyze costs based on factors other than accounting IDs.
An example of a dynamic object is item type. By inserting this dynamic object in an accounting dimension in the accounting rule, the ID of the particular item type in question is saved automatically in the accounting string of the account entries created based on that accounting rule.
Assign Accounting Strings to Accounting Rules
After the dynamic objects are downloaded, the empty accounting rules are displayed with their respective start date in (CRS395/B). You can assign an accounting string to each combination of accounting rule and start date. On the E panel, two columns of empty fields are displayed.
Left-Hand Column: Fixed Accounting IDs
The left-hand column consists of one field for each accounting dimension in the standard accounting string. The fields are reserved for fixed accounting IDs, that is, accounting IDs registered in 'Accounting Identity. Open' (CRS630). The top field – accounting dimension 1 – is always reserved for the account itself.
Tip: Use the seventh accounting dimension to enter the ID of the accounting rule (for example, AR30-130). This ID is then stored in that accounting dimension for each account entry created based on that accounting rule. This helps identify the accounting rules during troubleshooting.
Right-Hand Column: Dynamically Retrieved Values
The right-hand column consists of fields for accounting dimensions 2 to 7. This column is reserved for values other than fixed accounting IDs. Which values – dynamic objects – are available vary from accounting rule to accounting rule. If you use dynamic objects, you leave the corresponding fields in the left-hand column blank.
There are two categories of dynamic objects: 1) objects that represent a field in a table, and 2) non-field objects. Only objects that belong to the former category can be generated into and stored in the accounting string. Non-field objects are only used to define exceptions (see below).
Example of Dynamic Objects in Accounting String
We assume that the second accounting dimension in the company's accounting string is reserved for cost center and the third for product group. The accounting rule to define is OI20-120 (Revenues from customer order invoicing).
By entering dynamic object CKSDST – which is the field that represents the district in the customer master file – in the accounting dimension for cost center in the right-hand column, the cost center is retrieved from the District field in 'Customer. Open' (CRS610/F) and saved in the accounting string of the revenue account entry when invoicing a customer.
By entering dynamic object MMITGR – which represents the item group in the item master file – in the third accounting dimension, the product group is retrieved from the 'Item group' field in 'Item. Open' (MMS001/F).
Define Accounting Rule Exceptions
Since you might need different accounts for different occasions, the standard accounting rules with their fixed accounting IDs are sometimes insufficient for effective follow-up. For example, you might want to use a different revenue account for non-domestic invoicing of customer orders. In (CRS395/F) you define such exceptions to the rule based on one or more fields (dynamic objects) in various tables. For each exception you can define a different accounting string.
The exceptions are defined using lines in a matrix in (CRS395/F). Each line can consist of up to five fields. Different fields are available depending on the accounting rule and are displayed when you press F4 in one of the exception fields.
In (CRS396) you then determine the valid values for every field and the different accounting string to apply for them. For example, you can apply a different accounting string for a specific range of districts. All valid values will have to be fulfilled to trigger the new accounting string.
You can define exceptions in several steps by using more than one exception in (CRS395/F). If M3 does not make a match on the first step, it will try to fulfill the definition on the next step. For example, if there is no hit on a district, you may want to look at the value in the item class field in the item master table. The priority you selected for each line determines the order in which M3 tries to match the exception.
An asterisk is displayed in (CRS395/B) for accounting rules with one or more exceptions.
Instead of using a regular account for normal transactions in the accounting string in (CRS395/E) and defining exceptions in (CRS395/F) and (CRS396), many companies switch these steps. Companies use a special error account in (CRS395/E) – originally intended for the "normal" account – for all unacceptable account entries. An error account is an account that is labeled as blocked in 'Accounting Identity. Open' (CRS630/E). They then cover all acceptable situations in which account entries can be created in the exceptions part. An account entry would then only be created for the error account when a situation occurs outside the scope of the approved exceptions. Since the error account is blocked, the incorrect transaction is placed in 'Transaction Work File. Restart Erroneous Jobs' (GLS037) before the general ledger is updated. This helps alert the financial department at an early stage that someone is not complying with the approved process.
Define Additional Settings for Dynamic Objects
If an accounting rule has exceptions defined but none matches the transaction in question, either the standard accounting string defined in (CRS395/E) is used or the account entry is labeled with an error code. You define in 'Settings – Accounting Error Methods' (CRS736) which procedure to use.
In the same program you define two other values related to the use of dynamic objects:
Define Automatic Replacement of Dynamically Retrieved Values
In 'Field. Update Control Values' (CRS388) you define automatic replacement of dynamically retrieved values. For example, if the company uses the district from the customer master file as the dynamic object in the accounting dimension reserved for cost center, the districts can here be "translated" into cost centers: Districts 100 and 101 will be replaced automatically by cost center AAA, and so on. Note that this replacement does not work retroactively. It is only applied to future account entries.
Simulate Accounting Strings
You can simulate the results of a specific accounting rule in two ways:
In (CRS399/E) the accounting string as it would be for that particular transaction is displayed. You are informed whether the accounting string is based on the standard accounting string in (CRS395/E) or on an exception. If an error is detected, an error code is displayed. You can also combine the two methods by first creating a dummy transaction and then, if an error occurs, use the same transaction when simulating the accounting string.