This PR is merged into the trunk. Thanks -- Divesh Dutta www.hotwaxsystems.com
On Tue, Jul 21, 2026 at 5:24 PM Divesh Dutta <[email protected]> wrote: > Hi all, > > Following up on the earlier discussion, I have now opened the Jira issue > and PR for review: > > OFBIZ-13459: > https://issues.apache.org/jira/browse/OFBIZ-13459 > > PR #1474: > https://github.com/apache/ofbiz-framework/pull/1474 > > This change is intentionally narrow. It preserves facilityId on generated > MrpEvent rows only when the MRP engine already has reliable facility > context from source data or the current run context. > > The intent is to improve planner traceability without changing MRP > calculation behavior, MrpEvent identity, or merge semantics. > > For facilityGroupId runs, the current code still resolves the run to > concrete facilities before event creation, and the PR preserves those > resolved facilities on the event rows rather than stamping the group id > itself. > > Feedback and review would be appreciated. I will merge this PR in a day > or two. > > Thanks > > -- > > Divesh Dutta > > www.hotwaxsystems.com > > On Tue, Jul 21, 2026 at 12:06 AM Divesh Dutta < > [email protected]> wrote: > >> Hi Swapnil, >> >> Thanks, this is a helpful suggestion. >> >> I agree that a dedicated MrpRun or MrpRunLog/Header record is the right >> place to store run-level provenance such as facilityGroupId, the >> resolved planning context, and other execution metadata. That avoids >> repeating purely run-level information on every event row. >> >> At the same time, I think that is complementary to MrpEvent.facilityId, >> rather than a full replacement for it. >> >> The reason is that, in the current MRP flow, the same run can emit events >> that belong to different concrete facility contexts. For example, >> warehouse-oriented events and manufacturing-oriented events can both be >> produced within one run. In the facilityGroupId case, the current logic >> resolves the group into a warehouse facility and a manufacturing facility >> for the run, and different event types can naturally belong to one or the >> other. >> >> Because of that, I do not think facility varies only at the run level in >> the current model. MrpRun can tell us the overall planning context of >> the run, but MrpEvent.facilityId still helps tell us which concrete >> facility a particular event belongs to. >> >> So my current thinking is: >> >> - MrpRun should carry run-level provenance such as facilityGroupId and >> resolved run context >> - MrpEvent.facilityId should carry per-event facility context when >> the engine already knows it >> - the two pieces are complementary rather than overlapping >> >> That seems to preserve both traceability at the event level and clean >> provenance at the run level. >> >> Thanks >> >> -- >> Divesh Dutta >> >> www.hotwaxsystems.com >> >> On Mon, Jul 20, 2026 at 3:03 PM Swapnil Shah < >> [email protected]> wrote: >> >>> 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 >>> >> >>> > >>> >>
