[
https://issues.apache.org/jira/browse/OFBIZ-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yashwant Dhakad reassigned OFBIZ-12054:
---------------------------------------
Assignee: Yashwant Dhakad
> 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
> Assignee: Yashwant Dhakad
> Priority: Major
> 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 side 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 side 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)
