[W1][Codeunit][99000760]["Mfg. Item Jnl. Check Line"][Procedure OnRunOnCheckWarehouse - NewEvent OnBeforeOnRunOnCheckWarehouse]

[gangabhushan-std2026]

Why do you need this change?

We currently have two subscribers associated with the OnRunOnCheckWarehouse publisher event: one provided by the standard Microsoft application and another implemented in our extension.

When posting Consumption transactions through our application, the warehouse validation logic executed in the local procedure OnRunOnCheckWarehouse of codeunit 99000760 "Mfg. Item Jnl. Check Line" is preventing further processing as it is called by MS standard event.

To handle this scenario, we require a handler event to conditionally bypass this validation logic for transactions from our application. Provide an extensibility point (publisher event) within OnRunOnCheckWarehouse would allow extensions to skip the standard validation, when necessary, while preserving the existing behavior for all other scenarios.

Describe the request

Introduce a new publisher 'OnBeforeOnRunOnCheckWarehouse' event in procedure OnRunOnCheckWarehouse that allows extensions to skip the standard validation logic when required from our application.

[EventSubscriber(ObjectType::Codeunit, Codeunit::"Item Jnl.-Check Line", 'OnRunOnCheckWarehouse', '', true, false)]
local procedure OnRunOnCheckWarehouse(var ItemJournalLine: Record "Item Journal Line"; CalledFromAdjustment: Boolean; CalledFromInvtPutawayPick: Boolean)
var
ProdOrderLine: Record "Prod. Order Line";
WorkCenter: Record "Work Center";
IsHandled: Boolean;
ShouldCheckItemNo: Boolean;
Begin
// New Event Request>>
IsHandled := false;
OnBeforeOnRunOnCheckWarehouse(ItemJournalLine, CalledFromAdjustment, CalledFromInvtPutawayPick, IsHandled);
if IsHandled then
exit;
// New Event Request<<

    if (ItemJournalLine."Entry Type" in [ItemJournalLine."Entry Type"::Consumption, ItemJournalLine."Entry Type"::Output]) and
       not (ItemJournalLine."Value Entry Type" = ItemJournalLine."Value Entry Type"::Revaluation) and
       not ItemJournalLine.OnlyStopTime()
    then begin
        ItemJournalLine.TestField("Source No.", ErrorInfo.Create());
        ItemJournalLine.TestField("Order Type", ItemJournalLine."Order Type"::Production, ErrorInfo.Create());
        ShouldCheckItemNo := not CalledFromAdjustment and (ItemJournalLine."Entry Type" = ItemJournalLine."Entry Type"::Output);
        OnRunCheckOnAfterCalcShouldCheckItemNo(ItemJournalLine, ProdOrderLine, CalledFromAdjustment, ShouldCheckItemNo);
        .....
        .....
    end;
end;



[IntegrationEvent(false, false)]
local procedure OnBeforeOnRunOnCheckWarehouse(var ItemJournalLine: Record "Item Journal Line"; CalledFromAdjustment: Boolean; CalledFromInvtPutawayPick: Boolean; var IsHandled: Boolean)
begin
end;

Internal work item: AB#642012

[github-actions]

Hi @gangabhushan-std2026,

Thank you for your extensibility request. To help us process it efficiently, please update the issue to include the required information.

📚 Extensibility Guidelines

Missing Information:

• Performance considerations: Please describe the expected execution frequency of this IsHandled event and any performance impact considerations.
• Data sensitivity review: Please confirm that the proposed event does not expose sensitive data, or explain why any exposed data is necessary.
• Multi-extension interaction considerations: Please explain possible conflicts if multiple extensions subscribe and set IsHandled, and how that risk should be handled.

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

Note

Automatically generated by the Triage Agent — advisory only. An engineer will review before any action is taken.

Tip

Not accurate? Reply with /not-accurate (optional: add a short explanation). Your feedback improves future responses.

[gangabhushan-std2026]

Updated Missing Information:

Performance considerations

The proposed OnBeforeOnRunOnCheckWarehouse event is expected to execute only when the existing OnRunOnCheckWarehouse publisher is invoked during Item Journal validation, primarily for Consumption and Output posting scenarios. These operations occur only during manufacturing posting processes and are not part of high-frequency background processing.

The event itself performs only a single publisher invocation and an IsHandled check before the existing validation logic. If no extension subscribes to the event, the runtime overhead is negligible. Extensions that subscribe to the event are responsible for keeping their implementation lightweight, as the intended usage is only to determine whether the standard validation should be bypassed for specific scenarios.

Therefore, the proposed event is not expected to introduce any measurable performance impact on standard posting operations.

Data sensitivity review

The proposed event exposes only the existing Item Journal Line record together with the existing Boolean context parameters (CalledFromAdjustment and CalledFromInvtPutawayPick) and the IsHandled flag. All of this information is already available within the standard posting process and does not introduce any new business data or sensitive information.

The exposed parameters are necessary to allow extensions to make an informed decision about whether the warehouse validation should be skipped for a specific posting scenario. No confidential or security-sensitive data is exposed beyond what is already accessible during the posting execution context.

Multi-extension interaction considerations

As with other IsHandled publisher events in Business Central, multiple extensions may subscribe to this event. If one subscriber sets IsHandled := true, the standard validation logic is skipped, which may affect the expectations of other subscribers.

This behavior follows the established Business Central extensibility pattern and is appropriate because the event is intended to provide a complete override of the standard validation when required. Extensions should implement appropriate conditions before setting IsHandled and should only do so for scenarios they explicitly own (for example, transactions initiated by their own application).

If multiple extensions attempt to bypass the validation simultaneously, the first subscriber that sets IsHandled := true effectively takes responsibility for the validation outcome. This is consistent with existing IsHandled patterns throughout the Base Application, and extension developers are expected to avoid conflicts by scoping their logic to their own business scenarios.

[github-actions]

Hi @gangabhushan-std2026,

Thank you for your extensibility request. Unfortunately, this request cannot be implemented.

Reason: The requested IsHandled event at the start of OnRunOnCheckWarehouse would bypass critical manufacturing validations beyond warehouse checking, including Source No., Order Type, production order line/item consistency, and subcontracting validation. A narrower existing event, OnBeforeCheckWarehouse, already allows bypassing only the warehouse validation.

Note

Automatically generated by the Triage Agent — advisory only. An engineer will review before any action is taken.

Tip

Not accurate? Reply with /not-accurate (optional: add a short explanation). Your feedback improves future responses.

[gangabhushan-std2026]

/not-accurate (This is blocking our customized process. As We are extending the solution from Embed Application (25) to Cloud version 28)

[github-actions]

✅ Feedback recorded
Thanks — your /not-accurate feedback has been logged and will be reviewed.