Why do you need this change?
We need an event inside the OnValidate trigger of field "No." of table 5409 "Prod. Order Routing Line".
OnValidateNoOnBeforeModifyCapNeedEntries is necessary to execute custom logic after the execution of WorkCenterTransferFields() or MachineCtrTransferFields() and immediately before ModifyCapNeedEntries().
Our customization needs to evaluate both the current and previous values of the routing line (Rec and xRec) after all standard transfer logic has been completed, but before capacity need entries are updated.
At the moment there are no existing events raised at this exact point in the execution flow.
Describe the request
In the OnValidate trigger of field (8; "No."; Code[20]) of table 5409 "Prod. Order Routing Line" we need the following event:
[IntegrationEvent(false, false)]
local procedure OnValidateNoOnBeforeModifyCapNeedEntries(var Rec: Record "Prod. Order Routing Line"; xRec: Record "Prod. Order Routing Line")
begin
end;
Changes between **:
trigger OnValidate()
begin
...
case Type of
Type::"Work Center":
begin
WorkCenter.Get("No.");
WorkCenter.TestField(Blocked, false);
WorkCenterTransferFields();
end;
Type::"Machine Center":
begin
MachineCenter.Get("No.");
MachineCenter.TestField(Blocked, false);
MachineCtrTransferFields();
end;
end;
**OnValidateNoOnBeforeModifyCapNeedEntries(Rec, xRec);**
ModifyCapNeedEntries();
GetProdOrderLine();
if (ProdOrderLine."Routing Type" = ProdOrderLine."Routing Type"::Serial) or (xRec."No." <> '') then
CalcStartingEndingDates(Direction::Forward);
OnAfterValidateNo(Rec, xRec, ProdOrderLine);
end;Alternatives evaluated
We reviewed the existing extensibility points related to the validation of field "No.", including:
OnAfterValidateNo
events raised before WorkCenterTransferFields()
events raised before MachineCtrTransferFields()
None of these events provides an extensibility point after the standard transfer of Work Center or Machine Center information and immediately before:
ModifyCapNeedEntries();
Our customization depends on the values assigned by WorkCenterTransferFields() or MachineCtrTransferFields(). Therefore, subscribing to an earlier event is not sufficient because the required field values have not yet been populated.
Likewise, OnAfterValidateNo is raised after ModifyCapNeedEntries() has already updated the capacity need entries, making it too late for our scenario.
The only alternative would be duplicating the entire validation logic, which would significantly increase maintenance effort and upgrade risks.
Why xRec is required
The subscriber needs access to both Rec and xRec.
Our custom logic depends on comparing the routing line before and after validation in order to determine whether additional processing is required before capacity need entries are updated.
Rec alone contains only the current values after validation and is therefore insufficient for scenarios that require detecting changes between the previous and current state.
Providing both records follows the standard extensibility pattern used throughout Business Central validation events and avoids forcing extensions to retrieve or cache the previous record state themselves.
Performance considerations
The proposed event is executed only when field "No." of table 5409 "Prod. Order Routing Line" is validated.
This validation occurs during maintenance of production routings and production order routing lines and is not part of high-frequency batch processing.
The proposed change introduces only a single integration event invocation and does not add any database operations.
Therefore, the expected performance impact is negligible, and any additional overhead depends entirely on the subscriber implementation.
Data sensitivity review
The proposed event exposes only:
Rec: Record "Prod. Order Routing Line"
xRec: Record "Prod. Order Routing Line"
These records are already available throughout the standard manufacturing process and do not expose any new categories of information.
No personally identifiable information, credentials, secrets, or other sensitive data are introduced by this event.
Multi-extension interaction
This event does not use the IsHandled pattern.
Multiple extensions can safely subscribe and execute additional logic before ModifyCapNeedEntries() while allowing the standard behavior to continue.
The only possible interaction is that multiple subscribers may modify the same fields before the standard procedure executes. This is the normal and accepted behavior of integration events exposing record variables and does not introduce any additional extensibility risks.
Internal work item: AB#641735
Why do you need this change?
We need an event inside the OnValidate trigger of field "No." of table 5409 "Prod. Order Routing Line".
OnValidateNoOnBeforeModifyCapNeedEntries is necessary to execute custom logic after the execution of WorkCenterTransferFields() or MachineCtrTransferFields() and immediately before ModifyCapNeedEntries().
Our customization needs to evaluate both the current and previous values of the routing line (Rec and xRec) after all standard transfer logic has been completed, but before capacity need entries are updated.
At the moment there are no existing events raised at this exact point in the execution flow.
Describe the request
In the OnValidate trigger of field (8; "No."; Code[20]) of table 5409 "Prod. Order Routing Line" we need the following event:
Changes between **:
Alternatives evaluated
We reviewed the existing extensibility points related to the validation of field "No.", including:
OnAfterValidateNo
events raised before WorkCenterTransferFields()
events raised before MachineCtrTransferFields()
None of these events provides an extensibility point after the standard transfer of Work Center or Machine Center information and immediately before:
ModifyCapNeedEntries();
Our customization depends on the values assigned by WorkCenterTransferFields() or MachineCtrTransferFields(). Therefore, subscribing to an earlier event is not sufficient because the required field values have not yet been populated.
Likewise, OnAfterValidateNo is raised after ModifyCapNeedEntries() has already updated the capacity need entries, making it too late for our scenario.
The only alternative would be duplicating the entire validation logic, which would significantly increase maintenance effort and upgrade risks.
Why xRec is required
The subscriber needs access to both Rec and xRec.
Our custom logic depends on comparing the routing line before and after validation in order to determine whether additional processing is required before capacity need entries are updated.
Rec alone contains only the current values after validation and is therefore insufficient for scenarios that require detecting changes between the previous and current state.
Providing both records follows the standard extensibility pattern used throughout Business Central validation events and avoids forcing extensions to retrieve or cache the previous record state themselves.
Performance considerations
The proposed event is executed only when field "No." of table 5409 "Prod. Order Routing Line" is validated.
This validation occurs during maintenance of production routings and production order routing lines and is not part of high-frequency batch processing.
The proposed change introduces only a single integration event invocation and does not add any database operations.
Therefore, the expected performance impact is negligible, and any additional overhead depends entirely on the subscriber implementation.
Data sensitivity review
The proposed event exposes only:
Rec: Record "Prod. Order Routing Line"
xRec: Record "Prod. Order Routing Line"
These records are already available throughout the standard manufacturing process and do not expose any new categories of information.
No personally identifiable information, credentials, secrets, or other sensitive data are introduced by this event.
Multi-extension interaction
This event does not use the IsHandled pattern.
Multiple extensions can safely subscribe and execute additional logic before ModifyCapNeedEntries() while allowing the standard behavior to continue.
The only possible interaction is that multiple subscribers may modify the same fields before the standard procedure executes. This is the normal and accepted behavior of integration events exposing record variables and does not introduce any additional extensibility risks.
Internal work item: AB#641735