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 >
