[Event Request] Table 246 "Requisition Line" - OnBeforeUpdateReplenishmentSystem

[LorenzoSartori-NBT]

Why do you need this change?

We are migrating a legacy customization from Dynamics NAV to Business Central.
In our scenario, we have a custom boolean field on the Item table (e.g., "No Stockkeeping"). When a user changes the "Location Code" or "Variant Code" on a Requisition Line, the system automatically triggers the UpdateReplenishmentSystem() local procedure.

If our custom flag on the Item is set to true, we must completely bypass the standard logic that fetches the SKU parameters and updates the "Replenishment System".

Alternatives Evaluated:
We evaluated using the existing event OnBeforeValidateReplenishmentSystem. However, this event is triggered at the very end of the process, after the system has already executed Item.GetSKU("Location Code", "Variant Code") and evaluated the Subcontracting logic. We need to bypass the entire procedure from the beginning to avoid unnecessary database reads and standard evaluations that conflict with our custom item setup.

Justification for IsHandled:
An IsHandled pattern at the beginning of the UpdateReplenishmentSystem procedure is essential to allow partners to skip the standard replenishment recalculation based on custom Item/SKU routing rules, without affecting the rest of the OnValidate triggers of Location and Variant codes.

Describe the request

Please add a new integration event OnBeforeUpdateReplenishmentSystem with an IsHandled pattern at the beginning of the UpdateReplenishmentSystem local procedure in Table 246 "Requisition Line".

Requested Event Signature:

[IntegrationEvent(false, false)]
local procedure OnBeforeUpdateReplenishmentSystem(var RequisitionLine: Record "Requisition Line"; var IsHandled: Boolean)
begin
end;

local procedure UpdateReplenishmentSystem()
    var
        StockkeepingUnit: Record "Stockkeeping Unit";
        IsHandled: Boolean;
    begin
        // >>> NEW EVENT REQUEST
        IsHandled := false;
        OnBeforeUpdateReplenishmentSystem(Rec, IsHandled);
        if IsHandled then
            exit;
        // <<< NEW EVENT REQUEST

        GetItem();
        StockkeepingUnit := Item.GetSKU("Location Code", "Variant Code");
        if Subcontracting then
            StockkeepingUnit."Replenishment System" := StockkeepingUnit."Replenishment System"::"Prod. Order";
        ValidateReplenishmentSystem(StockkeepingUnit);
    end;

[AleksandricMarko]

Hi @LorenzoSartori-NBT,

Thanks for submitting this extensibility request. To help us process it efficiently, please update the issue to include the required information.

📚 Extensibility Guidelines

Missing Information:

• Performance Considerations: Please provide the expected execution frequency of the UpdateReplenishmentSystem procedure (e.g., how often this will be called during typical usage) and assess the potential performance impact of allowing subscribers to bypass this logic.
• Data Sensitivity Review: Please confirm that no sensitive or confidential data is exposed through the event parameters, or provide rationale if exposure is necessary for the functionality.
• Multi-Extension Interaction: Please discuss the potential risks if multiple extensions subscribe to this IsHandled event and describe strategies to mitigate conflicts (e.g., execution order dependencies).

Please update the issue with the missing details. We'll automatically re-analyze once updated.

[LorenzoSartori-NBT]

Update with required Extensibility Guidelines information:

1. Performance Considerations:
   Execution frequency: The UpdateReplenishmentSystem procedure is called every time the "Location Code" or "Variant Code" is validated on a Requisition Line. This occurs during manual data entry by users or when planning batch jobs (like Calculate Plan) insert or modify requisition lines.
   Performance impact: The performance impact is actually positive. By allowing subscribers to set IsHandled := true, we prevent the system from executing unnecessary database reads (like Item.GetSKU) and standard evaluations for items that follow custom routing rules. The event itself is a lightweight memory operation with negligible overhead.
2. Data Sensitivity Review:
   No sensitive data is exposed. The event only passes the Requisition Line record and a boolean flag. The data involved consists of standard supply chain and planning parameters (Item No., Location, Variant, Quantities). There is no exposure of PII (Personally Identifiable Information), GDPR-sensitive data, or confidential financial data.
3. Multi-Extension Interaction:
   Risks: As with any IsHandled pattern, if multiple extensions subscribe to this event and attempt to bypass the standard logic, the first subscriber to execute will take precedence. This could theoretically cause conflicts if two different apps try to enforce different replenishment rules on the same item.
   Mitigation: All subscribers must implement the standard safeguard if IsHandled then exit; at the very beginning of their event subscriber. Furthermore, the bypass logic is typically bound to specific custom setup fields (e.g., a custom boolean on the Item card). Therefore, the IsHandled flag will only be triggered for items explicitly configured to use that specific extension's logic, drastically reducing the chance of conflicts with other generic apps.