Oracle TCA uptakes in Oracle Release 12

TCA update in R12 to additional entities:

• Banks & Bank Branches
• Suppliers
• Legal Entity

TCA in R12 - New Bank Account Model:

• Central place to define internal bank accounts
• Keep track of all bank accounts in one place
• Explicitly grant account access to multiple operating units/functions and users
• Multi-Org Access - In the new model, bank accounts are owned by Legal Entities with the option to grant account use to Operating Unit (Payables, Receivables), Legal Entity (Treasury), Business Group (Payroll)

TCA in R12 - Bank model benefits:

• Reduce number of access points to manage bank accounts - Centralized user interface
• Improve visibility and control of bank accounts - Multi-org access control
• Simplify bank reconciliation - Single bank statement can be reconciled across multiple Operating Units
• Increase percentage of automatically reconciled transactions - Bank account level reconciliation parameters add flexibility

TCA in R12 - Supplier Representation:

• Supplier organizations are in TCA
• Terms of doing business with the supplier are in Purchasing / Payables
• Supplier organization, address, contact, phone, email etc. are all in TCA
• Employees are already in TCA, Payables using the same employee records in TCA
• New supplier maintenance UI using TCA UI components

TCA in R12 - Benefits of Supplier representation:

• Single repository for suppliers data
• AR/AP netting
• Oracle Payments serves as a payment data repository on top of the Trading Community Architecture (TCA) data model. The TCA model holds the party information. Oracle Payments then stores all of the party’s payment information and its payment instruments (including credit cards, debit cards, customer bank accounts, and supplier bank accounts).

TCA in R12 - Legal Entities:

• Legal entity is created as a party of party type ORGANIZATION or PERSON
• An establishment is created as a party of party type ORGANIZATION
• TCA creates a new classification category called “Business Function”. It is used mainly to model what business functions a party can perform in E-Business Suite
• For modeling legal entities and establishments in TCA, classification code “Legal Entity” and “Establishment” are created under the “Business Function” class category
• An establishment is created as a party and always link to a party that is classified as a legal entity through the relationship model

TCA in R12 - Integration with HRMS:

• TCA creates the global view of person
• TCA enables you to store person Information at a corporate level
• Person is stored as party in TCA
• Comprehensive duplicate person check when entering a new person – Across the business group
• Propagate some information entered in one business group to the record in the other business group
• PER_ALL_PEOPLE_F.PARTY_ID is a foreign key to the HZ_PARTIES table, an integral part of Oracle's "Trading Community Architecture" (TCA).

Oracle Trading Community Architecture (TCA) - key concepts

I have seen many clients who do not understand the power of TCA architecture and how they can effectively use the TCA model to design their customer master. In this post I will explain the key TCA concepts and I will also try (in later posts) to take a real world example of customers and model it in the Oracle Release 12.1.3 environment.

TCA = Trading Community Architecture; Data Model and not Module. TCA provides a single, universal definition of trading partners across applications and job function.

A Trading Community Architecture is a way to understand who our trading partners interact with inside and outside the enterprise. TCA puts a foundation in place for a trading partner model:

• Linking Suppliers and Customers
• Online Marketplace
• Shared Service Centers

How did TCA come about?

• First introduced in 11i
• Introduction of Oracle CRM application
• Requirement for a common customer model for all Oracle Applications
• Model evolved from working with ERP and CRM teams to create a view of the customer base which supports all flows throughout the E-Business Suite
• To support both B2B and B2C business models
• Re-architected to enable future support for entire trading Community

Guiding Principles of TCA:

• Create a central repository for the entire E-Business Suite to store information relating to all members of a trading community versus separate tables for each member
• Prospects, Customers, Contacts, Employees, Partners, Distributors, Suppliers, Banks, etc.
• Record complex business relationships between Trading Community entities (including 3rd party relationships)
• Support all business models, industries, and geographies

TCA Data Model: Parties vs. Accounts:

• From an application perspective, one of the most important things to understand about the TCA model is that the concept of “customer” is separated into two layers: The Party layer and the Account layer.
• When CRM applications refer to “Customer” they are referring to the Party Layer.
• On the other hand, when ERP applications refer to “Customer” they are referring to the Account Layer.
• Thus, confusion arises because both are using the word “Customer” to refer to two different things.

Other features of TCA:

• Public API’s for data manipulation of TCA tables
• Common Party User Interface Components
• Hierarchy Model
• Bulk Import of customer data and D&B Integration
• DQM for duplicate prevention
• Party and Account Merge

TCA data dictionary:

• HZ Parties - Stores basic information about parties and their relationship. Party ID is the primary key. Party id, Party Number, Party Name and Party Type are key columns. Establishes the Business Relationships.
• HZ Locations - Stores delivery or postal address. Location ID is the primary key. Not to be used for modeling party hierarchical relationships (use party relationships). Identifies the Party and its Account. Location can cross Parties and a Party can have multiple Locations. Account (beneath the Party) inherits the Locations defined for the Party.
• HZ Party Sites - Table that links HZ Parties with HZ Locations. Party Site ID is the primary key.
• HZ Cust Accounts - Different instances of Business Relationships (Selling, etc). Multiple Accounts can exist for a Party. Cust Account ID is the primary key.
• HZ Cust Acct Sites All - Site reference to the Account . Partitioned by Org Id. Primary Key is Cust Acct Site Id.
• HZ Cust Site Uses All - Stores business purpose usage (Bill To, Ship To, etc) for the Customer Account. Site Use Id is the Primary Key. Integrated with HZ Cust Acct Sites All.
• HZ Customer Profiles - Stores credit characteristics of Party, Account, Site.
• HZ Party Relationships - Stores relationships between parties.
• HZ Cust Profile Classes - Stores credit characteristics that is common across a group of Accounts

Order Management - Pick Release Concepts

Release Rules

• Release rules define the criteria to be used during Pick Release. Only orders that meet the criteria and are eligible will be released. An order line is eligible if it has completed the prerequisite workflow activities, such as Schedule - Line or Create Supply.

Release Sequence Rules

• Release Sequence rules determines the order in which inventory is allocated to sales orders. You choose to allocate by order, outstanding Invoice value, Scheduled Date, Departure Date and Shipment Priority.
• The order in which sales orders are filled could be very important. If a company has a problem of running out of material before all of their orders have been filled it is very important that they have filled their most important orders first.

Picking Rules

• Picking rules, which are created and maintained in Oracle Inventory, suggest which material to use, based on inventory controls such as revision control, lot control, FIFO (first in first out) or subinventory/locator picking numbers.
• Picking rule is an Item Attribute. Create a variety of picking rules and associate them with the appropriate items. If there isnt a Picking Rule associated with the item, the system will use the organizations default picking rule which is found on the Shipping organizations Parameters.
• Note: Picking Rules are covered in Oracle Inventory. To learn more see Oracle Inventory users guide.

Pick Slip Grouping Rules

• Pick Slip Grouping Rules organize how released order lines are grouped on Pick Slips for ease of picking. For Example: By using the Pick Slip Grouping Rule as Subinventory, the user can reduce the number of trips to a particular subinventory by grouping all lines for that subinventory on to one Pick Slip.

Order Management - Shipping Concepts

Trip

• A trip is carrier specific and represent a unique instance of that carrier leaving your warehouse with deliveries.
• The carrier could be a public carrier such as DHL or could be a companys own fleet of trucks.
• A trip could represent a truck, air cargo, ship cargo, or railcar. These entities would be set up as items in Oracle Inventory with an item type of Vehicle.
• Each trip has a minimum of two stops, pick-up and drop-off.
• A trip can be created automatically or manually from the Shipping Transactions form or can be automatically created from the Ship Confirm window. You can also create a trip as a part of a concurrent process.
• Companies that use public carriers can enable the system to automatically create Trips as part of of the Ship Confirm process. This eliminates unnecessary transactions.

Stops

• A stop is a point along the route of a trip that is due for pick-up or drop-off.
• The Ship Confirm process can initiate closing the pick-up stop updating the delivery
  status to Intransit.
• Manually record all stops made by the Trip using the Shipping Transactions form or
  have the Ship Confirm process automatically close a Trip, which creates and closes the
  pick-up stop and drop-off stop and changes the Delivery status to Closed.
• Companies that use public carries let the system automatically close a Trip as part of Ship
  Confirm.

Delivery leg

• A delivery leg consists of two stops where the delivery is picked up and dropped off, respectively on the same trip. The delivery might travel through several legs to get to its final destination and is synonymous to the Bill of Lading.
• A bill of lading is a receipt, listing all the goods that were signed over to a carrier.
• The Ship Confirm window enables you to generate a bill of lading which can then be printed separately or as part of the Delivery Document Set.

Deliveries

• A delivery must be created to perform Ship Confirm. It represent all the goods that were shipped from the same warehouse, going to the same Customer location.
• The grouping of delivery lines into deliveries is restricted by the grouping rules that are established on the Shipping Parameters - Delivery Tab.
• A delivery can be created automatically or manually from the Shipping Transactions form at any time after the order line status has become Awaiting Shipment or can be automatically created during the Release Sales Order process.
• A delivery is also automatically created when you invoke the action Pick and Ship or Pick, Pack, and Ship.

Delivery Lines

• Delivery lines are sales order lines which have completed all their workflow activities that are prerequisites to Oracle Shipping Execution such as Schedule Line or Create Supply.
• Delivery lines are visible from the Shipping Transactions form. They are also visible from the sales order lines Additional Information Deliveries tab.
• Delivery lines with similar attributes can be systematically grouped together into deliveries based on grouping rules.

LPNs

• LPN, (License Plate Number) are also known as Containers. An LPN can be loaded inside of another container, for example, pack an item into a box and then pack that box onto a pallet.
• Optionally LPNs can be setup as inventory items if the shipper is interested in using weight and Volume and packing functionality.
• LPNs can be made mandatory using your Shipping Parameters.

Ship From

• The ship-from location represents the warehouse that is performing the shipping transaction. A warehouse is an Inventory organization.

Ship to

• The Ship To Location represents a Ship-To address that has been setup on the customers record.

Order Management Concepts - Shipping Execution Flow

After a sales order has been booked, the sales order lines must complete all workflow activities leading up to the shipping activity. Two typical preceding workflow activities are Schedule - Line and Create Supply.

Schedule – Line:


Scheduling the line makes the order lines demand visible to Oracle Inventory for planning. It
also sets the Shipment Schedule Date.

Create Supply:

Variety of subflow paths can be taken within Create Supply Line based on the type of item
shipped. They are as follows:
Configurable Items: Configurable items must complete the Create Supply activity
which takes an order line through a build cycle. The final assemblies that are completed
out of Oracle Work in Process are received into Oracle Inventory as Reserved for a
specific customers order.
Drop ship: Drop ship order lines must complete the Create Supply activity too. After a
Purchase Requisition has been passed to Oracle Purchasing the order line advances to the
Shipping Activity.
Standard Shippable Items: Standard shippable items don't need to perform any of the
Create Supply activities so directly advance to the Shipping activity.

Shipping:

What happens when the order line reaches ‘Ship Line’ workflow activity?

• Oracle Order Management calls Oracle Shipping Execution APIs to indicate that a line is Ready to Release.
• The sales order line status is changed to Awaiting Shipping. Order lines that are awaiting shipping are called Delivery Lines in the Oracle Shipping Execution module
• Pick Release process creates move orders to move items to the staging location and create
• reservation in Oracle Inventory
• From the staging area shipments are weighed, packed and shipped 
• Deliveries are Ship Confirmed out of the staging location
• When a delivery is Ship Confirmed, Oracle Shipping Execution calls OM APIs to communicate the event, triggering the line flow to move forward

Order Management Concepts - Qualifiers and Modifiers

Qualifiers:

A qualifier defines eligibility rules for modifiers and price lists.

A qualifier can be a customer name, a customer class, an order type, or an order amount that can span orders.

Though a qualifier may be set up independently, it comes into effect only when linked to a modifier or a price list. Thus, the modifier that is set up and linked to a qualifier determines who the price adjustment will affect as well as the amount that will change.

You can create qualifier groups to apply individual qualifiers as a set. When you group qualifiers, they become a set, which allows for faster searching and setup.

Modifiers:

Modifiers determine the adjustments made to the list price. These are dependant on various business factors such as the type of adjustments to make, the level at which the adjustments are made, how the modifiers are qualified, how they are applied, etc. You can create three modifier list types in Oracle Pricing:

• Discount List
• Surcharge List
• Freight and Special Charges List

There are four modifier line types available in Oracle Pricing:
• Discount
• Surcharge
• Freight and Special Charges: Amount applied to the customer invoice for movement of a shipment to a destination
• Price Break: Only point price breaks are allowed in Basic Pricing modifiers. For example, the following pricing decisions are:

If Item Quantity = 1-50, then discount = 5%
If Item Quantity = 51-100, then discount = 7%
If Item Quantity is between 101 and 99999999999, then discount = 10%.
So if the ordered item quantity is 110, then the discount applicable is 10%.

Modifier controls are of the following types:
Pricing Event is a time in the process flow of the calling application at which it makes a call to the pricing engine (analogous to an Oracle Workflow event); for example, Book Order in Order Management.

Pricing Phase is a user-defined group of modifiers that the search engine considers together when applying them to pricing requests, for example, Phase 1: Line Adjustments.

Incompatibility: In any given level within the same phase, the system only allows one modifier to be selected. The pricing engine may retrieve more than one modifier that meets the calling request and can be applied. There are three methods to resolve incompatibilities within the modifiers that the pricing engine retrieves:

• Precedence
• Best price
• Exclusivity

Incompatibility Level: Each modifier has an incompatibility level. If there is more than one modifier line with the same incompatibility level, the pricing engine selects the one with the highest precedence. If there is more than one modifier with the highest precedence in an incompatibility level, the pricing engine selects the modifier that provides the best benefit to the customer.

In Basic Pricing, users cannot add additional phases or events, and incompatibility level and buckets are defaulted.

Order Management Concepts - Basic Vs Advanced Pricing

Oracle offers two levels of pricing functionality: Basic and the separate enhanced product, Advanced Pricing. While both levels of functionality share some similarities, the licensed Advanced Pricing application extends the ability to adjust pricing.

Price Lists:
The creation of price lists within both levels carries many of the same elements. Both are able to add items to, and copy price lists. However, as you implement Advanced Pricing, the ability to use Qualifiers, Pricing Attributes, and Secondary Price Lists becomes extended from only allowing the default or one context element in Basic, to an unlimited number of values being available.

Agreements:
The use of Agreements is the same for both Basic and Advanced Pricing. They are both able to identify customer items, create price lists, use versioning, and define price breaks.

Formulas:
Both Basic and Advanced Pricing allow Static Formulas, while only Advanced Pricing allows the use of Dynamic Formulas.

Modifiers:
While both basic and Advanced Pricing have the ability to execute Discounts, Surcharges, Freight Charges, and point-based price breaks, Advanced Pricing extends this functionality greatly. Advanced Pricing also allows price modifications via Coupons, Terms Substitution, Promotions, Item Upgrades, and Other Items discounts. Additionally, Advanced Pricing
allows you to implement adjustment functionality that will change the list price used for the adjustment; affect the timing of when the adjusting activity will occur; and enable you to define rules affecting which adjustments may be used at the same time. In Advanced Pricing,
you can also flag discounts as exclusive, which implies that only that discount will be eligible and no others.

Note: Additionally, Advanced Pricing enables you to derive prices from external sources. For further information on the Advanced Pricing functionality, please refer to the Advanced Pricing User and Implementation Manuals.