TAB Whitepaper R9
TAB Whitepaper R9
TAB Whitepaper R9
November 2012
Disclaimer
The following is intended to outline our general product direction. It is intended for information
purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any
material, code, or functionality, and should not be relied upon in making purchasing decisions. The
development, release, and timing of any features or functionality described for Oracles products
remains at the sole discretion of Oracle.
1.
Introduction .................................................................................. 3
2.
Background ................................................................................. 4
3.
4.
5.
6.
4.1.
4.2.
4.3.
4.4.
4.5.
Source ............................................................................... 14
5.2.
5.3.
5.4.
5.5.
5.6.
5.7.
5.8.
6.1.
6.2.
7.
8.
Conclusion ................................................................................. 42
9.
1. Introduction
Transaction Account Builder (TAB) provides a flexible mechanism to derive accounting
flexfields for subledger transactions.
Purchase requisitions and purchase orders have several accounts stored on them. The three
mandatory accounts are:
Charge Account The account against which the money spent is finally withdrawn or
charged.
Variance Account Certain situations call for variances to be recorded for certain
kind of spending. An entry is created against this account for all such variances. E.g.
price variance between PO and invoice.
Accrual Account An intermediary account which records money spent for goods or
services that have been consumed or taken ownership of and that is yet to be
invoiced. An entry against this account is reversed once the money is physically spent
or the invoice is issued.
In addition to these three accounts, there are two other accounts for more advanced
procurement scenarios where there is an intercompany transaction involving a procuring
organization and a destination organization. Namely:
Destination Charge Account - The charge account belonging to the destination
organization
Destination Variance Account - The variance account belonging to the destination
organization
Business would like to automate the derivation of these accounts on transactions based upon
their corporate policies. There needs to be calculations done to build these accounts on
transactions such as a requisition or purchase order. The Subledger Accounting (SLA) engine
does that. The component of the engine which does it is known as Transaction Account
Builder or TAB.
In other words, TAB is the component of Subledger Accounting which is solely responsible for
building or defaulting the accounts on a transaction such that appropriate accounting entries
can be created against such transaction accounts.
2. Background
TAB is a new concept in Oracle Fusion Applications and it replaces all prior account generator
solutions. Before Oracle Fusion there was a similar need to default transaction accounts. That
need was fulfilled by different solutions. For instance, in Oracle E-Business Suite (EBS), Oracle
Purchasing uses the Account Generator Workflow to derive account code combinations on
purchase orders and requisitions. Oracle EBS Purchasing provides default Account Generator
processes for you to use. If the defaults do not satisfy your accounting requirements, you can
use the Oracle Workflow Builder to customize the default processes. Account Generator
Workflow has been obsoleted in Fusion and replaced by SLAs Transaction Account Builder
process.
Oracle Fusion delivers seeded account defaulting rules within SLA's transaction account
builder which aims to address the common defaulting scenarios of customers and also to
facilitate further rule extensions in place of customers/implementers having to plan it out
from scratch.
In PeopleSoft applications, ChartFields are used to define and default the account segments
in the transaction accounts. Each ChartField has its own attributes for maximum efficiency
and flexibility in recording, reporting and analyzing its intended category of data. Though,
PeopleSoft delivers a set of ChartFields and associated functionality that fully covers most
accounting and reporting requirements, ChartFields are designed to be configured by
customers to meet their specific requirements.
In JD Edwards, account generation is carried out by AAI (Automatic Accounting Instruction).
AAIs are rules that define the relationships between your day-to-day accounting functions
and your chart of accounts. In the General Accounting system, AAIs determine how to
distribute general ledger entries that the system generates. Each AAI is associated with a
specific general ledger account that consists of a business unit, an object, and optionally, a
subsidiary and is mapped to your chart of accounts.
There are a few ways TAB is envisioned to be better than its predecessors. For EBS Release
12 customers TAB configuration will be significantly easier than Workflow customization as it
will be within the SLA application instead of in a separate technology tool.
For both Peoplesoft and JDE customers the TAB configuration allows greater control over the
available sources and defaulting logic, since not all of the defaulting rules are currently
accessible for configuration.
Moreover, customers can reduce customized account defaulting definitions by sharing them
between applications. For instance, the account defaulting for Projects is used by Projects,
Purchasing, and Accounts Payable and can be shared by all three, but only defined once.
Accounts on purchase orders and requisitions are used as defaults by downstream accounting
transactions such as PO-matched invoices and receipts. Those transactions may have account
definition rules defined in SLA that will allow an override of some or all segments of the
account found on the PO. The exact flow of these accounts is complex and varies by the
account, and accounting options.
The following diagram is an overview of the general flow of data from defaulting on to the
purchase order, to its final usage in an accounting transaction.
Account Sources
(Reference Data)
Account Generator
Workflow (EBS)
PO Distribution
Account
Hard-coded logic,
some configurable
defaulting
(Peoplesoft)
User Updates
(Some data)
PO Distribution
Account
Defaulting Process
Ledger
Accounting
Transaction
Account
(Peoplesoft)
Use PO Distribution
Account
Additional Rules
Defined by Customer
SLA AMB Rules
(EBS R12)
(Fusion)
Removing in
Fusion
Customer
Defined
Figure 1
The TAB data is contained in the SLA data model, moving from workflow components. The
top level process in Transaction Account Definitions is the equivalent of the overall workflow
process, and it includes assigning rules to each Transaction Account Type defined by the
product.
In Workflow Purchasing had to pre-define the workflow attributes and pass them into the
Workflow process. The behavior in TAB is similar: Purchasing will define what sources may be
used for a particular account and pass them into TAB.
In EBS R12 users could write custom PL/SQL and add functions to the workflow to execute
that SQL and utilize the results in their workflow function. In Fusion TAB although there is no
support to define custom PL/SQL sources that execute during processing, TAB offers a
comprehensive set of seeded sources such that users will not need to define custom sources
in most cases.
In Oracle Fusion users also have the ability to define data in mapping sets and utilize them in
modified ADRs. This could also be used for customer-specific reference account data needed
to drive the account defaulting process.
Source Assignments
Application
Seeded Sources
(R12 WF attributes)
(DROP)Custom
Sources (R12 pl/sql)
Diagram Legend
Object
Explanation
Not Configurable
Configurable
Figure 2
4.1.
At the top level, there is Transaction Account Definition (TAD). Transaction Account Definition
defines the account rule assignments that are used to derive the transaction accounts on a
purchase order and requisition. This includes both rules which define the entire account
combination as well as rules which can define how certain segments of the account are
generated. In other words, TAD specifies which rules should be used to drive which accounts
on a procurement transaction. This leads to the next building block namely, Transaction
Account Types (TAT).
4.2.
Transaction Account Types are elements which represent each transaction account on
procurement transactions. There are five such transaction account types for five different
accounts exposed on procurement transactions. This was discussed briefly before. They are:
Charge Account: The account against which the money spent is finally withdrawn or
charged
Variance Account: Certain situations call for variances to be recorded for certain kind
of spending. An entry is created against this account for all such variances. For
example price variance between PO and invoice.
Accrual Account: An intermediary account which records money spent for goods or
services that have been consumed or taken ownership of and that is yet to be
invoiced. An entry against this account is reversed once the money is physically spent,
for example, check cashed/invoice paid.
Destination Charge Account: The charge account belonging to the destination
organization
Destination Variance Account: The variance account belonging to the destination
organization
Each of these transaction account types are assigned some seeded sources out of the box.
Sources are attributes in the transaction which can be used to determine the derivation of
the account combinations. For instance, there can be a business requirement to default
Account A as the charge account when the purchase order destination type is Expense vs
Account B when the destination type is Inventory. Thus in the above example Destination
Type is seeded as a Source and assigned to the charge account such that it is possible to
author rules to derive charge account combinations. The source assignments are nonalterable. You can learn more about sources in section 4.5 Source.
4.3.
Account Rule
Account segments for each transaction account type are derived from some Account Rules.
The rule can be for the entire account combination (Account Combination Rule) or just for a
particular segment (Segment Rule) specified by Rule Type. Each such account rule comprises
one or more rules with specified conditions which dictate when they are fired. For instance
there can be a rule with priority one, saying that the Purchasing Charge Account is derived
from the Requisition Charge Account when Cross BU = N and the Requisition Charge Account
is not null.
10
You can use both segment rules and account combination rules to derive a single account.
Segment rules are used, where they are defined, and take the remaining values from an
account combination rule. For example, you can select an account combination rule which is
for all segments and also separately select a segment rule which is for one particular
segment. Segment rules take precedence over the account combination rule.
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.
Account Combination Rules
You set up account combination rules based upon the following value types:
11
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.
For example, a variance account can be derived from a charge account where the
latter is setup as a 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.
For example, you can setup a mapping set which maps ship-to org to account
combinations
Input ship-to org
Org A
Org B
Org C
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 chart of accounts or no chart of accounts.
For example, if both your charge and accrual account shares the same derivation
logic, you can create the account rule once, and then specify the same as source for
the charge account rule and the accrual account rule.
Tip: A chart of accounts must be specified for rules using constants.
12
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.
Note: A chart of accounts must be specified for rules using constants.
4.4.
Mapping Set
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. Use mapping sets to quickly
define a specific output value with an account or a segment. Based on the input value from
subledger transactions or reference information, a specific value can be assigned to a
segment or values can be assigned to all segments of the account. Mapping sets provide an
efficient way to define the output values and are easier than using the account rule
conditions.
To define a mapping set, pairs of values are specified. For each input value, specify a
corresponding account combination or segment output value. One or more related pairs of
these input values with the segment or account output values form a mapping set. Use value
sets or lookup types for validating the input values of the mapping set.
For example, assume a business has three major spend classifications: Software, Hardware,
and Misc. The business has a natural account segment in their chart of accounts. Category
names which drive spend classifications are input values in the application transaction such as
PO and requisition. These input values can be included with other information about the
transaction and become part of the source information. Users can create a mapping set that
maps category names to the corresponding natural account as described in the table below.
13
Input Value
Software
Hardware
Misc
4.5.
Source
ii.
iii.
Account rule values (both account combination rule and segment rule) for value type
of Source. In such cases only the sources which are accounting flexfields are available
for usage.
Conditions for account rules setup.
Input sources in Mapping Sets setup.
14
5.1.
In this section, you will learn all the sources that are seeded out of the box and available
for you to base your account rule setups on. Please note that you cannot add or modify
these sources. There are a set of sources which are available to all the five transaction
types. Thereafter, there are few additional sources available ONLY for specific transaction
types.
Please use these source lists for reference during your TAB setup task.
5.1.1 Source Assignments for All Transaction Types
Subledger Application
Source Name
Comments
Purchasing
Purchasing
Purchasing
Buyer Identifier
Purchasing
Purchasing
Cross BU
Purchasing
Category ID
Purchasing
Purchasing
Purchasing
15
Purchasing
Destination Subinventory
Purchasing
Purchasing
Document Style
Purchasing
Purchasing
Inventory Item
Purchasing
Line Price
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
PO schedule attributes 1 - 20
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
16
Purchasing
Purchasing
Purchasing
Purchasing
Preparer Identifier
Purchasing
Purchasing
Purchasing
Sold-to BU Name
Purchasing
Purchasing
Supplier Type
Purchasing
Supplier Identifier
Purchasing
Purchasing
Project Costing
Subledger Application
Source Name
Comments
Purchasing
Purchasing mapping set Expense Accrual Account Business Unit with Business Unit as parameter.
For local orders, use requisitioning BU, and for global
orders, use profit center BU of the PO trade org.
Purchasing
Cost Management mapping set Accrual Account Organization with organization as parameter.
For local orders, use ship-to org, and for global orders, use
PO trade org.
17
Subledger Application
Source Name
Comments
Purchasing
Purchasing
PO Charge Account
Purchasing
Cost Management mapping set Invoice Price Variance Account Organization with ship-to org as a parameter.
Purchasing
Cost Management mapping set Invoice Price Variance Account Organization with PO trade org as a parameter.
Subledger Application
Source Name
Comments
Purchasing
Purchasing
Requisitioning BU Name
Purchasing
Purchasing
Cost Management mapping set Cost of Sales Account Organization with PO trade org as parameter.
Purchasing
Purchasing
Purchasing
Purchasing
Cost Management mapping set Expense Account - Item with shipto org and item as parameters.
Purchasing
Purchasing
Purchasing
Purchasing
18
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
5.1.5 Additional Source Assignments for Destination Charge Account Transaction Type
Subledger Application
Source Name
Comments
Purchasing
Purchasing
Requisitioning BU Name
Purchasing
Purchasing
Cost Management mapping set Expense Account - Item with shipto org and item as parameters.
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
Purchasing
19
5.1.6 Additional Source Assignments for Destination Variance Account Transaction Type
Subledger Application
Source Name
Comments
Purchasing
Purchasing
Cost Management
Cost Management mapping set Invoice Price Variance Account Organization with ship-to org as a parameter.
20
5.2.
21
Step 3: Select and view the seeded Purchasing Accrual Account Rule
Step 4: Take note on how the Accrual Account is defaulted. According to the seeded rule, the
accrual account gets defaulted from the Source: Expense Accrual Account when PO
destination type is Expense OR Cross BU = Y. This source maps to the Purchasing mapping set
Expense Accrual Account Business Unit.
22
However, if the Destination Type is Inventory and this is not a global procurement scenario,
the Accrual Account is defaulted from the Source: Accounts Payables Accrual Account for
Inventory Item. This source maps to the Cost Management mapping set Accrual Account
Organization.
Priority
Value
Type
Value
Condition
Source
Source
23
Item
For this example you will assume that this PO is for an expense item and hence you will verify
that a mapping exists for the requisitioning BU on the Purchasing Mapping set Expense
Accrual Account Business Unit.
Step 5: Navigate to the task Manage Mapping Sets in the Task List Define Transaction
Accounting for Procurement.
24
Step 6: Edit the mapping set Expense Accrual Account - Business Unit. Select the appropriate
Chart of Account, and ensure that a mapping exists for your Sold-to BU (it will same as
requisitioning BU in local procurement scenario). If a mapping does not exist, create a new
one and specify the appropriate account.
Step 7: Optionally if your business uses inventory items, setup the Mapping Set Accrual
Account Organization for the Cost Management subledger. See setting up Cost Management
Mapping Sets for more details.
5.3.
25
Step 2: Take note on how the Charge Account is defaulted out of the box. According to the
seeded rule, the charge account gets defaulted from a series of sources having descending
priorities. Also note the condition for each such priority rule to fire.
Priority
Value
Type
Value
Condition
Source
Requisition Charge
Account
Source
Source
Subinventory Expense
Account
Source
Source
Source
Source
Ship-to Organization
Expense Account
Source
Subinventory Material
Account
Source
Ship-to Organization
Material Account
10
Source
11
Source
Ship-to Organization
Material Account
12
Source
Purchasing Trade
Organization Item
Expense Account
13
Source
Purchasing Trade
Organization Expense
Account
26
For this example we will assume that this PO has no backing requisition, it has an expense
destination type and the charge account is defaulted from the requesters HR default expense
account i.e. priority 6 gets fired. In the next steps we will verify that the requesters default
expense account is indeed setup in the HCM Person Management.
Step 3: Navigate to Person Management from the navigator
Step 4: Search for the requester by Name
27
Step 5: Click on the requester name and navigate to Manage Persons page. Select Manage
Employment from the task pane on the left.
Step 6: Verify that the Default Expense Account is populated. If not populate the account
accordingly.
28
The charge account on the PO will now get defaulted from the requesters default expense
account as setup in HCM.
Tip: Do not forget to verify that the requester field on the po distribution is populated for this
to work. If there is no requester on the PO distribution, no account will be generated from the
priority rule 6.
Step 7: Optionally if your business wants to drive the PO charge account based on ship-to
organization, item, sub-inventory, destination type etc, you need to setup one of the seeded
Cost Management Mapping Sets accordingly. The priority rules 3,4,5 and the 7-13 all uses
Cost Management Mapping Sets as sources. See setting up Cost Management Mapping Sets
for more details.
5.4.
Value
Type
Value
Condition
Source
Requisition Variance
Account
Source
PO Charge Account
Source
Source
Purchasing Trade
Organization Price
Variance Account
29
For this example we will assume that the PO has no backing requisition and the destination
type is expense. In such case, the priority Rule 2 gets fired and the variance account gets
defaulted from the charge account on the PO.
5.5.
Step 1: In an implementation project for Procurement, navigate to the task Manage Mapping
sets in the Task List Define Cost Management Mapping Sets for Procurement.
30
Step 2: All the seeded mapping sets are listed here. You can edit any of the mapping sets and
populate the input and output mappings.
31
Step 3: In this example we will setup the Expense Account Organization mapping set. This
mapping set maps input inventory organizations to output account combinations.
Step 4: Add one or more chart of accounts in the chart of accounts section. This defines which
chart of accounts is setup to use this mapping set
Step 6: Populate the mappings. For every input organization code, populate an output
account combination. Note: you can designate one of the output account combination as a
default. This results in using that output combination in the scenario where no appropriate
input organization code is found.
32
Tip: Note the Output Type for a Mapping Set. By modifying output type, a mapping set can be
used to map input parameters to an entire account combination or individual account
segments.
This setup task demonstrates how to setup one of the Cost Management Mapping Sets.
Similarly, you can setup the other available Mapping Sets depending on your business needs.
5.6.
Step 1: In an implementation project for Procurement, navigate to the task Manage Mapping
sets in the Task List Define Transaction Accounting for Procurement.
33
Step 2: A seeded mapping set Expense Accrual Account Business Unit is available. You can
use this to setup the Accrual Account.
Step 3: Another seeded mapping set Purchasing Natural Account for Transaction Account
Builder is available here. One can edit the mapping set and populate the input and output
mappings. This is a natural account segment mapping set. Based on input Requisitioning BU
and Item Category Name, you can determine the natural account segment of an account
combination.
34
Step 4: Add one or more chart of accounts in the chart of accounts section. This defines which
chart of accounts is setup to use this mapping set
Step 5: Populate the mappings. For every input Requisitioning BU Name and Category Name,
populate an output account segment. Note: you can designate one of the output account
segments as a default. This results in using that output segment in the scenario where no
appropriate Requisitioning BU and Category combination is found.
35
Tip: Note the Output Type for a Mapping Set. By modifying output type, a mapping set can be
used to map input parameters to an entire account combination or individual account
segments.
This setup task demonstrates how to setup one of the seeded Purchasing Mapping Sets.
Similarly, you can create new Mapping Sets depending on your business needs.
5.7.
Oracle Fusion Procurement seeds a Transaction Account Definition which makes use of the
account rules and mapping sets explained above. For most cases, you can reuse this seeded
transaction account definition. In this task you will explore this seeded Transaction Account
Definition and how it combines all the account combination rules to default the accounts on a
requisition or purchase order.
Step 1: Go to FSM and navigate to Define Transaction Account Rules Task
36
Step 4: Observe the account combination rules which drives each of the transaction account
types on requisitions and purchase orders. Also take note, that the seeded transaction
account definition does not have any Segment Rules. In a later section we will talk about
more advanced TAB setups where customers can set up segment Rules and/or modify the
Account Combination Rules. See section 6.2 for details.
37
5.8.
This is the final yet the most crucial step of TAB setup. Your business can centralize the
account defaulting piece by virtue of setting up one TAB and reusing it across different
ledgers if you so choose. Once you are done setting up the Transaction Account Definition,
you need to associate it with a ledger. Based on which ledger a PO or a requisition
corresponds to, the appropriate Transaction Account Definition will be picked up.
Step 1: Go to FSM and navigate to Define Transaction Account Rules Task
38
Step 3: Search for the Ledger. Once the ledger is displayed in the search results, select
Purchasing as the component type and edit the Accounting Options.
Step 4: Populate the Transaction Account Definition with the seeded Purchasing TAB Default
Accounting or alternately with a new Transaction Account Definition that you might have
created. Save.
39
This completes the setup of TAB using the seeded setup configurations.
40
In this section, we will setup a minimalistic custom TAB such that all the three mandatory
accounts in a purchase order or a requisition gets defaulted appropriately. We will assume an
overly simplistic business where based on destination type, they default the accounts on the
PO and requisition to specific constants. All the accounts on the document are same in this
example. To tabulate the use case:
Destination
Type
Expense
Inventory
Charge
Accrual
Variance
01-000-2440-0000-000
01-110-4110-0000-000
01-000-2440-0000-000
01-110-4110-0000-000
01-000-2440-0000-000
01-110-4110-0000-000
You can easily learn how to start from scratch to accomplish this task. Please download the
video demonstration attached to the My Oracle Support Note 1507175.1 for step by step
guidance.
6.2.
In this setup you will assume the hypothetical company ABC Corp. driving the natural account
segment of their charge account on requisitions and purchase orders from project sources in
case there are project references on the document distributions. Basically if the PO
references a project, then default the charge account segment to the following based on
project top task number.
Top Task Number
1.0
2.0
Default
41
You can easily learn how to start with the seeded setups to accomplish this task. Please
download the video demonstration attached to the My Oracle Support Note 1507175.1 for
step by step guidance.
7. Known Limitations
If you plan to use the Item Category Name source in your transaction account definitions,
make sure the category name does not exceed 80 characters. Otherwise, Transaction
Account Builder might not be able to derive an account.
8. Conclusion
Oracle Fusion Procurement leverages Oracle Subledger Accounting's flexible rules based
engine that enables you to author your unique account derivation policies and manage
them effectively. You can either use the seeded setups to lessen setup overhead or decide
to add your own layer of customizations on top of the seeded setups or even start from
scratch.
9. Additional References
For additional references please see Define Accounting Transformation section in the
Oracle Fusion Accounting Hub Implementation Guide
http://docs.oracle.com/cd/E28271_01/fusionapps.1111/e20374/toc.htm
42
Copyright 2011, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the
November 2012
contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are
Oracle Corporation
World Headquarters
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Worldwide Inquiries:
AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices.
Phone: +1.650.506.7000
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license
Fax: +1.650.506.7200
and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open
Company, Ltd. 1010
oracle.com