Hi all, I’ve created a Jira and PR for the MRP run history/provenance work we discussed.
Jira: OFBIZ-13460 <https://issues.apache.org/jira/browse/OFBIZ-13460> PR: PR 1478 <https://github.com/apache/ofbiz-framework/pull/1478/changes> This is the additive upstream slice only. It introduces a durable MrpRunLog so MRP runs can retain lightweight history such as who ran the job, when it ran, facility/facility group context, status, duration, mrpId, and concise outcome/failure details. I’d appreciate review and feedback. I plan to merge the PR in a day or two. Thanks -- Divesh Dutta www.hotwaxsystems.com On Tue, Jul 21, 2026 at 12:36 AM Divesh Dutta < [email protected]> wrote: > Hi Swapnil, > > Thanks, this is a very useful distinction. > > I agree that because MrpEvent data is cleared/recreated by later MRP runs, > MrpRunLog should not be treated as durable historical storage for prior > event rows. In that sense, older mrpId values may no longer have > corresponding MrpEventrecords behind them after subsequent runs, and I > think that is fine as long as we are explicit about the semantics. > > My intent is for MrpRunLog to be a lightweight, self-contained run header > / audit record: who ran it, when it ran, scope, duration, status, and > outcome. Those fields remain useful even when older MrpEvent rows are no > longer available. I would still keep mrpId on the log row as > informational provenance metadata for the batch produced at execution time, > but not as a guarantee of durable linkage to retained historical events. > > I also agree that persisting a human-readable outcome/message on the run > row would be valuable, especially for failure cases, since otherwise that > detail only lives in the log file. That seems like a sensible addition. > > So I think the right framing is: > > - MrpRunLog is a durable run-history / audit header > - it does not attempt to preserve historical MrpEvent detail across > later runs > - mrpId is retained as informational run metadata, with that > limitation understood > > Appreciate you calling this out clearly. It helps tighten the proposal. > > > Thanks > > -- > > Divesh Dutta > > www.hotwaxsystems.com > > On Mon, Jul 20, 2026 at 1:33 PM Swapnil Shah < > [email protected]> wrote: > >> Hi Divesh, >> I agree there's clear value in adding a log/header entity for each MRP >> run — >> capturing mrpId, start/end time, duration, and who triggered it would give >> us auditability, a way to surface run status, and a basis for a >> run-history >> view, none of which exist today. >> >> However, as with the current logic, it wipes the entire MrpEvent table at >> the start of every run. So the moment a new run is triggered, the previous >> run's events are gone — and the header row we just added would be left >> holding an mrpId that no longer points to any events. In other words, we'd >> immediately accumulate orphan mrpIds. Every log entry except the most >> recent >> one would reference events that have already been deleted. >> >> I don't think the answer is to stop wiping and keep every run's events, as >> it isn't practically feasible. So if you are presuming to just treat the >> header as a lightweight, self-contained audit record i.e., with values >> (who/when/duration/status/outcome etc.) that doesn't depend on the >> underlying events still existing then we should also accept that older >> mrpIds in it won't have any events behind them to trace back. >> >> It would also be nice to include a free-text field — say MESSAGE — on the >> entity to record the outcome of the run: any error/exception detail on >> failure, or an aggregated success summary (e.g. number of >> events/requirements created) on completion. Right now that information >> only >> lands in the log file, which is easy to lose; persisting it on the run >> record makes failures and results visible directly in the data / UI. >> >> That said, let's see how others in the community feel about this — keen to >> hear other perspectives. >> >> Regards, >> Swapnil >> >> -----Original Message----- >> From: Divesh Dutta <[email protected]> >> Sent: 17 July 2026 12:50 >> To: [email protected]; ofbizuser <[email protected]> >> Subject: Proposal: Add durable MrpRunLog model for MRP run history and >> provenance >> >> Hi all, >> >> I would like to start a discussion about a possible additive change in >> Manufacturing to introduce a durable MrpRunLogmodel for MRP execution >> history and provenance. >> >> At present, some context for the current MRP state can be derived from >> MrpEvent records and, while available, from JobSandbox runtime data. >> However, neither seems to be a durable planner-facing source of MRP run >> history. A newer MRP run can clear or replace earlier event data, and >> JobSandbox records may be cleaned up independently as part of async job >> management. >> >> This creates two related gaps. >> >> First, some context for the latest MRP run may still be inferred from >> current MrpEvent data, but that is not durable history. Once MRP is run >> again, prior run context can be cleared or replaced. >> >> Second, user and execution provenance often depends on JobSandbox and its >> runtime data. When those job records are cleaned up, details such as who >> ran >> MRP, when it was run, and how it was triggered may no longer be available >> in >> a planner-friendly form. >> >> As a result, the main gap is not only about the latest run, but about >> durable run history overall. After a new MRP execution, it becomes >> difficult >> to determine: >> >> - what previous MRP runs were executed >> - when those runs happened >> - who ran them >> - for which facility or facility group they were executed >> - whether they completed successfully or failed >> - which mrpId each run produced >> - how long each run took >> - what planning evidence or proposals were associated with those runs >> at >> that time >> >> The idea would be to add a new MrpRunLog entity as a lightweight run >> header >> for MRP executions. >> >> A possible initial set of fields would be: >> >> - mrpRunLogId >> - mrpId >> - jobId >> - mrpName >> - facilityId >> - facilityGroupId >> - defaultYearsOffset >> - runByUserLoginId >> - runStatusId >> - startedAt >> - finishedAt >> - durationMillis >> >> The execution flow would remain additive and backward-compatible: >> >> - create a run-log record before or while scheduling/running MRP >> - mark it running when executeMrp starts >> - store the generated mrpId once available >> - mark it finished or failed at the end >> - record duration for history and troubleshooting >> >> The intent is not to replace either MrpEvent or JobSandbox, but to keep >> responsibilities separate: >> >> - MrpEvent: detailed planning evidence for the current run >> - JobSandbox: technical async execution state >> - MrpRunLog: durable business-level run history and provenance >> >> This proposal would not aim to change: >> >> - MRP quantity calculations >> - requirement generation logic >> - existing MrpEvent semantics >> - existing MRP screens or callers that do not use the new run-log >> inputs >> >> The goal would be to provide a more durable and explicit source for MRP >> run >> history while keeping the change small and additive. >> >> I would appreciate feedback on a few points: >> >> - Does it make sense for MRP run provenance to have its own durable >> model instead of relying only on JobSandboxand current MrpEvent state? >> - Does MrpRunLog seem like a reasonable boundary for this >> responsibility? >> - Are there fields that should be added or removed from the proposed >> model? >> - Are there concerns about compatibility or placement within the >> existing manufacturing data model? >> >> If there is general agreement on the direction, I can create a Jira ticket >> and begin work on this solution. >> >> >> Thanks >> >> -- >> >> Divesh Dutta >> >> www.hotwaxsystems.com >> >
