[
https://issues.apache.org/jira/browse/OFBIZ-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15220355#comment-15220355
]
Swapnil Shah edited comment on OFBIZ-6964 at 3/31/16 6:14 PM:
--------------------------------------------------------------
Just for reference, The existing MRP simulation essentially works in two phases
(Even if RMEI is not set at Product Level):
# Initialization: MRP events get created for each Product by factoring in -->
quantity on hand(+) , approved sales orders(-) , approved purchase orders(+) ,
sales forecasts(-) , approved product requirements(+) , incoming production
runs (from which product would be produced)(+) , outgoing production runs (for
which product would be issued)(-) , minimum/safety stock (-)
# Execution: new MrpEvents get created with Proposed Quantity with dates to
replenish the product's stock via Purchase Orders, Production Runs etc. The
output is a then transformed into series of requirements of type
PRODUCT_REQUIREMENT corresponding to MrpEventType PROP_PUR_O_RECP
(i.e.,proposed for sourcing product from outside the facility) or
INTERNAL_REQUIREMENT corresponding to MrpEventType PROP_MANUF_O_RECP
(i.e.,proposed for manufacturing the product within a facility)
Point to note here is that separate MrpEvents & Requirements for sourcing are
created one based on safety stock and dependent outgoing production runs(if
any) and another based on Sales Order requirement only(if any).
was (Author: swash78):
Just for reference, The existing MRP simulation essentially works in two phases
(Even if RMEI is not set at Product Level):
# Initialization: MRP events get created for each Product by factoring in -->
quantity on hand(+) , approved sales orders(-) , approved purchase orders(+) ,
sales forecasts(-) , approved product requirements(+) , incoming production
runs (from which product would be produced)(+) , outgoing production runs (for
which product would be issued)(-) , minimum/safety stock (+)
# Execution: new MrpEvents get created with Proposed Quantity with dates to
replenish the product's stock via Purchase Orders, Production Runs etc. The
output is a then transformed into series of requirements of type
PRODUCT_REQUIREMENT corresponding to MrpEventType PROP_PUR_O_RECP
(i.e.,proposed for sourcing product from outside the facility) or
INTERNAL_REQUIREMENT corresponding to MrpEventType PROP_MANUF_O_RECP
(i.e.,proposed for manufacturing the product within a facility)
Point to note here is that separate MrpEvents & Requirements for sourcing are
created one based on safety stock and dependent outgoing production runs(if
any) and another based on Sales Order requirement only(if any).
> Support for replenishment of a secondary warehouse from a main warehouse
> ------------------------------------------------------------------------
>
> Key: OFBIZ-6964
> URL: https://issues.apache.org/jira/browse/OFBIZ-6964
> Project: OFBiz
> Issue Type: New Feature
> Components: manufacturing, product
> Reporter: Shrenik Bhura
> Labels: features
> Fix For: Upcoming Branch
>
>
> At the onset let me define a few terms clearly as I mean it in the story
> description below :
> Requirement - A request generated for a particular product for a specific
> quantity that needs to be purchased from a supplier for satisfying certain
> inventory needs of a particular facility.
> Replenishment - A request generated for a particular product for a specific
> quantity that needs to be transferred from a "backup facility" for satisfying
> certain inventory needs of a particular facility.
> Fulfilment - The process of reserving, picking, packing and shipping the
> ordered quantity of product(s) as per a sales order.
> Terms 'warehouse' and 'facility' have been used interchangeably.
> *The Use Case:*
> Consider a scenario wherein there is a website and a physical retail store of
> the same Company.
> Each having its own facility i.e. 1:1 mapping.
> {{Store A (webstore) -> associated with facility 1 (webstore facility)}}
> {{Store B (retailstore) -> associated with facility 2 (retailstore facility)}}
> However, both the stores share the same catalog/products. But both have
> independent inventory requirement and replenishment rules for the same
> product.
> There is a Requirement Method Enum ID (RMEI) of each product which is
> applicable irrespective of the store and supersedes the RMEI defined, if any,
> on a store.
> A product's inventory thresholds (Minimum Stock, Reorder Quantity) are
> independently managed via the facilities tab for the product. A product has
> its ATP and QOH levels on a per facility basis. _Do note that all these
> inventory numbers are at a facility level and has no bearing at a store
> level._
> Where the difficulty crops up with the current implementation is the way
> requirements are generated. A product can have only one RMEI. When an order
> is placed from any store, then based on the combination of a product's RMEI
> and the store mapped facility's inventory threshold, requirements are
> generated. This is without consideration of the inventory status (surplus or
> otherwise) at another facility of the same Company. If a store has multiple
> facilities associated with it then the one defined in the ProductStore entity
> -> inventoryFacilityId field would be considered for picking the inventory
> threshold values and thus for requirement generation.
> Most typical real-world facility arrangements:
> 1. Usually an organisation would have a main facility/warehouse where
> all the purchases are received and sub-facilities which are replenished from
> the main facility after QA, internal processes, etc. OR
> 2. For each product there would be a primary facility where the product
> is received from the supplier (to derive benefits of demographic convenience
> and consumption patterns) and then replenished to other facilities on a
> demand based pull basis.
> To drive efficiencies across an organisation they need methods to consider
> open fulfilment needs, in process purchase orders and inventory levels across
> multiple facilities and thereafter propose inventory transfers across them to
> facilitate better stocking and thus order fulfilment.
> Coming back to our use case, the webstore warehouse is the main facility at
> which incoming shipments from suppliers are received for the entire Company
> but sales order fulfilment happens only for the webstore. The retail
> warehouse is primarily 're-stocked' via replenishment requests raised upon
> the webstore warehouse and thus need not issue direct purchase orders to
> suppliers. However, if the need be, requirement generated based on the
> product's RMEI and the retail facility's inventory thresholds can also be
> approved, converted into Purchase order and issued.
> *Proposed Solution:*
> There doesn't seem to be an out of the box solution for this in OFBiz. This
> could work if either we think of -
> Approach A: Setting RMEI at a ProductFacility level as well which shall
> supersede the Product level RMEI setting OR
> Approach B: Build in support for a solution that I have encountered in
> Opentaps (a system built atop OFBiz) i.e. implement support for a new setting
> *Replenishment Method Enum ID (RPMEI)* and the concept of *Backup Facility*.
> The obvious difficulty with Approach A could be the need to modify existing
> logic everywhere RMEI is being used and _may_ be difficult to implement and
> validate (must confess that I have not given this approach much more
> thought). On the contrary the Approach B seems a safer method to add this
> feature with minimum possibility of breaking existing functionality.
> _Herein is the Approach B in detail-_
>
> Introduce a ProductFacility specific *Replenishment Method Enum ID (RPMEI)*
> with values such as -
> **Code snippets are from Opentaps**
> {code:xml}
> <!-- Enumeration for ProductFacility replenishMethodEnumId -->
> <EnumerationType enumTypeId="PFAC_REPL_METHOD" hasTable="N"
> description="Product Facility Replenish Methods"/>
> <Enumeration enumId="PF_RM_NEVER" description="Never transfer"
> enumTypeId="PFAC_REPL_METHOD"/>
> <Enumeration enumId="PF_RM_BACKUP" description="Transfer from backup
> warehouse if available" enumTypeId="PFAC_REPL_METHOD"/>
> <Enumeration enumId="PF_RM_SPECIF" description="Transfer from specified
> warehouse if available" enumTypeId="PFAC_REPL_METHOD"/>
> <Enumeration enumId="PF_RM_BACKUP_ALW" description="Always transfer from
> backup warehouse" enumTypeId="PFAC_REPL_METHOD"/>
> <Enumeration enumId="PF_RM_SPECIF_ALW" description="Always transfer from
> specified warehouse" enumTypeId="PFAC_REPL_METHOD"/>
> {code}
> and extend the entity ProductFacility -
> {code:xml}
> <extend-entity entity-name="ProductFacility">
> <field name="replenishMethodEnumId" type="id"/>
> <field name="replenishFromFacilityId" type="id-ne"/>
> <relation type="one" rel-entity-name="Facility" fk-name="PF_R_FAC"
> title="ResplenishFromFacility">
> <key-map field-name="facilityId"/>
> </relation>
> <relation title="ResplenishMethod" fk-name="PF_R_METH"
> rel-entity-name="Enumeration" type="one">
> <key-map field-name="replenishMethodEnumId" rel-field-name="enumId"/>
> </relation>
> </extend-entity>
> {code}
> Create new entities -
> {code:xml}
> <entity entity-name="FacilityAssoc"
> package-name="org.opentaps.common.facility"
> title="Define associations between facilities">
> <field name="facilityId" type="id-ne"/>
> <field name="facilityIdTo" type="id-ne"/>
> <field name="facilityAssocTypeId" type="id-ne"/>
> <field name="fromDate" type="date-time"/>
> <field name="thruDate" type="date-time"/>
> <field name="sequenceNum" type="numeric"/>
> <prim-key field="facilityId"/>
> <prim-key field="facilityIdTo"/>
> <prim-key field="facilityAssocTypeId"/>
> <prim-key field="fromDate"/>
> <relation type="one" fk-name="FACASSOC_FAC" title="From"
> rel-entity-name="Facility">
> <key-map field-name="facilityId"/>
> </relation>
> <relation type="one" fk-name="FACASSOC_FACTO" title="To"
> rel-entity-name="Facility">
> <key-map field-name="facilityIdTo" rel-field-name="facilityId"/>
> </relation>
> <relation type="one" fk-name="FACASSOC_TYPE"
> rel-entity-name="FacilityAssocType">
> <key-map field-name="facilityAssocTypeId"/>
> </relation>
> </entity>
> <entity entity-name="FacilityAssocType"
> package-name="org.opentaps.common.facility"
> title="Define associations between facilities">
> <field name="facilityAssocTypeId" type="id-ne"/>
> <field name="description" type="description"/>
> <prim-key field="facilityAssocTypeId"/>
> </entity>
> <FacilityAssocType facilityAssocTypeId="BACKUP_INVENTORY" description="Holds
> backup inventory"/>
> {code}
> Hence now we can define a replenishment method at a product level and that
> too on a per facility basis.
> Additional now we can provision for defining of backup facility for any
> facility. (May consider using the parentFacilityId available on the Facility
> entity but am not sure about its purpose and there is no way to define the
> relation between the parent and child.)
> We have to safeguard these:
> 1. There should be no direct or indirect cyclic backup facility
> relation between any 2 facilities due to backup facility relation definition.
> 2. There should be no direct or indirect cyclic replenishment facility
> relation created due to defining of replenishFromFacilityId in a
> ProductFacility entry for a product.
> Now when an order is placed on the retail store and ATP falls below Minimum
> Stock at the primary facility mapped to the retail store, then depending on
> the product's or store's RMEI setting combined with the facility's inventory
> thresholds a purchase requirement may be generated. However, we are not
> interested in this and may even block the generation of such a purchase
> requirement for product's which have a RPMEI defined for a particular
> facility.
> Instead on a subsequent MRP run for the retailstore facility, based on the
> open sales orders, we should generate/propose 'Inventory transfer
> requirement' from the _backup facility_ or the _replenishFromFacilityId_
> depending on what's defined in the ProductFacility entity.
> This solution should hold good even in the case of many:many mapping between
> stores and facilities as existing implementation is to reserve inventory
> against the facility that is mapped to the store via inventoryFacilityId.
> Hence there is no chance of the same sales order resulting in redundant
> requirements on multiple facilities.
> And since the RPMEI (Replenishment Method Enum Id) is defined at the
> ProductFacility level there is no possibility of a general setting of RPMEI
> at a facility or store level to compete with.
> This seems to be a rather important feature without which many businesses
> operating brick and mortar stores as well as an ecommerce web-front can't
> favourable use OFBiz.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
