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
