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

2. 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

3. 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.

4. 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.

5. 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.

6. 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

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

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

15. 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.

16. 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.

17. 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

18. 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)

19. 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

20. 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.

21. Transaction Description Before/After

22. Chart Tracker & Journal Listing

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

24. 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.

25. AR Invoice Edit List Before/After

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

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

28. 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.

29. PO Release GL Transaction Type

30. Part – GL Control Type

31. Workshop Demo – PO Release
Purchase Order 4216

32. 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

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

34. 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.

35. 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]

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

37. Book Validations – Auto correction

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

39. Workshop Demo – Import / Export Transaction Type

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

41. 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.

42. 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

43. 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.

44. Questions?

45. Thank You