Oracle Cloud offers a broad portfolio of software as a service applications, platform as a service, and social capabilities, all on a subscription basis. Oracle Cloud delivers instant value and productivity for end users, administrators, and developers alike through functionally rich, integrated, secure, enterprise cloud services.
 Get a Free Magzine ...Profit:The Executive's Guide to Oracle Applications

Subscribe to the OracleAppsHub to receive notifications when there are new posts:

 get RSS feed
 Oracle Fusion Applications (OFA) is a portfolio of next generation suite of software applications from Oracle Corporation. It is distributed across various product families; including financial management, human capital management, customer relationship management, supply chain management, procurement, governance, and project portfolio management
 Get a Free Magzine ...Profit:The Executive's Guide to Oracle Applications

TCA & Business Objects

Posted on August 19th, 2011 by Sanjit Anand ||Email This Post Email This Post

Do you know In R12 , there is New Public API’s for Business Objects, which can be used with a single API call. This Covers a total of 16 objects
of 4 Composite objects as

  • Person
  • Organization
  • Person Customer
  • Organization Customer

It also covers granular objects like Customer Account, Address etc.

There are four action avaiable in these API’s as Create / Update / Save / Get
This provides API’s to Map Business objects in TCA to Source system identifier of other systems.

Public API for logical Person is HZ_PERSON_BO_PUB

  • create_person_bo – Creates person related elements
  • update_person_bo – Updates person related elements
  • save_person_bo – Saves person related elements
  • get_person_bo – Retrieves person related elements

where as Person Customer API is HZ_PERSON_CUST_BO_PUB

Public API for logical Organization is HZ_ORGANIZATION_BO_PUB

Public API for Organization Customer is HZ_ORG_CUST_BO_PUB

There is Business Object Events which can be used to notify the Spoke/custom systems for updates done to TCA data.

Posted in Oracle TCA | No Comments »

What Is Extensible Attribute Architecture?

Posted on June 13th, 2011 by Sanjit Anand ||Email This Post Email This Post

Extensibility framework and features basically comes from Oracle Product Lifecycle Management (PLM).

Extensible Attributes are similar to DFF’s in the sense that Extensible Attributes feature provides out-of-the box capability to store additional information associated with certain EBS modules entities.In the past, Oracle Descriptive FlexFields (DFF) had a limitation of 15 or 22 data fields per record. There is no limit for Extensible attributes.

The functionality allows you to view and maintain these additional attributes without having to create custom screens. It also allow you to group related attributes and display attributes on specific UI pages.

dgreybarrow R12 Extensible Attributes –What are they?

  • Extensible attributes add additional rows or records into the database structure and therefore are limitless.
  • Extensible attributes can contain one single record (of numerous extended. data fields) or multiple record
  • The extended database fields have four data types to choose from and can contain list of value (LOV) definitions for data consistency (entry and reporting) and can control record inserts to be based upon uniqueness (no duplicates)

dgreybarrow In Comparison to Descriptive FlexFields (DFF)

Here are the quick comparision with DFF.

Extensible Attribute

dgreybarrow Some of the features are

  • Limited to certain EBS modules entities.
  • Attributes can be displayed as text, check box or radio group.
  • Database view is created for each attribute group.
  • Uses Value Set for attribute validation.
  • Extensible Attributes store unlimited number of repeating attributes (multiple rows of similar data), unlike Descriptive Flexfields.

dgreybarrowComponents of an extension:

  • Attribute Group
  • Attributes
  • Associations
  • Pages
  • Functions
  • Actions
  • Value Sets (Recommend creating before attribute groups)

Extensible entities have corresponding tables to store additional attributes.

For example, in the case of Teleservice some of the tables are CS_INCIDENTS_EXT_B, CS_INCIDENTS_EXT_AUDIT, etc.

If customer wants to use Extensible Attributes in Oracle Loans then you need to check with Loans Development to see if they implemented or not Extensibility framework.

Will see more details for TCA Extensible Attributes, in next post.

Posted in AOL, Oracle TCA | No Comments »

TCA : Party Purge API

Posted on January 30th, 2011 by Sanjit Anand ||Email This Post Email This Post

Looking for API which can delete desired party record completely.. use this API which can be used to Purge the Party Information from TCA Architecture.The name of the API is apps.hz_purge.purge_party.

Read the rest of this entry »

Posted in Oracle TCA | No Comments »

TCA in EBS: Integration with HRMS

Posted on October 23rd, 2009 by Sanjit Anand ||Email This Post Email This Post

dgreybarrowHRMS Integration with TCA – Concept

When the CRM Application were incorporated into EBS , there was a need to manage the relationships within the trading community of the corporation from one standard model. that why Oracle came with a complete suite of integrated modules that cover the front to back end office operation in its entirety, and therefore could uniquely provide a ‘Single Source of Truth’ mostly meant for customer information. That means , a customer record is the exact same record whether it is viewed through Oracle Sales Online, Oracle Marketing Online, Oracle Customer Care, Oracle Financials, or iStore.

The concept of ‘Party’ enables the Customer Model to treat all business entities equally. This means that regardless of the type of customer (i.e., organizations, people, groups, or relationships), each customer is handled in the same way by the data model.

As HRMS is the main application for the management of people in the e-Business Suite, it is also responsible for maintaining a corporate record of each person which is held in TCA. This corporate person record not only provides a central source of data for those applications that require basic access to the people of the enterprise, but also links all the local records for a person within Oracle HRMS itself . For example , in a Global Enterprise, a person may need to be transferred between business groups to work temporarily in other countries. That will mean records will exist for the same person in different business groups but which are identified by a common party_id linked to the corporate record in TCA.

HRMS only maintains the Person entity in TCA. It does not maintain Organizations or Locations.

dgreybarrowTCA in R12: Integration with HRMS

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

Hope this helps.

Posted in Oracle TCA | No Comments »

TCA and Web Services

Posted on March 29th, 2009 by Sanjit Anand ||Email This Post Email This Post

New CDH Web Services are based on the existing Business Object APIs of TCA;

  • Spoke applications can leverage CDH Web Services to integrate with the Customer Data Hub
  • New DQM Search Web Service to access matching in the Hub from any transactional application
  • CDH Web Services leverage the Web Service standards such as WSDL (Web Services Description Language) and UDDI (Universal Description,
    Discovery and Integration)

Here are the list of some of CDH Web Services, that you can utilize it.


Name Description
DQM Search Service DQM search service to search for parties
Organization Business Object Services Manages the Organization business object
Organization Customer Business Object Services Manages the Organization Customer business object
Organization Contact Business Object Services Manages the Organization Contact business object
Person Business Object Services Manages the Person business object
Person Customer Business Object Services Manages the Person Customer business object
Party Site Business Object Services Manages the Party Site business object
Location Business Object Services Manages the Location business object
Phone Business Object Services Manages the Phone business object
Email Business Object Services Manages the Email business object
Web Business Object Services Manages the Web business ob
Relationship Business Object Services Manages the Relationship business object

Posted in MDM, Oracle TCA | No Comments »

Implementation Options: Customer Data Hub (CDH)

Posted on March 24th, 2009 by Sanjit Anand ||Email This Post Email This Post

Read this for more information on Customer Data Hub (CDH).

Customer Data Hub (CDH) can be implemented in multiple ways. There are three main instance strategy options that organizations can often consider when implementing the Oracle Customer Data Hub. these three options are industry accepted are:

  1. E-Business Suite as Hub to 3rd Party Systems
  2. Customer Data Hub Integrated with E-Business Suite and 3rd Party Systems
  3. Customer Data Hub with no E-Business Suite

While Oracle Customer Data Hub provides the technology base for meeting the business problem, correct implementation strategy and tools are important to ensure complete solution for implementing organizations and meet specific requirements of each customer.


With this option, customers can easily leverage their existing E-Business Suite footprint to include the functionality of a Customer Data Hub with integration to heterogeneous 3rd party systems.

Given that E-Business Suite applications are built on the TCA oganizations running the E-Business Suite already store customer data in TCA.Therefore, in order to make the TCA customer data sync with the customer data residing in disparate systems, the implementing organization will need to leverage twith integration or middleware technology, and the Source Systems Management capabilities within the TCA infrastructure. If implementing company use Customer Data Librarian to keep the customer data clean and duplicate-free.That would be best case of either side.


  • Existing customer data is migrated one time from 3rd party systems and is continually kept in sync.
  • In line with the single-global-instance vision, thereby lowering costs and increasing benefits.
  • Allows implementing organizations to sunset any legacy application at any time.
  • All customer data resides in operational, transactional E-Business Suite. Therefore, customer information is actionable in real-time.


  • Potentially longer initial implementation timeframe given more complexities in maintaining single source of customer truth within the operational data system.


With this option, customers are able to implement the Customer Data Hub more rapidly and begin realizing immediate benefits by integrating the Hub with existing E-Business Suite and 3rd party transactional systems.

In this model, the Oracle Customer Data Hub is installed as the central repository of customer data, and is integrated with the existing E-Business Suite footprint as a source system, in the same fashion that 3rd party legacy systems are integrated. By mapping the E-Business Suite as a spoke system to the Customer Data Hub, implementing organizations are able to get the Hub up-and-running in parallel with their operational business systems, without spending extensive time on transactional business flow integration testing. In addition, this methodology allows implementing organizations to refine their single source of customer truth over time, and eventually cut over to the ‘single instance model’ when appropriate.

Just as with any other spoke system mapping, it is required that organizations use the Oracle AS 10g integration services (or other third party middleware), and the Source Systems Management capabilities within TCA to keep customer information in sync across all systems, including the E-Business Suite. In addition, implementing organizations will use Customer Data Librarian to keep the customer data clean and duplicate-free.


  • Shorter initial implementation timeframe given less complexities in maintaining the CDH separate from operational systems.
  • Minimal risk of adversely impacting customer data which could impede business and transactional processes.
  • Allows implementing organizations to migrate to the single instance model at their own pace, while still taking advantage of a single source of customer reality.
  • Allows implementing organizations to patch the CDH with latest functionality without risk of impacting the existing E-Business Suite footprint.


  • Additional spoke system created with this model, rather than reduction of systems. Therefore, additional integration development is required.
  • Customer data migrated to Customer Data Hub initially, and then a second effort is required to sync the Customer Data Hub with the E-Business Suite when consolidation occurs in the future.


Of course, customers who are not running any E-Business Suite applications at all can also implement the Customer Data Hub.

In this case, the Hub is implemented as the central source of customer truth, and is integrated with all heterogeneous 3rd party systems.


  • Allows implementing organizations to begin realizing the value of the E-Business Suite functionality, even before they have the E-Business Suite up and running.
  • Allows implementing organizations to plug in pieces of the E-Business Suite at their own pace, or keep legacy systems living on if migrating to the E-Business Suite is not an option.
  • Provides an easy migration path to single global instance vision.


  • Continued costs (IT and personnel) associated with maintaining disparate systems, with different technologies and platforms.

These three implementation options will helps to find the main instance strategy options which is major task considered when implementing the Oracle Customer Data Hub.

Posted in Oracle TCA | No Comments »

What is Oracle Customer Data Hub (Oracle CDH)

Posted on March 23rd, 2009 by Sanjit Anand ||Email This Post Email This Post

Oracle Customer Data Hub is a comprehensive set of services, utilities and applications to create and maintain a single source of truth of customer identity across the company. CDH allows organizations to have consolidated customer data from heterogeneous systems in a central location and establishing enterprise-wide data quality. Oracle CDH is an application with middleware services which can be deployed in any IT infrastructure.

In short,Customer data hub consolidates following concepts under one umbrella to provide a single view of the customers

  • Customer Data Business Strategy
  • Customer Data Architecture
  • Customer Data Integration
  • Customer Data Governance
  • customer Data Analysis

The Customer Data Hub is a bundling of architecture and application elements that work together to provide a clean and reliable central and shared repository of customer data across Oracle and non-Oracle systems. It has following three layers.

  • Architecture: Oracle’s Trading Community Architecture (TCA) provides the basis for the Customer Data Hub.
  • Applications: Oracle Customers Online, the application provides the “window” into the Customer Data Hub’s centrally stored data and Oracle Customer Data Librarian, a data quality application, plays a central role in cleansing, enriching and maintaining party data.
  • Integration: The final element that brings the Customer Data Hub together is the integration layer that links the Customer Data Hub to the “spoke” systems. A spoke system is defined as a source of information that is providing or synchronizing information with the Customer Data Hub on a regular basis


Oracle’s Trading Community Architecture (TCA) provides the basis for the Customer Data Hub. TCA is made up of two core elements: the database schema and the enabling infrastructure.

The TCA database schema is the repository for all party related data (a party may be an organization, a person, a buying consortium, a contact, a supplier, a partner, or any other person or organization with which you do business), including profile characteristics of a party (who/what they are), what their association/relationship with other parties is, where they are located, what the locations are used for, how to get in touch with them, how they are classified and more.

The TCA enabling infrastructure is an intermediary between the business applications that wish to utilize the data stored in TCA (whether they are Oracle eBusiness Suite applications or other systems) and the schema itself. The enabling infrastructure is meant to ensure that the data that is entered into, or extracted from, the database tables is done in a uniform manner, ensuring consistent data quality. This infrastructure takes the form of:

  • Public APIs which ensure the integrity of the data entered into and retrieved from the database tables.
  • Data Quality Management (DQM) tools which use sophisticated match rules to detect and/or resolve potential duplicate data.
  • Third Party Content Integration which enriches or validates party data to ensure usefulness and correctness.

dgreybarrowCDH Application Layer

Lets take a quick look on these application , which is subset or can be work standalone.

1. Oracle Customers Online provides the tools and functionality to:

  • Set-up and maintain Party Relationships, Party Classifications, Data Quality Management (DQM rules)
  • Create, view and update party information
  • Upload flat data files for import into TCA.

2. Oracle Customer Data Librarian, a data quality application, plays a central role in cleansing, enriching and maintaining party data. Data Librarian provides the tools needed to:

  • Configure and deploy match rules for automated duplicate identification.
  • Maintain mappings between a party record in TCA and the corresponding record(s) in one or more third party systems.
  • Identify potential duplicate records, and take action to merge those records together with a mix of the best attribute values from the records to be merged.
  • Purge party records from the TCA database.
  • Manage party active/inactive status.
  • Control party merge at the attribute, relationship and address levels.

3. Oracle DQM

Oracle Data Quality Management, a highly configurable engine which is used to setup match rules, attributes and resolution set rules.

  • Prevent, Identify and Resolve Duplicates
  • Synchronize Consistent Data
  • Match Rules
  • Smart Search

Next post , we will see the CDH Implementation Options and more on Oracle Data Librarian with some real time senarios

Posted in Oracle TCA | No Comments »

Its all about TCA API

Posted on December 20th, 2008 by Sanjit Anand ||Email This Post Email This Post

As you read some of my earlier post, its already known to you the TCA is an architecture that allows you to model and manage an electronic representation of the commercial community in which you do business.Trading Community Architecture (TCA) is literally an architecture designed to support complex trading communities which included in the TCA.Therefore in layman language this is:

  • A comprehensive database schema.
  • A set of public APIs for custom development.
  • Integration with 3rd party content providers for data enrichment.
  • A sophisticated set of data management utilities to keep the registry clean

The next question you might have how to get data Data Into TCA.

There are two ways recommended for getting the data into the TCA data model.They are

  • CRM and ERP/AR applications through Using the “Customer Interface Program”.
  • Application Programming Interfaces (APIs).

dgreybarrow Meeting Business Needs:

Programmatic access to the TCA Data model should go only if these are business needs:

  • Applications in the Oracle E-Business Suite can use the TCA public APIs to insert and update entities in the TCA model, as part of server side and middle tier business logic.
  • APIs provide a gateway to the TCA data model from applications that use Forms 6.0/9.0 user interfaces (UIs) as well as from HTML UIs.
  • Data migration from legacy systems into the TCA model.

dgreybarrow Important features of the Version 2 TCA API’s:

  • Flexible, easy to understand, and modular.
  • Extensive debugging capability.
  • Extensive error handling and reporting capability.
  • Robust validation in all of the APIs.
  • A ne locking mechanism based on the OBJECT_VERSION_NUMBER field,which has been included in all of the HZ entities for which the public APIs have been provided.
  • Standard signature and availability of common parameters.

dgreybarrow Categories of Entities Covered in TCA APIs:

The following are main categories of entities that are covered in TCA APIs :

  • Parties – Person, Organization, Relationship, Group
  • Locations, Party Sites, Party Site Uses
  • Contact Points
  • Customer Accounts, Account Sites and Site Uses
  • Relationships
  • Relationship, Relationship types
  • Classification

dgreybarrow APIs available for Trading Community Architecture:

Following are Some of the Important APIs Available for Trading Community Architecture.

  • Party APIs:
    • Create Organization API
    • Create Person API
    • Create Group API
  • Party Contact APIs:
    • Create Org Contact API
    • Update Org Contact API
  • Location APIs:
    • Create Location API
    • Update Location API
  • Party Site APIs:
    • Create Party Site API
    • Create Party Site Use API
  • Contact Point APIs:
    • Create Contact Point API (Person or Organization)
  • Relationship Type API:
    • Create Relationship Type API
  • Relationship API:
    • Create Relationship API
  • Customer Account APIs:
    • Create Customer Account API (Person or Organization)
    • Update Customer Account API
  • Customer Account Site APIs:
    • Create Customer Account Site API
    • Create Customer Account Site Use API
  • Customer Profile APIs:
    • Create Customer Profile API
    • Update Customer Profile API
  • Classification API:
    • Create Class Category API
    • Create Code Assignment API
  • Tax Assignment API:
    • Create Location Assignment API

You can check my old post for getting information for TCA tables structure to see how data get populated.

Posted in Oracle TCA | No Comments »

Dissecting TCA Architecture

Posted on November 10th, 2008 by Sanjit Anand ||Email This Post Email This Post

Before start , you try to understand the a Typical Business model as per figure below then you can able to understand the TCA Data Architecture easily.



dgreybarrow Hz_Parties

Information Stored

  • The HZ_PARTIES stores information about parties such as organizations, people, and groups, including the identifying address information for the party.Several pieces of data, such as the identifying address, organization profile information, and person profile information, are denormalized onto this table for performance reasons.Although a record in the HZ_PARTIES table represents a unique party, multiple parties can have the same name.
  • The identifying address contained in the HZ_PARTIES table is denormalized from the HZ_LOCATIONS table.
  • Example, It stores the information about Hub Inc. as Party_Relationship, Hub Corp. as Organization and Mike as Person

dgreybarrow Hz_Person_Profiles

Information Stored

  • The HZ_PERSON_PROFILES stores detail information about people (including demographic information, phonetic name pronunciation, academic/professional titles,
  • Some of the information stored on this table is denormalized to the HZ_PARTIES table.
  • Example, It stores complete details about Mike.

dgreybarrow Hz_Organization_Profiles

Information Stored

  • The HZ_ORGANIZATION_PROFILES table stores a variety of information about a party. This table gets populated when a party of the Organization type is created.This table stores credit rating, financial statistics, socio-economic and corporate linkage information for organizations.Each time organization information is changed, the effective end date column for the original record is updated and a new record that contains the updated information is created.Some of the information stored on this table is denormalized to the HZ_PARTIES table.
  • Example, it stores complete details about the Hub Corp Organization.

dgreybarrow Hz_Person_Language

Information Stored

  • Hz_Person_Language table stores information about a language spoken by a party of the Person type.
  • Example, Mike may speak Spanish as his primary language. You would create another record if he speaks French, but it is not his primary language. Note that a separate record must exist for each language.

dgreybarrow Hz_Relationships

Information Stored

  • Hz_Relationships table stores information about relationships between one party and another party. The SUBJECT_ID and OBJECT_ID columns specify the relationship that exists between two parties.

Linking Details

  • Subject_id is stored in the party id of Hz_Parties when the party type of Hz_Parties is person.
  • Object id is stored in party of Hz_Parties when the party type of Hz_Parties is Organization.


The HZ_RELATIONSHIP_TYPES table defines the business rules that are associated with a relationship type. A non-directional relationship type consists of a single record with the same forward (FORWARD_REL_CODE) and backward (BACKWARD_REL_CODE) relationship codes. A directional relationship type consists of two records: one for the parent (DIRECTION_CODE is P) and the other for a child (DIRECTION_CODE is C) of that parent. Forward and backward relationship codes are validated against the PARTY_RELATIONS_TYPE lookup type.

dgreybarrow Hz_Party_Relationships

Information Stored

  • Hz_Party_Relationships table stores parent – child information and the relationship between them.
  • Example, It stores information about the Hub Inc with the subject as John and Object as Hub Corp and relationship as Employee of.

Linking Details

  • Subject_id is stored in the party id of Hz_Parties when the party type of Hz_Parties is person.
  • Object id is stored in party of Hz_Parties when the party type of Hz_Parties is Organization.

dgreybarrow Hz_Org_Contacts

Information Stored

  • Hz_Org_Contacts table stores information about the position of the contact for a party or party site. The records in this table provide information about a contact position such as JOB_TITLE,DEPARTMENT_CODE and general contact information.
  • This table is not used to store information about a specific person or organization, such as name and identification codes, that information in stored in the HZ_PARTIES table.
  • Example, this table may include a record for the position of vice president of manufacturing that indicates that the contact is a senior

Linking Details

  • HZ_RELATIONSHIPS is the ‘parent table’ to HZ_ORG_CONTACTS (i.e. 1-to-Many) but there is a Many to-1 relationship enforced in the API. That is, inserting a row into HZ_ORG_CONTACTS will insert two rows into HZ_RELATIONSHIPS table One row is inserted for the relationship and another one for the reciprocal relationship.
  • Example “Mike Employee of Hub Corp.” and “Hub Corp. Employer of Mike”.


Information Stored

  • Hz_Org_Contact_Roles stores information about the role of the contact position that is specified in the Hz_Org_Contacts table. Contacts may have multiple roles.
  • Example an employee may have a role a Manager, Assistant etc

dgreybarrow Hz_Party_Sites

Information Stored

  • Hz_Party_Sites table stores location specific party information. One party can Optionally have one or more party sites.
  • Example, It stores SFO and LA as sites for the party Hub Corp..

dgreybarrow Hz_Party_Site_Uses

Information Stored

  • Hz_Party_Site_Uses table stores information about how a party site is used.
  • Party sites can have multiple uses for example, Bill to and Ship to uses.

dgreybarrow Hz_Locations :

Information Stored

The HZ_LOCATIONS table stores information about a delivery or postal address such as building number, street address, postal code, and directions to a location. This table provides physical location information about parties (organizations and people) and customer accounts. Records in the HZ_LOCATIONS table can store delivery and postal information about a location through columns such as the LOCATION_DIRECTIONS, POST_OFFICE,
and TIME_ZONE columns. You can also use the HZ_LOCATIONS table to store latitude and longitude information. Data in the HZ_LOCATIONS table is also used to determine the appropriate tax authority and tax rates for sales tax and VAT calculations

dgreybarrow Hz_Loc_Assignments

Information Stored

  • Hz_Loc_Assignments table stores information about the relationship between a location defined in the HZ_LOCATIONS table and a tax
    authority defined in the AR_LOCATION_COMBINATIONS table.
  • The appropriate sales tax can be calculated when you assign a location to a tax authority.
  • In a multi–org environment, a record is created for each organization at the location.

dgreybarrow HZ_CUST_ACCOUNTS

Information Stored

  • The HZ_CUST_ACCOUNTS table stores information about customer relationships established with a party. Since a party can have multiple customer accounts, this table may contain several records for a single party. For example, an individual person may establish a personal account, a family account, and a professional account for a consulting practice. Note that the focus of this table is a business relationship and how transactions are conducted in the relationship.

  • Example, When Hub Corp or Mike becomes the customer, and then their account information is stored in this table.

dgreybarrow Hz_Cust_Acct_Relate_Al

Information Stored

  • Hz_Cust_Acct_Relate_All stores information about relationships between customer accounts.
  • A flag allows you to indicate whether a relationship is reciprocal.

Linking Details


dgreybarrow Hz_Cust_Account_Roles

Information Stored

  • Hz_Cust_Account_Roles table stores information about a role or function that a party performs in relation to a customer account. Note that only Parties of type Relationship should be inserted into this table.
  • Example, Jack is an employee of Hub Corp. Jack might be a legal contact for Hub Corp. So the role type is Contact.

dgreybarrow Hz_Role_Responsibility

Information Stored

  • Hz_Role_Responsibility table stores information about the required or expected activities of a party based on the party’s role or function in relation to a customer account.
  • Example, Jack might be the first contact for Hub Corp. So the responsibility type is First Contact.

dgreybarrow Hz_Cust_Acct_Sites_All

Information Stored

  • Hz_Cust_Acct_Sites_All table stores information about customer account sites or locations for customer accounts. One customer account can have multiple sites or locations

Linking Details

  • Address information for a site is stored in Hz_Locations table. But it is linked via Hz_Party_Sites table.

dgreybarrow Hz_Cust_Site_Uses_All

Information Stored

  • Hz_Cust_Site_Uses_All table stores information about the business purposes assigned to a customer account site.
  • Example, Bill to and Ship to uses.

dgreybarrow Hz_Customer_Profiles

Information Stored

  • Hz_Customer_Profiles table stores information about the credit characteristics of a single customer account.

dgreybarrow Hz_Cust_Profile_Amts

Information Stored

  • Hz_Cust_Profile_Amts table stores information about the credit limits specified for a customer profile class for a single currency.
  • The credit limits of the profile class can then be assigned to specific customer accounts or customer account sites.

dgreybarrow Hz_Cust_Profile_Classes

Information Stored

  • Hz_Cust_Profile_Classes table stores information about credit characteristics those are common across a group of customer accounts.
  • Example, you can create a profile class called Trade and can specify several attributes that describe this class of customer. In the future, you can assign new customers to this class so that the new customer inherits the characteristics of the class.

dgreybarrow Hz_Contact_Points

Information Stored

  • Hz_Contact_Points table stores information about how to communicate to parties or party sites using electronic media or methods such as Electronic Data Interchange (EDI), e-mail, telephone, telex, and the Internet.
  • Example, telephone related data can include the type of telephone line,a touch-tone indicator, a country code, the area code, the telephone number, and an extension number to a specific handset.
  • NOTE: Each media or method should be stored as a separate record in this table.with Hz_Parties via Hz_Relationships.
  • If the party type is Person,then Hz_Contact_Points can be directly linked with Hz_Parties

Linking Details

  • If the party type is Organization, then Hz_Contact_Points is linked here.

dgreybarrow Hz_Contact_Restrictions

Information Stored

  • Hz_Contact_Restrictions table stores information about limitations on when and how parties should be contacted or why no contact should be made with the party.
  • Example, a customer contact that is on vacation for several weeks may request that no faxes be sent during a specific time period.

Posted in Oracle TCA | No Comments »

Customer Interface Vs TCA API

Posted on October 27th, 2008 by Sanjit Anand ||Email This Post Email This Post

dgreybarrow Customer Interface

Customer Interface aka RACUST is a concurrent program that is responsible for the import and update of AR customer information from open interface tables to AR Customer tables. Check out the details here.

dgreybarrowTCA Application Programming Interface (API)

TCA API’s are an integrated set of PL/SQL code designed in a highly modular fashion, that are easy to understand, maintain and extend.These are modular approach defaults and validates users who enter information, defaults information not provided by the user and calls the appropriate entity handler to perform the business related tasks.

Use of the TCA APIs allows you much more control of inserts and updates over the customer interface.


  • Customer Interface (RACUST)
    When the customer interface executes, a report is generated. You can view the output by selecting the request and then choosing View Output. Here are details for all Error code.
    The APIs provide an extensive error-handling and error-reporting mechanism whereby all errors encountered in the different phases of API execution are reported and put on the message stack. You can refer to TCA API documentation for further details.

Read the rest of this entry »

Posted in Oracle Receivable, Oracle TCA | No Comments »

« Previous Entries