Hi Swapnil, Thanks, that is a very helpful point.
You are right that the current proposal is not intended as an algorithmic MRP change. The main goal is to preserve facility context on MrpEvent for planner traceability when the engine already has that context available. You also raised an important concern about event merging. In the current implementation, MrpEvent merging is based on the existing event key and does not use facilityId, so stamping alone would not guarantee per-facility separation if mixed-facility events ever land on the same product/date/type combination within a run. I will verify whether any of the proposed stamping paths can actually produce that kind of cross-facility merge in practice inside a single MRP run. If they can, that likely needs to be treated as a separate design question. I will get back to you on this. For the current proposal, I will keep the scope narrow and describe it as preserving already-known facility context on MrpEvent, not as changing event identity or merge behavior. Thanks, Divesh Dutta -- www.hotwaxsystems.com On Fri, Jul 17, 2026 at 7:08 PM Swapnil Shah <[email protected]> wrote: > Hi Divesh, > OFBiz MRP run is essentially single-facility-scoped i.e. it resolves one > facilityId up front (from facilityId or facilityGroupId). It looks like the > recorded MrpEvent.facilityId is essentially informational. As nothing in > the > algorithm reads it back, so the gap as such has no functional effect. > > However, you may still like to check if there is any case where multiple > events for the same product/date combo could get silently merged across > facilities as it might create a false sense of per-facility separation > while > the quantities still collapse together. > > Regards, > Swapnil > > -----Original Message----- > From: Divesh Dutta <[email protected]> > Sent: 17 July 2026 11:37 > To: [email protected]; ofbizuser <[email protected]> > Subject: Proposal: Preserve known facility context on MRP events generated > by the OFBiz MRP engine > > Hi all, > > I would like to propose an improvement to the OFBiz MRP engine around how > it > generates MrpEvent records. > > Today, the OFBiz MRP engine can create MrpEvent rows without facilityId > even > when the planning signal being processed is already tied to a specific > warehouse or manufacturing facility. In other words, the engine often > already has facility context available while processing demand, supply, > requirements, production runs, or stock policy records, but that context is > not always preserved on the generated MRP event. > > This becomes a problem for planners because the event stream loses > warehouse-level traceability even though the source planning data was > facility-aware. > > In practice, this can lead to issues such as: > > > - Product-plus-facility event timelines being incomplete or harder to > trust > - Proposed supply appearing disconnected from the warehouse or plant it > is intended for > - Exception or setup views showing events as effectively unassigned > - Multi-warehouse planning becomes harder to interpret once source > records are converted into MRP events > > > The core idea behind this proposal is simple: when the OFBiz MRP engine > already has a reliable facilityId in hand while creating an event, it > should > preserve that value on the MrpEvent instead of dropping it. > > This is not meant to force facility assignment onto every planning signal. > If the source record is truly organization-level, or if there is no > reliable > facility context available, then the event should remain facility-less. > > Below is the proposed stamping behavior by event type. > > > *For sales order demand (SALES_ORDER_SHIP):* > > - Use the facility from the source query result when one is already > available > - If no facility is known, leave the event facility empty > > > > *For approved requirements (PROD_REQ_RECP):* > > - Use the facility already present on the requirement > > > > *For purchase order receipt events (PUR_ORDER_RECP):* > > - Use the current planning facility when the MRP run itself is > facility-scoped > > > > *For production run demand and receipt (MANUF_ORDER_REQ, > MANUF_ORDER_RECP):* > > - Use the facility already associated with the production run > > > > *For stock policy marker events (REQUIRED_MRP):* > > - Use the ProductFacility.facilityId from the source record, since the > minimum stock condition is facility-specific > > > > *For component requirement events (MRP_REQUIREMENT) created during BOM > explosion:* > > - Use the manufacturing facility of the parent proposed manufacturing > plan > > > > *For proposed supply events:* > > - Use the planning warehouse for proposed purchase supply > - Use the manufacturing facility for proposed manufacturing supply > > > > *For MRP error events:* > > - When the error occurs while processing a facility-specific planning > context, preserve that facility on the error event as well > > > I would also like to propose a conservative improvement when updating > existing MrpEvent rows. If an existing event was previously created without > facilityId, and a later matching update has a valid facility, then the > missing facility could be backfilled only when the existing value is empty. > This would not overwrite any existing facility assignment, but it would > avoid permanently losing context once it becomes available for the same > merged event. > > The benefits for planners are fairly direct: > > > - Better product-plus-warehouse event views > - Clearer traceability for proposed replenishment > - More accurate understanding of which warehouse or plant an event > belongs to > - Improved exception analysis in multi-facility planning > - Better backend event data for API-first or headless planning > applications > > > I believe this is a low-risk improvement because it does not change MRP > quantity calculations, planning rules, or event identity. It simply > preserves facility context that the OFBiz MRP engine already knows at the > time the event is generated. > > I would appreciate feedback on this proposal, especially on: > > > - Whether this principle makes sense for MrpEvent generation in the > OFBiz MRP engine > - Whether any of the event categories above should intentionally remain > facility-less even when facility context is available > - Whether conservative backfilling of missing facilityId during event > merge seems acceptable > > > Thanks, > Divesh Dutta > www.hotwaxsystems.com >
