Neral Ledger
Neral Ledger
Neral Ledger
Disclaimer
This document is for informational purposes only and is subject to change without notice. This document and its
contents, including the viewpoints, dates and functional content expressed herein are believed to be accurate as of its
date of publication. However, Epicor Software Corporation makes no guarantee, representations or warranties with
regard to the enclosed information and specifically disclaims any applicable implied warranties, such as fitness for a
particular purpose, merchantability, satisfactory quality or reasonable skill and care. As each user of Epicor software is
likely to be unique in their requirements in the use of such software and their business processes, users of this document
are always advised to discuss the content of this document with their Epicor account manager. All information contained
herein is subject to change without notice and changes to this document since printing and other important information
about the software product are made or published in release notes, and you are urged to obtain the current release
notes for the software product. We welcome user comments and reserve the right to revise this publication and/or
make improvements or changes to the products or programs described in this publication at any time, without notice.
The usage of any Epicor software shall be pursuant to an Epicor end user license agreement and the performance of
any consulting services by Epicor personnel shall be pursuant to Epicor's standard services terms and conditions. Usage
of the solution(s) described in this document with other Epicor software or third party products may require the purchase
of licenses for such other products. Where any software is expressed to be compliant with local laws or requirements
in this document, such compliance is not a warranty and is based solely on Epicor's current understanding of such laws
and requirements. All laws and requirements are subject to varying interpretations as well as to change and accordingly
Epicor cannot guarantee that the software will be compliant and up to date with such changes. All statements of
platform and product compatibility in this document shall be considered individually in relation to the products referred
to in the relevant statement, i.e., where any Epicor software is stated to be compatible with one product and also
stated to be compatible with another product, it should not be interpreted that such Epicor software is compatible
with both of the products running at the same time on the same platform or environment. Additionally platform or
product compatibility may require the application of Epicor or third-party updates, patches and/or service packs and
Epicor has no responsibility for compatibility issues which may be caused by updates, patches and/or service packs
released by third parties after the date of publication of this document. Epicor is a registered trademark and/or
trademark of Epicor Software Corporation in the United States, certain other countries and/or the EU. All other
trademarks mentioned are the property of their respective owners. Copyright Epicor Software Corporation 2012.
All rights reserved. No part of this publication may be reproduced in any form without the prior written consent of
Epicor Software Corporation.
ED901905
90521-905-8798-583701
9.05.701
Revision: September 26, 2012 5:42 p.m.
Total pages: 81
course.ditaval
Contents
Contents
Advanced General Ledger Course.........................................................................................7
Before You Begin....................................................................................................................8
Audience.........................................................................................................................................................8
Prerequisites....................................................................................................................................................8
Environment Setup..........................................................................................................................................8
Workshop Constraints..............................................................................................................................9
Overview...............................................................................................................................10
Daily Advanced General Ledger Processing.......................................................................11
Advanced General Ledger Topics...................................................................................................................11
GL Transaction Type Maintenance..........................................................................................................11
Revision Control..............................................................................................................................12
Revisions..................................................................................................................................12
Active Mode.............................................................................................................................14
Workshop - Add a Revision......................................................................................................14
Manual Review................................................................................................................................15
Workshop - Review Transactions in the Review Journal.............................................................15
Incoming Document Templates.......................................................................................................16
Selection Criteria.............................................................................................................................17
Posting Codes.................................................................................................................................17
Posting (Booking) Rules...................................................................................................................18
Operations...............................................................................................................................19
Functions.................................................................................................................................20
Workshop - Copy and Delete Posting Rules..............................................................................21
Multiple Books........................................................................................................................................22
Book Maintenance..........................................................................................................................23
Retained Earnings.....................................................................................................................24
Validations...............................................................................................................................25
Rounding Differences...............................................................................................................26
Source Book.............................................................................................................................26
Book Detail..............................................................................................................................27
Workshop - Create a General Ledger Book......................................................................................27
Workshop - Set Up Posting for Multiple Books in GL Transaction Type Maintenance........................28
Add a Book to the AR Invoice Revision.....................................................................................28
Use Mapping............................................................................................................................28
Workshop - Post a Transaction to Multiple Books.............................................................................29
Activate Manual Posting for Revision........................................................................................29
Enter an AR Invoice..................................................................................................................29
Review Transactions.................................................................................................................30
Workshop - Link to a Source Book with a Different Book Currency..................................................30
Add a Book..............................................................................................................................30
Contents
Contents
Contents
Conclusion.............................................................................................................................79
Audience
Specific audiences will benefit from this course.
CFO/Controller
Accountant/Financial Specialist
AP Manager
AR Manager
Payroll Manager
System Administrator
Prerequisites
In order to complete the workshops in this course, all necessary modules must be licensed and operating in your
training environment. For more information on the modules available, contact your Epicor Customer Account
Manager at [email protected]. It is also important you understand the prerequisite knowledge contained
in other valuable courses.
General Ledger Course - This course provides a clear perspective of the maintenance programs, concepts,
processes, and reporting tools you encounter as you work within the General Ledger (GL) module.
Posting Engine - This course provides an overview of the posting process concept for the Epicor application
and the Posting Engine as the technology to implement this process. In addition, the course discusses how
the posting engine provides flexibility and control over the financial transaction creation process in the Epicor
application.
Environment Setup
The environment setup steps and potential workshop constraints must be reviewed in order to successfully
complete the workshops in this course.
Your Epicor training environment, in which the Epicor demonstration database is found, enables you to experience
Epicor functionality in action but does not affect data in your live, production environment.
The following steps must be taken to successfully complete the workshops in this course.
1.
Verify the following or ask your system administrator to verify for you:
Your Epicor training icon (or web address if you are using Epicor Web Access) points to your
Epicor training environment with the Epicor demonstration database installed. Do not complete
the course workshops in your live, production environment.
Note It is recommended that multiple Epicor demonstration databases are installed. Contact
Support or Systems Consulting for billable assistance.
The Epicor demonstration database is at the same service pack and patch as the Epicor
application. Epicor's education team updates the Epicor demonstration database for each service pack
and patch. If your system administrator upgrades your Epicor application to a new service pack or patch,
he or she must also download the corresponding Epicor demonstration database from EPICweb > Support
> Epicor > Downloads and install it. If this is not performed, unexpected results can occur when completing
the course workshops.
Your system administrator restored (refreshed) the Epicor demonstration database prior to
starting this course. The Epicor demonstration database comes standard with parts, customers, sales
orders, and so on, already defined. If the Epicor demonstration database is shared with multiple users
(that is, the database is located on a server and users access the same data, much like your live, production
environment) and is not periodically refreshed, unexpected results can occur. For example, if a course
workshop requires you to ship a sales order that came standard in the Epicor demonstration database,
but a different user already completed this workshop and the Epicor demonstration database was not
restored (refreshed), then you will not be able to ship the sales order. Epicor's education team has written
the course workshops to minimize situations like this from occurring, but Epicor cannot prevent users
from manipulating the data in your installation of the Epicor demonstration database.
2.
Log in to the training environment using the credentials manager/manager. If you are logged in to your
training environment as a different user, from the Options menu, select Change User.
3.
From the Main menu, select the company Epicor Education (EPIC06).
4.
5.
SonicMQ must be installed and operational in the same environment as your Epicor ERP training database,
and the SonicMQ DomainManager and SonicMQ Broker (or SonicMQ Container) must be started. For
assistance, contact your System Administrator or refer to the Multi-Site Technical Reference Guide section
- Verify SonicMQ Broker Status. This guide is accessible from the Application Help.
6.
Schedule the Multi-Company Server Process in the demonstration database. For assistance, contact your
System Administrator or refer to the Epicor ERP Install Guide section - Schedule the Multi-Company Server
Process - which is available for download on the EPICweb.
7.
Start the Multi-Company Server Process for the demonstration database. For assistance, contact your
System Administrator or refer to the Epicor ERP Install Guide section - Start the Multi-Company Process.
Workshop Constraints
All workshops in this course can be performed only once in each instance of a restored (refreshed) database. If
a user has already completed these workshops in the database, the database must be restored (refreshed) before
another user can complete this course.
Overview
Overview
A company's general ledger (GL) is the main repository for financial information. The GL processes and posts
entries created by all interfaced modules, such as Inventory Management, Accounts Receivable, Accounts Payable
and Payroll. Manual and multi-company journal entries can also be made directly to the GL.
In the Epicor application, the posting process first collects financial data and then evaluates this information to
create appropriate GL transactions. The "behind the scenes" functionality which runs this process is called the
Posting Engine.
The Posting Engine functionality runs independently for each company within the Epicor application. If a company
has multiple books defined for specific financial requirements, each book can have a unique set of posting rules
defined. Posting rules indicate how and when all business and GL transactions post to various accounts.
Use multiple GL books to display the same financial information in multiple contexts. Multiple books are useful
if you need to report and analyze the same financial business transactions in different ways, including in multiple
charts of accounts, currencies, methods of accounting, and fiscal calendars.
As transactions occur within a company, create consolidated financial statements to report on all companies or
books at once. Consolidation is the process of rolling up GL transactions and balances from one or more child
company to the parent(s). Accounting data is consolidated for subsidiary accounts mapped to parent accounts
that are active for a specific fiscal period.
The Epicor application's Multi-Site module provides support for centralized accounting and purchasing,
intercompany trading, and the separation of production facilities. Multi-company consolidation can be set up
between all or some companies in the database. Companies outside the application can also complete financial
rollups.
Use the GL Advanced Allocation module to disburse amounts booked to the GL into a more detailed and specific
representation. The Advanced Allocations module reviews how to set up, generate, simulate, and view different
types of allocations.
10
11
contexts for later processing. Pre-posting rules define the defaults used when you manually enter general
ledger accounts.
Important If you modify or delete posting rules, it can cause the Epicor application to generate invalid
journals. Display results in the Review Journal to ensure new and modified posting rules create valid
transactions. You should also first run your modified rules on a test server so that you avoid the risk of
posting invalid journals to the general ledger. For more information on how to create and edit posting
rules, review the Posting Engine Technical Reference Guide. This guide also contains a reference section
which documents the extended set of posting rules. It is available in the application help; use the help
Table of Contents and navigate to the General Ledger > Working With section.
Note that you cannot create a new transaction type. Instead, add a new revision to an existing transaction type.
You can assign revisions to different books. Each book has settings that also affect the posting process. These
settings include the chart of accounts, fiscal calendar, and currency the book uses. The general ledger control
used by the posting process defines the accounts that posting rules use. You can set up the posting rules in one
book and then use these same rules in another book.
Example You define a rule for a journal which generates when a sales order posts. The rule obtains the
warehouse ID for the inventory sold and sets the value of a dynamic segment based on the ID.
Menu Path
Navigate to this program from the Main Menu:
Financial Management > General Ledger > Setup > GL Transaction Type
Important This program is not available
in the Epicor Web Access interface. You can launch this program
Revision Control
The Epicor application contains default revisions which use the elements (posting codes, functions, and amounts)
and posting rules the posting process requires.
You cannot change the installed posting rules and elements to control changes to the posting processes. You
can only change and delete new revisions you create.
The Epicor application also prevents an upgrade revision (typically installed through a service pack) to overwrite
an active, modified revision. You can therefore compare the upgrade revision to your modified revision and
change the upgrade revision as necessary. You can then change the upgraded revision's status to Active.
Revisions
To modify transaction types, you create revisions. Only one revision can be active at a time within the book. As
an option, you can activate and block different revisions depending upon an Apply Date value, so you can set
up a series of revisions to run in a scheduled sequence you define. You can either create a new revision by copying
the existing posting rules, or you can create an entirely new revision which contains no posting rules and create
the posting rules you need.
You can add or update many items within each revision; you can modify posting codes, pre-posting rules, posting
rules, reference rules, functions, book variables, rules variables, operations, and so on.
You can assign one of three status levels to each revision. Each status defines the current state of the revision.
Assign the status on the Revisions > Revision Detail sheet. The Status field has the following options:
Active - The revision the application currently uses to post GL transactions for the GL transaction type. The
revision is in use, processing GL transactions for all books assigned to it. Only one revision can be active at a
time for each GL transaction type and you cannot modify an active revision.
12
Draft - A revision you are currently modifying; this status is the default when you create a new revision. For
as long as the revision stays in the draft status, you can edit it. Once you change its status to Active or Blocked,
it can no longer be updated.
Blocked - A previous or alternate revision which is no longer in use. The application does not use this revision
to generate GL transactions for the current GL transaction type. Although you cannot modify a blocked
revision, you can change its status back to active and use it to post again. Blocked revisions are also used as
a reference to compare against the active and draft revision(s).
Use different revisions to model and test changes in the accounting logic for each transaction type. For example,
your company uses posting rules to set values for a dynamic segment that defines a product line. The product
line expires at the end of the year. You create a revision that includes new posting rules which record this change
at the same time.
Tip You cannot delete or modify the installed versions of the GL transaction types. You can only create a
new revision based on the original GL transaction type. If necessary, you can activate the original revision
(which is assigned the blocked status) to restore the original posting process.
Revision Options
In addition to creating a new revision and assigning it a status, you can perform the following actions:
Review All Transactions-- When you select the Manually review all transactions check box, you activate
the manual review option. This causes the application to capture all GL transactions generated by the process
and log them in the Review Journal. Epicor recommends you select this option while you are creating and
testing a revision; after you are satisfied with the results, be sure to clear this check box option so the Review
Journal only captures errors and warnings.
Schedule Different Revisions-- Changes in revisions can reflect changes in accounting processes. You can
indicate when a specific revision becomes active by entering a date within the Effective Revision Date
(From) field. When the system clock advances to this date, this revision becomes active and the previous
revision becomes blocked. The current revision then stays active until the system clock moves to a future
effective date on another revision. In this way, you can schedule a series of revisions to become active as you
need.
Upgrades and Revisions
When you upgrade the Epicor application through a service pack or patch, your custom revisions are not overridden.
The upgrade process first reviews the revision numbers; if it finds that a user modified revision is active for a GL
transaction type, it does not change it. An active revision only upgrades if it is the original default revision installed
with the application.
Instead, the installed default revisions are automatically assigned the blocked status. You can then review the
blocked version to see if any updates are needed to your modified revision. If you wish, you can then add your
modifications to the new default revision and assign it the active status.
Updates are always automatically installed for both the Standard and Extended packages of rules.
Compare Revisions
Before you make changes to a revision, you can compare revisions to see the different posting elements and
rules between the two versions. To do this, click on the Actions menu and select Compare Revisions. Use this
window to review the differences between the revisions.
13
Active Mode
The Epicor application supports two modes of active revisions.
Define which mode you want on the Accounting Transaction Type sheet:
Always a Single Active Revision - This GL transaction type can only have a single active revision available
at any time for the posting process.
Select an Active Revision by Date - The GL transaction can have several active revisions available through
a schedule you define. In this mode, each active revision must have an Effective Revision Date (From) value.
Use this date to indicate when this active revision is specifically used during the posting process. This field is
available on the Revision > Revision Detail sheet. When the system clock moves to the date value defined
on the next active revision, the application automatically sets the status of the previous active revision to
Blocked.
Example The company uses posting rules to set values for a dynamic segment which tracks a product
line. The product line expires at the end of the year. You set a revision that includes new posting rules to
take effect at the same time.
14
Manual Review
Use GL Transaction Type Maintenance to activate the manual review functionality.
Typically, valid transactions automatically post to the general ledger (GL) without review. You can indicate that
you want to review all GL transactions before they post. It is best to leverage this feature when you activate a
new revision. A manual review of the transactions can help identify errors that can occur during the posting
process of a revision.
To activate the manual review functionality, navigate to the Revisions > Revision Detail sheet and select the
Manually review all transactions check box.
When you use the manual review feature, all GL transactions post directly to the Review Journal, where you can
review the transaction line details. From there you can use the Actions menu to confirm, adjust, or cancel each
GL transaction.
Enter an AR Invoice
Navigate to AR Invoice Entry.
Menu Path: Financial Management > Accounts Receivable > General Operations > Invoice Entry
1. From the New menu, select New Group.
2. In the Group field, enter XXXGroup (where XXX are your initials).
3. From the New menu, select New Miscellaneous Invoice.
The Header > Detail sheet displays.
4. In the Sales Order field, enter 5120 and press Tab.
5. From the New menu, select New Line.
The Line > Detail sheet displays.
6. In the SO Line/Rel field, search for and select the line that displays.
7. Click Save.
Epicor ERP | 9.05.701
15
16
Templates can combine predefined and custom elements. Predefined elements ensure support for the transaction
type's posting processes. You cannot change or delete predefined elements. You can add custom elements to
provide attributes needed by any new or modified posting rules. You can also modify and delete your custom
elements.
The posting rules for a revision use information from the template elements to define journal details. These rules,
except for the reference rule, determine the detail amount, the account to which the detail posts, and whether
the amount debits or credits the account. The reference rule is used to set up and populate a reference GL control
with no direct relation to posting any amounts or selecting debit and credit accounts.
Each incoming document template contains the following elements:
Document Lines - Document lines group elements obtained from a portion of the posted transaction. For
example, an accounts receivable invoice template contains document lines for the invoice header, invoice line,
tax line, and miscellaneous charge line.
Posting Entities - Entities group related posting codes together. An entity holds a posting code collection
and provides default settings used to populate fields.
Posting Codes - Posting codes define the parameters used with posting rule operations and functions. Posting
rules use posting code values to create journal details. You can add posting codes and modify and delete the
codes you create. Posting codes are grouped under a parent posting entity.
Amounts - Amount elements hold the transaction amounts used by calculated fields.
Selection Criteria
In GL Transaction Type Maintenance, selection criteria are statements which return specific data from the posting
codes on the revision. The posting rules then use the data to create accounts used in journal details.
The incoming document template contains posting codes unique to its process. The posting codes are grouped
by posting entities and the entities are then grouped by the document lines from the business transaction (incoming
document template).
You can create or update selection criteria to return the posting code data required by a rule. For example, you
want to define a rule which posts an invoice amount to an account segment based on the Warehouse ID. The
incoming document template contains an invoice line element which has the warehouse posting entity which
contains the posting code required for each warehouse. You select Invoice Line in the For Each field and use the
other field in the sheet to create a statement that selects the correct posting code. The result resembles a WHERE
clause in a SQL statement. You then click Add to include the statement in the Selection Criteria field. You use
the And, Or, and Not buttons to insert logical operators into the statement.
Selection criteria can only pull in data from parent tables. Any information stored in child tables cannot be pulled
in by using selection criteria from the parent. You must create or modify a posting rule which pulls in data directly
from the child table.
Posting Codes
To add posting codes, you define settings that control how the revision retrieves data used for its posting rules.
These rules includes defining the data source for the posting codes. The application obtains data for posting code
fields by using:
Entity Fields-- Business entities (do not confuse these items with posting entities) are static database tables
like Part, Customer, and Supplier which contain data a business transaction requires. Because of this, you can
specify a field in the same table to access data in the business entity field.
Business Activity Queries (BAQs)-- You can pull in more detail into the revision by linking a business activity
query (BAQ) to an incoming document template. The revision then uses selection criteria defined for a posting
rule to obtain data pulled in by the BAQ. The interface can return a value from a single field or a calculated
sum of fields.
17
18
You can use this rule to assign default values to GL journal detail fields, but you can also override these values
in the posting rules. For example, you can initiate transaction text in the header rule but then override this text
in a posting rule which generates later.
To add a new header rule, add a new posting rule and select its Header check box.
Posting rules, together with a header rule, create a GL transaction.
Pre-Posting Rule
Pre-posting rules create a GL control with a determined account. Use this feature in certain programs to provide
a default account before the actual transaction document posts.
Each pre-posting rule is called individually. They do not produce GL journal details.
To add a pre-posting rule, from the New menu, select New Pre-Posting Rule.
Example A pre-posting rule creates the default expense account for the miscellaneous line on a purchase
invoice.
Reference Rule
The Reference Rule supports correspondence accounting by generating strictly bi-line GL transactions. This rule
functions similarly to the pre-posting rules. The reference rule is used only to populate a GL control and it does
not populate any amounts or debit/credit accounts. Correspondingly, this rule type does not create GL journal
details. However, unlike pre-posting rules, the reference rule is run during the normal posting process and has
a property that indicates the specific posting entity to which the outgoing GL control is attached.
To add a pre-posting rule, from the New menu, select New Reference Rule.
Functions
Each function is an algorithm that pulls in data common to the posting rules within the GL transaction type. All
other rules and functions share it. You can create, modify, and delete functions as necessary. When you add or
modify a function, you extend the operations list available to the posting rules.
To add a new function, from the New menu, select New Function.
Operations
Use GL Transaction Type Maintenance to add, modify, and delete rule operations.
The Revisions > Book > Booking Rules > Operations sheet has three sections:
Summary
Type
Options
19
Summary
This area displays operations available for the posting rules.
Type
Use these radio buttons to indicate whether the type is an Operation or a Logical Condition. An operation is
an algorithm which calculates a value or values; a logical condition uses If, Then, or Else commands to determine
how the data processes as it moves through the operation algorithms. Select the type you need; these options
change what displays in the Options section.
Options
This section contains two fields whose values reflect the selected operation type.
If you select the Operation option, the Field Name and Formula fields display. The list of fields (Field Name)
available for an operation depend on the GL transaction type and the posting rule details. The Formula field
contains a rule template with variables. The black text is a rule instruction you cannot change. The blue
underlined text is modifiable. Click on this text and select the variable value you need.
If you select the Logical Condition option, the Logical Condition and Formula fields are available. The
logical condition list includes Else, Else If, and If. Just like the Operation option, the Formula field contains
a rule template with variables. The black text is a rule instruction you cannot change. The blue underlined
text, however, is modifiable. Click on this text and select the variable value you need.
Functions
Functions are standard packages of posting rules which contain functionality common across the posting rules
within a revision. They include the rules required to populate account segments for natural accounts, divisions
and departments.
When you install or update the Epicor application, functions are included as part of each GL transaction type
revision.
Typically each function contains a series of account and journal contexts. When the posting engine processes
the function, it pulls in a complex piece of data and makes this data available to the pre-posting, posting, and
reference rules for the revision. For example, when the AR Invoice transaction type is run, its functions pull AR
account information out of the database to make this information available to the AR invoice posting rules.
Each function is an algorithm that gathers the specific data and the function code which processes the information
into a format usable by the pre-posting, posting, and reference rules. All other rules and functions share the
20
gathered data. You can create, modify, and delete functions as necessary. When you add or modify a function,
you extend the operations list available to the posting rules.
Functions are very useful when you create or update posting rules. You can use functions to avoid writing complex
rules to pull in common financial data. They also help you avoid constantly repeating the GL hierarchy while you
develop posting rules.
System Functions
A list of the system functions is below.
These algorithms define operations common across the GL Transaction Types. Items you can modify are in bold
text.
A=B
Value
Lookup Map name For Field Using arg1, arg2
Lookup COA map name For Segment Using Segment value
Lookup Business Data Using Query Field
Convert Amount To Currency Using Rate Type
End of Period which includes Date
Account is Valid
Account is not Valid
Value is Available
Value is not Available
Get Account From GLControl For Current Book AND Context Context
Get Segment From GLControl For Current Book AND Context Context
Select Amount From Doc Line Where Add Condition
Comment Text
Log Error: Log Error Text
Raise error: Error Description
Log warning: Warning Description
End Rule
Log Debug Message: Log Debug Message
Argument1 and Argument2 is Available
Lookup COA map name Using Account Account
Get Book Amount From GLControl For Current Book AND Context Context
Get External Account From GLControl For Context Context
21
1. In the tree view, navigate to and select AR Invoice > Revision: XXXOp - Draft > Rules > Book:Main
Book > Posting Rules > Post Tax Amount.
In the revision title, XXX are your initials.
2. From the Actions menu, select Copy Rule.
3. From the Actions menu, select Paste Rule.
In the tree view, a Post Tax Amount_1 rule is added to the Posting Rules list.
4. Click Save.
Multiple Books
A general ledger book provides a consistent view of the financials within a specific company. Use multiple books
for financial reporting and analysis of the same business transactions in a variety of ways, including different
charts of accounts by book, different reporting currencies, different methods of accounting, and multiple fiscal
calendars.
When configured to do so, the posting engine can generate GL transactions in every book for every input business
transaction. The GL transaction details depend on the different charts of accounts, currencies, methods of
accounting, and calendars defined for each receiving book.
All GL transactions generate from a single business transaction and each one represents a different view of that
business transaction. Each GL transaction has a reference to the original business transaction as well as the
resulting GL transactions in other books.
Important Use of multiple books in a company requires posting engine revisions. You can manually enter
a revision on every GL transaction type to which you want multi-book postings. This action requires account
mapping or the entry of GL controls for each book you add. Another option you have is in Book
Maintenance. There, you can set up GL transaction mapping from your source book to a secondary book
for multiple GL transaction types at the same time.
Examples of ways to modify and create GL transactions for multiple books:
Apply Chart of Accounts (COA) mapping to the GL transaction type: A mapped COA uses the posting
hierarchy from the original COA's posting rules. You can use COA mapping to modify the posting process
by making small changes to the map to reflect most posting process differences between receiving books.
Mapping provides you with a better alternative for designing posting rules for simple cases.
Apply posting rules to the additional book: You can revise the posting codes, amounts, accounts, functions,
posting rules, and other items the posting process uses for a specific GL transaction type within GL Transaction
22
Type Maintenance. It is common to copy rules from the main book and then adjust as necessary. Using this
method, you must also set up the required GL controls for each book before you can post transactions that
relate to the revised GL transaction type.
If neither posting rules or mapping is defined for a secondary book, automatic transactions will never be created
against that book.
Important The GL multi-book transaction type (MultiGLJrn) includes the standard default set of posting
rules for a single book. The single book is required to be linked to the master chart of accounts (COA) in
order for the rules to work correctly. You can then use this default set of posting rules as a starting point
to build on the rules for your book or for the COA mapping of other books.
For a sample rule, review the custom MultiGLJrn GL transaction type in the Demonstration Database's
Epicor Education company.
Book Maintenance
Book Maintenance defines the fiscal books a specific company uses. A book defines the currency, fiscal calendar,
chart of accounts, and Retained Earnings account used to generate its financial statements.
A company can use multiple books to display the same financial information in multiple ways. When you implement
the Epicor application, carefully consider the role each book plays in the financial management and reporting
within a specific company. When a transaction is entered, its amounts can be applied to multiple books, reflecting
the purpose for each book.
Each book can also have its own set of validation rules. These rules define error handling for journals posted to
a specific book. By default, books ignore most posting errors. You can change the defaults so the book blocks
and logs errors as needed.
Books are useful for recording transactions so they match the financial legal requirements for a specific country.
Use Chart of Accounts Structure Maintenance to create a chart of accounts (COA) which matches the structure
your country requires. You can use one book to post transactions in a specific currency for reporting, and then
use another book for posting the same transactions in the base currency the company uses.
Example Use the Modified Accelerated Cost Recovery System (MACRS) to depreciate a physical asset
for tax reporting. For financial reporting, the same asset is depreciated using straight-line depreciation.
Each book displays its own depreciation results.
Example Leverage multiple books so your companies can value items differently in financial and statutory
reports. An insurance company might use Generally Accepted Accounting Principles (GAAP) to value
investments and other items for one report and use National Association of Insurance Commissioners
guidelines for another book. State or provincial regulations can also impact reporting, so you may need to
implement additional books.
Use Book Maintenance to define the following:
Book Type - Books can record financial transactions or consolidate to other books. Standard books record
the financial activity of the company. Consolidation books mediate the transfer of consolidation journals
between two standard books.
Chart of Accounts (COA) - Each book can have a different COA, or several books can share the same COA.
The COA defines valid general ledger accounts, available dynamic segments, and balance maintenance for
segments other than the natural account. (The natural account maintains continuous balances.) The book
also determines the retained earnings account.
Fiscal Calendar - The fiscal calendar determines valid apply dates for each business transaction. The Epicor
application maintains periodic balances for segments based on the fiscal calendar.
Book Currency - The book currency can be used on financial reportsand in consolidations. All journal amounts
post in the currency defined on the book. Books can store journals in additional transaction currencies, but
will only post in the specified book currency.
23
Error Handling for Journals - Use the Validations sheet to ensure all transactions are valid. For example,
a validation rule can alert you when the Apply Date for a transaction falls within a closed fiscal period. When
the posting process runs, the Epicor application blocks posting of invalid journals and continues to process
the remaining journals in the batch. All error transactions display in the Review Journal.
Rounding Tolerance Criteria - For each book, you can specify rounding tolerance criteria as well as an
account to which transactions will post currency differences.
GL Transaction Mapping - Set up GL transaction mapping from your source (Main) book to a secondary
book. You determine the COA map and transactional currency to use as well as determine which GL transaction
types are affected by this revision.
You can modify a book's details (description, type, COA, calendar, currency) until a journal posts to its COA.
Once a posting process runs through the book, you can only change the book description.
Note You can also update the posting rules each book uses to record general ledger transactions. Update
posting rules for each book within GL Transaction Type Maintenance. For information on how to create
and update posting rules, review the Posting Engine Technical Reference Guide in Application Help.
Menu Path
Navigate to this program from the Main Menu:
Financial Management > General Ledger > Setup > Book
Financial Management > Multi-Site > Setup > Book
Menu Path
Navigate to this program through the Main Menu:
Menu Path: Financial Management > General Ledger > Setup > Book
Retained Earnings
Book Maintenance > Retained Earnings
The Retained Earnings sheet designates the standard account used for retained earnings for the book. The
application continually updates the retained earnings account balance with postings to the COA's revenue and
expense accounts. As a result, the balance sheet always reflects the current balance. At year-end closing, run the
Transfer Balances process to transfer account balances to the next fiscal year.
Balance sheets always report the balance in the standard retained earnings account. You can further divide the
reported retained earnings balance by the substitution of a segment in the retained earnings account for a
corresponding segment in the income statement. The substitution allows the splitting of retained earnings by
division, department, or other mandatory controlled account segment. Account masks designate the relationship
between the split segment and the retained earning accounts that displays the balances.
Often, a book that uses segment substitution also uses self-balancing segments. Designation of a self-balancing
segment in Self-Balancing Segment Maintenance enables the automatic posting of balancing journals within
a segment. This ensures the book to which the journals post maintains a balanced set of records within the
segment.
For example, a book uses a COA with a mandatory second segment that defines two divisions: LA and MP. The
third segment is optional and defines cost centers. You use segment substitution to split the balance in the
standard retained earnings account 3070. At year-end close, the following balances exist in COA revenue and
expense accounts.
24
4010-MP-100
240
4010-MP-200
500
4020-MP-100
100
4020-LA-100
300
3010-LA-100
-500
3010-MP-100
-1200
The application updates the retained earnings account when you transfer opening balances to the new fiscal
year.
4010-MP
3070-MP
740
4020-MP
3070-MP
100
3010-MP
3070-MP
-1200
Total to 3070-MP
-360
4020-LA
3070-LA
300
3010-LA
3070-LA
-500
Total to 3070-LA
-200
Validations
The Validations sheet defines error handling for journals posted to a specific book. By default, books ignore
most posting errors. You can change the defaults, so the book blocks and logs errors.
Define validation rules at the book level; because of this feature, you control how all issues are handled within
a specific book.
The Epicor application handles invalid journals through one of the following ways:
Error - This blocks posting of the journal. You can view the journal in the Review Journal.
Warning - A warning entry displays in the error log, but the journal posts to the general ledger.
Ignore - No entry displays in the error log, and the journal posts to the general ledger. This method is the
default setting for most posting errors.
Autocorrect - The Epicor application uses a pre-defined process to correct the error. For example, for a journal
posted to a closed period, the autocorrect process changes the apply date to the open period.
Warning and Autocorrect - This logs a warning in the Review Journal and automatically corrects the journal.
The following table lists posting errors for existing autocorrect options and describes how the Epicor application
handles each defined error.
25
Error
Autocorrection
The Segment is defined as 'not used' but segment This removes the unused segment and occurs when Account
value is specified (depends on natural account). Segment Values blocks use of the segment with a particular
natural account.
The Closing Period is specified but does not exist. This finds the open period for the book and posts the journal
to that period.
The Apply Date is earlier than the Earliest Apply This changes the apply date of the journal to the first day of
Date.
the first open period.
The Fiscal Period is closed.
This changes the apply date of the journal to the first day of
the first open period.
Note You can use the Business Process Management module to define additional validations.
Rounding Differences
If currency is converted during a posting process, a rounding difference can result in an unbalanced GL transaction.
You can correct unbalanced transactions manually or enable the posting engine to automatically add balancing
lines. To use automatic handling of rounding differences, configure the rounding tolerance criterion and specify
the account to use to post the difference.
Both the tolerance criterion and the account that records rounding difference are defined in Book Maintenance.
When a transaction is unbalanced without any currency conversion, it is due to a logic error or an improper
configuration. If currency is converted, the tolerance criterion is used to decide whether the conversion causes
the difference. The tolerance criterion records if a rounding difference results in an unbalanced transaction and
provides the reason for the difference (for example, logic errors, improper configuration, and currency conversion).
If the rounding difference does not meet the tolerance criteria, the transaction is considered unbalanced and the
posting process fails.
The tolerance criterion defines a maximum amount that can be considered as a rounding difference. The posting
engine uses a debit or credit amount, depending on which value is greater.
Source Book
Use the Source Book sheet to link general ledger accounts used during the posting process, from a source book
to a secondary book.
On this sheet you can determine the COA map and transactional currency to use as well as determine which GL
transaction types you want to be affected by this revision.
Linking secondary books to your source (Main) book allows you to post transactions to multiple books automatically
without having to manually modify any posting rules.
Tip If the books you are linking use the same COA, in the COA Map field select Use Source GL Account.
This tells the posting engine to post transactions to the same GL account in both books without having to
set up GL controls or mapping for the secondary book. If the books you are linking use different currencies,
in the Transactional Currency field you can select to either post to the second book in the document
currency or in the currency of the source book.
26
Book Detail
GL Transaction Type Maintenance > Book > Detail
Once the general ledger book is created, in GL Transaction Type Maintenance, use the Book > Detail sheet to
determine how transactions post to a book.
When you select a book on this sheet, you can define its rules. All rules defined for a single book are a rule set
which generates a complete journal for the book.
Book options you can define include the following:
Determine whether journals are summarized by account when they post to the book. Summarize posted
details to reduce how many records are stored in the database.
Designate whether mapped segments populate book accounts. Chart of Accounts Mapping defines maps
between specific chart of accounts (COA) segments. A map transfers journal details from one book to the
current book. Segment maps reduce the need to define the same posting rules in multiple maps. The application
also converts the currency of the journal when the currencies of the two books are different.
Define functions the posting rules reference in the book's rule set. Reusable functions reduce the time needed
to modify the posting elements and rules. For example, the book might use a COA with a mandatory division
segment. Define a reusable function that obtains a posting code value used to look up and return the segment
value.
Define variables that supply values to the book's posting rules. The posting rules use variables to populate
fields in a business transaction. You can create variables that use any of the data types the posting process
allows. You can use a custom variable to store an intermediate value in order to calculate a field in a new or
modified posting rule.
Tip The document template for the GL transaction type can hold predefined and custom variables. The
posting process controlled by the transaction type uses the pre-defined variables. You cannot delete or
modify these variables.
Data
Book (ID)
Book (Description)
Type
Standard
Chart of Account
Calendar
Book Currency
27
Use Mapping
1. In the Mapping pane, select the Use Mapping check box.
2. In the Mapping from field, select MAIN.
3. In the Using field, verify Use Source GL Account is selected.
28
4. Click Save.
5. Minimize GL Transaction Type Maintenance.
5. Click Save.
6. Minimize GL Transaction Type Maintenance.
Enter an AR Invoice
Navigate to AR Invoice Entry.
Menu Path: Financial Management > Accounts Receivable > General Operations > Invoice Entry
1. From the New menu, select New Group.
2. In the Group field, enter XXXGroup (where XXX are your initials).
3. From the New menu, select New Miscellaneous Invoice.
The Header > Detail sheet displays.
4. In the Sales Order field, enter 5121 and press Tab.
5. From the New menu, select New Line.
The Line > Detail sheet displays.
6. In the SO Line/Rel field, search for and select the line that displays.
7. Click Save.
8. From the Actions menu, select Group > Post.
The AR Invoice Post Process window displays.
29
Review Transactions
Navigate to the Review Journal.
Menu Path: Financial Management > General Ledger > General Operations > Review Journal
1. Click the Journal Entry button.
The Review Journal Entry Search window displays.
2. In the User ID field, enter Manager.
3. Click Search.
4. Double-click the search record line to select it.
5. In the tree view, note the green check marks for both books.
This indicates there are no errors.
6. In the tree view, navigate to and select NNN > Main Book > YYY AR Invoice > Transaction Lines > 1
(where NNN is the Review Journal number and YYY is the AR Invoice reference).
The Transactions > Lines > Detail sheet displays.
7. Review the transaction details for the first line.
8. In the tree view, navigate to and select NNN > XXXs Book > YYY AR Invoice > Transaction Lines > 1
(where NNN is the Review Journal number and YYY is the AR Invoice reference).
9. Review the transaction details for the first line.
10. From the Actions menu, select Journal Entry Confirmation.
The transactions are now posted to both GL books.
11. Exit the Review Journal.
Add a Book
Navigate to Book Maintenance.
Menu Path: Financial Management > General Ledger > Setup > Book
1. From the New menu, select New Book.
30
2. In the Book field, enter XXXLink (where XXX are your initials).
3. In the Book Description field, enter XXX Link Book (where XXX are your initials).
4. In the Chart of Account field, select Master Chart of Accounts.
5. In the Calendar field, select Main Fiscal Calendar.
6. In the Book Currency field, select Mexican Peso.
7. Navigate to the Retained Earnings sheet.
8. In the Standard Account field, enter 3030-00-00 and press Tab.
9. Click Save.
31
32
4. In the Mapping from field, select MAIN as the book from which the journal details are to be copied.
5. Click Save.
6. Navigate to the Revisions > Revision Detail sheet.
7. In the Status field, select Active.
8. Click Save.
9. Minimize GL Transaction Type Maintenance.
33
2. In the Description field, enter XXX MB Journal (where XXX are your initials).
3. Click Save.
4. From the New menu, select New Journal Line.
5. In the G/L Account field, enter 2000-00-00 and click Save.
6. In the enabled Debit field, enter 500.00 and click Save.
7. Click Auto Balance.
8. In the enabled Credit field, verify the default amount is 500.00.
9. In the G/L Account field, enter 6000-00-00.
10. Click Save.
Review Transactions
Navigate to the Journal Tracker.
Menu Path: Financial Management > General Ledger > General Operations > Journal Tracker
1. In the Book field, select XXXs Book (where XXX are your initials).
2. In the Journal Code field, enter GJ and press Tab.
3. On the toolbar, click the Refresh icon.
4. Navigate to the Transaction Detail > Specific > Detail sheet.
The journal transaction you posted in a previous task displays.
5. Update the Book field to Main Book.
6. Click the Retrieve button.
The journal transaction you posted in a previous task displays.
7. Exit the Journal Tracker.
34
GL Account
GL Account Description
Type
1100-00-00
Debit
4910-00-00
Debit
4010-00-00
Credit
The Main Book uses the Master Chart of Accounts which has three controlled segments: Chart, Division, and
Department. The Chart segment has three values: 3000, 1100, and 4010.
In this workshop, create a book that uses the Main COA and use Chart of Accounts Mapping to transfer journals
between the Master COA and the Main COA.
35
Data
Main COA
Map Type
GL Account Map
4. Click Save.
Data
GL Account
TargetGLAccount
3. Click Save.
4. Repeat steps 1-3 and use the data below to create two more account mappings:
Fields
Data A
Data B
GL Account
TargetGLAccount
5. Click Save.
6. Exit Chart of Accounts Mapping.
36
Add a Book
Navigate to Book Maintenance.
Menu Path: Financial Management > General Ledger > Setup > Book
1. From the New menu, select New Book.
2. In the Book field, enter XXXCompany (where XXX are your initials).
3. In the Book Description field, enter XXX Company Book (where XXX are your initials).
4. In the Chart of Account field, select Main COA.
5. In the Calendar field, select Main Fiscal Calendar.
6. In the Book Currency field, verify United States Dollar displays.
7. Navigate to Retained Earnings sheet.
8. In the Standard Account field, enter 3000-02-00 and press Tab.
9. Click Save.
37
Important The GL Transaction Type Maintenance currently displays the MultiGLJrn transaction type. Follow
the steps below to reopen the AR Invoice transaction type.
1. From the tree view, select the active revision.
2. Expand the revision's Rules node.
Both the Main Book and your new book display.
3. Select Book:XXX Company (where XXX are your initials).
The Revisions > Book > Detail sheet displays.
4. Review the Mapping details.
5. Navigate to the Revisions > Revision Detail sheet.
6. Select the Manually review all transactions check box.
7. Click Save.
8. Minimize GL Transaction Type Maintenance.
Enter an AR Invoice
Navigate to AR Invoice Entry.
Menu Path: Financial Management > Accounts Receivable > General Operations > Invoice Entry
1. From the New menu, select New Group.
2. In the Group field, enter XXXGroup (where XXX are your initials).
3. From the New menu, select New Miscellaneous Invoice.
The Header > Detail sheet displays.
4. In the Sales Order field, enter 5120 and press Tab.
5. From the New menu, select New Line.
The Line > Detail sheet displays.
6. In the SO Line/Rel field, search for and select the line that displays.
7. Click Save.
8. From the Actions menu, select Group > Post.
The AR Invoice Post Process window displays.
9. Click Submit and close the AR Invoice Post Process window.
10. Exit AR Invoice Entry.
38
Menu Path: Financial Management > General Ledger > General Operations > Review Journal
1. Click the Journal Entry button.
The Review Journal Entry Search window displays.
2. In the Group ID field, enter XXXGroup (where XXX are your initials).
3. Click Search.
If no records are available for selection, review the System Monitor for Active Tasks. (For information on
how to review the System Monitor, refer to the Application Help). The AR invoice post may take longer to
process this time because of the revised posting rules. Once the group posts, navigate back to the Review
Journal and search for the entry.
4. Double-click the search record line to select it.
5. Expand the tree view.
6. Compare the transaction line details for both books.
To view the transaction line details, in the tree view, click the transaction line number.
7. From the Actions menu, select Journal Entry Confirmation.
The transactions are now posted to the general ledger books.
8. Exit the Review Journal.
39
Data
Name
Customer
Abbreviation
Cust
Maximum Length
10
Minimum Length
Dynamic
Business Entity
Customer ID
Message: Do you want the segment values created when this Response to Message: Yes
dynamic segment is saved?
Segment Value Field
CustID
CustID
4. Click Save.
5. Click OK if a message displays saying some entity codes did not generate segment values.
6. Exit Chart of Account Structure Maintenance.
40
6. Click OK.
The Import Processing window displays to indicate the import completed successfully.
7. In the Import Processing window, click OK.
In the tree view, Revision: 905 Ext - Draft displays.
41
2. From the Posting Rules node, select Post Extended Price Amount (Regular Invoice, Part).
The Revisions > Book > Booking Rules > Operations sheet displays.
3. In the Summary pane, right-click on the line where the following transaction amount is defined.
Transaction Amount = Select Account From AR Invoice--Line Where Name = Extended Price AND
Currency = Transactional.
Note From this operation line, the controlled part of the account is already retrieved using the
hierarchy.
Create an AR Invoice
Navigate to AR Invoice Entry.
Menu Path: Financial Management > Accounts Receivable > General Operations > Invoice Entry
1. From the New menu, select New Group.
2. In the Group field, enter XXX-DM (where XXX are your initials).
3. From the New menu, select New Miscellaneous Invoice.
The Header > Detail sheet displays.
4. In the Sales Order field, enter 5121 and press Tab.
42
Advanced Allocations
Advanced Allocations describe the process of disbursing amounts booked to the general ledger (GL) into a more
detailed and specific representation.
Allocation settings are stored under Allocation Codes. One allocation code contains a set of selection criteria for
source data (either accounts or transactions) and allocation ratios, as well as other parameters that enable
allocation chaining. Unlike the standard GL Allocation functionality, you do not have to manually enter advanced
allocations through manual GL journal entries. The Generate Allocations process automates posting of allocations.
43
Account categories
2.
Journal codes
3.
4.
After applying the selection criteria, each account (or GL transaction that affects each account) that matches the
criteria is allocated.
Offset Account Settings
You have the option to define an offset account for each allocation code. The offset account you select is the
account from which the allocation total will be written off (instead of the source account).
Settings for Target Accounts and Corresponding Allocation Ratio
On each allocation code, enter a fixed list of target accounts (the accounts between which the source total
amount will be divided) and the ratios that define the proportion to divide.
Define target accounts as fixed account codes by entering all segment values. Alternatively, you can inherit some
segment values from the source account.
Define allocation ratios either as fixed values or as formulas. In order to support entry of formulas, a mechanism
for parsing and validating formulas exists. Each formula you enter must consist of basic arithmetic operators and
use the following operands:
1.
44
Fixed values
2.
Balances of specific GL accounts (including accounts other than the source and target accounts)
3.
4.
Formula Parameters
You have the option to define named parameters of the basic arithmetic operand types listed above in Allocation
Code Maintenance. The values you define become the operands. Every parameter of a complex type has its own
individual settings.
Define a single collection of named parameters for each allocation code and use these parameters in any formula
for any of the ratios.
Menu Path
Navigate to this program from the Main Menu:
Financial Management > General Ledger > Setup > Allocation Code
45
46
6. Click Save.
7. From the New menu, select New Journal.
The Journal > Header sheet displays.
8. In the Description field, enter XXX-1 (where XXX are your initials).
9. Click Save.
47
Type
Description
Maintenance40
Non-Financial Data
Maintenance50
Non-Financial Data
48
Lookup Table
Code
Maintenance40
DeptSQFt
SQFT
MACH
Maintenance50
DeptSQFt
SQFT
SERVC
49
Formula Criteria
8000-00-40
8000-00-50
50
51
6. Click Save.
Generate a Schedule
1. From the Actions menu, select Generate Schedule.
The Generate Schedule window displays.
2. In the Fiscal Year field, verify the current calendar year displays.
3. Click Generate.
A message displays and tells you how many schedules were created.
4. To the message, click OK.
5. Navigate to the Allocation Schedule sheet.
Note The current fiscal period is the only period with a status of Scheduled. To schedule additional
periods, in the row of the period you want to update, select the Scheduled check box.
6. Click Save.
7. Remain in Allocation Batch Entry.
Tiered Allocations
The Epicor application supports tiered allocations. Tiered allocations allow you to apply the results of one allocation
to the results of another.
Tiered allocations are set up in Allocation Code Maintenance. Like any allocation code, each code included in
a tiered relationship must have general parameters, source data criteria, and target accounts set.
Settings Specific to Tiered Allocations
The following describes the available parameters for tiering allocations:
Tier Level - This parameter is assigned to the allocation code. When you generate groups of allocations, this
parameter determines the order in which they should generate. The allocations of each subsequent tier are
applied to the results of the previous tier(s).
52
Allocation Stamp - This parameter is a generic alphanumeric code that is stored in a new field in each GL
transaction. Every GL transaction created through standard posting has an empty allocation stamp.
Correspondingly, every allocation code has the following three parameters:
Target Allocation Stamp - This is the allocation mark assigned to the transactions created by this allocation.
Source Allocation Stamp - This is the allocation mark assigned to the transactions processed by this
allocation.
Allocation Stamp - This is the allocation mark to which this allocation should be applied. The following
options are available:
Select the Include All check box to apply this allocation to all transactions previously stamped by a
different allocation.
In the Allocation Stamp field, select an allocation stamp (previously entered as a Target Allocation
Stamp on a different allocation code) to indicate that the current allocation should only apply to
transactions previously marked with the selected allocation stamp.
Select the Exclude check box to indicate the current allocation should exclude any transaction previously
stamped by a different allocation.
Do not select any allocation stamp parameter if the allocation code applies to all GL transactions.
Allocation stamps provide an efficient way of targeting 2+ tier allocations at the results of previous tiers. This
mechanism is more flexible and efficient than a hierarchy of allocation codes.
Note Allocation stamp parameters are applicable only to Transactional allocations.
Example
Suppose you have six allocation codes defined and grouped into a single Allocation Batch. Each of the six
allocation codes is assigned the Transactional allocation type as well as the following tier parameters:
Allocation A: Tier: 1; Allocation Stamp: <empty>, Target Allocation Stamp: 01
Allocation B: Tier: 1; Allocation Stamp: <empty>, Target Allocation Stamp: 01
Allocation C: Tier: 2; Allocation Stamp: 01, Target Allocation Stamp: 021
Allocation D: Tier: 2; Allocation Stamp: 01, Target Allocation Stamp: 022
Allocation E: Tier: 3; Allocation Stamp: 021, Target Allocation Stamp: 03
Allocation F: Tier: 3; Allocation Stamp: 022, Target Allocation Stamp: 03
When you execute the above allocation batch, the application generates the batch in the following order:
1.
First, the application generates allocations A and B because they are marked as Tier 1. Allocations A and B
each select GL transactions with empty Allocation Stamp fields (for instance, transactions that have never
been allocated) and create new allocation transactions. The application assigns an allocation stamp of 01
to each of the newly created GL transactions.
2.
Next, the application generates allocations C and D because they are marked as Tier 2. These two allocations
are applied to all transactional results of allocations A and B (generated during the previous step) because
allocations C and D are targeted at transactions with an allocation stamp of 01. All newly created GL
transactions created by allocation C are assigned an allocation stamp of 021, and those created by allocation
D are assigned an allocation stamp of 022.
3.
Lastly, the application generates allocations E and F. These allocations are marked as Tier 3. Following the
same logic, allocation E is applied to the results of allocation C (stamp 021) and allocation F is applied to
the results of allocation D (stamp 022).
53
54
Field
Data
Allocation Code
XXX-T2
Description
XXX Tier 2
Allocation Type
Transactional
Book
Main Book
Fixed Value
Percentage to Allocate
100.00
Tier
XXX-02
XXX-021
Allocation Stamp
XXX-01
55
56
57
5. In the Allocation Code field, select XXX Tier 2 (where XXX are your initials).
6. Click Save.
Generate Schedule
1. From the Actions menu, select Generate Schedule.
The Generate Schedule window displays.
2. In the Fiscal Year field, verify the current calendar year displays.
3. Click Generate.
A message displays and tells you how many schedules were created.
4. To the message, click OK.
5. Click Save.
6. Navigate to the Allocation Schedule sheet.
Note The current fiscal period is the only period with a status of Scheduled. To schedule additional
periods, in the row of the period you want to update, select the Scheduled check box.
Generate Allocations
After allocation codes are grouped into batches, use the Generate Allocations process to commit (write)
allocations to the general ledger (GL).
On a high level, the algorithm of generating allocations works as follows:
1.
Select a GL book and a fiscal period (based on the selected GL book's calendar) or a date range and define
an Apply Date.
2.
Select a batch of allocation codes (entered in Allocation Batch Entry) for the selected GL book.
3.
The Epicor application generates the selected allocations in order of their tier level (for example, first Tier 1,
then Tier 2, and so on) and displays a report that contains the allocation transactions. This report displays
in a report style similar to an Edit List.
4.
Review the report results and confirm the results are correct.
5.
The application writes the transactions to the GL and records the history of the allocations.
Menu Path
Navigate to this program from the Main Menu:
Financial Management > General Ledger > General Operations > Generate Allocations
58
Track Allocations
Navigate to the Allocation History Tracker.
Menu Path: Financial Management > General Ledger > General Operations > Allocation History Tracker
1. In the Book field, verify Main Book displays.
2. In the Start Period and End Period fields, select the current fiscal period.
Hint: The current fiscal period corresponds with the current calendar month.
59
60
Simulate Allocations
In Generate Allocations, there is a specific mode of posting allocations called Simulation Allocations. This
simulation mode enables you to calculate and save allocation transactions without actually affecting the general
ledger (GL).
When you generate allocations in simulation mode, the allocation transactions post to a separate set of tables
(GLJrnDtlSim) instead of the actual GL tables. The simulation mode does not affect in any way the process of
calculating allocations or generating transactions.
Note A journal number is still assigned to a simulated transaction; however, the number of the simulation
mode journal is based on the GLJrnDtlSim table.
The data flow of the allocation posting process for both the actual and simulation modes is illustrated in the
following diagram:
61
5. Delete any allocation batch except the tiered batch you created, XXX-Tiered Allocations Batch, (where
XXX are your initials).
6. Click Submit.
7. Exit Generate Allocations.
62
For extended details on the following, refer to the Multi-Site Technical Reference Guide available in the Application
Help.
To configure multi-site functionality within the Epicor application, complete the following steps:
Verify the installation of the Multi-Site Management license in your environment.
If your multi-company environment will use multiple databases, verify the status of the SonicMQ
DomainManager and the SonicMQ Broker or the SonicMQ Container. However, if your environment will
use a single database, the Sonic MQ application is optional. You can instead link your companies through a
Direct data transfer method.
Configure at least one external system record(s) that uses either the Direct or Sonic data transfer method
(Again, depending on your environment).
Configure at least one external company record(s).
In order for companies to share data, you must create external company records that define how each existing
company should interact with each other company.
Verify your Startup Schedule.
Schedule either the Multi-Company Server Process or the Multi-Company Direct Server Process.
Start either the Multi-Company Server Process or the Multi-Company Direct Server Process.
Select Global Tables for all companies.
63
64
Business Entity
Business entities define the overall primary items within each company database, such as customer, supplier,
part, and project. Your Epicor application installs with primary business entities. Each business entity is essentially
a static table which contains the overall database structure used to record transactions against the specific item.
You link, or reference a business entity for a dynamic segment within Chart of Account Structure Maintenance.
This segment type can define subsidiary ledgers for accounts receivable and accounts payable control accounts.
You can select a business entity from the Business Entity drop-down list when you select the Use Business
Entity check box.
When you select a customer, supplier, part, or other business entity in Chart of Accounts Structure Maintenance,
you indicate the segment uses the values recorded in the business entity's table and fields to calculate the segment
values. The posting rules, which reference the business entity, set the segment values during the posting process.
Business entities are at the top of the hierarchy which generates accounts during the posting process. The items
directly below business entities in the hierarchy are GL control types. Each GL control type is linked to a specific
business entity, and so the business entity defines what areas of the database the GL control type updates through
its account and journal contexts. GL control types are templates used by the third and final level of this hierarchy,
GL controls. A GL control uses the account contexts specified through the GL control type to defines the specific
accounts which update for each transaction.
GL Controls
GL controls define all the account strings and journal codes used during the posting process to record a specific
transaction.
Each GL control contains the accounts and journal codes available to a specific record. As part of the posting
process, these accounts generate as needed based on the business transaction which occurred. You attach the
GL control to a specific record, such as a customer record, and the general ledger accounts and journals defined
on the control post business transactions made against this customer record.
Each GL control is a child record of a GL control type. The parent GL control type defines the account and journal
contexts for the GL controls it contains. You then create or modify the child GL control, indicating the specific
accounts and journals it contains. A GL control type, in turn, is linked to a business entity. A business entry is a
static table that contains the table/fields which hold the data involved in the posting process.
As part of the setup for a new company in a multi-company environment, you need to create a GL control which
links to the AR Intercompany, AP Intercompany, and GL Intercompany account contexts. You also need to indicate
that the GL control uses the Inter-Company journal code you created in Journal Code Maintenance.
You create and modify the GL control types within GL Control Type Maintenance, and you create and modify
GL controls within GL Control Maintenance.
65
Menu Path
Navigate to this program from the Main Menu:
System Management > Utilities > Multi-Company Server Process
Important This program is not available
in the Epicor Web Access interface. You can launch this program
MultiCompany.log file
All multi-company transfers are recorded in a MultiCompany.log file. This log file is an excellent tool for confirming
the multi-company process is performing as expected.
All multi-company transfers are written to the MultiCompany.log file. It is a text file you can view using any text
editor. Following is an excerpt from several transfers written to the log. The log file is a commutative file which
populates with the date and time of the transfer(s).
3:21:28 (Myserver:9416) Multi-Company Process - Starting Sonic Session (TCP://localhost:2506)
13:21:30 (Myserver:9416) Multi-Company Process - 41 Outbound Records Processed (EPIC06/EPIC01)
13:21:30 (Myserver:9416) Multi-Company Process - 42 Outbound Records Processed (EPIC06/EPIC02)
13:21:31 (Myserver:9416) Multi-Company Process - 41 Outbound Records Processed (EPIC06/EPIC03)
07/30/09 13:21:41 (Myserver:9416) Multi-Company Process - Completed
Occasionally refresh the log, as it can become a large file.
Select the location of the log at the time you define the Multi-Company Server Process or the Multi-Company
Direct Server Process. To review the log, contact your system administrator for its current location.
66
Whether the account's description and active status are preserved during automatic account updates.
Whether the account is used for inter-company processing - Inter-company processing updates multi-company
accounts defined in the COAs of a parent company and its subsidiaries.
For more information on generating or defining GL accounts, refer to the Application Help.
Menu Path
Navigate to this program from the Main Menu:
Financial Management > General Ledger > Setup > General Ledger Account
67
Multi-Company Journals
Use multi-company journal processing to simultaneously post a journal from a parent company to one or more
journals within the current company, or to one or more subsidiary (child) companies.
Distribute these allocations across the accounts within the chart of accounts (COA) for a subsidiary company.
You typically use multi-company journals to divide the balance of an expense account across multiple companies.
Tip This functionality is similar to AP allocations. Use this multi-company functionality in AP Invoice Entry
on the GL Analysis sheet. When configured, AP allocations automatically distribute expense amounts
across the inter-company accounts.
For this functionality to work, you must define inter-company journals for the parent and subsidiary companies,
and external company records so that each company can receive inter-company journal transactions.
The flow of the data begins at the corporate (parent) location. In GL Journal Entry, enter transactions into the
inter-company journal. The GL control attached to these transactions must use the External Company GL control
type in order to define the required inter-company journal context. These journal entries are then posted to the
general ledger. You can run GL allocations on these entries.
The journals only transfer from the main book at the parent company to a book in the target child company. The
group entry mode used within the target company defines the COA, fiscal calendar, and currency values used
to record these journals; the mode it uses depends on the number of books which exist in the target company.
If the target company only has one book, the transferred journals display as journals in Single Book Mode,
using the values from the single book which received them. If the target company has multiple books, the
transferred journals display in Multi-Book Mode, and use the values defined in the configuration of the target
company.
These transactions are automatically sent out to the subsidiary (child) companies, where they are then incorporated
directly into the subsidiary journals. The updated financial information displays through the Journal Tracker and
the Journal Listing report.
68
69
70
2. Navigate to the Journal > Header sheet, and review the details.
In the Multi-Company pane, the Linked indicator displays.
GL Consolidation
Consolidation involves the transfer of subsidiary account balances to a consolidated chart of account (COA) used
in financial reports. Transfers require the configuration, generation, validation, adjustment, and posting of
consolidation journals. Typically, journals transfer balances from a source book owned by a subsidiary to a
consolidated book owned by its parent.
71
Consolidations occur in either continuous or periodic mode. Continuous consolidations occur between two
standard-type books. In periodic mode, the source book and the target book relate through an intermediate
book, which is a consolidation-type book. An intermediate book allows validation of consolidation journals and
tracking of consolidation entries.
Consolidations can occur between books in the same database or in different Epicor databases. A remote parent
maintains the consolidated book in a different database from the subsidiaries' books. In this case, consolidation
involves the generation of an output file containing source journals. Import Consolidation From Subsidiary enables
the posting of journals in the file to the target book in the parent's database.
The following tasks are fundamental to the implementation of the consolidation process:
Use Book Maintenance to define a Consolidation book type used mediate the transfer of consolidation
journals between two standard books.
Use Consolidation Rate Type Maintenance to define consolidation rate types used to convert balances
when consolidated books use different currencies.
Use Consolidation Type Maintenance to determine the method used to calculate account balances during
consolidations and the consolidation rate type applied to them. Consolidation types apply to account categories.
Use COA Category Maintenance to set the consolidation type applied to account categories that display
on consolidated financial statements.
Use Consolidation Definition Maintenance to defines settings that control consolidations, including currency
conversion defaults, consolidation mode, and account mappings between consolidation books. Definitions
determine whether:
For more information on the consolidation setup, refer to the Multi-Company Course or the Application Help.
Process Flow
The financial data from the source book is transformed into the account structures defined in an intermediate,
or consolidation, book. The COA account structure matches the structure in the target book, so this data can
now move from the intermediate book into the target book within the target company.
The following diagram illustrates the consolidation process flow:
72
The general ledger (GL) transactions post to the source book. These transactions use the posting process
defined for the source book.
2.
The consolidation process begins transforming these GL transactions into the format needed for the
intermediate (consolidation) book. If the intermediate book uses a different currency, the process first
converts the amounts using the exchange rate calculated by the selected consolidated rate type and the
consolidated type. Consolidation rate types convert balances when the books use different currencies;
consolidation types determine the method used to calculate the converted account balances.
3.
The GL transactions are then transformed into the account structure required for the intermediate book.
4.
73
5.
Now using the Sonic functionality, the GL transactions move from the intermediate book in the source
company to the target book within the target company.
6.
Reports can now be run on the consolidated financial data. This data can also display on various entry programs,
financial trackers, and dashboards within the target company.
Consolidation Process
Once the consolidation between the source and target books is set up, you can run the consolidation process.
This process is primarily run in Consolidate to Parent Entry. Each time you need to consolidate financial data
between the source and target books (typically at the end of a fiscal period), launch Consolidate to Parent Entry
and post the results. This program specifies the consolidation period and the consolidation definition used to run
the process. The consolidation process creates journals for source chart of accounts (COA) segments that maintain
balances. Use consolidation journals to validate entries and adjust journals.
Menu Path: Financial Management > Multi-Site > General Operations > Consolidate to Parent
If necessary, pull in consolidation journals from a company in an external database. Unlike a consolidation which
occurs between multiple companies in the same database, you need to import an external file that contains the
consolidation data. Use Import Consolidation From Subsidiary to import journals from a source book that
exists in a different Epicor database.
Menu Path: Financial Management > Multi-Site > General Operations > Import Consolidation From Subsidiary
Important This program is not available in the Epicor Web Access interface. You can launch this program
74
Field
Data
Company
Epicor Distribution
Field
Data
Book
Target Book
6. In the Intermediate Book Options pane, in the Book field, select Intermediate Book.
7. Click Save.
8. From the New menu, select New Source Book Definition.
9. In the Source Book field, select Source Book.
10. In the Posting Options pane, enter the following:
Field
Data
Intermediate Journal
General Journal
Target Journal
Consolidation Journal
Data
Balance Sheet
Balance Consolidation
Income Statement
Income Statement
75
76
77
78
Conclusion
Conclusion
Congratulations! You have completed the course.
Please take a moment to let Epicor University know how to serve you better by completing an evaluation at htt
p://www.keysurvey.com/survey/379199/e92f/. Your feedback provides the guidelines for the future direction of
Epicor University offerings.
79
Index
Index
B
book maintenance 23
gl controls 65
80