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.

 ”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.