[Event Request] Codeunit 99000818 "Mfg. Carry Out Action" - OnBeforeCarryOutActionsFromProdOrderCaseStatement

[LorenzoSartori-NBT]

Why do you need this change?

Following the rejection of issue #29709 and the recommendations provided by the Microsoft team, I am requesting a NEW event with an IsHandled pattern in Codeunit 99000818 "Mfg. Carry Out Action", inside the CarryOutActionsFromProdOrder procedure.

We need to bypass the standard case statement based on the ProdOrderChoice parameter, regardless of the RequisitionLine."Action Message".

Describe the request

Please add the following new integration event:

[IntegrationEvent(false, false)]
local procedure OnBeforeCarryOutActionsFromProdOrderCaseStatement(var RequisitionLine: Record "Requisition Line"; ProdOrderChoice: Enum "Planning Create Prod. Order"; ProdWkshTempl: Code[10]; ProdWkshName: Code[10]; var TempDocumentEntry: Record "Document Entry" temporary; var sender: Codeunit "Carry Out Action"; var Result: Boolean; var IsHandled: Boolean)
begin
end;

And implement it inside the CarryOutActionsFromProdOrder procedure in Codeunit 99000818 "Mfg. Carry Out Action" as follows:

procedure CarryOutActionsFromProdOrder(RequisitionLine: Record "Requisition Line"; ProdOrderChoice: Enum "Planning Create Prod. Order"; ProdWkshTempl: Code[10]; ProdWkshName: Code[10]; var TempDocumentEntry: Record "Document Entry" temporary; var sender: Codeunit "Carry Out Action"): Boolean
var
IsHandled: Boolean;
Result: Boolean;
begin
PrintOrder := ProdOrderChoice = ProdOrderChoice::"Firm Planned & Print";
OnCarryOutActionsFromProdOrderOnAfterCalcPrintOrder(PrintOrder, ProdOrderChoice.AsInteger());
#if not CLEAN27
CarryOutAction.RunOnCarryOutActionsFromProdOrderOnAfterCalcPrintOrder(PrintOrder, ProdOrderChoice.AsInteger());
#endif

    // >>> NEW EVENT REQUEST
    IsHandled := false;
    OnBeforeCarryOutActionsFromProdOrderCaseStatement(RequisitionLine, ProdOrderChoice, ProdWkshTempl, ProdWkshName, TempDocumentEntry, sender, Result, IsHandled);
    if IsHandled then
        exit(Result);
    // <<< NEW EVENT REQUEST

    case RequisitionLine."Action Message" of
        RequisitionLine."Action Message"::New:
            if ProdOrderChoice = ProdOrderChoice::"Copy to Req. Wksh" then
                sender.CarryOutToReqWksh(RequisitionLine, ProdWkshTempl, ProdWkshName)
            else
                InsertProductionOrder(RequisitionLine, ProdOrderChoice, TempDocumentEntry);
        RequisitionLine."Action Message"::"Change Qty.",
        RequisitionLine."Action Message"::Reschedule,
        RequisitionLine."Action Message"::"Resched. & Chg. Qty.":
            exit(ProdOrderChgAndReshedule(RequisitionLine));
        RequisitionLine."Action Message"::Cancel:
            DeleteProdOrderLines(RequisitionLine);
    end;
    exit(true);
end;

Internal work item: AB#625529

[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:

• Alternatives Evaluated: Please explain which existing events or patterns you tried and why they are insufficient for your scenario. You mentioned issue Extend event OnCarryOutActionsFromProdOrderOnAfterCalcPrintOrder in Codeunit 99000813 #29709 was rejected, but please clarify what alternatives you evaluated.

• Justification for IsHandled: The current justification "We need to bypass the standard case statement" is too generic. Please provide:

  • Specific technical reason why a standard event is insufficient
  • Concrete business logic that must be skipped/replaced
  • Exact scenario where bypass is essential
  • Why alternative approaches won't work

  Example of good justification: "We must bypass the standard case statement because our vertical industry (e.g., automotive manufacturing) requires custom production order routing based on real-time machine availability. The standard logic creates orders based solely on Action Message, but we need to evaluate machine capacity and material availability before deciding whether to create, reschedule, or split production orders. There's no way to inject our routing logic after the case statement executes because the production order would already be created with wrong parameters."

• Performance Considerations: What is the expected execution frequency of this event? How many times will it be called during typical operations (per transaction, per line, per batch)? What is the potential performance impact?

• Data Sensitivity Review: Please confirm that no sensitive data is being exposed through this event parameters, or provide rationale if exposure is necessary.

• Multi-Extension Interaction: What are the risks if multiple extensions subscribe to this event with IsHandled? How should conflicts be mitigated?

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

[LorenzoSartori-NBT]

1. Alternatives Evaluated:
   We evaluated using existing events in Codeunit 99000818 (and previously 99000813). The only event triggered before the case statement is OnCarryOutActionsFromProdOrderOnAfterCalcPrintOrder. As discussed in the rejected issue Extend event OnCarryOutActionsFromProdOrderOnAfterCalcPrintOrder in Codeunit 99000813 #29709, we cannot add an IsHandled parameter to this existing event because it would break the signature for current subscribers.
   We also evaluated subscribing to events inside or after the case statement, but this is not viable. If we wait for the standard case to execute, the system will have already executed ProdOrderChgAndReshedule or DeleteProdOrderLines, modifying or deleting live Production Orders in the database, which is exactly what we need to prevent.

2. Justification for IsHandled:
   We must bypass the standard case statement because of a specific business requirement regarding the planning workflow.
   In standard Business Central, if a user runs "Carry Out Action Messages" and selects ProdOrderChoice::"Copy to Req. Wksh", the system respects this choice only if the RequisitionLine."Action Message" is New. For all other action messages (Change Qty., Reschedule, Cancel), the standard code ignores the user's choice and directly modifies or deletes the Production Orders.
   Our customer's planning department requires a strict validation workflow: all planning suggestions (including changes and cancellations) must be routed to the Requisition Worksheet for review before committing them to actual Production Orders.
   Therefore, if the user selects "Copy to Req. Wksh", we must bypass the standard case statement to execute CarryOutToReqWksh for any Action Message, preventing the system from automatically altering live Production Orders against the planner's intent.

3. Performance Considerations:
   Execution frequency: The event will be called once per Requisition Line processed during the "Carry Out Action Messages" batch job.
   Performance impact: Negligible. It is a standard event publisher with a boolean check running in memory before any heavy database operations (like inserting or modifying production orders) occur.

4. Data Sensitivity Review:
   No sensitive data is exposed. The parameters involved (Requisition Line, Document Entry, and standard Enums/Codes) contain standard manufacturing and planning data. There is no exposure of PII, GDPR-sensitive, or confidential financial data beyond what is already accessible to a user authorized to run the planning engine.

5. Multi-Extension Interaction:
   Risks: If multiple extensions subscribe to this event and set IsHandled := true, the first one to execute will take precedence.
   Mitigation: Subscribers should follow the standard pattern of checking if IsHandled then exit; at the very beginning of their logic. Furthermore, the bypass logic is highly specific to a precise user selection (ProdOrderChoice = ProdOrderChoice::"Copy to Req. Wksh"), making conflicts with other generic extensions highly unlikely.

[AleksandricMarko]

✅ Analysis complete - approved for implementation

---

Implementation:

Add a new integration event in the CarryOutActionsFromProdOrder procedure of Codeunit 99000818 "Mfg. Carry Out Action" before the case statement to allow bypassing the standard action message processing.

Location in CarryOutActionsFromProdOrder procedure (around line 48):

procedure CarryOutActionsFromProdOrder(RequisitionLine: Record "Requisition Line"; ProdOrderChoice: Enum "Planning Create Prod. Order"; ProdWkshTempl: Code[10]; ProdWkshName: Code[10]; var TempDocumentEntry: Record "Document Entry" temporary; var sender: Codeunit "Carry Out Action"): Boolean
var
    IsHandled: Boolean;
begin
    PrintOrder := ProdOrderChoice = ProdOrderChoice::"Firm Planned & Print";
    OnCarryOutActionsFromProdOrderOnAfterCalcPrintOrder(PrintOrder, ProdOrderChoice.AsInteger());
#if not CLEAN27
    CarryOutAction.RunOnCarryOutActionsFromProdOrderOnAfterCalcPrintOrder(PrintOrder, ProdOrderChoice.AsInteger());
#endif

    IsHandled := false;
    OnCarryOutActionsFromProdOrderOnBeforeCaseStatement(RequisitionLine, ProdOrderChoice, ProdWkshTempl, ProdWkshName, TempDocumentEntry, sender, IsHandled);
    if IsHandled then
        exit(true);

    case RequisitionLine."Action Message" of
        RequisitionLine."Action Message"::New:
            if ProdOrderChoice = ProdOrderChoice::"Copy to Req. Wksh" then
                sender.CarryOutToReqWksh(RequisitionLine, ProdWkshTempl, ProdWkshName)
            else
                InsertProductionOrder(RequisitionLine, ProdOrderChoice, TempDocumentEntry);
        RequisitionLine."Action Message"::"Change Qty.",
        RequisitionLine."Action Message"::Reschedule,
        RequisitionLine."Action Message"::"Resched. & Chg. Qty.":
            exit(ProdOrderChgAndReshedule(RequisitionLine));
        RequisitionLine."Action Message"::Cancel:
            DeleteProdOrderLines(RequisitionLine);
    end;
    exit(true);
end;

Event Publisher (add at the end of the codeunit with other events):

[IntegrationEvent(false, false)]
local procedure OnCarryOutActionsFromProdOrderOnBeforeCaseStatement(RequisitionLine: Record "Requisition Line"; ProdOrderChoice: Enum "Planning Create Prod. Order"; ProdWkshTempl: Code[10]; ProdWkshName: Code[10]; var TempDocumentEntry: Record "Document Entry" temporary; var sender: Codeunit "Carry Out Action"; var IsHandled: Boolean)
begin
end;

---

File: MfgCarryOutAction.Codeunit.al

[JesperSchulz]

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.

Build ID: 47814.