Order To Cash

Order to Cash Process flow:

The Customer Order is received to the time the product or services

is paid for:

Customer:
As a party to a contract, the customer is responsible for oversight

of the contract, payments and any agreed-to obligations with the

contractor. The organization which is in the process of placing an

order with the company.

Creating Order:
The following information is to be provided while entering an order:
- Order details
- Customer information
- Item information at line level.

Booking an Order:
In Order Management, booking is workflow enabled. The application

comes seeded with two types of Booking processes:
- Manual Booking Process
- Deferred Booking Process.

Pick Release:

An order cycle action to notify warehouse personnel that orders are

ready for picking.

Pick Confirm:
Executes the sub-inventory transfer that moves the material from its

source location in the warehouse to the staging location.

Ship Confirm:
To enter shipped quantity and inventory controls for specific

shippable lines. You can ship confirm the same delivery/departure

repeatedly until you close the delivery/departure. Once it is closed,

no more changes can be made into a delivery/departure.

Interface Trip Stop:
Updates the quantity in inventory.It runs two interface programs

- Inventory interface

- Order management interface program.

Auto Invoicing :
=============

The Invoicing workflow activity transfers shipped item information

including quantities, selling prices, payment terms, and transaction

dates to Oracle Receivables, which processes invoices and accounts

for revenue.

Submit the Autoinvoice Master or Import program to transfer

transactions from the interface tables to Oracle Receivables.

- Autoinvoice Master Program
Autoinvoice Master Program selects and marks records in the

interface tables, for processing based on the parameters entered.

Once the records are selected, the Autoinvoice Import Program is

spawned. Autoinvoice Master Program does not provide any report

or output. The Master program allows running of several instances

of Autoinvoice to improve system performance and to facilitate

importing of transactions quickly.

- Autoinvoice Import Program

Autoinvoice Import Program validates the selected records and

creates transactions. Any record that fails validation is left in the

interface table with an error code. Depending on the overall setup,

related records may be rejected as well. An output file called

Autoinvoice Execution Report and Validation Report, can be viewed

by clicking the View Report button in the Requests Window.

Order Management Interfaces:

- Order Import.

- eComerce Gateway.

- Purchase Release.

- Invoice Interface.

- Inventory Interface.

- Shipping Interface.

Order Management Key API's

- Shipping Execution (SE)

- Configurator (CZ)

- Customer Relationship Management (CRM)

- Pricing (QP)

- Release Management (RLM)

- Configure to Order (CTO, formely ATO)

- eCommerce Gatway

- Process Order.

Other API's Interface:

1. Purchasing (PO)

2. Advanced Planning and Scheduling (APS)

3. Accounts Receivables (AR)

4. Inventory Managment (IM)

5. Shipping Execution (SE)

6. Configurator (CZ)
7. Customer Relationship Management (CRM)
8. Pricing (QP)
9. Release Management (RLM)
10 Configure to Order (CTO)

Back Ordered:

If the items are coming back from the staging area to the

source sub-inventory.

RMA:

If the material is coming back from customers after reaching

them. Then we do RMA to accept that back.

Drop Ship:

Supplying material to your customer by getting it from a

external source(supplier).

Internal Sales Order:

Getting material from any of the other organization by means

of a internal requistion.

Basic Order Process Flow:

Line Status Flow:

================

A Standard flow Status are:

Entered (OM): Order is saved but not booked.
Booked (OM): Order is booked.
Scheduled (OM): A user can customize the Workflow to show

the Scheduled status which indicates that the order line has been

successfully scheduled. When the ship line logic starts, the order line

status changes to Awaiting Shipping.

Awaiting Shipping (OM): Order is booked but lines are not yet

picked.

Open (OM): This status of a delivery on the Additional Line

Information form indicates that none of the delivery lines associated

with that delivery have been ship confirmed.

Shipping Execution - the delivery line status flow:

Ready to Release (SE): Order line is booked and passed to

Shipping Execution. It is now a delivery line that is eligible for Pick

Release.

Released to Warehouse (SE): Pick Release has started but not

completed. Either no allocations were created or allocations have

not been Pick Confirmed.
Not Ready to Release (SE): A delivery line may be in this status

when it is interfaced manually into Shipping, is not scheduled and has

no reservations. When lines are imported automatically from Order

Management this status is not used.

Backordered (SE): The delivery line is pick released but no

allocations were created or partial allocations occurred.

As an example, if a delivery line has a quantity of 100, and at pick

release only 25 are available for allocation, the original delivery line

splits to create a new line (quantity of 75) for the unallocated portion

with a status of Backordered. The quantity on the original delivery

line changes to 25 to reflect the allocated portion with a status of

Staged/Pick Confirmed.

Staged/Pick Confirmed (SE): The delivery line is successfully

pick released. It occurs after pick confirm to indicate subinventory

transfer from source location to staging location is complete. Lines

staged until they are ship confirmed. Both Backordered and

Staged/Pick Confirmed status provide the ability to perform

opportunistic cross-docking for warehouse organizations with Oracle

Warehouse Management System (WMS) installed.

Shipped (SE): This line status indicates that the delivery

associated with the delivery line(s) is ship confirmed.

In Transit (SE): This delivery status indicates that the delivery

associated with the line is ship confirmed and the pick up stop is

closed.
Confirmed (SE): This delivery status indicates that the delivery

line is either shipped or backordered and the trip stops are open.

Picked (OM): Pick release has completed normally (both allocation

and pick confirm). The delivery associated with the delivery line(s)

may have also been Ship Confirmed but the Delivery may not be set

in transit and the Trip may not be closed.

Picked Partial (OM): This status occurs when a delivery line is

not allocated the full quantity during Pick Release and Ship Confirm

has not occurred.

Shipping Execution pushes status information to Order Management

once Ship Confirm is completed:

Shipped (OM): The delivery associated with the line is Ship

Confirmed. The Delivery status is set to in transit. This status

appears in the Additional Line Information at the Pick Status field.

Interfaced (SE): If delivery was sourced from Oracle OM: The

delivery line is shipped and the OM Interface and Inventory Interface

concurrent processes have completed.

Interfaced to Receivables (OM): Invoice Interface has been

launched. Order Management writes information to Receivables

tables.

Partially Interfaced to Receivables (OM): This status is used

in a PTO flow and indicates that the particular PTO item is required

for revenue.

Closed (OM): Closed indicates that the line is closed. It does not

necessarily indicate that the line is interfaced to Accounts Receivable

(AR) since you must “close line” activity in a no-bill flow.

Canceled (OM): Indicates that the line has been completely

canceled. No further processing will occur for this line.

OM to AR:

==========

1. Create Item.

2. Create Price List.

3. Inventory increased/Increase on-hand Qty.

4. Create Sales Order.

5. Release Sales Order.

6. Pick Release.

7. Inventory Reduced.

8. Ship Confirm/Shipping notice Generated (ASN).

9. Run Auto Invoice/Invoice Generated.

10. Review Invoice.

11. Invoice sent to customer.

12. Payment Received from Customer.

13. Create Receipts

14. Apply Receipts.

15. Run reports and Reconcile accounts.

Inventory in Stock - Ship from Stock

Inventory Provided by Outside Suppliers:

- Ship to customer directly from the supplier - Drop ship.

Inventory Provided by Outside Supplier:

- Supplier ships the product which is received in inventory,

the shipment is done to Customer - Back to Back.

Internally:

IRISO - Internal Requistion Internal Sales Order

CRM- OM:

========
OM Process Orders entered through the CRM Suite:

- Oracle Marketing

- Mobile Field Sales

- iStores

- Telesales

- Mobile Field Services

- Oracle Services.

Oracle Apllications provides the capability to intergrateback office

modules (ERP) with front office modules (CRM).

OrderManagement is specifically tied to Quote Management, Service

Orders, and Mobile Service charges via Order Capture.

Information from sales order Sales credit are integrated to Sales and

Marketing modules.

Information from sales orders also integrate to the Service product

suite for instillation details and service program information into the

Service InstallBase.

Multi Org

What is Multi-Org:

Multi-Org is a way to consolidate your operations under one

installation of Oracle Apps and yet keep transaction data securely

confined within individual operating units.

Multi-Org is an application server side enhancement that enables

multiple business units in an enterprise to use a single installation of

Oracle applications products while keeping transaction data separately

and secure.

Multi-Org Features:

1. Architectural model that supports multiple financial sets of books

in a single installation.
2. Data security by Operating unit.
3. Global Customer and supplier registries.
4. Automatic intercompany accounting entries for sales transactions

booked in one organization and shipped out of another related

organization.

When would you use Multi-Org:
1. Multiple Set of Books.
- Global company with different set of books.
2. Multiple Legal Entities within a Set of Books.
3. Multiple independent Operating Units.
a. Additional requirement to secure data by operating unit
i) Regulatory Requirements
ii) Business Requirements
- Data security issues, etc.
iii) Other Drivers
- Bank code security, purchase agreements, etc.
b. Inter-company accounting is supported.

Multi-Org Basic Elements:

1.Business Group:
This is an organization that represents the consolidated enterprise, a major division, or an operating company and has no accounting impact. The Business Group partitions Human Resources (HR) information and the Purchasing approval hierarchy. Multiple legal entities can relate to a single Business Group.

2.  Ledger/Set of books:
This is the highest level which impacts the accounting side of the Business. Multiple Ledger/Sets of Books may be associated with a Single Business Group. Oracle Applications secure accounting information, such as journal entries and account balances, by Ledger/Set of Books.

3. Legal Entity:A legal entity represents a legal company for which you prepare fiscal or tax reports. You assign tax identifiers and other legal entity information to these types of organizations. Each legal entity may be linked to one and only one Set of Books. However, more than one legal entity may be linked to the same Set of Books.

4. Operating Unit:
An operating unit represents a Business Unit or a group of Business Units that share an Oracle sub-ledger application or suite of applications (AP,AR PO, OM). Oracle Applications secure transactional data, such as Customer and Vendor site information, Payables and Receivables invoices, and Payments and Receipts, by operating unit.

5. Inventory Organization:An organization for which you track inventory transactions, balances, manufacture or distribute products. Examples include manufacturing plants, warehouses, distribution centers, and sales offices.




















Multi-Org Impacts:
General Ledger:- Not impacted by Multi-Org. However, because the G/L sits above the Operating Unit level, its has a direct impact on the Multi-Org design (ie: you can point multiple A/P Operating Units to a single Set of Books, but you Cannot point a single A/P Operating Unit to multiple Sets Of Books).
-The more Sets of Books that are created will mean the more A/P Operating Units that need to be configured to support the General Ledger design. You can see a graphical example on the following slide.
Accounts Receivable:

-A Single Installation to Support AR Functions in multiple Countries.
-Allow for Sharing Business Information Such as Customer Master Header Information at Global Level.
-Secures Transaction Data (e.g.: Invoices and Receipts) at Operating Unit Level.
-Facilitate Inter-Company Transactions.
-Multiple Setups for Multiple AR Operating Units (e.g. Auto-Accounting and Transactions Types).
-Allow for Configuration of Diverse Processes for Different AR OU.
-Cash Receipts are applied by Operating Unit

Accounts Payable:

-A Single Installation to Support AP Functions in Multiple Countries.
-Allow for Sharing Business Information Such as Supplier Master Header Information at Global Level.
-Secures Transaction Data (e.g.: Invoices and Payments) at OU Level.
-Facilitate Inter-Company Transactions.
-Multiple Setups for Multiple AP Operating Units.
-Allow for Configuration of Diverse Processes for Different AP OU's.
-Payment Runs are by Operating Unit.

Project Accounting:

-Secures data at the project level.
-Allows for the configuration of accounting rules to support site specific accounting conventions.
-Limits list of values for ease and accuracy of data entry.

Fixed Assets:
-No Impact, since Assets is not multi-org enabled
-Data is secured at the asset book level.
-Intend to use Projects and its native integration with Assets to drive assets to the proper asset book.

Purchasing:
-Contracts, Blanket agreements, the purchasing hierarchy and the vendor sites are all maintained at the Operating Unit level.
-All demand coming from Inventory Organizations is sourced thru the Operating Unit that the Inventory Org is assigned to.
-In order to do centralized purchasing, all Inventory Organizations that share the same purchasing organization preferably are grouped into one Operating Unit
-If these Inventory Orgs are not grouped into one OU, maintenance of contract, sites, hierarchies, etc. becomes problematic

Order Entry:

-Order Lines are secured and processed at the OU Level.
-Allows Order Types to be setup and maintained by operating. This reduces the risk of clerical error during the order entry process.
-Price List Information is not secured by Operating Unit, but is available across the entire instance.
-If Price list information needs to be secured at the OU level, a low level customization will be needed in order to accomplish this.

Inventory, Purchasing (Receiving), MRP, BOM, WIP:
-Item information and accounting transactions are secured at the Inventory Org level.
-These applications (With the exception of Purchasing), sit below the Operating Unit level.
-Internal Shipping Networks can be setup to facilitate Inter-Org inventory movement.
-Multiple Inventory Orgs can be setup for a single Operating Unit. However, an Inventory Org cannot point to more than one Operating simultaneously.

Users:
- Users must vacillate between multiple Responsibilities to accomplish their daily tasks in R11i.

Shared Services:
-The Multi-Org architecture is not setup to facilitate a Shared Services environment in R11i releases. - Oracle has addressed this issue in R12 using MOAC - Multi-Org Access Control Concept.

Oracle TCA - R12

TCA- What's New in R12:
======================
What is Oracle TCA:

Trading Community Architecture (TCA) is a model for maintaining
information about parties and customers who belong to an
enterprise's commercial community. Parties can be people or
organizations that can enter into business relationships accross
the e-Business Suite.

The main purpose of TCA is to provide a single source of information
in the TCA Registry for all Oracle e-Business Suite Applications.


















R12 - Intergration Capabilities:












R12- TCA:

















Trading Community Manager:















This is predefined for country United States in any new instance as
STATE, COUNTY, CITY and POSTAL CODE. For other countries,
you can simply create the geography structure depending on your
requirement or just use the Copy Structure feature to create the
geography structure based on the geography structure of another
country.

First query the country for which you want setup Address Validation
by Country Code or Name.

















Real-time address validation validates addresses during address
entry. For Oracle Trading Community Architecture, and other
Oracle E-Business Suite applications, this validation is based on the
information and setup of Geography Hierarchy.

Real-time address validation is performed only for addresses created
in the HZ_LOCATIONS table and countries that are set up in
Geography Hierarchy.

Geography Hierarchy Overview:
Geography Hierarchy is a data model that lets you establish conceptual parent-child relationships between geographies. Oracle Trading Community Architecture (TCA) and other Oracle E-Business Suite applications can leverage Geography Hierarchy for various uses related to locations, such as real-time address validation and tax calculation.

The geography information is centrally located in TCA and share among all the applications.

An ability to create and maintain hierarchies between multiple address elements or tax authorities for the purpose of real time address validation and/or tax calculation.

- Does not include street level Data. - Hierarchies can be created from Tax Vendor provided Data using utility provided by eBusiness Suite Tax Application. - Users can further extend the hierarchies that were created based on data provided by Tax Vendors.

Configuration: - Define Country specific structures for geographic hierarchies. - Manage Geography Details. - Manage Data Validation Levels during Data Entry.

Geography Validation: For example, for the United States, you specified the North America address style for HZ_LOCATIONS addresses. Then for that combination, you map the US country structure to HZ_LOCATIONS attributes, and specify that Country, State, and Postal Code values are used for geography validation.

When the user enters a US address using this address style, the address must have the correct country , state, and postal code combination, based on Geography Hierarchy data, to be considered geographically valid. Use the Geography Validation check box to specify which address elements are mandatory during address entry, based on the geography validation level for country selected.

The Geography Validation Level for Country can be:
1. Error: Only completely valid addresses can be saved, with all mandatory address elements entered.
2. Mandatory Fields Only: Invalid addresses can be saved without warning users, but only if users enter a value for all mandatory addresses elements, as defined by the geography types selected for Geography Validation usage.
3. No Validation: All addresses can be saved including incomplete and invalid addresses.
4. Warning: Invalid addresses are saved after warning users.

The Geography Validation usage determines which address elements re mandatory during ddress entry, based on the geography validation level selected. For example, if the validation level is Mandatory Fields Only, then users must enter address elements that have Geography Validation usage, but the address can still be saved if values are invalid.

Tax Validation: For example, for the United States, you had specified the North America address style for HR_LOCATIONS_ALL. Then for that combination, you map the US country structure to HR_LOCATIONS_ALL attributes, and specify that County, State, and City are used for tax validation. When a sales transaction involves an address with the North America address style, the address must have the correct county, state, and city combination, based on Geography Hierarchy data, to be considered valid for tax calculation.

Important: For either usage, do not skip more than one consecutive level unless you are certain that the selected geography types can uniquely identify geographies. For example, the country structure is: State, County, City, and Postal Code, and you want to select just State and Postal Code for geography or tax validation. However, for the combination of California and 94065, the city can be either Redwood Shores or Redwood City. In this case, you should also select at least City for geography or tax validation.

AR - New Customer User Interface:
- Customer Standard form that has been existing till R11i is finally gone.
- Oracle Introduced a brank new HTML UI built using OA Frame works leveraging TCA that can be used to manage Customers, Accounts, etc.
- New UI Displays both Party Level as well as Account Level information
which is sepearted into Customer Overview and Account Overview.



















Find Customer screen now uses DQM (Simple and Advanced Search
Match Rules) similar to what you see in Customers Online or Customer Data Librarian.
- After search, you can create new customer or see customer
overview. From here you can add accounts or modify accounts
and so on.
- You can update customer information from customer overview
page.


R12- Customer Tab Structure:


















R12 Supplier is part of TCA:

Supplier can be setup from many different application, but the
datails stored in a single repository called the Trading Community
Architecture.

TCA Provides a single, common definition that can be used to
identify customer,suppliers and organziations that provide you with
goods or services.

Supplier information is shared by the following applications.

1. TCA:
All Supplier information is defined in TCA.

2. Purchasing:
Purchasing uses supplier defaults, such as freight terms, shipping
details,on requisitions, purchase orders, request for Quotations, etc.

3. Payables:
Payables uses supplier defaults, such as method of payment and bank
account information during invoice entry and payment processing.

4. Fixed Asssets:
Assets maintains the supplier name and number for each asset record.

5. Property Manager:
Property Manager exports lease invoces for suppliers to payables so
they may be paid.

6. iSupplier Portal:
iSupplier Portal allows you to grant acces to supplier to review order,
receipt and payment details for the supplier. Supplier can enter
planned (with PO) or unplanned (without PO) invoices and update
supplier information.

MOAC: if you are using Multi organization support feature, you
cannot enter the following information at the supplier level, only at
the supplier site level they can be entered.

- Liability Account
- Prepayment Account
- Distribution set
- Invoice Tax Code
- Future Dated Payment Account.

As we know in R12 Supplier is part of TCA , thus the link between
PO_VENDORS and HZ_PARTIES is PO_VENDORS.party_id.
The link betweenPO_VENDOR_SITES_ALL and
HZ_PARTY_SITES is PO_VENDOR_SITES_ALL.party_site_id.
When a Supplier is createdRecord will be Inserted in HZ_PARTIES.
When the Supplier Site is created Record will be Inserted in
HZ_PARTY_SITES. When Address is created it will be stored
in HZ_LOCATIONS.

Bank Model is part of TCA in R12.

If we compare the bank setup in R11i and R12, we can notice
that banks was utilized into three different places Finance ,
Payroll and Treasury, which requires altogether a different
setup.

We have notice in 11i there was functionality in which Payables in
which we will create an employee type supplier from HR data and
it will contain name and address info but not bank information.

The reason for this is that HR/Payroll does not store the bank
information in a standard way that makes the integration possible.

Bank Account Data Model in R12 is consolidated in TCA Model.

Overview of Bank Model:

The Bank Model feature allows you to define and keep track of all
banks accounts in the e-Business suite in one place and explicity
grant account access to multiple operating Units and users.

The bank model is based on the following concept:

- Centrally located in Cash Managment.
- TCA Parties associated with bank branches.
- Owned by LE's.
- Applications that use Bank Accounts are AR, AP, Treasury
and Payroll.
- Grouped by Country.

In Prior release AP owned banks, bank branches and bank accounts,
such bank accounts could be used by AR, Payroll and Treasury.
In R12, Banks and Bank Branches are created as TCA parties,
The bank Accounts are associated with Bank Branches but reside
with in the Cash Management Application.
During the Bank Account creation, you are able to define in which
application this bank account can be used.
















TCA Tables:




















Bank Accounts will be stored in a new table called
CE_BANK_ACCOUNTS and will be located at a Bank Branch.
The new table which hold the bank information are as:
CE_BANK_ACCOUNT:stores bank account attributes
CE_BANK_ACCT_USES_ALL : This stores the bank account
use attributes specific to Operating Unit (AR, AP) and Legal
Entity (Treasury).
CE_GL_ACCOUNTS_CCID :The accounting data pertaining to
the bank account use will be stored in the table.

Oracle Trading Community Architecture (TCA)

Trading Community Model:
Trading Community is defined as a group of entities taking part
in commerce.
Trading Community includes both persons and Organization.

What is Oracle TCA?
TCA: Trading Community Architecture.
Oracle’s Central Customer Data Repository underlying all
Oracle Applications. TCA is a Model, an Architecture and
NOT a Module.

Evolution of TCA Release:











Oracle Trading Community Architecture (TCA) is a data model
that allows you to manage complex information about the
parties, or customers, who belong to your commercial community,
including organizations, locations, and the network of hierarchical
relationships among them.











The below diagram depicts the relationship among the entities
of Trading Community.

Entity Relationship:















TCA Key Entities:

1. Parties:
“Party” is an entity in the Trading Community Model that can
enter into business relationships.
A party is a person, organization (branch, subsidiary, legalentity,
holding company, etc) or relationship (this is a relationship
between two parties).

2. Party Relationships:
A relationship is a state of connectedness between two parties ,
Each relationship consists of two entities; a subject and an object.
Relationship - Associates any two parties

Binary relationship between two parties Inter-Company and
Intra-company relationships Non-business relationships too Are
reciprocalUnlimited in number Dynamic in natureBoth seeded or
user-defined Relationship Types Relationship itself is stored as a
partyAny number of relationships between two organizations
(org-to-org) or two persons (person-to-person) or anorganization
and a person (org-to-person).

The relationship model enables you to :
- Understand the complex relationships among members of your
trading community.
- Use this information to make better business decisions.

3. Customer Accounts:
“Customer Accounts ” is used to represent a party with whom
the deploying company has a selling relationship, regardless of
whether anything has actually been purchased or serviced.
An Account cannot be created without party.

4. Locations:
A geographic location, physical place, usually with an address.
Any number of location types. (e.g., bill-to, ship-to, mail-to).
Allows for restricted use of a location (begin / end date).

Is a Party Site with one or more site uses Only one of the
Party Sites can become an “Identifying Address” for the Party
An Account Site in the context of an Account .

Geographic location including Spatial content Many to Many
relationship between party and location.

Party Site: Links a Party with a Location and describes the usage
of that Location (e.g., mailing address, billing address, home address, etc.).
Parties may be associated to one or more Locations and any one
location may have one or more uses.

5. Contracts.
A Person related to an Organization, this can be a relationship
between an organization and a person as well as between two people.















Party Vs Account:
====================

The Concept of Customer is sepearted in two layers ,
- Party Layer.
- Account Layer.

CRM applications are referring to the Party layer when they
refer to “Customer”.
ERP Applications, on the other hand, are referring to the
Account layer, when they refer to “Customer”.

The word “Customer” is the combination of both the “Party layer”
and the “Account layer”.
- Party layer exists independent of any selling or buying relationship.
- Customer Account layer exists in the context of a Party and only
when a selling relationship exists.

The Party Layer captures intrinsic truths about a person or
organization. The Account Layer captures the details describing
the Party’s financial relationship with the implementing
organization. The Account Layer cannot exist without the Party Layer.

Party:
The unique set of truths about a person, organization, group or
relationship. An entity that can enter into a business relationship.

Person - A unique individual (dead or alive) of interest to the owner
of the software.
Organization - A legal entity recognized by some government authority.
Group - a combination of two or more people, organizations or
groups of created for the use of the owner of the software.
Relationship - links two Parties, regardless of type.

Once a Party Relationship is formed, it may become a Party
in its own right. A Party can belong to any number of relationships.

The combination of a party and its account(s) is considered a customer

Customer Module Overview:
• TCA is designed to encapsulate all members of a ‘trading community.’
• A trading community may include customers, prospects, suppliers,
distributors, resellers, consortiums, etc.
• TCA not only allows for the tracking of relationships between the
implementing organization and its trading partners, but also tracks
relationships between the trading partners themselves.














Customer Standard Strucutre in 11i.:

















Account Layer - Components:
===========================
Account:
The attributes of the implementing organization’s financial
relationship with a party, Cannot exist without a Party.
Account Site:
A Party Site that is used within the context of an Account.
Account Site Use:
Use of an Account Site (e.g.billing, shipping).
Account Relationships:
Established between accounts to allow sharing of billing, shipping,
and pricing information.
- One way or bi-directional,
- 1:1 Relationships – not used for multiple levels of a hierarchy .

Party Layer components:
================================
Party: An entity that can enter into a business relationship
- Person (Mr SMITH).
- Organization (ABC) .
Party Relationship: A relationship between two parties .
- Mr. Smith “Contact Of” ABC
- ABC Handhelds “Division Of” ABC - HQ
Location: Essentially an address.
Party Site: The connection between a location and a party that
indicates that a particular location is valid for that party.
Party Site Use: Use of a Party Site (e.g. billing, shipping, purchasing).

Entering orImporting Customer Data into TCA: