TCA

Oracle® Trading Community Architecture
User Guide
Release 11i
Part No. B12310-03
April 2005
Oracle Trading Community Architecture User Guide, Release 11i
Part No. B12310-03
Copyright © 2002, 2005, Oracle. All rights reserved.
Primary Author: Essan Ni
Contributing Author: Charlie Ahern
Contributor: Alan Adams, Olga Basman, Anupam Bordia, Carol Chow, Rashmi Goyal, Rahul
Kamath, Charity Kocher, Shannon Kreps, Jocelyn Lin, Kavi Nandakumar, Cuby Ng, Ronda Pitts, Srinivasa
Rangan, Ajay Singh, Adam Stafford, Matt Stitz, Ryan Taketa
The Programs (which include both the software and documentation) contain proprietary information; they
are provided under a license agreement containing restrictions on use and disclosure and are also protected
by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly,
or decompilation of the Programs, except to the extent required to obtain interoperability with other
independently created software or as specified by law, is prohibited.
The information contained in this document is subject to change without notice. If you find any problems
in the documentation, please report them to us in writing. This document is not warranted to be error-free.
Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs
may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose.
If the Programs are delivered to the United States Government or anyone licensing or using the Programs on
behalf of the United States Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS

Programs, software, databases, and related documentation and technical data delivered to U.S. Government
customers are "commercial computer software" or "commercial technical data" pursuant to the applicable
Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication,
disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be
subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent
applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights
(June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently
dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup,
redundancy and other measures to ensure the safe use of such applications if the Programs are used for such
purposes, and we disclaim liability for any damages caused by such use of the Programs.
The Programs may provide links to Web sites and access to content, products, and services from third parties.
Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear
all risks associated with the use of such content. If you choose to purchase any products or services from
a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a)
the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the
third party, including delivery of products or services and warranty obligations related to purchased products
or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing
with any third party.
Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.
Contents
Send Us Your Comments
Preface
1 Overview
Introduction to Oracle Trading Community Architecture . . . . . . . . . . . . . . . 1- 1
Oracle Customer Data Management . . . . . . . . . . . . . . . . . . . . . . . . . 1- 2
Using Oracle Trading Community Architecture . . . . . . . . . . . . . . . . . . . . 1- 3
2 Bulk Import
Bulk Import Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 1
Loading Data into the Interface Tables . . . . . . . . . . . . . . . . . . . . . . . . 2- 2
Interface Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 6
Import Batch to TCA Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . 2- 8
Import Batch De-Duplication Report . . . . . . . . . . . . . . . . . . . . . . . 2- 9
Import Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Import Address Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Matching Records with Source System Management . . . . . . . . . . . . . . . . 2-11
Import Validations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Postimport Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Resolving Import Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
TCA Import Batch Purge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
3 Third Party Data Integration

Third Party Data Integration Overview . . . . . . . . . . . . . . . . . . . . . . . 3- 1
Introduction to D&B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 2
Data Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 3
Business Information Report (BIR) . . . . . . . . . . . . . . . . . . . . . . . . 3- 5
Data Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 5
Source System Management Impact . . . . . . . . . . . . . . . . . . . . . . . . . 3- 6
Mapping of D&B Data Elements . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 7
Details on Creating Parties with D&B Information . . . . . . . . . . . . . . . . . . 3- 8
Online Purchasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 8
Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3- 9
iii
Searching for Existing Parties in the TCA Registry . . . . . . . . . . . . . . . . . 3-10
Searching for Companies in the D&B Database . . . . . . . . . . . . . . . . . . . 3-10
Selecting Data Products or BIRs . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Requesting D&B Investigations . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Mapping API Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Load D&B Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Batch Loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Generate Request List for D&B Batch Load . . . . . . . . . . . . . . . . . . . . 3-20
Transferring a Request List File to D&B . . . . . . . . . . . . . . . . . . . . . . 3-21
D&B Import Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
Loading Rationalized Legacy Data . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
Viewing Information from Data Sources . . . . . . . . . . . . . . . . . . . . . . . 3-23
Subtabs of Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24
Duplicate DUNS Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
DNB Global Data Products Request Report . . . . . . . . . . . . . . . . . . . . . 3-25
4 Locations and Phones

Locations Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 1
Address Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 1
eLocations Spatial Data Integration . . . . . . . . . . . . . . . . . . . . . . . . . 4- 4
Spatial Information for Locations Batch Update . . . . . . . . . . . . . . . . . . 4- 4
Generate Time Zone for Locations . . . . . . . . . . . . . . . . . . . . . . . . . . 4- 5
Generate Time Zone for Phone Numbers . . . . . . . . . . . . . . . . . . . . . . . 4- 5
5 Relationship Manager
Relationship Manager Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 1
Relationships Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 2
Relationship Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . 5- 3
Major Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 3
Party Relationship Management Process . . . . . . . . . . . . . . . . . . . . . . . 5- 4
Searching for Parties and Viewing Results . . . . . . . . . . . . . . . . . . . . . . 5- 6
Viewing Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 7
Creating Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 7
Editing Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 9
Viewing Relationship Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . 5- 9
D&B Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Updating Relationships by Moving Parties in a Hierarchy . . . . . . . . . . . . . . 5-14
6 Batch Duplicate Identification

Batch Duplicate Identification Overview . . . . . . . . . . . . . . . . . . . . . . . 6- 1
Defining Duplicate Identification Batches . . . . . . . . . . . . . . . . . . . . . . 6- 2
Reviewing Duplicates and Creating Merge Batches . . . . . . . . . . . . . . . . . . 6- 4
Submitting Merge Batches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6- 7
iv
7 Party Merge
Party Merge Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 1
Party Merge Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 2
Party Merge Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 4
Duplicate Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 5
Impact on Source IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 7
Impact on D&B Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 8
Creating Merge Batches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7- 8
Merging Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
Merging Party Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
Merging Party Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Merging Organization Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
Viewing Profile Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
Merging Party Sites of a Party . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Processing Merge Batches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
Reviewing the Party Merge Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
Identifying Types of Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
Party and Customer Account Merge . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
A Reports and Processes
B Standard Navigation Paths

Standard Navigation Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B- 1
Index
v
Send Us Your Comments
Oracle Trading Community Architecture User Guide, Release 11i

Part No. B12310-03
Oracle welcomes your comments and suggestions on the quality and usefulness of this publication. Your
input is an important part of the information used for revision.
• Did you find any errors?
• Is the information clearly presented?
• Do you need more information? If so, where?
• Are the examples correct? Do you need more examples?
• What features did you like most about this manual?
If you find any errors or have any other suggestions for improvement, please indicate the title and part
number of the documentation and the chapter, section, and page number (if available). You can send
comments to us in the following ways:
• Electronic mail: appsdoc_us@oracle.com
• FAX: 650-506-7200 Attn: Oracle Customer Data Management Documentation Manager
• Postal service:
Oracle Customer Data Management Documentation Manager
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
If you would like a reply, please give your name, address, telephone number, and electronic mail address
(optional).
If you have problems with the software, please contact your local Oracle Support Services.
vii
Preface
Intended Audience
Welcome to Release 11i of the Oracle Trading Community Architecture User Guide.
This guide contains the information needed to learn about Oracle Trading Community
Architecture and how to use features from the Trading Community Manager
responsibility to create, update, enrich, and cleanse the data in the TCA Registry.
See Related Documents on page x for more Oracle Applications product information.
TTY Access to Oracle Support Services

Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services
within the United States of America 24 hours a day, seven days a week. For TTY support,
call 800.446.2398.
Documentation Accessibility
Our goal is to make Oracle products, services, and supporting documentation accessible,
with good usability, to the disabled community. To that end, our documentation
includes features that make information available to users of assistive technology.
This documentation is available in HTML format, and contains markup to facilitate
access by the disabled community. Accessibility standards will continue to evolve over
time, and Oracle is actively engaged with other market-leading technology vendors to
address technical obstacles so that our documentation can be accessible to all of our
customers. For more information, visit the Oracle Accessibility Program Web site at
http://www.oracle.com/accessibility/ .
Accessibility of Code Examples in Documentation

Screen readers may not always correctly read the code examples in this document. The
conventions for writing code require that closing braces should appear on an otherwise
empty line; however, some screen readers may not always read a line of text that consists
solely of a bracket or brace.
Accessibility of Links to External Web Sites in Documentation

This documentation may contain links to Web sites of other companies or organizations
that Oracle does not own or control. Oracle neither evaluates nor makes any
representations regarding the accessibility of these Web sites.
ix
Structure
1 Overview
This chapter provides an overview of using Oracle Trading Community Architecture.
2 Bulk Import
This chapter describes using Bulk Import to load data from legacy or other external
systems into the TCA Registry.
3 Third Party Data Integration
This chapter describes using Third Party Data Integration to purchase and batch load
information from D&B, load legacy data into the TCA Registry after the data has been
rationalized by D&B, review information from data sources, and run reports for more
information about the D&B data you have acquired.
4 Locations and Phones
This chapter describes using features for locations and phones, including address
validation, eLocations Spatial Data Integration, and time zone generation for locations
and phones.
5 Relationship Manager
This chapter describes using Relationship Manager to view, create, and edit relationships
among existing parties in the TCA Registry.
6 Batch Duplicate Identification
This chapter describes using batch duplicate identification to create batches of duplicate
parties to merge.
7 Party Merge
This chapter describes using Party Merge to identify batches of duplicates, merge
duplicate parties and party sites, and resolve Party Merge errors.
A Reports and Processes
This section lists the reports and processes, including relevant request sets, that
are seeded in Standard Request Submission for the Trading Community Manager
responsibility.
B Standard Navigation Paths
This appendix describes standard navigation paths for using Oracle Trading Community
Architecture.
Related Documents
You can choose from many sources of information, including online
documentation, training, and support services, to increase your knowledge and
understanding of Oracle Trading Community Architecture.
If this guide refers you to other Oracle Applications documentation, use only the Release
11i versions of those guides.
Online Documentation
All Oracle Applications documentation is available online (HTML or PDF).
• PDF Documentation: See the Oracle Applications Documentation Library CD
for current PDF documentation for your product with each release. The Oracle
x
Applications Documentation Library is also available on OracleMetaLink and
is updated frequently.
• Online Help: Online help patches (HTML) are available on OracleMetaLink.
• About Documents: Refer to the About Document for the mini-pack or family pack
that you have installed to learn about new documentation or documentation patches
that you can download. About Documents are available on OracleMetaLink.
Guides Related to All Products

• Oracle Applications User’s Guide: This guide explains how to enter data, query, run
reports, and navigate using the graphical user interface (GUI). This guide also
includes information on setting user profiles, as well as running and reviewing
reports and concurrent processes. You can access this user’s guide online by choosing
Getting Started with Oracle Applications from any Oracle Applications help file.
Guides Related to This Product

• Oracle Trading Community Architecture Administration Guide: This guide
describes how to administer and implement Oracle Trading Community
Architecture. You set up, control, and manage functionality that affect data in
the TCA Registry.
• Oracle Trading Community Architecture Reference Guide: This reference
guide contains seeded relationship types, seeded Data Quality Management
data, D&B data elements, Bulk Import interface table fields and validations, and
a comprehensive glossary. This guide supplements the documentation for Oracle
Trading Community Architecture and all products in the Oracle Customer Data
Management family.
• Oracle Trading Community Architecture Technical Implementation Guide: Use
this technical implementation guide to learn how to use the public Oracle Trading
Community Architecture application programming interfaces (APIs) and develop
callouts based on Oracle Workflow Business Events System (BES). For each API, this
guide provides a description of the API, the PL/SQL procedure, and the Java
method, as well as a table of the parameter descriptions and validations. For each
BES callout, this guide provides the name of the logical entity, its description, and
the ID parameter name. Also included are setup instructions and sample code.
• Oracle Customers Online User Guide: This guide describes how to use Oracle
Customers Online to view, create, and maintain your customer information. Oracle
Customers Online is based on Oracle Trading Community Architecture data model
and functionality, and is also part of the Oracle Customer Data Management
product family.
• Oracle Customers Online Implementation Guide: This guide describes how to
implement Oracle Customers Online.
• Oracle Customer Data Librarian User Guide: Use this guide to learn how to use
Oracle Customer Data Librarian to establish and maintain the quality of the TCA
Registry, focusing on consolidation, cleanliness, and completeness. Oracle Customer
Data Librarian has all of the features in Oracle Customers Online, and is also part of
the Oracle Customer Data Management product family.
• Oracle Customer Data Librarian Implementation Guide: This guide describes
how to implement Oracle Customer Data Librarian. As part of implementing
xi
Customer Data Librarian, you must also complete all the implementation steps
for Oracle Customers Online.
• Oracle Receivables User Guide: This user guide describes how to enter and
maintain party and customer account information, define and use customer
profiles, run reports for customer information, merge customer accounts or sites
within an account, and import party and customer accounts.
Installation and System Administration

• Oracle Applications Concepts: This guide provides an introduction to
the concepts, features, technology stack, architecture, and terminology for
Oracle Applications Release 11i. It provides a useful first book to read before
installing Oracle Applications. This guide also introduces the concepts behind
Applications-wide features such as Business Intelligence (BIS), languages and
character sets, and Self-Service Web Applications.
• Installing Oracle Applications: A Guide to Using Rapid Install: This guide
provides instructions for managing the installation of Oracle Applications
products. In Release 11i, much of the installation process is handled using Oracle
Rapid Install, which minimizes the time to install Oracle Applications and the
technology stack by automating many of the required steps. This guide contains
instructions for using Oracle Rapid Install and lists the tasks you need to perform to
finish your installation. You should use this guide in conjunction with individual
product user’s guides and implementation guides.
• Upgrading Oracle Applications: Refer to this guide if you are upgrading your
Oracle Applications Release 10.7 or Release 11.0 products to Release 11i. This guide
describes the upgrade process and lists database and product-specific upgrade
tasks. You must be either at Release 10.7 (NCA, SmartClient, or character mode) or
Release 11.0, to upgrade to Release 11i. You cannot upgrade to Release 11i directly
from releases prior to 10.7.
• Maintaining Oracle Applications Documentation Set: Use this guide to
help you run the various AD utilities, such as AutoUpgrade, AutoPatch, AD
Administration, AD Controller, AD Relink, License Manager, and others. It
contains how-to steps, screenshots, and other information that you need to run
the AD utilities. This guide also provides information on maintaining the Oracle
Applications file system and database.
• Oracle Applications System Administrator’s Documentation Set: This guide
provides planning and reference information for the Oracle Applications System
Administrator. It contains information on how to define security, customize menus
and online help, and manage concurrent processing.
• Oracle Alert User’s Guide: This guide explains how to define periodic and event
alerts to monitor the status of your Oracle Applications data.
• Oracle Applications Flexfields Guide: This manual provides flexfields
planning, setup, and reference information, as well as information on creating
custom reports on flexfields data.
Other Implementation Documentation

• Oracle Applications Product Update Notes: Use this guide as a reference for
upgrading an installation of Oracle Applications. It provides a history of the changes
to individual Oracle Applications products between Release 11.0 and Release 11i. It
xii
includes new features, enhancements, and changes made to database objects, profile
options, and seed data for this interval.
• Oracle Workflow Administrator’s Guide: This guide explains how to complete
the setup steps necessary for any Oracle Applications product that includes
workflow-enabled processes, as well as how to monitor the progress of runtime
workflow processes.
• Oracle Workflow Developer’s Guide: This guide explains how to define new
workflow business processes and customize existing Oracle Applications-embedded
workflow processes. It also describes how to define and customize business events
and event subscriptions.
• Oracle Workflow User’s Guide: This guide describes how Oracle Applications
users can view and respond to workflow notifications and monitor the progress
of their workflow processes.
• Oracle Workflow API Reference: This guide describes the APIs provided for
developers and administrators to access Oracle Workflow.
• Oracle Applications Developer’s Guide: This guide contains the coding
standards followed by the Oracle Applications development staff. It describes the
Oracle Application Object Library components needed to implement the Oracle
Applications user interface described in Oracle Applications User Interface Standards
for Forms-Based Products. It also provides information to help you build your custom
Oracle Forms Developer 6i forms so that they integrate with Oracle Applications.
• Oracle eTechnical Reference Manuals: Each eTechnical Reference Manual
(eTRM) contains database diagrams and a detailed description of database
tables, forms, reports, and programs for a specific Oracle Applications product. This
information helps you convert data from your existing applications and integrate
Oracle Applications data with non-Oracle applications, and write custom reports for
Oracle Applications products. Oracle eTRM is available on OracleMetaLink.
• Oracle Applications User Interface Standards for Forms-Based Products: This
guide contains the user interface (UI) standards followed by the Oracle Applications
development staff. It describes the UI for the Oracle Applications products and tells
you how to apply this UI to the design of an application built by using Oracle Forms.
Do Not Use Database Tools to Modify Oracle Applications Data

Oracle STRONGLY RECOMMENDS that you never use SQL*Plus, Oracle Data Browser,
database triggers, or any other tool to modify Oracle Applications data unless otherwise
instructed.
Oracle provides powerful tools you can use to create, store, change, retrieve, and
maintain information in an Oracle database. But if you use Oracle tools such as SQL*Plus
to modify Oracle Applications data, you risk destroying the integrity of your data and
you lose the ability to audit changes to your data.
Because Oracle Applications tables are interrelated, any change you make using an
Oracle Applications form can update many tables at once. But when you modify Oracle
Applications data using anything other than Oracle Applications, you may change a row
in one table without making corresponding changes in related tables. If your tables get
out of synchronization with each other, you risk retrieving erroneous information and
you risk unpredictable results throughout Oracle Applications.
xiii
When you use Oracle Applications to modify your data, Oracle Applications
automatically checks that your changes are valid. Oracle Applications also keeps track of
who changes information. If you enter information into database tables using database
tools, you may store invalid information. You also lose the ability to track who has
changed your information because SQL*Plus and other database tools do not keep a
record of changes.
xiv
1
Overview
This chapter provides an overview of using Oracle Trading Community Architecture.

This chapter covers the following topics:
• Introduction to Oracle Trading Community Architecture
• Oracle Customer Data Management
• Using Oracle Trading Community Architecture
Introduction to Oracle Trading Community Architecture

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.
This information is maintained in the TCA Registry, which is the single source of trading
community information for Oracle E-Business Suite applications. These applications, as
well as TCA itself, provide user interfaces, batch data entry functionality, and other
features for you to view, create, and update Registry information. See: Using Oracle
Trading Community Architecture, page 1- 3 .
The key entities in TCA include:
• Parties: Entities of type Person or Organization that can enter into business
relationships. Parties can also be of type Relationship. For example, Joe as himself is
a party of type Person, but Joe as a contact for Vision Corporation is a party of type
Relationship. Every party in the TCA Registry has a unique Registry ID.
TCA includes an extensive variety of information for parties, for example party
name, addresses, contacts, and contact points. Joe as a person can have a personal
phone number that differs from the phone number for the relationship of Joe as a
contact.
• Party sites: Addresses that parties use for specific purposes, or uses.
• Customers: Parties with whom you have a selling relationship.
• Customer accounts: The business relationships between you and your customers.
• Customer account sites: Party sites used in the context of customer accounts for
specific purposes, or uses, for example ship-to and bill-to account sites.
• Locations: Geospatial points, usually defined by an address.
Overview 1-1
• Contacts: People who have a contact or employment relationship with an
organization or person.
• Contact points: Means of contact, for example, phone and e-mail address.
TCA also includes conceptual functionality that helps you manage and understand your
trading community. For example, you can use relationships to model the roles that
parties play with respect to one another, and classifications to classify entities.
Entities and Attributes Details

Entities in the TCA Registry consist of logical groups of descriptive, related
attributes. For example, the Person Profile entity contains attributes, such as last name
and date of birth, that describe parties of type Person. Likewise, the Organization Profile
entity consists of attributes that describe parties of type Organization, the Address entity
has address-related attributes, and so on.
An entity corresponds to one or more tables in TCA. For example, attribute values for a
party record are stored in the HZ_PARTIES table.
Related Topics
Oracle Customer Data Management, page 1- 2
Oracle Customer Data Management

Oracle Trading Community Architecture is the foundation not only for the Oracle
E-Business Suite, but also specifically for the product family that it belongs to: Oracle
Customer Data Management (CDM). CDM includes:
• Oracle Customers Online (OCO): Oracle Customers Online lets you
view, create, maintain, and enrich your central repository of customer data.
See: Oracle Customers Online User Guide and Oracle Customers Online Implementation
Guide.
• Oracle Customer Data Librarian (CDL): Oracle Customer Data Librarian lets
you establish and maintain an accurate, duplicate free, and complete customer
database. This application includes all of the features from Oracle Customers Online.
See: Oracle Customer Data Librarian User Guide and Oracle Customer Data Librarian
Implementation Guide.
• Oracle Customer Data Hub (CDH): Oracle Customer Data Hub lets you centralize
customer data from various source systems, providing an single view of your
customers. The links between each source system and the Hub are operational and
real-time. CDH includes all the TCA features, for example to maintain source
systems, and cleanse and enrich data, and also includes Oracle Customers Online.
For reference material that supplements not only TCA but CDM product
documentation, see Oracle Trading Community Architecture Reference Guide.
Related Topics
Introduction to Oracle Trading Community Architecture, page 1- 1
1-2 Oracle Trading Community Architecture User Guide

Using Oracle Trading Community Architecture
Various applications in the Oracle E-Business Suite can view, create, and update the TCA
Registry data. Because this information is shared, any changes made in one application
is reflected in all applications.
TCA itself provides the Trading Community Manager responsibility, which includes
these features that you can use to maintain, enrich, and cleanse the TCA Registry.
• Bulk Import: Import batches of data from external source systems into the TCA
Registry. See: Bulk Import Overview, page 2- 1 .
• Customers: Enter and maintain party and customer account
information. See: Entering Parties and Customer Accounts, Oracle Receivables User
Guide and Defining Customer Profile Classes, Oracle Receivables User Guide.
Run these reports for customer information:
• Customer Listing - Detail
• Customer Listing - Summary
• Customer Profiles Report
• Customer Relationships Listing
• Duplicate Customer Report
See: Listing Reports, Oracle Receivables User Guide.
• Third Party Data Integration: Enrich the data for organizations and persons with
D&B information. See: Third Party Data Integration Overview, page 3- 1 .
• Locations: Validate addresses, acquire longitude and latitude information
through eLocations Spatial Data Integration, and generate time zones for
locations. See: Locations Overview, page 4- 1 .
• Phones: Generate time zones for phones. See: Generate Time Zone for Phone
Numbers, page 4- 5 .
• Relationship Manager: Create and manage relationships among existing parties in
the TCA Registry. See: Relationship Manager Overview, page 5- 1 .
• Batch duplicate identification: Create batches of potentially duplicate parties to
merge. See: Batch Duplicate Identification Overview, page 6- 1 .
• Party Merge: Cleanse the TCA Registry by merging duplicate parties and duplicate
sites within a party. See: Party Merge Overview, page 7- 1 .
• Customer Account Merge: Cleanse the TCA Registry by merging duplicate
customer accounts and duplicate sites within an account. See: Merging Customers,
Oracle Receivables User Guide.
Note: If you have Oracle Customer Data Librarian, the data librarian
can permanently purge parties from the TCA Registry. See: Party Purge
Overview, Oracle Customer Data Librarian User Guide.
The Trading Community Manager responsibility also provides features for administering
and implementing TCA. See: Introduction to Administration, Oracle Trading Community
Architecture Administration Guide.
Overview 1-3
Related Topics
Introduction to Oracle Trading Community Architecture, page 1- 1

2
Bulk Import
This chapter describes using Bulk Import to load data from legacy or other external
systems into the TCA Registry.
• Bulk Import Overview
• Loading Data into the Interface Tables
• Import Batch to TCA Registry
• Resolving Import Errors
• TCA Import Batch Purge
Bulk Import Overview

Use Oracle Trading Community Architecture (TCA) Bulk Import to load data from
legacy or other external systems in bulk into the TCA Registry. TCA provides validations
and optional de-duplication to ensure the quality of the imported information.
The import is only for information on the party level. To import both party and account
information, use Customer Interface. See: Customer Interface, Oracle Receivables User
Guide.
Note: Customer Interface runs independently and does not regard party
information already loaded in the TCA Registry. In particular, if the
process does not find an existing account site or account contact point, it
creates a new account site or contact point, as well as the associated party
site or contact point, even if the party level versions already exist. As a
result, if duplicates are created, use Party Merge or Oracle Customer
Data Librarian to resolve them. See: Party Merge Overview, page 7- 1 or
De-Duplication Overview, Oracle Customer Data Librarian User Guide.
Your administrator can set up for Bulk Import. See: Setting Up Bulk Import, Oracle
Trading Community Architecture Administration Guide.
Bulk Import Process

1. Load data into the interface tables. See: Loading Data into the Interface Tables,
page 2- 2 .
2. Run the Import Batch to TCA Registry program to import a batch into the TCA
Registry. See: Import Batch to TCA Registry, page 2- 8 .
Bulk Import 2-1

3. Optionally run the Import Batch De-Duplication report to view results of batch
de-duplication. See: Import Batch De-Duplication Report, page 2- 9 .
4. Run the TCA Import Error report to view errors, and reload the corrected
data. See: Resolving Errors, page 2-15.
5. Purge data from the interface tables. See: TCA Import Batch Purge, page 2-15.
Related Topics
Using Oracle Trading Community Architecture, page 1- 3
Loading Data into the Interface Tables

You should have a strong knowledge of the data and data structure to be imported. You
can load data through:
• SQL/ETL Load: Create scripts or use tools to extract the source
information, transform the values to meet the data requirements of the interface
tables, and populate the interface tables with large volumes of information. See: Bulk
Import Interface Tables, Oracle Trading Community Architecture Reference Guide.
• D&B Load: Use the standard D&B bulk file that you receive from D&B and run
the D&B Import Adapter request set to automatically map and load the D&B
information into the interface tables. See: D&B Import Adapter, page 3-21 and
Batch Loading, page 3-18.
• File Load: Use Oracle Customers Online (OCO) or Oracle Customer Data Librarian
(CDL) to load data from a comma-separated value (CSV) file, or file delimited by
another allowed character, into the interface tables. See: File Loads Overview, Oracle
Customers Online User Guide.
Import Batches
A set of data to be loaded into the TCA Registry at one time is called a batch. The data in
one batch must be from the same data source. The interface tables can store as many
batches from different sources as needed, and any number of batches can be actively
populating the interface tables at the same time. However, if a D&B import batch is being
loaded into the interface tables, using the D&B Import Adapter request set, the tables are
locked and all other batches must wait until the D&B batch is completed. The request set
uses direct inserts into the interface tables, which requires table-level locks.
Note: When the request set is running, you also cannot run the Import
Batch to TCA Registry program to transfer any batch from the interface
tables into the TCA Registry.
Batch IDs
Each import batch must have a batch ID. Use the create batch procedure from the Create
Import Batch API to guarantee that a unique batch ID is assigned.
Call the following script to create a batch ID:

Set serveroutput on;
DECLARE
x_batch_id NUMBER;
x_return_status VARCHAR2(4000);
x_msg_count NUMBER;
x_msg_data VARCHAR2(4000);
BEGIN
hz_imp_batch_summary_v2pub.create_import_batch(NULL,’&batchname’,’
&batchdescription’,
’&ORIGSYS’,’&loadtype’,12,x_batch_id,x_return_status,x_msg_co
unt,x_msg_data);
dbms_output.put_line(SubStr(’x_batch_id = ’||TO_CHAR(x_batch_id),
1, 255));
dbms_output.put_line(SubStr(’x_return_status = ’||x_return_status,
1,255));
dbms_output.put_line(SubStr(’x_msg_count = ’||TO_CHAR(x_msg_count)
, 1, 255));
dbms_output.put_line(SubStr(’x_msg_data = ’||x_msg_data,1,255));
COMMIT;
EXCEPTION
WHEN OTHERS THEN
dbms_output.put_line(SubStr(’Error ’||TO_CHAR(SQLCODE)||’: ’|
|SQLERRM, 1, 255));
RAISE;
END;
See: Create Import Batch API, Oracle Trading Community Architecture Technical
Implementation Guide.
Unique IDs for Interface Table Records

You must provide a unique ID for each record in the interface table. The unique ID is
a combination of:
• The source system code, defined through Source System Management (SSM)
administration, which identifies the source that the imported data comes from
• The source ID, which identifies the record in the source system
In the HZ_PARTIES, HZ_PARTY_SITES, HZ_CONTACT_POINTS, and
HZ_ORG_CONTACTS tables, these unique IDs are treated as source IDs for Source
System Management. In other tables that do not support SSM, the ID is treated as
a logical key. See: Source Systems Overview, Oracle Trading Community Architecture
Administration Guide.
These IDs serve to link:
• Details of each party together, as foreign key references among interface tables.
• The data in the source system, now in the interface tables, to the target TCA
tables, for making updates to existing parties in the Registry from the same source
data. See: Matching Records with Source System Management, page 2-11.
You should maintain all unique IDs locally in your system, and use them in the future to
update specific information in the TCA Registry.
Bulk Import 2-3

Unique Source IDs for Importing Associated Accounts
If you plan to use Customer Interface to import accounts that are associated with the
imported parties, you must ensure that the source ID alone is unique across all source
systems. Customer Interface uses only source IDs, not source system codes, so the
imported account must have a unique source ID to link to the corresponding imported
party.
For example, if you are importing a party and do not plan to import associated
accounts, you pass for the imported party:
• Source system code: MKT
• Source ID: 141442
You only need to ensure that this combination is unique across all source systems. If
you are importing a party and plan to import associated accounts, then you pass for the
imported party:
• Source system code: MKT
• Source ID: MKT141442
You can concatenate the source system code and source ID values to use as the source
ID for the party, or implement your own system to ensure that the source IDs alone
are unique across all source systems. When you load the accounts with Customer
Interface, you would pass the MKT141442 source ID to associate the accounts with the
imported party. See: Customer Interface, Oracle Receivables User Guide.
Inserts and Updates

Through import, you either insert new records into the Registry or update existing
TCA records. An update means that the imported information, if not null, completely
overwrites all values in the corresponding TCA record.
• All records inserted into the TCA tables are assumed to be active.
• You can update TCA Registry records of any status through import, but you cannot
change the status value itself during import.
The matching phase of the import process determines whether the interface table record
is an insert or update. See: Matching Records with Source System Management, page
2-11.
You can use the optional INSERT_UPDATE_FLAG column in the interface tables for
insert or update protection: I for insert and U for update. The system matching must
align with the action in this column. If not, the record is marked with error and not
loaded into TCA. If the column is left blank, the system matching alone decides between
insert or update for each record.
If the HZ: Use Data Sharing and Security During Import profile option is set to Yes, then
the import process invokes Data Sharing and Security (DSS) each time that a TCA
record is updated. DSS provides additional security against update and is enabled for
these tables involved in import:
• HZ_CONTACT_POINTS
• HZ_CODE_ASSIGNMENTS
• HZ_PARTIES
• HZ_PARTY_SITES

• HZ_RELATIONSHIPS
See: Data Sharing and Security Overview, Oracle Trading Community Architecture
If the HZ: Validate Flexfields During Import profile option is set to Yes, then flexfield
validation also applies to inserts and updates for these tables:
• HZ_LOCATIONS
• HZ_PARTIES
Null Values for Update

When a record in the interface table is designated to update an existing record upon
import, any null values in that record would not update the TCA value. The existing
value in TCA remains the same after import. You are not required to pass values in all
interface table columns when values are optional and not available from a given source
system.
If you want to intentionally overwrite a TCA value with NULL, you must pass a specific
value, as defined in these profile options:
• HZ: Character Value to Indicate NULL During Import
• HZ: Date Value to Indicate NULL During Import
• HZ: Numeric Value to Indicate NULL During Import
For example, the HZ: Date Value to Indicate NULL During Import profile option is set to
01-01-4000, and a record in the TCA Registry currently has an end date of 02-02-2005. If
you want to update the date with a null value, then you must pass 01-01-4000 for
that column.
Party and Party Site Numbers

The PARTY_NUMBER and PARTY_SITE_NUMBER columns in the TCA tables must
contain unique values.
If values for these columns are passed in the interface tables, the import process checks
for the uniqueness during the import.
• If unique, the values are accepted.
• If not unique, the record fails with a unique index error.
If no values for these columns are passed, the import process generates values from an
internal sequence.
• If the sequence numbers are unique, the values are accepted.
• If not unique, the record fails with a unique index error.
You should maintain one of these strategies:
• Always pass values for these columns so that the import process does not have to
generate sequence numbers.
Bulk Import 2-5

• Never pass values for these columns so that the generated sequence numbers would
not conflict with existing values in the Registry.
Primary Flags
Primary flags indicate which record is the primary one when multiple records exist. For
example, if a party has multiple bill-to addresses, the main bill-to address is marked
as primary.
Primary flags are exposed in these interface tables, which correspond to TCA tables that
contain primary flags:
• HZ_IMP_ADDRESSES_INT
• HZ_IMP_ADDRESSUSES_INT
• HZ_IMP_CLASSIFICS_INT
• HZ_IMP_CONTACTPTS_INT
If a new party is inserted through import, you can define primary flags for any of
the above child entities.
If an existing party in the Registry do not have any contact points and is being updated
with one or more contact points, you can mark one of the imported contact points as
primary. If you do not specify any of the new records as primary, the import process
marks one at random. If you mark more than one record as primary, the import process
will pick one of the marked records at random.
If the party already has an existing address, contact point, address use, or
classification, then you cannot change the primary status through import. Even if
you pass a value in the PRIMARY_FLAG column of the interface table, the value is
ignored. You can only change primary statuses through a user interface or APIs.
Related Topics
Interface Tables, page 2- 6
Bulk Import Overview, page 2- 1
Interface Tables
This table shows the interface tables and the TCA tables that the data would be
imported into. The interface tables do not include any columns that have been made
obsolete in TCA.

Entity Interface Table TCA Table
Addresses HZ_IMP_ADDRESSES_INT HZ_LOCATIONS

HZ_PARTY_SITES
Address Uses HZ_IMP_ADDRESSUSES_ HZ_PARTY_SITE_USES

INT
Classifications HZ_IMP_CLASSIFICS_INT HZ_CODE_ASSIGNMENTS
Credit Ratings HZ_IMP_CREDITRTNGS_ HZ_CREDIT_RATINGS

INT
Contact Points HZ_IMP_CONTACTPTS_INT HZ_CONTACT_POINTS
Financial Numbers HZ_IMP_FINNUMBERS_INT HZ_FINANCIAL_NUMBERS
Financial Reports HZ_IMP_FINREPORTS_INT HZ_FINANCIAL_REPORTS
Parties HZ_IMP_PARTIES_INT HZ_PARTIES

HZ_PERSON_PROFILES
HZ_ORG_PROFILES
Relationships HZ_IMP_RELSHIPS_INT HZ_RELATIONSHIPS

HZ_ORG_CONTACTS
(optional)
HZ_PARTIES
Contacts HZ_IMP_CONTACTS_INT HZ_RELATIONSHIPS

HZ_ORG_CONTACTS
HZ_PARTIES
Contact Roles HZ_IMP_CONTACTROLES_ HZ_ORG_CONTACT_ROLES

INT
See: Bulk Import Interface Tables, Oracle Trading Community Architecture Reference Guide.
Interface Table Parent and Child Relationships

The parent and child relationships among the import interface tables are:
• HZ_IMP_PARTIES_INT is the parent of all interface tables.
• HZ_IMP_FINREPORTS_INT is the parent of HZ_IMP_FINNUMBERS_INT.
• HZ_IMP_ADDRESSES_INT is the parent of HZ_IMP_ADDRESSUSES_INT.
• HZ_IMP_CONTACTS_INT is the parent of HZ_IMP_CONTACTROLES_INT, and
potentially HZ_IMP_ADDRESSES_INT and HZ_IMP_CONTACTPTS_INT because
addresses and contact points can be defined at the contact level.
If a child entity record has an error, the parent entity record can still be imported if it
has no errors. If a parent entity record has errors, however, all related child entity
records will also fail.
Bulk Import 2-7

Related Topics
Loading Data into the Interface Tables, page 2- 2
Import Batch to TCA Registry

Use the Import Batch to TCA Registry program to import a batch from the interface
tables into the TCA Registry. The program provides optional preimport processes you
can perform on the data before the actual import into TCA:
• Batch de-duplication: Identify and resolve duplicates within the batch that you
are importing from the interface tables.
Note: The Import Batch to TCA Registry program identifies only
duplicates with respect to the batch that you are importing. You
cannot check for duplicates between batches in the interface tables.
You can run the Import Batch De-Duplication report to view results. See Import
Batch De-Duplication Report, page 2- 9 .
• Address validation: See: Import Address Validation, page 2-11.
• Registry de-duplication: Identify duplicates between the interface tables and
the Registry.
Tip: You should purge data from the interface tables after the
corresponding batch has been loaded to TCA, to reduce the overall size
of the interface tables and improve performance for subsequent batch
loads. See: TCA Import Batch Purge, page 2-15.
Prerequisites
• The data you want to import must be loaded into the interface tables. See: Loading
Data into the Interface Tables, page 2- 2 .
• Optionally check that the D&B Import Adapter request set is not currently running. If
it is and you submit the Import Batch to TCA Registry program, the program will be
pending until the request set is complete. See: Import Batches, page 2- 2 .
• If you are running the Import Batch to TCA Registry program for an import batch
that was not loaded into the interface tables using File Load in Oracle Customers
Online or Oracle Customer Data Librarian, optionally check that another non-File
Load batch is not currently being loaded into the TCA Registry. If it is, and you
submit the program for a non-File Load batch, the program will be pending until
the process for the other batch is complete. See: File Loads Overview, Oracle
Customers Online User Guide.
Program Parameters
Batch
Enter the batch to import.
Import Run Options

Specify whether to run both preimport and import processes, or only the preimport
processes.

If you plan to run batch de-duplication, you can run only preimport processes and then
run the Import Batch De-Duplication report to preview batch de-duplication results.
Run Batch De-Duplication

Specify whether you want to run de-duplication on the batch or not.
Batch De-Duplication Match Rule

If you select to run batch de-duplication, you must enter the match rule to use. Only
match rules of type Bulk Duplicate Identification are used for batch de-duplication.
Action to Take on Duplicates

Specify how to resolve duplicates found with batch de-duplication. The specified action
would be taken on the batch before the data is imported into the TCA Registry.
Run Address Validation

Specify whether you want to run address validation on the batch or not.
Run Registry De-Duplication

Specify whether or not you want to run de-duplication between the batch and the
TCA Registry.
Registry De-Duplication Match Rule

If you select to run Registry de-duplication, you must enter the match rule to
use. Only match rules of type Bulk Duplicate Identification are used for Registry
de-duplication. You can select the same match rule as for batch de-duplication.
If the specified match rule is designated for Automerge, then potential duplicates that
reach or exceed the match rule’s:
• Match threshold, but not the automatic merge threshold, are included in System
Duplicate Identification (SDI) batches for merge consideration in Oracle Customer
Data Librarian.
• Automatic merge threshold are automatically merged after the import.
If the match rule is not enabled for Automerge, then all potential duplicates that reach or
exceed the match threshold are included in SDI batches.
All records that do not reach the match threshold are considered not duplicates and
inserted as new parties. All potential duplicates are also inserted into the TCA Registry
as new parties, but then accordingly included in SDI batches or automatically merged.
Related Topics
Import Process, page 2-10
Import Batch De-Duplication Report

If you run batch de-duplication as part of the Import Batch to TCA Registry program, you
can run the Import Batch De-Duplication report:
Bulk Import 2-9

• After the preimport processes and before the actual import, to preview the
de-duplication results.
• After the import, to view the actual de-duplication results.
The report shows the duplicates that were identified and resolved within the batch
that you are importing from the interface tables. This de-duplication does not resolve
duplicates between the batch and the TCA Registry itself.
Report Parameter
Batch ID
Enter the batch that was imported with batch de-duplication.
Related Topics
Import Batch to TCA Registry, page 2- 8
Import Process
When the Import Batch to TCA Registry program is submitted, this process follows:
1. The batch de-duplication and address validation runs, if selected.
Duplicates found through batch de-duplication are resolved as you specified in the
Action to Take on Duplicates parameter, for example, to keep the records that
are last updated.
If you chose to run preimport processes only so that you can preview preimport
results, then address validation includes all records. If not, then address validation
includes only records that batch de-duplication determines as not duplicates.
2. The data in the interface tables are matched against source system mappings to
determine if imported records are inserted as new parties or to update existing
parties. See: Matching Records with Source System Management, page 2-11.
3. For performance reasons, the records are populated into staging tables for processing
before loading into the TCA tables.
4. If you have selected the optional Registry de-duplication, then duplicates are
identified between the batch that you are importing and the TCA Registry. All
parties are to be inserted as new parties, but then the duplicates are resolved
as described in step 7.
5. After any selected preimport processes finish, depending on your choice, either:
• The actual import into TCA starts immediately.
• You start the actual import by rerunning the program, after you optionally:
• Review preimport process statistics from the program output.
• Run the Import Batch De-Duplication report for this import batch, if
batch de-duplication was run. The report output provides a preview of
the de-duplication results.
6. Mandatory validations are performed on all data, and records that pass all
validations are loaded into the TCA Registry. Records that fail are marked with error
and not imported. See: Import Validations, page 2-13.

7. If Registry de-duplication was run, then:
• System Duplicate Identification batches are created with potential duplicates for
merge consideration in Oracle Customer Data Librarian. See: System Duplicate
Identification, Oracle Customer Data Librarian User Guide.
• Duplicates are automatically merged through Automerge, if
applicable. See: Automerge, Oracle Trading Community Architecture
• Records that are not duplicates are inserted as new parties.
8. Postimport processes automatically run. See: Postimport Processes, page 2-14.
9. If you ran batch de-duplication, optionally run the Import Batch De-Duplication
report for this batch. The report output provides the de-duplication results.
Related Topics
Import Address Validation

If you choose to validate the addresses in the interface tables before importing them into
the TCA Registry, the addresses are validated using address validation adapters. An
adapter connects TCA to an external source of information, which provides the
validation service.
Each address is validated through the default adapter set up for each country. For
example, if the Vision adapter is the default for Thailand, then all Thai addresses in the
interface tables are validated against Vision’s standard addresses.
If an address from the interface tables differs from the validated address, it is updated
with the validated address only if it is valid above the threshold defined for the
adapter. Such an update is called an address correction. For example, if the adapter
configuration has the threshold at the municipality level, an address in the interface
tables is corrected if at least its city or town is valid.
Note: Aside from the validation threshold, address correction only
occurs if the update does not violate other validations, such as tax
validation rules.
After the addresses are validated and corrected in the interface tables, they are ready for
import into the TCA Registry.
Related Topics
Matching Records with Source System Management

When the import into the TCA tables starts, the matching phase of the import process
automatically begins to identify if each record in the interface table has an associated
record in the TCA Registry. The matching determines whether an imported record is
inserted as a new party or updates an existing party in the TCA Registry.
The unique ID of each record in the interface table is compared against the Source System
Management (SSM) mappings. See: Unique IDs for Interface Table Records, page 2- 3 .
Bulk Import 2-11

A SSM mapping links a TCA record to the original record from an external source. SSM
mappings are enabled for these tables:
• HZ_PARTIES
• HZ_PARTY_SITES
• HZ_ORG_CONTACTS
See: Source Systems Overview, Oracle Trading Community Architecture Administration
Guide.
The unique ID indicates the source ID and source system of the interface table record. If
that unique ID matches a SSM mapping, the interface table record will be used to update
the corresponding existing record in TCA. If no match is found, the interface table record
will be inserted into the TCA Registry as a new party.
For example, you import a record from the Vision source system, with source ID 100, for
the first time. This record is inserted as a new party in TCA, and a SSM mapping is
created between this TCA party and the source ID 100 from Vision. If you try to reimport
the record from Vision with source ID 100, that record would be matched to the existing
SSM mapping, and the reimported data would update the existing TCA party.
Note: Each combination of source ID and source system can update only
one party in the TCA Registry.
You can choose to load only entities without the associated party, as long as the
provided source ID and source system matches a parent record in the TCA Registry to
be updated. For example, you can import addresses without parties, if the addresses
are matched to existing parties. Otherwise, you must import associated parties along
with addresses.
You cannot change the source ID of a record in the TCA Registry during the import
process unless you are importing data from D&B.
Matching Addresses
If an address’s source ID in the interface tables matches an existing SSM address
mapping, then the interface table address is compared to the existing address.
• If the addresses are exactly the same, the existing address will be updated with
the imported address.
• If not the same, the value passed in the CORRECT_MOVE_INDICATOR column
of the HZ_IMP_ADDRESSES_INT table determines if the address should be a
correction or move. The default is move.
• Correction: The HZ: Allow Updates of Address Records During Import profile
option must be set to Yes. The imported address will update the existing
address. If the country, state, province, county, city, or postal code changes due
to the update, the tax assignment is deleted.
If the profile option is set to No, you will get an error. You should either change
the profile option or the CORRECT_MOVE_INDICATOR column value.
• Move: A new location is created with the imported address, and the existing
address is inactivated. Any SSM mappings to the existing address will be

changed to the new address, but none of the transactions are automatically
transferred.
Related Topics
Import Validations
Before import from the interface tables into the TCA Registry, a record must pass import
validations. All elements of an interface table record must succeed, or the entire record is
considered with error.
Records that fail validations are marked, and all errors for one record are captured after
the entire record is validated. After validation, only successful records are imported
into the Registry.
The types of validations include:
• Lookups. For example, the HZ_ORG_CONTACTS.DEPARTMENT_CODE value
should be from the DEPARTMENT_TYPE lookup. If the HZ: Allow Import of
Records with Disabled Lookups profile option is set to Yes, then values that reference
disabled lookups are still valid.
• Foreign keys. For example, HZ_LOCATIONS.COUNTRY should have a foreign key
to FND_TERRITORIES.TERRITORY_CODE.
• Requirements, if a value is mandatory or conditionally required. For
example, HZ_CONTACT_POINTS.CONTACT_POINT_TYPE is mandatory, while
HZ_CONTACT_POINTS.EDI_ID_NUMBER is mandatory only if the value for
CONTACT_POINT_TYPE is EDI.
• Cross-column dependencies. For example, EDI as the value for
HZ_CONTACT_POINTS.COMMUNICATION_TYPE is allowed only if the value for
HZ_CONTACT_POINTS.OWNER_TABLE_ID is a party ID of an organization.
• TCA columns that are not updateable. Values that are entered for such columns are
ignored without error.
• Flags that should have Y, N, or NULL as values.
• Flexfields. If the HZ: Validate Flexfields During Import profile option is set to
Yes, then flexfields are validated based on the flexfield setups.
These tables have flexfields:
• HZ_LOCATIONS
• HZ_PARTIES
• Address sharing. Multiple parties cannot share a single address. If the same address
applies to two parties, you must enter the address for each party.
• Business rules.
The parent and child relationships of entities also affect whether a record succeeds or
fails validation. See: Interface Table Parent and Child Relationships, page 2- 7 .
Bulk Import 2-13

Related Topics
Bulk Import Interface Tables, Oracle Trading Community Architecture Reference Guide
Postimport Processes
After data is loaded into the TCA Registry, the TCA Import Postprocessing program
automatically runs and kicks off various postimport processes. Even before some of
these processes finish, imported data can already be viewed and used in the Oracle
E-Business Suite.
• The Data Quality Management staged schema is synchronized to include any
information added or changed during the import process.
• Person name information is reformatted to be properly displayed based on
context, location, and language.
• Party names are generated for relationship party records.
• Fuzzy keys are generated for customer and address information.
• Phone numbers imported in a raw format are split into the appropriate segments, for
example area code, prefix, and so on.
• Phone numbers that include letters are converted into numbers.
• Person title information is denormalized into the HZ_PARTIES and
HZ_PERSON_PROFILES tables.
• Certain relationship information is denormalized into the HZ_PARTIES table to
improve performance for certain Oracle E-Business Suite applications.
• The D&B hierarchy is created from D&B data that has been entered in a flat format.
• A time zone description is applied to each address and phone number that has been
imported or updated during import.
• Tax assignment is calculated.
If the TCA Import Postprocessing program results in error, you can resubmit it from
Standard Request Submission.
Program Parameters
Use these parameters to resubmit the TCA Import Postprocessing program for a
previous run that resulted in error.
p_request_id
Enter the request ID of the Import Batch to TCA Registry submission that the failed
postprocessing was originally run for.
p_num_of_worker
Enter the number of workers to run the program. The recommended number is four, and
the maximum number is ten.
Related Topics

Resolving Import Errors
Records with errors are marked with E in the INTERFACE_STATUS column
of the interface table and associated with detail records in the import errors
table, HZ_IMP_ERRORS. Use the TCA Import Error report to view the error details for a
specific import batch.
To resolve errors:
1. Run the TCA Import Error report, specifying the batch that was imported.
2. Go to the report output to see import errors for the batch.
3. Correct the data directly in the interface tables.
4. Change the INTERFACE_STATUS column value to C for each corrected record.
5. Run the Import Batch to TCA Registry program again for the same batch. Only
records with an INTERFACE_STATUS column value of C is processed.
Resolving Postimport Errors

If the TCA Import Postprocessing program results in error, review the log of the program
from Standard Request Submission. After you fix the errors, you can resubmit the TCA
Import Postprocessing program. See: Postimport Processes, page 2-14.
Related Topics
TCA Import Batch Purge

Use the TCA Import Batch Purge program to purge batches from the import interface
tables, as well as internal tables such as staging and error tables. You permanently
remove all records in the batch from all these tables.
You should purge batches after a satisfactory number of records are successfully
imported into the TCA Registry from that batch.
Purging the interface tables improves import performance. To archive imported
data, you should copy the data to a set of custom tables.
Program Parameters
Batch Identifier
Enter the batch ID of the batch that you want to purge.
Related Topics
Bulk Import 2-15

3
Third Party Data Integration
This chapter describes using Third Party Data Integration to purchase and batch load
information from D&B, load legacy data into the TCA Registry after the data has been
rationalized by D&B, review information from data sources, and run reports for more
information about the D&B data you have acquired.
• Third Party Data Integration Overview
• Introduction to D&B
• Source System Management Impact
• Mapping of D&B Data Elements
• Details on Creating Parties with D&B Information
• Online Purchasing
• Batch Loading
• Loading Rationalized Legacy Data
• Viewing Information from Data Sources
• Duplicate DUNS Report
• DNB Global Data Products Request Report
Third Party Data Integration Overview

Use Oracle Trading Community Architecture (TCA) Third Party Data Integration
to purchase third party data from D&B to enrich the data in the TCA Registry. D&B
information is integrated with the party records to maintain accurate information that
you can use to evaluate credit risks.
The D&B information coexists with user-entered data in the Registry. In Oracle
applications, users can view and use information from different data sources, such as
user entered and D&B. Your administrator can control how the D&B and user-entered
data are used and displayed in Oracle applications, as well as set up Third Party Data
Integration.
Note: Even though all purchased D&B data are stored in TCA
tables, some information might not appear in user interfaces, based on
the Single Source of Truth (SST) setup.
Third Party Data Integration 3-1

See: Setting Up Third Party Data Integration, Oracle Trading Community Architecture
Administration Guide and Single Source of Truth Overview, Oracle Trading Community
In the TCA Registry, a party exists separately from any business relationship that it
enters into with other parties. A customer account for a party represents a business
relationship that parties can enter into. The account has information about the terms and
conditions of doing business with the party. The D&B information that you purchase is
stored in TCA for parties, not for customer accounts. See: Customer Overview, Oracle
Receivables User Guide.
Purchasing D&B Data

D&B provides profile, demographic, credit risk, and financial information about parties
to help you make business decisions about the parties that you transact with.
To acquire third party information from D&B, you can use either of these methods:
• Online purchasing for a single party, page 3- 8 .
• Batch loading for multiple parties, page 3-18.
You can also load legacy data that D&B has rationalized into the TCA Registry, page 3-22 .
Viewing Information from Data Sources

For specific parties, view and compare the data from different data sources, such as user
entered and D&B. See: Viewing Information from Data Sources, page 3-23.
You can also run two reports for more information about the D&B data in the TCA
Registry:
• Duplicate DUNS Report: To review parties with the same DUNS
Number. See: Duplicate DUNS Report, page 3-25.
• DNB Global Data Products Request Report: To determine what D&B data products
have been requested. See: DNB Global Data Products Request Report, page 3-25.
Related Topics
Introduction to D&B, page 3- 2
Source System Management Impact, page 3- 6
Mapping of D&B Data Elements, page 3- 7
Details on Creating Parties with D&B Information, page 3- 8
Introduction to D&B
Dun & Bradstreet (D&B) maintains a growing global database of more than 70
million businesses worldwide. This database provides key information such as
D&B’s unique identifier, the DUNS Number, and executive contacts, as well as
demographic, financial, and credit risk data. D&B provides information in the form of
data products and Business Information Reports that contain a variety of data elements.

D&B Contact Information
If you have a D&B relationship manager assigned to your company, you should contact
that individual for any D&B issues or information, for example, to interpret credit ratings
and other information that D&B provides.
If you do not have a relationship manager, contact D&B’s Global Service Center at (888)
243-4566, e-mail dnb4oracle@dnb.com, or visit http://www.dnb.com.
Related Topics
Data Products, page 3- 3
Business Information Report (BIR), page 3- 5
Third Party Data Integration Overview, page 3- 1
Data Products
D&B data products meet the needs of businesses that transact business worldwide. Each
data product provides different sets of information called data elements to meet your
business decision-making criteria. The data products contain information such as:
• Business identity
• Number of employees
• Years in operation
• Industry
• Corporate structure
• Financial history
• Proprietary D&B scores and ratings that indicate credit risk
You can use Third Party Data Integration to obtain any of these data products:
• Business Verification
• Quick Check
• Delinquency Score
• Global Failure Risk Score
• Financial Standing
• Decision Support
• Enterprise Management
• Commercial Credit Score
Business Verification
The Business Verification Global Data Product (GDP) provides the information necessary
to verify a company’s existence and validate its location with background information
such as primary name, address, phone, SIC codes, branch indicator, and D&B DUNS
Number.

Quick Check
The Quick Check GDP provides information that you use to perform low-risk credit
assessments with D&B’s core credit evaluation information. You can prescreen
prospective customer accounts, evaluate a party’s creditworthiness, and develop
appropriate credit terms. In addition to the information in the Business Verification
GDP, Quick Check includes financial event indicators, basic financial data, number of
employees, payment activity summary, and the D&B Rating.
Delinquency Score
The Delinquency Score GDP contains a statistically modeled D&B score that indicates the
risk of a company to make delinquent payments, based on payment history information
from the D&B file. The higher the Delinquency Score, the lower the probability of
payment delinquency. D&B’s Delinquency Score lets you rank the customer accounts
in your credit portfolio from highest to lowest risk of payment delinquency. You can
also quickly divide new and existing accounts into various risk segments to determine
appropriate marketing or credit policies. Most of the information included in the Quick
Check GDP is also in the Delinquency Score GDP.
Global Failure Risk Score

The Global Failure Risk Score GDP contains a statistically derived predictive score that
helps you assess the risk of business failure when dealing with global companies and
managing the customer accounts in your global credit portfolios. The Global Failure
Risk Score is a single, uniform measure predicting the risk of business failure over a
12-month period. This data product is ideal for companies that have centralized credit
processes and policies or those with decentralized credit processing that plan to globally
or regionally standardize decision making. The Global Failure Risk Score GDP contains
the information included in the Delinquency Score GDP and other financial data.
Financial Standing
The Financial Standing GDP provides key financial information such as sales volume, net
worth, assets, and liabilities to help you assess a party’s financial condition. You can
determine the financial strength of a business to set credit terms and conditions, perform
research, or determine the strengths and weaknesses of a prospective customer
account, existing customer account, or supplier. Key income statement and balance
sheet information are provided, as well as information included in the Global Failure
Risk Score GDP.
Decision Support
The Decision Support GDP provides information that you use with a decision support
system or manual credit evaluation processes. You can improve the timeliness
and consistency of credit decisions by matching your company’s credit policies
and requirements to D&B credit scores and ratings, as well as the party’s financial
information. This data product helps you set credit terms and conditions for medium- to
high-risk value decisions, prioritize collection efforts, evaluate potential merger and
acquisition candidates, and introduce rapid, accurate, and consistent credit decision
making. The Decision Support GDP contains the data included in the Financial Standing
GDP, as well as additional scores and ratings information.

Enterprise Management
The Enterprise Management GDP provides detailed demographic, corporate
structure, risk, and financial information. You can use this information to improve
risk assessment procedures, make better informed credit decisions, and improve the
acquisition and retention of customer accounts. Enterprise Management includes the
most complete set of data, scores, and ratings available about the party.
You can view the corporate structure that this GDP provides in a hierarchical display. The
hierarchical relationships within the structure make up the D&B hierarchy, which you
can access using Relationship Manager. See: D&B Hierarchy, page 5-11.
Commercial Credit Score (USA) Data Product

The Commercial Credit Score data product includes the Commercial Credit Score and
other data elements that you can use to predict the likelihood that a company would
pay invoices in a severely delinquent manner within the next 12 months. D&B defines
severe delinquency as the receipt of payment more than 90 days past the due date. This
data product also includes information about bankruptcies, delinquent payments, and
payment history.
Note: This data product is only available to D&B customers in the US
for businesses located in the US.
Related Topics
Data Elements, page 3- 5
Business Information Report (BIR)

The Business Information Report (BIR) provides many of the data elements from the
D&B database in a standard report format. You can order a BIR, store the report in your
database, and view the report whenever necessary.
The BIR usually includes:
• D&B rating
• General information such as number of employees, business history, and so on
• Financial statements
• Payment performance information, such as the D&B PAYDEX score
Related Topics
Data Elements, page 3- 5
Data Elements
The complete D&B database includes over 150 key business data elements. Each data
product consists of a fixed set of data elements. These data elements provide information
that you can use to identify, contact, and evaluate the credit risk of parties.
A few of the available data elements are:

• DUNS Number: Unique business identification number assigned by D&B to
each commercial entity in the D&B database. If an organization has multiple
locations, each location has a unique DUNS Number.
• D&B Rating: Rating that indicates a company’s creditworthiness. The rating usually
consists of a financial strength code and a risk indicator.
Note: For a key to the D&B Ratings, contact your local D&B
representative or D&B’s Global Service Center at (888) 243-4566, or
visit Customer Service at http://www.dnb.com.
• Local Business ID: The primary business identification number assigned to the
business by a government agency, chamber of commerce, or association.
• Parent Bankruptcy Chapter Conversion: Indicator of whether the parent of the
business has converted its bankruptcy filing from one chapter to another; for
example, from Chapter 11 to Chapter 7. This data element is only available as part of
the Commercial Credit Score data product.
Related Topics
General Data Elements, Oracle Trading Community Architecture Reference Guide
Financial Data Elements, Oracle Trading Community Architecture Reference Guide
Source System Management Impact

Source System Management (SSM) maps records in the TCA Registry with the source
system that the data comes from. See: Source Systems Overview, Oracle Trading
Community Architecture Administration Guide.
For D&B, the DUNS Number is used as the source ID, which identifies the record in the
source system. Each record from D&B with a unique DUNS Number can map to only
one party record in the TCA Registry. Likewise, if multiple parties in the Registry has the
same DUNS Number, only one of those records can be mapped to D&B. The party that is
actively mapped to D&B has what is called the mapped DUNS Number.
Important: When you repurchase D&B data through batch load, and
several parties have the same DUNS Number, only the party with the
mapped DUNS Number is updated.
For both online purchase and batch load, when you acquire D&B data with a DUNS
Number that does not yet exist in TCA, the party is automatically mapped to D&B. For
example, you get D&B data for Vision Corporation for the first time, including the
DUNS Number for Vision. If that DUNS Number is not already mapped, then Vision
Corporation is created as a new party, with the mapped DUNS Number.
If you repurchase D&B information for Vision Corporation, and D&B provides a
different DUNS Number, then Vision gets a new, mapped DUNS Number.
You can also later acquire D&B information with the same DUNS Number for another
party, but only one of the two parties can have the mapped DUNS Number. The mapping
would automatically switch to the party that you are working with. For example:

• You are acquiring D&B information for Vision Corporation for the first time, and you
get DUNS Number A for Vision. Another party, however, already has that DUNS
Number and is mapped to D&B. The existing mapping would be inactivated, and
Vision would get the mapped DUNS Number.
• You are acquiring D&B information to update Vision, which currently has DUNS
Number A. D&B provides DUNS Number B to update Vision, but another party
already has DUNS Number B and is mapped to D&B. Again, the mapping for
DUNS Number B would go to Vision.
DUNS Number A is no longer a mapped DUNS Number, until you purchase D&B
data with DUNS Number A for a party.
Tip: Multiple parties with the same DUNS Number are allowed to
support different company situations. You should use the shared
DUNS Number to identify and merge duplicates, since only the
record with the mapped DUNS Number is updated through
batch load.
Related Topics
Mapping of D&B Data Elements

When you purchase D&B data online or batch load D&B information, certain D&B data
elements are mapped to the appropriate columns in the TCA Registry. Most of the
columns have the same names as the D&B data elements, but other columns have more
general names that differ from those used by D&B.
• Online purchasing: The Mapping API utility maps and loads the D&B data elements
from the HZ_PARTY_INTERFACE table into the TCA Registry. See: Mapping
API Utility, page 3-13.
• Batch loading: The D&B Import Adapter request set maps and loads the D&B data
elements to the appropriate import interface table columns. The mapped data is then
ready for import into the Registry. See: D&B Import Adapter, page 3-21.
DUNS Number is the Same as the Related DUNS Number

If the party is the headquarters, the HQ DUNS Number is the same as the DUNS
Number for the party. This case also applies to related parties. If the DUNS Number of
the related party is the same as the party DUNS Number, two possible scenarios arise:
• If the party is a Domestic Ultimate, Global Ultimate, or Headquarters, a relationship
is created between the party and its related party. Both of the companies in the
relationship will be the same, to convey that the party itself is of type Domestic
Ultimate, Global Ultimate, or Headquarters.
• If the related party does not have a parent, D&B does not provide parent information.
DUNS Number and Enquiry DUNS Number

Outside of North America, D&B does not store information at the branch level. If
you request information for a company that is a branch location outside of North
America, D&B provides data for its headquarters. The DUNS Number for the branch’s

headquarters is used to select the D&B data for the headquarters. The DUNS Number
for the branch is displayed as the Enquiry DUNS Number. If a headquarters record does
not exist in the TCA Registry, Third Party Data Integration automatically creates one.
Related Topics
Details on Creating Parties with D&B Information

When you online purchase or batch load D&B information for a party that does not
yet exist in the TCA Registry, you create a new party and load its D&B data. For this
party, both a D&B and a user-entered record are created in these tables:
• HZ_ORGANIZATION_PROFILES
• HZ_LOCATIONS
• HZ_PARTY_SITES
The user-entered records are also created because they are needed for the party to be
visible in the Oracle e-Business Suite applications. In all other tables where D&B data
is stored, only the D&B records are created. When D&B data is later refreshed for this
party, only the D&B records are updated, even in the above three tables.
If the D&B data refresh results in changes of the party address, only new D&B location
and party site records are created. The user-entered location and party site records are
not created or updated.
Related Topics
Online Purchasing
Use the online purchasing functionality of Third Party Data Integration to search for
and purchase Dun & Bradstreet (D&B) information on specific companies from D&B’s
database. You can update the information obtained from D&B during online sessions
or by using the batch loading process.
You can purchase and retrieve D&B information for organizations that exist or do not
exist in the TCA Registry. When you obtain D&B information about a company that does
not exist in the TCA Registry, a new party is created using the D&B data. See: Details
on Creating Parties with D&B Information, page 3- 8 .
Related Topics
Mapping API Utility, page 3-13
Load D&B Data, page 3-18

Process Overview
This diagram describes the process flow for purchasing D&B information online. You
can correct errors that might occur in this process. See: Correcting Mapping API Utility
Errors, page 3-14.
To purchase D&B information online:

1. Search for an existing party in the TCA Registry, page 3-10.
2. If the party exists, you view the information it currently has from data sources, if
any, page 3-23. You can search the D&B database for that company if you want to
initially purchase or update D&B information for the selected party.
If the party does not exist, you can search the D&B database to create a new party
with purchased D&B information.
3. Search for the company in the D&B database, page 3-10.
4. If the company exists in the D&B database:
• You can continue and select the data product or Business Information Report
(BIR) to purchase.
• And if the D&B information for the selected company is already purchased for at
least one existing party, you can either:
• Continue purchase by selecting a data product or BIR for your selected
or new party, page 3-11.
• Cancel the purchase.
If the company does not exist in the D&B database, you can request a D&B
investigation for a party, page 3-12.
5. After the purchase process completes, view the updated or purchased D&B
information for your party, page 3-23. If you purchased D&B information for a
party that did not exist in the TCA Registry, a new party is created with that D&B
information.

Searching for Existing Parties in the TCA Registry
You search for a party in the TCA Registry to:
• Find the party that you want to purchase D&B information for.
• Confirm that a party does not already exist before purchasing D&B information
to create a new party.
• View its existing third party and user-entered information.
Tip: With the advanced search criteria, you can search for only parties
with active mapped DUNS Numbers. This criterion is available only if
DUNS Numbers exist in the Registry. See: Source System Management
Impact, page 3- 6 .
If your search criteria do not match any existing party in the TCA Registry, or the specific
party that you are searching for is not displayed, you can create a new party with the
purchased D&B data. See: Searching for Companies in the D&B Database, page 3-10.
If your search criteria match the party you are searching for, click the party name to view
its third party and user-entered data, if any, and to optionally continue with purchasing
D&B data. See: Viewing Information from Data Sources, page 3-23.
In other Oracle applications, accordingly search for the party or customer. For
example, in Customers Online, you search for an organization as usual and, from the
overview and other pages for that organization, you can proceed to view existing
information from data sources and purchase D&B data.
Related Topics
Online Purchasing, page 3- 8
Searching for Companies in the D&B Database

Search the D&B database to determine if D&B’s database contains information
about your party. You can search for either a party that you want to create using
D&B information or for an existing party that you want to purchase or update D&B
information for.
Note: If you search by unique identifiers, you do not need to enter
required values for searching by company name and location, but you
must enter at least one identifier.
If you are purchasing data for an existing party that has no D&B information, the
identifying address is used as the default address search criterion. If the party already
has D&B information, then the address that D&B provided is the default.
Note: The most commonly used and effective search criterion is the
DUNS Number. Second is the local business ID, which can be assigned
by a governmental agency or a nongovernmental organization.
From the search results, you can:

• Request a D&B investigation for the party, page 3-12.
• Select the company to purchase information for, and then the data product or
BIR, page 3-11.

D&B Information Already Exists for a Party
If you are trying to purchase D&B information, and D&B data for the selected company
is already purchased for at least one other existing party, you can either:
• Continue to purchase the D&B data for the party that you are creating or
updating. See: Selecting Data Products or BIRs, page 3-11.
Note: Possible duplicate parties might exist in the TCA Registry
if the same D&B information applies to more than one party. You
should consider merging parties that are actually duplicates.
• Cancel the purchase.
Related Topics
Selecting Data Products or BIRs

After you find the party in the D&B database that you want to purchase information
for, you select one of the available data products or Business Information Reports
(BIR) to purchase. See: Data Products, page 3- 3 and Business Information Report
(BIR), page 3- 5 .
Tip: For a new or existing party that has no existing D&B data, you
might initially want to gather basic information about a company in
the form of a BIR.
The following table shows which data product provides information to the subtabs where
you can view D&B information. See: Viewing Information from Data Sources, page 3-23.

Subtab Data Product
Summary All
Business Verification All
Special Event • Commercial Credit Score
• Quick Check
Relationships Enterprise Management
BIR Business Information Report (BIR)
Credit and Risk • Commercial Credit Score
• Delinquency Score
• Global Failure Risk Score
• Quick Check
Financial Analysis • Decision Support
• Quick Check
After the D&B data is purchased, you can review the D&B information. See: Viewing
Information from Data Sources, page 3-23.
Related Topics
Requesting D&B Investigations

Request an investigation for a company that you cannot find in the D&B
database. Because of the time required to conduct an investigation, you cannot use D&B
data to create a new party at the same time that you request an investigation from D&B.
Information about the party defaults into this page to identify the party that you want to
investigate. If the party does not exist in the TCA Registry, the criteria entered for the
D&B database search provide the default identifying information. See: Searching for
Companies in the D&B Database, page 3-10.

Instructions Section
• Email To: The address that D&B uses to send an acknowledgement of your request
and to notify you when the investigation has been completed. A separate e-mail
provides you with a BIR containing the information that D&B gathered about
your party.
The e-mail address defaults with the one that your system administrator entered in
your user definition, if any.
See: Users Window, Oracle Applications System Administrator's Guide.
• Service: The level of priority for your investigation request.
In the US, a Regular investigation is usually carried out by D&B within five business
days. A Priority investigation is completed the next business day but incurs a
premium price from D&B.
• Additional Information: More details to identify your party or other instructions
to D&B.
Related Topics
Mapping API Utility

When you purchase D&B information online, the information is first loaded into the
HZ_PARTY_INTERFACE table. The Mapping API utility takes the data from the
interface table, and maps and loads them into the TCA Registry. See: Mapping of
D&B Data Elements, page 3- 7 .
The utility processes party data in two phases:
1. Data for the party is processed.
The utility retrieves records one by one for the parties from the interface table
and then processes them. Online requests for information cause the processing of
only one record.
New records in the interface table are identified with a STATUS data element value
of N. When the utility successfully processes a record, the utility changes the
STATUS value for the record to P1. If D&B does not have any information about
a business, the utility changes the party’s DUNS Number to 000000000 and the
STATUS value to B for blank.
If the utility cannot successfully process the record, it changes the STATUS value to
E1, to indicate that an error occurred. In some cases, the utility can automatically
correct invalid values from D&B, and it changes the STATUS value for the corrected
record to W1. See: Automatic Correction of Invalid D&B Values, page 3-14.
2. Information for related parties associated with the party is processed. Related
parties, such as the Parent, Headquarters, Domestic Ultimate, and Global Ultimate
locate the party within an organization’s hierarchy.
When you request D&B data for more than one party, the utility must process all
of the party records in the first step before processing data for the organizations
associated with each party. Only if a party record was successfully processed in the
first step can the utility process data for the organizations associated with that party.

When the utility successfully processes the organization data associated with
a party, it changes the STATUS value for the record to P2. If the utility cannot
successfully process the data, it changes the STATUS value to E2 to indicate that
an error occurred. In some cases, the utility can automatically correct invalid
values from D&B, and it changes the STATUS value for the corrected record to
W2. See: Automatic Correction of Invalid D&B Values, page 3-14.
Correcting Mapping API Utility Errors

The received data from online purchase is loaded into the HZ_PARTY_INTERFACE
table as one record. The record is automatically assigned a unique ID in the GROUP_ID
column. If there are no errors, the data automatically transfers into the appropriate TCA
tables for you to view and use.
In some cases, you need to manually transfer the data. If errors arise with the online
purchase, the data remains in the interface table. For example, D&B might provide
values in a format that is not valid for TCA number and date columns. Most E1 and
E2 errors occur due to changes in information codes that D&B provides for the data
elements. All errors are listed in the HZ_PARTY_INTERFACE_ERRORS table.
You should be able to access the interface table and correct any errors. After making the
necessary corrections, change the STATUS codes from E1 to N or from E2 to P1 so that
the corrected data will be appropriately processed next time.
After resolving the issues, use the Load D&B Data program to import the data from the
interface table into the TCA tables. In the Group ID parameter of the program, you can
specify the group ID of the record that you want to import, for example the one that
originally incurred an error. See: Load D&B Data, page 3-18.
Automatic Correction of Invalid D&B Values

The application can automatically correct invalid values from D&B for specific
attributes. Corrected values are loaded into the TCA Registry along with all other
valid values.
Invalid Values Changed to N

For specific attributes that need a Y or N value, if D&B provides something other than
Y,N, or null, then the invalid value is automatically changed to N. Information about
the correction is stored in the HZ_PARTY_INTERFACE_ERRORS table, except in the
cases of exceptions listed below.
The affected attributes and any exceptions are:
• ANNUAL_SALES_CONSOL_IND
• AUDIT_IND
• BANKRUPTCY_IND
Exception: If D&B provides null, the corrected value is N. Likewise, B is changed to
Y.
• BRANCH_FLAG
• CLAIMS_IND
• CONSOLIDATED_IND
• CRIMINAL_PROCEEDING_IND

• DISADV_8A_IND
• DISASTER_IND
• ESTIMATED_IND
• EXPORT_IND
• FINAL_IND
• FINCL_EMBT_IND
• FINCL_LGL_EVETN_IND
• FISCAL_IND
• FORECAST_IND
• IMPORT_IND
• JUDGEMENT_IND
Exception: If D&B provides null, the corrected value is N. Likewise, J is changed to Y.
• LABOR_SURPLUS_IND
• LIEN_IND
• MINORITY_OWNED_IND
• NO_TRADE_IND
Exception: If D&B provides null, the corrected value is Y.
• OOB_IND
Exception: If D&B provides OB, the corrected value is Y.
• OPENING_IND
• OPRG_SPEC_EVNT_IND
• OTHER_SPEC_EVNT_IND
• PARENT_SUB_IND
• PROFORMA_IND
Exception: If D&B provides null, the corrected value is N.
• PRNT_HQ_BKCY_IND
• QUALIFIED_IND
• RESTATED_IND
• SECURED_FLNG_IND
• SIGNED_BY_PRINCIPALS_IND
• SMALL_BUS_IND
• SUIT_IND
Exception: If D&B provides null, the corrected value is N. Likewise, J is changed to Y.
• TRIAL_BALANCE_IND
• UNBALANCED_IND

• WOMAN_OWNED_IND
Invalid Values Changed to Null or Valid Value

For specific attributes, invalid D&B values are changed to null or a correct value.
Information about the correction is stored in the HZ_PARTY_INTERFACE_ERRORS
table.
This table shows the attributes that are validated against tables and the corrected values.
Attribute Table Name Corrected Value
ANNUAL_SALES_ FND_CURRENCIES Null

CURRENCY
CAPITAL_CURRENCY_ FND_CURRENCIES Null

CODE
FINANCIAL_NUMBER_ FND_CURRENCIES Null

CURRENCY
MAX_CREDIT_CURRENCY FND_CURRENCIES Null
PHONE_COUNTRY_CODE HZ_PHONE_COUNTRY_ Null

CODES
PREF_FUNCTIONAL_ FND_CURRENCIES Null

CURRENCY
TANGIBLE_NET_WORTH_ FND_CURRENCIES Null

CURR
This table shows the attributes that are validated against lookup types and the corrected
values.
Attribute Lookup Type Corrected Value
HQ_BRANCH_IND HQ_BRANCH_IND Null

If D&B provides any of these
values, they are corrected as
follows:
• H becomes HQ
• B becomes BR
• S becomes SL
LOCAL_BUS_IDEN_TYPE LOCAL_BUS_IDEN_TYPE Null
RENT_OWN_IND OWN_RENT_IND Null
Invalid Values Accepted as Valid Lookup Code

For specific attributes that are validated against lookups, invalid D&B
values are accepted and automatically added as a valid lookup code to the

corresponding lookup type. Information about this correction is not stored in the
HZ_PARTY_INTERFACE_ERRORS table.
This table shows the attributes and the corresponding lookup types.
Attribute Lookup Type
CREDIT_SCORE_COMMENTARY1 to CREDIT_SCORE_COMMENTARY
CREDIT_SCORE_COMMENTARY10
CREDIT_SCORE_OVERRIDE_CODE FAILURE_SCORE_OVERRIDE_CODE
EMP_AT_PRIMARY_ADR_EST_IND EMP_AT_PRIMARY_ADR_EST_IND
EMP_AT_PRIMARY_ADR_MIN_IND EMP_AT_PRIMARY_ADR_MIN_IND
FAILURE_SCORE_COMMENTARY1 to FAILURE_SCORE_COMMENTARY
FAILURE_SCORE_COMMENTARY10
FAILURE_SCORE_OVERRIDE_CODE FAILURE_SCORE_OVERRIDE_CODE
LEGAL_STATUS LEGAL_STATUS
LOCAL_ACTIVITY_CODE LOCAL_ACTIVITY_CODE_TYPE provided

by D&B
REGISTRATION_TYPE REGISTRATION_TYPE
SIC_CODE1 to SIC_CODE6 SIC_CODE_TYPE provided by D&B
TOTAL_EMP_EST_IND TOTAL_EMP_EST_IND
TOTAL_EMP_MIN_IND TOTAL_EMP_MIN_IND
TOTAL _EMPLOYEES_IND TOTAL_EMPLOYEES_INDICATOR
Combined Validations and Corrections

• The LOCAL_ACTIVITY_CODE_TYPE attribute is validated against the
LOCAL_ACTIVITY_CODE_TYPE lookup type. If D&B provides an invalid
value, then the LOCAL_ACTIVY_CODE_TYPE and LOCAL_ACTIVITY_CODE
attributes are both corrected to null.
If D&B provides null for the LOCAL_ACTIVITY_CODE_TYPE attribute, and the
LOCAL_ACTIVITY_CODE attribute is not null, then the LOCAL_ACTIVITY_CODE
attribute is corrected to null.
• The SIC_CODE_TYPE attribute is validated against the SIC_CODE_TYPE lookup
type. If D&B provides an invalid value, then the SIC_CODE_TYPE and SIC_CODE1
to SIC_CODE6 attributes are all corrected to null.
If D&B provides a value for any of the SIC_CODE attributes and null for the
SIC_CODE_TYPE attribute, then the SIC_CODE_TYPE attribute is corrected to 1985
SIC. Both SIC_CODE_TYPE and SIC_CODE attributes must have a value or none at
all. If D&B provides null for all SIC_CODE attributes, then the SIC_CODE_TYPE
attribute is corrected to null.

Related Topics
Load D&B Data

Use the Load D&B Data program to load corrected, online-purchased D&B information
from the HZ_PARTY_INTERFACE table into the appropriate TCA tables. See: Correcting
Mapping API Utility Errors, page 3-14. The Mapping API utility ensures that the
information in the D&B data elements populate the appropriate fields and TCA tables.
Prerequisites
Before you can run the Load D&B Data program, the HZ_PARTY_INTERFACE table
must be populated with data from online purchasing.
Program Parameter
Group ID
By default, every record from online purchase is automatically assigned a group
ID. Enter the group ID of the record that you want to reload after it was corrected. If
every record in the interface table has a group ID, the program processes nothing if
you leave the parameter blank.
Related Topics
Batch Loading
Use the batch load process to update D&B information for a large number of parties on a
regular schedule or whenever you need. You can update all parties, gather data only for
new parties, or update parties that have not been updated since a specified date. Batch
retrieval and loading of D&B information is usually a regularly scheduled, automated
process that you set up and run.
When you obtain D&B information about a company that does not exist in the TCA
Registry, a new party is created using the D&B data. See: Details on Creating Parties
with D&B Information, page 3- 8 .
If you are batch loading to update parties that already have D&B data, only the records
with a mapped DUNS Number are updated. See: Source System Management Impact,
page 3- 6 .
Related Topics
Process Overview
The batch loading process you use depends on the database version you are on.

Procedure for Oracle9i and Above
1. Run the Generate Request List for DNB Batch Load program to generate a list of
parties that you want to request D&B data for, page 3-20.
2. Transfer the file containing the request list to D&B, page 3-21.
3. Receive a properly formatted file, ready for loading, from D&B.
4. Create a batch ID using the Create Import Batch API, page 2- 2 .
5. Run the D&B Import Adapter request set to load D&B information into the interface
tables, page 3-21.
Note: If you use a method other than the D&B Import Adapter, then
you must pass a valid D&B value in the CONTENT_SOURCE_TYPE
column to make the information from D&B available for the Single
Source of Truth record. See: Single Source of Truth Overview, Oracle
6. Optionally verify that the D&B information is loaded into the interface tables as
expected.
7. Review the settings for import profile options and modify if needed. See: Bulk
Import Profile Options, Oracle Trading Community Architecture Administration Guide.
8. Run the Import Batch to TCA Registry program to load D&B information from the
interface tables into the appropriate HZ tables, page 2- 8 . For the Import Run
Options parameter, select to run both the preimport and import processes.
9. Correct errors, if any, page 2-15. Most errors occur due to changes in information
codes that D&B provides for the data elements.
Procedure for Oracle8i and Below

1. Run the Generate Request List for DNB Batch Load program to generate a list of
parties that you want to request D&B data for, page 3-20.
2. Transfer the file containing the request list to D&B, page 3-21.
3. Receive a properly formatted file, ready for loading, from D&B.
4. Run the SQL*Loader utility to load the provided D&B file into the
HZ_PARTY_INTERFACE table. The SQL*Loader command is:
Sqlldr userid=<User Name>/<Password>@<Database Name> control=ARHD
NBGX.ctl data=<Data File Name>
The data file name is the name of the flat file from D&B. You must pass a valid D&B
value in the CONTENT_SOURCE_TYPE column to make the information from D&B
available for the Single Source of Truth record.
Each newly loaded record in the interface table has a null GROUP_ID column. If
you want to import only a subset of records from the interface table into the TCA
tables, you can manually populate that column with the same value for all records in
the subset. You can then specify that group ID to transfer the subset of records from
the interface table into TCA tables. See: Load D&B Data, page 3-18.
5. Run the Load D&B Data program to load D&B information from the interface table
into the appropriate TCA tables, page 3-18.

Leave the Group ID parameter blank to process all records without a group
ID in the interface table. By default, the records that you batch load into the
HZ_PARTY_INTERFACE table from the D&B file have no group ID.
If you do assign a group ID to any of the records, you can:
• Leave the parameter blank to process all records except those assigned a
group ID.
• Enter a group ID to process a subset of records with the same ID.
6. Correct errors, if any, page 3-14.
Generate Request List for D&B Batch Load

Use the Generate Request List For DNB Batch Load program to select and generate a
text file of the parties that you require updated D&B information for. The request
list includes the following data elements:
• DUNS Number
• Party name
• Address1
• Address2
• Address3
• Address4
• City
• State
• Country
• Postal code
• Party ID
• Phone number
After the Generate Request List For DNB Batch Load program successfully
completes, you can find the request list in the usual directory for concurrent request
output files.
The Registry ID for each party is included in the output file that D&B returns to you after
you submit your request list and is used to match D&B information to the appropriate
party in the TCA Registry.
Program Parameters
Request list option

Select the type of request list that you want to generate:
• All parties
• Only parties not having D&B data
• Only parties whose D&B data was last updated prior to the date in the last update
date parameter

Important: If you select options 1 or 2, of the parties that already have
D&B data, only the ones with the mapped DUNS Number are included
in the request list.
Last Update Date

Enter the last update date that you want to base the request on. You need to specify this
date only if you are using request list option 3.
Related Topics
Batch Loading, page 3-18
Transferring a Request List File to D&B

You must make specific arrangements with D&B for the transfer of the file that identifies
the parties that you are requesting data for. Through a manual process, you usually
sends the file to D&B on a cartridge or a diskette. The file can also be sent to D&B using
File Transfer Protocol (FTP) or as an e-mail attachment.
Related Topics
D&B Import Adapter

Run the D&B Import Adapter request set to load data, from the ASCII flat file that D&B
provides for batch loading, into the interface tables used for TCA Bulk Import. The flat
file contains D&B information for the parties that you requested.
A flat file is loaded as a batch into the interface tables. At any given time, only one D&B
batch can be actively loading into the interface tables, but the interface tables can store
multiple D&B batches.
Note: The D&B Import Adapter request set supports only standard D&B
bulk files for the Enterprise Management data product.
Prerequisites
1. Manually create a directory object on the same environment as your TCA database. A
directory object is a database object that stores the absolute path of a physical
directory on the database node. Name this object HZ_DNB_SOURCE_DIR, and
make sure the database server can read and write from the location identified
by the directory object.
For example, create the directory object in APPS as follows:
CREATE or replace DIRECTORY HZ_DNB_SOURCE_DIR AS ’/emslog/dnb’
If the object is not in APPS, you must also grant access to APPS:
GRANT READ ON DIRECTORY HZ_DNB_SOURCE_DIR TO apps;
GRANT WRITE ON DIRECTORY HZ_DNB_SOURCE_DIR TO apps;
Note: You only need to create this directory object once, to be used
for all D&B Import Adapter requests.
2. Copy or FTP the flat file from D&B to the location that the directory object identifies.

3. Sort the flat file based on DUNS Number to make sure that all DUNS Numbers in
the flat file are unique. For example, in UNIX:
sort -u -t, +0 -1 <file with duplicate DUNS Number> -o <output fi
le name>
Program Parameters
The D&B Import Adapter request set includes two programs that you must specify
parameters for.
D&B Flat File Upload Table Creation

• Object Containing File Location: Enter the name of the database object you
created. You can override the HZ_DNB_SOURCE_DIR default if you used another
name.
• Data File Name: Enter the name of the flat file that D&B provided.
• Log File Name: Enter the case-sensitive name of the log file that is to be created
for the upload.
• Bad File Name: Enter the case-sensitive name of the file that is to be created for the
upload to store all bad records.
• Discard File Name: Enter the case-sensitive name of the file that is to be created for
the upload to store all discarded records.
D&B File Load - Pass 1

• Batch Identifier: Enter the batch ID that the Create Import Batch API generated. See
Batch IDs, page 2- 2 .
• Explicit NULL character value (G_MISS_CHAR): Enter the character value in
the interface tables that, when imported into the TCA tables, would make the
corresponding TCA character column null. If an interface table column is null, the
corresponding TCA column, empty or not, is not affected by the import.
Related Topics
Loading Data into the Interface Tables, page 2- 2
Loading Rationalized Legacy Data

When you migrate from a legacy system to Oracle Applications, you might need to
transfer legacy data into the TCA tables. If you want to cleanse your legacy data before
loading the data into the TCA tables, you can use D&B rationalization services. You
can then use the Import Batch to TCA Registry program to create new parties in the
TCA tables for the rationalized legacy data and use the Customer Interface program to
create customer accounts for those parties.
Important: Do not upload cleansed data from other third-party content
providers when using this functionality.

To load rationalized legacy data:
1. Compile a list of the parties in your legacy system that you want D&B to
rationalize. Each party in the list must include a unique identifier. This unique
identifier maps to the Original System Reference field in the TCA tables.
2. Transfer your list to D&B. For more information, see: Transferring a Request List
File to D&B, page 3-21.
3. D&B compares the companies in your list with the companies in the D&B database
and rationalizes the data on your list. After rationalizing your data, D&B sends three
flat ASCII files back to you:
• First file: Matched, unmatched, and duplicate records as well as information
appended from D&B’s database for each company
• Second file: All the duplicate records, listed in order of DUNS number
• Third file: Records that D&B could not find a DUNS number for
4. Run the D&B Import Adapter request set to load D&B information from the first flat
file into the interface tables, page 3-21.
5. Run the Import Batch to TCA Registry program to load D&B information from the
interface tables into the appropriate TCA tables, page 2- 8 . The program creates
parties in the TCA tables and maps the unique identifier that you identified in step 1
to the Original System Reference field.
6. Run the Customer Interface program to associate legacy customer accounts with
your newly created parties. The Customer Interface program matches customer
accounts to parties using the Original System Reference field. See: Customer
Interface, Oracle Receivables User Guide.
Related Topics
Viewing Information from Data Sources

Third Party Data Integration lets you view information from all relevant data sources
for any given party. Before you acquire any third party data about a party, you can
only view the user-entered party information. After you purchase and retrieve D&B
information for a party, for example, you can also view the D&B information.
User-entered information is entered or loaded by users of Oracle Applications. The
displayed D&B information depends on which data product you purchase for that
party, either ordered online or batch loaded. See: Selecting Data Products or BIRs,
page 3-11.
Procedure
1. Search for the party that you want to view. See: Searching for Existing Parties in
the TCA Registry, page 3-10.
2. For details about the information you can view for the party, see: Subtabs of
Information, page 3-24.
3. Optionally choose to purchase new or updated D&B information for that
party. See: Searching for Companies in the D&B Database, page 3-10.

Related Topics
Subtabs of Information
Summary, Business Verification, and Special Event

The Summary and Special Event subtabs display the user-entered and D&B information
for the party. The Business Verification subtab can show the Single Source of Truth
(SST) information, depending on the SST administration. See: Single Source of Truth
Overview, Oracle Trading Community Architecture Administration Guide.
If the SST record is set up, you see the D&B information in the D&B column and the
SST information in the Single Source of Truth column. If SST is not set up, you see the
user-entered information in the Customer Record column.
The subtabs provide the following:
• Summary: The Summary subtab provides general information about the party such
as DUNS Number, address, and the last update date.
• Business Verification: The Business Verification subtab provides:
• Demographic information such as CEO name, fiscal year-end month, potential
revenue, and functional currency.
• Business keys such as legal status, business structure, SIC code, and local
business identification.
• Employee statistics such as the total number of employees and the number of
employees at the location that you purchased D&B data for.
• Special Event: The Special Event subtab provides information about
legal, financial, and operational events or activities, including disasters, that might
affect a company’s creditworthiness.
Relationships, BIR, Credit / Risk, and Financial Analysis

These subtabs only display information provided by D&B. The data product purchased
for the party determines which data elements in these subtabs contain values.
• Relationships: The Relationships subtab displays business and legal structure
information, including branch to headquarters and parent to subsidiary
relationships, for up to five related entities or organizations: Primary
Organization, Headquarters, Parent, Domestic Ultimate, and Global Ultimate. For
each relationship, the displayed information can consist of the related party’s
name, DUNS Number, address, and telephone number.
• BIR: The BIR (Business Information Report) subtab displays an image of the BIR for
the party, providing detailed business and financial information.
• Credit / Risk: The Credit / Risk subtab displays payment and risk information. Some
of the data elements included are Paydex data, D&B Rating, delinquency scores, and
failure scores.
Note: For a key to the D&B Ratings, contact your local D&B
representative or D&B’s Global Service Center at (888)243-4566, or
visit Customer Service at http://www.dnb.com.

• Financial Analysis: The Financial Analysis subtab displays available income
statement and balance sheet data as well as financial ratios. This subtab also indicates
whether the financial statements are consolidated, audited, restated, and so on.
Related Topics
Viewing Information from Data Sources, page 3-23
Duplicate DUNS Report

Use the Duplicate DUNS report to identify parties with the same DUNS Number in the
TCA Registry. You can run the report to find duplicates for a particular DUNS number
or duplicates for any DUNS Number.
For each party with the same DUNS Number, the report displays:
• Party name
• Party number
• Address
• City
• State
• Country
Report Parameters
Duplicate DUNS Number

Enter the DUNS Number that you want to identify duplicates for.
If you enter a DUNS Number, the report only displays a result if two or more parties use
that same DUNS Number. If you leave the parameter blank, the report displays any
duplicated DUNS Numbers and the parties associated with those DUNS Numbers.
Related Topics
DNB Global Data Products Request Report

Use the DNB Global Data Products Request report to find out when D&B products
were requested, who requested each product, and which GDP was purchased. The
report provides information that you can use to control the purchase of and access to
D&B information.
The report contains the following details about each request:
• Party name
• Party number
• Requested product

Note: If Batch Load appears in this column, the last update to this
party’s D&B information was completed using the batch load
process.
• Purchaser
• Purchased date
Report Parameters
Start Date
Enter the date that you want to report from.
End Date
Enter the date that you want to report to.
Related Topics

4
Locations and Phones
This chapter describes using features for locations and phones, including address
validation, eLocations Spatial Data Integration, and time zone generation for locations
and phones.
• Locations Overview
• Address Validation
• eLocations Spatial Data Integration
• Generate Time Zone for Locations
• Generate Time Zone for Phone Numbers
Locations Overview
In the TCA Registry, a location is a point in geographical space, usually defined by an
address. You can:
• Validate existing addresses in the TCA Registry, page 4- 1 .
• Use eLocations Spatial Data Integration to acquire longitude and latitude
information for locations in the Registry, page 4- 4 .
• Generate time zones for locations in the Registry, page 4- 5 .
Related Topics
Address Validation
Address validation is the process of comparing raw or user-entered addresses against
a known or authorized data source, to determine if the addresses are recognized and
correct according to the authority’s database.
Run the Address Validation program to validate addresses in the TCA Registry. The
program sends data to the address validation black box, which must be integrated with
at least one adapter for address validation. For example, if the adapter is integrated with
a third party product called Gorman, the adapter would validate the TCA addresses
against the Gorman address database. See: Administering Adapters, Oracle Trading
Locations and Phones 4-1

Each address is validated through the default adapter set up for each country. For
example, if the Gorman adapter is the default for Peru, all Peruvian addresses in the
Registry are validated against Gorman’s standard addresses.
If an address from the TCA Registry differs from the validated address, the TCA address
is updated with the validated address only if the TCA address is valid above a specified
threshold. Such an update is called an address correction. For example, if you set the
Override Threshold parameter at the Municipality Match level, then an address is
corrected if at least its city or town is valid.
Note: Aside from the validation threshold, address correction only
occurs if the update does not violate other validations, such as tax
validation rules.
Your administrator can set up address validation, including determining the timeout
limit for communication with third party service providers and custom solutions. The
default is 300 seconds. See: Setting Up Address Validation, Oracle Trading Community
Program Parameters
The Address Validation program has three pairs of parameters, each including a filter
operator and the corresponding value, to determine which addresses in the TCA
Registry to include in the address validation.
For each parameter pair, you must use both or neither. To include addresses that were
never validated, do not use the validation status and date validated parameters.
Validation Status Filter

Specify the operator for filtering addresses to validate, based on the last validation
status. For example, you enter <= and select 3 as the validation status code. The
program would include only addresses that have validation status 3, 2, 1, or 0 from the
last address validation.
Validation Status Code

Enter the validation status to use with the validation status filter for including only
addresses based on their last validation status. The program considers addresses last
validated by any adapter, unless you specify one in the Adapter parameter.
Date Validated Filter

Specify the operator for filtering addresses to validate, based on the last validation
date. For example, you enter > and 01-JAN-2004 as the validation date. The program
would include only addresses that were last validated on January 2, 2004 or later.
Date Validated
Enter the validation date to use with the date validated filter for including only addresses
based on their last validation date. The program considers addresses last validated by
any adapter, unless you specify one in the Adapter parameter.

Last Update Date Filter
Specify the operator for filtering addresses to validate, based on the last update date. For
example, you enter < and 01-JAN-2004 as the validation date. The program would
include only addresses that were last updated on December 31, 2003 or earlier.
Last Update Date

Enter the update date to use with the last update date filter for including only addresses
based on their last update date. Updates include user-entered changes, address
corrections, or enrichment from a third party data source such as D&B.
Country
Leave this parameter blank to validate addresses in all countries, or enter the country
you want to validate.
Adapter
Enter the adapter that you want to use to validate addresses against. Use this
parameter, for example, to validate against a specific source after the source’s libraries
are updated with new data.
If you use the validation status or date validated parameters, the program further limits
the addresses to only those last validated by the specified adapter.
Override Threshold
Enter the code for the validation threshold that an address must reach or exceed to
be corrected with the valid address. For example, if you select 2, addresses must be
validated at least to the street or thoroughfare level to be updated. Addresses with
validation status 0, 1, or 2 would be updated.
This table describes the available status codes.
Status Meaning Description
0 Valid Address The highest level of validation. The address has

been certified deliverable based on postal authority
certifications.
1 Multiple or Ambiguous Address has been validated to the street level, but there
Address is ambiguity to locate the specific address.
2 Street or Thoroughfare Match Address has been validated to the street level, but no
further.
3 Municipality Match Address has been validated to the city or town

level, but no further.
4 Administrative Subdivision Address has been validated to be within the country’s

Match main administrative subdivision, such as province or
state, but no further.
5 Country Match Address has only been validated to the country

level, but no further.
6 No Match Address could not be validated in any way.

Related Topics
Locations Overview, page 4- 1
eLocations Spatial Data Integration

Oracle Trading Community Architecture (TCA) eLocations Spatial Data Integration lets
you retrieve spatial information from Oracle eLocations. Oracle eLocations provides
mapping, geocoding, and driving directions for the US and supports a range of
applications, from mapping, asset management, and transportation applications to
wireless location services and location-enabled e-business.
The spatial data that eLocations provides through the TCA integration contains the
latitude and longitude for any location within the US. You can acquire and store this
information for your addresses in the TCA Registry.
You run the Spatial Information for Locations Batch Update program in eLocations
Spatial Data Integration to retrieve spatial data from eLocations into the TCA
Registry. See: Spatial Information for Locations Batch Update, page 4- 4 .
The program starts a PL/SQL script to generate a spatial data request that is sent
to eLocations via an HTTP query post. An API parses the response from eLocations
and, if the results are successful, updates the HZ_LOCATIONS table with the latitude
and longitude for the requested locations.
Your administrator can set up eLocations Spatial Data Integration. See: Setting Up
eLocations Spatial Data Integration, Oracle Trading Community Architecture Administration
Guide.
Related Topics
Spatial Information for Locations Batch Update

Use the Spatial Information for Locations Batch Update program to acquire latitude
and longitude values for locations in the TCA Registry. For addresses that already
have spatial data, the program updates the records with the latest information from
eLocations.
In the request to eLocations, you can limit the addresses that you want spatial data for by
site use, country, and other criteria. You can update all records that satisfy the criteria or
specify a number of records, for example, the first 100 records that match the criteria. The
location ID orders the addresses, so the first records are usually the older ones.
Program Parameters
Site Use
Enter the site use for the locations that you want spatial data for.
Country
Enter the country for the locations that you want spatial data for.

Identifying Addresses Only
Enter Yes or No to indicate whether you want spatial data for only identifying addresses
or all addresses.
Only Unretrieved Locations

Enter Yes if you want spatial data only for locations without any spatial data or with
manual updates since the last run of this program. Enter No to update all locations.
Update Records For

Enter ALL if you want spatial information for all records that correspond to the previous
parameters or SUBSET for only a subset of records.
Records in Subset
Enter the number of records that you want spatial data for if you selected SUBSET
in the Update Records For parameter.
Related Topics
eLocations Spatial Data Integration, page 4- 4
Generate Time Zone for Locations

Use the Generate Time Zone for Locations program to create or update time zone
information for all existing locations in the TCA Registry. The time zone information is
based on the country, or for the United States only, the state.
Program Parameter
Overwrite Existing Time Zone

Specify whether the program should overwrite existing time zones.
Related Topics
Generate Time Zone for Phone Numbers

Use the Generate Time Zone for Phone Numbers program to create or update time
zone information for all existing phone numbers in the TCA Registry. The time zone
information is based on the phone setup by your administrator. See: Defining Time
Zones for Phones, Oracle Trading Community Architecture Administration Guide.
For example, the US phone setup is based on area codes, since the country has multiple
time zones. For the 650 or 858 area code, the program would assign the US west
coast time zone.
Program Parameter
Overwrite Existing Time Zone

Specify whether the program should overwrite existing time zones.

Related Topics

5
Relationship Manager
This chapter describes using Relationship Manager to view, create, and edit relationships
among existing parties in the TCA Registry.
• Relationship Manager Overview
• Party Relationship Management Process
• Searching for Parties and Viewing Results
• Viewing Relationships
• Creating Relationships
• Editing Relationships
• Viewing Relationship Hierarchies
Relationship Manager Overview

Use Oracle Trading Community Architecture (TCA) Relationship Manager to create and
manage relationships among existing parties in the TCA Registry.
Note: You view and manage only parties of type Organization and
Person in Relationship Manager.
Using relationships to model the interactions among parties in the TCA Registry
helps you make better business decisions. For example, you can analyze and manage
relationships with competitors and partners, or corporate relationships between
subsidiaries and parent corporations.
In Relationship Manager, you get a comprehensive view of the roles that a single party
plays with respect to other parties in the Registry, as well as a hierarchical view for
hierarchical relationships. Aside from viewing relationships, you can create, edit, and
end relationships.
Your administrator can set up Relationship Manager. See: Setting Up Relationship
Manager, Oracle Trading Community Architecture Administration Guide.
Related Topics
Relationships Overview, page 5- 2
Major Features, page 5- 3
Relationship Manager 5-1

Party Relationship Management Process, page 5- 4
Relationships Overview
The TCA relationship model lets you record complex, real-life relationships among
entities in the TCA Registry. You can analyze not only direct relationships such as those
with your competitors, but also indirect ones such as your customers’ customers. You
can also manage hierarchical relationships to better understand, for example, the
management hierarchy within an organization.
A relationship represents the way two entities interact with each other, based on the
role that each entity takes with respect to the other. For example, the employment
relationship between a person and an organization is defined by the role of the person
as the employee and the organization as the employer.
In addition, every relationship is reciprocal. Each entity is either the subject or
object, depending on the perspective, or direction. For example, if Joe is the employee
of Oracle, then Joe is the subject and Oracle is the object. Oracle as the employer of
Joe, which flips the subject and object, still describes the same relationship.
Relationship Phrase and Role Pairs

A relationship phrase and role pair contains a correlating phrase pair and role pair, which
describes the reciprocal roles that the two entities play in the relationship. For example, a
relationship phrase and role pair contains the Employee Of and Employer Of phrase pair
as well as the Employee and Employer role pair.
Every relationship is based on a relationship phrase and role pair. Even though only
phrase pairs are used in Relationship Manager, the corresponding role pair is still
stored in the system for each relationship.
A phrase pair, such as Employee Of and Employer Of, describe the role of either entity
in the relationship as the subject. For example, Joe as the subject of the relationship
would have Employee Of as the phrase, and Oracle as the subject would have Employer
Of. The other entity in the relationship would be the object.
A relationship role pair, such as Employee and Employer, describes the two entities no
matter the direction of the relationship. For example, Joe has the Employee role and
Oracle the Employer role, both as either the subject or object.
Each relationship phrase and role pair also determines the type of entities for the
relationship. For example, the Employer Of phrase and Employer role can be defined so
that the employer must be a party of type Organization and the employee a party of
type Person.
When you create a relationship with a relationship phrase or role, the reverse direction of
the relationship is automatically created with the other phrase or role in the pair. For
example, if you define Joe as the employee of Oracle, Oracle as the employer of Joe is
also created.
Relationship Type
Each relationship phrase and role pair belongs to a relationship type, which categorizes
the types of relationships that you can create. For example, the relationship phrase and
role pair described above would belong to an employment relationship type.

Relationship types determine if the relationships created with the type are
hierarchical, and if not, whether they can be circular or not. For more
information, see: Relationship Characteristics, page 5- 3 .
Every relationship type must contain at least one phrase and role pair. TCA provides
seeded relationship types and phrase and role pairs, but your administrator can create
new ones as needed. See: Administering Relationships, Oracle Trading Community
Architecture Administration Guide and Seeded Relationship Types, Phrases, and
Roles, Oracle Trading Community Architecture Reference Guide.
Relationship Date Range

Both directions of a relationship share a start and end date. The start date signifies when
the relationship starts, not necessarily when it was created. Likewise, the end date
is when the relationship ends.
The relationship date range helps you analyze the history of an entity’s relationships. For
example, you can see that Joe used to work for Oracle in a subsidiary location for the
past two years but has been working at Oracle headquarters since last month.
Relationship Group
In general, relationship groups are used to determine which relationship roles and
phrases are displayed in specific application user interfaces. Groups can also be used to
categorize roles and phrases for other functional uses.
Note: Relationship groups do not apply to Relationship Manager. All
seeded and user-created relationship phrases are available.
Relationship Characteristics
Relationships have additional characteristics that relationship types determine.
Hierarchical Relationships
A hierarchical relationship ranks one entity above the other. For example, in an
employment relationship, the employer is ranked above the employee. In the
employment hierarchy, the employee would be a child that appears below its parent, the
employer. Hierarchical relationships are created with phrase and role pairs that belong
to a hierarchical relationship type.
Circular Relationships
If a relationship type allows for circular relationships, you can create a relationship from
Party A to Party B to Party C and back to Party A. For example, Party A is a competitor
of Party B, which is a competitor of Party C, which is a competitor of Party A.
Hierarchical relationships cannot be circular. For example, if Alan’s manager is
Jenny, and Jenny’s manager is Chris, then Chris’s manager cannot be Alan.
Nonhierarchical relationship types can either allow or prevent circular relationships. For
example, marital relationships cannot be circular, while competitive relationships
described above can.
Major Features
Relationship Manager provides these features for relationships between existing parties
in the TCA Registry:

• Search for the party that you want to manage relationships for.
• View the party’s basic party information and any available additional details.
• View the relationship types that the party is involved in.
• View the relationships that the party belongs to for specific types.
• View the hierarchy of a hierarchical relationship type.
• Create relationships, available when you view the relationship types, relationships, or
hierarchies of the party.
• Edit existing relationships, including ending the relationship.
Relationship Hierarchy
Relationship Manager displays hierarchical relationships in a hierarchy, a visual
representation of the how parties rank among one another within a given relationship
type. For any party in the hierarchy, all parties displayed one level below are its
children, and the party displayed a level above is its parent.
For any party in the hierarchy, you can:
• Update its relationship by moving the party to another part of the hierarchy.
• Create new relationships.
• View additional party information, if available.
If you batch load data from D&B or acquire the Enterprise Management global data
product (GDP) through online purchase, you can view the provided corporate structure
relationships for a specific business in a relationship hierarchy. See: Introduction to
D&B, page 3- 2 .
Related Topics
Relationship Manager Overview, page 5- 1
Party Relationship Management Process

This diagram describes the general process flow of managing party relationships with
the Relationship Manager.

1. Search for the party that you want to view and manage relationships for and select
the party from the search results. See: Searching for Parties and Viewing Results,
page 5- 6 .
Note: If you want to see a relationship hierarchy, keep in mind that
the party you search for is the root of the hierarchy.
2. View the party’s overview information as well as the relationship types that it is
involved in.
From here, you have three options:
• View relationships of selected relationship types. See: Viewing Relationships,
page 5- 7 .
• Create new relationships with a relationship type that the party is not currently
involved in. See: Creating Relationships, page 5- 7 .
After you create relationships, Relationship Manager takes you back to view the
party’s information and relationship types.
• View the hierarchy of a hierarchical relationship type. See: Viewing Relationship
Hierarchies, page 5- 9 .
3. If you choose to view relationships, you can also:

• Create new relationships with a relationship type that you are
viewing. See: Creating Relationships, page 5- 7 .
• Edit the existing relationships that you are viewing. See: Editing Relationships,
page 5- 9 .
After you edit or create a relationship, Relationship Manager takes you back to
view the relationships.
4. If you choose to view a hierarchy, you can also:
• Update relationships by moving parties within the hierarchy. See: Updating
Relationships by Moving Parties in a Hierarchy, page 5-14.
• Create relationships for any party in the hierarchy, using the relationship type of
the hierarchy. See: Creating Relationships, page 5- 7 .
After you move parties or create relationships, Relationship Manager takes you
back to the hierarchy view.
Related Topics
Relationship Manager Overview, page 5- 1
Searching for Parties and Viewing Results

Use the Party page to search for and select the party that you want to view and manage
relationships for. This search includes parties of type Organization or Person.
If you want to see a relationship hierarchy, keep in mind that the party you search for is
the root of the hierarchy. For example, if you view the corporate hierarchy for Party
B, you can see Party C as the subsidiary of Party B but cannot see that Party B is a
subsidiary of Party A. For more information, see: Viewing Relationship Hierarchies,
page 5- 9 .
From the search results, you select the party that you want and bring up the Overview
page. View the party’s overview and relationship type information, including:
• The relationship types that the party is involved in.
• The number of relationships for each type.
• Whether the relationship type is hierarchical or not.
• Whether the type allows circular relationships or not.
If available, you can access more information about the party from the Additional
Details field.
From the Overview page, you can choose to:
• View relationships, page 5- 7 .
• Create new relationships with a relationship type that the party is not currently
involved in, page 5- 7 .
• View relationships hierarchies, page 5- 9 .
Note: You can also access the Overview page from other pages in
Relationship Manager by clicking the party name.

Related Topics
Viewing Relationships
Use the View Relationships page to view the relationships of the selected party. You can
view relationships for some or all of the relationship types that the party is involved in.
The selected party is the subject party of all displayed relationships. You also see the
object party name and Registry ID, the date range of the relationship, and the source
of the relationship, for example user entered or third party. Even relationships with
passed end dates are included.
To view relationships for a party:

1. Navigate to the Overview page for the party that you want to view relationships
for. See: Searching for Parties and Viewing Results, page 5- 6 .
2. Select at least one relationship type and click the View Relationships button.
3. The View Relationships page displays relationships for the party within your
selected relationship types.
4. You can choose to:
• Create relationships with one of the relationship types that you are viewing,
page 5- 7 .
• Edit any of the displayed relationships, page 5- 9 .
Related Topics
Creating Relationships
Use the Create Relationships page to create new relationships between existing parties in
the TCA Registry. You can choose to create relationships from three pages:
• Overview: Create relationships with a relationship type that is not displayed for the
party, which would be the subject of the new relationship.
• View Relationships: Create relationships with any of the selected types that you are
viewing for the party, which would be the subject of the new relationship.
• Hierarchy: Create relationships with any of the parties in the hierarchy as the
subject, using the relationship type of the hierarchy.
For example, a relationship phrase pair consists of: Organization is Headquarters Of
Organization, and Organization is a Subsidiary Of Organization. If you are working on
the party Oracle HQ, you would create a relationship with your party as the subject
party and use the appropriate relationship phrase: Oracle HQ is the headquarters
of Oracle Branch.

The reverse direction of the relationship, Oracle Branch as the subsidiary of Oracle
HQ, is automatically created. You would see this direction of the relationship when
you view relationships for Oracle Branch.
You can create multiple relationships between the same two parties, with different
relationship phrases, even if relationship date ranges overlap. To use the same
relationship phrase for multiple relationships between the same two parties, however, the
relationship date ranges must not overlap.
To create relationships:
1. Navigate to the Overview page for the party that you want to create relationships
for. See: Searching for Parties and Viewing Results, page 5- 6 .
Select the relationship type that you want to create relationships for and click the Go
button. The available types that you can create relationships for exclude the types
that the party is already involved in.
To create relationships with a type that the party is already involved in, you must
first view the relationships within that type. This restriction ensures that you review
the existing relationships for a type so that you do not create duplicate relationships.
After viewing current relationships, you select the type to create relationships for
and click the Go button. The available types include only the types that you are
viewing. See: Viewing Relationships, page 5- 7 .
Tip: You can also create relationships for any party in a relationship
hierarchy. See: Viewing Relationship Hierarchies, page 5- 9 .
2. The Create Relationships page displays your selected relationship type as the type
for the new relationship, and the selected party is the subject party.
3. Select a relationship phrase and object party for the relationship, with respect to
the subject party.
4. Optionally change the start date of the relationship, which defaults with the current
date.
If you use the current date, the relationship’s start time is the system time. If not, the
start time is at the beginning of the start date.
5. Optionally enter an end date.
The relationship’s end time is at the end of the end date.
6. Click the Add Another Row button to create another relationship for the subject
party with this same relationship type. Repeat steps 4 through 6.
7. Click the Apply button.
The confirmation takes you back to the page from where you chose to create
relationships. Your new relationships are reflected in that page.
Related Topics

Editing Relationships
Use the Edit Relationship page to edit a selected relationship for the party that you are
viewing relationships for. This party is the subject party, which, along with relationship
type and object party, cannot be changed. What you can update in the relationship are:
• Relationship phrase.
When you change the relationship phrase, Relationship Manager actually ends the
existing relationship and creates a new one with the new phrase. The current date is
the end date of the existing relationship.
• Start date.
• End date.
You can manually enter or change an end date to terminate a relationship at the
current or another specified date. You can also extend a relationship by entering a
later end date or removing the end date. Even relationships with an end date that
already passed can be prolonged by changing or removing the end date.
Any changes that you make to the direction of the relationship with your party as the
subject applies to the opposite direction of the relationship. For example, the direction
you are editing is: Oracle is the employer of Joe. If you end this relationship, Joe as the
employee of Oracle also ends.
Tip: You can also edit hierarchical relationships by moving parties
within the hierarchy of a relationship type, which changes the object
party. See: Updating Relationships by Moving Parties in a Hierarchy,
page 5-14.
To edit a relationship:
1. Navigate to the View Relationships page for a party with the relationships that you
might want to edit. See: Viewing Relationships, page 5- 7 .
2. Click the Edit icon for the relationship that you want to edit.
Note: You can edit only relationships with the User Entered source.
3. In the Edit Relationship page, change the relationship phrase, start date, end date, or
any combination of the above.
4. Click the Apply button.
The confirmation takes you back to the View Relationships page, where you can see
the results of your changes.
Related Topics
Viewing Relationship Hierarchies

Use the Hierarchy page to view a structured hierarchy of the relationships in a given
hierarchical relationship type. For example, you get a visual representation of how
a corporate structure is set up.

Your selected party is the root at the top of the hierarchy. You can see its children, or
parties ranked lower in relationships, but not its parents.
The hierarchy represents a structure of relationships for the date that you specify in the
As Of field. The hierarchy displays all relationships that fit both of these criteria:
• The start date is before or the same as the as of date.
• The end date is after the as of date, or no end date exists.
This table shows an example of three relationships and their date ranges.
Relationship Start Date End Date
A January 1 January 10
B January 10 January 30
C January 15 None
This table shows examples of which relationships the hierarchy would display
depending on the date in the As Of field.
As Of Included Relationships
January 1 A
January 10 B
January 15 B and C
January 30 C
For each node in the hierarchy, Relationship Manager displays the party’s:
• Name and Registry ID
• Relationship phrase with respect to its parent party
• Parent party name
If you have batch loaded data or acquired the Enterprise Management GDP through
online purchase, you can also view the corporate hierarchy that D&B provides. See: D&B
Hierarchy, page 5-11.
To view a relationship hierarchy:

1. Navigate to the Overview page for the party that you want to view relationship
hierarchies for. See: Searching for Parties and Viewing Results, page 5- 6 .
Note: Search for and select the party that you want as the highest
level, or root, in the hierarchy.
2. Click the Hierarchy icon for the relationship type that you want to view. Hierarchies
are available only for hierarchical relationship types.

3. Enter the date that you want to view the hierarchy for in the As Of field and click the
Go button. By default, the hierarchy is displayed for the current date.
4. To view the relationships within the hierarchy, click the arrows to expand or
collapse levels.
Tip: You can click the Focus icon for the party that you want to view
as the root of the hierarchy. Clicking the name of any party in the
hierarchy displays the party’s overview information and does not
render that party as the root of the hierarchy.
5. Click the Details icon for the party that you want to view additional information
for, if available.
6. Repeat steps 3 to 5 as needed.
7. From the Hierarchy page, you can choose to:
• Select parties and move them under another party within the same hierarchy,
page 5-14.
Note: You cannot update the D&B hierarchy by moving parties
within the hierarchy.
• Create relationships for any party in the hierarchy., page 5- 7
Related Topics
D&B Hierarchy
The D&B hierarchy contains hierarchical corporate relationships that D&B provides
through the Enterprise Management global data product (GDP). To access this
hierarchy, you select the D&B Hierarchy relationship type, which includes the following
relationship phrase pairs:
• Parent Of and Subsidiary Of
• Headquarters Of and Division Of
• Domestic Ultimate Of and Domestic Subsidiary Of
• Global Ultimate Of and Global Subsidiary Of
The Domestic Ultimate is the highest ranking entity within a country, while the Global
Ultimate is the uppermost entity within the global corporate hierarchy. D&B creates
a reporting structure from the lowest level of a corporate hierarchy to the Global
Ultimate, providing a complete hierarchical organization structure.
When you purchase the Enterprise Management GDP for any entity, D&B provides
a hierarchy containing all the related parents up to the Global Ultimate, but not
other entities on the same or lower levels. For example, if you purchase data for
a headquarters, then the provided hierarchy includes its Domestic and Global
Ultimate, but not its branches or other headquarters reporting to the same Domestic or

Global Ultimate. When you subsequently purchase the GDP for entities on the same or
lower levels, then the hierarchical links to the original entity are established.
The structure of the D&B hierarchy depends on many additional factors, including the
countries that the entities are in, the entity that you purchase the D&B data for, and so
on. For more clarification and illustrations of other rules and regulations, see: D&B
Hierarchy Examples, page 5-12.
Related Topics
Viewing Relationship Hierarchies, page 5- 9
Data Products, page 3- 3
D&B Hierarchy Examples

These examples illustrate how the information that you acquire from D&B appear in
Relationship Manager as the D&B hierarchy.
Example 1
In this example, you purchase D&B data for a branch, which has its headquarters
within the same country. This table shows the information that you acquire from
D&B, including the corporate structure with respect to the branch.
Name Role Country
Vision Global Global Ultimate Japan
Vision US Domestic Ultimate US
Vision HQ Headquarters US
Vision Branch Branch US
With the information that you acquire from D&B for the branch, Relationship Manager
displays the D&B hierarchy as shown in this table:
Hierarchy Level Name Relationship Phrase Parent Name
1 Vision Global <None> <None>
2 Vision US Global Subsidiary Of Vision Global
3 Vision HQ Domestic Subsidiary Vision US

Of
4 Vision Branch Division Of Vision HQ
The Global Ultimate is always at the top of a D&B hierarchy, no matter which country it
is in. The Domestic Ultimate is displayed above the headquarters because they are in the
same country, and the Domestic Ultimate is the highest ranking within a country. The
Domestic Ultimate is always in the same country as the entity that you purchase D&B
data for, by definition.

Example 2
In this example, you purchase D&B data for a branch, which has its headquarters in
another country. This table shows the information that you acquire from D&B, including
the corporate structure with respect to the branch.
Name Role Country
XYZ Global Global Ultimate US
XYZ US Domestic Ultimate US
XYZ HQ Headquarters Japan
XYZ Branch Branch US
With the information that you acquire from D&B for the branch, Relationship Manager
displays the D&B hierarchy as follows in this table:
1 XYZ Global <None> <None>
2 XYZ US Global Subsidiary Of XYZ Global
2 XYZ HQ Global Subsidiary Of XYZ Global
3 XYZ Branch Division Of XYZ HQ
The Domestic Ultimate and headquarters are displayed on the same level in the
hierarchy because they do not necessarily have any relationship to each other. In the
previous example, they are in the same country, so the Domestic Ultimate ranks higher
by default. In this example, they are in different countries.
The branch appears only as a child of the headquarters, not also of the Domestic
Ultimate, because the reporting structure is based on the headquarters/division and
parent/subsidiary relationships only. The Global and Domestic Ultimates do appear in
the hierarchy with respect to the entity that you purchased D&B data for.
Example 3
In this example, you purchase D&B data for Vision HQ from Example 1, which also has
its headquarters in the same country. This table shows the information that you acquire
from D&B, including the corporate structure with respect to Vision HQ as the branch.
Name Role Country
Vision Global Global Ultimate Japan
Vision US Domestic Ultimate US
Vision Parent Parent US
Vision HQ Subsidiary US

With the information that you acquire from D&B first for Example 1 and then
3, Relationship Manager displays the D&B hierarchy as follows in this table:
1 Vision Global <None> <None>
2 Vision US Global Subsidiary Of Vision Global
3 Vision Parent Domestic Subsidiary Vision US

Of
4 Vision HQ Subsidiary Of Vision Parent
5 Vision Branch Division Of Vision HQ
As you subsequently purchase more D&B data for other entities within the Vision
corporate hierarchy, you accordingly fill out its D&B hierarchy and establish more
concrete reporting relationships with the hierarchy.
Updating Relationships by Moving Parties in a Hierarchy

Use the Hierarchy and Move Parties pages to move selected parties within a
hierarchy, accordingly updating affected relationships. You can select one or more
parties that you want to move under a new parent in the same hierarchy. The parties that
you move and the new parent can be on any level of the hierarchy.
Each move ends the existing relationship and creates a new one based on the new
structure in the hierarchy. The current date is the end date of the existing relationship as
well as the start date of the new relationship.
Note: If you need to change start or end dates after moves, use the Edit
Relationships page. See: Editing Relationships, page 5- 9 .
For example, the current hierarchy has Party A as the parent of Party B, which is the
parent of Party C, which is the parent of Party D. You move Party C and select Party A as
its new parent. This move ends the relationship for Party B as the parent of Party C and
creates a new relationship for Party A as the parent of Party C. Party D moves along with
Party C and remains a child of Party C.
This diagram shows the hierarchy before and after the move:

The relationship phrase of the moved relationship stays the same with respect to parties
that you move. For example, if Party C was a subsidiary of Party B, it would then be the
subsidiary of Party A, and Party D is still a subsidiary of Party C.
To update relationships by moving parties in a hierarchy:

1. Navigate to the Hierarchy page for the hierarchy that you want to view and
manage. See: Viewing Relationship Hierarchies, page 5- 9 .
Important: To ensure accurate results when you move parties, use
the current date as the as of date. All moves are based on the
hierarchy as it is today.
2. Select the party or parties that you want to move and click the Move button.
Note: You cannot move parties with the relationship start date in
the future.
3. In the Move Parties page, expand the hierarchy as necessary to find the new parent
party.
4. Select the new parent party and click the Apply button.
The confirmation takes you back to view the results of your move in the updated
relationship hierarchy.
Related Topics
Viewing Relationship Hierarchies, page 5- 9

6
Batch Duplicate Identification
This chapter describes using batch duplicate identification to create batches of duplicate
parties to merge.
• Batch Duplicate Identification Overview
• Defining Duplicate Identification Batches
• Reviewing Duplicates and Creating Merge Batches
• Submitting Merge Batches
Batch Duplicate Identification Overview

Although Oracle E-Business Suite applications share the same TCA Registry, each
application uses TCA differently depending on the context and need for particular
party information. Each application must quickly, accurately, and consistently retrieve
information from the TCA Registry for transaction processing. Duplicate data in the
Registry can reduce the efficiency and accuracy of party processing and reports.
To resolve duplicates, you can use batch duplicate identification to find duplicate
parties that already exist in your TCA Registry and select the parties that you want
to merge. The batch duplicate identification process compares all records for each
party. For example, each contact point for a party is compared against all contact points.
Batch duplicate identification is powered by Data Quality Management (DQM)
functionality. Your administrator can set up batch duplicate identification. See: Setting
Up Batch Duplicate Identification, Oracle Trading Community Architecture Administration
Guide and Data Quality Management Overview, Oracle Trading Community Architecture
Process Overview
The batch duplicate identification process involves:
• Defining and submitting a duplicate identification batch, page 6- 2 .
• Review duplicate candidates and create merge batches from the duplicate
identification batch, page 6- 4 .
• Submit merge batches to Party Merge, page 6- 7 .
This diagram illustrates the process in more detail:
Batch Duplicate Identification 6-1

1. In the Submit Duplicate Identification Batch window, define a duplicate
identification batch, which can consist of a subset of parties. Specify whether to
compare the parties against one another or against all parties.
2. From the same window, run the DQM Duplicate Identification program, which
searches for duplicates of the batch that you defined. The batch provides the input
records that the staged schema matches against.
3. The DQM Duplicate Identification program applies the match rule in the Submit
Duplicate Identification Batch window to identify duplicates.
4. The Duplicate Identification: Batch Review window displays the duplicate
candidates for your batch.
5. Review the results for your duplicate identification batch and use the Match Details
window to see more information about the matches.
6. In the Duplicate Identification: Batch Review window, specify the duplicate parties
that you want to merge from and to and indicate which parties you do not want to
be identified as duplicates in the future.
7. In the same window, create a merge batch with the parties that you want to merge.
Use the Review Party Merge Batches window to submit merge batches to Party
Merge for the actual merge process. See: Party Merge Overview, page 7- 1 .
Related Topics
Defining Duplicate Identification Batches

Use the Submit Duplicate Identification Batch window to define and submit the batch
of subset entries that you want to find duplicates for. When you submit the batch, the
DQM Duplicate Identification program automatically applies the match rule from this
window and scores potential duplicates.

If you do not define a subset, the DQM Duplicate Identification program compares
all records in the staged schema against one another. This process can take a long
time, depending on the detail of your match rule and the size of your staged schema.
Define a subset of records to compare against the rest of the staged schema or against
one another, for two reasons:
• To save time
• If you are familiar with the contents of the TCA Registry, for example, if you know
about a new influx of data in a specific date range or records that were created by
a particular application or individual
You can select up to ten conditions to define the subset, using any of the attributes from
the HZ_PARTIES table. You can also manually enter SQL statements to define the subset.
After the DQM Duplicate Identification program finishes, the results are displayed in the
Duplicate Identification: Batch Review window.
To define and submit a duplicate identification batch:

1. Navigate to the Submit Duplicate Identification Batch window.
2. Enter a name for the duplicate identification batch in the Batch Name field.
3. Select a match rule from the list of values to use for identifying and scoring
duplicates in the Match Rule field. The match rule defaults from the DQM Match
Rule for Batch Duplicate Identification profile option, if defined.
Even if the selected match rule is allowed for Automerge, the Automerge feature
is not integrated with batch duplicate identification.
Note: Use a match rule with the Bulk Duplicate Identification
type if you want to identify only records that are almost exact
duplicates. Match rules with Simple Duplicate Identification type
provide fuzzier matches.
4. In the Number of Workers field, enter the number of parallel workers that you
want to use to improve performance.
Workers are processes that run at the same time to complete a task that would
otherwise take longer with a single process. The default number of workers is 1, and
you cannot use more than ten workers.
5. Uncheck the Match within Subset check box if you want to compare the subset
against the entire staged schema for duplicates.
By default, the records in the subset are only compared against one another.
6. Check the Find Merged Parties check box if you want to include parties that were
previously merged in the search.
7. Navigate to the Define Subset region.
8. In the Attribute fields, select attributes from the list of values that you want to
define the subset with.
9. For each attribute, select a condition:
• >
• <

• =
• CONTAINS
Note: The CONTAINS condition applies only to a word
surrounded by white space.
10. In the Value fields, enter a value for each attribute and condition.
For example, if you enter 1001 for the Party Number attribute with a less than
condition, the subset includes only parties with a number of 1000 or lower.
11. In the SQL Clause text box, you can manually add to the corresponding
SQL clauses that are automatically generated when you define subset
conditions. Alternatively, you can enter SQL statements instead of selecting
attributes and conditions in the previous fields.
12. Press the Submit Batch button.
The DQM Duplicate Identification program runs to identify duplicates for the subset
of records that you defined, using the match rule that you specified.
Related Topics
Batch Duplicate Identification Overview, page 6- 1
Reviewing Duplicates and Creating Merge Batches

Use the Duplicate Identification: Batch Review window to review the potential
duplicates that the DQM Duplicate Identification program found and create a merge
batch that consists of parties that you want to merge. For the subset that you defined for
the duplicate identification batch, the Duplicate Identification: Batch Review window
displays parties with matches as merge-to parties and their potential duplicates as
merge-from parties. A merge-from party would be merged into the merge-to party
during the party merge process.
You can use the Match Details window to see the reasons why the DQM Duplicate
Identification program selected any pair of merge-to and merge-from parties as
duplicate candidates. This information helps you determine whether the parties are in
fact duplicates or not.
After you evaluate a pair of duplicate candidates, you can:
• Switch the merge-from party to the merge-to party and the merge-to party to the
merge-from party.
• Mark the pair as not duplicates so that the parties are not selected as candidates in
the future. You can define a date range for this definition to be active.
• Determine whether to merge the pair or not. Any merge-from party with a score that
exceeds the automatic merge threshold defined in the match rule is defaulted to be
merged into the merge-to party. You can override this default.
When you finish evaluating a batch, you can create a merge batch with all the duplicate
pairs of parties that you select for merge.
Note: After you become familiar with DQM, you might choose to
trust your match rules and submit a merge batch with the results of

the DQM Duplicate Identification program without evaluating each
duplicate candidate.
Prerequisites
❒ Before you can review potential duplicates and define merge batches, you must use
the Submit Duplicate Identification Batch window to define a duplicate identification
batch and run the DQM Duplicate Identification program on that batch. For more
information, see: Defining Duplicate Identification Batches, page 6- 2 .
To review duplicates and define merge batches:

1. Navigate to the Duplicate Identification: Batch Review window.
2. Query the duplicate identification batch that you want to review.
For the batch, the window displays the information shown in this table:
Field Value
Batch Name The name of the duplicate identification

batch.
Match Rule The match rule that the DQM Duplicate

Identification program used to match and
score duplicate candidates.
Creation Date The date that the duplicate identification

batch was created.
Match Threshold The match threshold defined in the match

rule. Records with a score that exceeds the
match threshold are selected as matches, or
potential duplicates.
In the Merge-To Parties region, the Duplicate Identification: Batch Review window
displays the information shown in this table for each merge-to party:
Field Value
Name The party name
Number The party number
Identifying Address The party identifying address
Duplicates The number of potential duplicates, or

merge-from parties
In the Merge-From Parties region, the window displays all the duplicate candidates
for the selected merge-to party. For each potential duplicate, you can see the
information shown in this table:

Field Value
Name The party name.
Number The party number.
Identifying Address The party identifying address.
Score The match score, which signifies how closely

the merge-from party matches the merge-to
party. The score is the sum of scores that
the match rule assigns to attribute matches
between the two parties. The match score
must exceed the match threshold of the
match rule for the party to be selected as a
merge-from party.
Merge Yes or no to indicate whether to merge the

party into the merge-to party or not. The
default of this value depends on the
automatic merge threshold of the match
rule. A party with a match score that exceeds
the threshold is defaulted to be merged.
3. To view information about why a pair of merge-to and merge-from parties was
designated as a potential duplicate match, select the merge-to and merge-from
party in the window.
4. Press the View Match Details button. The Match Details window appears. The
window shows again the name, number, and address of the merge-from and
merge-to parties.
The window also displays the information shown in this table:
Field Value
Matched Attribute The attribute that matches in both parties

according to the match rule definitions.
Merge-From Party Value The value of the matched attribute from the
merge-from party.
Merge-To Party Value The value of the matched attribute from the
merge-to party.
Score The score that the match rule assigns to the

merge-from party for the particular attribute
match to the merge-to party. The sum of
these scores makes up the total match score
of the merge-from party.
5. To view attribute match details between the same merge-to party and another
merge-from party, select another merge-from party in the list of values for the
Merge-From field.

6. Press the Close button when you finish viewing match details for the selected
merge-to party.
7. Repeat steps 3 to 6 for each merge-to party that you want to view match details for.
8. To switch the selected merge-from party to a merge-to party and vice versa, select a
merge-to party in the Duplicate Identification: Batch Review window.
9. Press the Change Merge-To Party button and select the merge-from party that you
want to replace the selected merge-to party.
Alternatively, you can use the list of values from the Merge-To Parties Name field
to change the merge-to party.
10. For each merge-from party, specify in the Merge option whether to merge
into the merge-to party or not. You can accept the defaults or, based on your
evaluation, select not to merge parties that were defaulted for merge.
Note: You can only override Merge options that are set to Yes.
11. If you want to specify that a merge-from party is not a duplicate match for the
merge-to party, select the merge-from party and check the Not Duplicate of
Merge-To Party check box.
Note: You can only select merge-from parties with the Merge
option set to No.
12. You can optionally enter or remove the end date for the merge-from party not to be
selected as duplicate of that specific merge-to party.
13. When you finish evaluating the batch, press the Create Merge Set button to create a
merge batch that consists of merge-from parties with the Merge option set to Yes and
their corresponding merge-to parties.
The Review Party Merge Batches window automatically appears for the next
procedure of submitting the sequence of parties in the batch to Party Merge. For
more information, see: Submitting Merge Batches, page 6- 7 .
If you decide later to change the Merge option to No for some parties in this
batch, you can still do so in the Duplicate Identification: Batch Review window as
long as you have not yet submitted the merge batch to Party Merge.
Related Topics
Submitting Merge Batches

Use the Review Party Merge Batches window to submit merge batches to Party
Merge. Party Merge is the Oracle Trading Community Architecture feature that performs
the actual merging of parties. The Review Party Merge Batches window displays all the
merge batches that you created from a specific duplicate identification batch.
For each merge batch, the window also displays the pairs of parties to be merged and the
sequence in which they are submitted. DQM automatically determines the sequence
when you create the merge batch to ensure that parties are successfully submitted
and merged.

For example, if you are merging party A to party B, and party B to party C, you must
merge party A to B before merging B to C. If you merge party B to C first, party B does
not exist any more for party A to merge into.
Prerequisites
❒ Before you can submit merge batches to Party Merge, you must create a merge batch
for the selected duplicate identification batch. For more information, see: Reviewing
Duplicates and Creating Merge Batches, page 6- 4 .
To submit merge batches:

1. Navigate to the Review Party Merge Batches window.
The window automatically appears when you create a merge
batch. Otherwise, navigate to the Duplicate Identification: Batch Review
window, query the duplicate identification batch that you want to submit merge
batches for, and press the View Merge Set button.
2. You can change the merge batch names in the Party Merge Batch field if you want.
The default names consist of the original duplicate identification batch name and
a sequential number. For example, the first merge batch that you create with
duplicate identification batch ABC is named 1-ABC. The second merge batch is
called 2-ABC, and so on.
The Status field displays the status of the merge batch:
• Ready to Submit: This batch is the one that is submitted when you press the
Submit Party Merge Batch button.
• In Queue: This batch is in the queue for submission.
• Pending: This batch has been submitted to Party Merge.
• Partially Complete: This batch has been partially merged with success in
Party Merge.
• Complete: This batch has successfully merged in Party Merge.
For each merge batch, the Merge Batch Parties region displays the names and
numbers of all the merge-from and merge-to parties, in the default sequence that
the pairs will be submitted.
3. Press the Submit Party Merge Batch button to submit the batch with the Ready
to Submit status.
Note: You must submit batches in the order that they are displayed.
When the submission successfully completes, the status for the batch changes to
Pending and the next batch gets the Ready to Submit status.
4. To continue to the Party Merge process, press the Go To Party Merge button. The
Merge Parties window automatically appears for the selected merge batch.
Note: You can only select merge batches with a Pending status
for Party Merge.

When the actual Party Merge process is run on a merge batch, the concurrent
request number of the process is displayed in the Request ID field of the Review
Party Merge Batches window.
Related Topics
Party Merge Overview, page 7- 1

7
Party Merge
This chapter describes using Party Merge to identify batches of duplicates, merge
duplicate parties and party sites, and resolve Party Merge errors.
• Party Merge Overview
• Creating Merge Batches
• Merging Parties
• Merging Party Sites of a Party
• Processing Merge Batches
• Reviewing the Party Merge Log
• Party and Customer Account Merge
Party Merge Overview

Party Merge provides the capability to merge parties and their related entities in the
TCA Registry, eliminating duplicate data in the Registry. Because the TCA Registry
shares information across the E-Business Suite, you must maintain the quality of the
data in the Registry. Duplicate data can reduce the efficiency and accuracy of your
party processing and reports.
With Party Merge, you can:
• Consolidate duplicate parties or party sites.
For example, you can merge Vision Corp. into Vision Corporation.
• Merge duplicate party sites for a party.
Note: Even though you can also use Party Merge to integrate an acquired
party into the acquiring party, Party Merge is primarily for finding
and resolving duplicates. Before using Party Merge for mergers and
acquisitions, you must fully test and prepare for the results of merging.
For example, after merge, all existing transactions are repointed to the
surviving party. You cannot reconcile transactions or audit transactions
details for the acquired party, or reprint invoices for that party. If you
still need to perform various tasks for the acquired party, you might
not want to merge it into the acquiring party.
Party Merge 7-1

In Party Merge, merge batches are sets of parties or party sites to merge, and the Party
Merge process runs on one merge at a time. A merge batch determines the records
involved in the merge as well as the general outcome of the merge.
When you submit parties or party sites for merge, the Party Merge process runs as a
concurrent request to complete the actual merge. You can review the log to check the
results and any errors that might have occurred.
To identify the duplicate parties to include in a merge batch, you can:
• Use batch duplicate identification to automatically find batches of
duplicates. See: Batch Duplicate Identification Overview, page 6- 1 .
• Manually determine and enter the duplicates into merge batches in Party Merge.
In addition to Party Merge, you can use the Customer Account Merge feature to merge
transactions from a source customer account to a target customer account. After the
merge-from account is merged into the merge-to account, you can either inactivate
or delete the source customer account. See: Merging Customers, Oracle Receivables
User Guide.
Your administrator can set up Party Merge. See: Setting Up Party Merge, Oracle Trading
Party Merge Process

The Party Merge process involves four procedures to resolve duplicate parties and
party sites in the TCA Registry:
1. Creating the merge batch, page 7- 8 .
2. Processing the merge batch, page 7-14.
3. Reviewing the Party Merge log, page 7-15.
4. Identifying types of errors, page 7-17.
Related Topics
Party Merge Details, page 7- 2
Impact on Source IDs, page 7- 7
Impact on D&B Data, page 7- 8
Party and Customer Account Merge, page 7-17
Party Merge Details

In Party Merge, the merging parties are referred to as the merge-from party and the
merge-to party, or the source and the target respectively. After the merge-from party is
merged into the merge-to party, you can delete the merge-from, or source, party. By
default the merge-from party is set to a Merged status.
The related child entities that get merged or transferred include party
relationships, contact information, party profiles, customer accounts, and information
obtained from third-party sources. For more information about what information is
merged or transferred, see: Duplicate Checking, page 7- 5 .

Merging Parties or Party Sites
You can merge parties or party sites that belong to a party. You cannot merge party sites
between parties, however, until you merge the parties that they belong to. Before the
Party Merge process begins, you can choose to delete the merge-from party when the
process ends. If you merge party sites for the same party, you cannot choose to delete the
merge-from party because the merge-from and merge-to parties are the same party.
Deleting a party changes its status to Deleted. You cannot retrieve a deleted party in
any search or transaction window unless the application is specifically designed to
include deleted parties in any query results.
Note: If the merge-from and merge-to party have extended TCA
attributes, only the attributes of the merge-to party are retained after
the merge. See: Administering Extensions, Oracle Trading Community
Details on Transferring Party Sites

If a merge-from and merge-to party site are not duplicates, the merge-from party site is
essentially transferred to the merge-to party. The actual process, however, involves a
copy and merge, for legal auditing requirements.
1. A copy of the merge-from party site is created for the merge-to party.
2. The merge-from party site is then merged with that copy.
3. The merge-from party and party site have the Merged status.
For example, this table shows the parties before the merge, with two party sites that
are not duplicates.
From Party Name From Party Site To Party Name To Party Site
Vision1 500 Vision Parkway Vision2 100 Vision Parkway
During the merge, a copy of 500 Vision Parkway is created for Vision2, so both parties
now have duplicate party sites. As with all duplicate party sites, the 500 Vision Parkway
site from Vision1 is merged into the copied site of Vision2. After the merge, both Vision1
and the original 500 Vision Parkway have a Merged status.
Merging Persons or Organizations

You can merge Person or Organization party types. You can, however, only merge
parties with the same party type. This implies that an organization can only be merged
with another organization, a person with a person, and so on.
Merging Entities from Other Applications

You must process and merge or appropriately transfer other Oracle Applications
information of the duplicate party, such as transactions and attributes, into the
merge-to party. Before using the Party Merge feature, your administrator must
register all applications and entities that interact with Oracle Trading Community
Architecture to ensure that all transaction and attributes are merged when the party
is merged. See: Merge Dictionary Overview, Oracle Trading Community Architecture
Party Merge 7-3

Related Topics
Party Merge Example

This example of a party merge shows both the before and after conditions.
ABC Company has implemented the Oracle Applications E-Business Suite. While
checking the quality of its data, ABC Company determines that duplicate records exist
for a party, Vision Corporation. Data for this party were entered into the database under
the names Vision Corp. and Vision Inc. Using Party Merge, ABC Company plans to
merge the two Vision parties.
Before the Merge
This table shows the from and to parties and their party sites.
From Party From Party Site Use To Party To Party Site Site Use
Name Site Name
Vision Corp. 500 Vision • Bill-to Vision Inc. 100 Vision Bill-to
Parkway Parkway
• Ship-to
• Marketing
600 Vision • Bill-to 600 Vision Ship-to

Parkway Parkway
• Ship-to
The 600 Vision Parkway party site exists for both parties and is considered to be
duplicated.
During the Merge
The party site 500 Vision Parkway is transferred to Vision Inc. The details of 500 Vision
Parkway, for example the bill-to, ship-to, and marketing party site uses stay with the
party site.
The party site 600 Vision Parkway is merged with 600 Vision Parkway on Vision Inc. The
bill-to site use is transferred because it does not exist for Vision Inc. The ship-to site use
is merged because it already exists for Vision Inc.
After the Merge
Vision Corp.
• Vision Corp. is set to a status of Merged.
• The party site 600 Vision Parkway is set to a status of Merged.
• The ship-to party site use for 600 Vision Parkway is set to a status of Merged.
Vision Inc.
Vision Inc. has three party sites:
• 100 Vision Parkway with a bill-to site use.
• 500 Vision Parkway with a bill-to, ship-to, and marketing site use.
• 600 Vision Parkway with a bill-to and ship-to site use.

Duplicate Checking
In Party Merge, you can either merge or transfer the child entities that belong to the
merge-from party. These entities can include party sites, contacts, relationships, and
profile information. The merge procedures automatically handle the merge or transfer
of other child entities.
Below are some of the TCA entities and the rules that are applied to them to determine
whether the entities should be merged or transferred. In general, if the Party Merge
process determines that the entities are exact duplicates based on the concatenation of
table columns, the merge-from record will be merged with the merge-to record. If the
entities are not exact duplicates, the merge-from entity is transferred to the merge-to
entity.
Contact Points and Preferences
Contact Points
You must transfer contact points unless they are exact duplicates. Only exact duplicates
are merged.
Contact points can point to a party site. These contact points are transferred or merged
the way that the contact points are at the party level.
Contact Preferences
Contact preferences are always merged.
Customer Accounts and Related Information
Customer Accounts
Customer accounts are transferred to the merge-to party. After the parties are
merged, you can use the Customer Merge program to merge customer accounts. This is
a separate process that requires a separate concurrent request. See: Merging Customers,
Customer Account Sites

Customer account sites are related to party sites. How customer account sites are merged
depends on how the party site is processed.
• Party site merge: The customer account site must be modified to point to the
existing merge-to party site.
• Party site transfer: The customer account site should point to the merge-from party
site, which now points to the merge-to party.
Roles in a Customer Account

Each role in a customer account points to a party. A customer account role can be
processed during the Party Merge process in either of these situations:
• The role points to the merge-from party. In this case, the role must be modified to
point to the merge-to party.
• The role points to an organization contact or other relatable party relationship. This
relationship is being merged or transferred as the relationship’s subject or object
in a party merge.
Party Merge 7-5

Customer Contact Points
Customer contact points point to party-level contact points. The customer contact point
refers to the merge-to contact point on the merge-to party. This contact point is either
a pre-existing contact point for the merge-to party or a contact point that has been
transferred from the merge-from party.
Additional Party Information

If the duplicate check procedure identifies the following as exact duplicates, these
entities are merged, otherwise they are transferred. The additional party information
depends on whether the party is an organization, person, or either.
When the Party is an Organization

If the duplicate check procedure identifies the following as exact duplicates, they are
merged.
• Financial Numbers: If there is a duplicate financial number in the merge-to party’s
financial report data, that financial number is merged with the duplicate.
• Financial Reports: The procedure checks for duplicates in the
HZ_FINANCIAL_REPORTS table.
• Industrial Reference: The procedure checks for duplicates in the
HZ_INDUSTRIAL_REFERENCE table.
• Organization Indicators: The procedure checks for duplicates in the
HZ_ORGANIZATION_INDICATORS table.
• Securities Issued: The procedure checks for duplicates in the
HZ_SECURITY_ISSUED table.
When the Party is a Person

merged.
• Citizenship: The procedure checks for duplicates in the HZ_CITIZENSHIP table.
• Education: The procedure checks for duplicates in the HZ_EDUCATION table.
• Employment History: The procedure checks for duplicates in the
HZ_EMPLOYMENT_HISTORY table.
• Person Interest: The procedure checks for duplicates in the HZ_PERSON_INTEREST
table.
• Person Language: The procedure checks for duplicates in the
HZ_PERSON_LANGUAGE table.
• Work Class: The procedure checks for duplicates in the HZ_WORK_CLASS table.
When the Party is Either an Organization or a Person

merged.
• Certifications: The procedure checks for duplicates in the HZ_CERTIFICATIONS
table.
• Credit Ratings: Credit ratings are always transferred unless the application
providing the credit rating information has a duplicate check in its merge procedures.

• Financial Profiles: The procedure checks for duplicates in the
HZ_FINANCIAL_PROFILE table.
• References: The procedure checks for duplicates in the HZ_REFERENCES table.
Related Topics
Impact on Source IDs

A party can have mappings to the source systems that the record originated from. A
source ID is the ID of that record in the original system. For example, the Oracle party
has the ID 12345 in the Gorman source system. When this Oracle record is imported
from Gorman into the TCA Registry, 12345 becomes the source ID. See: Source Systems
When you merge two parties with source IDs, the IDs of the merge-from party are
transferred to the merge-to party. If multiple source IDs from the same source system
are not allowed to map to one TCA record, then only the merge-to party’s mapping is
kept active.
Note: D&B is the one source that can never be set to allow multiple
mappings to one TCA record.
For example, this table shows source system mapping records for the Oracle 1 and
Oracle 2 parties. The Gorman source system was set to allow multiple mappings from
that source. As always, D&B allows only one source ID to map to a party.
Party Source System Source ID Status

Name
Oracle 1 Gorman 10001 Active
Oracle 1 D&B 22222 Active
This table shows the result of Oracle 1 merging into Oracle 2.
Party Source System Source ID Status

Name
Oracle 1 Gorman 10001 Inactive
Oracle 1 D&B 22222 Inactive
Party Merge 7-7

The Oracle 1 mapping record for Gorman is inactivated, and a new mapping record is
created for Oracle 2 and source ID 10001. Because a party can have multiple mappings to
Gorman, Oracle 2 ends up with the mapping transferred from Oracle 1.
The mapping to D&B from Oracle 1 is inactivated and does not transfer over to Oracle 2
because a party cannot have multiple mappings to D&B. Oracle 2 remains with the same
mapping to D&B, before and after the merge.
Related Topics
Impact on D&B Data

Oracle Trading Community Architecture lets you purchase data from D&B’s global
business databases. Information purchased from D&B is stored in the party tables at the
party level and is also merged with other party information when you run Party Merge.
Party Merge resolves and merges D&B data for the merge-from and merge-to
parties, and retains as much of the D&B data about the parties as possible. When two
parties with D&B data are merged, these situations might arise:
• DUNS Numbers Are Different: If the DUNS Numbers for the merge-from and
merge-to parties are not the same number, the data for the merge-to party is
retained. The D&B data for the merge-from party is set to the Merged status.
• DUNS Numbers Are the Same: If the DUNS Numbers for the merge-from and
merge-to parties are the same number, the latest D&B data, whether for the
merge-from or merge-to party, is retained. If the latest D&B data is stored for the
merge-from party, that data overwrites the D&B data stored for the merge-to party.
• No D&B Data Exists for the Merge-To Party: If D&B data exists for the merge-from
party but not the merge-to party, the D&B data for the merge-from party transfers to
the merge-to party as a result of the merge process.
• Merge-From Party is a Branch of Merge-To Party: If the merge-to party is the
headquarters for the merge-from party, which is a branch, and the merge-to party
contains the D&B data, this data is retained. The status of the merge-from party
is set to Merged.
• Merge-From Party is the Headquarters of Merge-to Party: If the merge-from
party is the headquarters and the merge-to party is its branch, the D&B data for
the merge-from party is copied to the merge-to party. The merge-to party becomes
the headquarters. All branches associated with the merge-from party now belong
to the merge-to party.
Related Topics
Creating Merge Batches

Use the Merge Batch window to set up a merge batch for the parties or party sites that
you are merging. See:

• Merging Parties, page 7-10
• Merging Party Sites of a Party, page 7-13
You can only merge parties of the same party type. You can merge or transfer party
sites, organization contacts, party relationships, and profiles related to a party. All other
entities related to a party are either always merged or always transferred based on the
merge procedures defined for that entity.
When you select a party as the merge-from or merge-to party in a batch, the records for
that party are locked and cannot be selected as a merge candidate for this or any other
batch until after this batch is submitted and processed.
Note: For your merge batch, you cannot include any party that is
already part of a de-duplication merge request. See: Merge Requests
Overview, Oracle Customer Data Librarian User Guide.
Aside from manually creating merge batches in the Merge Batch window, you can
also use batch duplicate identification to automatically determine duplicate parties
based on match rules. You create merge batches from the suggested duplicate
candidates. See: Batch Duplicate Identification Overview, page 6- 1 .
In the Merge Batch window, you can specify if you want to delete the merge-from
party after the merge process completes. Otherwise, the merge-from party is set to a
status of Merged.
The results of the merge are saved only after the entire batch has completely processed. If
one record results in error, none of the parties in the batch are merged. If you want to
save the resulting party after each merge, you must create a separate batch for each
pair of parties to merge.
If the merge batch creation itself results in error, review the log of the Create Merge Batch
program in Standard Request Submission. After fixing the errors, you can manually
rerun the Create Merge Batch program.
Prerequisites
Before you create a merge batch, you should decide if you want to delete all of the
records of the merge-from party.
Program Parameter
Use this parameter when you submit the Create Merge Batch program to re-create a
merge batch that previously resulted in error.
Merge ID
Enter the merge ID of the merge batch that you want to re-create. Only failed merge
batches are available. The merge ID is the number automatically appended to the
end of the merge batch name.
Related Topics
Party Merge 7-9

Merging Parties
When you create a merge batch with parties to merge, you can also define the merge of
entities from the merge-from and merge-to parties, including:
• Party sites, page 7-10
• Party relationships, page 7-11
• Organization contacts, page 7-12
You can also view party profile attributes of the merge-from and merge-to
parties. See: Viewing Profile Information, page 7-12.
If you used batch duplicate identification to create the merge batch, all the details
of the merge-from and merge-to parties are already determined and cannot be
changed. See: Batch Duplicate Identification Overview, page 6- 1 .
To create a merge batch for parties:

1. Navigate to the Merge Batch window.
2. Enter a batch name that is unique and related to the parties that you are merging.
3. Enter a reason for the merge, either a predefined reason or your own.
4. Check Delete Merged Records to delete the merge-from party records after the batch
merge completes. Do not check this box if you do not want to delete the merged
records. These records are instead assigned a Merged status.
5. In the Party Details region, enter pairs of parties that you want to merge, including
the party type and merge reason for each pair.
6. Save your work before moving on to the tabbed regions.
Related Topics
Creating Merge Batches, page 7- 8
Merging Party Sites

You can merge party sites either within a single party or between a pair of parties
that you are merging.
For tax purposes, you can only merge addresses with the same tax jurisdiction as defined
in Oracle Receivables.
Note: Oracle Applications calculates sales taxes in the United States
based on the address components of the Sales Tax Structure that you
define in the System Options window. Because sales tax rates can
change, modifying these components can invalidate the tax calculated
for transactions previously assigned to an address. To ensure that you
do not violate US sales tax audit requirements, you must merge party
sites with addresses of same Sales Tax Structure. See: Setup Steps for
US Sales Tax, Oracle Receivables Tax Manual.

To merge party sites:
1. Navigate to the Party Sites tabbed region after you enter the basic merge batch
information. See: Merging Parties, page 7-10 or Merging Party Sites of a Party,
page 7-13.
2. Enter the from site’s address and the appropriate merge operation, Merge or
Transfer Party Merge.
3. If you enter the Merge operation, you must enter an address for the merge-to party
site.
Merging Party Relationships

Party relationships are binary roles between two parties, such as a partnership. You can
merge or transfer relationships that the merge-from or merge-to party has, as part of the
merge of the two parties. If the same party relationship exists for these two parties, the
relationships are automatically selected to be merged and cannot be transferred.
Note: You cannot use Party Merge to merge parties of type
Relationship, or to independently merge relationship records without
a merge batch with at least one organization or person involved in
those relationships.
Example
If Joe is your contact at Vision Corporation, you can record this as a relationship between
the person Joe and the organization Vision Corporation. This table shows details of
this sample relationship.
Party ID Subject ID Object ID Type of Relationship
789 (Joe, contact for 456 (Joe) 123 (Vision Corp.) Contact Of
Vision Corp.)
After reviewing your database, you might determine that Vision Corporation and Vision
Inc., another party in your database, are duplicates that should be merged.
After the merge process, the contact information would be changed as shown in this
table.
Party ID Subject ID Object ID Type of Relationship
789 (Joe, contact for 456 (Joe) 123 (Vision Inc.) Contact Of
Vision Inc.)
To merge party relationships:

1. Navigate to the Party Relationships tabbed region after you enter the basic merge
batch information. See: Merging Parties, page 7-10.
Note: This tab does not show relationships in which a person
is a contact, employee, or member of an organization, or any
other role in the Party Contacts relationship group. For these
relationships, see: Merging Organization Contacts, page 7-12.
Party Merge 7-11

2. For each relationship to be transferred or merged for a party, enter that relationship’s
subject, object, and type in the From Relationships region.
For example, if a type of relationship exists called Subsidiary of and Vision
Manufacturing is a subsidiary of Vision Corporation, then Vision Manufacturing
would be the subsidiary of Vision Corporation. Vision Manufacturing would be
the subject of the relationship and Vision Corporation would be the object of the
relationship.
Party relationships do not require a hierarchical relationship like a parent-child
relationship. For example, party relationships defined as Partner of, Colleague
of, Competitor of, and so on do not imply a hierarchical relationship, but you have to
identify a subject and object of the relationship before you can merge relationships.
3. Enter either Merge or Transfer for the operation.
You can merge only if the same party relationship exists for the merge-from and
merge-to parties.
4. Enter a relationship for the merge-to party in the To Relationships region.
Merging Organization Contacts

You can merge organization contacts between parties that you are merging. See: Merging
Parties, page 7-10.
If the same organization contact exists for the merge-from and merge-to parties, that
contact is automatically selected to be merged.
To merge organization contacts:

1. Navigate to the Org Contacts tabbed region after you enter the basic merge batch
information. See: Merging Parties, page 7-10.
Note: This tab shows only relationships in which a person is a
contact, employee, or member of an organization, or any other
role in the Party Contacts relationship group. For all other
relationships, see: Merging Party Relationships, page 7-11.
2. In the From Org Contact region, for each organization contact for the merge-from
party, enter that contact’s name and title. You can enter the type, department, and
party site to identify a group of organization contacts.
3. Enter either Merge or Transfer for the operation.
You can merge only if a similar organization contact exists for the merge-to party.
4. If you enter Merge as the operation, enter an organization contact for the merge-to
party that the party in the From Org Contact region is to be merged into.
Viewing Profile Information

For the parties that you are setting up to be merged in a merge batch, you can view the
merge-from and merge-to parties’ profile information. See: Merging Parties, page 7-10.
Party profile information differs depending on whether the parties to merge are
organizations or people. You can see the taxpayer ID and tax registration number for

both, but the date of birth for parties of type Person and the DUNS Number for parties
of type Organization.
To view profile information for the merging parties:

Navigate to the Person Profiles or Org Profiles tabbed region after you enter the basic
merge batch information. See: Merging Parties, page 7-10.
For either the person or the organization, you see the profile of the merge-from party
that is to be merged with the profile of the merge-to party.
Merging Party Sites of a Party

Use the Merge Batch window to create merge batches for merging duplicate party
sites within a single party. For each batch, you can include multiple parties to merge
party sites for.
After the merge process, all entities associated with the merge-from party site, including
customer account sites, refer to the merge-to party site.
To submit a merge for two sites of the same party, you cannot check Delete Merged
Records. Checking that check box implies deleting both the merge-from and merge-to
parties.
If the merge-from address is the identifying address, you must confirm that the merge-to
address should be used as the identifying address to continue with the merge. If you
want to merge the identifying address of a customer account, you can use Customer
Account Merge to merge the account sites that point to these party sites only after you
merge the party sites. See: Merging Customers, Oracle Receivables User Guide.
To merge party sites for the same party:

1. Navigate to the Merge Batch window.
2. Enter a batch name that is unique and related to the party for which you are merging
the party sites.
3. Enter a reason for the merge, either a predefined reason or your own.
4. Make sure that Delete Merged Records is not checked.
5. In the Party Details region, enter one or more from-parties for which you want to
merge the party sites, including the party type.
6. Check Site Merge. The To Party fields are automatically populated with information
from the From Party fields.
Alternatively, you can just enter the party name or party number of your from-party
in the To Party fields.
7. Enter the reason for merging these party sites.
8. Save your work.
9. Enter all party sites to be merged in the Party Sites tabbed region. See: Merging
Party Sites, page 7-10.
The other tabbed regions are disabled.
Party Merge 7-13

Related Topics
Creating Merge Batches, page 7- 8
Processing Merge Batches

After you create the merge batch to merge either different parties or party sites of the
same party, you have three options to process your merge batch:
• Preview your merge batch and the outcome of the merge process before submitting
the Party Merge process.
• Submit the Party Merge process immediately after entering your merge details.
• Save your work and submit the Party Merge process at a later time.
After a merge batch is successfully processed, you cannot reverse the results.
To preview the merge batch results:

1. Create the merge batch in the Merge Batch window. For more
information, see: Creating Merge Batches, page 7- 8 .
2. Click Preview Batch.
3. The Party Merge process runs and merges the appropriate parties and other
entities, but does not save the merged records to the database. The request number is
displayed in the Last Request ID field.
4. In Standard Request Submission, find the Party Merge process and preview
the expected effect of the merge process on the merging parties and their
entities. See: Reviewing the Party Merge Log, page 7-15.
If you query for the merge batch at this point in the Merge Batch window, the Merge
Done check boxes are not checked. Even if you checked the Delete Merged Records check
box, no records are deleted because the merge process is submitted in the preview mode.
To submit the Party Merge process:

1. Create the merge batch in the Merge Batch window. See: Creating Merge Batches,
page 7- 8 .
Optionally save the merge batch and submit it later.
2. Click Run Batch.
The Party Merge process runs and merges the appropriate parties and other
entities. The entire batch must be successfully processed before the merged records
are saved to the database.
The request number is displayed in the Last Request ID field.
3. In Standard Request Submission, find the Party Merge process and view the results
and status of the merge process. See: Reviewing the Party Merge Log, page 7-15.
If you query for the merge batch at this point in the Merge Batch window, the Merge
Done check box is checked. If you checked Delete Merged Records, the merge-from
parties are set to the Deleted status.
If the Party Merge process results in error, you can rerun it from Standard Request
Submission after you fix the errors. See: Identifying Types of Errors, page 7-17.

Program Parameter
Use this parameter when you submit the Party Merge process to remerge a batch that
previously resulted in error.
Merge ID
Enter the merge ID of the merge batch that you want to remerge. Only failed merge
batches are available. The merge ID is the number automatically appended to the
end of the merge batch name.
Related Topics
Reviewing the Party Merge Log

You can use the log of the Party Merge process to review the parties and related entities
affected by the process. This output file is automatically generated after you run the
Party Merge process. The report body displays Merged or Deleted for each merge-from
party to indicate the status of the merge-from party or party site. The report displays an
error message if the Party Merge process fails.
This table shows the report headings and the corresponding values.
Party Merge 7-15

Heading Value
Request ID The request ID for your concurrent process.
Log Message The sequence of processes that run to execute the merge batch, including:
• Start time of the merge
• Batch ID
• Batch name
• Rule set name
• Merge process
• Entities merged or transferred
Execution status The possible execution status combinations are:

• Merge batch successfully executed / Batch rollback complete: This status occurs after
you click Preview Batch in the Merge Batch window and the Party Merge process
successfully runs without saving any merged records.
This status indicates that the merge procedures registered with the Merge Dictionary
ran, the merge process completed, but the merged records were not committed to the
database.
• Merge batch successfully executed / Batch commit complete: This status occurs after
you click Run Batch in the Merge Batch window and the Party Merge process successfully
runs.
This status indicates that the merge procedures registered with the Merge Dictionary
ran, the merge process completed, and the merged records were saved to the database.
• Merge batch failed / Batch rollback complete: This status indicates that the merge
procedures registered with the Merge Dictionary did not run successfully, and no
merged records were saved to the database. Along with this status information, the log
provides details of the error and identifies the merge procedure that the error occurred
in. See: Identifying Types of Errors, page 7-17.
The log message displays the details of the entities that have been merged or
transferred. The entities that are merged or transferred are based on the merge
procedures that were registered with the Merge Dictionary. See: Merge Dictionary
The entities include, but are not restricted to, parties, party sites, relationships, contacts,
profiles, contact points, customer accounts, customer account sites, and so on.
In addition to these standard TCA entities, other Oracle Applications and legacy system
entities can be registered with the Merge Dictionary. These entities are also merged
during the Party Merge process. You can also view the details about these entities in the
Party Merge Request log file.
Related Topics

Identifying Types of Errors
The Party Merge process encounters two types of errors: data errors and procedure
errors. After you fix the errors, you can resubmit the Party Merge process from Standard
Request Submission. See: Processing Merge Batches, page 7-14.
Data Errors
The Party Merge process might fail at the batch or party level if any record contains
corrupt data. If the Party Merge process encounters corrupt data, the entire batch
fails, and none of the parties are merged. Users should be able to correct most data errors.
Procedure Errors
The Party Merge process can fail if any procedures were not correctly
coded, registered, and tested. The Party Merge log identifies the procedure that caused
the Party Merge process to fail. Procedure errors must be corrected by an application
developer or administrator who has access to the error log, Merge Dictionary, and
PL/SQL procedures.
Related Topics
Reviewing the Party Merge Log, page 7-15
Party and Customer Account Merge

Oracle Trading Community Architecture allows you to merge parties and customers, or
customer accounts. You can use the Customers Merge window and the Customer Merge
program to merge customer accounts. See: Merging Customers, Oracle Receivables
User Guide.
If you find duplicate parties, you should determine if duplicate customer accounts
exist between the merge-from and merge-to parties. If you find duplicate customer
accounts, duplicate parties might exist for these customer accounts. You should verify
that duplicate parties exist and merge those duplicate parties.
• When two customer accounts are merged and the corresponding parties are verified
as duplicates, the parties can be merged.
• When two parties are merged and the corresponding customer accounts are verified
as duplicates, the customer accounts can be merged.
Related Topics
Party and Customer Account Merge Example, page 7-17
Party and Customer Account Merge Example

ABC Company has implemented the Oracle Applications E-Business Suite. While
checking the quality of its customer data, ABC Company determines that duplicate
records exist for a party, Vision Corporation. Data for this party were entered into the
database under the names of Vision Corp. and Vision Inc. Using Party Merge, ABC
Company plans to merge the two Vision parties.
Party Merge 7-17

Before Party or Customer Account Merge
This table shows the from and to parties and their customer accounts and account
party sites.
From Party From Acct From Acct Site Use To Party To Acct To Acct Site Use
Name Num Party Site Name Num Party Site
Vision Corp. 765432 500 Vision • Bill-to Vision Inc. 234567 100 Vision Bill-to
Parkway Parkway
• Ship-to (ID: 1VIS
(ID: 1V
• Marketing INC)
ISCORP)
600 Vision • Bill-to 600 Vision Ship-to

Parkway Parkway
• Ship-to (ID: 2VIS
(ID: 2V
INC)
ISCORP)
The 600 Vision Parkway party sites exist for both Vision Corp. and Vision Inc. and are
deemed to be duplicates.
Party Merge Followed by Customer Account Merge Example

Merging the Parties
The 500 Vision Parkway party site is transferred to Vision Inc. The details for 500 Vision
Parkway, such as the bill-to, ship-to, and marketing party site uses stay with the party
site.
The 600 Vision Parkway party site from Vision Corp. is merged with 600 Vision Parkway
for Vision Inc. The bill-to site use is transferred because it does not exist for Vision
Inc. The ship-to is merged because it already exists for Vision Inc.
After Party Merge and Before Customer Account Merge
Vision Corp.
• Vision Corp. is set to a status of Merged.
• The 600 Vision Parkway party site is set to a status of Merged.
• The ship-to party site use for 600 Vision Parkway is set to a status of Merged.
Vision Inc.
• Vision Inc. has two customer accounts with these account numbers:
• 765432
• 234567
• Vision Inc. has three party sites:
• 100 Oracle Parkway with a bill-to site use.
Customer account site ID: 1VISINC.
• 500 Oracle Parkway with a bill-to, ship-to, and marketing site use.
Customer account site ID: 1VISCORP.
• 600 Oracle Parkway with a bill-to and ship-to site use.

Merging the Customer Accounts
Customer account 765432 is merged with customer account 234567. Customer account
site 2VISCORP is merged with customer account site 2VISINC.
After Customer Account Merge
• Customer account 765432 is set to a status of Merged.
• Customer account site 2VISCORP is set to a status of Merged.
• The bill-to and ship-to site uses on customer account site 2VISCORP are set to a
status of Merged.
• Vision Inc. has one customer account, 234567.
• Vision Inc. has three party sites:
• Customer account site ID: 2VISINC.
Customer Account Merge Followed by Party Merge Example

Merging the Customer Accounts
Customer account 765432 is merged with customer account 234567. Customer account
site 2VISCORP is merged with customer account site 2VISINC.
After Customer Account Merge and Before Party Merge
• Customer account 765432 has the status of Merged.
• Customer account site 2VISCORP has the status of Merged.
• The bill-to and ship-to site uses for customer account site 2VISCORP have the
status of Merged.
• Vision Corp. has the following party sites:
• 500 Vision Parkway, with three uses: bill-to, ship-to, and marketing.
• 600 Vision Parkway, with two uses: bill-to and ship-to.
• Vision Corp. does not have any customer accounts or customer account sites
belonging to it.
• Vision Inc. has two party sites:
• 100 Vision Parkway, with one use: bill-to.
• 600 Vision Parkway, with one use: ship-to.
Party Merge 7-19

Merging the Parties
The 500 Vision Parkway party site is transferred to Vision Inc. The details of the party site
uses for 500 Vision Pkwy, such as bill-to, ship-to and marketing stay with the party site.
The 600 Vision Parkway party site is merged with 600 Vision Parkway to Vision Inc. The
bill-to site use is transferred because it does not exist for Vision Inc. The ship-to is
merged because it already exists for Vision Inc.
After Party Merge
• Vision Inc. has three party sites.

A
Reports and Processes
This section lists the reports and processes, including relevant request sets, that
are seeded in Standard Request Submission for the Trading Community Manager
responsibility.
Some reports and programs can be submitted in multiple ways, but these descriptions
are for running them from Standard Request Submission.
Reports
Customer Listing - Detail
Provides detail information about customers. See: Customer Listing Detail and
Summary Reports, Oracle Receivables User Guide.
Customer Listing - Summary

Provides summary information about customers. See: Customer Listing Detail and
Summary Reports, Oracle Receivables User Guide.
Customer Profiles Report

Provides customer profile information for customers or customer sites. See: Customer
Profiles Report , Oracle Receivables User Guide.
Customer Relationships Listing

Provides customer relationships information. See: Customer Relationships Listing,
DNB Global Data Products Request Report

Provides details about the D&B information purchased within a specified date
range. See: DNB Global Data Products Request Report, page 3-25.
Duplicate Customer Report

Lists possible duplicate customers. See: Duplicate Customer Report, Oracle Receivables
User Guide.
Duplicate DUNS Report

Lists parties in the TCA Registry with the same DUNS Number. See: Duplicate DUNS
Report, page 3-25.
Reports and Processes A-1

HZ Upgrade Script Report
Provides details on scripts that were run during upgrade. See: HZ Upgrade Script
Report, Oracle Trading Community Architecture Administration Guide.
Import Batch De-Duplication Report

Provides batch de-duplication results, or a preview if you run it before the actual
import. See: Import Batch De-Duplication Report, page 2- 9 .
TCA Import Error Report

Displays errors from bulk imports. See: Resolving Import Errors, page 2-15.
Processes
Account to Party Relationships Migration Program
Migrates account relationships to party relationships after upgrade. See: Account
to Party Relationships Migration Program, Oracle Trading Community Architecture
Address Validation
Validates addresses against known or authorized data sources. See: Address Validation,
page 4- 1 .
Automerge
Resubmits previous Automerge processes that resulted in error. See: Automerge, Oracle
Copy Organization Extensions Data for Profile Versioning

Copies organization profile extensions data and creates new extensions records for new
organization profile versions. See: Copying Extensions Data for Profile Versioning,
Oracle Trading Community Architecture Administration Guide.
Copy Person Extensions Data for Profile Versioning

Copies person profile extensions data and creates new extensions records for new person
profile versions. See: Copying Extensions Data for Profile Versioning, Oracle Trading
Create Merge Batch

Resubmits previous merge batch creations that resulted in error. See: Creating Merge
Batches, page 7- 8 .
Customer Interface
Imports customer and account information. See: Importing Customers Using Customer
Interface, Oracle Receivables User Guide.
A-2 Oracle Trading Community Architecture User Guide

Customer Interface Master Conc Program
Imports customer and account information using parallel workers. See: Importing
Customers Using Customer Interface, Oracle Receivables User Guide.
Customer Merge
Merges duplicate customers and account information. See: Submitting the Merge
Process, Oracle Receivables User Guide.
Customer text data creation and indexing

Indexes customer account data. See: Customer Text Data Creation and Indexing, Oracle
D&B Import Adapter

Loads D&B information in batches. This is a request set. See: D&B Import Adapter,
page 3-21.
DQM Compile All Rules

Compiles all DQM match rules. See: DQM Compile All Rules Program, Oracle Trading
DQM Index Optimization Program

Optimizes interMedia indexes in the DQM staged schema. See: DQM Index
Optimization Program, Oracle Trading Community Architecture Administration Guide.
DQM Staging Program

Creates or updates the DQM staged schema. See: DQM Staging Program, Oracle Trading
DQM Synchronization Program

Synchronizes the DQM staged schema with the TCA Registry. See: DQM
Synchronization Program, Oracle Trading Community Architecture Administration Guide.
Generate key for fuzzy match

Generates keys for fuzzy search.
Generate Request List for DNB Batch Load

Generates a list of parties that you want to purchase and batch load D&B information
for. See: Generate Request List for D&B Batch Load, page 3-20.
Generate Time Zone for Locations

Creates or updates time zone information for locations. See: Generate Time Zone for
Locations, page 4- 5 .
Generate Time Zone for Phone Numbers

Creates or updates time zone information for phone numbers. See: Generate Time Zone
for Phone Numbers, page 4- 5 .
Reports and Processes A-3

Import Batch to TCA Registry
Imports parties from interface tables into the TCA Registry. See: Import Batch to TCA
Registry, page 2- 8 .
Load D&B Data (8i Implementation)

Loads D&B information that was purchased online and corrected due to errors. See: Load
D&B Data, page 3-18.
Locations Spatial Index Rebuild

Rebuilds the spatial index on the HZ_LOCATIONS table. See: Locations Spatial Index
Rebuild, Oracle Trading Community Architecture Administration Guide.
Party Merge
Resubmits previous party merges that resulted in error. See: Processing Merge Batches,
page 7-14.
Person Names Migration Program

Migrates person names after upgrade. See: Person Names Migration Program, Oracle
Refresh of Classification Denormalization

Populates and refreshes the HZ_CLASS_CODE_DENORM denormalization
table. See: Refresh of Classification Denormalization, Oracle Trading Community
Remove Protected HR Person Data From TCA Tables

Removes protected Oracle Human Resources person data from the TCA tables.
Source System – Migrate Party Level Source System References

Migrates source system information. See: Source System – Migrate Party Level Source
System References, Oracle Trading Community Architecture Administration Guide.
Spatial Information for Locations Batch Update

Acquires latitude and longitude values for locations in the TCA Registry. See: Spatial
Information for Locations Batch Update, page 4- 4 .
TCA Import Batch Purge

Purges batches from the import interface tables. See: TCA Import Batch Purge, page 2-15.
TCA Import Postprocessing

Resubmits TCA Import Postprocessing runs that resulted in error. See: Postimport
Processes, page 2-14.
Third Party Data Integration Update

Regenerates the Single Source of Truth record. See: Third Party Data Integration Update
Program, Oracle Trading Community Architecture Administration Guide.
A-4 Oracle Trading Community Architecture User Guide

B
Standard Navigation Paths
This appendix describes standard navigation paths for using Oracle Trading Community
Architecture.
This appendix covers the following topics:
• Standard Navigation Paths
Standard Navigation Paths

Although your system administrator may have customized your navigator, typical
navigation paths are shown in this table. Access all of these features through the Trading
Community Manager responsibility.
Standard Navigation Paths B-1

Feature Functionality Navigation Path
Batch Duplicate Identification Duplicate Identification: Batch Data Quality Management >
Review Duplicate Identification > Batch
Review
Batch Duplicate Identification Match Details Data Quality Management >

Duplicate Identification > Batch
Review > View Match Details
Batch Duplicate Identification Review Party Merge Batches Data Quality Management >
Review > Create Merge Set
Data Quality Management >
Review > View Merge Set
Batch Duplicate Identification Submit Duplicate Identification Data Quality Management >
Batch Duplicate Identification > Batch
Definition
Party Merge Merge Batch Data Quality Management > Party

Merge
Review > Create Merge Set > Go to
Party Merge
Review > Create Merge Set > Submit
Party Merge Batch
Relationship Manager All Trading Community > Relationships
Third Party Data Integration D&B Online Purchase Content Access and Integration
> Dun and Bradstreet > Access/
Purchase
Third Party Data Integration Generate Request List for Batch Load Content Access and Integration
> Dun and Bradstreet > Generate
Request List
Third Party Data Integration Load D&B Data Content Access and Integration >
Dun and Bradstreet > Load
B-2 Oracle Trading Community Architecture User Guide

Index
A description, 3- 5
adapters purchasing, 3-11
address validation, 4- 1 viewing, 3-24
preimport address validation, 2-11 Business Verification Global Data Product, 3- 3
address corrections, 2-11, 4- 1
address uses C
import interface tables and TCA tables, 2- 7
address validation CDH
description, 4- 1 See Oracle Customer Data Hub (CDH)
in Bulk Import, 2-11 CDL
Address Validation program See Oracle Customer Data Librarian (CDL)
description, 4- 1 CDM
parameters, 4- 2 See Oracle Customer Data Management (CDM)
addresses circular relationships
import interface tables and TCA tables, 2- 7 description, 5- 3
mapping for Bulk Import, 2-12 classifications
validating, 4- 1 import interface tables and TCA tables, 2- 7
as of date contact points
relationship hierarchy, 5- 9 description, 1- 2
attributes import interface tables and TCA tables, 2- 7
description, 1- 2 contact roles
Automerge import interface tables and TCA tables, 2- 7
Registry de-duplication, 2- 9 , 2-11 contacts
description, 1- 2
import interface tables and TCA tables, 2- 7
B merging organization contacts, 7-12
batch de-duplication Create Import Batch API, 2- 2
description, 2- 8 Create Merge Batch program
batch duplicate identification description, 7- 9
defining and submitting duplicate parameter, 7- 9
identification batches, 6- 2 credit ratings
overview, 6- 1 import interface tables and TCA tables, 2- 7
process, 6- 1 Customer Account Merge
reviewing duplicates and creating merge and Party Merge, 7-17
batches, 6- 4 description, 1- 3 , 7- 1
submitting merge batches, 6- 7 example with Party Merge, 7-17
batch IDs customer account sites
creating for import batches, 2- 2 description, 1- 1
BIR merging, 1- 3
See Business Information Report customer accounts
Bulk Import, 2- 1 description, 1- 1
See also Import Batch to TCA Registry entering and maintaining, 1- 3
See also interface tables merging, 1- 3
overview, 2- 1 reports, 1- 3
process, 2- 1 Customer Interface, 2- 1 , 3-22, 3-23
Business Information Report (BIR) source IDs of associated parties, 2- 4
Index-1
using with Bulk Import, 2- 4 Data Sharing and Security (DSS)
Customer Listing - Detail, 1- 3 using for Bulk Import, 2- 4
Customer Listing - Summary, 1- 3 data sources
Customer Profiles Report, 1- 3 viewing information from, 3-23
Customer Relationships Listing, 1- 3 Decision Support Global Data Product, 3- 4
customers Delinquency Score Global Data Product, 3- 4
description, 1- 1 DNB Global Data Products Request report
entering and maintaining, 1- 3 description, 3-25
reports, 1- 3 parameters, 3-26
DQM Batch Duplicate Identification program
description, 6- 2
D reviewing results, 6- 4
D&B DSS
automatically correcting values from, 3-14 See Data Sharing and Security (DSS)
batch loading provided files, 3-21 DUNS Numbers
contact information, 3- 3 definition, 3- 6
description, 3- 2 Enquiry, 3- 7
See also Third Party Data Integration mapped, 3- 6
investigations, 3-12 related parties, 3- 7
mapping of data elements, 3- 7 same as related DUNS Number, 3- 7
Party Merge impact, 7- 8 viewing duplicates, 3-25
rationalizing legacy data, 3-22 duplicate checking
transferring request list to, 3-21 determining merge or transfer, 7- 5
viewing information, 3-23 Duplicate Customer Report, 1- 3
D&B batch loading Duplicate DUNS report
generating request list, 3-20 description, 3-25
loading data into interface tables, 3-21 parameters, 3-25
overview, 3-18 duplicate identification batches
process overview, 3-18 defining and submitting, 6- 2
request list, 3-20 reviewing potential duplicates, 6- 4
transferring request list to D&B, 3-21 duplicate parties
D&B File Load - Pass 1 program identifying in TCA Registry, 6- 1 , 7- 8
parameters, 3-22 merging, 7- 1
D&B Flat File Upload Table Creation program duplicate party sites
parameters, 3-22 merging, 7- 1
D&B hierarchy
Enterprise Management GDP, 3- 5
examples, 5-12 E
postimport processes, 2-14 eLocations Spatial Data Integration
viewing, 5-11 overview, 4- 4
D&B Import Adapter request set Enquiry DUNS Number, 3- 7
description, 3-21 Enterprise Management Global Data Product,
impact on Import Batch to TCA Registry, 2- 8 3- 5
impact on other data loads, 2- 2 entities
parameters, 3-22 description, 1- 1 , 1- 2
prerequisites, 3-21 error tables
D&B load purging, 2-15
See D&B batch loading errors
D&B Rating Bulk Import, 2-15
definition, 3- 6 Mapping API utility, 3-14
data elements examples
description, 3- 5 D&B hierarchy, 5-12
mapping, 3- 7 Party and Customer Account Merge, 7-17
request list for D&B batch loading, 3-20 Party Merge, 7- 4
data products extensions
overview, 3- 3 merge details, 7- 2
purchasing, 3-11
Index-2
F HZ: Validate Flexfields During Import profile
file loads, 2- 2 option, 2- 5 , 2-13
financial numbers HZ_CERTIFICATIONS table
import interface tables and TCA tables, 2- 7 checking for duplicates, 7- 6
financial reports HZ_CITIZENSHIP table
import interface tables and TCA tables, 2- 7 checking for duplicates, 7- 6
Financial Standing Global Data Product, 3- 4 HZ_CODE_ASSIGNMENTS table
fuzzy keys corresponding import interface table, 2- 7
postimport processes, 2-14 Data Sharing and Security (DSS), 2- 4
HZ_CONTACT_POINTS
unique IDs for import interface tables, 2- 3
G HZ_CONTACT_POINTS table
GDP corresponding import interface table, 2- 7
See Global Data Products (GDP) Data Sharing and Security (DSS), 2- 4
Generate Request List for DNB Batch Load flexfield validations, 2- 5 , 2-13
program Source System Management (SSM) mappings,
description, 3-20 2-12
parameters, 3-20 HZ_CREDIT_RATINGS table
Generate Time Zone for Locations program corresponding import interface table, 2- 7
description, 4- 5 HZ_DNB_SOURCE_DIR directory object, 3-21
parameters, 4- 5 HZ_EDUCATION table
Generate Time Zone for Phone Numbers program checking for duplicates, 7- 6
description, 4- 5 HZ_EMPLOYMENT_HISTORY table
parameters, 4- 5 checking for duplicates, 7- 6
Global Data Products (GDP) HZ_FINANCIAL_NUMBERS table
Business Verification, 3- 3 corresponding import interface table, 2- 7
Decision Support, 3- 4 HZ_FINANCIAL_PROFILE table
Delinquency Score, 3- 4 checking for duplicates, 7- 7
Enterprise Management, 3- 5 HZ_FINANCIAL_REPORTS table
Financial Standing, 3- 4 checking for duplicates, 7- 6
Global Failure Risk Score, 3- 4 corresponding import interface table, 2- 7
overview, 3- 3 HZ_IMP_ADDRESSES_INT table
Quick Check, 3- 4 matching addresses, 2-12
viewing purchased data elements, 3-23 parent and child relationships among interface
viewing request and purchase statistics, 3-25 tables, 2- 7 , 2- 7
Global Failure Risk Score Global Data Product, primary flags, 2- 6
3- 4 tables to import into, 2- 7
group IDs HZ_IMP_ADDRESSUSES_INT table
correcting Mapping API utility errors, 3-14 parent and child relationships among interface
Load D&B Data parameter, 3-18, 3-20 tables, 2- 7
manually providing, 3-19 primary flags, 2- 6
table to import into, 2- 7
HZ_IMP_CLASSIFICS_INT table
H primary flags, 2- 6
hierarchical relationships table to import into, 2- 7
description, 5- 3 HZ_IMP_CONTACTPTS_INT table
HZ: Allow Import of Records with Disabled parent and child relationships among interface
Lookups profile option, 2-13 tables, 2- 7
HZ: Allow Updates of Address Records During primary flags, 2- 6
Import profile option, 2-12 table to import into, 2- 7
HZ: Character Value to Indicate NULL During HZ_IMP_CONTACTROLES_INT table
Import profile option, 2- 5 parent and child relationships among interface
HZ: Date Value to Indicate NULL During Import tables, 2- 7
profile option, 2- 5 table to import into, 2- 7
HZ: Numeric Value to Indicate NULL During HZ_IMP_CONTACTS_INT table
Import profile option, 2- 5 parent and child relationships among interface
HZ: Use Data Sharing and Security During tables, 2- 7
Import profile option, 2- 4 tables to import into, 2- 7
Index-3
HZ_IMP_CREDITRTNGS_INT table Source System Management (SSM) mappings,
table to import into, 2- 7 2-12
HZ_IMP_ERRORS table, 2-15 unique IDs for import interface tables, 2- 3
HZ_IMP_FINNUMBERS_INT table HZ_PERSON_INTEREST table
parent and child relationships among interface checking for duplicates, 7- 6
tables, 2- 7 HZ_PERSON_LANGUAGE table
table to import into, 2- 7 checking for duplicates, 7- 6
HZ_IMP_FINREPORTS_INT table HZ_PERSON_PROFILES table
parent and child relationships among interface corresponding import interface table, 2- 7
tables, 2- 7 HZ_REFERENCES table
table to import into, 2- 7 checking for duplicates, 7- 7
HZ_IMP_PARTIES_INT table HZ_RELATIONSHIPS table
parent and child relationships among interface corresponding import interface tables, 2- 7
tables, 2- 7 Data Sharing and Security (DSS), 2- 5
tables to import into, 2- 7 flexfield validations, 2- 5 , 2-13
HZ_IMP_RELSHIPS_INT table HZ_SECURITY_ISSUED table
tables to import into, 2- 7 checking for duplicates, 7- 6
HZ_INDUSTRIAL_REFERENCE table HZ_WORK_CLASS table
checking for duplicates, 7- 6 checking for duplicates, 7- 6
HZ_LOCATIONS table
corresponding import interface table, 2- 7
creating parties with D&B information, 3- 8 I
flexfield validations, 2- 5 , 2-13 Import Batch De-Duplication report
updating with spatial data, 4- 4 description, 2- 9
HZ_ORG_CONTACT_ROLES table parameter, 2-10
corresponding import interface table, 2- 7 part of Bulk Import process, 2- 1
HZ_ORG_CONTACTS table previewing batch de-duplication results, 2-10,
corresponding import interface tables, 2- 7 2-11
Source System Management (SSM) mappings, Import Batch to TCA Registry program
2-12 creating new parties for D&B rationalized
unique IDs for import interface tables, 2- 3 legacy data, 3-22
HZ_ORG_PROFILES table description, 2- 8
corresponding import interface table, 2- 7 importing corrected records, 2-15
HZ_ORGANIZATION_INDICATORS table importing D&B information, 3-19
checking for duplicates, 7- 6 parameters, 2- 8
HZ_ORGANIZATION_PROFILES table prerequisites, 2- 8
creating parties with D&B information, 3- 8 process, 2-10
HZ_PARTIES table when cannot run, 2- 2
corresponding import interface tables, 2- 7 import batches
Data Sharing and Security (DSS), 2- 4 batch IDs, 2- 2
flexfield validations, 2- 5 , 2-13 D&B, 3-21
Source System Management (SSM) mappings, description, 2- 2
2-12 purging, 2-15
unique IDs for import interface tables, 2- 3 import errors
HZ_PARTY_INTERFACE table resolving, 2-15
loading D&B data, 3-14 import validations, 2-13
loading D&B data using SQL*Loader, 3-19 insert through Bulk Import
status values, 3-13 description, 2- 4
transferring data from, 3-18 determining, 2-11
HZ_PARTY_INTERFACE_ERRORS table, 3-14, interface tables
3-14, 3-16, 3-17 list of each with corresponding TCA tables,
HZ_PARTY_SITE_USES table 2- 6
corresponding import interface table, 2- 7 loading for Bulk Import, 2- 2
HZ_PARTY_SITES table parent and child relationships, 2- 7
corresponding import interface table, 2- 7 purging, 2-15
creating parties with D&B information, 3- 8 unique IDs for Bulk Import, 2- 3
Data Sharing and Security (DSS), 2- 4 investigations
requesting, 3-12
Index-4
L O
legacy data OCO
importing, 2- 1 See Oracle Customers Online (OCO)
rationalizing by D&B and loading, 3-22 online purchasing
Load D&B Data program loading corrected D&B data, 3-18
description, 3-18 overview, 3- 8
importing corrected D&B data, 3-14 process, 3- 9
parameters, 3-18 requesting investigations, 3-12
prerequisites, 3-18 resolving errors and manually importing data,
local activity codes 3-14
validations, 3-17 searching TCA Registry, 3-10
Local Business IDs, 3- 6 searching the D&B database, 3-10
locations selecting data products or BIRs, 3-11
description, 1- 1 Oracle Customer Data Hub (CDH)
generating time zones for, 4- 5 description, 1- 2
overview, 4- 1 Oracle Customer Data Librarian (CDL)
description, 1- 2
file loads, 2- 2
M purging parties, 1- 3
mapped DUNS Number, 3- 6 resolving duplicates from Customer Interface,
Mapping API utility 2- 1
automatic correction of D&B values, 3-14 System Duplicate Identification batches, 2- 9 ,
correcting errors, 3-14 2-11
description, 3-13 Oracle Customer Data Management (CDM), 1- 2
mapping records Oracle Customers Online (OCO)
determining insert or update for Bulk Import, description, 1- 2
2-11 file loads, 2- 2
match rules Oracle eLocations, 4- 4
for batch de-duplication, 2- 9 Oracle Trading Community Architecture (TCA)
for Registry de-duplication, 2- 9 administering and implementing, 1- 3
merge batches overview, 1- 1
creating, 7- 8 using, 1- 3
description, 7- 1 Organization Profile entity
organization contacts, 7-12 description, 1- 2
parties, 7-10
party relationships, 7-11
party sites, 7-10 P
party sites within a party, 7-13 Parent Bankruptcy Chapter Conversion, 3- 6
previewing results, 7-14 parties
processing, 7-14 description, 1- 1
submitting, 7-14 enriching with third party data, 3- 1
submitting from batch duplicate identification, identifying duplicates, 6- 1
6- 7 import interface tables and TCA tables, 2- 7
viewing profile information, 7-12 importing, 2- 1
merge-from parties managing relationships among, 5- 1
deleting after merge, 7- 8 merging, 7- 1
description, 7- 2 Party Contacts relationship group, 7-12
viewing profile information, 7-12 Party Merge
merge-to parties and Customer Account Merge, 7-17
description, 7- 2 example, 7- 4
viewing profile information, 7-12 example with Customer Account Merge, 7-17
impact on D&B data, 7- 8
merging versus transferring, 7- 5
N overview, 7- 1
navigation paths, B- 1 See also merge batches
null values process, 7- 2
updating with Bulk Import, 2- 5 source ID impact, 7- 7
Party Merge process
Index-5
description, 7- 1 D&B Flat File Upload Table Creation, 3-22
identifying errors, 7-17 DQM Batch Duplicate Identification, 6- 2
parameter, 7-15 Generate Request List for DNB Batch Load,
program description, 7-14 3-20
reviewing log, 7-15 Generate Time Zone for Locations, 4- 5
party names Generate Time Zone for Phone Numbers, 4- 5
postimport processes, 2-14 Import Batch to TCA Registry, 2- 2 , 2- 8 , 2-15,
party numbers 3-19, 3-22
maintaining uniqueness during Bulk Import, list of, A- 1
2- 5 Load D&B Data, 3-14, 3-18
party site numbers Party Merge, 7- 1 , 7-14
maintaining uniqueness during Bulk Import, Spatial Information for Locations Batch
2- 5 Update, 4- 4
party sites TCA Import Batch Purge, 2-15
description, 1- 1 TCA Import Postprocessing, 2-14, 2-15
duplicates from Customer Interface, 2- 1
merging, 7- 3 , 7-10
merging within a party, 7-13
Q
party types Quick Check Global Data Product, 3- 4
description, 1- 1
in Relationship Manager, 5- 1 R
person names
postimport processes, 2-14 rationalized legacy data
Person Profile entity loading, 3-22
description, 1- 2 Registry de-duplication
person titles description, 2- 8
postimport processes, 2-14 Registry IDs
phone numbers description, 1- 1
generating time zones for, 4- 5 relationship date ranges
postimport processes, 2-14 changing, 5- 9
postimport errors description, 5- 3
resolving, 2-15 relationship groups
postimport processes, 2-14 description, 5- 3
preimport processes relationship hierarchies
description, 2- 8 D&B hierarchy, 5-11
primary flags description, 5- 4
description, 2- 6 viewing, 5- 9
specifying with Bulk Import, 2- 6 Relationship Manager
profile options major features, 5- 3
HZ: Allow Import of Records with Disabled overview, 5- 1
Lookups, 2-13 process, 5- 4
HZ: Allow Updates of Address Records During relationship phrase and role pairs
Import, 2-12 description, 5- 2
HZ: Character Value to Indicate NULL During relationship phrase pairs
Import, 2- 5 See relationship phrase and role pairs
HZ: Date Value to Indicate NULL During relationship phrases
Import, 2- 5 changing, 5- 9
HZ: Numeric Value to Indicate NULL During description, 5- 2
Import, 2- 5 relationship role pairs
HZ: Use Data Sharing and Security During See relationship phrase and role pairs
Import, 2- 4 relationship roles
HZ: Validate Flexfields During Import, 2- 5 , description, 5- 2
2-13 relationship types
programs description, 5- 2
Address Validation, 4- 1 relationships
Create Merge Batch, 7- 9 changing in hierarchy, 5-14
Customer Interface, 3-22, 3-23 creating, 5- 7
D&B File Load - Pass 1, 3-22 editing, 5- 9
Index-6
ending, 5- 9 staged schema
import interface tables and TCA tables, 2- 7 postimport processes, 2-14
merging, 7-11 staging tables
overview, 5- 2 purging, 2-15
postimport processes, 2-14 standard navigation paths, B- 1
searching for parties to manage, 5- 6 System Duplicate Identification (SDI) batches
viewing, 5- 7 creating from Registry de-duplication, 2- 9 ,
viewing information for parties, 5- 6 2-11
reports
Customer Listing - Detail, 1- 3
Customer Listing - Summary, 1- 3
T
Customer Profiles, 1- 3 tables
Customer Relationships Listing, 1- 3 HZ_CERTIFICATIONS, 7- 6
DNB Global Data Products Request, 3-25 HZ_CITIZENSHIP, 7- 6
Duplicate Customer, 1- 3 HZ_CODE_ASSIGNMENTS, 2- 4 , 2- 7
Duplicate DUNS, 3-25 HZ_CONTACT_POINTS, 2- 3 , 2- 4 , 2- 5 , 2- 7 ,
Import Batch De-Duplication, 2- 1 , 2- 9 , 2-10, 2-12, 2-13
2-11 HZ_CREDIT_RATINGS, 2- 7
list of, A- 1 HZ_EDUCATION, 7- 6
TCA Import Error, 2-15 HZ_EMPLOYMENT_HISTORY, 7- 6
request sets HZ_FINANCIAL_NUMBERS, 2- 7
D&B Import Adapter, 2- 2 , 2- 8 , 3-21 HZ_FINANCIAL_PROFILE, 7- 7
responsibilities HZ_FINANCIAL_REPORTS, 2- 7 , 7- 6
Trading Community Manager, 1- 3 , 1- 3 , B- 1 HZ_IMP_ADDRESSES_INT, 2- 6 , 2- 7 , 2- 7 ,
2- 7 , 2-12
HZ_IMP_ADDRESSUSES_INT, 2- 6 , 2- 7 , 2- 7
S HZ_IMP_CLASSIFICS_INT, 2- 6 , 2- 7
SIC codes HZ_IMP_CONTACTPTS_INT, 2- 6 , 2- 7 , 2- 7
validations, 3-17 HZ_IMP_CONTACTROLES_INT, 2- 7 , 2- 7
Single Source of Truth (SST) HZ_IMP_CONTACTS_INT, 2- 7 , 2- 7
displaying third party data, 3- 1 HZ_IMP_CREDITRTNGS_INT, 2- 7
making D&B information available for, 3-19, HZ_IMP_ERRORS, 2-15
3-19 HZ_IMP_FINNUMBERS_INT, 2- 7 , 2- 7
viewing, 3-24 HZ_IMP_FINREPORTS_INT, 2- 7 , 2- 7
source IDs HZ_IMP_PARTIES_INT, 2- 7 , 2- 7
description, 7- 7 HZ_IMP_RELSHIPS_INT, 2- 7
DUNS Numbers, 3- 6 HZ_INDUSTRIAL_REFERENCE, 7- 6
importing associated accounts, 2- 4 HZ_LOCATIONS, 2- 5 , 2- 7 , 2-13, 3- 8 , 4- 4
unique IDs for import interface tables, 2- 3 HZ_ORG_CONTACT_ROLES, 2- 7
Source System Management (SSM) HZ_ORG_CONTACTS, 2- 3 , 2- 7 , 2-12
determining insert or update for Bulk Import, HZ_ORG_PROFILES, 2- 7
2-11 HZ_ORGANIZATION_INDICATORS, 7- 6
impact on D&B data, 3- 6 HZ_ORGANIZATION_PROFILES, 3- 8
unique IDs for import interface tables, 2- 3 HZ_PARTIES, 2- 3 , 2- 4 , 2- 5 , 2- 7 , 2-12, 2-13
spatial data HZ_PARTY_INTERFACE, 3-13, 3-14, 3-18, 3-19
acquiring, 4- 4 HZ_PARTY_INTERFACE_ERRORS, 3-14, 3-14,
description, 4- 4 3-16, 3-17
Spatial Information for Locations Batch Update HZ_PARTY_SITE_USES, 2- 7
program HZ_PARTY_SITES, 2- 3 , 2- 4 , 2- 7 , 2-12, 3- 8
description, 4- 4 HZ_PERSON_INTEREST, 7- 6
parameters, 4- 4 HZ_PERSON_LANGUAGE, 7- 6
SQL*Loader HZ_PERSON_PROFILES, 2- 7
loading D&B file, 3-19 HZ_REFERENCES, 7- 7
SQL/ETL load, 2- 2 HZ_RELATIONSHIPS, 2- 5 , 2- 5 , 2- 7 , 2-13
SSM HZ_SECURITY_ISSUED, 7- 6
See Source System Management HZ_WORK_CLASS, 7- 6
SST tax assignments
See Single Source of Truth (SST) postimport processes, 2-14
Index-7
TCA viewing information from data sources, 3-23
See Oracle Trading Community Architecture time zones
TCA Import Batch Purge program generating for locations, 4- 5
description, 2-15 generating for phone numbers, 4- 5
parameters, 2-15 postimport processes, 2-14
TCA Import Error report Trading Community Architecture
description, 2-15 See Oracle Trading Community Architecture
TCA Import Postprocessing program Trading Community Manager responsibility, 1- 3 ,
description, 2-14 1- 3 , B- 1
parameters, 2-14 transferring party sites, 7- 3
resolving errors, 2-15
TCA Registry
description, 1- 1 U
Third Party Data Integration, 3- 1 unique IDs for interface tables, 2- 3 , 2-11
See also D&B update through Bulk Import
See also D&B batch loading description, 2- 4
See also online purchasing determining, 2-11
creating parties with D&B information, 3- 8
DNB Global Data Products Request report, 3-25 V
Duplicate DUNS report, 3-25
loading rationalized legacy data, 3-22 validation status codes, 4- 3
overview, 3- 1 validations
Source System Management impact, 3- 6 Bulk Import, 2-13
Index-8
Index-9

TCA

Uploaded by

Copyright:

Available Formats

TCA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TCA

Uploaded by

Copyright:

Available Formats

Oracle® Trading Community Architecture

Part No. B12310-03

Copyright © 2002, 2005, Oracle. All rights reserved.

Primary Author: Essan Ni

Contributing Author: Charlie Ahern

U.S. GOVERNMENT RIGHTS

Send Us Your Comments

3 Third Party Data Integration

4 Locations and Phones

6 Batch Duplicate Identification

A Reports and Processes

B Standard Navigation Paths

Oracle Trading Community Architecture User Guide, Release 11i

TTY Access to Oracle Support Services

Accessibility of Code Examples in Documentation

Accessibility of Links to External Web Sites in Documentation

Guides Related to All Products

Guides Related to This Product

Installation and System Administration

Other Implementation Documentation

Do Not Use Database Tools to Modify Oracle Applications Data

This chapter provides an overview of using Oracle Trading Community Architecture.

Introduction to Oracle Trading Community Architecture

Entities and Attributes Details

Oracle Customer Data Management

1-2 Oracle Trading Community Architecture User Guide

1-4 Oracle Trading Community Architecture User Guide

Bulk Import Overview

Bulk Import Process

Bulk Import 2-1

Loading Data into the Interface Tables

2-2 Oracle Trading Community Architecture User Guide

Unique IDs for Interface Table Records

Bulk Import 2-3

Inserts and Updates

2-4 Oracle Trading Community Architecture User Guide

Null Values for Update

Party and Party Site Numbers

Bulk Import 2-5

2-6 Oracle Trading Community Architecture User Guide

Addresses HZ_IMP_ADDRESSES_INT HZ_LOCATIONS

Address Uses HZ_IMP_ADDRESSUSES_ HZ_PARTY_SITE_USES

Classifications HZ_IMP_CLASSIFICS_INT HZ_CODE_ASSIGNMENTS

Credit Ratings HZ_IMP_CREDITRTNGS_ HZ_CREDIT_RATINGS

Contact Points HZ_IMP_CONTACTPTS_INT HZ_CONTACT_POINTS

Financial Numbers HZ_IMP_FINNUMBERS_INT HZ_FINANCIAL_NUMBERS

Financial Reports HZ_IMP_FINREPORTS_INT HZ_FINANCIAL_REPORTS

Parties HZ_IMP_PARTIES_INT HZ_PARTIES

Relationships HZ_IMP_RELSHIPS_INT HZ_RELATIONSHIPS

Contacts HZ_IMP_CONTACTS_INT HZ_RELATIONSHIPS

Contact Roles HZ_IMP_CONTACTROLES_ HZ_ORG_CONTACT_ROLES

Interface Table Parent and Child Relationships

Bulk Import 2-7

Import Batch to TCA Registry

Import Run Options

2-8 Oracle Trading Community Architecture User Guide

Run Batch De-Duplication

Batch De-Duplication Match Rule

Action to Take on Duplicates

Run Address Validation