[releases/29.0] Update expense VAT specification source- #10838

[Copilot]

Backports #10838 (itself a backport of #10312) onto releases/29.0, enforcing source-based controls on Expense VAT Specification records and improving VAT reclaim error handling during expense report posting.

Bug AB#648678

Source-based integrity

• Source field set to Agent when VAT specs are created via API, Manual when created via UI; field is now read-only with system metadata classification.
• Validation logic on Expense VAT Specification skips category/subcategory checks and calculations for agent-created records.

Immutability of agent-created records

• Modify/delete triggers block changes to VAT spec records sourced from the Expense Agent API, with clear error messages.
• UpdateVATSpecification no longer overwrites or deletes agent-created lines.

Posting & error handling

• More specific errors (with navigation actions) when VAT reclaim status is pending during expense report posting.
• Rounding difference logic now handles both amount and local currency amount.
• Expense report lines from VAT specs now copy currency code/factor and update reimbursement amounts correctly.
• Expense Location truncated to fit field length.

Cleanup

• Removed #if not CLEAN30 obsolete-pending blocks (VATSpecification action/actionref) as done in source PR.

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Request Changes

What this PR does

This backport adds source-based handling for expense VAT specifications, protects agent-created VAT spec lines from later edits, and updates posting so VAT spec amounts are carried in reimbursement currency. The approach is mostly aligned with the requested behavior, and the tests cover several VAT spec posting and currency paths. However, the page conflict resolution left references to visibility variables that are not declared in the reviewed branch, so the app cannot compile as submitted.

Problem-solution fit

Fit: Partial

The change covers the requested VAT source control and reimbursement-currency posting paths, but it is not deliverable while one page keeps stale visibility assignments after removing the related variable. Fixing that conflict should make the implementation fit the scenario more cleanly.

Suggestions

S1 (🔴 High): Page uses undeclared visibility variables
UpdateControls() still assigns AllowVATReclaim after the variable was removed, and this backport also assigns AgentEnabled without declaring it on the reviewed branch. The page will not compile. Remove the stale assignment and declare or remove each remaining visibility variable.

Risk assessment and necessity

Risk: This touches expense report posting, VAT reclaim approval, currency conversion, and upgrade backfill, so a wrong change can post wrong reimbursement or VAT amounts, or block report posting. The immediate risk is build failure in ExpenseReport.Page.al; no BaseApp publisher dependency is involved.

Necessity: The change is needed to protect agent-created VAT specification records and keep reimbursement-currency amounts accurate during posting. The scope is appropriate for the backport, but the page conflict must be corrected before merge.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=10943 round=1 by=alexei-dobriansky at=2026-09-02T13:22:59Z lastSha=c1a931ac710258992eb0c4f5d70953eb5d41edc8 reviewKey=0e5f6aa8da34b3523e91a1187c0d0804d0964ba251e515cef07744e1c29db94f suggestions=S1@5a041a1e

[alexei-dobriansky]

Good Sense Reviewer - Round 2

Recommendation: Accept

What this PR does

Since round 1, the attributable code change removes the stale AllowVATReclaim assignment from UpdateControls() on the expense report page. The remaining AgentEnabled visibility variable is declared and assigned from setup, so the previous page compile issue is resolved. I did not find any new issue in the round-2 change.

Status of previous suggestions

ID	Title	Status	Author response
S1	Page uses undeclared visibility variables	Addressed	No reply; fixed by the latest code change.

New observations (commits since round 1)

None - the attributable change only addresses the prior compile blocker.

Risk assessment and necessity

Risk: The full PR still touches expense report posting, VAT reclaim approval, currency conversion, and upgrade backfill, so the functional area remains sensitive. The round-2 change itself is narrow and only removes a stale page assignment.

Necessity: The change is needed to make the backport deliverable after the merge conflict. With the compile blocker resolved, the implementation now fits the reported VAT source-control and reimbursement-currency scenario.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=10943 round=2 by=alexei-dobriansky at=2026-09-04T13:59:32Z lastSha=004be75f4aed4310f8a108ca19031580f344c25f reviewKey=8c28c2f572fe3332302d533e172d9014c655454a2a574fca68010584a0244789 suggestions=S1@5a041a1e:addressed parentRound=1