[Event Request] [CZ] Codeunit 31018 "Rel. Purch.Adv.Letter Doc. CZZ“, procedure PerformManualRelease

[kamilvysmek]

Why do you need this change?

We need new event for application customization - customer has special approval management.

Describe the request

Please add new event into this codeunit :

31018 "Rel. Purch.Adv.Letter Doc. CZZΓÇ£

procedure PerformManualRelease(var PurchAdvLetterHeaderCZZ: Record "Purch. Adv. Letter Header CZZ")
var
AdvPaymentsApprovMgtCZZ: Codeunit "Adv. Payments Approv. Mgt. CZZ";
//New varaible ->
IsHandled: Boolean;
//New variable <-

begin

//New Code ->
IsHandled := false;
OnBeforeManualReleaseDoc(PurchAdvLetterHeaderCZZ, IsHandled);
if IsHandled then
exit;
//New Code <-

    if AdvPaymentsApprovMgtCZZ.IsPurchaseAdvanceLetterApprovalsWorkflowEnabled(PurchAdvLetterHeaderCZZ) and (PurchAdvLetterHeaderCZZ.Status = PurchAdvLetterHeaderCZZ.Status::New)
    then
        Error(ApprovalProcessReleaseErr);

    Codeunit.Run(Codeunit::"Rel. Purch.Adv.Letter Doc. CZZ", PurchAdvLetterHeaderCZZ);
end;

//New Event ->
[IntegrationEvent(false, false)]
local procedure OnBeforeManualReleaseDoc(var PurchAdvLetterHeaderCZZ: Record "Purch. Adv. Letter Header CZZ"; var IsHandled: Boolean)
begin
end;
//New Event <-
Internal work item: AB#629859

[AleksandricMarko]

Hi @kamilvysmek,

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:

• Business context and desired outcome: Explain the current limitation in PerformManualRelease and the exact behavior your extension must control.
• Meaningful justification: Provide a concrete business or technical reason beyond a generic customization need.
• Alternatives evaluated: List any existing events, extension points, or patterns you already checked and why they are insufficient.
• Why IsHandled is required: Explain why bypassing the standard release logic is necessary instead of using a non-IsHandled event.
• Performance considerations: Describe how often this logic runs and any expected impact.
• Data sensitivity review: Confirm whether any sensitive data could be exposed and, if so, why that is acceptable.
• Multi-extension interaction analysis: Describe possible conflicts if multiple extensions subscribe and how that risk should be handled.

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

[kamilvysmek]

Hi @AleksandricMarko, thanks for your quick reply.
I am sending answers :

• Business context and desired outcome: The Perform Manual Release function does not contain an event that would allow us to customize the behavior with respect to the possible approval of a purchase advance. The customer's requirement is to customize the approval process based on additional parameters

• Meaningful justification: The customer controls the approval process using the Document Kind customer modif. field, which contains a parameter whether the advance should be approved or not according to the settings of the internal document control processes

• Evaluated alternatives: This event is present in the Reopen function, as well as in the PerformManualRelease function for Purchase invoices (standard func.). The PerformManualRelease function for Purchase advances is used in several parent functions and we believe this is the right place to modify this functionality.

• Why the IsHandled event is required: The above parameterization (Document Kind and its params) allows the existing functionality to be modified in such a way that the existing code in the PerformManualRelease function must be skipped.

• Performance considerations: The functionality (Release Purchase Advance) is triggered in tens of cases per day during the manual process of processing a Purchase advance

• Data sensitivity check: Not relevant to data sensitivity.

• Multi-extension interaction analysis: The planned behavior of modification is specific only to the given customer context, and other possible behavior modifications should not have an impact (either the functionality is omitted or remains in its original scope with possible modifications in this place). If other possible modifications respect the current state of the IsHandled flag, there should be no conflict with the logic we added, which replaces the entire original code with the required modifications

[AleksandricMarko]

✅ Analysis complete - approved for implementation

---

Implementation:

Add a new IsHandled integration event before the approval-pending check in PerformManualRelease() so extensions can bypass only the approval error and still continue through the standard release flow.

Location in PerformManualRelease() procedure:

procedure PerformManualRelease(var PurchAdvLetterHeaderCZZ: Record "Purch. Adv. Letter Header CZZ")
begin
    CheckPurchaseAdvanceLetterPendingApproval(PurchAdvLetterHeaderCZZ);
    Codeunit.Run(Codeunit::"Rel. Purch.Adv.Letter Doc. CZZ", PurchAdvLetterHeaderCZZ);
end;

local procedure CheckPurchaseAdvanceLetterPendingApproval(var PurchAdvLetterHeaderCZZ: Record "Purch. Adv. Letter Header CZZ")
var
    AdvPaymentsApprovMgtCZZ: Codeunit "Adv. Payments Approv. Mgt. CZZ";
    IsHandled: Boolean;
begin
    IsHandled := false;
    OnBeforeCheckPurchaseAdvanceLetterPendingApproval(PurchAdvLetterHeaderCZZ, IsHandled);
    if IsHandled then
        exit;

    if AdvPaymentsApprovMgtCZZ.IsPurchaseAdvanceLetterApprovalsWorkflowEnabled(PurchAdvLetterHeaderCZZ) and
       (PurchAdvLetterHeaderCZZ.Status = PurchAdvLetterHeaderCZZ.Status::New)
    then
        Error(ApprovalProcessReleaseErr);
end;

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

[IntegrationEvent(false, false)]
local procedure OnBeforeCheckPurchaseAdvanceLetterPendingApproval(var PurchAdvLetterHeaderCZZ: Record "Purch. Adv. Letter Header CZZ"; var IsHandled: Boolean)
begin
end;

---

File: RelPurchAdvLetterDocCZZ.Codeunit.al