Current Situation

The OnBeforeLoadCapBack event in Codeunit 99000810 (Shop Calendar Management) currently exposes only three parameters:

ProdStartingDate: Date

ProdStartingTime: Time

IsHandled: Boolean

This means subscribers have no access to the production order's ending date/time at the point where the calendar entry scan is initiated.

Requested Change

Add ProdEndingDate: Date and ProdEndingTime: Time as var parameters to the OnBeforeLoadCapBack event signature, so that subscribers can both read and override the ending boundary of the capacity lookback scan.

Proposed signature:

OnBeforeLoadCapBack(var ProdStartingDate: Date; var ProdStartingTime: Time; var ProdEndingDate: Date; var ProdEndingTime: Time; var IsHandled: Boolean)

Business Justification / Use Case

In production environments with large calendar entry datasets, the current implementation scans from ProdStartingDate/ProdStartingTime all the way back to 0D/0T as the lower bound. On companies with years of calendar history, this causes full-history table scans on the Calendar Entry table, resulting in significant performance degradation during production order scheduling and capacity planning.

With access to ProdEndingDate and ProdEndingTime via a var parameter, a subscriber could constrain the lookback window to a configurable number of days relative to the production ending date — for example, limiting the scan to 60 or 90 days back — rather than scanning from the dawn of time.

Existing Pattern

The OnAfterLoadCapBack event (if present in the same codeunit) already follows the convention of exposing both start and end date/time context to subscribers. The OnBeforeLoadCapBack event should be brought in line with that pattern for consistency and to enable the symmetrical use case of overriding the scan boundaries before execution begins.