Thanks Divesh for your research and it sounds good to me. On an alternate thought, as you proposed in another thread (Proposal: Add durable MrpRunLog model for MRP run history and provenance) to have new MrpRun(Log/Header) entity with facilityId (and facilityGroupId) on the MrpRun record, and every MrpEvent already carries mrpId as an FK to it. The facility is then recorded exactly once, at the level where it actually varies. It could avoid per-row redundancy, half-populated column, and stays correct automatically. It could be pretty non-invasive too for the core MRP service.
Regards, Swapnil -----Original Message----- From: Divesh Dutta <[email protected]> Sent: 17 July 2026 20:43 To: [email protected] Cc: [email protected] Subject: Re: Proposal: Preserve known facility context on MRP events generated by the OFBiz MRP engine Hi Swapnil, I checked this in the current code paths. For the event types covered by this proposal, I currently do not see a practical cross-facility merge case within a single MRP run, even though facilityId is not part of MrpEvent identity. The reason is that these event sources are already scoped by the run’s resolved planning facility, and the later generated proposal/component events also inherit a single run-scoped warehouse or manufacturing facility. I also checked the facilityGroupId case specifically. In the current executeMrp flow, a facility group is still resolved into one concrete warehouse facility and one concrete manufacturing facility for the run. So this proposal would stamp those resolved concrete facilities on the generated MrpEvent rows, not the facility group itself. So based on the current code, I believe this first change can still be kept narrow and described as a traceability improvement only: - preserve already-known facility context on MrpEvent - do not change event identity - do not change merge semantics If OFBiz later wants true multi-facility event separation within a single run, that would likely need to be addressed separately. Thanks -- Divesh Dutta www.hotwaxsystems.com On Fri, Jul 17, 2026 at 8:31 PM Divesh Dutta <[email protected]> wrote: > 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 >> >
