,

Trading Community Architecture (TCA) in Oracle Apps

Before TCA:

  • There are multiple customer definitions across the enterprise.
  • It was very difficult to track current and historical information about the customers.
  • There was a lack of support for mixed business.
  • It was quite tough to understand relationships between customers and others (suppliers, partners, competitors).

Customers: More important than anything else!

In any business, Customers and their data are always important. More than that what is important is to understand who your customer interacts with inside and outside the enterprise.

What is Trading Community?

The summation of all entities, inclusive of partners, suppliers, and competitors, that are related to your customers is called a Trading Community.

Trading Community Architecture:

Trading Community Architecture is the implementation of technology and applications to allow users to create and maintain relationships among entities. It is a way to understand who your customer interacts with inside and outside the enterprise.

It’s Main Purpose:

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

TCA Data Model Components:

1] Party:

It represents any entity that can enter into business relationships with your organization – Organization, Person, or Group.

  • Person – A unique individual (dead or alive) of interest to the user.
  • Organization  – A legal entity recognized by some government authority.
  • Group  – A combination of two or more people, organizations or groups.

2] Party Relationship:
It is a binary relationship between two parties such as a partnership.

  • Has a Role – Specifies the nature of the relationship between parties (e.g., member of, contact at, married to).
  • Indicates the Nature of the relationship – hierarchy or matrix.
  • Indicates the Direction of the relationship – superior – subordinate.
  • Can become a Party – a Relationship becomes a party in itself.

The relationship model enables you to:

  • Understand the complex relationships among members of your trading community
  • Use this information to make better business decisions

3] Location:
A Location is a point in geographical space described by a street address. In previous releases of Oracle, there was a risk of some data redundancy if more than one customer shared the same site or location. The new model eliminates this redundancy.

  • Any number of location types can be defined. (e.g., bill-to, ship-to, mail-to).
  • There is no duplication of an address.
  • It is possible to maintain Customer History per address.
  • It is also possible to maintain Important Install Base info.

4] Party Site:
It links a Party with a Location

  • Describes the usage of that Location for the Party  (e.g., mailing address, billing address, home address, etc.).
  • Allows Parties to be associated to one or more Locations and any one Location to be associated with Parties.

5] Contact:
A Contact is a person in the context of an organization, modeled as a relationship between an organization and a person or between two people, (this can be either a party contact or an account contact).
6] Contact Point:
A Contact Point is a means of contacting a party, for example, a phone number, e-mail address, or fax number.
This can be applied to:

  • A Party (person, organization, group or relationship)
  • A Site or Location
  • A Party at a Site or Location

An entity may have one or more Contact Points.
7] Customer Account:
A Customer Account represents the business (selling) relationship that a company deploying Oracle Applications has with a party.

  • Stores details about the Financial relationship between a Party and your business.
  • A Party may have one or more Customer Accounts.

8] Customer Account Site:
A Customer Account Site is a party site that is used by a customer account, for example, for billing or shipping purposes.
9] Customer Account Contacts:
A party contact that is used as a means of contacting the customer regarding his/her account.

Parties vs. Accounts

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

New Trading Entities in R12

Below are the new entities that are merged in TCA architecture in R12.

  • Banks & Bank Branches
  • Suppliers
  • Legal Entity
/by
,

Interfaces in Oracle Application: An Introduction

What are Interfaces?

  • Interfaces are used in Oracle Applications to integrate external systems and Data Conversion.
  • The interfaces are mainly used to either transfer data from Oracle Applications to a flat file or data from legacy system to Oracle Applications.
  • Used extensively at the time of Data Conversion from legacy/ old systems to a fresh implementation of Oracle Applications.
  • Used also at regular intervals when data transfer is from other live systems if the systems are not defined in Oracle Applications implementation.
  • Oracle provides flexible and flexible tools in the form of Interface programs to import the master and transactional data like Customers, Invoices, and Sales Orders etc from external systems into Oracle Applications.

Types of Interfaces

There are two major types of Interfaces:

  • Inbound Interface : These interfaces are used to transfer data from external systems to Oracle Applications.
  • Outbound Interface :  These interfaces are used to transfer data from Oracle Applications to external systems.

Two other distinctions of Interfaces:

  • Open Interface: If the interface logic is provided by Oracle Applications, it is called an Open Interface.
  • Custom Interface: If the interface logic needs to be developed by the implementation team, it is called a Custom Interface.

Interface Components

Open Interface Logic

  • First the data from the source application is loaded into a database table (called Interface table).
  • Then the provided validation program logic validates the records whether they are correct or not .
  • If the validation fails, the errors are transferred into another table (called Error Table).
  • If the validation succeeds, the correct records are transferred through a process into the destination application table.

Components of an Interface

a] Source Application:
You obtain data from a source application to pass on to a destination application for further processing and/or storage.
b] Source Data Issues:
Type of file, Size, Frequency of upload, Record Length (Variable or fixed), Delimiter, Datatype for each field, Any unwanted data, Naming convention and uniqueness of file, Location of the file, Access on the file.
c] Destination Application:
You send data to a destination application so that the application can perform further processing and/or storage.
d] Interface Table:
For inbound interfaces, the interface table is the intermediary table where the data from your source application temporarily resides until it is validated and processed into the destination application.
e] Identifier columns:
Uniquely identify rows in the interface table provide foreign key reference to both the source and destination applications.
f] Control Columns:

  • Control columns track the status of each row in the interface table, as it is inserted, validated, rejected, processed, and ultimately deleted.
  • WHO columns are also control columns.

g] Data Columns:

  • Stores the data that is being converted.
  • Required columns store the minimum information needed by the destination application to successfully process the interface row.

h] Derived Columns:
Derived columns are created by the destination application from information in the required columns.
i] Optional Columns:
Optional columns are not necessarily required by the destination application, but can be used by the destination application for additional value-added functionality beyond the basics.
j] Error Table:

  • For inbound interfaces, the errors table stores all errors found by the validation and processing functions.
  • In some cases, the errors table is a child of the interface table. This allows each row in the interface table to have many errors, so that you can easily manage multiple errors at once.
  • In other cases, the errors are stored in a column within the interface table, which requires you to fix each error independently.

Developing an Interface

1] Identification:
Find out if there exists an Open Interface to carry out the functionality.
2] Creation of Pre-Interface table ( staging Table):
A table in the format of the data file which can be pruned to load as clean a data into the Interface table.
3] Load data into Pre-Interface table:
SQL*LOADER can be used to load the flat file into the pre-interface table.
4] Validate data in the Pre-Interface table:
Basic validation of the data loaded into the Pre-Interface table can be carried out like:

  • For checking NULL values in required columns
  • Checking for Foreign Key and Quick Code values.
  • Duplication Validation
  • Business Rule validation

5] Mapping the values:
Generated fields in Oracle Applications can be mapped in this step to either default values or sequences.
6] Load data into Interface table:

  • Once the data is as clean as you can get it, the data can be inserted into the Interface table.
  • At such a time, certain columns, which are necessary in Applications but not found in legacy system, need to be populated accordingly like WHO columns.

7] Run the interface program
8] Check for Errors
9] Report on the Interface

/by
, ,

Adding and Updating Customer Accounts in R12

Use the Customer Overview page in R12 to manage details of your existing customers. 
This page has five subtabs:

  • Accounts.
  • Profile
  • Communication
  • Party Relationships
  • Tax Profile

 Accounts:

Use the Accounts subtab of the Customer Overview page to view, add, and update the accounts of existing customers.
  • view and update an account:
  • view and update an account site
  • create an account
  • create an account site

Customer Profiles:

Use the Profile subtab of the Customer Overview page to add and update the profiles of existing customers.

Tax Registration Number

  • The customer’s unique taxpayer registration number, also known as the VAT number.
  • Oracle Receivables prints this number on customer invoices.
  • Receivables provides country-specific validation of the tax registration number.

Credit Classification

  • Displays the credit classification for a particular profile class.

Credit Analyst

  • Indicates who is responsible for monitoring the creditworthiness of the account and for assisting in the resolution of credit-related issues.

Review Cycle

  • Specifies how often to review the credit status of the customer account. For example, you can specify that the creditworthiness of the account is reviewed each month.

Customer Communication Information:

Use the Communication subtab of the Customer Overview page to enter and update contact information, such as phone numbers, e-mail addresses, and URLs, of existing customers.
Phone Numbers:

  • FAX
  • MOBILE
  • PAGER
  • TELEPHONE
  • VOICEMAIL

Email Address:

 URLs:

Party Relationships:

Use the Party Relationship subtab of the Customer Overview page to define, view, and update relationships among existing customers (parties), using predefined relationship types and roles.
Note: Relationship types and roles are defined using Oracle Trading Community Architecture Relationship Manager.

Relationship Role: Describes the role that an entity plays in a relationship.

Customer Tax Profiles:

Use the Tax Profile subtab of the Customer Overview page to set up, view, and update tax profiles for your customers.

/by
, ,

AR Tables:A Diagrammatic Relation

AR Tables:A Diagrammatic Relation

A Diagrammatic Relation between AR Tables

Click in the photo to have a better view.

/by
, ,

List of Receipts API in Oracle Receivables

List of Receipts API in Oracle Receivables
Below is the list of some of the Receipt API’s in Oracle Receivables. Receipt APIs provide an extension to existing functionality for creating and manipulating receipts through standard AR Receipts forms and lockboxes.
AR_RECEIPT_API_PUB is the main package that has several procedures to perform different actions.

1] AR_RECEIPT_API_PUB.CREATE_CASH
Use this procedure to create a single cash receipt for payment received in the form of a check or cash.
2] AR_RECEIPT_API_PUB.APPLY & AR_RECEIPT_API_PUB.APPLY_IN_DETAIL
Use these procedures to apply the cash receipts from a customer to an invoice, debit memo, or other debit item.
3] AR_RECEIPT_API_PUB.UNAPPLY
Use this procedure to unapply a cash receipt application against a specified installment of a debit item or payment schedule ID.
4] AR_RECEIPT_API_PUB.CREATE_AND_APPLY
Use this procedure  to create a cash receipt and apply it to a specified installment of a debit item.
5] AR_RECEIPT_API_PUB.REVERSE
Use this procedure to reverse cash and miscellaneous receipts.
6] AR_RECEIPT_API_PUB.APPLY_ON_ACCOUNT
Use this procedure to apply a cash receipt on account.
7] AR_RECEIPT_API_PUB.UNAPPLY_ON_ACCOUNT
Use this procedure to unapply an on-account application of a specified cash receipt.
8] AR_RECEIPT_API_PUB.ACTIVITY_APPLICATION
Use this procedure to create an activity application on a cash receipt, including Short Term  Debit (STD) and Receipt Write-off applications.
9] AR_RECEIPT_API_PUB. ACTIVITY_UNAPPLICATION
Use this procedure to create a reversal of an activity application on a cash receipt including Short Term Debt and Receipt write-off.
10] AR_RECEIPT_API_PUB.CREATE_MISC
Use this procedure to create a miscellaneous receipt.
11] AR_RECEIPT_API_PUB.APPLY_OPEN_RECEIPT
Use this procedure to apply a cash receipt to another open receipt. Open receipts include unapplied cash, on-account cash, and claim investigation applications.
12] AR_RECEIPT_API_PUB.UNAPPLY_OPEN_RECEIPT
Use this procedure to reverse a payment netting application on a  cash receipt.
/by