One of the major downsides with using IR/ISO in 11i and the initial R12 releases was the change management process. Once an IR is approved it is essentially locked down and cannot be updated thereafter. Only cancelations were only allowed if the corresponding ISO was canceled. So if required dates needed to be changed on the IR, the corresponding ISO and the IR itself would have to be canceled and recreated with the proper dates. Terrible!

Additionally, changes to the ISO, which were restricted to cancelations and scheduled ship date changes, would not propagate automatically to the IR and would have to be done manually. In my opinion this was a huge gap in functionality. If cancelations or scheduled ship date changes were made to the ISO, and if the IR was not manually updated to reflect these changes, it would result in a conflicting supply/demand picture between the requesting and source organizations. In other words, the requesting organization would still see the supply quantity or required date of the IR it originally requested, while the source organization would be planning to the revised demand quantity or scheduled ship date on the ISO.

However, in 12.1 Oracle has finally provided some improvements. The “Improved Internal Requisition/Internal Order Change Management” functionality provides automated change control between the two transactions. In this release, changes made to the ISO can now be automatically applied to the IR. Better yet, the IR itself can also be modified after it has been approved, where changes are also propagated to the ISO. Workflow notifications can also be setup to notify the requesting or supplying organizations of such changes. No longer will there be a discrepancy between the IR and ISO!

Another nuisance of the IR/ISO process was that the changes to the IR or ISO could not be initiated from planning. So if planning had recommendations to change or cancel an IR, this would have to be done manually. Likewise, the ISO would also have to be manually updated to ensure both were in sync.

But in 12.1.2, Oracle has added integration between Advanced Supply Chain Planning (ASCP) and Purchasing to provide internal requisition management from the planner’s workbench. The “Release Recommendations for Internal Requisitions” functionality now allows the planner to release scheduled date and cancelations changes to the IR. This perfectly complements the change management functionality introduced in 12.1.

As a consultant who has seen the pain in implementing the IR/ISO process in the past, these are welcomed changes. I would highly recommend any customers who are in need of an integrated supply chain solution to consider these releases.

Approvals in Quoting

You may have heard of Oracle’s Approval Management (AME) module.  AME provides flexible, workflow-based approval capabilities and serves as a one-stop-shop for managing all fixed and dynamic approval hierarchies throughout Oracle EBS.

Lucky for you, the Quoting module is well integrated with AME functionality, allowing approval hierarchies to be dynamically built based on different types of transactional criteria such as operating unit, total quote amount, customer, etc.  Base approval lists can be built manually or can be associated with SQL statements to dynamically generate hierarchies based on employee data.  Quoting also provides security settings that allow skipping an approver in the hierarchy or bypassing the process entirely. 

Needless to say, the tight integration between the Quoting and AME modules provides great out-of-the-box approval functionality that is likely to meet or exceed your business requirements.

Approvals in Order Management

I wish I could say the same about Order Management (OM).  Unfortunately, there’s no out-of-the-box integration between OM and AME.  Compared to Quoting, the approval capabilities are limited and inconsistent depending on what type of transaction you’re performing. 

You’ve probably seen the Approver setups in the OM module by clicking on the “Approvals” button on the order type setup screen; however, these setups pertain only to Negotiations (OM’s version of quoting).  The configuration gives the impression that approval lists can be built for Fulfillment type transactions (orders), but Oracle hasn’t implemented these capabilities into any of the generic OM workflows.

Another setback with Approver setups in OM is that they’re assigned and dedicated to a transaction type.  This can cause issues if you have multiple facilities that each require their own set of approvers, but are under the same operating unit in Oracle and share the same set of order types.  The only work-around for this is to create a separate set of transaction types for each facility, but this can get ugly.  Additionally, the approval lists are fixed, sequential and do not provide any of the dynamic capabilities that are available in the AME module. 

It gets worse for return transactions.  The capabilities are limited to only allowing individual approvals and not approval hierarchies.  The generic return workflows in OM refer to a profile option that allows storage for only one approver.

Approval Enhancements

As you can guess, most of the enhancements I’ve designed and implemented have been to compensate for the limited approval functionality in OM.  Generally there are two approaches, each varying in complexity and produce different results.

As low-cost alternative with quick turnaround, I’ve provided enhancements to the seeded order and return workflows that incorporate the Approver setups in OM.  I say “quick” because Oracle already provides the necessary nuts and bolts to easily “plug” in the approver functionality with minimal customization.  Though the solution is low cost and quick, the functionality will still not provide all the capabilities of the AME module as I mentioned earlier.  However, this may suit your business fine depending upon your requirements.

A fancier approach I’ve taken is to integrate OM with the Approvals AME module entirely.  This way all the capabilities I spoke of earlier in the Quoting module are also made available to OM.  From a technical standpoint it’s definitely more involved than the first enhancement I mentioned, but if your business requires the flexibility, it certainly can provide a great return on investment.

Multiple Operating Unit Access – In 11i, a responsibility could only be tied to a single operating unit. However, in R12, responsibilities can be assigned to one or more operating units by assigning the responsibility to a security profile. This is a great enhancement for businesses where users require multi-organization access.

Credit Card Entry Enhancements - An additional field has been added to the order entry screen to capture the security code typically located on the back of a credit card. Additionally, the credit card number is encrypted at the database level and stored within the Payments (formally iPayments) module. I’ll put out a more detailed article that talks about the drastic changes to the iPayments module.

Reoccurring Charges - Functionality has been added to the TSO (Telecommunications Service Ordering) module which allows reoccurring billings. This is perfect for subscriptions and other like services.

Partial Period Revenue Recognition – A joint OM and AR enhancement, partial period revenue recognition is a set of new revenue recognition rules in AR which allow for revenue recognition on a daily basis. Previously in 11i revenue recognition could only be done on a monthly basis.

Pay Now or Pay Later – Upfront billing in Order Management can now be done and can be configured based on pricing charges, taxes, deposits, installment billing, and prepayments.

Mass Scheduling Changes – The scheduling concurrent request can now pick up lines that have errored in the scheduling workflow activity. It also can now pick up lines that are in Entered status – both converted and manually entered orders.

Customer Acceptance Process - Oracle R12 now provides the ability to introduce a customer acceptance step prior to invoicing. By setting up a deferral reason in AR, invoicing can be deferred until acceptance has been captured.

Tax Updates – Additional tax fields have been added to the order entry screens that provide more flexibility with Vertex.

Architectural Changes to Inventory - in 11i, Discrete and Process Inventory modules were entirely separate entities. Oracle has converged these modules into one data structure, where functionalities from both modules have combined to be available to both. This doesn’t mean much from an OM perspective, but technical changes have been performed to the Pick Release and Ship Confirmation processes to work with the new combined inventory model.

Architectural Changes to OM, Install Base, and Service Contracts Integration – My understanding is that there is no functionality changes, but from a technical standpoint Oracle has implemented a best practice approach  to OM to Install Base and OM to Service Contracts touchpoints to ensure API calls are used rather than direct queries.

For corporations which conduct sales in the U.S. and in other locations across the world, the complexity increases because every country has their own set of embargo laws. For example, a U.S. based company cannot sell to an Iranian company because of U.S. regulation, but on the other hand, if the same organization has a location or distribution warehouse in France, their French location could sell to that same Iranian customer. Granted, this situation is also dependent on the citizenship of the individual conducting the sale – an employee sitting at a desk in France can’t make the same sale to Iran if they hold U.S. citizenship.

By now I think you get the point – keeping track and enforcing export compliance procedures can be quite complex. If your business operates an international sales organization and has difficulty enforcing and adapting to the ever changing embargo regulations at a global level, then the Oracle Export Compliance module, in conjunction with Kewill export compliance screening, can provide just the tools you need to ensure your sales organization remains compliant.

A Brief Look at the Technology

Out of the box, Oracle provides a workflow process in Order Management that establishes an XML based connection to a selected 3^rd party compliance screening service. Kewill, a commonly used screening service in the Oracle community, maintains an elaborate database of the latest export compliance regulations. Upon entering and booking a sales order, Oracle sends various information about the sale order transaction to Kewill, who then accepts and evaluates the sale based on the most current and up-to-date export compliance laws.

Once Kewill determines whether or not the sale is compliant, the results are sent back to Oracle Order Management. If the result is found to violate export compliance laws, the sales order goes on export compliance violation hold and awaits review by an individual in the organization who is given the property authority to either process the order or cancel the sale.

Additionally screening can be performed during the pick release and shipment confirmation processes to ensure that changes that are made to a sales order after booking are also captured and screened prior to sending the product out the door.

The technology around the communication between Oracle and Kewill services is fairly straightforward, but the actual screening performed by Kewill can be quite complex. As I mentioned earlier, international embargo laws vary country, so to deem a transaction compliant there are many pieces of information to consider. What country is the customer located? Do the billing and shipping locations for the customer differ? Or is the billing customer entirely different than the shipping customer?

What about your facilities – is the location of your shipping warehouse different than the location from where the order is being processed? Does the citizenship of the individual entering the transaction qualify to make the sale?

As you can see, the situation can get quite complex. How these questions are answered determines the set of export compliance laws that need to be evaluated. Lucky for you, Oracle Export Compliance and Kewill takes care of this complexity for you.

For more information regarding the Oracle Export Compliance product visit http://www.oracle.com/products/export/index.html.

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.

Perhaps, but before you go down this path there is another factor that should be taken into consideration: ensuring the order fulfillment process as a whole remains seamless and intact. What is the impact to the order entry, scheduling, pick release, on-hand availability and reservation processes if an interface is built to an outside WMS? The answer to this question is especially important in a high-volume environment where your organization fulfills hundreds to thousands of orders a day.

Generally, when an interface between Oracle (or any order processing system for that matter) and a Legacy WMS is built, a division of duties is established. Oracle is given the responsibility to capture orders and release these orders for shipment when ready. The Legacy WMS system is responsible for accepting shipment requests, processing these shipments, and sending the results of the shipment back to Oracle. Essentially, the Pick Release process in Oracle is the “throw” to Legacy WMS, and the Ship Confirmation step is the “catch”.

Since the nature of both system’s responsibilities require access to inventory data, your organization must understand that not only are you building a shipping interface, but you are committing to maintain two sets of inventory data that may require several interfaces. Oracle will need access to on-hand balance and reservation information so that order processors have insight to product availability and so that the system knows what orders are eligible for shipment. The Legacy WMS will of course require inventory data to maintain on-hand balance and deduct balances upon shipment. Oracle inventory data, to a degree, will need to be in synch with inventory data in Legacy.

To what degree must be decided. Your organization may determine that both sets of inventory do not require real-time synchronization. For example, you may decide that manual adjustments made to inventory in Legacy may only need to be interfaced through a daily polling process that posts these updates to Oracle. If this direction is taken, then you will need to decide how your shipping interface will handle exceptions that may result from an on-hand balance delta between Oracle and Legacy inventory.

How can an inventory delta occur? Well, let’s say at the time we place an order for an item in Oracle there is 1 quantity available for reservation. However, during the day a warehouse worker reviews the item and determines that it fails to meet quality standards and as a result he/she performs a manual transaction in the Legacy WMS to issue that quantity to scrap. Because Oracle is unaware that this transaction occurred, the interface will continue to release the ordered item for shipment – even though there isn’t enough quantity on-hand in Legacy.

In this situation, you will need to ensure that this situation (among many others) can be handled by the interface. From a business prospective, a decision needs to be made to determine how exactly this delta should be handled. For example, you may want to leave the interfaced transaction in an error status and continue to retry until inventory is made available. Or you may want to cancel the transaction entirely. Whatever that action may be, it’s important that there is visibility to these kinds of inventory deltas.

If your organization decides that Oracle inventory and Legacy inventory requires real-time synchronization, your interface will still need the ability to handle situations that result in inventory deltas. Let’s face it – we’re all human. Any level of time and effort that is put into a real-time interface could still result in situations unaccounted for. And as best practice, an error handling procedure should still be implemented, especially in an environment where you require real-time synchronization.

Attempting to identify all scenarios that require a communication between Oracle and the Legacy WMS can get pretty crazy. Here are some examples of scenarios that would need to be included:

• Order cancelations in Oracle
• Shipment cancelations in Legacy
• Manual inventory transactions in either system
• Inventory location transfers, but this is only important if your organization is utilizing hard reservations at order time, which in this case you should seriously rethink using an interface.
  
• Split and partial shipment scenarios

We could go on and on with the list of scenarios to cover – these are just a small fraction of what can occur. And as I mentioned, even if you think you’ve listed all scenarios, you still need an error resolution process.

I can’t stress more the importance of error resolution in the event of an inventory delta. Whether it’s an automated or manual solution is not important, but the most important point is making sure that if an unidentified inventory delta situation occurs that the interface can be capture and handle this error. At minimum, if the error cannot be handled, at least provide the tools necessary to bring visibility to the situation. Trust me – there is nothing worse than going live with an interface and experiencing errors that were unaccounted for.

This all may come off as something you probably learned in a beginner’s course for software design, but I’ve seen and witnessed the aftereffects of an unsuccessful inventory interface launch with some very reputable clients. What results is the very situation that the client wanted to avoid in the first place – a chaotic situation that requires the involvement of lots of time and resources that the organization did not budget for but has no choice to deploy in order to fix an interface that is the backbone of their business.

Some brief examples I’d like to share…

Example #1

Working with a life sciences client to implement Oracle Order Management a few years back, the organization decided to keep their existing mainframe inventory system with the idea of avoiding risk and cutting costs. The consulting group at the time recommended against this decision, but the client continued on and even decided to take on the effort using internal resources.

In a nutshell, the core exchange of the interface was centered on the Pick Release and Ship Confirmation processes. Testing was lackluster and didn’t cover all scenarios such as partial line shipments or order cancelations. More importantly, there lacked a substantial volume test.

What resulted at go-live was a disaster. Because of the bugs around partial line shipping, some orders were shipped two, three, and occasionally four times over. It took a team of 10-12 people during go-live to identify the dozen situations that were causing the Pick Release failures and shipping issues. Overall, it had taken a year+ to stabilize the situation and resulted in an exceeded IT budget and sales losses to the client. A team still exists today in maintaining and monitoring this interface.

Example #2

A publishing organization implementing Oracle decided to build an interface to their existing warehouse system. Aside from its age, this system was a beta version of the vendor’s product. It was heavily customized and interfaced to dozens of other order processing systems already. Cost and risk were definitely a factor.

Results at go-live were also poor. Multiple or no shipments were occurring. Since shipment sets in Oracle were not in synch with the activity that occurred in the legacy system, it caused many issues. An extensive amount of resources were needed to help stabilize the situation. Over time, the client became limited to the amount of functionality that could be used in Oracle. For example, for an order that had several shipping locations, separate orders had to be created for each shipment vs. establishing different shipping addresses at the order line level.

Additionally, the client implemented a daily process that “synchronizes” the Oracle on-hand balances with Legacy on-hand balances if a delta occurs (scary). Overall, it has taken nearly 2 years to stabilize the situation and currently has resources dedicated to the effort today.

As you can see, clients typically downplay the risk exposed to the rest of the fulfillment process when implementing an inventory interface to “protect” the shipping operation. Even worse, these organizations had made the decision to keep the legacy WMS because it was determined that the implementation effort in replacing the system was to costly compared to building the interface. Looking at this short-term, this may be true. But like most system interface projects, the cost of maintaining such a beast can greatly exceed the cost of implementing a new WMS over time (at least based on my experience).

If you’re an organization that is the process of deciding upon an inventory and shipment interface or a new WMS, I hope you can take the above situations into consideration. In going with the direction of an interface, you must also take into account:

• Increased Go-Live Risk – In case the situation gets ugly, you’ll need extra time and resources to correct and stabilize the situation. Also will need to factor in any impact to the business and sales it may cause.
• A New Department - The interface itself will be a unique process that will require several individuals who understand and are familiar with the process and include expertise in both the Oracle and Legacy inventory systems.
• Difficulty or Inability to Upgrade/Change - Being that the interface will be a delicate process requiring much involvement from both systems at a technical level, any changes to the table structure on the Oracle side as a result of an upgrade or customization could result in breaking this interface. Likewise, any changes done to the legacy side could also adversely affect this interface. With that said, expect all upgrade efforts to your system to exponentially increase.

My position should be pretty clear from all my ranting – DON’T DO IT! Or at least if you do, thoroughly evaluate the alternative of implementing a new WMS. Hopefully through the experiences I’ve shared, you’ll find that both options are exposed to the same level risk, but that the long term cost benefits of implementing a new WMS will prevail.

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!

 ”What” you say?   Shipping an item without deducting inventory?   Why would anybody want to do that?

Believe it or not, there are certain requirements which make this a viable solution.   For example, your organization may:

• Periodically ship low costs goods along with your product, such as nuts or bolts, tacks, etc., that would be too costly from an inventory management prospective to track on-hand balance.
• Offer services along with the shipped product that, for legal reasons, may need to appear on the shipment documentation.  
• Or the service being provided could be related to the shipment itself, which would also entail it appearing on the shipping docs.
• Apply charges along with your product that must appear as line items on sales, shipment, and invoicing documentation.

If any of these situations apply to your business, it’s quite possible that shipping without transacting inventory could work for your organization.  

Surprisingly, to make shipping without transacting inventory work, there are only a few configurations that need to take place – the most important being the item setup.   Essentially, we want to attribute this item so that it’s not an inventory item but orderable and shippable from an Order Management prospective.  

While there are a number of item attributes that require setup, these settings in particular are important in making our scenario work:

• Under the “Inventory” tab:
  o  Inventory Item Unchecked – This ensures that the Shipping Execution module treats the item like a non-inventory item.
  o  Stockable Unchecked – As a result of making the item non-inventory the stockable cannot be checked.
  o  Transactable Unchecked – Same situation for this attribute, can’t be checked if we’re dealing with a non-inventory item.  

• Under the “Order Management” tab
  o  Customer Ordered Checked - Allows the item to be placed on a sales order in Order Management.
  o  Customer Orders Enabled Checked – Simply enables the customer orderable functionality.
  o  Shippable Checked – Marks the item as shippable.   This is important in attributing the item as shippable, but a non-inventory item.      

• Under the “Invoicing” tab
  o  Invoiceable Item – Checked
  o  Invoice Enabled – Checked    

Next, aside from having all the basic Order Management setups in place, it’s important that the line type being used is assigned to a workflow which contains the shipment activity so that the order follows through the Pick Release and Ship Confirmation process steps.   Oracle generic line workflows such as “Line Flow – Generic” or “Line Flow – Generic, Ship Only” can be used.

That’s it!   Pretty simple, eh?   Now that we know how to setup our shippable, non-inventory item and have our basic Order Management setups in place, let’s test our scenario.

Using an item called ZBULK that I attributed as non-inventory and shippable, I enter a sales order using a line type which I have assigned to the “Line Flow – Generic” workflow.   The “Customer Order Enabled” flag of the item allows me to add this item to the sales order.   After we book the order, the line automatically progresses into an “Awaiting Shipping” status.

Next, like any normal inventory item, we proceed with the Pick Release of the sales order.   If this were a typical inventory item, the resulting inventory transaction from the execution of Pick Release to the completion of the Move Order would be a sub-inventory transfer from the inventory location of the stocked good to the staging sub-inventory.   And as a result of the sub-inventory transfer the shipping transaction status changes from “Released to Warehouse” to “Staged/Pick Confirmed”.

However, because the combination of flags we have set on our ZBULK item (”Inventory Item” flag unchecked; “Shippable” checked), the shipping transaction progresses directly to a “Staged/Pick Confirmed” status – bypassing the sub-inventory transaction that results from the Move Order.   This is important to understand because, from a process standpoint, we have skipped all manual picking steps such as the Move Order, pick slip printing, etc. that typically occurs when shipping a regular inventory item.   In skipping these steps, we’re able to release our ZBULK item without regard to inventory, on-hand balance, etc.

Additionally, the picking steps are skipped regardless of how the “Auto Pick Confirm” flag is set during the release.   Under normal circumstances, this flag controls whether the Mover Order transaction occurs automatically or manually and is often dictated by the business process.   In this case, the “Auto Pick Confirm” flag has no bearing.

This “bypass” of the inventory transaction is more obvious if you refer to the corresponding record within the Shipping Transactions form.   With a typical inventory item, the initial shipment status is usually “Ready to Release” with “Launch Pick Release” as the next step.   But for our ZBULK item, you’ll notice that the status is “Not Applicable” with “Ship Confirm” as the next step.   Again, this is due to the combination of attributes we have set for the ZBULK item.  

Now you may be asking “If the next step is to ‘Ship Confirm’, why are we still releasing the order?”   In fact, it’s not required to perform the Pick Release.   You can actually bypass the pick release of this line entirely and proceed directly with the normal ship confirmation steps.   However, depending upon your business process, you may want to incorporate the Pick Release step.   For example, if our order line was part of a shipment set tied to other inventory items, you would require that this line in addition to the other lines of the ship set are released together so that the entire grouping is made available for shipment confirmation.   For the sake of this demonstration, let’s assume our process requires that we release this item.

After launching the pick release process our delivery line now becomes “Staged”; allowing us to proceed with the normal ship confirmation steps.   Like all ship confirmations, the “Interface Trip Stop” process is executed either real time or later as a concurrent request.   Typically, the process accomplishes three main objectives:

1. Deducts on-hand quantity and debits Cost of Goods Sold.
2. Progresses the order line to “Shipped” status so that it can progress to the next workflow activity.  
3. Progresses the shipment line to an “Interfaced” status and sets the trip to “In-Transit” or “Closed” depending on whether you elected to close the trip.

For our non-inventory item we’re shipping, “Interface Trip Stop” will also execute, but will only complete steps #2 and #3.   Therefore, our sales order and shipment transactions will progress without executing the inventory deduction or debiting Cost of Goods Sold.
Upon completing the ship confirmation we find that our shipping transaction is now in an “Interfaced” status.   From a shipping prospective, the process to confirm the delivery is seamless.  

Additionally, the closure of our order line is also seamless.   Since we’re using the “Line Flow – Generic” workflow and have our ZBULK item attributed as “Invoiceable”, our order line will be set to a “Closed” status and proceed to Accounts Receivables for invoicing.

There you have it – we’ve successfully shipped an item without generating any inventory transactions.

Take for example the following situation.   As a manufacturing company on Oracle, you sell extremely large manufactured goods that usually are disassembled and shipped across multiple carriers.   Typically when an order is placed for this good it’s represented as one line item on a sales order (and invoiced as one line item).   This item could be a configured model or a standard finished good with a complex bill of material.  

When the order is booked, demand is instantly sent to planning for this item.   Once the work order is issued, this item is then manufactured and placed into finished goods where the shipper can now pick release and stage the item in preparation for shipping.   The preparation process for this extremely large, manufactured good begins with final testing to ensure the good is operational as a whole.   Once the testing requirements have been fulfilled and documented, the good is then ready to be disassembled and shipped.

While this may sound simple, the disassembly process is quite involved and is conducted in a non-uniform fashion.   Essentially, the shipping crew is to disassemble this gigantic item so that:

1.)  All disassembled parts can fit unto a typical truck.
2.)  Disassembled parts and materials are tagged with identification prior to placement in the container and are listed on the packing list specific to that container.  
3.)  Along with the packing list, instructions for reassembly are included which reference the identification tags.   Once all of the shipments arrive at the client site, this document is referenced by the assembly crew who then reassembles the components.

To accomplish these tasks there are a few pieces of information that need to be handy within the shipping dock.   Most of this information such as the destination, intended carrier, weights & dimensions of parts, freight costs, etc. can be referenced or collected using standard Shipping Execution functionality.  

But some of the information required to execute this process resides outside of the Shipping Execution module.   For instance, the bill of material for the manufactured good needs to be accessible so that parts can be easily identified when containerized.   We must keep in mind that the individuals within the shipping dock were not involved in the engineering and manufacturing processes of this good and will need this information for reference.   It is also vital that the shipping crew have this information to accurately identify, label, and containerize the parts properly considering the liabilities involved with shipping this high dollar item.

And because of the liability risks involved with this large item, all shipment information resulting from the disassembly process needs to be tracked in detail – this is where a major functionality disconnect occurs.  

As I mentioned earlier, the final good is placed into inventory as a single item once manufacturing is complete.   The pick release process within Shipping Execution then transfers this good to the staging area; which results in a single delivery detail line.   However, the requirement asks for all information related to this shipment line to be tracked – this includes all of the disassembled parts, containers, and carriers used.   Several questions are to be asked of this process:

1.)  How do we split apart this single delivery line to represent the multiple shipments resulting from the disassembly process?
2.)  And how do we track the disassembled components in each of these shipments?

Let’s first investigate the issue of splitting a single delivery detail line.   Functionality exists within Shipping Execution that allows the user to split the delivery line into fractional quantities if the “OM Divisible” flag for the manufactured item is enabled within the Item Master.   However, this leads to several issues:

1.)  Though the delivery line can be split, the fractional quantities may not accurately represent the percentage of the item that was pulled a part from the main assembly.
2.)  Depending on your client’s requirements, there may be a need to perform this action on a serial controlled item.   If this is the case, Oracle will not allow an item to be “OM Divisible” if serial control is enabled, thus preventing delivery line splitting.
3.)  If your client is implementing Installed Base, several records are interfaced to the module for each of the split delivery lines vs. a single interfaced record that represents the entire manufactured good.
4.)  And most importantly, no manual or automatic functionality exists in Shipping Execution that allows the user to assign disassembled parts of the bill of material to a split delivery line.

Depending on how flexible your requirements are regarding order entry, you may be able to alter the order entry process so that line items could be entered that represent each of the major components that will need to be disassembled and shipped.   However, this is also making some radical assumptions:

1.)  Presentation of the invoice is not an issue (4 line items vs. 1)
2.)  Either Installed Base is out of scope, or interfacing several “partial” Installed Base records is not an issue.
3.)  Breakdown of the manufactured good for shipment is know at the time the order is placed.

Placing the disassembled components as separate line items on the sales order also creates a major side affect within manufacturing.   Demand is no longer sent for the good as a whole, but is now sent for the components of that good.   This means that work orders are issued for each component, manufactured, and placed into inventory as separate finished goods.   Oracle then has no knowledge that in reality this is actually a single manufactured good that was sold to the customer.   And in the case that I described above, it also doesn’t show that the unit was actually assembled completely for testing prior to the disassembly process.

Another approach would be to create the good as a PTO item, where each of the options within the PTO model resembles the major shippable components.   But again, this is making the same assumptions as the previous solution.   And this also has the same side affect on manufacturing.

Regardless, neither of the approaches address the requirement that the disassembled components need to be tracked and assigned on a per shipment basis.   This requirement would most definitely require a customization that would allow the user to “drill” into the shipment and assign the disassembled parts to an LPN/container item.

Additionally, to be able to reliably split apart the delivery line that represents the large item, and in order to avoid any adverse affects on manufacturing and Installed Base, a customization would be needed to enhance the delivery line splitting functionality.   Essentially the delivery line would need to be taken to another level of detail that would be stored outside of the standard Shipping Execution application to track the multiple container shipments associated with a single delivery line in standard tables.   In affect, this would allow manufacturing to produce this good as a single item (as intended) and would interface to Installed Base as single record upon ship confirmation.

As you can see, this situation could potentially be very challenging to implement.   And while most consultants refrain from customizing the application as much as possible, there doesn’t appear to be a solution that would completely avoid altering the Shipping Execution module while fulfilling all of the requirements described.

Got a better solution?   Let’s hear it!

These can be tough questions to answer depending on the pricing policies your company enforces. Surprisingly, many of today’s global corporations still manage pricing of their products and services independently at a regional level. Even companies that are running a global ERP system have implemented their pricing strategy in this fashion.

For some companies this isn’t necessarily bad. It could have been that it made good business sense at the time to keep pricing controlled independently at each of your regional operations. For example, your organization may have a subsidiary in China that manufactures and sells a product that’s only offered domestically because there’s no market for it anywhere else.

But for most global supply chain companies this isn’t the case. The organization you work for most likely manufactures and distributes products across multiple factories, which are then shipped to distribution centers and/or clients all over the world. If your company operates at this scale, there’s a good chance that your pricing strategy remains separate and potentially inconsistent across the board.

Let’s take for example this situation; as a sales manager, you have just sold a high-powered engine for big bucks from your office in Louisville, Kentucky to a client headquartered in Germany. You call up your colleague, Adolph, at the Berlin branch to relay the good news. However, Adolph tells you that his division recently increased the price for this model engine and has sold it for nearly 25% more to one of your client’s competitors. When you find this out you may be upset for two reasons:

1.) You could have just sold the same engine for 25% more and made a heck of a lot more money, not to mention a higher commission.

2.) Your company may lose a customer (not to mention a friend), because when Adolph’s client finds out your company just sold one of their major competitors the same engine for less, they’re not going to be very happy (and neither is Adolph).

In this scenario, you had no clue that the operations in Germany had increased their price for the engine you just sold. If you hadn’t spoken to Adolph, you would have never of found out about this price increase. The price you used was a figure based on the policies that were established within your local operation. And the policy you referenced was based on the marginal figures and market conditions within your specific region – all of which may not have been consistent with the German policies.

An even worse situation could be that both you and Adolph quoted the engine to the same customer for different prices. For example, a solicitation is issued by a potential client looking for the same engine offered by your company. Both you and Adolph spot this RFP and, without knowing, you each send your own formulated quote. And because of separate pricing policies, the quoted prices differ. This could definitely raise a few eye brows from a client prospective and puts your company at serious risk of losing the contract.

The problem in both of these cases is that the US and German pricing policies are completely separate, and there’s no procedure in place to communicate any price change between the two operations. This may have happened for many reasons – maybe when the German operation was first established or acquired an initial procedure wasn’t put in to ensure pricing consistency. It’s also possible that competition between the two operations is quite heated and as a result neither division wishes to share any information that could potentially give the other a competitive edge.

If you’re truly operating a global supply chain company you don’t want situations like these to occur. Ideally what your organization wants is a central point of reference where the entire company can obtain an accurate and consistent price – no matter what continent you’re selling from or who you’re selling to. This referenced price should take into consideration several factors such as the line of product being sold, the regional manufacturing and/or purchasing costs, expectations in margin, and selling conditions at a domestic and international level.

This central point of reference cannot be established through implementation of an IT system alone – it takes people to execute this philosophy. Essentially what is needed is a core “pricing think tank”. The members of this committee should be representative of your organization across the globe and have long-term experience within the organization, a strong understanding of the organization at a regional and international level, and proven marketing and financial leadership. The establishment of a “pricing think tank” is a very important first step towards the globalization of your organization’s pricing policy.

But this can also prove to be a difficult task. As I mentioned earlier, competition to sell may be intense between your operations. Thus, sales managers are reluctant to share any information related to revenue and margin to the rest of your internal operations. Though spurring internal competition to increase sales can be effective to a certain extent, there  are some negative side effects as a result.   For instance,  it steers the focus of your people away from customer satisfaction to focus on financial metrics. While your organizations strive to make better numbers than the rest of the company, it often leads to a communication breakdown between operations and creates an extremely difficult obstacle in the road to building a centralized “pricing think tank”.

So how can this challenge be overcome?

One approach is to change the metrics that are used to measure your company’s performance. For instance, instead of using sales, margins, or revenues to measure and reward operations and individuals within the organization, try customer satisfaction. Redirect the focus of your people to minimizing customer complaints, increasing repeat customer sales, and striving to receive positive feedback from clients. And make it a common effort across all your operations. Setting such an environment may not eliminate internal competition completely, but it will ease the tension amongst your operations.

Once you get past the obstacle of establishing your organization’s “think tank”, your next major challenge is to ensure the lines of communication remain open and a policy is established that enforces the communication of changes to any and all pricing trends through the committee. Also make sure the group establishes a procedure around how to calculate and maintain the pricing information. In establishing global policy, here are some questions your committee should answer:

• Can the pricing information be maintained through a centralized source or should it be segregated by region?   If segregated, how will communication of price changes ensure that these changes take effect across the board?
• Can pricing information and changes be formulated in some fashion?   For example, what factors determine price?   And can these factors be represented in a global calculation?
• How do exchange rates affect pricing?
• What constitutes a price change? And how often can this price change occur?
• Can an IT system be put in place to implement such a strategy?

Now I’ll be the first to admit that establishing a global pricing strategy is easier said than done. And it doesn’t happen over night. An effort of this magnitude will most likely require the need of a strong change management team. And if your company plans to utilize an information technology system to implement this strategy, they will also need individuals that have a good understanding of your business and the application. What I can say is that it is, can, and has been made possible. And in the long run this strategy will open your organization to complete visibility of your pricing policy, increased customer satisfaction, and fully realized margins.

Stay tuned for a future article that will discuss how this global pricing strategy can be implemented using Oracle Advanced Pricing.