Invoicing and Payments

Invoice Processing

Overview

Invoice processing in Order Management is the process by which data from Orders and Returns is interfaced to Oracle Receivables for the creation of invoices and credit memos to recognize revenue and manage sales credits.

Within Oracle Order Management, invoice processing has been implemented as a workflow activity (Invoice Interface). The Invoice Interface activity collects order, return, and freight charges information from Order Management tables and transfers this information to Oracle Receivables Interface tables. Data elements such as item description, ordered quantity, unit list price, total amount, payment methods, warehouse id, and sales credit are transferred via Oracle Receivables Interface tables, and upon completion the Invoice Interface activity, the Oracle Receivables concurrent program AutoInvoice must be submitted to import the invoice and credit data into Oracle Receivables.

Note: Return orders without reference information of the sales order or invoice will result in on account credits.

For additional details on interfacing transactions to Oracle Receivables, please refer to Oracle Receivables Implementation Guideand Oracle Receivables Reference Guide.

For more information on Invoicing and Credit Memo creation, please refer to the Oracle Receivables User Guide and the Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide.

Invoice Level Processing

Oracle Order Management supports invoice processing at 2 levels:

  1. Order Header level Invoicing

    The Order Level Invoice Interface workflow activity is part of the Order Header workflow process. It will interface data from the entire order or return to Oracle Receivables at the same time.

  2. Order Line level Invoicing

    The Order Line level Invoice Interface workflow activity is part of the Order Line workflow process. It will interface data from each line or set of lines as to Oracle Receivables as they become eligible for interface.

    Note: Grouping of orders or order lines for invoicing or credit memos is dependent upon the mandatory Grouping Rules and optional Grouping Rules you setup in Oracle Receivables. There is no grouping done by the Order Management Invoice Interface Workflow activity.

    Order Management Invoice Interface Activity

The Oracle Order Management' Invoice Interface workflow activity enables you to:

The Order Management Invoice Interface activity interfaces sales order line details to Oracle Receivables. Order lines with any of the following conditions are not eligible for invoice interface:

  1. Item with Invoiceable attribute set to No or

  2. Item with Enabled Invoicing attribute set to No or

  3. Included item type or

  4. Configure item type or

  5. Service item where the serviced item is not serviceable or

  6. Internal order

For all conditions listed above, the Invoice Interface workflow activity is completed with a status of Not Eligible.

Order or return lines will not be interfaced to Oracle Receivables if there is a hold on the line or on the order. When the invoice interface activity encounters a order or return line with a status of On Hold, the Invoice Interface workflow activity will also complete with a status of On Hold. You can perform the manual ‘Progress Order' concurrent program to continue with the order processing, or the order or return line will automatically be re-evaluated at a 12 hour interval after the hold is released.

The workflow activity Fulfillment must be placed prior to the Invoice Interface activity for Required for Revenue cases. Order Management performs the Invoice Interfacing activity for orders with partial shipped quantity in Required for Revenue cases at the order line level only.

Discount Information

Invoice Interface activity interfaces price adjustment information to Oracle Receivables. You have an option to print detail discount information.

For example, suppose you had an order line with the following example data and the profile option OM: Show Discount Details on Invoice is set to YES.

The table below lists example order line details and what will be displayed on a Oracle Receivable invoice for the data listed above.

Example Order Line Details
Line Description Quantity Unit Price Extended Amount
1 Item A 2 100 200
2 Discount Name 1 2 < 10 > < 20 >
3 Discount 2 2 < 15 > < 30 >
Order Total - - - 150

Note: Column Extended Amount for Line 1 within the table above does not include the discount amount on the invoice line.

Now, suppose the profile option OM: Show Discount Details on Invoice is set to NO. No detail information relating to discounts will be displayed on the Oracle Receivables invoice, but you will be able to view the Amount Paid per invoice Line. The table below lists example order line details and what will be displayed on a Oracle Receivable invoice for the example data listed above.

Example Order Line Details
Line Description Quantity Unit Price Extended Amount
1 Item A 2 100 150
Order Total - - - 150

Note: Column Extended Amount within the table for Line 1 does include discount on the invoice line, but no additional details.

Charges Information

The Invoice Interface activity also interfaces order or return charge information to Oracle Receivables. However, Order Management currently only interfaces the charge lines as invoice header level charges. With Order Management;

Order Management passes detail charges information to Receivables, but you will not be able to view individual charges on the invoice itself.

For Example, an order with the following information is invoiced:

Order #123 consisting of one order line with order Freight Charge of $5.

For Order #123, Line#1: Item Number = ItemXYZ, Qty = 1, Price = $100. The order line has a Freight charge $10, and additional charge (insurance charge) of $3.

Oracle Order Management will interface 3 charge lines:

The 3 charge lines will be transferred individually to Receivables, and then be consolidated within Receivables as a single order charges. (total of $18)

Invoice #500 for Order #123:

Delivery Based Invoice Numbering

The Invoice Interface activity interfaces invoice number based on delivery name to Oracle Receivables if the profile option OM: Invoice Numbering Method is set to Delivery.

Required for Revenue

The Invoice Interface activity interfaces full or partial quantity of a line where there is a Required for Revenue component on the Bill of Material. The activity also prevents the parent item from invoicing until the Required for Revenue component has been shipped.

Viewing Invoice Information

Invoice data, such as Invoice Number, Batch Source, Invoice Date, Amount and Balance, can be viewed under:

Profile Options

The table below lists profile options that will affect the operation of the Order Management Invoice Interface activity.

Profile Options Affecting the Operation of the OM Invoice Interface
Profile Option Name Usage
OM: Invoice Numbering Method Determine whether to use automatic invoice numbering, or to use delivery name numbering.
TAX: Inventory Item for Freight Invoice Interface activity interfaces this item for freight charges treated as revenue lines.
TAX: Invoice Freight as Revenue Determine that freight charges are treated as revenue lines, and Invoice Interface activity interfaces VAT tax information and sales credits for them as well.
TAX: Allow Override of Tax Code Determine whether or not to interface VAT tax code information.
OM: Credit Salesperson for Freight on Sales Determine whether to pass dummy sales credits or order line/header sales credits for freight lines when freight lines are interfaced as revenue lines.
OM: Show Discount Details on Invoice Determine whether or not to print detail discount information on the invoice.
OM: Invoice Source Value is interfaced to Receivables if no value is defined at OM Transaction Type.
OM: Non-delivery Invoice Source Value is transferred to Receivables if OM: Invoice Numbering Method is set to Delivery and line is non-shippable.
OM: Invoice Transaction Type Value is transferred to Receivables if no value is defined at OM Transaction Type.

The system parameter Overshipment Invoice Basis determines whether to interface ordered quantity or shipped quantity for overshipment.

For additional information surrounding the user of the profile options and system parameter listed above, see Order Management Profile Options in the Oracle Order Management Implementation Manual.

Detailed Order Statuses for Invoicing

The order line status is now enhanced to provide complete information concerning the status of the line with regard to the Invoicing Activity. Formerly the line status included Interfaced to AR and Partially Interfaced to AR, now the line status details the reasons why the line has not progressed.

Multiple and Partial Payments Overview

Multiple Payments enhances the payment options for orders, replacing the single payment type option at the order header (with the exception of Commitments) for example, cash, check, credit card, or null. Now you can specify multiple payment types for a single order. This change enables other payment options like Purchase-cards, direct bank transfer, etc. Other business situations include:

Order Management enforces that, if there is prepayment, you are not allowed to specify another payment type at the order line level. Order Management also enforces that credit check for commitment is set to No, the commitment applied (promised) amount is always excluded from credit check exposure.

Note that there is no enhanced payment support on EDI/XML standards.

Multiple and Partial Payments Major Features

Tax Issues and Prepayments

Prepayments that are collected via the Receipts API do not make accounting entries for tax. This can be an issue in countries (especially VAT countries) where the receipt of money is a tax event. In those cases, to be totally correct from an accounting point of view, prepayments cannot be used.

Order Management will not disallow use of prepayments in these countries. It will be the responsibility of the deploying company to ensure they conform to tax law.

100% prepaid and the Multiple Payments Prepayment Functionality

In the multiple payment support, changes in order value will not automatically trigger receipt creation or refund. The process must be done manually, where users need to adjust the prepaid amount manually.

Note: We do not support automatic receipt creation or refund when order values change.

Payment Features

Multiple Payment Types Per Order

Order Management will allow orders to be paid for with multiple payment types or multiple occurrences of the same payment type (as in multiple credit cards) in a limited way in this release.

Note: Order Management will support Multiple Payment Types at the order level only and only for Prepayments.

Notes on Payment Terms in Order Management:

Possible payment types currently supported include:

Order Management will only seed the payment types that AR and Oracle Payments supports.

These instruments are supported for prepayment collected in Order Management or invoice payment collected in AR.

In addition, you can enter a PO number on the order header.

Note on Commitment:

  1. Commitment is available at the order line level only. Only one commitment can be specific per order line.

  2. You can update the promised commitment amount.

    The promised amount entered must be:

  3. equal to or smaller than the total order line amount,

  4. and equal to or smaller than the available balance on the commitment.

  5. Commitment cannot be used for prepayment or down payment.

    Down payment or prepayment can be paid using one or more supported instruments listed above. However, only one payment instrument, in addition to Commitment, can be used for the balance on an invoice.

  6. Revenue is not recognized upon collection of down payment.

  7. Tax is not accounted upon collection of down payment.

Payment Processing

During payment processing, the following occurs:

How does Order Management calculate the amount for prepayment and credit card authorization?

Prepayment:

Credit Card Authorization:

Subsequent payment processing can be triggered only by the following:

There is an attribute on the Remittance Bank Account called Minimum Receipt Amount. Before creating a receipt, this amount is checked against the receipt amount. If the amount is smaller than the Minimum Receipt Amount, then a receipt is not created and the order is placed on Pending Payment Process hold. This small incremental amount can be collected by AR at Invoicing, or could be included in a subsequent receipt if further order changes are made. The Minimum Receipt Amount does not apply to refunds.

Payment Assurance Workflow

Activity Name: Payment Assurance.

Parameter: Frequency to check the status. Set this up according to your business requirement. Order Management will seed to run once in 24 hours.

In some business practices, especially retail, a prepayment or down payment is collected so a reasonable payment assurance before fulfilling the order is necessary.

You can place this activity at any point in the order flow between booking and invoicing, preferably before shipping. This activity will check the receipt status and hold the flow until the status shows a reasonable payment assurance.

For orders with prepayment, Order Management will check the status of the receipt. A unique Payment Set is assigned in AR, and all receipts for one order will have the same Payment Set. See the following table for status of receipt upon creation and the required status for Payment Assurance to pass.

Receipt StatusReceipt Status
Creation Status
Payment Instrument		 Approved Confirmed Remitted Cleared Status for payment assurance
Credit Card, Purchase Card   X     Remitted
ACH   X     Cleared
Direct Debit   X     Cleared
Wire Transfer (EFT/EDI) X        
Check   X     Cleared
Cash   X     Cleared
Commitment          

Note: When payment from the customer has been remitted to the supplier's account, during account reconciliation, Cash Management will set receipt status to Cleared. Account reconciliation is normally done at the end of the month. You can also set up your system to set the receipt status when the payment has been deposited into the account. You can set the Clearing Method in the Receipt Class to be Automatic Clearing. Normal business practice is to wait for 3 days before checks are cleared, this is set up specific.

Multiple Payment Type Input

Order Management will provide multiple payment capability through the various Sales Order user interfaces, via Order Copy, Order Import, and the Process Order API.

Copy

When canceling an order, refunds of prepayments are generated automatically. Canceling an order line will not generate an automatic refund. The refund has to be done manually by setting the down payment to a lower value and activating Process Payment.

In a mixed order, that contains both inbound and outbound lines, the defaulting of the prepaid amount will be based on the outbound lines only. The prepayment functionality will not account for the inbound order lines in calculating the total order.

Credit due to customers:

Credit processing in Receivables:

  1. Return order or order line may or may not have reference to the paid invoice.

    For Returns without reference information of the paid invoice, credit will placed into On-account Credit.

    For Returns with reference information of the paid invoice, credit can be given out in different ways depending on how the invoice was paid. See the table below.

    Return process:

    Order Management interfaces the return order line to AR for credit memo creation.

  2. For canceled order or order line, credit may be given out in different ways depending on how the prepayment was paid. See the table below.

    Refund process:

    Order Management calls the AR Refund API as follows:

    Automatically for canceling the whole order.

    Initiated manually or through concurrent program for other cases.

    Note: When calling the Refund API, AR will refund the same credit card or purchase card up to the amount on the receipts. The delta will be credited using Check.

    RefundsRefunds
    Credit
    Paid By    		 Check cut by Acct Payable Card Refund Commitment Reversed Comments
    Credit Card, Purchase Card   X   Delta is credited using Check.
    ACH X      
    Direct Debit X      
    Wire Transfer X      
    Check X      
    Cash X      

Credit Card Authorization in Batch Mode

You can defer the credit card authorization. This is available at the Payment Type Setup level and the Payment Transaction level. To process the pending authorization, you can use Pending Process Payment concurrent program or Process Payment action.

Business Flows

Single Payment Type

  1. Enter an order using the Sales Orders window. A default payment type appears on the header based on whatever Defaulting Rules have been set up. Enter additional data as required by the Payment Type – for example, if a check, then the bank account, routing number, and check number is recorded.

  2. At booking or shipping, based on the set up of the order type and validate payment rules, the payment may be authorized and approved.

  3. At invoicing, the payment information is passed to AR for invoicing or collection and accounting purposes.

Payment With Differing Types on One Order

  1. Enter an order using the Sales Orders window. A default payment type appears on the header based on whatever Defaulting Rules have been set up. Enter additional data as required by the Payment Type – for example, if the payment type is PO, then the Customer PO number may be required.

  2. Enter order lines as required. The customer wants to pay for one or more lines using a different payment type, for example credit card. Add the secondary payment information while on the order line it is to apply to. All other lines should be paid for using the Payment Type on the header. If a different line is to use a third payment type, it would be entered in a similar fashion.

  3. At booking or shipping, based on setup of order type and validate payment rules, the credit card or other payment type may be authorized and approved. The approval information is recorded.

  4. At invoicing, the payment information is passed to AR for invoicing or collection and accounting purposes. The line that was supposed to be paid from the credit card will have the credit card information passed to AR – other lines will get a payment type from the line or the header.

Prepayment Flow

  1. Enter an order using the Sales Orders window. Payment terms that indicate a prepayment is needed are defaulted or chosen. A default payment type also appears on the header based on whatever Defaulting Rules have been set up. Enter additional data as required by the Payment Type – for example, if payment type is credit card, then the credit card number and expiration may be required.

  2. Lines are entered for the order.

  3. Book the order. Credit card collection and receipt creation is done for the amount that is a down payment. Credit card authorization is attempted for the balance if the payment type is credit card.

  4. The order ships as usual.

  5. At invoicing, the payment set id is passed to AR so that the balance can be collected on the account, and the receipt created in step 3 can be matched to the invoice.

Payment By Installments

  1. Enter a customer and order type using either the Sales Orders or Quick Sales Orders windows.

  2. A default payment type and payment terms appears on the header based on whatever Defaulting rules have been set up.

  3. You can override payment terms and may choose one with installment payments.

  4. Enter one or more items.

  5. After entering all the items, view the payment information. Open the Payments window and see the amount of the first installment, and the amount outstanding.

  6. Book the order.

  7. At booking or shipping, based on setup of order type and credit check rules, the first installment payment or the total order amount may be authorized and approved. Credit Card authorization is done only if the credit check is set for Booking. The amount authorized (full amount or first installment) is controlled by the setting of the OM system parameter Authorize First Installment Only.

  8. At invoicing, the payment information is passed to AR for Invoicing or collection and accounting purposes.

User Procedures

To order with a Check as Prepayment, with Payment Assurance, and print a receipt:

  1. Navigate to the Sales Orders window and enter an order. Payment terms that indicate a prepayment is needed are defaulted or chosen. Assume the payment terms indicates a need for a 100% down payment. A default payment type also appears on the header based on whatever Defaulting Rules have been set up.

  2. Enter all the lines for the order.

  3. When finished, go to the order header and open the Payments window. The Payment window will have two entries in the multiline area, with the default Payment Type entered on each line. The percentages will be defaulted from the payment terms definition in this case, 100% for the down payment and 0% for the balance. The amounts are computed as well.

    Payments Window

    the picture is described in the document text

  4. The down payment is with a check, and invoicing is for the remaining amount. Choose check as the down payment, payment type, enter the check number, and verify the amount. It may be more or less than the computed amount. Change the amount if necessary. Close the Payment window.

  5. Book the order, choose Action Print Payment Receipt to print a receipt, to give to the customer as a receipt for the check.

  6. The Order Management process creates a receipt for the check, passing the check information to AR. Order Management may credit check the remainder, if credit check conditions apply.

  7. If you want to wait for the check to clear before the items can be shipped, as the items are ready to ship, the Payment Assurance workflow activity is reached, and that activity checks the AR Receipt to see if the check has cleared. If not, the goods are not released to Shipping, but instead the line status shows Awaiting Payment Assurance. Once the AR Receipt clears, the next time the Payment Assurance activity checks, it will succeed and the line will progress to the next activity (shipping).

  8. Items are shipped, and the lines go to invoicing carrying the payment set id of the receipt created in step 6. AR will automatically apply the check receipt to the transaction, and send an actual invoice for the remaining balance due.

Lookups

Changes on existing Quick Codes:

New Quick Codes:

System Parameters

New Order Management System Parameter: Allow Multiple Payments can be set to NO to preserve the existing functionality. When set to NO, the payment information can only be entered at the order header. You can not navigate to the new Payments window. In this case only a single payment type at the header level without partial prepayment feature is allowed. With the parameter set to NO, you are allowed to enable more payment types. However, to use multiple payments per order and to use down payment feature, this parameter must be set to YES.

Note: Once this parameter is set to Yes it cannot be changed to No.

Authorize First Installment Only Authorize First Installment Only can be set to YES to authorize the first installment only. The default is No. The amount authorized (full amount or first installment) is controlled by the setting of the OM system parameter Authorize First Installment Only.

Multiple Payments System ParameterMultiple Payments System Parameter
Code Name Desc Category Value Set Open Orders Check Enabled Comment
Multiple_Payments Allow Multiple Payments To enable Multiple Payments functionality Payments OM: Yes or No W Yes Seeded with No
Authorize_First_Installment_Only Authorize First Installment Only To authorize first installment only. Payments OM: Yes or No Y Yes Seeded with No

Constraints

Seeded Processing Constraints

Order Management has seeded processing constraints to prevent updates to attributes once the order is booked and a prepayment receipt has been created, or for invoice payment using a credit card, data can not be changed when authorization has been completed.

For prepayments, when a payment has been processed and a receipt has been successfully created, the payment information cannot be updated except for the amount that can be adjusted to a lower or higher value.

For prepayments, when payment has been processed and a receipt has been successfully created, the payment information can not be deleted.

Order Header:

When order has been booked, and prepayment has been processed (i.e. payment set id is populated), these attributes cannot be changed by the user:

Order Line:

None

There are two new entities for constraints for oe_payments:

  1. Order Payments

  2. Line Payments

Order Payments:

Line Payments:

Payment Types:

INSERT/DELETE is not allowed in the Payment Types window.

Payment_type_code is not updatable, others are updatable in the Payment Types window.

Messages

Only one payment instrument with a payment collection event as Invoice (for header or line payments) can be selected. When you add another one, an error will be raised upon saving.

Message Name: ONT_INVOICE_PAYMENT_INSTUMENT

Message Text: You cannot select more than one payment instrument for invoice.

Message Type: Error

Prepayment is not supported for line level payments. When you add a line level prepayment, an error will be raised upon saving.

Message Name: ONT_LINE_PREPAY_NOT_SUPPORTED

Message Text: Prepayment is not supported at line level.

Message Type: Error

Wire Transfer is not a supported prepayment instrument. When you select Wire Transfer as prepayment instrument then an error will be raised.

Message Name: ONT_NO_WIRE_TRANSFER_FOR_PREPAY

Message Text: 'Wire Transfer is not supported for prepayment.'

Message Type: Error

When multiple payments exist, you must use the Payments window to update payment information.

Message Name: ONT_MULTIPLE_PAYMENTS_EXIST

Message Text: ‘You cannot update payment attributes of the order header because multiple payments exist for the order. Please use Payments window to update payment attributes.'

Message Type: Error

Prepayments cannot co-exist with line level payments.

Message Name: ONT_LINE_PAYMENTS_EXIST

Message Text: ‘You cannot enter prepayments because payments exist at the line level.'

Message Type: Error

Message Name: ONT_LINE_INVOICE_NOT_SUPPORTED

Message Text: ‘You cannot enter payments at line level because prepayments exist at the order level.'

Message Type: Error

Line level payments must be associated with order lines.

Message Name: ONT_NO_LINES_FOR_PAYMENT

Message Text: ‘You cannot enter line level payments because there are no lines on this order.'

Message Type: Error

Using the Payments window to update payment information.

Message Name: ONT_GOTO_PAYMENTS_WINDOW

Message Text: ‘Please use Payments window to update the payment attributes for this order.'

Message Type: Error

Order Import - When payment reference information is invalid, an error will be raised.

Message Name: OE_OI_ORIG_SYS_PAYMENT_REF

Message Text: ‘Invalid ORIG_SYS_PAYMENT_REF. Please enter a non-null value.'

Message Type: Error

Data Requirements for AR

  1. Commitment - commitment number

  2. CC/P-Card - number, expiration date

  3. ACH - normal business practice is to have an agreement on file with the customer that authorizes the originator of the ACH transfer (Oracle deploying company - merchant) to debit the customer’s bank account. One time phone ACH authorization is legally allowed provided we capture the following pieces of data:

    • The date on or after which the consumer’s account will be debited;

    • The amount of the debit entry to the consumer’s account;

    • The consumer’s name;

    • A telephone number that is available to the consumer and answered during normal business hours for customer inquiries;

    • The date of the consumer’s oral authorization; and

    • A statement by the Originator that the consumer’s authorization will be used to originate an ACH debit to the consumer’s account.

    Theses 6 points are mandated by NACHA - the governing body of the ACH Network.

  4. Wire

  5. Check: We support 2 flows.

    • The check given to the Order Management clerk, which is then deposited directly to the bank. Checks mailed to the AR department.

    • Checks deposited via lockbox or mailed directly to the bank are not supported.

Retroactive Billing Overview

Retroactive billing refers to a business practice common in certain industries, especially the automotive industry, when a customer requests changes to amounts charged by a supplier on an invoiced order to receive credits.

Periodically, the price of an item on a sales agreement or purchase order will be changed, for example, a commodity will sharply increase or decrease in price. The customer will issue an amendment to the sales agreement or purchase order. If the price change is retroactive, shipment quantities are identified that occurred during the retroactive billing period, and the additional charges or credits are calculated and sent to the customer for billing.

Retroactive Billing Major Features

Price List Changes

You can capture a new selling prices for an item, a range of items, or a particular customer price list. You can enter the new selling price (either as a unit price or a % of the previous price) with an effective date range.

You can use the Price List window to define or modify a unit list price for items or item categories with an effective date range. You can also add qualifiers to a price list to specify what kind of customers or orders will get the price from a particular price list. The Sales Agreements window are entry windows to capture price list line changes.

1. The difference in list price would be considered to determine whether the retrobill line would be of type 'ORDER' or 'RETURN'. If the difference in list price is zero, the difference in selling price would be considered. Example: If Invoiced ulp = $100 and latest ulp = $50, the retrobill line type is 'RETURN,' even if invoiced usp = $90 latest usp = $110 (due to some new modifiers in the setup)

2. If a modifier present in the original line (or previous retrobill line) is invalid in the setup during the retrobill run, this modifier would be shown in the View Adjustments window for the retrobill line and the following would be the value for adjusted_amount. Adjusted_amount corresponding to the retrobill line = -1 * adjusted_amount corresponding to the original line (or previous retrobill line) if the retrobill line type is 'ORDER.' The adjusted_amount corresponding to the retrobill line = adjusted_amount corresponding to the original line (or previous retrobill line) if the retrobill line type is 'RETURN.'

3. If a new modifier MOD_NEW is present in the setup and is returned by the pricing engine, the following would be the value of adjusted_amount for MOD_NEW in the View Adjustments window. If list_line_type_code = 'PBH', it will be changed to 'DIS'. Adjusted_amount = The amount returned by pricing engine corresponding to the latest list price, if the retrobill line type is 'ORDER'. Adjusted_amount = -1 * (amount returned by pricing engine corresponding to the latest list price) if the retrobill line is of type 'RETURN'. > >

4. In View Adjustments form, for the diff adjustments > sign(operand) = -1 * sign(adjusted_amount) if list_line_type_code = 'DIS' and sign(operand) = sign(adjusted_amount) if list_line_type_code = 'SUR.'

Identify Eligible Lines

You can identify eligible shipped/invoiced lines with a flexible list of criteria. You can identify invoice lines by:

Report Eligible Lines

You can report all eligible re-priced invoice lines. This report is intended to replace RLM's current Retrobilling Report. You can view the results of a Preview or Executed retrobill request online.

See: RetroBilling Report

Adjust Prices on Future Shipments

You can update pricing of all future shipments based on new price list information. You can mass change open orders, or re-price shipments before ship confirm to insure the latest price details.

This functionality is available in Order Management. You can mass select orders and use the Price Order action. Alternately, you can add the Reprice at Shipment workflow activity to the line workflows, so that repricing is automatically executed at shipping before invoicing.

Visibility to Re-billed Lines

You can identify all re-pricing actions against an invoice line when you search for eligible invoice lines. You can see the history of the re-priced lines, as well as the latest unit-selling price, and the debit/credit based off that price.

The Retrobill Report and the Inquiry Results show the eligible order lines. The ‘invoiced unit price' and ‘invoiced extended price' is the net of any existing executed Retrobill runs. In other words, if the original invoice unit price was $10, and there was already one retrobilling executed that reduced the price to $9, and now we are working on another retrobill request to lower the price to $8, we show $9 as the ‘unit invoiced price' on the report and the query.

Retrobilling Preview (Inquiry)

With retrobill criteria, you can preview a list of eligible invoice lines, the proposed price changes (with updated unit selling price, the invoice difference as a debit or credit) as well as any previous changes to a price that would impact the invoiced amount.

The process will allow for the retrobilling request to be run in Preview mode, and the results could be viewed on line. After Preview has been executed (either concurrently or real-time), the Adjustment/Credit part of the window is populated as well as the Summary tab. You can also print the Retrobilling Report to show retrobilling details including original price, new price and variance price.

Approve and Automatically Create Adjustments

Before creating any adjustments, you should be able to approve the set of re-priced lines. When you approve a list of eligible re-priced invoice lines, you can automatically create debit (invoice lines) or a credit (credit memo) for each line. You can group the new invoice lines onto an invoice by shipment, by customer ship-to location, or by customer. You can group the new credit memo lines onto a credit memo by shipment, by customer ship-to location, or by customer.

Approval Process

Approval will consist of the user viewing the Preview results and choosing to Execute the retrobill request. That activity will book the retrobill orders, which will then execute their workflows like any other orders/lines.

Note: If companies need a more formal approval process, they can insert a workflow approval step into the order or line workflow.

Retrobill Order

When a retrobilling event occurs, the adjusted amount is created as an open adjusting order line. If the price increases, this line will be bill-only and have an ORDER line category. If the price drops, this line will be credit-only and have a RETURN line category. A new seeded Retrobill source indicates that the line is an adjusted line, and refers to the current retrobilling request. See the following table to see how attributes on retrobill lines are populated.

Retrobill Values
Columns on the retrobill line Get value from
Item Copy from original line
Quantity Retrobillable quantity (ordered quantity of original line reduced by any return quantity
UOM Copy from original line
Line Category Code RETURN when the line is used for crediting customer
ORDER when the line is used to bill customer
Line Type Use the default ORDER or RETURN line type as setup in the order type definition.
Item Type Code Always hard code as STANDARD
Calculate Price Flag Default to N, which means Freeze Price
Unit List Price Difference of the unit price on price list line
Unit Selling Price Difference after discounts applied
Price List If the price list on the original order line is no longer active, it will be defaulted based on defaulting framework. This could be different from the original order line based on defaulting or pricing engine output.
Pricing Date Current date
Tax Code Copy from original line
Shippable_Flag N, means the line is not shippable
Return Reason Code Default from system parameter ‘Default retrobill reason'. You can also override for each retrobilling request
Order_Source_ID A new seeded order source type ‘Retrobill'
Orig_sys_document_ref Store original order's header_id
Orig_sys_line_ref Store original order line's line_id
Source_Document_shipment_ref Not populated for retrobilling
Retrobill_Request_ID Foreign key to retro request table
Reference_Line_Id We are not going to use this column
Credit_Invoice_Line_Id Store the retrobilled invoice line
Shipped_Quantity Null
Reserved_Quantity Null
Shipping_Quantity Null
Shipping_quantity_UOM Null
Actual_Shipment_Date Null
Over_Ship_Reason_Code Null
Over_Ship_Resolved_Flag Null
Shipping_interfaced_Flag Null
Option_Number Null
Commitment_Id Null
Other fields Will be copied from original line

These lines are grouped into orders by customer, currency, conversion type, conversion date, and conversion rate. These orders are bill only or credit only open orders. One or more invoices or credit memos can be generated from a retrobill order depending on AR grouping rules. See the following table to see how order attributes are populated.

Order Attribute Population
Columns on the Retrobill Order Get value from
Order Type Default from Order Management system parameter. You can override the default by choosing any order type for a retrobilling request
Other attributes Defaulted
Order_Source_Id Use new order source type ‘Retrobill'
Orig_sys_document_ref Store retrobill_request_id

Note: Agreement information on the original line will be copied over to the retrobill line.

Retrobilling Event Parameters

You can optionally give the following input parameters to retrobilling run:

Retrobilling Event ParametersRetrobilling Event Parameters
Parameter Description Required? Defaulting source
Order Type Retrobill orders will be created with this order type No From the Order Management System Parameter
Retrobill Reason Credit memo reason to send to AR Yes From the Order Management System Parameter
Retrobill Event Name Name to identify retrobilling run Yes  
Description Short description or comment of the retrobill request No  
Mode Preview or Execute Yes Determined by which action is chosen. Previewed retrobill orders if saved will be created in Entered status. Executed retrobill orders will be created in Booked Status

Retrobill Amount Calculation

A seeded Pricing Event, Retrobill determines the amount to bill or credit It is seeded with a pricing phase, List Line Base Price. If there are already discounts applied to the original order line, the discounts will be applied to the new list price to determine whether there is any price change.

For customers who also want the line level modifiers reevaluated, they can change the Advanced Pricing event phases mapping to activate line level phases. Only phases with modifier_level_code='LINE' should be attached. The Retrobilling engine will validate and raise an error if the wrong phases are attached. Only discounts, surcharges, and price break headers will be considered.

  1. Recalculating line group level and order level discounts are not supported.

  2. We will price the selected order lines with current date as pricing date.

  3. Each adjustment is compared with the same modifier attached to original order line, and if it had been retrobilled before, the most recent (based on pricing date) retrobill line, and come up with an adjusted_amount difference. This adjustment is stored with the difference as applied. The application method is changed to Amount when needed. The View Adjustment for the retrobill line will only show these adjustments.

    Sales Credits

The sales representative and sales credits are copied from the original order line. These are interfaced to AR and the sales credits are adjusted.

Workflow Considerations

Please assign the same workflow for both Order and Return lines for the Order Type that is used for Retrobill Orders. If you require different processing in the workflow for Order and Return lines, create the workflow which branches based on line category of the Retrobill Lines.

Typical Retrobilling Usage

The following are some typical examples of using the Retrobilling feature in this design. This is not intended to describe all business scenarios:

Retroactively Crediting to Customer Due to Item List Price Drop

  1. Customer A and B have placed the following orders:

    Customer Order Placement
    Ord # Cust Line Item Qty Line Cat Unit List Price Unit Selling Price Ext Price Invoice #
    1000 A 1.1 X 10 Order 20 20 200 2000
    1001 B 1.1 X 20 Order 20 20 400 2001
    1000 A 1.1 X 5 Order 20 20 100 2002

    Customer Order Placement

  2. The Unit List Price of Item X has dropped from $20 to $17. The user end-dated the Corporate Price List Line for Item X, and added another price list line for Item X:

    Price List Changes
    Price List Item Start Date Active End Date Active Unit List Price
    Corporate X 1/1/2000 7/31/2003 20
    Corporate X 8/1/2003   17

    Price List Changes

The user retrobills the three orders and the Retrobilling Engine generated the following orders:

Retrobill Generated Orders
Ord # Cust Line Item Qty Line Cat Unit List Price Unit Selling Price Ext Price Credit Memo Against
2000 A 1.1 X -10 Return 3 3 -30 Invoice 2000
2001 B 1.1 X -20 Return 3 3 -60 Invoice 2001
2000 A 1.1 X -5 Return 3 3 -15 Invoice 2002

Retrobill Generated Orders

Retroactively Bill To Customer Due To Item List Price Increase

  1. Customer A and B have placed the following orders:

    Customer Order Placement
    Ord # Cust Line Item Qty Line Cat Unit List Price Unit Selling Price Ext Price Invoice #
    1000 A 1.1 X 10 Order 20 20 200 2000
    1001 B 1.1 X 20 Order 20 20 400 2001
    1000 A 1.1 X 5 Order 20 20 100 2002

    Customer Order Placement

  2. The Unit List Price of Item X has increased from $20 to $23. The user end-dated the Corporate Price List Line for Item X, and added another price list line for Item X:

    Price List ChangesPrice List Changes
    Price List Item Start Date Active End Date Active Unit List Price
    Corporate X 1/1/2000 7/31/2003 20
    Corporate X 8/1/2003   23

  3. The user retrobills the three orders and the Retrobilling Engine generated the following orders:

    Retrobill Generated OrdersRetrobill Generated Orders
    Order # Cust Line Item Qty Line Cat Unit List Price Unit Selling Price Ext Price Invoice Number
    2000 A 1.1 X 10 Order 3 3 30 3000
    2001 B 1.1 X 20 Order 3 3 60 3001
    2000 A 2.1 X 5 Order 3 3 15 3000

User Procedures

To perform Retrobilling:

  1. Navigate to the Retrobilling Organizer Find window.

    Retrobilling Organizer Find Window

    the picture is described in the document text

  2. Enter the criteria for the orders to retrobill. Searching by item and customer is similar to the searches that you can carry out in the Order Organizer.The lines that match the criteria are displayed.

    The Operating Unit field is folder enabled and available in all the tabs. It displays your default Operating Unit. You can choose a different Operating Unit that is accessible to you from the LOV. The Operating Unit selected should have Retro-Billing enabled (via System Parameters).

    Retrobill Find Results Window

    the picture is described in the document text

  3. Choose the row(s) to Retrobill. If you do not choose any rows, then any action described in steps 4 through 6 will execute against all rows selected by the Find criteria.

  4. Click either Online or Concurrent Request to invoke retrobilling. A parameter window will pop up to accept parameters. You can give a retrobill event name, description, order type, reason and mode (either Preview or Execute).

    Retrobilling Parameters window

    the picture is described in the document text

  5. Optionally perform a Preview Retrobilling activity. This will execute the retrobilling engine in preview mode. You can view the results of the Preview in the Retrobilling Organizer by querying up the request by name. You can see the amounts to be retrobilled for each line and also summary information. You can optionally run the Retrobilling Report to see the details as a standard report.

    You cannot create a single Retro-Billing request for Orders from across Operating Units. However you can retrobill orders from different Operating Units that are accessible to you without changing responsibilities, thus creating multiple Retro-Billing requests (one or more) for each Operating Unit that you have access to.

    Note: After preview or execution, the Lines tab will show the retrobill order lines created by the retrobilling engine. For previewed results, you can deselect retrobill order lines or change the retrobill quantity and do either preview or execution again.

    You can input parameters and click OK. If this was invoked from the Concurrent Request button, a concurrent request id will be displayed and cursor back to the Retrobilling window. If it was invoked from the Online button, the results show in the Retrobilling window Lines tab for each retrobill line. An additional tab, Summary shows. You can choose the Summary tab to see retrobill orders. This summary tab has two regions.

    The upper region displays the parameters: Retrobill Event, Description, Order Type, and Reason. Another field Request Status shows whether the retrobill request is previewed or executed.

    The lower region is the same as the order organizer Summary tab and is folder enabled. The seeded default folder will have Order Number, Customer Name, Currency, Order Amount, Subtotal, Tax and Conversion Type, Conversion Rate, and Conversion Date. Operating Unit is a folder enabled field.

    Retrobilling Results Summary Tab

    the picture is described in the document text

  6. You can choose to change the quantity on any retrobilling line, or delete lines from the Preview set of lines before executing.

  7. You can finally choose an Execute Retrobilling activity. This will execute the retrobilling engine in ‘execute mode' against the selected lines. If not previewed before, this will create and book the retrobill orders and lines. If previewed previously and results were saved, this execution will update the retrobill orders to Booked status.

  8. You can optionally exit without executing the request, and later return to the retrobilling request by querying it up in the Retrobilling Organizer.

  9. To query previewed retrobilling requests by event name, you can go to the Retrobilling Organizer window Retrobill Requests tab to do that. This tab is also useful when users want to query retrobill requests by item, customer, request date. (Figure 7) When any information is entered in this tab, the ‘Order Information' and ‘Line Information' tab will be disabled. Item identifier type and ordered item will be available as hidden folder fields so that you can query by customer item also.

    Note: Note: You can enter free text in the field where the query will run based on whatever was entered. If you select a request from the LOV, the query would run based on the retrobill_request_id corresponding to the selection.

  10. When you click Find the following summary window shows. You can choose one retrobilling request and click Open to see individual retrobill requests.

    Note: When only one retrobilling request is found, the retrobilling requests summary window is bypassed, and the Retrobilling window displays.

Seed Data

Order Management Parameters

Several new Order Management Parameters related to Retrobilling have been added as follows:

  1. Enable Retrobilling – values are Enabled or Disabled. The default is Disabled.

  2. Default Retrobill Order Type – values will be based on all active Order Types that have been defined. This is used as the default order type for retrobill orders.

  3. Default Retrobill Reason – values will be based on all active AR credit memo reasons. This is used as the default retrobill reason for retrobill orders.

These parameters will be added to a new category Retrobilling.

Constraints

A new seeded validation template Retrobill Line. It will be true for lines with retrobill_request_id populated.

A new seeded validation template Return Retrobilled Line. It will be true for Return Lines that have retrobill lines created after the Return Line is created.

Invoice Processing.

Customer Acceptance

In different countries a number of companies prefer to accept goods formally before being invoiced by the supplier. To record and view customer acceptance, Oracle Order Management integrates with Accounts Receivables and Costing. The customer can accept the goods in any or in combination of the following ways:

In Pre-Billing Customer Acceptance, once the goods are accepted, invoicing is carried out. In Post-Billing Acceptance, the revenue recognition process is deferred and linked to customers accepting the shipped goods. Only full acceptance is recorded; partial acceptance is not recorded. Post-billing acceptance is not supported for lines with deferred accounting rules.

Implicit Customer Acceptance

The field Acceptance Days on the Sales Order line (folder enabled on the Others tab), enables you to see the time limits specified on customer acceptance. This is set up in Receivables (Revenue Management) in the deferral reason definitions. For more information on setting up deferral reasons and Expire Activities, please refer to the Oracle Receivables User Guide.

Implicit Customer Acceptance

Implicit Acceptance of Pre-Billing and Post-Billing is checked using the Implicit Acceptance request set. This request set verifies the expiration of implicit acceptances.

Explicit Customer Acceptance

The Actions item Fulfillment Acceptance enables you to accept the goods explicitly. This is available in the Sales Orders Lines window and on selecting this option, the Order Details window of the Order Information Portal opens.

the picture is described in the document text

Explicit Acceptance is recorded in Order Information Portal, using which you can search and accept/reject multiple lines at a time.

the picture is described in the document text

Once you select Accept or Reject, the Acceptance Status on the line in OIP changes to Accepted or Rejected. You need to specify an Acceptance Date, signature and other fields for the acceptance to be recorded in OIP. The order status in the Sales Order window also changes to Closed. The Sales Orders window has two other dates - Earliest Acceptable Date and Latest Acceptable Date - that are related to Scheduling and not to the Customer Acceptance functionality. Acceptance details like Acceptance Date, Acceptance Comments etc., are allowed for update only before the line is closed and are available for users who have the privilege (function security) to perform explicit acceptance.

Note: The acceptance date can be before the fulfillment date, however, it cannot be prior to the actual shipment date. If the actual shipment date is not available, then the application validates the acceptance date against the fulfillment date and does not allow the acceptance date to be prior to the fulfillment date.

Though Customer Acceptance is available at both levels – header and line, the Sales Orders line (Others tab) contains the following Customer Acceptance related fields (folder enabled):

the picture is described in the document text

Specify an Acceptance Name in the field, this is also known as Deferral Reason and has been defined in Receivables, Revenue Management. If a number of days that the acceptance will expire in, has been defined in Receivables, then the Acceptance Number of Days will display the value. Similarly, the Acceptance Expire Event will display from the Receivables field. These will be populated in case of Implicit Acceptance.

Customer Acceptance for Promotional Goods

When the original item has promotional goods associated with it, both need to be individually accepted by the customer. The customer may accept one and reject the other.

Customer Acceptance for ATO/PTO/CTO Items

In the case of ATO models:

In the case of PTO models:

For kits (PTO items):

Acceptance only at the top model. All included items will be accepted when top model line is accepted.

Please note that in case of Sales Agreements, if the goods are rejected or treated as scrap, an RMA (Return Material Authorization) needs to be created. The sales agreement quantity and amount are always adjusted during pre-billing acceptance or rejection.

User Procedures

The following are the steps to record and view Customer Acceptance:

General Procedures

  1. Enter orders that need to be accepted by the customer and this acceptance is to be recorded by the Customer Sales Representative.

  2. View/update Acceptance fields on the order line. The Others tab of the sales orders line displays the folder enabled Acceptance fields.

  3. Sales Order Acknowledgment Report prints Acceptance Required.

  4. Ship Confim the items – view the line status ‘Pending Pre-Billing / Pending Post-Billing Acceptance’.

  5. Perform Acceptance/Rejection.

  6. View Acceptance Details in Sales Orders line.

  7. Explicit Acceptance:

    Acceptance through Order Information Portal (click on Sales Order Actions – Fulfillment Acceptance) from Header or Lines OR through Order Import.

  8. Implicit Acceptance:

    Deferral reason has to be defined in AR with event attribute as Ship Confirm date and expiration days.

An Implicit Acceptance Request set that records Implicit Acceptance consists of the following concurrent programs:

Customer Acceptance/Rejection Scenarios

Given below are different scenarios in which acceptance/rejection (implicit or explicit, pre-billing or post-billing) are specified:

Customer Acceptance prior to billing, full explicit acceptance

Customer Acceptance required prior to billing, with full explicit acceptance:

  1. Customer Acceptance required prior to billing, with full explicit acceptance:

  2. Order is picked and shipped.

  3. Order lines status is Pending Pre-Billing Acceptance’.

  4. Customer logs into Order Information Portal, queries their order and marks the lines as accepted for the full quantity shipped. Or, if the customer has called or faxed their acceptance to the call center, the CSR queries the order and uses the Sales Order form Action ‘Fulfillment Acceptance’ which brings up the OIP page, and records the acceptance there.

  5. Order line proceeds to invoicing and revenue recognition. The invoice date for the line is the acceptance date.

  6. CSR can query the lines to find out the details of the acceptance.

Customer Acceptance prior to billing, some goods not acceptable

Customer Acceptance required prior to billing, but some of the quantity on a line are not acceptable:

  1. CSR enters order and books it.

  2. Order is picked and shipped.

  3. Order lines status is Pending Pre-Billing Acceptance’.

  4. Customer calls or faxes to CSR indicating they cannot accept all the items that they have received - they have rejected part of one or more of the order lines. CSR instructs the customer to send back the items for replacement.

  5. CSR raises an RMA for credit referencing the original order line (since the original order line has not been invoiced, the credit will go on account).

  6. CSR also raises a new order for shipping replacement goods.

  7. When the replacement items are shipped and received, the customer calls or faxes to indicate that the items are acceptable.

  8. CSR logs into OIP, queries the original order line and marks it as accepted for the full quantity shipped. Or CSR uses the Sales Order form Action ‘Fulfillment Acceptance’ which brings up the OIP page, and records the full acceptance. When recording the acceptance, CSR can enter Comments to indicate what happened, and can reference the replacement order number if desired.

  9. Order line proceeds to invoicing and revenue recognition.

  10. CSR can query the lines to find out the details of the acceptance.

Customer Acceptance after billing, full implicit acceptance

Customer Acceptance after billing, with full implicit acceptance:

  1. CSR enters order and books it. Revenue Management is set up to assume acceptance if explicit acceptance/rejection is not performed within 30 days of shipment.

  2. Order is picked and shipped.

  3. Order line is invoice interfaced.

  4. Order lines status is Pending Post-Billing Acceptance.

  5. Even after 30 days, there is no acceptance or rejection of the goods.

  6. Acceptance is assumed. Order line closes and revenue recognition takes place.

  7. Later, if there is a question, CSR can query the order lines and see that an automatic acceptance was generated on the 31st day after shipping.

Customer Acceptance after billing, full explicit rejection

Customer Acceptance required after billing, with full explicit rejection:

  1. CSR enters order and books it.

  2. Order is picked and shipped.

  3. Order lines are invoice interfaced.

  4. Order lines status is Pending Post-Billing Acceptance.

  5. Customer calls or faxes to CSR indicating they have rejected the order lines. CSR instructs the customer to either send back the items or scrap them.

  6. CSR logs into OIP, queries the order line and marks it as rejected for the full quantity shipped. Or CSR uses the Sales Order form Action ‘Fulfillment Acceptance’ which brings up the OIP page, and records the rejection.

  7. Order lines close.

  8. CSR creates an RMA order referencing the rejected order line, with a line flow indicating receipt of goods or scrap.

  9. CSR can query the lines to find out the details of the acceptance.

Customer Acceptance prior to billing, full explicit acceptance, goods and service on same order

Customer Acceptance required prior to billing, with full explicit acceptance:

  1. CSR enters order for a product and a service on that product (extended warranty) and books it.

  2. Goods line is picked and shipped.

  3. Both order lines (good and service) appear in status ‘pending pre-billing acceptance’.

  4. Customer calls or faxes to CSR indicating they have accepted the goods.

  5. CSR logs into OIP, queries the order line for the goods and marks it as accepted for the full quantity shipped. The Service line does not appear in the UI as a line that can be accepted. Or CSR queries the order in the Sales Order or Quick Sales Order form, then invokes Action Fulfillment Acceptance which brings up the OIP page, where the line is marked for acceptance.

  6. Both order lines proceed to invoicing and revenue recognition – the invoice date for both the goods and the service is the acceptance date.

  7. CSR can query the lines to find out the details of the acceptance.

Customer Acceptance prior to billing, delayed service

Customer Acceptance required prior to billing, for orders with delayed service:

  1. CSR uses Order Management to enter order for service such as extended warranty for an item that was ordered on a different order. The service line can reference the serviceable item’s original order or its install base instance. CSR books order for service.

  2. Service line status is Pending Pre-Billing Acceptance.

  3. If the serviceable good has already been accepted, then the service line will be automatically accepted. There is no user action required. The acceptance details from the good line will be copied to the service line.

  4. If the serviceable good has NOT be accepted, then the service line will wait at the invoice interface in status ‘pending pre-billing acceptance’ until the goods line is accepted. CSR will not be able to explicitly accept or reject the service line. Once the goods line is accepted, the acceptance details will be copied automatically to the service line and the service line will automatically proceed in the workflow.

  5. Service line invoices and closes once acceptance of the good has been received.

  6. Later, if there is a question as to when or how the service line was accepted, CSR can query the service line, as the acceptance details are copied to that line.

Customer Acceptance prior to billing, ATO or PTO models

Customer Acceptance required prior to billing, with full explicit acceptance, for ATO and PTO models, including ATO within PTO:

  1. CSR enters order, configures as necessary and books it.

  2. Acceptance attributes will be visible and updatable only on the top model lines of the order, not the child lines.

  3. Order is picked and shipped.

  4. All order lines status is Pending Pre-Billing Acceptance, including all child lines of the configurations.

  5. Customer logs into OIP, queries their order. They will see only the model lines eligible for acceptance. They will mark them as accepted for the full quantity shipped.

  6. All order lines proceed to invoicing and revenue recognition.

  7. CSR can query the lines to find out the details of the acceptance.

Note: In the case of non-SMC PTO models and PTO models with imbedded ATO models, be aware that acceptance takes place at the top model level only. If a business is concerned with billing and collecting for options as they are shipped, then they should choose post-billing acceptance rather than pre-billing.

Credit Card Encryption

Funds Capture Enhancements is initiated by Oracle Payments and Cash Management and its objective is to use a centralized credit card and bank account information system. Vital and sensitive data such as the credit card number, the credit card security code (CVV2), bank account are encrypted and stored in this centralized model. This means that applications (such as Order Management) that have been locally storing information such as credit card details now integrate with the central model. This provides enhanced security and control over critical information. Credit card information such as credit card holder name is displayed in encrypted format and the expiration date appears without a value in the Sales Orders, Payments, and Quick Sales Orders windows. Additionally, you can view the status of a credit card as Unexpired or Expired in the credit card expiry status field in these windows, based on the encrypted expiry date. This encrypted format is customizable and has the following options:

Note: Such an option is available for masking the bank account too.

the picture is described in the document text

You are not allowed to enter line level credit card payment if the line has already been covered by the header level credit card, and a valid authorization exists for the header level credit card. The error message is displayed: Credit Card payment cannot be entered for this line, it is already authorized by the Credit Card specified at the Order Header.

For upgraded credit card orders coming from previous releases, if you have run the Audit History Consolidation program before upgrade, then the credit card numbers shown on the View Audit History window will be in the encrypted format, and the new credit card number masking setting will not be applied.

If you run the Audit History consolidation concurrent program after upgrading, then the credit card numbers shown on the View Audit History window will be in the format per current credit card masking setting.

If you have run the Audit History Consolidator for credit card orders in previous releases before upgrade, you can see the credit card numbers in masked format in the View Audit History window. You can delete the credit card related records in table oe_audit_attr_history then re-run the Audit History Consolidator concurrent program. The attribute ids for credit card records are 46,47,48,49.

Credit Card Security Code

To ensure that Internet-based transactions are protected from credit card fraud during buying and selling of goods and services, credit card companies such as Visa, Master Card, and American Express are required to include a security code number in addition to the credit card number. This is called as CVV2 (Card Verification Value) by Visa, CVC2 (Card Validation Code) by MasterCard and as CID (Card Identification #) by American Express. It is a 3 or 4 digit number printed on the back of the card.

The credit card companies use this verification code to provide greater security to merchants who process transactions in situations where their customers' cards are not present, such as over the Internet. This code is used to confirm that customers possess genuine credit cards, and that their account numbers are legitimate. The security code is not encoded in the card's magnetic stripe and is not printed on sales receipts.

In the Credit Card Security Code field of the Sales Orders window, you can enter a security code that is verified with the credit card number that is entered. The Security Code field is folder-enabled and its value is verified in Oracle Payments.

the picture is described in the document text

If a credit card authorization failure occurs (either the security code or the credit card number cannot be validated), the order is put on hold. In addition, if the card fails risk validation, Order Management puts the order on hold. 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.

Some considerations when using Credit Card Security Code that has been set as a required field in Oracle Payments:

For more information on credit card encryption and credit card security code, please refer to the Oracle Order Management Implementation Manual, Payments chapter.

Partial Period Revenue Recognition

Due to strict accounting standards, Revenue Management must account for revenue at a granular level, such as daily revenue or partial period revenue. The Partial Period Revenue Recognition feature enables you to recognize revenue for partial periods or daily rate accurately. The Accounts Receivables module initiates this; however, you can use it for rate calculation in Order Management and Service Contracts (for service items only). The revenue for a service sold needs to be distributed accurately over the duration of the service term (between start date of the service to end date of the service).

A calendar month is a standard month definition and consists of a number of specified days (for example 1-Jan to 31-Jan). A year has 12 standard months.

A service calendar month is started based on the day the user signs the contract. Therefore, if a contract is signed on 23-Feb-2004, a service month is defined as 23-Feb-2004 to 23-Mar-2004. If the customer wants to consider 23-Feb-2004 to 23-Mar-2004 as a single month, the customer should not use the partial period revenue recognition rule.

For example, if the customer does not use the partial period revenue recognition rule on a service line that is invoiced into Receivables, Receivables will recognize revenue for the whole month on 23-Feb-2004 (rule start date) in this example.

The available accounting rule types are:

Type Description
Fixed Schedule All periods have fixed duration and fixed percentage.
Variable Schedule First period is optionally fixed, remaining periods are prorated.
Daily Revenue Rate, All Periods All periods use daily revenue rate.
Daily Revenue Rate, Partial Periods Partial periods use daily revenue rate, full periods are prorated.

The examples below show how partial period or daily rate is calculated.

Fixed Schedule

In this example, the revenue is not calculated based on daily rate. The revenue is distributed evenly over the duration provided.

The fixed schedule accounting type, the GL calendar is used, and duration is 6 months.

Revenue per period = $600/6 = $100. The revenue schedule is:

GL Date Period Amount
April 17 Month of April 100
May 17 Month of May 100
June 17 Month of June 100
July 17 Month of July 100
August 17 Month of August 100
September 17 Month of September 100
  6 Monthly Periods 600

Variable Schedule

GL Date Period Amount
April 17 Month of April 85.71
May 17 Month of May 85.71
June 17 Month of June 85.71
July 17 Month of July 85.71
August 17 Month of August 85.71
September 17 Month of September 85.71
October 17 Month of October 85.71
  6 monthly periods 600

Daily Revenue Rate - All Periods

With this option, the revenue is calculated based on daily revenue rate. The calling applications, Order Management and Service Contracts, must interface either rule start date and duration number, or rule start date and rule end date.

Partial periods and full periods are based on the number of days in the periods.

The revenue schedule is:

GL Date Period Amount Days
April 17 Month of April 45.92 14
May 17 Month of May 101.68 31
June 17 Month of June 98.40 30
July 17 Month of July 101.68 31
August 17 Month of August 101.68 31
September 17 Month of September 98.40 30
October 16 Month of October 52.24 31
  7 monthly periods 600 183

Daily Revenue Rate - Partial Periods

Partial periods are prorated based on the number of days in the periods. Full periods have equal revenue distributions.

The revenue schedule is:

GL Date Period Amount Days
April 17 Month of April 45.92 14
May 17 Month of May 100.32 31
June 17 Month of June 100.32 30
July 17 Month of July 100.32 31
August 17 Month of August 100.32 31
September 17 Month of September 100.32 30
October 16 Month of October 52.48 16
  7 Monthly Periods 600 183

Windows using Partial Period Revenue Recognition

The Receivables window, Accounting Rules, enables you to set up accounting rules with attributes like Rule Type, Period, Number of Periods etc.

the picture is described in the document text

The sales orders window, Header > Others, displays the accounting rule field with an LOV that is populated from the Receivables Accounting Rule window.

the picture is described in the document text