WHAT IS IPAYMENT?
Oracle iPayment is a complete electronic payment
processing solution designed for application developers,
systems integrators and enterprises that need to
"payment-enable" new or existing Internet or
client/server applications. Oracle iPayment supports
multiple payment processing systems operating
simultaneously and provides a powerful, business rulesdriven
routing system that gives businesses and
merchants full control over transaction processing.
iPayment provides payment instrument registration
APIs for registering payment instruments such as credit
cards, bank accounts, and purchase cards. It also
provides payment transaction APIs that can perform
credit card and purchase card operations such as
authorization, capture, and bank account transfer
operations. Risk evaluation APIs are provided to
perform risk analysis.
iPayment integrates with Oracle Receivables, Oracle
iStore via Oracle Order Capture, and Oracle Order
Management.
Most of your effort will go into identifying and setting
up the Payment transactions and Order Management.
Once set up, it is a simple matter to use iPayment to
authorize the transactions in Order Management.
SETTING UP ORDER MANAGEMENT
Using the System Administrator privilege, setup the
following profile options at the lowest possible level
(Site is the highest and User is the lowest level).
OM: Credit Card Privileges - ALL
OM: Risk Factor Threshold for Electronic Payments -50
OM: Estimated Authorization Validity Period - 1 day
OM: Payment Method for Credit Card Transactions -Credit Card
SETTING UP PAYEE IN AR
In Receivables Manager responsibility open the form
Setup -> Receipts -> Receipt Classes. Query up Credit
Card . Enter a Merchant ID.
For each Merchant ID you need to use in Order
Management, a corresponding payee identifier needs to
be setup in iPayment. For setting the payee in iPayment
navigate as follows:
Jtflogin.jsp -> iby_admin user -> click on Payee tab
Follows the instructions provided in the iPayment
Implementation Guide for setting up payees.
USING IPAYMENT IN OM
1. Create a Sales Order with Credit Card information
and Book it.
2. Once you Book the Sales Order, the system should
populate the Sales Order with Authorization Code.
This means that the transaction has been
authorized. This does not mean that the funds have
been captured.
TROUBLESHOOTING
There are two log files we can use to troubleshoot issues
if the Payment Authorization results in an error or does
not provide the authorization code. Both Order
Management and iPayment have their own log files.
Generating the log file from Order
Management
1. Set the profile OM: Debug Level to 5
2. Set the profile OM: Debug Log Directory. This
value should be selected from the value(s) set for
utl_file_dir in init.ora
3. Before booking the order in Order Management
click on Tools -> Debug and choose Write to a
FILE. This should create a log file (Log File Name
will be displayed when this option is chosen) in the
directory mentioned in step 2.
Log file from iPayment
iPayment may create a log file if the process has failed
within iPayment. The name and location of the file can
be found from jtflogin.jsp. Login as sysadmin and click
on Advanced -> View IBY properties. Debugfile
property points to the name and location of the log file.
Additional information
1. Verify from Metalink that the latest iPayment and
Order Management patches have been applied.
2. The payee identifier in iPayment must exactly
match the Merchant ID setup in Accounts
Receivables responsibility.
3. At this time only seeded Payment Types are
allowed and custom Payment Types may not be
used with iPayment
4. Instead of Booking the Order to Authorize
Payment, you can also click on Actions and choose
Authorize Payment.
Friday, August 24, 2007
Parties & Customer Accounts
Party Model Overview
The party model flows through the entire e-Business Suite. There is
just one record to represent both a prospect and a customer. The
entity itself is recorded, such as a person or an organization.
However, customer terms are established, that record represents a
prospect. Once customer terms are recorded, that same record now
represents the entity as your customer. So, there are no separate lists
to maintain and reconcile. In the Oracle e-Business Suite, there is
one record to represent Company ABC throughout its full life-cycle.
Each application uses different features of the party model. For
instance, the Customer Relationship Management Suite (CRM)
applications use more details about party relationships and new
prospects. The Receivables and Order Management applications use
more of the customer accounts including payment terms, billing, and
shipping information.
The party model contains a unique set of information about a
person, organization, or relationship. The tables store information
such as parties, addresses, and bank accounts.
You are able to interact with the party model through the following:
Customer forms: Online entry and query of party and customer
account information.
Party interface: Batch load of party information.
Party and customer account merge: Merge parties and customer
accounts. This functionality is used after entering a party incorrectly,
in duplicate, or due to a business consolidation.
Party Model
A party is an entity that can enter into business relationships. A party
is defined by information about that party, not its relationships. For
example, the name “Vision Corporation” is part of the definition of a
party with the Organization party type.
A relationship is defined by the characteristics or terms and
conditions of that relationship. For example, the attribute “Marital
Status” is part of the definition of the Spouse of relationship.
The definition of a party is independent of its relationships. For
example, a party, “John Smith,” with the Person party type exists
independent of any relationship entered by John Smith.
A party site links a party with a location, indicating that party’s usage
of the location. This location can be a customer account site which
would be used within the context of a customer account for business
purposes like billing and shipping.
A location is a point in geographical space described by a street
address.
A party relationship is a binary relationship between two parties like
a partnership.
A contact point is means of contacting a party. For example, a phone
number, e-mail address, or fax number.
Party Model and Relationships
The party model has tables that store party information about people
or organizations and any relationships between these parties.
A party is anything that can enter into a business relationship with
another party. The party can be an organization, a person or a
relationship. This allows you to store information about your
relationships in one representation of people and businesses.
The party registry stores information about relationships between
parties, such as:
Organizational hierarchies
Business relationships
Personal relationships
Organization contacts
In addition to the original relationship, the party registry stores the
reciprocating data for the relationship for example:
Marla is a Customer of the Phone Company. Relationship
information about Marla:
Marla is an Employee of Business World. The Business World record
also indicates it is an Employer of Marla (Business Relationship)
Marla is the Spouse of John. John’s record indicates he is the Spouse
of Marla. (Personal Relationship)
Marla is Related to Digital Image Corporation. Digital Image’s record
indicates it is Related to Marla.
Party Model Components
Data model: Tables and attributes for modeling parties
Backwards-compatible views: Other Oracle Applications see the new
party model as an Oracle Applications Release 11 data model.
PL/SQL APIs: Allows developers to use common business logic to
update the party master.
Customer account forms, open interface, and merge function work
with the new party model.
Managing parties
When managing parties, you can:
Create customer account profile classes
Assign profile classes to customer accounts
Create and maintain party information
Define relationships between parties and between customer
accounts. (Both reciprocal and non-reciprocal)
Merge parties and customer account information
Review party and customer account information online and in
reports
Customer Accounts
Information held in the registry level is universally true. It is
independent of relationships.
Information held in the customer account level is about your
business relationship. It is for items like payment terms and billing
preferences.
The financial rollup point is an account. It tracks the monetary
portion of a party’s purchases and payments.
Party information is separate from the information about the
relationships of the party. The party model separates information
about the organization or person party from the terms of the
relationship.
Additionally, the party model allows you to establish multiple
relationships (also known as party accounts) with the same
organization or person party .
Addresses work in a similar fashion. You record an address for an
organization or person once, then reference it within the customer
account layer, through the customer account site entity.
Customer Account Relationships
Receivables, Vision Operations (USA)
(N) Customers > Quick or Standard (T) Relationships
Relationships exist between two customers and can be reciprocal or
nonreciprocal. They allow the following:
Payment of related invoices.
Sharing of pricing entitlements (Agreements and Commitments).
Consolidation of business addresses (Selection of a related
customer’s ship-to address during order entry).
Relationships are not transitive: If customer A is related to B and B is
related to C, A and C are not related. You must build the A to C
relationship separately.
Under System Options you can select the check box Allow Payment
of Unrelated Transactions if you want to permit application of funds
from one party to another unrelated party. If you do not select this
check box, a customer account relationship must be set up to apply
payments from one account to another.
TCA Registry
The TCA Registry is the single source of trading community
information for all Oracle E-Business Suite applications.
Administration allows you to control the data in the Registry to best
fit your business needs.
Oracle Credit Management utilizes TCA parties to consolidate
historical AR and OM data for credit reviews. For example, if a party
has 3 accounts related to it and each account has AR data, all data
will be consolidated for a global view of the party’s credit worthiness
and party level credit limits can be shared by all accounts in the
relationship.
TCA Administration Subtabs
Relationships: Set up the relationship types that can be used to
create relationships among entities in the TCA Registry.
Classifications: Set up the class categories and codes that can be used
to classify entities in the TCA Registry.
DQM: Set up Data Quality Management (DQM), which provides
powerful search and duplicate identification functionality.
Enrichment: Set up Third Party Data Integration to control the usage
and display of third party data along with user-entered information
in the TCA Registry. You also set up your integration with D&B.
Security: Set up data sharing groups and control how specific entities
in the TCA Registry can be accessed depending on user and
responsibility privileges.
Merge Parties or Customer Accounts
Receivables, Vision Operations (USA) or Order Management Super
User, Vision Operations (USA)
(N) Customers > Merge
(N) Customers > Party Merge
Merging a party is different than merging a customer account. The
party is everything under that party. The customer account merge is
two accounts under one party. Merging party or customer account
information combines all information for two parties, customer
accounts, or account sites. You can delete or inactivate the mergefrom
party, customer account, and account sites.
Before merging consider archiving the historical data for the
absorbed party, customer account, or account site. Also, consider
that the information is being used by the entire e-Business suite and
will affect other applications.
Merging Incorrect Data
The most common reason to merge parties is to clean up data
entered in error. For example, data related to an existing
party “White Place” might be entered in error for a new party created
as “White Corp.” You merge the data for these parties to consolidate
all the data for White Place. Misspellings and the incorrect use of
upper and lower case are also common reasons for merging parties.
Merging Site Data
Another reason to merge party data is the consolidation or relocation
of party sites. For example, if a party closes a facility in Milan and
moves all activity to an existing facility in Rome, data related to the
Milan site will be merged with the data for the Rome site.
Note: Because historical reporting will no longer be available for the
Milan site, you should carefully consider any merging.
Merging Party or Customer Account Data
A less common reason to merge party data is when two different
parties merge and form a single party.
Note: Because historical reporting will no longer be available using
the parties’ prior names, you should carefully consider any merging.
When merge processing is complete, Receivables automatically
generates a party Merge Execution report which can be printed or
reviewed online.
After party data has been merged, there are no links between the
previous party and its transaction records. These transactions appear
as if they had always belonged to the succeeding party.
To automatically copy “From” addresses as “To” addresses, select
Create Same Site.
The party model flows through the entire e-Business Suite. There is
just one record to represent both a prospect and a customer. The
entity itself is recorded, such as a person or an organization.
However, customer terms are established, that record represents a
prospect. Once customer terms are recorded, that same record now
represents the entity as your customer. So, there are no separate lists
to maintain and reconcile. In the Oracle e-Business Suite, there is
one record to represent Company ABC throughout its full life-cycle.
Each application uses different features of the party model. For
instance, the Customer Relationship Management Suite (CRM)
applications use more details about party relationships and new
prospects. The Receivables and Order Management applications use
more of the customer accounts including payment terms, billing, and
shipping information.
The party model contains a unique set of information about a
person, organization, or relationship. The tables store information
such as parties, addresses, and bank accounts.
You are able to interact with the party model through the following:
Customer forms: Online entry and query of party and customer
account information.
Party interface: Batch load of party information.
Party and customer account merge: Merge parties and customer
accounts. This functionality is used after entering a party incorrectly,
in duplicate, or due to a business consolidation.
Party Model
A party is an entity that can enter into business relationships. A party
is defined by information about that party, not its relationships. For
example, the name “Vision Corporation” is part of the definition of a
party with the Organization party type.
A relationship is defined by the characteristics or terms and
conditions of that relationship. For example, the attribute “Marital
Status” is part of the definition of the Spouse of relationship.
The definition of a party is independent of its relationships. For
example, a party, “John Smith,” with the Person party type exists
independent of any relationship entered by John Smith.
A party site links a party with a location, indicating that party’s usage
of the location. This location can be a customer account site which
would be used within the context of a customer account for business
purposes like billing and shipping.
A location is a point in geographical space described by a street
address.
A party relationship is a binary relationship between two parties like
a partnership.
A contact point is means of contacting a party. For example, a phone
number, e-mail address, or fax number.
Party Model and Relationships
The party model has tables that store party information about people
or organizations and any relationships between these parties.
A party is anything that can enter into a business relationship with
another party. The party can be an organization, a person or a
relationship. This allows you to store information about your
relationships in one representation of people and businesses.
The party registry stores information about relationships between
parties, such as:
Organizational hierarchies
Business relationships
Personal relationships
Organization contacts
In addition to the original relationship, the party registry stores the
reciprocating data for the relationship for example:
Marla is a Customer of the Phone Company. Relationship
information about Marla:
Marla is an Employee of Business World. The Business World record
also indicates it is an Employer of Marla (Business Relationship)
Marla is the Spouse of John. John’s record indicates he is the Spouse
of Marla. (Personal Relationship)
Marla is Related to Digital Image Corporation. Digital Image’s record
indicates it is Related to Marla.
Party Model Components
Data model: Tables and attributes for modeling parties
Backwards-compatible views: Other Oracle Applications see the new
party model as an Oracle Applications Release 11 data model.
PL/SQL APIs: Allows developers to use common business logic to
update the party master.
Customer account forms, open interface, and merge function work
with the new party model.
Managing parties
When managing parties, you can:
Create customer account profile classes
Assign profile classes to customer accounts
Create and maintain party information
Define relationships between parties and between customer
accounts. (Both reciprocal and non-reciprocal)
Merge parties and customer account information
Review party and customer account information online and in
reports
Customer Accounts
Information held in the registry level is universally true. It is
independent of relationships.
Information held in the customer account level is about your
business relationship. It is for items like payment terms and billing
preferences.
The financial rollup point is an account. It tracks the monetary
portion of a party’s purchases and payments.
Party information is separate from the information about the
relationships of the party. The party model separates information
about the organization or person party from the terms of the
relationship.
Additionally, the party model allows you to establish multiple
relationships (also known as party accounts) with the same
organization or person party .
Addresses work in a similar fashion. You record an address for an
organization or person once, then reference it within the customer
account layer, through the customer account site entity.
Customer Account Relationships
Receivables, Vision Operations (USA)
(N) Customers > Quick or Standard (T) Relationships
Relationships exist between two customers and can be reciprocal or
nonreciprocal. They allow the following:
Payment of related invoices.
Sharing of pricing entitlements (Agreements and Commitments).
Consolidation of business addresses (Selection of a related
customer’s ship-to address during order entry).
Relationships are not transitive: If customer A is related to B and B is
related to C, A and C are not related. You must build the A to C
relationship separately.
Under System Options you can select the check box Allow Payment
of Unrelated Transactions if you want to permit application of funds
from one party to another unrelated party. If you do not select this
check box, a customer account relationship must be set up to apply
payments from one account to another.
TCA Registry
The TCA Registry is the single source of trading community
information for all Oracle E-Business Suite applications.
Administration allows you to control the data in the Registry to best
fit your business needs.
Oracle Credit Management utilizes TCA parties to consolidate
historical AR and OM data for credit reviews. For example, if a party
has 3 accounts related to it and each account has AR data, all data
will be consolidated for a global view of the party’s credit worthiness
and party level credit limits can be shared by all accounts in the
relationship.
TCA Administration Subtabs
Relationships: Set up the relationship types that can be used to
create relationships among entities in the TCA Registry.
Classifications: Set up the class categories and codes that can be used
to classify entities in the TCA Registry.
DQM: Set up Data Quality Management (DQM), which provides
powerful search and duplicate identification functionality.
Enrichment: Set up Third Party Data Integration to control the usage
and display of third party data along with user-entered information
in the TCA Registry. You also set up your integration with D&B.
Security: Set up data sharing groups and control how specific entities
in the TCA Registry can be accessed depending on user and
responsibility privileges.
Merge Parties or Customer Accounts
Receivables, Vision Operations (USA) or Order Management Super
User, Vision Operations (USA)
(N) Customers > Merge
(N) Customers > Party Merge
Merging a party is different than merging a customer account. The
party is everything under that party. The customer account merge is
two accounts under one party. Merging party or customer account
information combines all information for two parties, customer
accounts, or account sites. You can delete or inactivate the mergefrom
party, customer account, and account sites.
Before merging consider archiving the historical data for the
absorbed party, customer account, or account site. Also, consider
that the information is being used by the entire e-Business suite and
will affect other applications.
Merging Incorrect Data
The most common reason to merge parties is to clean up data
entered in error. For example, data related to an existing
party “White Place” might be entered in error for a new party created
as “White Corp.” You merge the data for these parties to consolidate
all the data for White Place. Misspellings and the incorrect use of
upper and lower case are also common reasons for merging parties.
Merging Site Data
Another reason to merge party data is the consolidation or relocation
of party sites. For example, if a party closes a facility in Milan and
moves all activity to an existing facility in Rome, data related to the
Milan site will be merged with the data for the Rome site.
Note: Because historical reporting will no longer be available for the
Milan site, you should carefully consider any merging.
Merging Party or Customer Account Data
A less common reason to merge party data is when two different
parties merge and form a single party.
Note: Because historical reporting will no longer be available using
the parties’ prior names, you should carefully consider any merging.
When merge processing is complete, Receivables automatically
generates a party Merge Execution report which can be printed or
reviewed online.
After party data has been merged, there are no links between the
previous party and its transaction records. These transactions appear
as if they had always belonged to the succeeding party.
To automatically copy “From” addresses as “To” addresses, select
Create Same Site.
Data Flow of a Standard 'Order' in Order
1. Order Entry
This is first stage when Order in enter in system.When the order is
entered it basically creates a record in order headers and Order Lines
table.
oe_order_headers_all (Here the flow_status_code as entered)
oe_order_lines_all (flow_status_code as entered) ( order number is
generated)
2.Order Booking
This is next stage , when Order which is entered in step 1 is booked
and Flow status changed from Entered to Booked.At this stage ,
these table get affected.
oe_order_headers_all (flow_status_code as booked ,booked_flag
updated)
oe_order_lines_all (flow_status_code as awaiting shipping,
booked_flag updated)
wsh_new_deliveries (status_code OP open)
wsh_delivery_details (released_status ‘R’ ready to release)
Same time, Demand interface program runs in background And
insert into inventory tables mtl_demand
3. Reservation
This step is required for doing reservations SCHEDULE ORDER
PROGRAM runs in the background and quantities are reserved.Once
this program get successfully get completed , the mtl_reservations
table get updated.
4. Pick Release
Ideally pick release is the process which is defined in which the items
on the sales order are taken out from inventory.
Normally pick release SRS program runs in background . Once the
program get completed these are the table get affected:
oe_order_lines_all (flow_status_code ‘PICKED’ )
wsh_delivery_details (released_status ‘S’ ‘submitted for release’ )
mtl_txn_request_headers
mtl_txn_request_lines
(move order tables.Here request is generated to move item from
saleble to staging sub inventory)
Mtl_material_transactions_temp (link to above tables through
move_order_header_id/line_id
5.Pick Confirm
Items are transferred from saleble to staging Subinventory.
mtl_material_transactions
mtl_transaction_accounts
wsh_delivery_details (released_status ‘Y’‘Released’ )
wsh_delivery_assignments
6.Ship Confirm
Here ship confirm interface program runs in background . Data
removed from wsh_new_deliveries
oe_order_lines_all (flow_status_code ‘shipped’)
wsh_delivery_details (released_status ‘C’ ‘Shipped’)
mtl_transaction_interface
mtl_material_transactions(linked through Transaction source
header id)
mtl_transaction_accounts
Data deleted from mtl_demand,mtl_reservations
Item deducted from mtl_onhand_quantities
7.Enter Invoice
This is also called Receivables interface, that mean information
moved to accounting area for invoicing details.
Invoicing workflow activity transfers shipped item information to
Oracle Receivables.
ra_interface_lines_all (interface table into which the data is
transferred from order management)T
Then Autoinvoice program imports data from this
Table which get affected into this stage are recievables base table.
ra_customer_trx_all (cust_trx_id is primary key to link it to
trx_lines table and trx_number is the invoice number)
ra_customer_trx_lines_all (line_attribute_1 and line_attribute_6
are linked to header_id (or order number) and line_id of the orders)
8.Complete Line
In this stage order line leval table get updated with Flow status and
open flag.
oe_order_lines_all (flow_status_code ‘shipped’, open_flag “N”)
9.Close Order
This is last step of Order Processing . In this stage only
oe_order_lines_all table get updated.
These are the table get affected in this step.
oe_order_lines_all (flow_status_code ‘closed’,open_flag “N”)
These are the typically data flow of a order to cash model for a
standard order.
This is first stage when Order in enter in system.When the order is
entered it basically creates a record in order headers and Order Lines
table.
oe_order_headers_all (Here the flow_status_code as entered)
oe_order_lines_all (flow_status_code as entered) ( order number is
generated)
2.Order Booking
This is next stage , when Order which is entered in step 1 is booked
and Flow status changed from Entered to Booked.At this stage ,
these table get affected.
oe_order_headers_all (flow_status_code as booked ,booked_flag
updated)
oe_order_lines_all (flow_status_code as awaiting shipping,
booked_flag updated)
wsh_new_deliveries (status_code OP open)
wsh_delivery_details (released_status ‘R’ ready to release)
Same time, Demand interface program runs in background And
insert into inventory tables mtl_demand
3. Reservation
This step is required for doing reservations SCHEDULE ORDER
PROGRAM runs in the background and quantities are reserved.Once
this program get successfully get completed , the mtl_reservations
table get updated.
4. Pick Release
Ideally pick release is the process which is defined in which the items
on the sales order are taken out from inventory.
Normally pick release SRS program runs in background . Once the
program get completed these are the table get affected:
oe_order_lines_all (flow_status_code ‘PICKED’ )
wsh_delivery_details (released_status ‘S’ ‘submitted for release’ )
mtl_txn_request_headers
mtl_txn_request_lines
(move order tables.Here request is generated to move item from
saleble to staging sub inventory)
Mtl_material_transactions_temp (link to above tables through
move_order_header_id/line_id
5.Pick Confirm
Items are transferred from saleble to staging Subinventory.
mtl_material_transactions
mtl_transaction_accounts
wsh_delivery_details (released_status ‘Y’‘Released’ )
wsh_delivery_assignments
6.Ship Confirm
Here ship confirm interface program runs in background . Data
removed from wsh_new_deliveries
oe_order_lines_all (flow_status_code ‘shipped’)
wsh_delivery_details (released_status ‘C’ ‘Shipped’)
mtl_transaction_interface
mtl_material_transactions(linked through Transaction source
header id)
mtl_transaction_accounts
Data deleted from mtl_demand,mtl_reservations
Item deducted from mtl_onhand_quantities
7.Enter Invoice
This is also called Receivables interface, that mean information
moved to accounting area for invoicing details.
Invoicing workflow activity transfers shipped item information to
Oracle Receivables.
ra_interface_lines_all (interface table into which the data is
transferred from order management)T
Then Autoinvoice program imports data from this
Table which get affected into this stage are recievables base table.
ra_customer_trx_all (cust_trx_id is primary key to link it to
trx_lines table and trx_number is the invoice number)
ra_customer_trx_lines_all (line_attribute_1 and line_attribute_6
are linked to header_id (or order number) and line_id of the orders)
8.Complete Line
In this stage order line leval table get updated with Flow status and
open flag.
oe_order_lines_all (flow_status_code ‘shipped’, open_flag “N”)
9.Close Order
This is last step of Order Processing . In this stage only
oe_order_lines_all table get updated.
These are the table get affected in this step.
oe_order_lines_all (flow_status_code ‘closed’,open_flag “N”)
These are the typically data flow of a order to cash model for a
standard order.
Subscribe to:
Posts (Atom)
