Configure Accounting Rules Information

[Financial Events and their Bookings] [Control Types per Posting Type]

Basic financial data and sets of rules for IFS Applications are managed in the IFS/Accounting Rules component. This module includes code parts, posting control, and functions for creating a code string, such as code string completion. The common IFS Applications information in the IFS/Accounting Rules module allow unified inspection and automatic functions throughout IFS Applications.

Accounting rules must be defined for each company you establish in IFS Applications.

Creating the Code String

Financial monitoring occurs in connection with certain events in IFS Maintenance:

• Issue material on work order
• Report in time on work order or on route work order
• Receive object into inventory on work order

As a rule, a financial event in the system usually creates one debit and one credit posting. Each debit and credit posting is created based on posting types.  See the Posting Types section for more information about posting types. You can also see the control types that you can use in the Control Types pre-posting section.

When the system creates postings for a financial transaction, it uses the rules in the IFS/Accounting Rules module in following the order:

1. Posting control (IFS/Accounting Rules)
2. Code string completion (IFS/Accounting Rules) 
3. Pre-posting (IFS Maintenance)

The Work Order section in Financial Events and their Bookings page lists the financial transactions that can occur in IFS Maintenance, and what posting types are used..

Posting Control

The IFS/Accounting Rules module contains a set of rules called posting control, which helps you to control how your posting will look and what will affect it. The central concepts in posting control are posting types and control types.

Posting Types

The posting types that you link to the financial event are the terms for which you create posts. Posting types are registered in IFS/Accounting Rules. Here, you specify how you want the code string for the posting type to be controlled.

You can register posting control for up to 10 code parts for all posting types. The posting types, i.e., credit and debit posts that are installed with IFS Maintenance (depending on which components you have installed) are shown in the following table.

Control Types

In posting control in IFS/Accounting Rules, you specify what posting types you will use (see above for posting types in IFS Maintenance), what code parts should be used for the posting type, and what control types should be used to retrieve the correct code part value when a transaction occurs.

For each posting type, there are several control types available. The control types are usually different kinds of basic data, which is used to determine the value a certain code part should receive in a transaction. For example, you can specify that a certain cost center (code part and code part value) should be burdened for the expense transaction, depending on what maintenance organization (control type) is reporting in time (posting type) on a work order.

When you have defined the control types that are valid for which posting types, you can map the control type values (basic data values) to code part values. You can, for example, specify that maintenance organization Maint corresponds to Cost center 110.

When you define the control types and control type values, there are two ways of using default values. You can either use a default code part value or a fixed default value. If posting is always to be done on the same code part, enter a fixed value as the control type. The default value defined for the posting type will then always be used as the code part value (unless overwritten by pre-posting). If you use a default code part value (i.e., not a fixed value), the value is only used if you do not enter a control data value. You can use default values for all posting types in IFS Maintenance.

In IFS Maintenance, you can define accounting rules for all posting types defined above, except for T50 and T51. For T50 and T51, you should only use control type AC2 (Pre accounting) or Mandatory pre-posting. By defining AC2 for the various code parts, you define the code parts that can be pre posted on a work order. If Mandatory pre-posting are used on any code part then it is mandatory to have a value to perform a transaction.

Pre-posting

If for some reason, the posting control is not flexible enough to meet your needs, or it is not possible to define a rule for how something should be posted to GL, you can use pre-posting. Pre-posting allows you to manually define code part values for a transaction.

• Pre-posting – In pre-posting, a code part value can be manually entered but is not required. Pre-posting can be used for work orders, issue of material on work order, purchase requisitions, purchase order headers, purchase order rows, customer order headers, and customer order rows. These values are validated against the code parts in IFS/Accounting Rules.

Pre-posting of Work Orders

In order to pre post a work order, you need to set up Posting type T50 (separate work order) and T51 (route work order), and define what code parts can be pre posted on by defining one or several control types for these posting types.

On a work order, you will be able to define code part values for the code parts you have made available for pre-posting. The pre-posting information will be used when time is reported against the work order. The pre-posting information is also used for material issue on the work order, purchase requisitions (created on the work order after the pre-posting information was added on the work order), and customer order lines (when transferring posting lines to a customer order in IFS/Service Management). The pre-posting information from the work order can be manually overwritten on the work order's material requisition (header or line), purchase requisition, and customer order line (see below).

Posting Information Automatically Inherited from a Work Order

It is important to note that the code part values used/defined on the work order (defined for T1 or defined as pre-posting) will be automatically inherited by the work order's material requisition (header and line), the work order's purchase requisition and the customer order lines created from the work order. To overwrite any of these values, you need to make sure that the necessary posting types are correctly defined:

• If you would like to overwrite the default posting information on the work order's material requisition (header or line), you need to make sure that Posting Type M50 is set up for each code part (control type) you would like to manually update.
• If you would like to overwrite the default posting information on the work order's purchase requisition line, you need to make sure that Posting Type M100 (Pre accounting purchase) is set up for each code part (control type) you would like to manually update. To overwrite the default value, you must go to the purchase requisition in IFS/Purchasing.
• If you would like to overwrite the default posting information on the customer order line created from a work order's posting line (IFS Applications for Service Management), you need to make sure that Posting Type M104 (Pre accounting customer order row) is set up for each code part (control type) you would like to manually update. To overwrite the default value, you must go to the customer order in IFS/Customer order. Note that the information from the work order will overwrite any rules defined for M30 (VAT Sales) and M28 (VAT free sales)

Code String Completion

Code string completion is used to add more parts to the code string based on the code part value. You can specify code string completion for all code parts. The code string will be supplemented with the values you enter for the other code parts linked to the code part value. For example, a certain object group is connected to a certain cost center through the code string completion function.

For each posting type and code part, you must specify if code string completion should override the value that posting control has assigned the code part.

Validating the Code String

When a code string is created according to the rules above, it must be checked for information, such as validity interval. The code string is validated in the following order:

1. Validity on the code part level (IFS/Accounting Rules)
2. Code part requirements (IFS/Accounting Rules)
3. Combination control (IFS/Accounting Rules)

Validity on the Code Part Level

In the basic data windows in IFS/Accounting Rules, specify the validity interval of each code part.

Code Part Requirements

Code part requirements indicate how other code parts in the code string may be used with an account. The requirement can be Can, Mandatory or Blocked. You enter code part requirements per account in IFS/Accounting Rules; they are default depending on the account type you specify when you enter accounts.

Combination Control

The rules for combination control are found in IFS/Accounting Rules. Combination controls define the combinations of code parts that are allowed or blocked for each user group. It is possible for a given combination of code parts to be legal and illegal at the same time. The illegal combination is always dominant.

Error Handling

When maintenance transactions are created the postings will be validated against the accounting rules. If there are any errors the status of the specific accounting line will be set as Invalid for the particular transaction. 

The Transfer Maintenance Transaction function will check if both debit and credit accounting lines are valid for a particular transaction owned by IFS/Maintenance. If both accounting lines are valid the function will create vouchers for those lines in IFS/General Ledger. Accounting lines that contain errors will be skipped at this stage.

Usually, the errors are due to erroneous code string completion, code part requirements, combination control, or invalid code part values. Once the corrections are made to the accounting rules or the pre-posting values you can perform the Rerun Erroneous Maintenance Postings function in order to update the erroneous transactions with the correct financial information.

 It is strongly recommended  that you check the transaction history and perform the Rerun Erroneous Maintenance Postings function frequently, since this will make it easier to identify any erroneous accounting rules settings that will prevent you from successfully creating vouchers. 

For material issues on a work order a different method for error handling is used. Creating vouchers for work order issues is handled in the Transfer Inventory Transactions dialog box in IFS/Inventory. If an error occurs, the creation of vouchers is stopped for that particular transaction. To check if the transactions resulted in any erroneous postings zoom on the transaction identities of the posting lines. The status of the accounting lines will be set as Invalid if any errors exist. The adjoining field displays a description of the error. When you have corrected the rules, you can rerun the incorrect posting in the Rerun Erroneous Distribution and Manufacturing Postings window.