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)
