Oracle does provide the ability to recognize freight as revenue, which in turn calculates tax on the charge, but this doesn’t happen until the order has been interfaced to Receivables (AR). For some corporations, that calculation needs to happen at the time of order entry.   Additionally, some clients who utilize iPayment to authorize a credit card charge in OM and apply the fully transact the charge when the order is interfaced to AR will also encounter issues because the authorized amount, which doesn’t include the tax on freight, is less than the actual charge amount on the AR side, causing the credit card transaction to fail entirely.  

Needless to say, it’s a pain, and a blatant functionality gap.   However, with a slight customization, a semi-acceptable solution can be found by harnessing some of the functionalities available in Advanced Pricing.

Going back to Oracle’s recommended solution of adding an order line item for freight if it is to be taxed – the main issue with this work around is that it’s not automatically added to the order.   For high-volume order entry environments, this is an absolute necessity.   One of the great advantages of modifiers in Advanced Pricing is the ability to allow charges and adjustments to be automatically applied to an order based on qualifying events.   This is an important piece of functionality that is lost using Oracle’s line item workaround.

However, there is a functionality in Advanced Pricing, often not used, that can automate the entry of an order line.   The “get item” functionality under the “Promotion” modifier type allows you to add items to a sales order based on the qualifiers you set.   This functionality is typically used for a “buy one, get one free” scenario, but can be used in this situation to add a freight order line automatically to a sales order.

The only setback to this functionality is that the pricing capabilities are limited.   When setting up a “get item” modifier, you cannot attach a formula.     The functionality only allows you to obtain a fixed list price from a price list or generate a new price.   This may be OK if you’re organization charges a fixed amount for freight, but for those who calculate freight based on the selling amount, this is very bad.   Out of the box, there is no way to get around this.   Even applying a modifier on top of the order line that is added by the “get item” modifier doesn’t work, because when the line item is added, the Calculate Price Flag is set to “Partial Pricing”.   What “Partial Pricing” means is that it will obtain the price that is established in the “get item” setup, but it will neglect any modifiers or adjustments applied to that order line.   The only way around this is to manually set the Calculate Price Flag to “Calculate Price”, then re-price the line.  

While setting the Calculate Price Flag manually works, this defeats the purpose of adding the freight line automatically to the order.   The point of this exercise is to add the line with the price automatically calculated so that there’s no need for the users to perform this step in a high volume order entry environment.   This is where that “slight” customization as I mentioned earlier comes in.

If setting the Calculate Price Flag to “Calculate Price” after the line has been automatically added solves the issue, then why not have a concurrent request, which runs as often as the business desires, perform this action so that the price of the freight order line is correctly calculated?   This is exactly what we did with my last client and it ended up working quite well, but with one little exception.

Being that this is a line item, there is no way to prorate the freight in the event there is partial or multiple shipments for a given order.   Depending on the nature of your business, this may not be acceptable.   There’s a couple of way to address this:

• Restrict partial shipments from occurring by enabling header level invoicing or utilizing fulfillment sets.   This will ensure that all line items are fulfilled before issuing an invoice.   However, if you’re organization requires that an invoice be generated for each shipment, this would not be an acceptable solution.
• If the first option doesn’t fit your business model, you can place an automatic invoicing hold on the freight line item that is only released when the entire order is shipped.   What this does is allow items that are shipped partial to generate an invoice, but delays the billing of freight until the last shipment is made.   The automatic hold can be done as a hold source, but releasing the hold would need to be another one of those “slight” customizations you would need.   However, if you’re organization needs to include freight charges with every delivery, this solution wouldn’t work for you either.
• If neither of the above option is acceptable, and you need the whole shebang, than a more complex customization is needed that splits the freight item for each shipment.   So for example, you have a 10 line item sales order where your freight charge is $50.   During the first shipment, 5 of the 10 lines are shipped out there door.     What the customization would do is split the freight line item into two lines 0.5 quantities, which in affect would split the price in half.   Only one of the split lines would be processed with the shipment, the other split line would be placed on hold.   For this to happen, you’re item would need to be setup as “OM Divisible” enabled, which indicates that fractional quantities are allowed.

Getting around this issue is not easy, but can be possible.   If you’d like to obtain a copy of my code which resolves the pricing issues with adding line items automatically using the “get item” functionality, feel free to contact me.

Also, to find out how to calculate freight, charges, or adjustments based on the total order amount, check out this article.

However, as of recently, Oracle has offered a patch (5192725) which allows for the use of the credit card fields in OM without the need to install iPayment. The application of this patch alone is not enough, as there are other tweaks that need to take place to make it all work. At any rate, I take this as a great act of generosity on Oracle’s part – it’s not often they provide us the choice to implement a module!

The first step (of course) is to apply the patch. If you look up the patch in Metalink the given description is kind of hazy, but this was the patch recommended to me by Oracle. It appears to incorporate several fixes for Family Pack J. As with any patch, be sure to thoroughly test the patch first before applying to your production instance.

Next, we need to create our receipt class in AR which will classify the receipts that are generated from processing a credit card payment in OM. To do this navigate to the appropriate AR responsibility, than Setup > Receipts > Receipt Classes.

To start, let’s name our receipt class “Credit Card”, since this receipt class will be used specifically for receiving credit card prepayments. Additionally, we’ll want to specify “Automatic” to indicate this will be an automatic transaction that will be generated from OM.

As you continue entering the other key information, the most important field to note is the “Payment Type” field located under the “Automatic” tab. Prior to the introduction of this patch, we would select a type of “Credit Card” in order to enable the use of the credit card functionality with iPayment. But for our purposes, leave this field BLANK. With the application of patch 5192725, this is now the key indicator which will tell the credit card processor in OM to avoid making any calls to the iPayment module.

Once you have saved your “Credit Card” receipt class, you can continue with the remaining AR setups that are standard to any receipt class; most notably, the document sequence (which should be set to Automatic) and your receivables activity.

After completing all the AR setups, our next step is to configure Order Management to use this receivables class when initiating a credit card prepayment. We do this by setting the “OM: Payment Method For Credit Card Transactions” to the “Credit Card” receipt class. But before we do this, there is one small tweak we need to make. Prior to the introduction of this patch, this profile limited assigning receipt classes to only those which were setup with a “Payment Type” of “Credit Card”. Since our receipt class does not have a type assigned, we’ll need to change the validation behind this profile so that it allows assignment of “Credit Card” and “None” payment types.

To do this, you’ll need access to Application Developer to open the profile definition. After logging into this responsibility, navigate to NAVIGATION_PATH and query for the “OM: Payment Method For Credit Card Transactions” profile. Upon opening the responsibility, you’ll notice a SQL validation section. Copy and paste the below code into this box:

SQL=”SELECT NAME \”Receipt Method\”
, RECEIPT_METHOD_ID
INTO :VISIBLE_OPTION_VALUE
, ::PROFILE_OPTION_VALUE
FROM AR_RECEIPT_METHODS
WHERE SYSDATE >= NVL( START_DATE, SYSDATE )
AND SYSDATE <= NVL( END_DATE,SYSDATE)
AND (PAYMENT_TYPE_CODE IN (’CREDIT_CARD’,'NONE’)
OR PAYMENT_TYPE_CODE IS NULL)
”
COLUMN=”\”Receipt Method\”(50)”

Notice the above SQL opens up the restriction so that the profile will allow both “Credit Card” and “None” types of payments. After pasting the code, save your changes, and navigate to your System Administrator responsibility (if you happen to be so lucky) and set the “OM: Payment Method For Credit Card Transactions” profile to our receipt class.

Now we’re in business! Let’s test our solution…

To start, enter a sales order header with data you have handy. In the “Others” tab, the key fields to note are:

• Payment Term – make sure this is set to a term setup for prepayment. If not, revert back to your OM setups to ensure a prepayment term is established.
• Payment Type – this will be entered as “Credit Card”
• Credit Card Number
• Card Holder
• Card Expiration Date
• Approval Code – this should be the approval code issued by your 3^rd party processor upon successful confirmation of the card

Notice that when you’re entering the credit card number that it’s fully visible. Depending upon how you’ve setup the credit card number encryption, this data will save and be replaced by ‘*’’s for extra security. It’s important that you communicate to your users that before saving this information that they must perform there offline processing so that they can reference the full credit card number!

The offline credit card processor typically provides an approval code which indicates the credit card screening was successful. Enter this approval code into the “Approval Code” field. Otherwise, in the situation where the credit card has failed, you can leave this field blank and the order will be automatically placed on “Prepayment Hold” which will prevent further processing of the order until the transaction is revisited and the hold is released.

After performing the offline processing, you can than proceed with entering your order lines, again, using test data you have handy.

After completing order line entry, it’s now time to put our solution to the test! Upon booking the order, Order Management will interface a prepayment receivable in AR indicated that the sales order has been prepaid. Results of this activity can be evaluated in the Order Messages window that appears after clicking the “Book” button. If you see a message stating “Receipt number XXX has been processed”, your test was a success!

Your next step is to revert back to Accounts Receivable to verify the receipt is complete and generates the proper accounting. Aside from this validation, you’re now in the position to capture credit card information in Order Management and process offline -without the need of iPayment!