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.

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!