Oracle® Fusion Applications Cost Accounting and Receipt Accounting Implementation Guide 11g Release 1 (11.1.2) Part Number E22767-02

Contents

Previous

Next

17 Cost Management Configuration: Define Cost Management

This chapter contains the following:

Manage Cost Organizations, Cost Organization Relationships, and Cost Books

Manage Cost Analysis Groups

Define Cost Policies and Cost Book Policies

Define Overheads

Define Subledger Accounting Rules

Manage Cost Organizations, Cost Organization Relationships, and Cost Books

Cost Organizations, Inventory Organizations, and Cost Books: How They Fit Together

A cost organization structure comprises cost organizations, inventory organizations, and cost books. Your accounting and business needs determine how you set up your cost organization structure. This structure in turn determines how the cost processors create cost accounting distributions and accounting entries for inventory transactions.

This figure illustrates the relationship between cost organizations, inventory organizations, and cost books.

Cost Organizations and Inventory Organizations

A cost organization can represent a single inventory organization, or a group of inventory organizations that roll up to a business unit. You can group several inventory organizations under a cost organization for financial reporting purposes. However a cost organization can map to only one business unit.

The inventory organizations that are assigned to a cost organization must all belong to the same legal entity.

For each cost organization, define an item validation organization from which the processor should derive the default units of measure. You can designate one of the inventory organizations assigned to the cost organization to be the item validation organization, or you can designate the item master organization to be the item validation organization.

Cost Books

A cost book sets the framework within which accounting policies for items can be defined. You can define different cost books for each of your financial accounting, management reporting, and analysis needs. By assigning multiple cost books to a cost organization, you can calculate costs using different rules simultaneously, based on the same set of transactions.

Every cost organization must have one primary cost book that is associated with the primary ledger of the legal entity to which the cost organization belongs. You can also assign secondary ledger-based cost books for other accounting needs, as well as ledgerless cost books for simulation purposes. For example, you could assign a primary cost book for financial reporting, a secondary cost book for business analysis, and a ledgerless cost book to simulate results using different cost calculations.

When you assign a cost book to a cost organization, you can optionally associate it with a ledger. The cost book then inherits the currency, conversion rate, cost accounting periods, and period end validations of that ledger. If you are assigning a ledgerless cost book, then you define these elements manually.

Setting Up the Cost Organization Structure: Points to Consider

Set up your cost organization structure to accommodate your costing and accounting needs. The following discusses considerations for creating cost organizations, their association with inventory organizations, and their assignment to cost books.

Creating Cost Organizations

When deciding what cost organizations to set up, consider the following:

• Financial reporting. You typically create a separate cost organization for every business unit.

• Data security needs. The cost organizations that you create may be determined by the separation of duties and security requirements for your users.

Using Cost Organization Sets

By assigning cost organizations to a set, the entities defined at the set level can be shared by all the cost organizations belonging to that set. A cost organization set enables you to streamline the setup process, and helps you avoid redundant setup by sharing set-level definitions of your cost profiles, valuation structures, cost elements, and cost component groups across the cost organizations that belong to the set.

You also have the flexibility to assign cost organizations to different sets, for example if they are in different lines of business. That way you can segregate the definitions that are shared.

Associating Inventory Organizations with Cost Organizations

Your operation may lend itself to a simple configuration of one inventory organization to one cost organization. Or, when there are many inventory organizations in the same business unit, you may group several inventory organizations under a single cost organization for any of the following reasons:

• Costing responsibilities. You may want to group inventory organizations that roll up to a manager or a cost accounting department under the same cost organization.

• Uniform cost accounting. For example, if you want to define your overhead rules just once and apply them to transactions from several inventory organizations, you could group those inventory organizations into one cost organization.

• Cost sharing. If there are items in more than one inventory organization for which you want a single average cost, those inventory organizations must fall under the same cost organization.

Assigning Cost Books to Cost Organizations

Every cost organization must be assigned one primary cost book that is associated with the primary ledger of the legal entity to which the cost organization belongs. You may also assign several secondary cost books as needed for other purposes such as: business analysis and management reporting, local currency accounting, or profit tracking of inventory items.

You can also assign ledgerless cost books to a cost organization for simulation purposes.

Setting Up a Cost Organization Structure: Examples

The following examples illustrate cost organization structures that support different cost accounting needs.

Example 1

Set up three inventory organizations to optimize materials management across three different locations. Because they all belong in the same business unit and are managed by one cost accounting department, you could group them under a single cost organization; or you could assign each inventory organization to its own cost organization.

Example 2

Three inventory organizations are geographically dispersed, and each one falls under a separate business unit. Create three cost organizations, and assign each inventory organization to its own cost organization.

Example 3

Four inventory organizations are geographically dispersed. Two of them fall under one business unit, and two fall under another business unit. You could group the inventory organizations under two cost organizations corresponding to the two business units; or you could assign each inventory organization to its own cost organization.

Example 4

Two inventory organizations in the same business unit need to share a single average cost for some items. These inventory organizations must belong to the same cost organization.

FAQs for Manage Cost Organizations and Cost Organization Relationships

What's a set-level definition?

A set-level definition enables you to segment and share your reference data. Entities that are defined at the set level can be shared by all cost organizations belonging to that set. For example, to segment your cost element reference data by country, you can define cost elements for each country set; and the cost organizations belonging to the country set can share the cost elements within that set. You can also use the Common set to share the same reference data across all cost organizations. This saves you redundant setup, and streamlines the process.

Can I change the legal entity of a cost organization?

No. You cannot change the legal entity of a cost organization once transactions are processed under that cost organization.

How can I create and maintain a cost organization?

You can create, edit, or delete a cost organization in the Oracle Fusion Global Human Resources application, on the Manage Cost Organization page.

Can I associate an inventory organization with more than one cost organization?

No. You can associate an inventory organization with only one cost organization.

Can I delete or inactivate a cost book or a cost book assignment to a cost organization?

Yes. You can delete or inactivate a cost book or a cost book assignment to a cost organization if there are no costing transactions or other references that depend on the cost book or cost book assignment. Do this by first deleting references to the cost book in other cost management setup, then delete the cost book. Likewise, first delete references to the cost book assignment in other cost management setup, then delete the cost book assignment.

You can inactivate a cost book or cost book assignment to a cost organization at any time. To inactivate a cost book or cost book assignment, set the effective end date to a current or future date; however, all past assignments remain in effect.

Can I delete or inactivate the association of an inventory organization with a cost organization?

Yes. You can delete or inactivate the association of an inventory organization with a cost organization, but only if there are no costing transactions or other references that depend on the inventory organization and cost organization relationship. Do this by first deleting all references to the inventory organization and cost organization association in other cost management setup, then delete the association.

You can also inactivate the association of an inventory organization with a cost organization by setting the effective end date to a current or future date; however, all past associations remain in effect.

Manage Cost Analysis Groups

Cost Elements, Analysis Codes, and Analysis Groups: Explained

Map cost elements to analysis codes within analysis groups for reporting purposes. This enables you to categorize and summarize your costs differently, depending on your reporting needs.

Use analysis groups to define alternate views of item costs. For example, you can group cost elements into a fixed and variable analysis group, or a direct cost and indirect cost analysis group.

Using Cost Elements, Analysis Codes, and Analysis Groups

You can assign a cost element to multiple analysis codes. However an analysis code must be unique within an analysis group, and it can be reused in multiple analysis groups. For each analysis group you can set up a default analysis code that is used for unassigned cost elements.

The following are examples of cost elements classified under analysis groups.

Define Cost Policies and Cost Book Policies

Cost Components, Cost Elements, and Cost Component Groups: How They Work Together

Cost components come from external sources, and are mapped to cost elements which the costing application uses to track the cost of items. Use cost component groups to map cost components to cost elements, and to map source cost elements to destination cost elements when items are transferred from one inventory organization to another.

This figure illustrates the relationship between cost components, cost elements, cost component groups, and cost profiles.

Cost Components

Cost components are the most granular representation of item costs. They come into the costing application from external sources such as inventory, receiving, and accounts payable. Examples of cost components are purchase order item price, material, freight, and tax.

Cost Elements

A cost element is the level where the costs of an item are tracked through the inventory accounting life cycle. Cost components are mapped to cost elements, which enables you to calculate item costs at different granularity levels for different business needs. For example, you may want more granularity for high-value than for low-value items.

You can define cost elements for four types of costs:

• Material cost element type for incoming material cost components.

• Overhead cost element type for costs that are calculated by the cost processor based on user-defined overhead rules.

• Profit in Inventory cost element type for tracking of internal margins when items are transferred from one inventory organization to another, including global procurement and drop shipment flows. For cost elements of this type, indicate the Profit in Inventory organization that incurs the gain or loss due to the transfer of goods.

• Adjustment cost element type for separate tracking of cost adjustments, which provides a more detailed view of item costs and profit margins.

Cost elements are defined at the set level and thereby have the advantages of set-level definitions for sharing and segregation. A Profit in Inventory cost element must be assigned to the Common cost element set so that it can be shared across cost organizations.

The following are examples of cost element definitions:

Cost Component Groups

Use cost component groups to define mappings of:

• Cost components from external sources to cost elements in the costing application. These mappings provide flexibility in the granularity level where you track costs. You can map one cost component to one cost element for a detailed cost breakdown, or several cost components to one cost element for a less granular view of costs.

• Source cost elements to destination cost elements in the transfer of items from one inventory organization to another. This helps to maintain visibility of the item cost structure from the source application and across the supply chain.

You can specify a default cost component mapping to cost element to be used in cases where the source cost element does not have a matching destination cost element. The default cost component mapping is helpful when:

• The detailed mapping of a cost component to cost element is not required, and you want to map it to a single cost element.

• The designated mapping for a cost component is missing. If the mapping is missing, the transaction automatically picks up the default cost component mapping.

Cost component groups are one of the attributes of cost profiles, which the cost processor uses to determine how to calculate item costs. Cost component groups are defined at the set level and thereby have the advantages of set-level definitions for sharing and segregation. Cost component groups and cost profiles are both set enabled; therefore, only those cost component groups belonging to the same set as the cost profile are available to that cost profile.

The following are examples of cost component group mappings.

Example 1: Mapping of one cost component to one cost element.

Example 2: Cost components mapped to one or more cost elements.

Example 3: Mapping of source cost elements to destination cost elements in an interorganization transfer.

You have flexibility in how you map cost component groups to items:

• Different items in a cost organization and book combination can have the same or different cost component group mappings if they use different cost profiles.

• One item can have different cost component group mappings in different cost books.

• Several cost organizations can share the same cost component group mappings if they belong to the same set, or if they are defined the same way in different sets.

The following figure illustrates different mappings of cost component groups to items.

Cost Profiles, Default Cost Profiles, and Item Cost Profiles: Explained

Cost profiles define the cost accounting policies for items. The cost processor refers to the attributes of a cost profile to calculate costs and create accounting distributions for item transactions. Each item in a cost organization book requires a cost profile to calculate the inventory transaction costs.

The following describes how to define cost profiles and assign them to items.

Cost Profile Definition

A cost profile has the following attributes:

• Cost profile set. Cost profiles use set-level definitions, and all cost organizations belonging to that set can share the same cost profile definitions.

• Cost method. Establishes how cost is calculated. The costing application uses the perpetual average cost or actual cost method.

• Valuation structure. Sets the granularity level at which items are costed, for example Cost Organization level, or Inventory Organization, Lot, and Grade level.

• Valuation structure type. Asset or Expense type.

• Cost component group. Maps incoming cost components to cost elements, which are used to cost transactions.

• Costing unit of measure (UOM). Used to cost the item. Some items have primary and secondary units of measure, and there is no fixed conversion factor between the two. For example, you can calculate the cost of chickens by eaches or by weight.

• Quantity depletion method. Sets how inventory quantity is depleted when inventory transactions are costed. The method used by the costing application is first in, first out (FIFO).

• Method for processing negative quantity. Establishes how to treat depletion of inventory when the depletion quantity exceeds inventory on hand. Options are Always, To Zero, or Never.

• Propagate cost adjustment. Option to propagate cost adjustments down the supply chain, available only if using the actual cost method.

• Receipt without cost. Specifies that for sales returns without an RMA reference or missing incoming cost, the cost processor uses the first or last receipt layer cost.

• Referenced RMA cost. Specifies that for sales returns with an RMA reference, the cost processor uses the average cost of the original sales issue.

Cost Profile Assignment to Items

Assign cost profiles to items in each cost organization and book combination where there are item transactions. Cost organizations can have multiple cost books and the same item can have different cost profiles in different cost books used by the cost organization. This is useful when you want to use different books for various financial reporting and decision making purposes, such as statutory reporting, or management reporting.

Items can also use different cost profiles in various cost organization and book combinations, when they require different cost accounting policies.

You can simplify the effort by assigning default cost profiles at the cost organization book level, or at the item category level within the cost organization book. Default cost profiles are generally used if the costing policy is the same for all items in the cost organization book, or in the item category.

Override default cost profiles by assigning specific item cost profiles at the individual item level. You can modify or delete a default cost profile assignment at any time, and these changes will be in effect for subsequent transactions.

You can assign cost profiles in three ways:

• Automatic without approval. If the default cost profile has the new item profile creation mode set to Auto, the preprocessor automatically generates and assigns the default cost profile to new items. This means that the cost processor uses the same cost profile for all items within that cost organization book, or within the item category.

• Automatic with approval. If the default cost profile has the new item profile creation mode set to Review Required, you must review and approve the generated cost profile before the cost processor assigns it to new items.

• Manual. Manually assign the cost profile to a new item before the cost processor processes the first transaction. This cost profile then remains in effect for subsequent transactions. The manually assigned cost profile always takes precedence over the defaulted cost profile.

New Item Cost Profile Creation: Review and Approval Process

One of the attributes of a default cost profile is the new item cost profile creation mode, which can be set to Auto or Review Required. The creation mode determines how a new item cost profile is created.

Settings That Affect the Review and Approval Process

If a default cost profile has the new item profile creation mode set to Auto, the preprocessor automatically assigns cost profiles to new items, and they can be immediately used by the cost processor. If a default cost profile has the new item profile creation mode set to Review Required, then you must review and approve cost profiles before they can be used.

How a New Item Cost Profile Is Reviewed and Approved

When you save a default cost profile that is in Review Required mode, the preprocessor generates the cost profiles for new items based on the default cost profile, and sets them to Awaiting Approval status.

You then review the cost profiles on the Review and Approve Item Cost Profiles page, which is accessed from the Manage Default Cost Profiles page, or from the Cost Accountant Dashboard. After reviewing the cost profiles that are in Awaiting Approval status, set them to Approved or Rejected status. If you approve them, the creation source becomes Default Cost Profile. If you reject the cost profiles, you can manually modify them, and the creation source becomes Manual.

Save your changes and rerun the preprocessor, for final assignment of the item cost profiles.

Valuation Structures and Valuation Units: Explained

Valuation structures and valuation units define the granularity level at which the cost of an item is maintained. For example, you can maintain your cost calculations at the lot ID, serial ID, grade , or item level. Under certain circumstances, you can even have a single average cost for an item spanning more than one inventory organization.

The following describes how to use valuation structures and valuation units.

Valuation Structures

A valuation structure defines the level at which item costs are maintained. It specifies which inventory control attributes are used to segregate costs, and it is one of the attributes of an item cost profile. When a cost profile is assigned to an item, the cost processor uses the valuation structure on that cost profile to determine how to calculate the item cost.

The flexfield structure specifies the costing attributes that are enabled for a valuation structure. The costing attributes can be one or more of the following: Cost Organization (mandatory), Inventory Organization, Subinventory, Locator, Lot, Serial, and Grade. The costing attributes must be consistent with the inventory attributes, and cannot be at a lower level of granularity than the inventory on hand.

Valuation structures are of two types, asset and expense. An asset valuation structure is used for receipts of items that are valued as inventory on the balance sheet. An expense valuation structure is used to account for receipts to inventory of items that are expensed rather than treated as assets on the balance sheet. A cost profile with an asset valuation structure becomes an asset cost profile, and a cost profile with an expense valuation structure becomes an expense cost profile. Define both the asset and expense valuation structures on your cost profile; the item then inherits both valuation structures when it is associated with the cost profile.

Valuation structures are defined at the set level and thereby have the advantages of set-level definitions for sharing and segregation.

The valuation structure mode determines whether the valuation units are created manually, or automatically by the cost processor, or both:

• Valuation structures that you define as automatic are those that tend to be unlimited and unknowable in advance, such as lot IDs and serial IDs. With the automatic setting, the cost processor automatically creates a new valuation unit code as transactions for new lot IDs or serial IDs are processed.

• Valuation structures that you define as manual are those that tend to have a finite list of possibilities, such as grades or subinventories. Use the manual mode when you want to ensure that transactions that do not meet one of the expected possibilities will trigger an error condition.

• Valuation structures that you set as both manual and automatic are those cases where you can either define the anticipated valuation units before they enter the processor, or you can let the processor automatically create the valuation units if you have not already created them manually.

Valuation Units

A valuation unit is the set of values for the control attributes defined by the valuation structure. For example, valuation unit V1 comprises cost organization A, lot L1, and grade G1, and valuation unit V2 comprises cost organization B, lot L2, and grade G2. The processor calculates two different costs for the item: a cost for valuation unit V1 and a cost for valuation unit V2.

You can define multiple valuation units under a valuation structure, using different combinations of these costing attributes. The cost processor will automatically generate these valuation units if the valuation structure mode is set to Auto or Both.

By assigning a valuation unit to a cost organization book you specify the set of values for the inventory control attributes that are used to cost the item within that cost organization book.

Valuation Structure Rules: Explained

The valuation structure is one of the attributes of an item cost profile which is used to cost inventory items.

Conflicts may arise if the inventory control attributes in the valuation structure do not match the inventory control attributes of the inventory items.

Valuation Structure Conflict Resolution

In cases where the valuation structure specifies an inventory control attribute that is missing on the item, the cost processor applies the following rules.

If the inventory control attribute has the Required attribute set toYes, then the association of the valuation structure to the item is disallowed. If the inventory control attribute has the Required attribute set to No, then the association of the valuation structure is allowed, and the valuation unit will have a Null value for that inventory control attribute.

For example, suppose an item is not lot enabled, whereas lot is an attribute of the valuation structure. In this case, if the Required attribute is set to No, the valuation structure is considered valid for the item, and the processor applies Null to the lot value. However, if the Required attribute is set toYes, the valuation structure is considered invalid.

The Required attribute can be changed from Yes to No at any time to accommodate missing values. However it cannot be changed from No to Yes if any transactions using that valuation structure have been processed.

Using Valuation Structures to Calculate Item Costs: Examples

The following are examples of how the cost accounting application maintains costs for an item using different valuation structures.

Assume that a cost organization stocks an item in four stores under two inventory organizations, as follows.

Example 1

The application calculates and maintains the item cost at the cost organization level. It maintains one cost for the item across all inventory organizations in the cost organization.

Example 2

The application calculates and maintains the item cost separately for each inventory organization in the cost organization.

Example 3

The application calculates and maintains the item cost separately for each subinventory in the cost organization.

Example 4

The application calculates and maintains the item cost separately for each lot under each subinventory and inventory organization.

Example 5

The application calculates and maintains the item cost separately for each lot under each inventory organization.

Manage Costing Units of Measure

Costing Units of Measure: Explained

You can cost an item using different units of measure (UOMs) for different business purposes, such as pricing, reporting or tracking costs.

The UOM is one of the attributes of a cost profile. You can calculate different costs for an item by assigning it cost profiles with different UOMs.

Primary and Secondary UOMs

To illustrate the use of a primary or secondary UOM, consider the case of chickens that can be costed by a UOM of each or of pounds. There is no standard conversion from one UOM to the other. In such a case, the costing UOM depends on how the chickens are sold, priced, or tracked. It may be more logical to cost the chickens by pound if that is how they are sold. However it may be more useful to cost them by each for planning and tracking purposes. In this case, the primary UOM could be each, and the secondary UOM could be pounds.

When an item in a cost organization and book combination is assigned a cost profile that specifies the use of the primary or secondary UOM, the cost accounting application uses the primary or secondary UOM that is defined in the item validation organization.

Using Different Units of Measure to Cost an Item: Example

This example illustrates how to calculate costs for an item using different units of measure.

Scenario

Consider a jewelry retail business that sells gold rings. The company purchases the rings in dozens, and maintains inventory costs in dozens and eaches.

Shipment Quantities and Costs

The company receives five shipments of rings as follows.

Analysis

Define a primary unit of measure (UOM) of dozens and a secondary UOM of eaches. You can calculate two different costs for each shipment using the primary UOM and the secondary UOM.

Resulting Costs in Primary and Secondary UOMs

The costs using the primary versus the secondary UOMs are as follows.

FAQs for Define Costs and Cost Book Policies

Can I delete or modify a cost profile, a default cost profile, or an item cost profile?

No. You cannot delete or modify a cost profile after it has been used to cost transactions for an item. However, if a cost profile has not been used to cost any transactions, you can delete or modify it after you delete references to it in other cost management setup.

What happens when I select different options for processing negative inventory quantities?

The options for processing inventory quantities when the transaction quantity exceeds the quantity on hand are:

• Always: applies cost for the entire transaction, including negative balances. The cost processor costs the transaction as follows:

  • If the cost method is perpetual average cost, it applies the average cost for the entire transaction quantity.

  • If the cost method is actual cost, it applies the FIFO layer cost for the entire transaction quantity, and then processes a cost variance when the next receipt replenishes inventory.

• To Zero: applies cost only for quantity on hand, and holds the remaining shortfall until inventory is replenished.

• Never: does not apply cost for the transaction until quantity is sufficient to cover the entire transaction.

Define Overheads

Expense Pools, Cost Element Groups, and Overhead Accounting Rules: How They Fit Together

Use expense pools, cost element groups, and overhead accounting rules to calculate overhead absorption for inventory transactions. Overhead expenses can be absorbed and capitalized into inventory, or they can be absorbed and reclassified as an expense.

Overhead Costs Expensed or Capitalized

On inbound transactions and inventory transfer transactions, overhead expenses can be absorbed and capitalized into inventory value, or the absorption can be redirected to an expense account: a credit to an absorption account and a debit to either an inventory or expense account. On outbound transactions, overhead absorption is redirected to an expense account, and will be included in the gross margin calculation.

For example, consider a receipt of inventory items that cost $10 each to purchase, and you would like to absorb overhead cost of $2 each on the inbound transaction. When the item is sold, you would like to absorb additional overhead of $3 each on the outbound transaction. The total cost of goods sold is $15 each.

Expense Pools

Expense pools represent a collection of general ledger expense accounts that can be absorbed as overhead costs. Expense pools are defined at the cost organization level. Overhead rules are defined for expense pools, and an expense pool can have many overhead rules that absorb it.

Expense pools are mapped to a cost element, and a cost element can contain one or more expense pools. When overhead is absorbed, an accounting distribution is created for each expense pool, so you can define accounting rules crediting the absorption account at the expense pool level. Once the inbound transaction is in inventory, the application tracks the value of inventory at the cost element level, so that you can track costs through inventory at the desired level of granularity.

Cost Element Groups

Cost element groups tell the processor which cost elements to sum when the overhead rule is a percentage of cost. Cost element groups can be system defined or user defined, and they are set at the cost organization level.

There are two predefined cost element groups, Transaction Cost and Material. You can also define your own cost element groups.

Overhead Accounting Rules

The application uses the overhead accounting rules that you define to determine when and how overhead costs should be calculated. Overhead calculations are based on cost element pools or cost element groups.

Overhead accounting rules are defined at the cost organization book level. You can set the calculations to absorb overhead at the level of the cost organization, inventory organization, item category, or item.

Using Expense Pools and Cost Element Groups to Calculate Overhead Absorption: Example

This example illustrates how to use expense pools and cost element groups to define overhead accounting rules, and calculate overhead absorption for transactions.

Scenario

Your cost organization is a bicycle retail store with monthly overhead costs of $10,000 for rent, $500 for water, $1,500 for electricity, and $1,000 for gas. You have additional costs of $50 freight per incoming receipt; and $10 inspection fees per unit. You want to calculate overhead absorption for 5 transactions during the month, 2 receipts of bike X, and 3 receipts of bikeY.

Transaction Details

You could combine the water, electricity, and gas costs into one utility expense pool of $3,000. Then define the expense pools on the Manage Overhead Expense Pools page as follows.

Next define a Materials cost element group on the Manage Overhead Cost Element Groups page. This cost element group will be used to calculate overhead costs as a percentage of material costs. Your material costs are $500 per unit for bike X, and $300 per unit for bike Y.

Finally, you want overhead costs to include cost organization administrative and inventory organization facilities costs.

Analysis

Define the overhead accounting rules and absorption rates so that, over the course of the month, the total amount absorbed by the transactions will equal the overhead expense pools.

Resulting Overhead Costs

Following are the overhead cost calculations based on the rules defined.

Overhead Accounting Rules: Explained

Overhead accounting rules establish how to absorb overhead costs into inventory value and into cost of goods sold. The overheads processor checks for the rule based on the type of transaction. If a rule is defined and set to active, the processor applies overhead absorption to the transaction.

The following describes the overhead accounting rule attributes and cost drivers.

Overhead Accounting Rule Attributes

Associate an overhead accounting rule with a cost organization, cost book, and expense pool. The cost element from the expense pool definition is displayed automatically.

Also specify the following attributes:

• Transaction group (mandatory) and transaction type (optional). The transaction groups are predefined and they include one or more transaction types. You can define overhead rules at the transaction group level, or at the transaction type level. The transaction group options are Interorganization Transfers, Intraorganization Transfers, Inventory Transactions, Purchase Order Transactions, Sales Order Issues, and Sales Order Returns. The transaction group controls the transaction type options, which are more granular. If the transaction type detail is not provided, then the overhead absorption occurs for all transaction types within the transaction group.

• Transaction flow (mandatory). Options are Issue or Receipt.

• Inventory organization. Required only when absorbing overhead at the level of the inventory organization. If this attribute is blank, then the overhead is applied to all transactions in all inventory organizations under the cost organization.

• Category name and item. Required only if you are absorbing overhead at the item category or item level.

Cost Drivers

In addition to the attributes, specify the cost drivers for the rule.

The cost drivers include:

• Cost basis (required). Options are Per Lot, Per Transaction, Per Unit, or Percentage Value. Lot is based on the standard lot size defined in the item master. The processor divides the per lot overhead rate by the standard lot size to arrive at the per unit overhead cost. For example, suppose the lot size is 100 units, the overhead rate is $10 per lot, and the quantity is 150 units; then the overhead cost per unit is $10/100 = $0.1; and the overhead absorbed is $0.1 * 150.

• Based on. Mandatory if the cost basis is Percentage Value, and it specifies the cost element group that the percentage is based on.

• Rate (mandatory). Represents either the overhead percentage amount that you want to apply to the predefined cost element group, or the currency amount that you want to apply per unit or per transaction.

• Absorption type (mandatory). Options are Include in Inventory, and Expense. The following are examples of different kinds of absorption:

  • Absorb to inventory value when overhead is applied to incoming transactions, including transfers from other inventory organizations.

  • Absorb and redirect as a period expense when overhead is applied to incoming transactions.

  • Absorb overhead from the expense pool and redirect to cost of goods sold when overhead is applied to outgoing transactions.

FAQs for Define Overheads

Can I delete or inactivate a cost element group?

Yes. You can inactivate a cost element group by first inactivating all rules where it is referenced. However, you cannot delete a cost element group after it has been used to define an overhead accounting rule because historical records are maintained for audit purposes.

Can I delete or inactivate an expense pool?

Yes. You can inactivate an expense pool by first inactivating all rules where it is referenced. However, you cannot delete an expense pool after it has been used to define an overhead accounting rule because historical records are maintained for audit purposes.

Can I delete or inactivate an overhead accounting rule?

Yes. You can inactivate overhead accounting rules. However you cannot delete overhead accounting rules that have been used to calculate overhead absorption in any transactions because historical records are maintained for audit purposes.

Define Subledger Accounting Rules

Creating Accounting Method: Explained

Accounting methods group subledger journal entry rule sets together to define a consistent accounting treatment for each of the accounting event classes and accounting event types for all subledger applications. The grouping allows a set of subledger journal entry rule sets to be assigned collectively to a ledger.

For example, a subledger accounting method entitled US GAAP can be defined to group subledger journal entry rule sets that adhere to and comply with US Generally Accepted Accounting Principles (GAAP) criteria.

By assigning a different subledger accounting method to each related ledger, you can create multiple accounting representations of transactions.

Accounting rules can be defined with either a top down, or a bottom up approach. When defining subledger accounting rules from the top down, you will initially define the accounting method followed by components of each rule, which will need to be assigned to it. When defining subledger accounting rules from the bottom up, you will initially define components for each rule and then assign them as required.

The Create Accounting program uses the accounting method definition with active journal entry rule set assignments to create subledger journal entries.

When an accounting method is initially defined, or after modifying a component of any accounting rule associated to the assigned journal entry rule set, its status changes to Incomplete.

The accounting method must be completed, by activating its journal entry rule set assignments, so that it can be used to create accounting.

The following definitions are utilized to define the journal entries, and are applied as updates to the accounting method:

• Updates to the predefined accounting method

• Assignment of journal entry rule sets for an accounting event class and/or accounting event type from the accounting methods page

• Assignment of accounting methods to ledgers

• Activation of subledger journal entry rule set assignments

Updates on Predefined Accounting Method

You may update a predefined accounting method by end dating the existing assignment and creating a new assignment with an effective start date.

Assignment of Journal Entry Rule Set for Accounting Event Class and Accounting Event Type

You create the assignment of a journal entry rule set for an accounting event class and accounting event type using the accounting method page.

The following should be considered for assigning rule sets:

• If the accounting method has an assigned chart of accounts, you can select journal entry rule sets that use that same chart of accounts, or that are not associated with any chart of accounts.

• Select an option to assign existing journal entry rule sets or define a new one.

Assignment of Accounting Methods to Ledgers

If the accounting method has an assigned chart of accounts, it may only be used by ledgers that use the same chart of accounts.

If the accounting method does not have an assigned chart of accounts, the accounting method can be assigned to any ledger.

Activation of Subledger Journal Entry Rule Set Assignments

You can activate the subledger journal entry rule set assignments from the Accounting Method page. You can also submit the Activate Subledger Journal Entry Rule Set Assignments program to validate and activate your accounting setups.

Fusion Setup Flow

The figure below shows the relationship of components making up an accounting method as described in the above text.

Creating Subledger Journal Entry Rule Sets: Explained

Subledger journal entry rule sets provide the definition for generating a complete journal entry for an accounting event.

Select the option to define the subledger journal entry rule set for a particular accounting event class or accounting event type.

If you are using multiple ledgers to meet divergent and mutually exclusive accounting requirements, you can vary journal entry rule sets by ledger. Each of the subledger journal entry rule sets can meet a specific type of accounting requirements.

For example, use US Generally Accepted Accounting Principles (GAAP) oriented subledger journal entry rule sets for a ledger dedicated to US GAAP reporting, and French statutory accounting conventions for a ledger dedicated to French statutory reporting. These two sets of definitions have differences based on the setup of the various components that make up their subledger journal entry rule sets.

Seeded subledger journal entry rule sets are provided for all Oracle subledgers. If specific requirements are not met by seeded subledger journal entry rule sets, users can create new ones of copy the seeded definitions and then rename and modify the new copied definitions and their assignments.

Subledger journal entry rule set assignments can be made at two levels, header and line. The following are the subcomponents of a subledger journal entry rule set:

• Description rules

• Journal line rules

• Account rules

• Supporting references

Assignment at Header Level

Header assignments define subledger journal header information and line assignments define journal line accounting treatment.

A header assignment includes the following:

• Accounting date (required)

• Accrual reversal accounting date (optional)

• Description rule (optional)

• Supporting references (optional)

Assignment at Line Level

You can define multiple subledger journal entry rule sets for an accounting event class or accounting event type. A single journal entry is generated per accounting event per ledger using the line assignments from the journal entry rule set assigned to the accounting event class or accounting event type.

The following can be assigned to a journal entry line:

• Journal line description rule

• Journal line rule

• Account rule

• Supporting references

Assignment of Description Rules

If a description rule is defined with sources, the sources must also be assigned to the accounting event class that is assigned to the journal entry rule set. The description rule may be assigned at either the header or line level of the journal entry or to both levels.

Assignment of Journal Line Rules

When assigning the journal line rule, you must identify the line type: Gain, Loss, Gain or Loss, Credit, or Debit. The journal line rule must be assigned to the same accounting event class as the one assigned to the subledger journal entry rule set.

When assigning a journal line rule that is enabled for accounting for a business flow, the account combination and certain accounting attribute values are copied from its related journal line having the same business flow class as the current line. Optionally, copy the description rule into the current line instead of assigning a separate description rule.

When assigning a journal line rule that is enabled to copy from the corresponding line within the same journal entry, you have the option to copy the account combination, the segment value, or the line description from the corresponding line into the current line.

Assignment of Account Rules

The account rule assignment will define which accounts will be used for the subledger journal line. If the account rule is setup with a chart of accounts, it must have the same chart of accounts as the one assigned to the journal entry rule set. When account rules are defined with sources, the sources must also be assigned to the accounting event class that is assigned the journal entry rule set.

There are two types of account rules:

• Account Combination Rule: Assign an account combination rule to derive the account combination.

• Segment Rule: Assign a segment rule to derive a specific segment of an account. For example, a cost center or a natural account segment.

Assignment of Supporting References

Supporting references may be assigned at the header or line level of the journal entry to capture transaction values on the journal entry header or lines. If the supporting reference segments are assigned multiple sources, at least one source must also be assigned to the accounting event class that is assigned the journal entry rule set.

Journal Line Rules: Explained

Journal line rules are defined within the context of accounting event classes. A journal line rule can be used in a subledger journal entry rule set that has the same event class. You may also assign conditions to the journal line rule.

Journal Line Rules

Journal line rules are assigned to journal entry rule sets.

To create a journal line rule, select values for options such as:

• Side (Debit, Credit, Gain or Loss)

  For example, when an Oracle Fusion Payables invoice is generated, the liability account should normally be credited. The journal line rule must therefore specify the Side option as Credit. On the other hand, the payment of the Payables invoice must be accounted with a debit to the liability account. A separate journal line rule must be defined to create this debit line.

• Merge Matching Lines: To summarize subledger journal entry lines within each subledger entry. Journal entry lines with matching criteria are merged.

• Accounting Class

  • Select an accounting class to classify journal entry lines.

  • For example, when a validated Payables invoice is accounted, the Item Expense and Liability journal lines are created. In this case, the journal line rules used in the accounting rules are assigned Item Expense and Liability accounting classes respectively.

• Conditions: To restrict the use of a journal line rule by controlling when a particular journal line rule is used by the Create Accounting program.

• Accounting Attributes: When creating a journal line rule, accounting attribute assignments are automatically established based on the default accounting attribute assignments for that journal line rule's accounting event class. You can override this default mapping of standard sources to accounting attributes. The list of values for the source override includes all sources assigned to the accounting attribute for the event class associated with the journal line rule.

• Advanced Options

  • The Subledger Gain or Less Option: Applies only to amount calculations for the primary ledger. Gain or loss amounts are not converted to reporting currency or non-valuation method secondary ledgers. If the option is selected, the journal line holds the gain or loss amounts calculated by the subledger.

    The gain or loss amount is calculated as the difference in applied amounts due to fluctuations in exchange rates based upon conversion to the ledger currency. Foreign exchange gain or loss amounts occur when two related transactions, such as an invoice and its payment, are entered in a currency other than the ledger currency, and the conversion rate fluctuates between the times that the two are accounted.

  • The Rounding Class Option: Along with the transaction rounding reference group journal lines together and calculates transaction rounding. Subledger transaction rounding differences can occur when a transaction has multiple related applied-to transactions, such as when a Receivables invoice has multiple associated receipts.

  • The Link Journal Lines Option: Determines whether the journal line rule is set up to establish a link between the accounting of transactions that are related both within the same application, and across applications. The alternatives are described in this table:

Defining Conditions for Journal Line Rules

You may set conditions to specify whether the journal line rule will be used to create a subledger journal entry line. If the conditions are true, the line rule is used to create a subledger journal entry line. Use sources to create these conditions.

For example, you can set up a condition that will create a journal line to record tax, only if there is tax for an invoice. The line type and account class mentioned here are examples of sources.

• The condition for a Payables invoice tax journal line rule could be:

  • Where Line Type = Tax

  • When this condition is true, there is tax for a payables invoice line. A journal entry line is created to record the accounting impact of the tax.

• Similarly, the condition for a Oracle Fusion Receivables invoice tax journal line rule could be:

  • Where Account Class = Tax

  • In this case, if there is an account class of Tax, the journal line is used to record the accounting impact of the tax.

Another example is a condition that creates a journal line for freight when there are freight charges on an invoice.

Journal line rule conditions determine whether a journal line rule and its associated account rules and description rules, are used to create the subledger journal entry line.

Creating Conditions: Examples

The following illustrates an example of defining an account rule with a condition.

Example 1: Custom Real Estate Application Account Rule Condition Example

This is an example to define an account rule for assignment for a loan journal line. The account rule has two priorities, a mapping set and a constant.

• The first priority will create an output for an account based on the mapping set rule definition.

  • A condition is created on the first priority rule. This rule will only be used if the condition below is met.

    • The condition is Credit Status must not be null.

    • The accounts derived from the mapping set rule will be used if the Credit Status has a valid value. Otherwise, the accounts derived from the entered constants value from the second priority will be used.

The following table describes the setup of the condition on the first priority:

The second priority will create an output from a constant value (0.9100030.50034206331.0.0.0). There is no condition associated with the second priority.

Example 2: Oracle Fusion Assets Account Rule Condition Example

This is an example of a rule for a capital purchase. The rule is to be applied only if the distribution account cost center is the same as the liability account cost center and the asset tracking option is Yes. This condition can be expressed as:

• Where Distribution Cost Center = Liability Cost Center and Asset Tracking option = Yes

The following tables describe the setup of the condition:

The following two rows of data are used in the accounting event, to which the account rule and condition applies.

Account Rule Condition Example: Accounting Event Data

In the Accounting Event Data table above, assume the cost center segment is the second segment. When the account rule with this condition is used to derive the account for the transaction, the account rule is applied to derive the account of Invoice 1 only. For Invoice 2, even though the assets tracking option is set to Yes, the cost center for the Distribution account and Liability account are not the same. Both conditions must be met in order for the rule to apply.

Account Rules: Explained

Account rules are used to determine the accounts for subledger journal entry lines. In addition, you can specify the conditions under which these rules apply. Using these capabilities, you can develop complex rules for defining accounts under different circumstances to meet your specific requirements. You can define account rules for an account, segment, or value set.

Account Rules by Account

Define account rules by account to determine the entire account combination. For example, an account rule defined by account can be used to determine the complete supplier liability account in Oracle Fusion Payables.

Account Rules by Segment

Define segment rules to derive a specific segment of the general ledger account. For example, a particular segment like the company segment can be determined from the distribution account. Another segment can be determined with the use of a constant value. Creating the account one segment at a time offers greater flexibility, but also requires more setup.

Use both segment based and account based rules to derive a single account. Segment specific rules are used, where they are defined, and take the remaining values from an account based rule. For example, you can select an account rule which is for all segments and also separately select a rule which is for one particular segment. Segment specific rules take precedence over the all segments account based rule.

Combine account rules with segment rules. In this case, the segment value is derived from the segment rule to override the corresponding segment of the account. However, if the segment rule has conditions associated with the priorities and none of the conditions are met, no override occurs and therefore, the segment value is derived from the account rule.

Account Rules by Value Sets

In the absence of a chart of accounts, you may define account rules based upon value sets. This enables you to share the same rule between more than one chart of accounts if the segments in these charts of accounts share the same value set.

Sharing Account Rules across Applications

You may share account rules across applications in the following ways.

• Assign an account rule from the same or a different application to a journal line rule in the subledger journal entry rule set. For example, to derive an expense account for journal line rule Expense, assign the Projects Cost Account rule owned by Oracle Fusion Projects to the Payables journal line rule Expense.

• Create an account rule based on an account rule from another application and assign it to a journal line rule. For example, you may create a new account rule Invoice Expense Account referencing Project Cost Account assigned in the Priorities region. You may attach the Invoice Expense Account rule to the journal line rule Expense in the journal entry rule set.

Account Rules and Mapping Sets

Mapping sets can be used to associate a specific output value for an account or segment. You can use mapping sets in account rules to build the account.

Account Rules Conditions

In the account rules you may specify conditions for each rule detail line. Priorities determine the order in which account rule conditions are examined. When the condition is met, the rule associated with that priority is used. Depending on which of the defined conditions is met, a different account rule detail is employed to create the account.

The Create Accounting program evaluates conditions based on the priority of the rule detail. When the condition is met, the rule detail is applied.

Creating Account Rules: Points to Consider

You can define an account rule using the following rule types:

• Account combination

• Segment

• Value set

Account Combination Rules

Set up account combination rules based upon the following value types:

1. Source Value Type: Derive the account combination by specifying a source. Sources that have been set up as accounts can be assigned to an account combination rule. Oracle Fusion Subledger Accounting then obtains the code combination identifier from the source.

2. Constant Value Type: Establish the account as a constant value.

   For example, the constant could be a completed account combination from the chart of accounts specified. An example is the account combination, 01.000.2210.0000.000. This is the simplest way to derive an account.

3. Mapping Set Value Type: Derive the account combination by referencing a mapping set. Set up a mapping set to determine the complete account combination from the chart of accounts specified.

4. Account Rule Value Type: Derive the account by referencing another account rule.

   The chart of accounts does not need to be specified when defining this type of rule. If the account rule has a chart of accounts assigned, then all the related account rules must use the same or no chart of accounts.

Segment Rules

Set up segment rules as follows:

• When a chart of accounts is specified, create a rule to derive the value for a specific segment from the chart of accounts.

• If the chart of accounts is not specified, create a rule to derive the value for an account segment with a specific qualifier.

Set up segment rules using the same methods discussed in the preceding Account Combination Rules section. By specifying different value types, users can select the way in which the segment value is derived.

Value Set Rules

Value set based rules can be created when a chart of accounts is not specified. This enables you to share the same rule between more than one chart of accounts if the segments in these charts of accounts share the same value set.

Set up value set based rules using the same methods discussed in the preceding Account Combination Rules section.

Creating Description Rules: Explained

Use descriptions rules to define the elements of a description that appears on the subledger journal entry at the header and/or the line. The definition determines both the content and sequence in which the elements of the description appear. You can assign a condition to a description rule to determine that the description is selected for display if the condition is satisfied.

Description Rule Definition

A description rule can be defined with combinations of source and literal values. If sources are used in the rule, the accounting event class associated with the sources determines in which subledger journal entry rule set the description rule can be selected and used.

Build descriptions using the available sources for the application.

The following is the description details that have been entered, using a literal and a source:

• Loan Origination Date = Origination Date

  • Literal = Loan Origination Date

  • Source = Origination Date

Assuming that the source value of the Origination Date is 11/01/11, then a journal entry that has the above description rule attached will have the description, Loan Origination Date 11/01/11.

Creating Supporting References: Explained

Supporting references can be used to store additional source information about a subledger journal entry either at the header or line level.

Sources are assigned to supporting reference segments to indicate which transaction values should be captured on subledger journal entries. The segments are grouped into one supporting reference.

Supporting references that have the option for maintain balances set to Yes, establish subledger balances for a particular source and account.

You may want to use Supporting Reference balances for supporting:

• Reconciliation back to the source systems

• Profit and loss balances by dimensions not captured in the chart of accounts

Supporting Reference Assignment

If the information requirement is purely informational, and not needed for reconciliation or balances, you may consider using description rules to store the source values.

There are several key points to consider when assigning supporting references:

• Define a maximum of five segments for a supporting reference. Assign different sources to each segment.

• Assign only one source from the same accounting event class and application to a supporting reference segment.

• Assign only supporting references with header level sources to the header level of a journal entry rule set.

• Assign supporting references with header and line level sources to the line level of a journal entry rule set.

• Select the balances option in the definition of the supporting reference, to have balances only maintained when the supporting reference is assigned at the line level. For supporting references for which balances are maintained, you can specify whether the balances at the end of a fiscal year are carried forward to the next fiscal year.

As an example:

• A loan information supporting reference can be defined to track two segments:

  • Credit status

  • Loan contract number

Sources will be assigned to each of these segments and the source values for each of these segments will be used to create separate balances.

Accounting Event Model: Explained

Accounting events represent transactions that may have financial significance. Events with significantly different fiscal or operational implications are classified into different accounting event types. Event types categorize accounting events. Accounting definitions in the Oracle Fusion Accounting Hub are based on event types. An event type must be unique within an application, process category, and event class.

Examples of accounting events are issuing a loan and disposing of an asset. Financial accounting information can be recorded for these events and accounted by the Create Accounting process.

Accounting Process Overview

The figure below provides a high-level overview of the process used to create subledger journal entries and is described in the succeeding text.

The above diagram illustrates the process used to create subledger journal entries.

The Create Accounting program uses the transaction objects data to create subledger journal entries. For example, if a subledger journal entry rule set specifies that the customer name should appear in the description of a subledger journal entry line, then the customer name value is taken from the customer name source data provided by the transaction objects.

When transactions are committed in a subledger, accounting events are captured and stored in subledger accounting.

The Create Accounting program identifies all accounting events eligible to be processed. For each of these events, the transaction objects process provides the Create Accounting program with transaction objects data (source information). This is the contextual data of the transaction, such as amounts and accounting dates.

When the Create Accounting program is run, journal entry rule set definition and accounting transaction objects data are applied to the transaction object data to create subledger journal entries.

Subsequently, these entries are summarized and transferred to Oracle Fusion General Ledger.

Accounting Event Model

Define accounting events for non-Oracle source systems from a business perspective. Determine what activities or transactions occur in your source system which may create a financial impact.

Events are captured when transactions are committed in the subledgers, or they may be captured during end of day or period end processing. As an example, a loan is originated, possibly adjusted, interest is accrued, and then the loan is paid or canceled. The accounting events representing these activities can create one or more subledger journal entries, and subsequently link the originating transaction to its corresponding journal entries.

An example of an accounting event model setup for a loan application is shown below:

Process Categories

Process categories can be used to restrict the events selected for accounting when users submit the Create Accounting program. Selecting a process category indicates that all associated accounting event classes and their assigned accounting event types are selected for processing.

Event Classes

You can assign a transaction view, system transaction identifiers, and optionally user transaction identifiers for an event class in the Event Class window.

At least one system transaction identifier must be defined for the accounting event class. System identifiers are used to link accounting events with transactions from subledger applications.

Optionally, you may define user transaction identifiers. You can specify up to ten columns from the transaction views that are available for inquiry and reports. The user transaction identifiers help provide contextual information for inquiry and reports.

The transaction view should include all columns that have been mapped to system transaction identifiers for the accounting event class as well as the user transaction identifiers.

Optionally, you can define the processing predecessor for an accounting event class. The Processing Predecessor establishes an order in which the Create Accounting program processes events selected for accounting.

Event Types

Specify whether an accounting event has accounting or tax impact for an accounting event type. When the Create Accounting program is submitted, it only accounts business events that are enabled for accounting.

Transaction Identifiers

There are two types of transaction identifiers:

• System transaction identifiers

• User transaction identifiers

System Transaction Identifiers

System transaction identifiers provide a link between an accounting event and its associated transaction or document.

System transaction identifiers constitute the primary key of the underlying subledger transaction. Typically, the identifier is the name of the surrogate key column on the transaction (header) associated with the accounting event.

Whenever an accounting event is captured, the values of the system transaction identifiers are stored on the accounting event record along with other event data. Whenever system transaction identifiers are defined for the accounting event, the event capture mechanism validates that the system transaction identifiers are populated.

User Transaction Identifiers

User transaction identifiers constitute the user-oriented key of the underlying subledger transaction. They are typically drawn from one or more database tables.

These identifiers are primarily used in accounting events inquiry and on accounting reports. Users use these identifiers to uniquely identify underlying transactions.

The Oracle Fusion Accounting Hub displays user transaction identifiers on accounting event reports and inquiries.

User transaction identifiers enable users to uniquely identify any subledger transaction. The transaction data that identifies the transaction varies by accounting event class. Accounting event reports and inquiries display the transaction identifiers and their labels appropriate for the corresponding event class. The user transaction identifiers can be displayed for an event regardless of its status. This includes the case where the accounting event has not been used to create subledger journal entries due to an error or the cases where it has not been processed. The user transaction identifier values are displayed at the time that the accounting event reports and inquiries are run. If a transaction identifier value has changed after the accounting event was captured, the accounting event reports and inquiries reflect the change.

Register Source Systems: Critical Choices

Subledger applications can support third party control account type and calculate reporting currency amounts.

Support Third Party Control Account Type

You can set up the subledger application to support customer, supplier, or both third party control account types (customer and supplier).

Calculate Reporting Currency Amount

If the subledger application is configured to calculate reporting currency amount, there is no need to provide reporting currency information in the transaction objects.

Additional Considerations

The following are additional considerations when creating a subledger application:

1. Determine the subledgers requirement. For example, how many subledgers are to be created? This may depend on what security your company wants to have over its accounting rules.

   • Using the same subledger allows you to share subledger accounting rules, and lets you report across all data easily.

   • Using separate subledgers provides more security across applications and less data in each process run providing better performance. Specific benefits are:

     • If you run two Create Accounting requests at the same time for different applications, they are much less likely to contend for database resources. The requests will perform better, as the indexes are tuned for running with different applications instead of running for different process categories within the same application.

     • It allows you to efficiently process different sets of data (different applications) at different times during the day instead of running it as one process.

2. Determine the transaction objects requirements. These requirements determine what source data is required to successfully create subledger journal entries from transactions that are captured in transaction objects and shared in reference objects.

3. Analyze accounting events to determine what events to capture for the subledger application.

   Create programs to capture accounting events using APIs (application programming interfaces) that are provided as follows:

   • Get Event Information APIs to get event information related to a document or a specific event.

   • Create Event APIs to create accounting events, individually or in bulk.

   • Update Event APIs to update events and keep them consistent with related transaction data.

   • Delete Event APIs to delete events.

4. Determine how often to capture accounting events, populate transaction objects, and run the Create Accounting program. This may depend on the immediacy and volumes of accounting requirements in your company.

Transaction Objects: Points to Consider

You may assign transaction and reference objects for each accounting event class in the subledger application. Sources are generated based on the transaction objects and are assigned to the corresponding accounting event classes.

Sources are used to create accounting rules. Subledgers pass information to the application by populating transaction object tables. The columns in these tables are named after the source codes. Transaction and reference objects hold transaction information that is useful when creating journal entry rules for accounting. The transaction and reference objects are defined for an accounting event class so that source assignments to accounting event class can be generated using these objects.

Transaction Objects

Transaction objects refer to the tables or views from which the Create Accounting program takes the source values to create subledger journal entries. Source values, along with accounting event identifiers, are stored in the transaction objects. The Create Accounting program uses this information to create subledger journal entries.

You have several options. You can:

• Create new tables as the transaction objects and create a program to populate them.

• Use views of your transaction data as the transaction objects.

• Use your transaction data tables as the transaction objects.

The transaction objects and or views must be accessible to the Create Accounting program. Typically, an ETL (extract, transformation, and load) program is used to take values from the source system and load them into the database used by the Create Accounting program. The ETL process is done outside of the Create Accounting program processing.

The following are transaction object types:

• Header transaction objects

  • Implementers need to provide at least one header transaction object for each accounting event class. Header transaction objects store one row with untranslated header source values for each accounting event. The primary key of a header transaction object is the event identifier.

    Transaction details that are not translated, and whose values do not vary by transaction line or distribution, should normally be stored in header transaction objects. Examples of sources normally stored in header transaction objects include the Loan Number for a loan or the Contract Number for a contract.

• Line transaction objects

  • Line transaction objects are relevant when there are details for the accounting event that vary based upon transaction attributes. For example, a mortgage transaction for loan origination may have multiple amounts, each related to different components of the loan. There may be a loan origination amount, closing cost amounts, and escrow amounts. Each of these amounts could be captured as separate lines, along with an indication of the amount type

    Line transaction objects store untranslated line level source values. There should be one row per distribution, identified by a unique line number. The primary key of a line transaction object is the event identifier and transaction object line number. Transaction details that are not translated and whose values vary by transaction line or distribution are normally stored in line transaction objects columns. Examples include the Loan Number for a loan payment.

• Multi-Language Support (MLS) transaction objects

  • MLS transaction objects are relevant to applications that support the MLS feature. MLS transaction objects store translated source values. There should be one row per accounting event and language. The primary key of a header MLS transaction object is the event identifier and language. The primary key of a line MLS transaction object is the event identifier, transaction object line number, and language.

    Transaction details that are translated, and whose values do not vary by transaction line or distribution, are normally stored in header MLS transaction object columns. Examples include Loan Terms for a commercial loan. Implementers can avoid having to store source values in header MLS transaction objects by using value sets and lookup types.

    Transaction details that are translated, and whose values vary by transaction line or distribution, should normally be stored in the transaction object in columns defined in a line MLS transaction object.

Reference Objects

Reference objects are useful for storing information that is used for creating subledger journal entries. This information may not be directly from the source system or may be used for many entries, thus making it redundant. Use reference objects to share sources information across applications.

For example, store customer attributes, such as the customer class or credit rating in a reference object, and then, use it to account for different journal entries in a loan cycle, such as loan origination or interest accrual. Store information, such as bond ratings and terms, and use it to account for entries across the life of bonds, such as interest accruals or bond retirement.

Reference objects can either have a direct relationship to transaction objects (primary reference object), or be related to other reference objects (secondary).

Managing Accounting Sources: Critical Choices

Sources are a key component for setting up accounting rules. Sources represent transaction and reference information from subledger applications or reference systems. Contextual and reference data of transactions that are set up as sources can be used in accounting rules definitions.

Oracle Fusion Applications predefines sources for its subledger. When determining what sources should be available for non-Oracle applications, it is helpful to begin the analysis by considering which information from your systems is accounting in nature. Examples of sources that are accounting in nature include general ledger accounts that are entered on transactions, the currency of a transaction, and transaction amounts. Sources that are not always required for accounting rules include items that are related to the transaction for other purposes than accounting. Examples of information that may not be specifically for accounting, but which may be useful for creating subledger journal entries, are transaction identification number (loan number, customer number, or billing account number), counter party information, and transaction dates.

Provide a rich library of sources from your subledger applications for maximum flexibility when creating definitions for subledger journal entries. Predefined sources are provided as part of the startup data of the application.

Sources are assigned to accounting event classes by submitting the Create and Assign Sources program.

There is a distinct difference between sources and source values. Sources are representations of the data from transactions used to create accounting rules. Source values are used by the Create Accounting program to create subledger journal entries based upon source assignments to accounting rules.

Sources

Sources must be registered prior to creating accounting rules. This is a predefined step which must be undertaken before the application can be used to create subledger journal entries.

To set up appropriate journal entry rule sets, users and those implementing need to understand the origins, meaning, and context of sources. Use business oriented names for sources to allow accountants and analysts to effectively create accounting rules.

• Enables users to easily identify a source.

• Ensures consistency in nomenclature.

Source Values

Source values are stored in transaction objects. They are used to create subledger journal entries for the events. To enable the creation of subledger journal entries, first complete the definition of the sources and storing of the source values in the transaction objects. Transaction objects can be tables or views.

Accounting Attribute Assignments: Points to Consider

The Create Accounting program uses the values of sources assigned to accounting attributes plus accounting rules to create subledger journal entries. Almost all accounting attributes have sources assigned at the accounting event class level. Depending on the accounting attribute, the accounting attribute assignment defaulted from the accounting event class can be overridden on journal line rules or subledger journal entry rule sets.

Once sources are assigned to accounting event classes, they are eligible for assignment to accounting attributes for the same accounting event classes.

The Create Accounting program uses these assignments to copy values from transaction objects to subledger journal entries. For example, you may map the invoice entered currency to the subledger journal entry entered currency.

Each accounting attribute is associated with a level:

1. Header: To be used when creating subledger journal entry headers.

2. Line: To be used when creating subledger journal entry lines.

The types of accounting attributes values are as follows:

Values that are Subject to Special Processing

You may have values that are subject to special processing or values that are stored in named columns in journal entry headers and lines.

Examples of accounting attributes are Entered Currency Code and Entered Amount.

Values that Control the Behavior of the Create Accounting Program

You may have values that control the behavior of the Create Accounting program when processing a specific accounting event or transaction object line.

An example of accounting attributes of this type is Accounting Reversal Indicator.

Accounting Attributes

Accounting attribute groups are represented in the tables below:

Accounted Amount Overwrite

• The accounted amount overwrite accounting attribute indicates whether the accounted amount calculated by the Create Accounting program should be overwritten by the value of the accounted amount accounting attribute. If the source value mapped to Accounted Amount Overwrite is 'Y', then an accounted amount must be provided.

Accounting Date

• The accounting date attribute is relevant to all applications. The Create Accounting program uses it to derive the accounting date of journal entries. Typically, the event date system source is assigned to the accounting date attribute.

• The Accrual Reversal GL Date accounting attribute is relevant to applications using the accrual reversal feature. Users can assign system and standard date sources to the Accrual Reversal GL Date in the Accounting Attribute Assignments page. When the Accrual Reversal GL Date accounting attribute returns a value, the Create Accounting program generates an entry that reverses the accrual entry.

Accounting Reversal

• Accounting reversal accounting attributes are relevant to applications that wish to take advantage of the accounting reversal feature. The Create Accounting program uses them to identify transaction (distributions) whose accounting impact should be reversed. For the Create Accounting program to successfully create a line accounting reversal, the accounting reversal indicator, distribution type, and first distribution identifier should always be assigned to sources. The definition of the accounting reversal distribution type and distribution identifiers mirrors the definition of the distribution identifiers.

Business Flow

• The business flow accounting attributes are referred to as 'applied to' accounting attributes. If a transaction is applied to a prior transaction in the business flow, the transaction object must populate sources assigned to 'applied to' accounting attributes with sufficient information to allow the accounting program to uniquely identify a transaction object line for a prior event in the business flow. When deriving accounting data from a previous event in the business flow, the accounting program searches for a journal entry line for the prior event using a combination of the 'applied to' accounting attributes and the business flow class of both journal entries.

  The Applied to Amount accounting attribute is used to calculate the accounted amount and gain or loss in cross-currency applications when business flows are implemented. This attribute value is used to calculate the accounted amount when a source is mapped to the Applied to Amount attribute on a journal line type and the entered currency is different than the original currency entered.

Distribution Identifier

• Distribution identifiers accounting attributes are relevant to all applications. The distribution identifier information links subledger transaction distributions to their corresponding journal entry lines. In addition, many of the Oracle Fusion Subledger Accounting features, including accounting reversals, rely on the correct definition and storing of distribution identifiers in the line transaction objects. The distribution type and first distribution identifiers are always assigned to sources. If a transaction distribution is identified by a composite primary key, additional distribution identifiers are assigned to standard sources, as appropriate. Values for the distribution type and distribution identifiers are always stored in accounting transaction objects. The combinations of the values of the system transaction identifiers with the values of the distribution identifiers uniquely identify a subledger transaction distribution line.

Document Sequence

• The document sequence accounting attributes are relevant to applications that use the document sequencing feature to assign sequence numbers to subledger transactions. The Create Accounting program uses them to provide a user link between subledger transactions and their corresponding subledger journal entries. Assign all document sequence accounting attributes to sources or do not assign any. In addition, the Document Sequence Category Code is made available as an Accounting Sequence Numbering control attribute.

Entered Currency

• Entered currency accounting attributes are relevant to all applications. The Create Accounting program uses them to populate the journal entry line entered currency code and amounts. The entered currency accounting attributes must always be assigned to sources. The sources assigned to the entered currency accounting attributes must always contain a value. For event classes that support cross currency transactions and therefore, more than one entered currency and entered currency amount, multiple event class accounting attribute assignments are created.

Ledger Currency

• Ledger currency accounting attributes are relevant to all applications that use the Create Accounting program. The Create Accounting program uses them to populate journal entry accounted amounts. If a transaction's entered currency is different from the ledger currency, the Create Accounting program copies the conversion date, conversion rate, and conversion rate type to the corresponding journal entry lines. If the entered currency is the same as the ledger currency, the Create Accounting program ignores the conversion type and conversion rate. For event classes that support foreign currency transactions and therefore more than one exchange rate and reporting currency amount, multiple event class accounting attribute assignments are created.

Tax

• The tax accounting attributes are relevant to applications that uptake the tax initiative. The tax team uses the tax accounting attributes to link subledger transaction tax distributions to their corresponding journal entry lines. Oracle Fusion Tax specifies which tax reference values are mandatory in transaction objects and are assigned to standard sources.

Third Party

• Third party accounting attributes are relevant to subledger applications that use third party control accounts. The third party accounting attributes link suppliers and customers to their corresponding subledger journal entry lines in the supplier and customer subledgers. For all subledger transactions that represent financial transactions with third parties, all third party accounting attributes have sources assigned. If a transaction line is associated with a customer or supplier, the transaction objects need to include values for all sources mapped to third party accounting attributes for the event class.

Exchange Gain Account, Exchange Loss Account

• The Create Accounting program determines whether it is a gain or loss and derives the account combination based on whether the journal line rule is defined. If the gain or loss journal line rule is defined, the account rule assigned to the journal line rule is used to determine the gain or loss account to use. If the gain or loss journal line rule is not defined, the gain or loss account assigned to the Exchange Gain Account and Exchange Loss Account accounting attributes is used.

Gain or Loss Reference

• The Gain or Loss Reference accounting attribute groups entry lines together when calculating exchange gain or loss. The accounted debit and accounted credit amounts for lines with the same gain or loss reference are combined. The total of accounted debit and total of accounted credit are compared to calculate the exchange gain or loss.

Transfer to GL Indicator

• The Transfer to GL accounting attribute is relevant to applications which create subledger journal entries that will never be transferred to the general ledger. The Transfer to GL process uses this accounting attribute to determine whether to transfer subledger journal entries to the general ledger.

  If the Transfer to GL accounting attribute is not assigned to a source, the Transfer to GL process transfers journal entries for the event class to the General Ledger.

  If the Transfer to GL accounting attribute is assigned to a source and the source is not populated, the Transfer to GL process transfers journal entries for the event class to the General Ledger.

FAQs for Define Subledger Accounting Rules

How can I create subledger account rules and subledger journal entry rule sets for cost management?

Create your subledger account rules on the Manage Account Rules page. It is recommended that you highlight the account rules predefined by Oracle, copy, and modify them as needed.

Create your subledger journal entry rule sets on the Manage Subledger Journal Entry Rule Sets page. It is recommended that you highlight the journal entry rule sets predefined by Oracle, copy, and modify them as needed. For each journal line rule specify the copied account combination rule.

Access both the Manage Account Rules page and Manage Subledger Journal Entry Rule Sets page from an Oracle Fusion Applications Functional Setup Manager implementation project.

Previous Next

Copyright ©  2011, Oracle and/or its affiliates. All rights reserved. Legal Notices

Contents Contact Us