[ALAppExtensions #30313]codeunit 441 "Prepayment Mgt." OnBeforeReleaseSalesDocument

[Explorer986]

What & why

Adds OnBeforeUpdatePendingPrepaymentSales and OnAfterUpdatePendingPrepaymentSales integration events around the sales loop in UpdatePendingPrepaymentSales() of codeunit 441 "Prepayment Mgt.". This gives partners a signal specific to the prepayment-driven release flow (before/after processing) that the generic Release Sales Document events do not distinguish. Additive publishers with XML-doc comments matching the codeunit's existing style.

Linked work

Fixes AB#641536

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome

• Diff review: two event-raise calls wrapping the existing loop plus two documented publishers; the loop itself is untouched.
• No tests added: additive integration-event publishers with no behavior change when unsubscribed.

Risk & compatibility

Very low. New publishers only; no existing event signatures changed, no schema/data impact.

[github-actions]

Copilot PR Review

Iteration 1 · Outcome: completed

Knowledge source: https://github.com/microsoft/BCQuality@822cae1b2771ac25f665f73369f69093bd4fd630

Orchestrator pre-filter (13 file(s) excluded)

• layer-disabled (knowledge) : 13 file(s)

_{Findings produced by the Copilot CLI agent against BCQuality at 822cae1b2771ac25f665f73369f69093bd4fd630. Reply 👎 on any inline comment to flag false positives.}

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Request Changes

What this PR does

The diff adds two integration events around UpdatePendingPrepaymentSales(): OnBeforeUpdatePendingPrepaymentSales before FindSet, and OnAfterUpdatePendingPrepaymentSales after the loop. The publishers use [IntegrationEvent(false, false)], and there is no IsHandled path, so standard behavior is unchanged when there are no subscribers.

The placement does not match the stated request for an event before the sales document is released. Subscribers get the filtered record set before the loop, not the specific sales order that has passed TestSalesPayment and is about to run Release Sales Document.

Suggestions

S1 - Publish before each sales release
The request is for a prepayment-specific event before the sales document is released. Raise OnBeforeReleaseSalesDocument(var SalesHeader) (or the approved AA0228-compliant name) inside the if not PrepaymentMgt.TestSalesPayment(SalesHeader) block, just before CODEUNIT.Run(CODEUNIT::"Release Sales Document", SalesHeader). This gives subscribers the exact order that will be released.

S2 - Align the title and implementation
The title and work item still describe OnBeforeReleaseSalesDocument. If the intended design is the before/after batch events, update the title and linked request so the public contract is clear. Otherwise keep the change to the requested before-release publisher.

Risk assessment and necessity

Risk: This is a public integration-event contract in prepayment release flow. The current event names and timing would be hard to change after release, and subscribers may need to repeat the standard loop logic to find the order that is actually going to be released. There is no behavior change without subscribers.

Necessity: The extensibility scenario is valid: partners need to distinguish releases started by UpdatePendingPrepaymentSales() from other calls to Release Sales Document. The change should stay small, but it needs to publish at the correct point before the release call or clearly document that the accepted scope changed to batch-level events.

---

[AI-PR-REVIEW] version=1 system=github pr=9416 round=1 by=alexei-dobriansky at=2026-07-14T11:06:19Z lastSha=faef99f1024b1e56d7a91da282e03abd280042a3 suggestions=S1,S2