CREDIT CHECK-1

Setting up Customer Credit Limit

Category: Receivables

Use Customer Profiles to group customers with similar credit worthiness, business volume, and payment cycles. For each profile class you can define information such as credit limits, payment terms, statement cycles, invoicing, and discount information. You can also define amount limits for your finance charges, dunning, and statements for each currency in which you do business.

Define your standard customer profiles in the Customer Profile Classes window. These profiles contain generic options you can use to group your customers into broad categories. For example, you might define three categories: one for prompt paying customers with favorable credit limits; one for late paying customers with high finance charge rates; and a third for customers who mostly pay on time, with discount incentives for early payment. You can also use the profile class ‘DEFAULT,’ which the system provides.

Assign a profile class to each of your customers and addresses in the Customers window. The customer profile class you assign provides the default values, then you can optionally customize these values to meet your specific requirements for each customer or address. If a profile is assigned to both a customer and one of that customer’s addresses, the options set for the address take precedence over those set at the customer level.

Setting up Customer Credit Check

·         Receivables Super user Responsibility

·         Navigate: Customers à Customers

·         Query the Customer for whom you want to Setup Credit Hold/Check.

·         Select the Customer for whom you wish to setup Credit Hold.

·         Select Site.

·         Click on the Profile Amounts.

·         Enter the amount in the Credit Limit and Order Credit Limit Field.

·         What is Credit Limit: Over all credit limit for the customer. Once the credit crosses this limit, then one cannot book the order for this customer

·         What is Order Limit: Limit set for per Order. Once the order is made for the amount more than that is prescribed as limit, then the order is booked but will be put on HOLD.

·         Note: When required, Hold needs to be released by the Manager.

Pre-requisites:

Quick Codes for Customer Profile, Statement Cycles, Dunning Letters, Collectors, Payment Terms, Auto Cash Rule Sets, System Options, Grouping Rules & Currencies 

Payment

This chapter covers the following topics:

• Credit Checking
• Global Credit Checking
• Credit Cards and Oracle Payments
• Features
• Set Up
• Payment Terms
• Lookups
• Oracle Payments Setup
• Reports
• Implementation Considerations
• Examples
• Multiple and Partial Payments
• Profiles
• Setup

Credit Checking

Overview

The ultimate goal of Credit Management processes is to minimize the financial risk that your organization assumes as a result of day-to-day operations. Order Management's credit checking feature is the process by which orders are validated and released against your credit checking business rules. Using credit rules, system parameters, and credit profiles, Order Management credit checking verifies that your customer has a sufficient credit availability with your organization to allow orders to be processed and shipped in advance of payment.

Order Management enables you to perform credit checks on customer orders or order lines, and automatically hold orders or lines that violate your credit setup. Using Order Management credit checking effectively requires a complete understanding of the functional components as well as a careful consideration of timing and performance factors. For example,

·         You can choose to perform credit checking automatically at pre-specified workflow events against real time transactional data or pre-calculated summary exposure amounts. Pre-calculated exposure amounts can be either:

o    Real time transactional data summarized at a specific point in time

o    Exposure amounts imported into Oracle Order Management exposure tables

o    Real time transactional data summarized at a specific point in time plus exposure amounts imported into Oracle Order Management exposure tables

·         You can choose to perform credit checking across orders with different currencies within a single organization, specifying the currencies to include when calculating overall exposure amount

·         You can choose to perform credit checking at the customer account level, across all operating units within your system

·         You can choose to perform credit checking on external transactions utilizing the credit check processes and exposure balances maintained within Oracle Applications

Order Management Credit checking includes:

·         Validating orders and lines against existing credit limits to enable continued flow through order and line workflows

·         Placing credit holds at either the order or line level, including notifications to appropriate parties of credit holds

·         The functionality to either manually release or schedule credit reassessment processes for order or line credit holds

·         Approvals for orders that exceed credit limits

·         Reporting and querying tools to effectively manage your credit processes and ensure credit holds are processed in a timely manner

Depending upon your business practices, you may not want to perform credit check for all orders, but rather only those orders that could pose a credit risk. Orders that could be exempted from credit check can be:

·         Orders of a given type. For example, you may want to exclude staff sales or internal sales orders from credit checks. Credit checking rules are assigned to order types. While setting up order types, if the credit check rule fields are left blank, this would automatically exclude orders of that type from credit check.

·         Orders for a given customer. For example, a manufacturer may wish to exclude all orders from its largest customer from credit check. With Order Management and Oracle Receivables, excluding a specific customer from a credit check can be achieved by disabling the Credit Check flag for this customer in the individual customer profile.

·         Orders for a given class of customer. For example, a manufacturer may wish to exclude all orders from internal customers from credit check. You can group all your internal customers into one Customer Profile Class, and then set up credit checking rules to exclude that profile class of customer. With Order Management and Oracle Receivables, while setting up a customer profile class, you can disable the Credit Check flag. Customers that have this customer profile class assigned to them would then be excluded from credit check.

·         Orders for a given customer billing address. For example, a manufacturer may wish to exclude orders that will be invoiced to one of its' largest customer corporate headquarters from the credit check process. With Order Management and Oracle Receivables, the individual bill-to sites can have a different transaction profile from the parent customer. While setting up the bill-to site profile, enabling the Credit Check flag determines whether orders billed to that address will be credit checked.

·         Order lines with a given payment term. For example, order lines with a cash on delivery payment term can be excluded from the credit checking process. With Order Management and Oracle Receivables, the payment terms also have a Credit Check flag. Disabling this flag will automatically exclude order lines with that payment term from the credit evaluation. Only those lines that have payment terms with credit checking turned on are compared against the credit limits.

·         Order lines that are paid via Commitments. These lines are in effect prepaid, so you do not need to credit check them.

·         Orders with a payment type = Credit Card. These orders will have credit card authorization in place of credit checking.

When using Oracle Order Management to define your credit management policies, you should familiarize yourself with the following Oracle credit check concepts:

·         Credit Profile

·         Credit Check Rules

·         Credit Usage Rules

Credit Checking Components

The Credit Check process can be performed for orders or order lines, and the determination on whether credit checking is performed is based upon all of the following:

·         The credit check rule definition and the order type of which the definition is attached

·         Order or line payment terms

·         Enabled credit profiles

Credit Checking will only occur for an order or line when all three levels enable credit checking. If one level disregards credit checking, credit checking does not occur for the order or line.

Credit Exposure

When you perform credit checking in Order Management, you determine what type of exposure to use when determining credit worthiness. Order Management enables you to perform credit checking against real time transactional data or current exposure amounts stored in exposure summary tables.

·         Real time transactional data is all related transactions which are summarized at the point credit checking is invoked.

·         Current (pre-calculated) exposure amounts can be either:

o    Real time transactional data summarized at a specific point in time or

o    Exposure amounts imported using the Credit Exposure Import concurrent program.

When defining your Credit Check rules, you specify the type of exposure to utilize when performing credit checking.

Credit Check Rule Definition

Credit Checking Rules within Order Management enable you to determine credit worthiness of orders when performing credit checking, and provide you with various options in determining your customer's credit exposure.

Credit Check Rules are attached to Order Management Transaction Types. Within the Transaction Type window, credit check rules are assigned to pre-specified events that trigger the credit checking process. For example, you might want to perform a high-level credit check before booking, but you may want to apply more specific controls before shipping the product to your customer.

In Order Management, separate credit checking rules can be assigned for use at the time of booking, pick release and purchase release (for drop shipments), packing, or shipping within corresponding order or line workflow processes. You can also choose to perform credit checking at multiple points within an order or line processes by selecting credit check rules for a combination of booking, pick release and purchase release (from drop shipments), packing, or shipping.

Order Management Credit Check Rules enable and control:

·         Credit check level

·         Credit check hold level

·         Currency conversion type used during exposure calculations

·         The exposure method used for validating credit checking

·         Whether to include open receivables balances, uninvoiced order balances, freight and special charges, or taxes

·         Hold management procedures

·         Notifications of credit holds to appropriate personnel

See: Credit Cards and iPayment

Credit Checking Rule Level

The Credit Check process can be performed at sales order header or sales order line level. Additionally, the payment terms used for orders and order lines must be enabled for credit checking to occur. See: Payment Terms

1.    Order Header Level: Order Level credit check uses exclusively header level information ignoring different bill-to sites detailed at line level. Order level credit check uses the credit profile attached to the customer Bill-to site defined at order (header) level. Credit checking will use order totals and will evaluate credit exposure against the credit profile attached at header level, and holds are always applied at header level.

Note: Sales Order header level credit checking enables backward compatibility with previous credit check versions.

2.    Order Line Level: Line level credit check uses data at the sales order line level. If you have sales order lines that are attached to different Bill To sites and if you want to use the specific credit profiles attached to those Bill To Sites, you should use Sales Order Lines level credit check.

Additionally, you could use line level credit check when you have defined customer relationships in your system and you actively use them in Order Management. In this situation, you are able to create a sales order whose lines could be attached to different bill-to sites owned by different customers.

Lines with the same Bill To sites are not checked individually to see whether they exceed the credit limit. A cumulative total up to the line being assessed is taken to compare it against the credit limit. As a line is released and the order ID is passed to OM the total number of lines for the bill to should be summed and when the cum. Line totals arrive at a value that exceeds credit limits those lines only should be held. The line sequence in which the hold is applied is determined by a system parameter Credit Hold Sequence for Order Lines.

The system parameter Credit Hold Sequence for Order Lines is used to determine the sequence in which the lines are placed on hold:

1.    Option 1: All Lines

2.    Option 2:

o    Schedule Ship Date / Request Date

o    Shipment Priority Code

o    Line Number

3.    Option 3:

o    Shipment Priority Code

o    Schedule Ship Date / Request Date

o    Line Number

4.    Option 4: Uninvoiced line amount ascending

5.    Option 5: Uninvoiced line amount descending

Note: Include Uninvoiced Orders in Credit Check rule should be unchecked (i.e. the unInvoiced orders are NOT included in exposure calculation),

Credit Checking Rule Hold Level

You can choose to place credit holds for orders or lines that fail credit check validations at either the sales order or sales order line if you use order line level credit checking. Credit checking holds are automatically placed based upon your credit rule definition, and you can automatically release order or order line credit holds when a customer's credit exposure has been reduced to a point that enables credit checking validation to pass successfully. You automatically release credit holds by scheduling the Credit Check Processor concurrent program to run at specific intervals.

Credit Checking Rule Override Manual Release (check box)

In previous releases of Oracle Order Management, you had the ability to manually release order or line credit check holds that were placed by credit check process. However, no additional credit checking of manually released credit holds occurred.

You can now specify whether or not you wish to enable additional credit checking if an order or line credit check hold was released manually. The Override Manual Release check box, used in conjunction with Days to Honor Manual Release field, enables you to define the duration (number of days) you will forego additional credit checking if an order or line credit check hold is released manually.

Your Order Management Transactions Type definitions will control whether or not additional credit check processing can occur for manually released holds (credit check rules entered for booking, pick release and purchase release (for drop shipments), packing, or shipping within your transaction type definitions).

Manually released holds are honored only if the Credit Check Rule being used is Picking, Packing or Shipping, and the credit check was not triggered due to a change on the order itself, such as change in item quantity, or price.

Credit Checking Rule Days to Honor Manual Release

This field, in conjunction with the Override Manual Release check box, enables you to define the duration (number of days) manually released holds will be honored and not overridden by additional credit checking processes.

For example, suppose you have defined a credit check rule in which you have enabled the Override Manual Release check box, with a value of 15 within the Days to Honor Manual Release field. Assume that this credit check rule is assigned to the transaction type as a credit check rule for booking and shipping. If you manually release an order or line from credit check hold after booking, and if you ship the order or order line within 15 days, Order Management will not enable credit checking to occur again. However, if you ship after Day 15, then Order Management will enable the credit checking process to be invoked again.

Credit Checking Rule Conversion Type

Conversion types for credit check rules enable you to model a fixed exchange rate between currencies or use an average exchange rate. When performing credit checking, the credit limit currency does not necessarily have to be the same as the functional currency. Conversion types are limited to the values you define within the Oracle General Ledger Conversion Rate Types window.

Credit Checking Rule Exposure

You can choose how you wish to validate credit worthiness during credit checking by determining the exposure method used.

Previous versions of credit checking calculated customer exposure accessing underlying transactional tables. When a credit check request was executed, underlying transaction tables were summed to generate customer balance information.

In order to improve performance, Oracle Order Management has incorporated an additional option, the use of pre-calculated exposure. Using this option, credit checking will validate exposure against balance information stored in a summary table. The summary table is updated as often as your business practices require, and updates to the table are performed by submitting a concurrent program. This program accesses both Oracle Receivables and Order Management transactional tables, and should be scheduled to run periodically, based on your specific business needs.

Credit Checking Rule Values to Include Within Exposure Calculation

Your credit checking rule definition can include or exclude the following credit related details when calculating credit exposure:

·         Open receivables balances

·         Uninvoiced order balances

·         Freight and special charges

·         Taxes

·         Payments at risk

Credit Checking Rule Notifications

You can choose to send notifications whenever a sales order or order lines fails credit check. The notification is sent to the person who created the order.

Credit Checking Limits Hierarchy

Site Level

If credit check is not enabled, then no credit checking takes place. If credit checking is enabled and limits are available, then credit check is done at the site level. If credit checking is enabled and limits are Null, Customer level is accessed.

Customer Level

If credit check is not enabled, then no credit checking takes place. If credit checking is enabled and limits are available, then credit check is done at the customer level. If credit checking is enabled and limits are Null, Party level is accessed.

If Credit Management is installed and pre-calculated exposure is checked, then party limits are used.

Party Level

If credit check is not enabled, then no credit checking takes place. If credit checking is enabled and limits are available, then credit check is done at the Parent Party level. If credit checking is enabled and limits are Null, Operating Unit Default is accessed. If the party hierarchy is set up using Trading Community Architecture, then credit checking will look into this hierarchy, to verify if a Parent Party is available. If so, the limits of the parent and checked and if it is null, Operating Unit Default level is checked.

Operating Unit Default Level

If credit checking is enabled and limits are available, then credit check is done at the Operating Unit Default level. If the credit limits are null, then the Maximum Credit Limit is used.

Order Management Order Transaction Type

Order Management Order Transaction Types enable you to also control when credit checking occurs and the credit check rule to be utilized when calculating credit exposure (outstanding credit balance) by assigning credit check rules to Order Management Transaction Types.

When you assign a credit check rule to a transaction type within the Order Management Transaction Types window, you enable credit checking for all orders or order lines which use the order type. Select a credit check rule for an order type by selecting a credit check rule within the Booking, Pick Release and Purchase Release (for drop shipments), Packing, or Shipping fields of the Credit Check Rule region.

You can assign the same credit check rule to a single function (field), multiple functions, or all functions, or use a different credit check rule for each function, depending upon your business needs.

Payment Terms

Payment Terms specify the due date and discount date for payment of an invoice. Payment terms also enable you to choose whether or not the payment term will be used for controlling credit checking. Each payment term can be enabled for credit checking by selecting the Credit Check box for the payment term so you never unnecessarily perform credit checking.

All orders, except orders with a Payment Type of Credit Card are included when exposure calculations are performed, regardless of their payment terms. If an order is to be paid by credit card and has already been approved (approval date not null) it will never be included in exposure.

Credit Profiles

Credit profiles define the maximum financial risk you are willing to withstand on your regular operations. The Credit Check check box in the credit region of the Standard Customer window (for the customer master record) must be enabled in order to perform credit check. You can define the credit profile information at the following levels:

·         Customer and Customer Site: This profile defines your credit policies for individual customers or customer sites. You can accept the default credit policies from a Customer Profile Class, or you can customize credit limits to fit the particular customer.

You can implement credit policy changes by modifying a Profile Class and cascading the changes to individual Customer Profiles. Check current limitations for multi-currency credit check set up.

·         Organization: This type of Credit Profile is used to define an organization's (operating unit) credit policy for credit control and credit checking. It is used as a default when customer/customer site credit profile is missing.

Organization Default provides a higher level in the customer profile hierarchy (customer site - customer - organization default), and the fulfilled credit profile at operating unit level enforces credit checking for any customer which does not have credit limits defined at the customer or site level.

·         Item Category: Item Category Credit Profiles enables you to define credit information by Order Management Item Category.

Item Category credit profile is completely independent from customer credit profiles. Item-category credit check will place a credit hold for transaction amounts over pre-defined category credit limits.

Item Category credit profiles can be used to model credit limits such as service line for insurance coverage which can prevent you from shipping materials that exceed a pre-defined monetary limit.

There is an embedded hierarchy provided by credit checking routines for establishing credit information between the following entities:

o    Customer Site

o    Customer

o    Organization Default

When customer site and customer credit profiles do not exist, the Organization Default credit profile is used, if it exists.

Integration between Credit Checking and Credit Management

Credit Management is a Receivables functionality and when integrated with Credit Checking, enables you to perform credit checks at party level or at any level of a Credit Management hierarchy. You can also release holds based on implemented recommendations generated in Credit Management.

Some of the important integration features between Credit Checking and Credit Management include:

·         You can define a credit hierarchy of parties, party relationships, hierarchy levels, accounts, and account sites. Typically, the party object and party subject in a credit relationship represent a parent and child, or HQ and division hierarchy. For each entity in the hierarchy, you can view credit information, such as credit hold status, credit limits by currency, and credit review cycle. Please note that all setup is performed through Credit Management (credit profiles at party level can only be done in Credit Management).

·         In order to perform credit check at party level or at any level of a hierarchy, the credit check rule must use pre-calculated exposure.

·         When credit profile is not defined at customer site level, or customer account level, then credit checking will go up to the party level and use the credit profile defined at that level. Exposure is summarized for all the customer accounts associated to that party.

·         Whenever a sales order is placed on hold because of credit check failure at any one or more levels of credit checking, a Credit Request application is generated in Credit Management. Recommendations generated in Credit Management (i.e. release credit check hold) are implemented in Order Management in the background, if the sales order amount has not increased.

·         When using Credit Management, credit check holds trigger a credit review in Credit Management. Order Management submits a credit management review and passes the reason(s) of credit check failure as messages to OCM. These messages enable the credit manager/analyst reviewing the case folder to determine the exact reason for the credit check failure. For any one or more cases of credit check validation failure, Order Management creates one case folder in OCM. To apply a hold release or not is decided in Credit Management and implemented in Order Management.

·         Different Exposure Sources can be configured in OM as part of the OE_EXPOSURE_INTERFACE program. The Initialize Credit Summaries table program do not delete imported exposure. There is a purge program that allows you to delete by exposure source.

·         The imported exposure is maintained as one single amount group by customer account, bill-to site, and currency. Currently, it is not group by date. So, when enabled in the credit check rule, the imported exposure amount is always included in the overall exposure even if the shipping horizon days are specified. If you want to consider shipping horizon for the imported exposure, you will need to consider the shipping horizon in your exposure calculation before importing it. The import program allows import of exposure by overwriting any existing imported exposure amount or updating the existing exposure amount.

Global Credit Checking

Oracle Order Management enables you to perform global (across multiple operating units) credit checking. Global credit checking ensures that all organizational data, irrespective of the operating unit, is considered during the credit checking process. You enable global exposure credit checking if you select the Global Exposure check box when defining Credit Usage Rules.

Global Credit checking is currently only enabled at the following levels in the credit checking hierarchy:

1.    Customer level credit checking: Global credit checking will use the overall credit limit defined at the customer level for all operating units.

2.    Organization (org) Default level credit checking: Global credit checking will use the overall credit limit defined at the organizational level for all operating units within the organization.

The credit check engine will identify the overall limit (which level within hierarchy) to utilize for credit checking, calculate the credit exposure for all the operating units, and then validate the calculated exposure against the overall credit limit selected.

Multi-currency Credit Check

You can perform multiple currency credit checking by sharing credit limits across currencies you specify.

With Single currency credit check you must define a credit limit profile in each currency if you want to control your customer exposure in that currency. In other words, every currency is treated individually for credit check purposes.

With Multi-currency credit checking, you need to define just one credit profile (i.e. in US dollars) and share it among the other currencies.

Multi-currency Terminology

Usage Rule Sets: Usage rule sets define the set of currencies that are involved in a specific credit check process. A usage rule set specifies which transactions (based upon transaction currency) qualify for use with a credit limit.

Usage Rule Sets can be assigned to a customer profile class, or credit profiles: customer, customer site, item category, or organization. If you do not assign a credit usage rule set to your credit profiles, then the credit checking is performed as Single currency credit check.

Support for Credit Checking External Transactions against exposure balances maintained within Oracle Order Management (OE_EXTERNAL_CREDIT_PUB)

With this release Order Management enables you to perform credit checking of external amounts utilizing the Oracle credit check process and exposure balances maintained within Order Management. The API essentially perform the same credit checking process as the Order Management credit check engine except for the differences listed in the table below:

Credit Checking
OM Credit Check Engine	Check External Credit API
Validate if the item categories flag is enabled for the credit check rule. If, enabled, perform item category credit check for each item category of the sales order.	Item category limits will not be checked. The API will give an error if the credit check rule has the item categories flag enabled.
Check that the Credit Check flag is specified for the customer profile and payment term. If either of these items are not enabled, do not perform credit check for the sales order.	Ignore the Credit Check flag setting at the Payment term. Only the Credit Check flag specified at the default/customer/site credit profile is validated to see if credit checking will be performed.  For anything else, it is assumed that credit check is needed when the API is called. It is up to the calling program to determine credit check should be done or not.
The credit check level (order / line) selected for the credit check rule setup determines what level the credit engine will perform.	The API will only allow credit check rules that utilize order level credit checking; the API does not support line level credit checking and will error out if a line level credit checking rule is provided.
If the Send Holds Notification check box is enabled for the credit check rule, the credit check engine will send a workflow notification to the creator of the sales order when a credit hold is placed on the sales order.	The API will not send any notifications. It will ignore the Send Hold Notifications flag set at the credit check rule.
When an order fails credit check, it is placed on credit check hold. The hold contains the reason for the failure.	When an order fails credit check, a reason is returned to the calling program in addition to the Failure result. It is up to the calling program to take appropriate action, such as placing the sales order on credit check hold.

Given a credit check rule, a bill-to site, and the transaction amount and currency, the API will credit check the amount against the credit limits and exposure within Oracle Applications and return the result of the credit check. The calling routine then can perform the appropriate action depending on the result of the check.

You must create a custom program that can execute PL/SQL procedures to utilize the Check External Credit API. For each sales order in the external system, a call will need to be made to the Check External Credit API to credit check against the exposure data stored inside Oracle Order Management. Prior to executing the call, ensure the following:

·         Group all the lines for the external transaction into a single amount and single currency, along with the credit check rule to utilize

·         Determine appropriate customer (Bill To site) within Oracle Applications to associated your external transactions with

The API will return the result of the credit check.

Depending on the result of the check, the custom program can take the appropriate action for the sales order such as place a credit hold on it.

Credit Cards and Oracle Payments

Oracle Payments (formerly known as Oracle iPayment) now has a number of enhancements in the E-Business Suite funds capture process in the current release. One of the most important enhancements is the centralization and encryption of credit card data and bank account data in Oracle Applications. Information about credit cards, pinless debit cards and bank accounts is encrypted and stored in the centralized Payments model. Calling applications (like Order Management and iStore) now simply integrate with the Payments model and do not store any payment-related data locally. In addition to these enhancements, there is support for capturing and validating the Credit Card Security Code for credit card transactions. The security code is however, not stored anywhere in the database.

Features

Oracle Order Management enables you to enter one credit card that can be used as invoice payment on the order header and one credit card for the order line as invoice payment. You can enter multiple credit cards as prepayment, however prepayment can be used only at the order header level.

Credit card and bank account information are now stored in an encrypted format in Oracle Payments. Furthermore this information is masked as well for display purposes. The display / masking of credit card and bank account number is controlled by Oracle Payments. However it is user-definable. The possible masking options that a user can select are:

·         Display last N digits (N – user defined as per requirement)

·         Display first N digits (N – same as above)

·         Display all digits (no masking)

·         Mask all digits (complete masking)

For more information on this and other setup related to Oracle Payments, please refer to Oracle Payments Implementation Guide.

Changes to existing profile options/system parameters

OM: Credit Card Privileges: This profile option is used for controlling the entry of new credit card details, updating existing details, and allowing for manual authorization. The valid values for this profile option are Yes and No. Please note that this profile option was additionally controlling the masking or display of credit card number in earlier releases; in the current release, this profile option is used by Oracle Payments.

Obsoleted profile options:

·         OM: Risk Factor Threshold for Electronic Payments

·         OM: Estimated Authorization Validity Period

·         OM: Number of Days to Backdate Bank Account Creation

·         OM: Payment Method for Credit Card Transactions

·         OM: Process Payment Immediately at Booking?

System Parameter

The system parameter Enable Multiple Payments was used to enable multiple payments for the same order. In the current release the system parameter is always set to on, i.e. multiple payments are always enabled. This means that the users can always invoke the payment windows from the header or the lines and enter payment information.

Payment Types

The Order Management seeded payment types are in use and they now map to the Oracle Payments’ payments methods. In the current release you can disable a seeded payment method. Since Order Management uses its own lookup codes for payment types, only those payment types that map to active payment methods are displayed.

Credit Card Billing Address

Oracle Payments enables you to enter a card statement billing address and this can be set as mandatory. However Order Management passes the bill to address as the statement billing address during credit card creation.

Actions on sales orders that affect Payment information

·         The field label Credit Card Type used in the earlier release of the product would now be called as Card Brand.

·         When a sales order or line gets cancelled or deleted, the payment information would also get deleted in the order header and the payments windows of the header or lines.

·         The copy functionality ensures that payment information is also copied to new orders/returns. In the current release, copying of payment attributes from a source order to a destination order would be supported only when the security code is not set as mandatory. If the security code was set as mandatory in Oracle Payments, when trying to copy an order to a new order, you would have to uncheck the Payments box in the header or line before copying. If you go ahead with the copy, an appropriate error message would be displayed, asking the user to use copy appropriately.

·         In the Order Organizer, you can query for sales orders by credit card number. However, you need to enter the complete credit card number along with other criteria like bill to customer, bill to site, in order to optimize the search. Wild card searches with the credit card number are not supported. The search results would display the credit card number as per the display control setup in Payments Central Security. For more information on this, please refer to the Oracle Payments Implementation Manual.

·         When you change the bill to address on the order header or line, the information in the credit card related fields would be deleted from the Payments table. The information would no longer be shown in the order header or line and you would be required to enter new card information. This also applies to the Header Payments and Line Payments windows; ACH and Direct Debit types are also affected in the same way as they are dependant on bill to address.

·         In the credit card LOV, all credit card assignments belonging to a customer account are displayed. The LOV now displays additional fields like card holder name in encrypted format and expiration date without a value. It displays other fields like card expiration status and bill to org. The LOV is displayed in the figure below:

Note: There is no multi-org impact on credit card information as this information is not org-specific.

Credit Card Security Code

Credit card companies have incorporated new methods of securing transactions in order to ensure safety and authenticity during a transaction. One such precaution is to introduce a security code, a 3 or 4 digit code. The customer is required to verify this code to the customer service representative, in order to validate that he has the card in front of him, thus preventing fraud.

The security code, called CVV2 (by Visa) or CVC2 (by MasterCard) or CID (by American Express) is used to authenticate the cardholder and progress the transaction to authorization. During authorization, the credit card company reserves a credit amount from a customer’s account for an ongoing transaction. The account is not actually charged – that is carried out during the capture phase of the credit card transaction processing cycle. The credit card company issues an authorization code, which the system uses in the capture phase. Additionally, risk management is also carried out after authorization. Risk Management allows you to define any number of risk factors to verify the identity of your customers, assess their credit rating, and manage risk in a secure online environment.

Credit card transactions are validated and authorized by Oracle Payments. The Payments server now stores all credit card related information and Oracle Order Management uses the Process Order API to call the Payments application for credit card related transactions.

Online transactions are handled by iStore and there are 2 ways in which iStore handles the credit card transactions. Depending on the profile option IBE: Perform Payment Authorization in iStore, iStore can now either call the Payments Authorization directly or call Order Capture (ASO) and then Order Management, which in turn calls Payment Authorization. The details of the two scenarios are given below:

1.    When the profile option IBE: Perform Payment Authorization in iStore is set to Yes, iStore calls Payment Authorization to authorize the card. If the authorization succeeds, then iStore calls the Process Order API to create an order in Order Management. If the authorization fails, then iStore does not call the API to create an order. Please note that when iStore calls Payments directly, risk management is not carried out.

2.    When the profile option IBE: Perform Payment Authorization in iStore is set to No, then Order Management calls Payment Authorization. Now depending on the value of the Order Capture profile option ASO: Credit Card Authorization, authorization/risk management will be carried out. If authorization/risk management succeeds, then the iStore order can progress. If authorization/risk management fails, then the order will be put on hold. When ASO: Credit Card Authorization is set to Yes, either of the following flows take place:

o    When the profile option ASO: Enable Risk Management is set to N, ASO: default order status = ‘Entered’ and IBE: Perform Payment Authorization in iStore = ‘No’, the order will be created in entered mode and authorization will be performed at order creation time without risk management.

o    When the profile option ASO: Enable Risk Mgmt is set to ‘Y’, ASO: default order status = ‘Entered’ and IBE: Perform Payment Authorization in iStore = ‘No’, the order will be created in entered mode and authorization will be performed during order creation. In this scenario, risk management is also carried out during order creation.

In order to ensure both the safety and success of the transaction, the credit card transaction needs to be authorized and also risk management needs to be carried out. There are various scenarios in which credit card security code is checked and authorization is carried out. Given below are some common scenarios:

In iStore, customers enter credit card information along with the security code. iStore either calls Payments directly or via Order Capture / Order Management depending on the value of the profile option IBE: Perform Payment Authorization in iStore. In either case, Oracle Payments API is called and it creates a record in the Payments table and generates a unique id for the credit card. iStore passes this unique id to Order Management with other data for order creation. Order Management passes this unique id to Payments to identify the card and perform credit card authorization.

In Order Management, the Sales Orders, Quick Sales Orders and Order Import Corrections windows have a new field – Security Code - in the database. This field is also visible in the Payments window. The security code value is available only temporarily, that too only till the time authorization is done. Once authorization is done, the security code value gets nulled out and is not stored anywhere. Credit card authorization may fail on account of multiple reasons and one possible reason is an invalid security code. However, please note that there are some cornerstone cases where credit card authorization can still succeed even with an invalid security code. It depends on the payment system in use. Please refer to Oracle Payments Implementation Manual for more information on these scenarios.

The following Sales Orders window, Order Header, Others tab shows the new Security Code field. This is a field that can be displayed using the folder functionality. The security code field is also displayed in the in the Payment windows invoked from Order Information Sub-tab and Line Items sub-tab under Orders tab of Contact Center window in addition to its availability in Order Information sub-tab under the Orders tab as shown above.

If you want to run risk management during credit card authorization as an option, you need to populate request type of the action request table p_Action_Request_tbl with G_VERIFY_PAYMENT, the parameter param1 associated this request type will be used to indicate whether or not to turn on or off the risk management. This should be done when calling Process Order API to create or book an order with credit card authorization.

In case there is a credit card authorization failure, the order will be put on hold. Also if the card fails risk validation, Order Management would put the order on hold.

Scenarios	Message Text	Internal Name	Existing / New
Credit Card Authorization success	Payment of &AMOUNT has been authorized	ONT_PAYMENT_AUTH_SUCCESS	Existing
Credit Card Authorization failure on account of payment authorization and the parameter value is set to hold the order on failure	Credit card authorization for this order has failed. The order has been placed on Credit Card Authorization Failure Hold.	ONT_CC_AUTH_HOLD_APPLIED	New
Credit card authorization success but security code related errors	Credit card authorization for this order has succeeded but with security code warning. Order has been put on Hold.	ONT_CC_ SECURITY_CODE_ FAILED	New
Risk management evaluation failure and the parameter is set to hold the order on failure.	Risk management evaluation for this order has failed due to a high risk credit card. The order has been placed on Credit Card High Risk Hold.	ONT_CC_RISK_HOLD_APPLIED	New
Credit Card Attributes validations	Credit Card Security Code is required for credit card payment Credit Card Expiration Date is required for Credit Card Payment Authorization. Credit Card Holder Name is required for Credit Card Payment Authorization. Credit Card Number is required for Credit Card Payment Authorization. Invoice To is required for Credit Card Payment Processing. Unable to set up a Credit Card Bank Account for the Customer.	OE_CC_SECURITY_CODE_REQD OE_VPM_CC_EXP_DT_REQUIRED OE_VPM_CC_HOLDER_REQUIRED OE_VPM_INV_TO_REQUIRED OE_VPM_CC_ACCT_NOT_SET	New Existing messages

The credit card information can also be viewed in the Contact Center window (in the Orders tab) as shown below:

Authorization Flow

The following is an Oracle Payments authorization flow example:

·         During Order Header entry, choose a payment TYPE of Credit Card.

·         The customer's credit card number, expiration date and cardholder's name default in from Receivables Customer information. In Release 12, each credit card account for the customer has a priority, the highest priority is indicated by the lowest number (among the account level and account site level) and is defaulted to Order Management. Also, you cannot override the Primary flag as it does not exist at all in this release, instead, you can change the priority.

·         If the security code is set as mandatory in the Payments Central Security Setup, enter the security code. Enter the rest of the order information, including all the line information and book the order.

·         Order Management calls the Oracle Payments server to obtain authorization for the full amount of the order, including tax and freight and other charges, less commitments.

·         Oracle Payments returns an approval or a denial, along with a risk code. The authorization code is recorded on the order header, and the order proceeds in its workflow. If authorization is denied or an unacceptably high risk factor is returned, Order Management places the order on hold until the problem is resolved.

·         The order is picked and shipped, and during Invoice Interface, the credit card information is passed to Receivables. AR handles the funds capture and all accounting transactions.

·         In Oracle Payments, you can set up the risk score threshold, that determines which transactions are risky transactions.

Prepaid Flow

In Oracle Order Management, you can collect funds for credit card orders at the time of booking, rather than having to wait for Invoicing to occur. The following is an Oracle Payments authorization prepaid flow example:

·         Enter an order and open the Payments window through Actions.

·         Check the prepay flag and enter the required card information. Save the payment information and return to the order header.

·         Enter the rest of the order information, including all the line information and book the order.

·         The customer's credit card number, expiration date and cardholder's name default in from Receivables Customer Information. You can override the credit card and select from other credit cards that have been set up in Customer Bank Accounts for this customer, or enter a new credit card number along with any other required information. You also need to check the Prepay check box, and enter percent or amount of the prepayment amount.

·         Oracle Order Management calls the Receivables Receipt API to capture funds from the credit card and create a receipt for those funds. The amount captured is the amount you entered.

·         Receivables returns a payment set ID that references the receipt that was created. If any error occurs in this processing, Oracle Order Management places the order on hold until the problem can be resolved.

·         At any time during the processing of the order, any Receipts in Receivables tied to this order can be viewed from Order Management by using the View Receipts button from the Order Header Payment window. This action opens the Receivables Receipt window.

·         The order is fulfilled and the credit card information and the payment set ID are passed to Receivables during Invoice Interface. AR matches the receipt with the invoice and performs all accounting transactions.

Types of Authorizations

There are three types of authorizations that can be done from Order Management.

1.    A credit card can be authorized automatically, as described above. For this to occur, the order type must be setup must be set up in such a way that there is at least one credit check rule assigned to either Ordering, Picking/Purchase Release, Packing or Shipping event in the Order Type setup window. The authorization will occur automatically during the Payment Verification processing.

2.    A credit card can also be authorized on-line, by choosing the Process Payment order action from the Action button on the Sales Order window. If this is done, authorization is attempted using the Oracle Payments interface, and the results are processed the same as for automatic authorization.

3.    Problems, such as those with hardware, software, servers or networks, may require an authorization to be obtained manually. This might be necessary because of hardware or software problems with the link to the Oracle Payments server or out to the credit card networks. Some back-end processors return an error instructing the user to call for authorization. In any event, an authorization might be obtained via a telephone call, or a dial-up device. In that case, the authorization code can be keyed on the Order Header, and the order will be considered to be authorized. This Voice Authorization results in a call to Oracle Payments to record the authorization, so that AR can later capture funds against it.

Voice Authorization

Voice authorization is supported both in Payments’ UIs and APIs. There are three fields and their corresponding parameters in the APIs:

1.    Voice Authorization (Yes/No)

2.    Voice Authorization Date (date field)

3.    Voice Authorization Code (free text field)

If a voice authorization is obtained instead of an online electronic one, then the user should set the first field to Yes and enter the other two pieces of data. Oracle Payments then passes that information through when settlement is done.

Manual authorization refers to those approval codes that were obtained outside of the payment system. In Order Management, the manually obtained code is checked to confirm if it is still within the validity period; if so, it is marked as a Voice authorization and sent to Oracle Payments. If it is beyond the validity period, then it is re-authorized as the regular authorization.

Timing of Authorization

The authorization call to Oracle Payments takes place at Booking, if there is a Booking Credit Check Rule set up for the order type. The second authorization takes places in one of the following ways:

·         If the credit check rule is set at Booking and Pick Release Only, the Second Authorization takes place at Pick Release if the first authorization has expired.

·         If the credit check rule is set at Booking and Shipping Only, the Second Authorization takes place at Ship Confirm if the first authorization has expired. In this Case, there is NO Authorization during Pick Release because no Credit Check Rule is set at Pick Release.

Authorization Results

The authorization call to Oracle Payments returns a success or failure, as well as a risk code. The authorization code can be viewed by users with appropriate security. If an authorization fails, the order is placed on Credit Card Authorization Failure hold. If the authorization was done on-line or at Booking, you will be notified of the failure by a message. The message will indicate the type of error encountered, such as communication error, invalid credit card . If there was a communications error, the action can be retried using the Action button. An invalid credit card error can be remedied by changing the credit card information and then re-authorizing using the Action button.

Returns and Mixed Orders

In Order Management, you can use a credit card as a Payment Type on returns and also on mixed orders – that is, orders containing both outbound and return lines. In the case of mixed orders, the amount authorized is the total amount of the outbound order lines, not the net of outbound and inbound. For pure return orders, a credit card number can be recorded, but no processing is done with it in Order Management. The credit card information is passed to Receivables for return lines. The payment type on the return in Order Management is ignored in Receivables, and if the order was originally paid with a credit card, then that same card will be refunded for credit. If you set up your system to automatically manage receipts when importing credits, then the automated receipt handling process occurs as follows:

·         AutoInvoice reviews the transaction batch source for each submission, to determine if automated receipt handling is enabled.

·         If enabled, then AutoInvoice evaluates each credit memo and its associated invoice to determine eligibility for automatic receipt handling. To be eligible, the paid invoice’s transaction type must be set to allow natural application only. Additionally, the transaction must not be in doubt.

·         If eligible, then AutoInvoice unapplies the paid invoice (original transaction) from the receipt to be credited.

·         AutoInvoice automatically creates the credit memo in the amount of the requested credit, and applies the credit to the correct invoice.

·         If your policy is to automatically refund your customers, then AutoInvoice evaluates the receipt for refund eligibility. To be eligible, the receipt must not be in doubt.

·         Finally, AutoInvoice applies the appropriate receivable activity to the receipt, as determined by your batch source setup.

Copy Orders

Copy Orders has been enhanced in Order Management to give a choice whether or not to copy credit card information when an order header is being copied. There is a check box on the Copy Header window called Credit Card details where you can indicate your desire to copy. Data to be copied are Credit Card Number, Card Holder's Name, Credit Card Type and Expiration Date. This check box is enabled only when you have All or Limited credit card privileges, as set in the profile option. The check box is seeded as unchecked to allow users to make a conscious decision to copy such information.

Order Changes and Partial Shipments

Authorization Flow

Credit card authorization is obtained for the authorized amount. If the order changes after authorization result in the amount being decreased, no further authorization occurs. If the order total increases, another authorization is done if the previous authorization is still valid. Oracle Payments no longer supports void transactions, so in order to not block excess funds which would occur if multiple authorizations are done, reauthorization is done only if the previous authorization has expired. If an order is authorized and then only partially shipped, the shipped amount may go to Receivables for capture before the backordered quantities ship. If that occurs, Receivables captures only the amount of the shipped lines, using the original authorization code. An authorization code can only be used once for a capture transaction. When the remainder of the order is Shipped (Pick Released), a check is made to see if there is an unexpired and uncaptured authorization on the order. If not, then the remaining amount is authorized again. See the examples below for further clarification.

Prepaid Flow

Credit card funds capture takes place for the total order amount minus commitments. If order changes occur after the funds capture occurs, Oracle Order Management calls the Receivables Receipt API to create incremental receipts or creates refunds, if the order amount is reduced.

Holds

Authorization

There are two holds seeded in Order Management for credit card authorization processing:

·         Credit Card Authorization Failure is applied if authorization fails

·         Credit Card High Risk is applied if authorization is successful but the risk score is higher than the threshold set in Oracle Payments.

Both of these holds can be released manually, but can be reapplied automatically if a subsequent authorization fails. These holds can be removed with a manual authorization.

Prepaid

There are three holds seeded in Order Management for the Prepaid Credit Card feature:

·         Pending Process Payment is placed if an order needs to have a Receipt processed asynchronously

·         ePayment Failure is placed when a failure occurs in the capture and receipt creation process that needs human intervention to resolve

·         ePayment Server Failure is placed when an error occurs in the capture process. This error allows you to retry the capture process.

Note: The credit card bank account needs to be set up correctly in Payments for authorization to take place. If it is not set up correctly, an ePayment Failure hold is placed. So if the Payments server is unavailable and the bank account is not set up properly, the hold that is placed is the ePayment Failure Hold and not the ePayment Server Failure hold. This is because Receivables is checked first for errors/failures.

The concurrent program Credit Card Process Pending Payments can be scheduled to process ePayment holds.

Risk Management

Oracle Payments has a Risk Management feature, that can help manage exposure to questionable transactions. You can define any number of risk factors to verify the identity of your customers, assess their credit rating, and manage risk in a secure online environment. Set up these factors and a risk calculation formula when you set up Oracle Payments. Authorizations from Order Management use the default risk formula setup in Oracle Payments. Authorization returns a risk score, in addition to an authorization code. The score can range from 0 to 100, with 0 referring to a risk free transaction and 100 referring to a high risk authorization. If the risk score exceeds the risk threshold you have set up in the corresponding profile option, the order is automatically placed on Credit Card High Risk hold.

The profile option OM: Risk Factor Threshold for Electronic Payments has been obsoleted in the current release and now risk management is handled by Oracle Payments. Orders are checked for high risk and compared to the risk score returned by Payments. If the risk score exceeds the risk threshold, then Order Management initiated orders would go on high risk hold. For more information on setting up risk management, please refer to the Oracle Payments Implementation Manual.

For Order Management you can get the risk management evaluation results even if credit card authorization has failed as this is derived from Payments. For iStore, risk evaluation may be turned on or off depending on the parameter value.

Scenarios

·         In case authorization is carried out successfully and there is a security code warning, the order would be placed on hold.

·         In a situation where authorization is carried out successfully and there is no security code warning, risk evaluation is done. The order is placed on credit card high risk hold if the risk score exceeds the threshold.

·         If authorization is carried out and error messages like “Authorization Declined”, “System Error” or “Developer Error” are displayed, then the order is automatically placed on Order on Credit Card Authorization hold.

Importing Orders and CRM Integration

You can import orders with a payment type of credit card. There are columns in the payment interface tables for all of the credit-card related data. You can import orders that are already authorized by populating the authorization code and authorization date columns. This supports the business case where you might have a legacy system or some other feeder system that has already done the authorization sending orders into Order Management for fulfillment.

Similarly, orders coming from CRM or other front-end systems that have been pre-authorized can be entered into Order Management via the Process Orders API. Those orders will not be re-authorized, unless re-authorization is needed at Shipping or because of increases in the order value after authorization.

Commitments

Commitments are a type of prepayment transaction recorded in Oracle Receivables. Order Management enables you to specify that a line is to be paid from funds paid from a commitment by selecting a commitment number, and optionally, an amount on the order line. If commitments are used on orders that have a payment type of credit card, the amount to be authorized or collected is the total order or line amount minus the commitment amount on lines with commitments. This supports the business case where some lines are prepaid with commitments and the customer gives a credit card number to cover the amount of the order not paid by the commitment.

Set Up

To use credit card authorization in Order Management, you must install and set up the Oracle Payments server which in turn communicates with the credit card provider networks. In addition, create at least one Credit Check Rule in Order Management and set up your order transaction types to use Credit Checking. Credit Card authorization will not occur automatically unless a credit card rule is present on the order type.

See: Oracle Payments Implementation Guide

Oracle Payments Concepts and Procedures

Payment Terms

If you use the Prepaid Credit Card feature, you must set up at least one Payment Terms in Receivables with the prepaid credit card attribute checked. Oracle Order Management only invokes the Prepaid Credit Card processing if the order header payment terms is a prepaid payment terms. If an order has a header payment terms indicating prepaid credit card, then any payment terms at the order line level are ignored. They are not even passed to Receivables at Invoice Integration.

There are two ways to create a Prepayment in Release 12:

·         Enter a Prepaid Payment Term in the Order Header, and a prepayment record is created automatically.

·         In the Payments window, you can create Prepayments by selecting the Prepay box.

Lookups

There are several OM lookups that are used by Credit Card authorization. There is an OM lookup for Credit Card Type— this is seeded with the most common credit card types such as AMEX or Visa. You can extend this list.

Oracle Payments Setup

There is an entire manual devoted to implementing the Oracle Payments server. Several critical things to setup that influence Order Management are the risk management factors and formula and the merchant bank account. Other setup information can be found in the Oracle Payments Implementation Guide.

Reports

There are no new or existing reports in Order Management that list credit card information.

Implementation Considerations

Credit Checking

A credit check rule must be assigned to one of the credit checking events (Booking, Shipping, Picking/Purchase Release or Packing) in Order Type set up. It is not mandatory for credit checking to be active, as other setup steps are involved in activating credit checking. However, Authorization requires that a credit check rule be assigned in the Order Type setup.

Encryption

The masking of credit card information is now controlled by Oracle Payments.

Under Authorization

Order Management can have multiple active authorizations per order at any given time. If the order value increases on an order with an unexpired and uncaptured authorization, Order Management does not perform additional authorization. Because of this, it is possible that insufficient funds may be available on the credit card for the order when it gets to AR for capture. AR will still attempt to authorize and capture the full amount if the invoiced amount exceeds the authorized amount.

If it is a common practice in your business to have users add products to credit card orders after they have been authorized but before the typical authorization expiration, you will need to assess the risk of non-payment. If this is deemed to be an issue, you might want to adopt a practice of requiring that users create new orders for the additional lines or quantity, so that those amounts will be authorized.

If Oracle Payments is not Installed

If Oracle Payments is not installed, but a payment type of credit card is entered on the order, Verify Payment does not return an error or place the order on hold. The Authorize Payment action on the Action button will not be available. The only way to authorize a credit card without Oracle Payments or customization is to manually enter the authorization code. In effect, if you don't have Oracle Payments installed, the credit card fields on the order header are for information only. Credit card data is passed to Receivables; however, even if Oracle Payments is not installed, which may cause problems in Autoinvoice.

If you don't have Oracle Payments installed and you don't want to take the risk of entering credit card information that is not used, you can set up a Processing Constraint to prohibit users from saving data to the credit card fields. SeeProcessing Constraints for more information.

Oracle Order Management always treats credit card information as automatic payment. It is therefore recommended that you should not enter any credit card information in the sales order if the provided credit card information is not intended for automatic payment. You can make use of order or line level descriptive flex fields if credit card information is intended for information purposes only.

Debugging Tips

If you are experiencing problems getting the Oracle Payments integration to work in your environment, it can be very helpful to Oracle Support if you generate a log file of what is happening. Here are specific steps to generate a debug file while reporting Oracle Payments integration issues:

1.    Log into the application using a new session.

2.    Open the sales order window and query the order.

3.    From Tools menu click Debug.

4.    Choose Turn Debug On.

5.    From Tools menu click Debug.

6.    Choose Initialize Debug Cache.

7.    From Tools menu click Debug.

8.    Choose Write to a File. Make a note of the default file name—you cannot change it. Debug messages are logged into this file.

9.    Perform the steps which are failing—in this case it may be payment authorization through booking/ picking/ manual.

10. Turn debug off.

11. Provide the debug file to Oracle Support.

Examples

The following examples assume an order type that has a Credit Check Rule assigned for both Booking and Shipping.

Note: These are authorization-only examples and do not apply to prepayment orders or orders with line level payments.

Simple order: Consider the case of a simple order that is authorized at Booking, pick released and shipped complete within one week with no changes to the order. One authorization is obtained for the entire order at Booking. No further authorization at Shipping occurs, because an unexpired and uncaptured authorization existed. The entire order interfaces to Receivables at one time. Receivables does the funds capture against the original authorization code.

Partial Shipment: This order consists of one line for a quantity of 10 with an extended amount of $1000. The authorization obtained at Booking is for $1000. Only 3 of the quantity of 10 is picked and ship confirmed and interfaced to Receivables. The remaining 7 were backordered. What occurs when the remainder of the order is pick released depends on whether Receivables has captured against the original authorization. If so, AR captures $300 against the first authorization. At Pick Release of the remainder of the order, a new authorization is obtained for $700 – the amount uncaptured. If AR has not done a funds capture at the time of the second Pick Release, OM will not reauthorize if the original authorization had not expired. Whether or not an authorization has had funds captured is determined by calling an Oracle Payments API.

Cancellations: Consider the same order as in Partial Shipments above. However, after Booking, but before interface to Receivables, the order is cancelled. If the entire order is cancelled, OM will do nothing and the authorization will just be left to expire. On the other hand, if the order is partially cancelled, the part that is shipped and interfaced to Receivables will capture against the original authorization code but for the amount shipped. The remainder—the amount canceled—will never authorize, as it has been canceled.

Mixed Order: This order consists of one outbound line for $200 and one return line with a value of $50. Therefore the order total is the net or $150. The authorization at Booking will authorize for the full $200.

Migration/Upgrade

There is no special upgrade performed for orders containing credit card information. Credit card information from old Order Entry orders are copied to the upgraded order. If the new upgraded order goes through Booking or Shipping and there is a credit check rule on the order type, then authorization is attempted.

Multiple and Partial Payments

Overview

Oracle Order Management's multiple and partial payment features allow additional types of payment vehicles and specification of a payment type at the line level. Also multiple prepayments can be processed at the order header level, to provide support for down payments. This increases support for Business to Consumer flows, reduces risk in collection of payments, and enhances flexibility in the payment of orders through use of multiple credit cards, electronic payment options. Major features include the following:

·         Additional payment types supported:

o    Wire Transfer

o    Purchase Card

o    Automated Clearing House transaction (ACH)

o    Direct Debit

o    Cash

o    Credit Card

o    On-account (or PO)

·         Window to enable Payment Types and input optional attributes

·         Window of payment information for an order or line

·         Prepayment data input for an order: Create multiple prepayments for a partial amount of the order total or for the full amount. Oracle Order Management creates one or more Accounts Receivable receipts linked to the order, for later application to the invoice when it is created.

·         Workflow activity for Payment Assurance: Verifies that a prepayment has been collected before you ship, for example.

·         Ability to enter one payment instrument (in addition to a commitment) at the line level, as long as there are no prepayments on the order.

·         Quick Receipt document that can be printed and handed to a retail customer.

·         Enhanced Credit Card Authorization for Installment terms. Oracle Order Management provides an option to authorize the first installment only instead of the total order amount.

·         Batch authorization of Credit Cards, including automatic retries of authorizations that fail due to network outages.

·         Ability to create multiple payments and prepayments using Order Import.

·         Ability to copy order or line with payment information.

Profiles

Existing profile options related to Credit Card Processing must be set up appropriately when using multiple and partial payments.

Setup

Multiple Payments

1.    The system parameter Allow Multiple Payments is always enabled by default in Release 12. It is not visible in the System Parameters window for updating.

Adding new Payment Types or Deleting seeded payment types is not allowed. Payment Types are Operating Unit (OU) specific. Changes made in one operating unit are not replicated to other Operating Units. Order Management seeds only those payment types that are supported in Oracle Receivables and Oracle Payments.

Note: If payment types are not displayed for your Operating Unit, run the “Replicate Seed Data” concurrent program from the System Administrator responsibility.

Payment Types Setup Window Details

Payment Types window

o    Operating Unit:This shows your default Operating Unit. You can pick a different Operating Unit from the LOV which displays all Operating Units accessible to you via your MO: Security Profile. Thus you manage payment types across multiple Operating Units that are accessible to you.

o    Payment Type Code: Payment Types supported. You cannot change the entry in this field, but you can change the description and the Payment Type name.

o    Receipt Method: Assign a pre- defined Receipt Method to the Payment type. This payment method will be used on the Invoice to collect the open balance. You can update this field.

The Receipt Method that is assigned to the check payment type has a creation method of Manual, because that is validated in Order Management. The Accounts Receivables Receipt API handles Manual or Automatic Receipt Methods. The Automatic creation method is reserved for the Automatic Receipts program in Accounts Receivables, which is the automatic generation of receipts from the Invoice document flagged with an Automatic receipt method.

Please refer to the section Setting up Accounts Receivable for Multiple Payments in the payments chapter.

o    Start Date: Effective Start Date for payment type. You can update this field.

o    End Date: Effective End Date for payment type. You can update this field.

o    Defer Payment Processing: Y/N decides if this Payment Type should be processed in deferred mode for performance gain. You can update this check box.

o    Credit Check: Y/N decides if this payment type should go through Credit Check or not. This is an additional setup required for Credit Checking to occur if you are using the prepayments functionality. You can update this check box.

Payment Types supported and additional information required on the transaction

o    Credit Card / Purchase Card: Specify Credit Card Number, Credit Card Holder Name, Expiration Date, Type of Card

o    ACH: Specify Bank Number, Account Number, Account Holder Name, Account Type

o    Direct Debit: Specify Bank Number, Account Number, Account Holder Name, Account Type

o    Wire Transfer/EFT: Supported for Invoice Payment Only

o    Check: Specify Bank Account Number, Check Number. Note that if you use Check for a prepayment, you cannot use the lockbox to process the check.

o    Cash: cash

When the payment type on an Order Header is NULL Send an Invoice is implied. In addition, the PO number can be entered on the Order Header.

Specify Commitment Number (Supported for Line level payments)

o    Available only at the line level and Only one commitment per order line

o    The Commitment Promised Amount can be updated.

o    Commitment is not included as a Payment type and cannot be used for Down Payment.

Multiple Payment Types for down payment are at the order level only. If there is a pre payment/down payment on the Order, you cannot specify any payment types at the order line level. If there is a pre payment on the order, the View Line Payments button on the Payments window is greyed out and the Payments Action on the Lines tab is not visible.

For Orders without down payment you can choose ONE additional payment type in addition to a commitment PER order line. Only one payment instrument in addition to Commitment can be used for the balance of an order line.

Defer Prepayment Processing and Credit Card Authorization:

Payment can be processed first at Booking. However you can defer prepayment processing by setting the Defer flag on the Payment Type to Yes. You can override the defaulted value of the flag at the transaction level on the Payments window for more granular control.

The Defer flag represents both Prepayment Processing and Credit Card Authorization. Setting that flag to Yes defers both payment processing and credit card authorization.

Once flagged for deferred authorization, Order Management defers the call to Oracle Payments for credit card authorization. A Pending Payment Authorization hold is placed on the order/line.

If you use a Credit Check Rule at shipping the Defer flag is not applicable, as Credit Card Authorization is executed regardless of the setting of this flag.

Credit Check

For Credit Checking to occur on orders with Payment Types, this flag must be set to Y on the Payment Type, in addition to setting Credit Check = Y on the Payment Term, Order Transaction type and the Customer Profile.

Set up Prepayment Payment Terms. Payment Terms can be set up in Order Management. Navigate to Setup > Orders > Payment Terms. Optionally you can also set up Payment Terms from the Oracle Receivables Super user menu.

Payment Terms Window

A selected check box for Pre Payment in setup implies that when the payment term is used on the Order Header for pre payment, a suggested prepay amount is defaulted on the Payments window. The calculation for the suggested prepay amount is based on the first installment setup for the prepaid payment term.

During order entry the List of Values (LOV) for payment terms also displays Pre Paid / Non Prepaid flag. If a non prepaid payment term is used on the order header, user can still enter a prepayment amount to record a prepayment on the Payments window.

For down payments only the header level payment term is used to determine the suggested down payment amount. Users can manually override this amount on the payments window during order entry.

For pre paid payment term with installments you must set up the first installment to be the down payment.

Oracle Receivables supports early pay discounts when using prepayments on remaining installments other than the down payment. Tax is not accounted upon collection of down payment, and revenue is not recognized.

Note: IA prepayment term with an installments calculation of a suggested down, assumes the usage of “Allocate Tax and Freight” across the Installment instead of “Include Tax and Freight in first installment.”

2.    Create a transaction type with Payment Assurance activity included in the line workflow. It is possible to include Payment Assurance workflow activity within your line level workflow.

Payment Assurance in line level workflow

This optional workflow activity ensures that the receipt must be in a specific receipt status depending on the Payment Type before an order line can progress. You can set up workflow or extend seeded line flows to insert this activity at any point between booking and invoicing. It is recommended to add it before Shipping. With this activity in the flow, the order line does not progress unless the Pre pay Receipt is in an appropriate status depending on the Payment Type used. This ensures reasonable assurance of collection of down payment.

See: Define Order Management Transaction Types.

3.    Decide if you want to print the Payment receipt document and how you want to launch it. Create a transaction type with Payment Receipt Printing activity included in the order workflow. This optional step creates a document as a payment receipt when funds are collected along with the order. Note: Funds are not necessarily collected, and this shows only the prepayment processed. The three ways to create the Payment Receipt document are:

o    Option 1: Include the “Print Payment Receipt” function within the workflow. Use this option if you always want to trigger printing a Payment Receipt. Usually, you would put this right after booking in the Order flow.

§  Option 2: Launch the new report Payment Receipt with parameters Order Number or Order Type using Run Reports. Use this option if you do not want to Print Payment Receipts for every order.

§  Option 3: It is also accessible through Actions at the Order level.

The Print Payment Receipt action is available only if the function Sales Orders: Print Payment Receipt is attached to the OM Menu

4.    You can define Defaulting on the following attributes using the Defaulting Framework (payment_type_code, Receipt_method_id, Payment_collection_ event). Defaulting Rules are seeded for the entities Order Payment and Line Payment, Receipt Method, and API Based Defaulting:

o    If a value exists in the payment type setup, then this value defaults to the payment record.

§  Otherwise, for Credit Card and ACH payment type, look at the primary payment method defined for the customer site.

§  Otherwise, for Credit Card and ACH payment type, look at the primary payment method defined for the customer.

§  Otherwise, for Credit Card payment type only, please refer to Oracle Payments functionality.

Note: Payment method and customer bank account ID is defaulted at payment creation time. These are required at Booking for Credit Card and ACH. Payment Level code is defaulted at Payment creation time.

5.    See: Define Defaulting Rules.

6.    Set up Processing Constraints.

Seeded Processing Constraints

For prepayments, when payment has been processed and the receipt has been successfully created:

o    Payment information cannot be updated except for the amount, which can be adjusted to a higher or lower value

§  Payment information cannot be deleted

§  Cannot change the following attributes on the order header – Transactional Currency, Invoice To Customer, Invoice To Address, Payment Type

§  Payment number is system generated and cannot be updated

For header level invoice payment, the payment information cannot be changed if at-least one order line has been invoice interfaced.

For Line level payment the payment information cannot be changed if the order line has been invoice interfaced.

For Invoice payment using credit card, credit card related data cannot be changed when authorization has been completed.

Note: It is not required to provide a payment instrument at Order Entry. Null is allowed as the payment type. A constraint can be set up so that a not null form of payment type must be provided at order entry.

Constraints can be defined on other attributes using the constraint framework. Available attributes include:

o    Payment Type Code

o    Commitment Applied Amount

o    Credit Card Code

o    Credit Card Number

o    Credit Card Holder Name

o    Credit Card Expiration Date

o    Credit Card Approval Code

o    Credit Card Approval Date

o    Receipt Method Id

o    Payment Collection Event

o    Check Number

o    Payment Amount

See: Define Processing Constraints.

7.    Schedule the Process Pending Payment concurrent program. Payment Processing can also be triggered by running this program standalone or in batch mode. Navigate to the Submit Request window. Order Management > Reports, Requests > Run Requests.

Submit Request Window

8.    In the Name field select Process Pending Payment from the list of values.

Process Pending Payments Parameters Window

The Process Pending Payments concurrent program can be used to process the following in batch mode:

o    Credit Card Authorization Only (non – Prepayment): Process those orders that have no pre payments on the order and have a Pending Payment Authorization hold on the Order/Line

§  Pre Payment Processing only: Process those orders which have a pre payment on the order and have a Pending Process Payment hold on the Order/Line

§  Both Pre Payment and Non Prepayment processing: Process those orders that have a Pending Payment Authorization hold or Pending Process Payment hold on the Order/Line

You can submit this program to run a specified number of times or at regular intervals to process payments asynchronously without manual intervention. This setup is optional.

Note: The Process Payment action from the Sales Orders window processes all pending payments for the current order including prepayments processing and credit card authorizations. It behaves like the Pending Process Payment concurrent program with the parameter selected as Both Pre Payment and Non Prepayment processing.

Credit Check for Orders with Prepayment

Order Level Credit Check

Pre-paid amount for any payment type, is subtracted (in addition to commitment applied amount) from the total order value during credit checking. All other credit checking controls are still honored.

Line level Credit Check

For orders with down payment, the pre paid amount is not subtracted from the total order value. Only the commitment applied amount is subtracted from the line total.

Note: Calculation of Overall Credit exposure is not impacted by prepayments functionality, regardless of whether or not AR balances are included in the total exposure calculation.

Credit Card Payment Type

When Credit check flag is on: Credit Check and authorize open balance.When Credit check flag is off: Authorize open balance only.

Credit Checking is re-executed upon subsequent payment processing.

Pre Payment Holds

·         Pending Process Payment Hold: Relates to all cases where Process Payment activity is Pending.

·         Epayment Failure Hold: For expected errors returned by Oracle Payments, like invalid data.

·         Epayment server failure Hold: For any unexpected errors returned by Oracle Payments, like failure to connect to server.

o    Process Pending Payments concurrent program (batch mode)

o    Process Payments Action (manual action from sales order form - per order)

o    At Booking (Booking triggers Process Payments)

For credit card payment at header level, the amount to be authorized at the header level is equal to the Order Total, charges and estimated taxes included, minus the total prepayment, minus the line totals of commitment applied amount, and the amount covered by other payment instruments.

For credit card payment at the line level, the amount to be authorized at the line level is equal to the Line Total, charges and taxes included, minus the commitment applied amount.

For authorization to occur you must turn on the credit check rule as appropriate, such as those for Booking.

Overpayment

If the prepayment amount collected is higher than the total open balance a warning message is displayed and payment is processed successfully.

Note: Once a down payment amount has been processed any changes that increase or decrease the Order total will not automatically result in an additional Receipt/Refund. The prepaid amount must be manually set to a higher value for more collection, and the Process Payment Action must be executed or the Process Pending Payments program must be run.

Setting up Accounts Receivable (AR) For Multiple Payments

Receivables Activity is set up in Oracle Receivables. Receivables activity of type Prepayment must be set up. Once an order with prepayments is Booked, Payment Processing is triggered automatically provided Defer flag was unchecked on the Payments window prior to Booking. A prepayment receipt is created in Oracle Receivables. This prepay receipt is applied to the Prepayment Receivables Activity. The Receivables Activity of type Prepayment is a placeholder application until the Order is Invoiced and the Invoice and Prepayments are matched. Upon matching, the Prepayment is unapplied from the Prepayment Receivables Activity and applied to the Invoice to close out/reduce the balance of the Invoice.

See: Oracle Receivables Implementation Guide.

Setting up Remittance Bank Accounts

Navigate to Bank Accounts from the Receipt Class / Payment Method window. The attribute for the Remittance Bank should be the Minimum Receipt Amount. Before creation of a Receipt for Pre payment, the system validates that the Receipt creation amount is greater than the Minimum Receipt Amount of the Remittance Bank. If the receipt creation amount is less than the Minimum Receipt Amount then a prepay receipt is not automatically created. In such a case, the order is not placed on Pending Payment Process hold.

See: Oracle Receivables Implementation Guide

Copying Orders with Payment Information

The Payments check box on the Copy Header and Copy Lines tabs of the Copy window allows you to copy payment information. Please note that if the Credit Card Security Code is mandatory, then the order will not be copied with all the credit card attributes. If Credit Card Security Code is not mandatory, then the order will be copied with all the credit card attributes.

Copy Header Tab of Copy Window

The default value for this check box is Unchecked. The payment types are copied from the source order but the amounts are not.

Copy Lines Tab of Copy Window

Copy of payment information is available for Outbound orders only.