[jira] [Created] (OFBIZ-12054) Solution Design - OFBIZ-12053: Promising against Future Supply

["Swapnil Shah (Jira)" <ji...@apache.org>]

Swapnil Shah created OFBIZ-12054:
------------------------------------

             Summary: Solution Design - OFBIZ-12053: Promising against Future Supply
                 Key: OFBIZ-12054
                 URL: https://issues.apache.org/jira/browse/OFBIZ-12054
             Project: OFBiz
          Issue Type: Task
          Components: order
            Reporter: Swapnil Shah
             Fix For: Upcoming Branch


*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 ATP due to change in Demand snapshot for a SKU/Product:*
 # *_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.
 # *_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
 # *_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.
 # 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 ATP due to change in Supply snapshot for a SKU/Product.*
 # 
*******_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.
 # 
*_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.
 # 
*_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
 # 
*_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.
 # 
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. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)