Erick Martinez

When you add a new task to the job, as you cannot give that task different criteria, as it retains the original task criteria.

When you deal with various operations that works with batch job on the recurrence part, we need the recurring batch jobs with different sets of parameters to use this single batch class. But for example, the base batch class of InventTransferMultiReceive that we tested, the parameters do not hold with multiple batch jobs.

As you can see this was already submitted but it worth to take a second look.

Issue 940513

Currently the Delete Sales orders clean up routine is consuming a lot of time even when we select just a week range. The search is not efficient, if we select a larger range the system freeze.

In our current implementation of Planning Optimization, we’ve encountered a significant limitation: approved planned orders are being overwritten by subsequent MRP runs if the approval occurs after the batch job has started. This behavior, while aligned with current system design, is creating operational friction for our business users.

In our environment, it is common for users to make changes to planned orders and approve them throughout the day. However, because the Planning Optimization engine only captures a snapshot of data at the start of the batch job, any approvals made afterward are not respected—leading to those orders being overwritten. This was not the case with the classic master planning engine, which allowed for more flexible MRP execution without disrupting approved plans.

Proposed Enhancement:

Introduce a feature or configuration option that ensures approved planned orders are preserved during MRP runs, even if the approval occurs after the batch job has started. This could involve:

• A real-time check for approval status before overwriting.
• A buffer or grace period for recently approved orders.
• A toggle to prevent overwriting of any approved orders regardless of timing.