Vous êtes sur la page 1sur 45

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 PARALLEL
Multiple Books Book Book
GBP COA Map EUR

• 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)
1) Balance Validation – Verifies the transaction total debit equals total credit.
2) Account Validation – Verifies all accounts are valid.
3) Transaction Summarisation – Optional process which runs if GL Transaction Type is
set to ‘Summarization’.
4) Automatic Posting of Rounding Differences – Updates both rounded amount and
difference amount per each detail line.
5) Self-Balancing Segments – Ensure all self-balanced segments are actually
balanced.
6) 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

1) Revisions
2) Incoming Document Templates
3) Posting Codes
4) Amounts
5) Rules
6) Book Rules Node
7) Functions
8) Posting Rules
9) Reference Rules
10) 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
o Any BAQ can be used
o BAQ supposed to return a single record, but if it returns multiple records
only the first will provide data for the document
o BAQ typically will be a parameterised query, where parameters will be
mapped to business transaction document fields
o 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.
1) China
2) Colombia
3) Germany
4) Mexico
5) Peru
6) 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?

1) Change the actions for Posting Rule Validations.


2) Book Validations
3) Enable/Disable Transaction Summarisation for a GL Transaction Type.
4) Import / Export Revisions of GL Transaction types into one or multiple
companies.
5) Manually Review Transactions
6) Activate or Block particular Revision of a GL Transaction type.
7) 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

Vous aimerez peut-être aussi