Why do you need this change?
Hello, please add these new events:
1 event subscriber OnBuildMatrixForProductionBOMOnAfterGetHeader
Event Placement in procedure BuildMatrix:
Insert immediately after ProdBOMHeader.Get(ProductionBOMLine."No.") succeeds in the Type::"Production BOM" branch:
ProductionBOMLine.Type::"Production BOM":
if ProdBOMHeader.Get(ProductionBOMLine."No.") then begin
OnBuildMatrixForProductionBOMOnAfterGetHeader(ProductionBOMLine); // new event subscriber
BuildMatrix(
ProdBOMHeader."No.",
GetVersion(ProdBOMHeader."No."),
Level + 1,
Quantity * ProductionBOMLine.Quantity);
end;
Business Justification:
The Type::Item branch already exposes OnBuildMatrixForItemOnAfterGetItem(var ProductionBOMLine) immediately after Item.Get(...), allowing extensions to modify ProductionBOMLine.Quantity before the standard code uses it in recursive calls and component quantity calculations.
The Type::"Production BOM" branch has no equivalent event. Extensions that need to adjust ProductionBOMLine.Quantity for sub-BOM lines - for example, to apply a custom quantity divisor calculated from BOM header fields - cannot do so without duplicating the entire BuildMatrix procedure via OnBeforeBuildMatrix with IsHandled := true.
This asymmetry between the two branch types is the gap. The requested event fills it with an identical pattern to the already-existing Item branch event.
Alternatives Evaluated:
-
OnBeforeBuildMatrix with IsHandled := true: Would require the extension to re-implement the complete BuildMatrix procedure including all filter logic, the recursion structure, and temp table management. This is fragile and maintenance-intensive.
-
OnBuildMatrixForItemOnAfterGetItem: Only fires for Type::Item lines. Cannot be used for Type::"Production BOM" lines.
-
OnBuildMatrixForItemOnBeforeRecursion: Also Type::Item only. Same limitation.
Performance Considerations:
The event fires once per Type::"Production BOM" line within the BuildMatrix repeat loop. It provides an extension point to modify ProductionBOMLine.Quantity - no calculations occur in the event body itself. Cost is equivalent to the already-existing OnBuildMatrixForItemOnAfterGetItem event.
Data Sensitivity Review:
Exposes Production BOM Line - already read and processed at this point in the procedure. No additional data access beyond what is already in scope.
Multi-Extension Interaction:
No IsHandled. Multiple extensions can subscribe. ProductionBOMLine is passed as var - extensions execute in dependency order; the last modification to Quantity takes precedence.
2 event subscriber OnAfterCompareTwoItems
Event Placement in procedure CompareTwoItems:
Insert after both BuildMatrix calls complete, immediately before the procedure ends:
ItemAssembly := Item2;
BuildMatrix(
Item2."Production BOM No.",
VersionCode2, 1,
UOMMgt.GetQtyPerUnitOfMeasure(
Item2, UnitOfMeasureCode2) /
UOMMgt.GetQtyPerUnitOfMeasure(
Item2, Item2."Base Unit of Measure"));
OnAfterCompareTwoItems(Item1, Item2, CalcDate, NewMultiLevel, VersionCode1, VersionCode2, UnitOfMeasureCode1, UnitOfMeasureCode2); // new event subscriber
end;
Business Justification:
CompareTwoItems calls BuildMatrix twice (once per item), which internally calls BuildMatrix recursively. Extensions that use OnBeforeBuildMatrix to initialize per-call state (e.g., values derived from BOM header fields stored in a single-instance codeunit for consumption by loop-level events) need a guaranteed cleanup point after all recursive BuildMatrix calls for this operation have completed.
OnBeforeBuildMatrix fires on every recursive call - it cannot serve as a cleanup point. CompareTwoItems currently only has OnBeforeCompareTwoItems. There is no event that fires after the matrix is fully built, leaving the extension with no way to reset state without risk of it leaking into subsequent operations.
Alternatives Evaluated:
-
OnBeforeCompareTwoItems with IsHandled := true: Would require duplicating the entire procedure, including the two BuildMatrix invocations, version resolution, and UOM calculations. Prevents standard logic from running.
-
Relying on OnBeforeBuildMatrix for cleanup: OnBeforeBuildMatrix fires at the start of every recursive call, not at the end of the top-level call. It cannot serve as a post-operation cleanup point.
Performance Considerations:
Fires exactly once per CompareTwoItems call, after all processing is complete. Negligible overhead.
Data Sensitivity Review:
All parameters are values already provided by the caller and computed during the procedure. No additional data exposure.
Multi-Extension Interaction:
No IsHandled. VersionCode1/2 and UnitOfMeasureCode1/2 are var for consistency with OnBeforeCompareTwoItems and to allow post-processing of the resolved codes. Multiple subscribers coexist without conflict.
3 event subscriber OnAfterBOMMatrixFromBOM
Event Placement in procedure BOMMatrixFromBOM:
Insert after the repeat loop that processes all BOM versions completes, immediately before the procedure ends:
if ProdBOMVersion.Find('-') then
repeat
GlobalCalcDate := ProdBOMVersion."Starting Date";
BuildMatrix(ProductionBOMHeader."No.", ProdBOMVersion."Version Code", 1, 1);
until ProdBOMVersion.Next() = 0;
OnAfterBOMMatrixFromBOM(ProductionBOMHeader, NewMultiLevel); // new event subscriber
end;
Business Justification:
BOMMatrixFromBOM calls BuildMatrix multiple times - once for the base BOM and once per version. The same cleanup requirement as described for OnAfterCompareTwoItems applies: extensions using OnBeforeBuildMatrix to initialize per-call state need a single guaranteed cleanup point after all BuildMatrix calls for this operation have completed.
BOMMatrixFromBOM currently has only OnBeforeBOMMatrixFromBOM. There is no post-processing event, leaving the same gap as in CompareTwoItems.
Alternatives Evaluated:
-
OnBeforeBOMMatrixFromBOM with IsHandled := true: Would require duplicating the entire procedure including the version loop.
-
Relying on OnBeforeBuildMatrix for cleanup: Same limitation as described for OnAfterCompareTwoItems - fires at the start of each call, not as a final cleanup point.
Performance Considerations:
Fires exactly once per BOMMatrixFromBOM call, after all versions are processed. Negligible overhead.
Data Sensitivity Review:
ProductionBOMHeader is the record passed by the caller and already processed. NewMultiLevel is a boolean flag. No additional data exposure.
Multi-Extension Interaction:
No IsHandled. Parameters are by value - consistent with OnBeforeBOMMatrixFromBOM. Multiple subscribers coexist without conflict.
Describe the request
[IntegrationEvent(false, false)]
local procedure OnBuildMatrixForProductionBOMOnAfterGetHeader(var ProductionBOMLine: Record "Production BOM Line")
begin
end;
[IntegrationEvent(false, false)]
local procedure OnAfterCompareTwoItems(Item1: Record Item; Item2: Record Item; CalcDate: Date; NewMultiLevel: Boolean; var VersionCode1: Code[20]; var VersionCode2: Code[20]; var UnitOfMeasureCode1: Code[10]; var UnitOfMeasureCode2: Code[10])
begin
end;
[IntegrationEvent(false, false)]
local procedure OnAfterBOMMatrixFromBOM(ProductionBOMHeader: Record "Production BOM Header"; NewMultiLevel: Boolean)
begin
end;
Why do you need this change?
Hello, please add these new events:
1 event subscriber OnBuildMatrixForProductionBOMOnAfterGetHeader
Event Placement in procedure BuildMatrix:
Insert immediately after ProdBOMHeader.Get(ProductionBOMLine."No.") succeeds in the Type::"Production BOM" branch:
Business Justification:
The Type::Item branch already exposes OnBuildMatrixForItemOnAfterGetItem(var ProductionBOMLine) immediately after Item.Get(...), allowing extensions to modify ProductionBOMLine.Quantity before the standard code uses it in recursive calls and component quantity calculations.
The Type::"Production BOM" branch has no equivalent event. Extensions that need to adjust ProductionBOMLine.Quantity for sub-BOM lines - for example, to apply a custom quantity divisor calculated from BOM header fields - cannot do so without duplicating the entire BuildMatrix procedure via OnBeforeBuildMatrix with IsHandled := true.
This asymmetry between the two branch types is the gap. The requested event fills it with an identical pattern to the already-existing Item branch event.
Alternatives Evaluated:
OnBeforeBuildMatrix with IsHandled := true: Would require the extension to re-implement the complete BuildMatrix procedure including all filter logic, the recursion structure, and temp table management. This is fragile and maintenance-intensive.
OnBuildMatrixForItemOnAfterGetItem: Only fires for Type::Item lines. Cannot be used for Type::"Production BOM" lines.
OnBuildMatrixForItemOnBeforeRecursion: Also Type::Item only. Same limitation.
Performance Considerations:
The event fires once per Type::"Production BOM" line within the BuildMatrix repeat loop. It provides an extension point to modify ProductionBOMLine.Quantity - no calculations occur in the event body itself. Cost is equivalent to the already-existing OnBuildMatrixForItemOnAfterGetItem event.
Data Sensitivity Review:
Exposes Production BOM Line - already read and processed at this point in the procedure. No additional data access beyond what is already in scope.
Multi-Extension Interaction:
No IsHandled. Multiple extensions can subscribe. ProductionBOMLine is passed as var - extensions execute in dependency order; the last modification to Quantity takes precedence.
2 event subscriber OnAfterCompareTwoItems
Event Placement in procedure CompareTwoItems:
Insert after both BuildMatrix calls complete, immediately before the procedure ends:
Business Justification:
CompareTwoItems calls BuildMatrix twice (once per item), which internally calls BuildMatrix recursively. Extensions that use OnBeforeBuildMatrix to initialize per-call state (e.g., values derived from BOM header fields stored in a single-instance codeunit for consumption by loop-level events) need a guaranteed cleanup point after all recursive BuildMatrix calls for this operation have completed.
OnBeforeBuildMatrix fires on every recursive call - it cannot serve as a cleanup point. CompareTwoItems currently only has OnBeforeCompareTwoItems. There is no event that fires after the matrix is fully built, leaving the extension with no way to reset state without risk of it leaking into subsequent operations.
Alternatives Evaluated:
OnBeforeCompareTwoItems with IsHandled := true: Would require duplicating the entire procedure, including the two BuildMatrix invocations, version resolution, and UOM calculations. Prevents standard logic from running.
Relying on OnBeforeBuildMatrix for cleanup: OnBeforeBuildMatrix fires at the start of every recursive call, not at the end of the top-level call. It cannot serve as a post-operation cleanup point.
Performance Considerations:
Fires exactly once per CompareTwoItems call, after all processing is complete. Negligible overhead.
Data Sensitivity Review:
All parameters are values already provided by the caller and computed during the procedure. No additional data exposure.
Multi-Extension Interaction:
No IsHandled. VersionCode1/2 and UnitOfMeasureCode1/2 are var for consistency with OnBeforeCompareTwoItems and to allow post-processing of the resolved codes. Multiple subscribers coexist without conflict.
3 event subscriber OnAfterBOMMatrixFromBOM
Event Placement in procedure BOMMatrixFromBOM:
Insert after the repeat loop that processes all BOM versions completes, immediately before the procedure ends:
Business Justification:
BOMMatrixFromBOM calls BuildMatrix multiple times - once for the base BOM and once per version. The same cleanup requirement as described for OnAfterCompareTwoItems applies: extensions using OnBeforeBuildMatrix to initialize per-call state need a single guaranteed cleanup point after all BuildMatrix calls for this operation have completed.
BOMMatrixFromBOM currently has only OnBeforeBOMMatrixFromBOM. There is no post-processing event, leaving the same gap as in CompareTwoItems.
Alternatives Evaluated:
OnBeforeBOMMatrixFromBOM with IsHandled := true: Would require duplicating the entire procedure including the version loop.
Relying on OnBeforeBuildMatrix for cleanup: Same limitation as described for OnAfterCompareTwoItems - fires at the start of each call, not as a final cleanup point.
Performance Considerations:
Fires exactly once per BOMMatrixFromBOM call, after all versions are processed. Negligible overhead.
Data Sensitivity Review:
ProductionBOMHeader is the record passed by the caller and already processed. NewMultiLevel is a boolean flag. No additional data exposure.
Multi-Extension Interaction:
No IsHandled. Parameters are by value - consistent with OnBeforeBOMMatrixFromBOM. Multiple subscribers coexist without conflict.
Describe the request