Presenter: Tejas Kirtane (Aspera Solutions Ltd.) Epicor Users Group Posting Rules Presenter: Tejas Kirtane (Aspera Solutions Ltd.)

Agenda Posting Engine – Overview Posting Engine – Process Stages Why do we need to modify Posting Rules? GL Transaction Types Typical changes made to posting rules What you can do without a consultant? Tips

Posting Engine - Overview The posting process is the core financial functionality within your Epicor application. It first collects financial data and then evaluates this information to create appropriate general ledger (GL) transactions. It provides a unified process for all business transactions, and it is a flexible rule-based system you can modify to define which accounts you want to populate for which amounts.

Book Components Book contains a unique set of financial records created for a specific purpose – like budgeting or alternate currency calculations. A book defines the currency, chart of accounts, and fiscal calendar used to process its financial transactions. It contains the transactions generated by financial activity for the book.

Multiple Books and Posting Engine MAIN Book GBP PARALLEL Book EUR Multiple Books COA Map Posting engine can generate multiple GL transactions (one in each book) out of the single business transaction document. Two ways of producing GL transactions in multiple books: Apply posting rules to the business transaction document. Each book has a separate set of rules that defines how GL transaction will be created in this book. Apply COA mapping between two books so that GL transaction generated in main book flows into the other book. If neither posting rules nor mapping is defined for a book, no transactions will be created for that book.

Posting Engine – Process Stages Stage 1: Business transaction generation Stage 2A: Execute Posting Rules Stage 2B: Map GL Transactions Stage 3: Execute Automatic Procedures Stage 4: Review Posting Process Results

Stage 1: Business Transaction Generation The application creates a business transaction for a specific business event. A business event type is first detected and then an incoming template loads for this event type. The loading process first takes the default structure and then extends it with any modified posting elements (posting codes, functions, and so on) you may have created. Next, the template populates with the business event data. It becomes a business transaction which will be processed during the subsequent posting stages.

Stage 2 – Run Posting Rules The first method (Stage 2A) directly applies posting rules to the incoming business transaction. The second method (Stage 2B) maps GL transactions generated by the posting rules from one source book to one or more target books. GL transactions are not validated (verified) during this stage. They may be unbalanced, may contain invalid accounting segments, or invalid combinations of segments in the account.

Stage 3 – Run Automatic Procedures During this stage, several procedures are applied against un-verified transactions generated in stage 2 in all affected books. When Stage 3 completes, the GL transactions either update the book journals and account balances or are posted to the Review Journal – where you can adjust, validate, confirm, or cancel them.

Stage 3 – Automatic Procedures (continued) Balance Validation – Verifies the transaction total debit equals total credit. Account Validation – Verifies all accounts are valid. Transaction Summarisation – Optional process which runs if GL Transaction Type is set to ‘Summarization’. Automatic Posting of Rounding Differences – Updates both rounded amount and difference amount per each detail line. Self-Balancing Segments – Ensure all self-balanced segments are actually balanced. Final Validations – If a validation rule finds that a transaction is invalid, it either generates a logic error or a warning, depending on the setup of the rule.

Stage 4 – Transaction Review This optional stage occurs when a business transaction produces an invalid GL transaction or when you indicate that valid GL transactions can also post to the Review Journal.

Why do we need to modify Posting Rules? If your chart of accounts uses dynamic segments linked to business entities, you can modify the posting rules to populate the dynamic segment. If your company requires multiple books, like one for tax purposes and another for accounting purposes, you can set up posting rules to reflect the different purposes of these books. Your company may require multiple books to track costs in separate locations having different currencies. Posting rules can be modified to facilitate transactions. If you customise the application, use the posting engine to handle the automatic posting needs of the additional data you enter through these custom programs.

GL Transaction Types Epicor application contains a unique set of GL transaction types which post financial results to reports, trackers, and the general ledger. GL transaction types control the posting processes used by each book, and a posting process uses one or more GL transaction types to generate its financial results. Epicor application installs a series of GL transaction types which record the business transactions created by financial activity in the database. Examples: AP Invoice, AR Invoice, PO Release, COSandWIP, etc.

GL Transaction Type Components Revisions Incoming Document Templates Posting Codes Amounts Rules Book Rules Node Functions Posting Rules Reference Rules Pre-Posting Rules

Revisions Only one revision can be active at a time within the book. You can assign one of three status levels to each revision: Active – Active and in use Draft – Editable Blocked – No longer in use Option to Manually Review Transactions Compare Revisions: You can compare revisions to see the different posting elements and rules between the two versions.

Incoming Document Template (Business Transaction Document) A hierarchical document with unlimited number of hierarchical levels. Each hierarchical level (document level) contains: Child document levels Posting Codes: A collection of business entities having field names and data types. Amounts: Characterised by – Name, Value, Currency Type, Currency, Conversion Date and Calculation method.

Extending the Document Template Adding a field from the Business Entity table Adding a field using a BAQ Any BAQ can be used BAQ supposed to return a single record, but if it returns multiple records only the first will provide data for the document BAQ typically will be a parameterised query, where parameters will be mapped to business transaction document fields BAQ is assigned to a document level and thus it is executed for each instance of document level Creating a new Entity

Interesting Numbers (in Epicor v10.1.500.x) Number of GL Transaction Types = 43 Number of Posting Rules (Booking Rules) = 606 Max number of Posting Rules for a GL Transaction Type = 223 (COSandWIP)

Packages of Posting Rules Standard: Useful for 3 Account Segments (initially used in Vantage 8.03) Extended: Derived from Standard package but do not contain any Division or Department specific logic. CSF – Country Specific Functionality: You should only import CSF posting rules if you have activated the corresponding CSF license for your company. China Colombia Germany Mexico Peru Vietnam

Examples of Posting Rule Mods Most common requirement is to change the transaction description ‘Periodic Posting’ during COS/WIP Postings and provide specific transaction information instead.

Transaction Description Before/After

Chart Tracker & Journal Listing

GL Transaction type: COSandWIP Header Rule is modified Transaction text ‘Periodic Posting’ is replaced with specific transaction information.

Examples of Posting Rules Mod Another common requirement is to modify posting rule to populate dynamic segment when it is linked to a business entity. In this example, Customer is a dynamic segment and the sales/ revenue GL account should record the CustID in the dynamic segement during AR Invoice posting.

AR Invoice Edit List Before/After

GL Transaction Type: AR Invoice Post Code Cust ID created within BillTo Customer

Workshop Demo – AR Invoice CustID – Dynamic Segment Populate the dynamic segment for Sales/Revenue GL Account

Examples of Posting Rule Mods Requirement for PUR-UKN transaction: When raising PO Line for Other (Non Qty Bearing) Part number, let the hierarchy for determining the expense account start from Part GL Control Type instead of Part Class.

PO Release GL Transaction Type

Part – GL Control Type

Workshop Demo – PO Release Purchase Order 4216

What you can do without a consultant? Change the actions for Posting Rule Validations. Book Validations Enable/Disable Transaction Summarisation for a GL Transaction Type. Import / Export Revisions of GL Transaction types into one or multiple companies. Manually Review Transactions Activate or Block particular Revision of a GL Transaction type. View Posting Engine (PE) Log

Posting Rules – Validations Validations define how the application handles rules that create invalid journal details for a book included in a revision.

Posting Rules – Validation Actions Available posting rule validations: Error – Blocks posting of the journal. You can view the journal in Review Journal. Warning – The journal posts, but a warning message displays within the Review Journal. Ignore – The journal posts, but no entry displays within the Review Journal. This action is the default for most posting errors. Autocorrect – Automatically corrects the journal using a pre-defined process. For example, the Autocorrect process changes the apply date for a journal posted to a closed period to the current period. Autocorrect with Warning – Logs a warning in the Review Journal and automatically corrects the journal using a pre-defined process.

Example of Posting Rule Validations Review Journal for Apply Credit Memo transaction Error Message: Transaction amount is zero, but book amount is not zero [Line 2]

Book Validations Defines the overall error handling options for journals posted to a specific book.

Book Validations – Auto correction

Transaction Summarisation Create a new revision by copying the existing revision. Change the summarisation option: Activate the new revision.

Workshop Demo – Import / Export Transaction Type

Manually Review Transactions This causes the application to capture all GL transactions generated by the process and log them in the Review Journal.

Posting Engine Log The Posting Engine Log tracks the results of your posting rules. You can then evaluate how effective the posting rules are processing transactions. The data generated by the posting engine is traced by this log. Log Options: Clear PE File - Click this button to clear the log results. Show Details - Select this check box to display all the posting transaction information recorded by the log. Show Warning on Parent - Select this check box to display posting warnings on parent records. Use Bold Font for Details - Activate this check box to display the transaction details using a bold font.

PE Log Viewer With the PE Log Viewer, you can: • Turn logging on and off • Set detailed logging • Clear the log file • Export or import the log file • Read logging

Tips for creating Posting Rules If you need to copy a posting rule or a set of posting rules, first highlight a node on the Tree View. Then click on the Actions menu and select either Copy Rule or Copy Ruleset. All rules are based on the GL controls. Do not use a single quote ( ` ) in any context. It generates an error. Each selection criterion is case sensitive, so be sure to enter items using the correct case Once a revision is defined as Active, you can no longer change it. Instead, you will need to create a new revision based on the active revision. Only parent-child relationships are available for a GL transaction type. For example, you can use a GL control from the header for use within a line rule. You cannot, however, use GL controls across child to child or from child up to parent. When you create an If-Else condition, make sure this condition displays on the node below the operation you need, and not on the same node level. If you do not, the If-Else condition will not receive the data generated by its parent operation.

Questions?

Thank You