Professional Documents
Culture Documents
TAB Whitepaper R11
TAB Whitepaper R11
July 2016
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 Oracle’s products
remains at the sole discretion of Oracle.
Transaction Account Builder
5.6. Set Up Purchasing Seeded Mapping Set for TAB ............. 38
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
Businesses would like to automate the derivation of these accounts on transactions based
upon their corporate policies. Derivations are required to build these accounts on
transactions such as requisitions or purchase orders. This is done by the Transaction Account
Builder (TAB) component of the Subledger Accounting (SLA) engine.
TAB is solely responsible for building or defaulting the accounts on a transaction such that
appropriate accounting entries can be created against such transaction accounts.
3
Transaction Account Builder
2. Background
TAB is a new concept in Oracle Fusion Applications and it replaces all prior account generator
solutions. Before Oracle Fusion was available, there was a similar need to default transaction
accounts. That need was fulfilled by different solutions. For example, 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 is obsolete in Fusion and is replaced by Transaction Account
Builder.
Oracle Fusion delivers seeded account defaulting rules within Transaction Account Builder.
These rules address the common defaulting scenarios of customers and also facilitate further
rule extensions, avoiding the need for customers/implementers to create them 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. Although
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 applications, account generation is carried out by AAI (Automatic Accounting
Instruction). AAIs are rules that define the relationships between day‐to‐day accounting
functions and the chart of accounts. In the General Accounting system, AAIs determine how
to allocate system‐generated general ledger entries. 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 the chart of accounts.
In, TAB configuration in Oracle Fusion Applications is significantly easier than Workflow
customization in EBS Release 12, because it is accomplished within the SLA application
instead of in a separate technology tool.
4
Transaction Account Builder
Compared with Peoplesoft and JDE, TAB provides more flexible account derivation, as it
allows users to derive all transaction accounts, and provides a larger pool of potential
sources.
Moreover, customers can reduce customized account defaulting definitions by sharing them
between applications. For example, the account defaulting for Projects is used by Projects,
Purchasing, and Accounts Payable and can be shared by all three, but need only be 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 provides an overview of the general flow of data from defaulting, on to
the purchase order, and on to its final usage in an accounting transaction.
5
Transaction Account Builder
The TAB data is contained in the SLA data model, moving away from Workflow components.
The top level process in Transaction Account Definitions is the equivalent of the overall
workflow process, and it includes the assignment of rules to each Transaction Account Type
defined for 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 defines which sources may be
used for a particular account and passes them into TAB.
In EBS R12, users can write custom PL/SQL statements and add functions to the workflow to
execute them, and then use the results in their workflow function. 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, in most cases, users will not need to define
custom sources.
In Oracle Fusion, users also have the ability to define data in mapping sets and use them in
account rules. This could also be used for the customer‐specific reference account data
needed to drive the account defaulting process.
6
Transaction Account Builder
Before you can set up TAB to derive accounts, you must understand the business
requirements that drive the accounts on your transaction. Different business can have
completely different requirements, from something simple such as deriving the charge
account from the requesters default expense account in the HCM, to more complex flows
involving projects and segment substitution rules. The first step is to analyze the
requirements and use cases.
In this section, assume a hypothetical business requirement of a hypothetical company called
ABC Corp. ABC Corp. always creates requisitions which are processed into purchase orders.
The accounts on the purchase orders mirror the accounts generated on the requisition. They
do not have any inter‐company setup and they do not perform global procurement.
There are three accounts that must be defaulted on their requisitions, based on the following
logic:
Charge Account: ABC Corp. drives their charge account based on whether the
destination type is expense or inventory. For expense destination types, they map the
ship‐to organization on the requisition to a particular account combination. For
inventory destination types, they use a mapping in which a particular combination of
item and ship‐to organization maps to a specific account combination.
Variance Account: ABC Corp. requires that the Variance Account is the same as the
Charge Account.
Accrual Account: ABC Corp. would like to default the accrual account from the
expense account setup for the Business Unit responsible for creating invoices.
However, they want the balancing segment of the Accrual account to be derived from
the balancing segment of the Charge Account.
It is important to understand and formulate your business needs and how you would like
to derive the accounts on the procurement transactions such as requisitions and purchase
orders. This will enable you to evaluate whether the seeded default setup works for your
organization or if you need to modify the setup for your specific business need.
7
Transaction Account Builder
In order to understand TAB, we first need to understand the building blocks of TAB. These
building blocks make up the structure of TAB.
Figure 3 TAB structure
At the top level is Transaction Account Definition (TAD), which 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. Below TAD are a number of Transaction Account Types (TATs).
8
Transaction Account Builder
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. 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.
9
Transaction Account Builder
Each of these transaction account types have assigned seeded sources by default. Sources are
attributes in the transaction that can be used to determine the derivation of the account
combinations. For example, 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. 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 can’t be altered. You can learn more about
sources in section 4.5 Source.
Account segments for each transaction account type are derived from some Account Rules. A
rule can apply to 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 example,
there can be a rule with priority one, saying that the Purchasing Charge Account is derived
10
Transaction Account Builder
from the Requisition Charge Account when Cross BU = N and the Requisition Charge Account
is not null.
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 that
applies to all segments and also separately select a segment rule that applies to 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
11
Transaction Account Builder
You 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.
For example, a variance account can be derived from a charge account that is set up
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 set up a mapping set which maps ship‐to org to account
combinations
Input ship‐to org Output account value
Org A 01.000.2210.0000.000
Org B 01.000.2310.0000.000
Org C 01.000.2410.0000.000
4. Account Rule Value Type: Derive the account by referencing another account rule.
You can define this type of rule without specifying a chart of accounts. 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 your charge and accrual accounts share the same derivation logic, one
account rule can be used as the source for both of them.
Tip: A chart of accounts must be specified for rules using constants.
Segment Rules
12
Transaction Account Builder
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.
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, such as PO and requisition, are input values in the
application transaction. 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.
Input Value Natural Account Segment Value
Software 0001
Hardware 0002
13
Transaction Account Builder
Misc 0003
4.5. Source
A source is any transaction attribute (attribute on a requisition or purchase order) that is
registered with a subledger and available for TAB to build accounts from. For example, item
category name is a source and can be used as an input parameter to a mapping set. The
source can also be an accounting flexfield. As an example, the requisition charge account is a
source and can be used to drive the PO charge account defaulting. Sources can also be used
in account rule conditions to determine when a rule should get fired.
To summarize, sources can be used in the following TAB configurations:
i. 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.
ii. Conditions for account rules setup.
iii. Input sources in Mapping Sets setup.
14
Transaction Account Builder
Oracle Fusion Procurement tries to seed a standard setup for TAB such that customers can
complete their transactions, such as requisitions and purchase orders, with minimal
configuration. Most typical business needs can be addressed using the seeded setup with
minimal modifications. This section explains the seeded setups.
This section describes the default seeded sources that you can use to create account rule
setups. Note that you cannot add or modify these sources. There are a set of sources
which are available to all five transaction types. Thereafter, there are few additional
sources available ONLY for specific transaction types. Additional, some sources are
provided that apply only to specific transaction types.
Refer to these source lists during your TAB setup task.
5.1.1 Source Assignments for All Transaction Types
15
Transaction Account Builder
16
Transaction Account Builder
17
Transaction Account Builder
18
Transaction Account Builder
19
Transaction Account Builder
organization.
20
Transaction Account Builder
21
Transaction Account Builder
group tasks for processing purposes
5.1.2 Additional Source Assignments for Accrual Account Transaction Type
5.1.3 Additional Source Assignments for Variance Account Transaction Type
22
Transaction Account Builder
5.1.4 Additional Source Assignments for Charge Account Transaction Type
23
Transaction Account Builder
5.1.5 Additional Source Assignments for Destination Charge Account Transaction Type
24
Transaction Account Builder
5.1.6 Additional Source Assignments for Destination Variance Account Transaction Type
25
Transaction Account Builder
Step 1: Go to Functional Setup Manager (FSM) and navigate to the Define Transaction
Account Rules Task.
Note: Drill down to this task from the Implementation Project for Procurement. This picks up
the Purchasing context.
Step 2: Navigate to Manage Account Rules.
26
Transaction Account Builder
Step 3: Select and view the seeded Purchasing Accrual Account Rule.
27
Transaction Account Builder
Step 4: Note how the Accrual Account is defaulted. According to the seeded rule, the accrual
account is 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.
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.
28
Transaction Account Builder
For this example, assume that this PO is for an expense item. 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.
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 be same as the
29
Transaction Account Builder
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, set up the Mapping Set Accrual
Account Organization for the Cost Management subledger. See setting up Cost Management
Mapping Sets for more details.
Step 1: Repeat Steps 1 and 2 from section 5.2
Step 2: Select and view the seeded Purchasing Charge Account Rule
30
Transaction Account Builder
Step 3: Note that the Charge Account is defaulted without any configuration required..
According to the seeded rule, the charge account is defaulted from a series of sources having
descending priorities. Also note the condition that fires each such priority rule.
Priority Value Value Condition
Type
1 Source Requisition Charge "Cross BU" = N 'And' "Requisition Charge Account"."All" Is
Account not null
2 Source User Preferred Account "Cross BU" = N 'And' "Requisition Charge Account"."All" Is
null 'And' "Destination Type Code"(PO) = EXPENSE 'And'
"User Preferred Account"."All" Is not null
3 Source Subinventory Expense "Subinventory Expense Account"."All" Is not null 'And'
Account "Destination Type Code"(PO) = INVENTORY 'And' "Item Asset
Indicator" = N 'And' "Cross BU" = N 'And' "Inventory
Item"."All" Is not null
4 Source Ship‐to Organization Item "Ship‐to Organization Item Expense Account"."All" Is not null
Expense Account 'And' "Destination Type Code"(PO) = EXPENSE 'And'
"Inventory Item"."All" Is not null 'And' "Cross BU" = N
5 Source Ship‐to Organization Item "Ship‐to Organization Item Expense Account"."All" Is not null
Expense Account 'And' "Destination Type Code"(PO) = INVENTORY 'And' "Item
Asset Indicator" = N 'And' "Inventory Item"."All" Is not null
'And' "Cross BU" = N
6 Source Employee Charge Account "Cross BU" = N 'And' "Destination Type Code"(PO) = EXPENSE
'And' "Employee Charge Account"."All" Is not null
7 Source Ship‐to Organization "Ship‐to Organization Expense Account"."All" Is not null 'And'
Expense Account "Destination Type Code"(PO) = INVENTORY 'And' "Item Asset
Indicator" = N 'And' "Inventory Item"."All" Is not null 'And'
"Cross BU" = N
8 Source Subinventory Material "Subinventory Material Account"."All" Is not null 'And' "Cross
Account BU" = N 'And' "Destination Type Code"(PO) = INVENTORY
'And' "Item Asset Indicator" = Y
9 Source Ship‐to Organization "Ship‐to Organization Material Account"."All" Is not null
Material Account 'And' "Destination Type Code"(PO) = INVENTORY 'And' "Item
Asset Indicator" = Y 'And' "Cross BU" = N
10 Source Cost of Goods Sold "Cross BU" = Y 'And' "Inventory Item"."All" Is null
Account
11 Source Ship‐to Organization "Ship‐to Organization Material Account"."All" Is not null
Material Account 'And' "Destination Type Code"(PO) = INVENTORY 'And' "Item
Asset Indicator" = Y 'And' "Cross BU" = N
12 Source Purchasing Trade "Purchasing Trade Organization Item Expense Account"."All"
Organization Item Is not null 'And' "Item Asset Indicator" = N 'And' "Inventory
Expense Account Item"."All" Is not null 'And' "Cross BU" = Y
13 Source Purchasing Trade "Purchasing Trade Organization Expense Account"."All" Is not
Organization Expense null 'And' "Cross BU" = Y 'And' "Item Asset Indicator" = N
Account 'And' "Inventory Item"."All" Is not null
31
Transaction Account Builder
For this example, assume that this PO has no backing requisition, that it has an expense
destination type and that the charge account is defaulted from the requester’s HR default
expense account. In other words, priority 6 gets fired. Next, verify that the requester’s default
expense account is set up in the HCM Person Management.
Step 4: Navigate to Person Management from the navigator.
Step 5: Search for the requester by Name.
32
Transaction Account Builder
Step 6: Click on the requester name and navigate to the Person Management page. Select
Manage Employment from the task pane.
33
Transaction Account Builder
Step 7: Verify that the Default Expense Account is populated. If not, populate the account
accordingly.
The charge account on the PO is defaulted from the requester’s default expense account as
set up in HCM.
Tip: Verify that the requester field on the po distribution is populated. If there is no requester
on the PO distribution, no account will be generated from priority rule 6.
Step 8: Optionally, if your business wants to drive the PO charge account based on ship‐to
organization, item, sub‐inventory, destination type, and so on, set up one of the seeded Cost
Management Mapping Sets accordingly. Priority rules 3, 4, 5 and 7‐13 use Cost Management
Mapping Sets as sources. See Setting up Cost Management Mapping Sets for more details.
Step 1: Repeat Steps 1&2 from Section 5.2
34
Transaction Account Builder
Step 2: Select and view the seeded Purchasing Variance Account Rule
Step 3: Note that the Variance Account is defaulted without any configuration required.
According to the seeded rule, the variance account is defaulted from a series of sources
having descending priorities. Also note the condition that fires each such priority rule.
Priority Value Value Condition
Type
1 Source Requisition Variance "Cross BU" = N 'And' "Requisition Variance Account"."All" Is
Account not null
2 Source PO Charge Account ( "Cross BU" = Y 'And' "Destination Type Code"(PO) =
EXPENSE ) 'Or' "Requisition Variance Account"."All" Is null
'And' "Destination Type Code"(PO) = EXPENSE
3 Source Ship‐to Organization Price "Cross BU" = N 'And' "Requisition Variance Account"."All" Is
Variance Account null 'And' "Destination Type Code"(PO) = INVENTORY
4 Source Purchasing Trade "Cross BU" = Y 'And' "Destination Type Code"(PO) =
Organization Price INVENTORY
Variance Account
For this example, assume that the PO has no backing requisition and that the destination type
is expense. In such case, the priority Rule 2 is fired and the variance account is defaulted from
the charge account on the PO.
35
Transaction Account Builder
Step 1: In FSM, search for the Define Cost Accounting setup task list–. Expand the task
listMake sure that scope for the task is set to Cost Management. Navigate to the Manage
Mapping Sets setup task.
Note: Cost Management mapping sets cannot be accessed from a Procurement
implementation project. Search task lists directly in FSM.
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.
36
Transaction Account Builder
Step 3: In this example, we will set up 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 configured to use this mapping set.
37
Transaction Account Builder
Step 6: Populate the mappings. For every input organization code, populate an output
account combination. Note that you can designate one of the output account combinations
as a default. The default output account combination is used if no appropriate organization
code is found.
Tip: By modifying the mapping set Output Type, it can be used to map input parameters to an
entire account combination or individual account segments.
This setup task demonstrates how to set up one of the Cost Management Mapping Sets.
Similarly, you can set up the other available Mapping Sets depending on your business needs.
38
Transaction Account Builder
Step 1: In an implementation project for Procurement, navigate to the task Manage Mapping
sets in the Task List Define Transaction Accounting for Procurement.
Step 2: A seeded mapping set Expense Accrual Account – Business Unit is available. You can
use this to set up the Accrual Account.
Step 3: Another seeded mapping set Purchasing Natural Account for Transaction Account
Builder is available here. You 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.
39
Transaction Account Builder
Step 4: Add one or more chart of accounts in the chart of accounts section. This defines which
chart of accounts is set up to use this mapping set.
40
Transaction Account Builder
Step 5: Populate the mappings. For every input Requisitioning BU Name and Category Name,
populate an output account segment. Note that you can designate one of the output account
segments as a default. The default output segment is used if no appropriate organization
Requisitioning BU and Category combination is found.
Tip: By modifying the mapping set Output Type, it can be used to map input parameters to an
entire account combination or individual account segments.
If you need to derive the natural account segment based on the different levels in the
procurement category hierarchy, you can create your own mapping sets for this purpose. For
category level 1, mapping set – Purchasing Natural Account by Procurement Category Level 1
is seeded.
This setup task demonstrates how to set up one of the seeded Purchasing Mapping Sets.
Similarly, you can create new Mapping Sets depending on your business needs.
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 the task list Define Transaction Account Rules.
41
Transaction Account Builder
Step 2: Navigate to Manage Transaction Account Definition.
42
Transaction Account Builder
Step 3: Observe the seeded Purchasing TAB Default Accounting.
Step 4: Observe the account combination rules that drive each of the transaction account
types on requisitions and purchase orders. Also note that the seeded transaction account
43
Transaction Account Builder
definition does not have any Segment Rules. See section 6.2 for information on how you can
set up segment rules and/or modify the Account Combination Rules.
This is the final yet 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. After setting up the Transaction Account Definition, you must associate it with a
ledger. The appropriate Transaction Account Definition is picked up based on the ledger to
which a PO or requisition corresponds.
Please note that this setup step is optional because by default, every ledger is associated to
the seeded Transaction Account Definition Purchasing TAB Default Accounting. Perform this
setup only if you create your own Transaction Account Definitions.
Step 1: Go to FSM and navigate to Define Transaction Account Rules task list.
44
Transaction Account Builder
Step 2: Navigate to Manage Subledger Accounting Options
45
Transaction Account Builder
Step 3: Search for the Ledger. When the ledger is displayed in the search results, select
Purchasing as the component type and edit the Accounting Options.
46
Transaction Account Builder
Step 4: By default, for the Purchasing subledger application, every ledger in the application is
associated to the seeded Transaction Account Definition i.e. Purchasing TAB Default
Accounting. You can change it to a new Transaction Account Definition that you might have
created.
This completes the configuration of TAB using the seeded setup configurations.
47
Transaction Account Builder
In this section, we will set up 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:
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.
In this setup you will assume the hypothetical company ABC Corp. drives 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. If the PO references a
project, then default the charge account segment to the following based on project top task
number.
Top Task Number Account Segment Value
1.0 1200
2.0 1210
Default 1130
48
Transaction Account Builder
To quickly learn how to start with the seeded setups to accomplish this task, download the
video demonstration attached to the My Oracle Support Note 1507175.1.
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 set up overhead, 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
49
Transaction Account Builder Copyright © 2016, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the
July 2016 contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
Author: Mayukh Bhaowal 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
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
World Headquarters
means, electronic or mechanical, for any purpose, without our prior written permission.
500 Oracle Parkway
Redwood Shores, CA 94065
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
U.S.A.
Worldwide Inquiries: Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
Phone: +1.650.506.7000 are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
Fax: +1.650.506.7200 trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0116
oracle.com