This PR is merged into the trunk. Thanks -- Divesh Dutta www.hotwaxsystems.com
On Tue, Jul 21, 2026 at 7:25 PM Divesh Dutta <[email protected]> wrote: > 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 >>> >>
