[OFBIZ-12054] Solution Design - OFBIZ-12053: Promising against Future Supply

• Type: Task
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: order
• Assignee: Yashwant Dhakad
• Reporter: Swapnil Shah
• Created: 12/Nov/20 08:58
• Updated: 11/Jan/22 05:17

Description

Solution Design
In search of answers for few basic questions around promising, here is the list of few possible design options to explore and build on further:

• How much to Promise
  Before making any systemic or manual promise its important to know how much is remaining to be promised for any given order(item). It could be determined as follows:
  • Let system first promise out of on hand inventory using its current reservation mechanism.
  • Post inventory reservation, if Order item is still found backordered (BO) i.e. couldn't get any promise from Inventory then it could easily be adjudged how much more need to be promised yet based on summing up ORDER_ITEM_SHIP_GRP_INV_RES(OISGIR).QUANTIT_NOT_AVAILABLE for given order item

• How much is 'Promisable' or 'Available to Promise' (ATP) against supply: 
  Before systemic or manual promises against new demand/orders, It must be known how much is left or available to be promised. To begin with, all the future supply scheduled to come into the system from vendors or suppliers are usually gauged through Advance Shipment Notifications (ASNs) which can be expressed via SHIPMENT model in OFBiz. Assuming this to be true, here are few possible options:
  • SHIPMENT with dedicated SHIPMENT_TYPE either as 'INCOMING_SHIPMENT' or 'PURCHASE_SHIPMENT' can be recognized as scheduled inbound supply on a certain ESTIMATED_ARRIVAL_DATE (EAD) 
  • SHIPMENT_ITEM can express the Product/SKU wise details of supply in terms of QUANTITY 
  • Extend SHIPMENT_ITEM (SI) with new field 'AVAILABLE_TO_PROMISE' (ATP) to now maintain the remaining qty left to be promised at product level within a given shipment 
  • All the promises to be made for any open demand/order can be based off SI.ATP. At the same time, all the promises made based on it needs to keep on reducing it so as to reflect correct supply snapshot (very much in line with ATP on Inventory Item in OFBiz)       

• How to Promise
  There can be many ways to promise the demand against supply. Few of the automated or manual ways that can be honored (in line with how on hand Inventory is promised in OFBiz) could be based on following criteria:
  • FIFO: Order with earlier Estimated Ship Date (ESD) could get higher precedence in getting supply promised than that of later ESDs. In case of missing ESD, Order Date can be referred as fall back option
  • Order Priority: Order with higher priority takes precedence in getting supply promised than that of lower priority order.
  • Order Priority + FIFO : Order with higher priority gets precedence but within same priority orders, FIFO based rules can be applied
  • Fair Share: In this manual approach control could be more in hand of users to determine and set how much can be promised. It could come handy when sales reps or merchandisers have their own set of custom rules to be applied rather than having system making promises in automated fashion.

Depending upon the any of the preferred technique, system needs to keep pegging the 'Promisable Supply' against 'Yet to be promised demand'. One of the possible ways to maintain and capture this pegging could be:

•  Add new table ORDER_ITEM_SHIP_GRP_SHIPMENT_RES (OISGSR) with
  • ORDER_ID (PK)
  • SHIP_GROUP_SEQ_ID (PK)
  • ORDER_ITEM_SEQ_ID (PK)
  • SHIPMENT_ID (PK)
  • SHIPMENT_ITEM_SEQ_ID (PK)
  • RESERVE_ORDER_ENUM_ID (to capture the basis for promising i.e. FIFO, PRIORITY, FAIR_SHARE etc.)
  • QUANTITY (Ordered Qty)
  • QUANTITY_NOT_AVAILABLE (Un-promised Qty left if any)
  • PROMISED_DATETIME (promised date based on S.EAD)
  • PRIORITY (optional - to adjudge the shipment to be used first if same order item gets promised from multiple shipments. Lower the number, higher the priority)
  • Standard 4 timestamps 
• All the promises for an ordered item against future supply in (the form of inbound shipment) could be made based off SI.ATP
• Any promise made from Inbound shipments could keep getting captured through above table and get reflected on SI.ATP unless it gets completely exhausted i.e. goes down to ZERO.

• Where to Promise from
  At times it might be required to know from which part of supply the order is being promised specially in case there are multiple inbound supply from one or more sources. 
  • OISGSR.SHIPMENT_ID and OISGSR.SHIPMENT_ITEM_SEQ_ID could help in determining supply from which source is pegged for given order (item)

• When to Promise:
  Once its known which part of inbound supply is being used to promise order, what is equally important is to know what date should be promised to customer
  • OISGSR.PROMISED_DATETIME should be able to help in suggesting the dates to be promised for any given order of customer

Points to take into consideration during implementation:

A) Effect on supply side ATP due to change in Demand snapshot for a SKU/Product:

1. Backordered (BO) line Item gets cancelled. It could release the ATP back on Scheduled Incoming Shipment item (SI) i.e. SI.ATP would increase which in turn might end up revising promised Qty and promised Date for other BO lines for same SKU through released ATP over on hand inventory and SI.
2. Backordered (BO) qty gets revised on line item (due to update on Order item's Qty). If BO qty gets added then it would consume from SI.ATP (i.e. reduce it) and vice versa. It might end up revising the promised date for other BO lines for same SKU as well
3. Backordered (BO) line item's ESD gets updated. If ESD gets revised to a later or earlier date than current ESD then all FIFO based promises made from shipments gets reshuffled and BO lines may get revised promised date. It might end up revising the SI.ATP on all shipments for same SKU as well.
4. As described above, please note that any of the above changes on given BO line item could have cascading effects on all other SI.ATP for given SKU and also on promised Qty and/or promised Date on all other BO lines for given SKU

B) Effects on supply side ATP due to change in Supply snapshot for a SKU/Product.

1. New Inventory on hand gets added (via Inventory sync or actual receipt or returns or inventory variance or order cancellation). The BO line item for given SKU would get actual promise/reservation from added on hand Inventory. This in turn would release the SI.ATP back into system. Also at this point of time if there are still any BOs left for given SKU then they might end up getting revised promised Qty and promised Date from released SI.ATP.
2. Qty to be shipped on any Scheduled Incoming SI gets revised or new Shipment gets loaded. It would update SI.ATP which in turn might end up revising the promises made for the BO lines for same SKU due to change in SI.ATP.
3. EAD on scheduled Incoming SI gets revised. if EAD gets revised to a later or earlier than current EAD then FIFO based promises over BO lines made from shipments gets reshuffled and BO lines may get revised promised Qty and promised Date. This would in turn might revise SI.ATP
4. Scheduled Incoming Shipment itself gets cancelled. If BO lines were promised from it then It might end up shifting and reducing the SI.ATP from other shipments. Also it would end up revising the Promised Qty and Promised Date on BO lines for affected SKUs.
5. As described above, please note that any of the above changes on given Scheduled Incoming SI could have cascading effects on all other SI.ATP for given SKU and also on promised Qty and/or Promised Date on all BO lines for given SKU

Let's use this space to present more thoughts and possible choices before taking it up for implementation. 

Issue Links

• is related to: OFBIZ-12053 Promising against Future Supply of Inventory