August 1st, 2007
From an Oracle prospective, when I say “Shipping without Transacting Inventory”, I mean just that – being able to add a line item to the sales order in Order Management, following through with the pick release and shipment confirmation like a normal inventory item, but avoiding the inventory transactions that result from the shipment.
”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.
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:
- Deducts on-hand quantity and debits Cost of Goods Sold.
- Progresses the order line to “Shipped” status so that it can progress to the next workflow activity.
- 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.