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
