Align the Vend. Entry-Edit post-modify event with its Cust. Entry-Edit counterpart

[Franco111000]

What & why

Codeunit 113 "Vend. Entry-Edit" raises OnRunOnAfterVendLedgEntryMofidy after the vendor ledger entry is modified. The event name is misspelled, and it only exposes the modified entry. Its counterpart in codeunit 103 "Cust. Entry-Edit", OnRunOnAfterCustLedgEntryModify, passes both the record given to the codeunit and the modified entry, so vendor-side subscribers get less context than customer-side subscribers for the same hook point.

This change adds OnRunOnAfterVendLedgEntryModify with the exact shape of the customer event (both records passed by var, XML documentation mirroring the customer wording) and obsoletes the misspelled event with the standard #if not CLEAN29 pattern. The misspelled event is still declared and raised until cleanup, so existing subscribers keep working and get the usual obsolete warning pointing to the replacement. The country layers that carry full copies of the codeunit (APAC, CH, IT, NA, NL, NO, RU) receive the identical change, following the established practice of propagating W1 fixes to the localization layers.

Linked work

Fixes #8316

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

• Verified the new event signature is a one-to-one mirror of OnRunOnAfterCustLedgEntryModify in codeunit 103: first parameter is the record passed to the codeunit, second is the modified entry, both by var, raised immediately after Modify().
• Searched the whole repository for references to OnRunOnAfterVendLedgEntryMofidy: the only occurrences are the declaration and the raise in the eight copies of the codeunit itself. No app or test subscribes to it, so the obsoletion cannot break in-repo code.
• The obsoletion follows the pattern already used in the repository for replaced events (obsolete attribute and old raise wrapped in #if not CLEAN29, new event raised unconditionally), for example OnBeforeCalculateAndGetPlanningCompList in CalcItemPlanPlanWksh.Codeunit.al from the 27.0 wave.
• Confirmed the diff is uniform across W1 and the seven layer copies and contains only the two blocks per file (call site and event declarations).
• No tests added: the change is an additive integration event plus a guarded obsoletion, with no behavior change when no subscriber is registered. The customer counterpart event has no dedicated test either.
• I did not build the Base Application locally; the change is event-only and relies on CI for compilation across all layers.

Risk & compatibility

• No breaking change: the misspelled event remains declared and raised until CLEAN29, so external subscribers keep working while the obsolete warning steers them to the replacement.
• The new event is raised at the same execution point as the old one, right after Modify() and before Rec := VendLedgEntry, so both events observe the same record state.
• None beyond that: no object signatures, table schema, or permissions are affected.

Fixes AB#641574

[github-actions]

Copilot PR Review

Iteration 1 · Outcome: completed

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

Findings by domain

Findings split into Knowledge-backed (cite a BCQuality article) and Agent (the agent's own judgement, no matching BCQuality rule).

Domain	Findings	Knowledge-backed	Agent	Inline	Fallback
Agent	1	0	1	1	0

Totals: 0 knowledge-backed · 1 agent findings.

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

What this PR does

This PR adds the correctly named OnRunOnAfterVendLedgEntryModify event to all in-repo Vend. Entry-Edit BaseApp copies and keeps the misspelled OnRunOnAfterVendLedgEntryMofidy event obsolete under #if not CLEAN29.

The new vendor event matches the Cust. Entry-Edit counterpart in the important parts: it is raised immediately after Modify(), before Rec := ..., and it passes the record given to the codeunit plus the modified ledger entry, both by var. The old event is still raised for non-clean builds, so current subscribers keep compiling while new subscribers can move to the aligned event.

Suggestions

No blocking or optional suggestions.

Risk assessment and necessity

Risk: This is a public BaseApp integration event change, so subscriber compatibility is the main risk. I verified the publishers and call sites in src/Layers/**/BaseApp/Purchases/Payables/VendEntryEdit.Codeunit.al; the old misspelled event remains declared and raised under #if not CLEAN29, and the new event is additive.

Necessity: No AB# work item is linked, so there is no ADO work item type or [AI-REPRO] comment to use. GitHub issue #8316 clearly describes the customer/vendor asymmetry, and the change scope is limited to aligning that event across the affected BaseApp copies. Tests are not a blocker for this event-only alignment because behavior is unchanged without subscribers.

---

[AI-PR-REVIEW] version=1 system=github pr=9098 round=1 by=alexei-dobriansky at=2026-07-07 lastSha=d12c91115d38a7ba46e5aa4cc6663e1bf1abeed1 suggestions=none