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
