Finance enterprise groups

Your organization's accounting structure is determined by the finance enterprise group (FEG). Usually, a single FEG is sufficient for an organization’s accounting requirements. You can set up more than one for your organization. Consider these questions when determining whether to create multiple FEGs:

Do you have groups of accounting entities that do not share any chart or dimension definitions?
Must the financial information of the independent groups of accounting entities be combined for reporting purposes?
Financial information is not shared across finance enterprise groups, combining the hierarchy structures that are created in each finance enterprise group may not be possible.
Do the same actors perform the setup, processing, and reporting for these independent groups of accounting entities?
An actor is linked to one finance enterprise group, and actors are not shared across financial enterprise groups.
Are the vendors and customers identical for all the accounting entities?
Vendor and customer data cannot be shared across finance enterprise groups.
Creating multiple finance enterprise groups can require duplicating setup data.

These components are contained in the FEG record:


Component	Description
Enterprise group	A Landmark global entity that is shared by all Landmark applications. Your finance enterprise group is associated with it and shares the ID and description of a Landmark enterprise group. The currency tables and the currency translation rates that are used by the finance enterprise group are associated with the same enterprise group.
Core ledger	The core ledger contains all of the transactions that are common to all of the financial reports.
Finance structure	The finance structure determines the required and optional elements to include in the accounting string when transactions are created. At a minimum, the finance structure must include an accounting entity and an account. Optionally, the finance structure can include an accounting unit, a project, and up to ten user-defined dimensions. You determine which of these elements are required or optional, and the order in which they are displayed on transaction entry forms.
Currency exchange table	The currency exchange table is used to define all of the exchange rates that are used by the finance enterprise group. The currency exchange table is required if the finance enterprise group uses multiple currencies.
Enterprise currencies	Enterprise currencies are used for reporting by all the accounting entities that are associated with the finance enterprise group. All transactions are automatically converted to all enterprise currencies. If your organization uses Project Ledger, and you include projects in your finance structure, then you must define one enterprise currency. The project functional currency must be one of the enterprise currencies.
System accounts	System accounts are the posting accounts that are used for system-generated entries. You can provide system accounts on the FEG page before you save the record. The accounts are created when you save the record. After you save the finance enterprise group, you must create the system accounts on the Accounts tab.
Calendars	Calendars are used by the reporting basis, and by the closing configurations that are associated with the accounting entities.
Accounting entities	Accounting entities are the highest organizational element in Global Ledger within a finance enterprise group. This information can be specified for each accounting entity: A functional currency and up to three alternate currencies The closing configuration use The current year and period If accounting unit structures are used, then specify whether to use zone balancing for accounting units Whether to balance by transaction currency Whether to auto-balance currency transactions Whether to allow the Unrelease Manual Journal Valid systems Whether to require Journal approval and setting the approval amount Assign Address Code If your finance structure uses accounting units, then you must define at least one accounting unit structure, one of which must be an enterprise structure. Accounting unit structures are shared across accounting entities. But each accounting entity can define its own accounting unit hierarchy within the structure. An accounting unit hierarchy consists of summary and posting accounting units with parent-child relationships. The lowest level of each branch is a posting level.
Inter entity relationships	If a finance enterprise group includes multiple accounting entities, then you can create relationships between accounting entities.
Dimension for department journal	Multiple departments can be charged when one department pays an expense. Select accounting unit or dimension 1-10 to use for tracking the department journal entries. If using this feature, then you must set up system accounts for department journal payables and receivables.
Accounting entity groups	Accounting entity groups are used to revalue and translate the reporting basis.
Accounts	Accounts are the finance structure components where transactions are posted. All posting accounts and sub accounts, including the system accounts, are defined at the FEG level. They can be shared by multiple charts of accounts.
Projects	If your organization uses Project Ledger and you include projects in your finance structure, then you must create at least one project structure. Additional alternate structures or views can be created. Project structures are shared across the finance enterprise group. One of the project structures must be designated as the "enterprise" structure. The enterprise structure is the structure for which structure relations and relation rules are defined. Relation rules are used to define the valid pairs for posting. For example, the accounttoproject structure relation defines the valid accounts that can be used with projects. Each project structure must include a hierarchy that is similar to the accounting unit parent-child hierarchy. The lowest level in the hierarchy is the posting level.
User dimensions	If your finance structure includes user dimensions, then you must create at least one user dimension structure for each dimension. One must be an enterprise structure. Each dimension structure must include a hierarchy of dimensions that is similar to the accounting unit parent-child hierarchy. The lowest level in the hierarchy is the posting level. For example, if you have a location dimension, you can create a North America location, a Europe location, and an Asia location. Within each you can create locations by specific country. Each hierarchy is unique to the dimension and structure. For user dimension 1 only, you can specify zone balancing and create zones in your user dimension 1 hierarchies.
System codes	A system code identifies a solution. Each solution in Financials & Supply Management has a predefined system code. For example, GL is the system code for Global Ledger. System-defined system codes are loaded automatically. You can also create system codes for third-party applications that you plan to interface to Global Ledger.
Events	An event is used to identify actions that create a general ledger transaction. Events that can automatically create a transaction are an expense distribution, vendor payment, or cash receipt. You can also assign an event to a transaction that originates in Global Ledger to identify the reason for a manual entry. System-defined event codes that are associated with subsystem transactions are loaded automatically. You also define new event codes to represent a specific type of transaction.
Account Sub Types	An account sub type is assigned to an account to define accounts at a more granular level than account type in reporting. Account sub types are optional. System-defined account sub types are loaded automatically. You can also create new account sub types.
Ledgers	All transactions are associated with a ledger. Ledgers can be shared across the reporting basis, except the close ledger and currency ledger that are unique to each reporting basis. The core ledger is created automatically and assigned to the reporting basis. A close ledger is generated automatically for each reporting basis that you create. If the Currency Translation and Revalue option is selected for the finance enterprise group, then a currency ledger is also automatically created for each reporting basis. You can define other ledgers to meet your organization's reporting requirements. For example, you can create adjustment ledgers and eliminating entries ledgers.
Charts	You can define multiple charts of accounts, which provide the hierarchical reporting structures for the reporting basis. The charts can include all or some of the posting accounts. You can override select enterprise posting account settings at the chart level. One chart must be designated as an enterprise chart. The enterprise chart is used in validations.
Reporting basis	Reporting basis combines ledgers and accounting entities. Reporting basis is used to generate financial reports based on the chart, calendar, accounting entities, projects, and ledgers that are assigned to the reporting basis.
Structure relations	Optionally, you can use structure relations to create relations between elements of the FEG finance structure. You can use structure relations to define validation rules for each relation.
Project structure validations	If your organization uses Project Ledger, you can create valid dimension ranges for a summary project or a posting project only or in combination with another dimension, for example, accounting category. You can use project structure validations in addition to structure relations.
HR organization	Select the HR organization from your HCM system. Actor-agent records that exist in Global Human Resources can be created in FSM only after the employee exists in GHR. FSM maintains separate Agent and Parent Agent tables than HR Talent but the content must be identical.
Project date edit	If your organization uses Project Ledger and you include projects in your finance structure, then you must select a project date edit. Valid values are transaction date and posting date. Project Ledger transactions or journal entries must fall within a date range that is assigned to the project. Indicate whether to use posting date or transaction date when the date validation is performed.
Project burden date	If your organization uses Project Ledger and you calculate burdens to create indirect expenses, then you must select the burden date. The burdens are fees for administration and overhead based on project direct costs. Valid values are transaction date and posting date. Indicate whether to use posting date or transaction date from the source transaction. The rate that is in effect and the rate to use when calculating the burden transaction are determined by this date.
Project invoicing	If your organization uses Project Invoicing and Revenue to bill external customers, or grants for billable or grant-funded projects, then select the Project Invoicing check box. If that check box is selected, then `Finance Dimension 2` is required. Use `Finance Dimension 2` to track project funding sources, such as customers or grants.
Billing override level	If your organization uses Project Invoicing and Revenue to bill customers or grants for billable or grant-funded projects, then you can define a billing override. Billing overrides are defined at the project level. You can select another dimension for overrides below the project. The billing override that is selected must be consistent across all projects. The default value is Account.
d/EPM mapping	If your organization uses d/EPM for budgeting, then the Global Ledger structures are mapped to the d/EPM structures.
Teams	Users can be assigned to teams that are used for approvals.
Approval code	If your organization requires approvals, then codes must be created and assigned to the appropriate process.