Make E-Document import processing v2 (drafts) the default; deprecate v1 inbound import

[Groenbech96]

What & why

Makes Import Processing v2 (the multi-stage draft pipeline) the default for the E-Document framework and begins the deprecation of the legacy v1 single-shot import. The setup page and new services now flow through v2; v1 remains available but is marked obsolete-pending for removal in 29.0.

Concretely, this branch:

• Defaults new services to v2 — "E-Document Service"."Import Process" field 31 now has InitValue = "Version 2.0", so freshly initialized services use the draft pipeline. The setup/service card surfaces the v2 groups by default and hides v1-only inbound configuration.
• Obsoletes the two inbound interface methods on interface "E-Document" — GetBasicInfoFromReceivedDocument and GetCompleteInfoFromReceivedDocument — with [Obsolete('… v2 draft pipeline (IStructuredFormatReader / IProcessStructuredData) …', '29.0')]. The outbound Check / Create / CreateBatch methods are untouched.
• Obsoletes the "Version 1.0" value of enum "E-Document Import Process" (#if not CLEAN29).
• Obsoletes the v1-only service-table fields (Create Journal Lines; Validate Receiving Company; Resolve UoM; Lookup Item Reference / GTIN / Account Mapping; Validate Line Discount; Apply Invoice Discount; Verify Totals; Gen. Journal Template/Batch Name; Import Process) using the two-stage pattern (#if not CLEANSCHEMA32, Pending '29.0' / Removed '32.0').
• Guards all v1 consumers (runner codeunits, shared callers, UI, permissions, telemetry) behind #if not CLEAN29 and updates the framework docs.

All obsoletions are partial and phase-gated, so the pending phase compiles and behaves exactly as before while signalling the migration path.

Linked work

Fixes #

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

• Local AL build/run is not possible in this environment (no symbol packages), so correctness rests on static verification plus the CI gate (pending-phase compile + the Uncategorized/Integration/Legacy test buckets). The effective CI ruleset (src/rulesets/base.ruleset.json) sets AL0432 = None, so obsolete-pending references are compile-clean by policy.
• Tests added/updated: NewServiceDefaultsToImportProcessV2 (asserts Init() yields Import Process = Version 2.0). The v1-oriented test factories in Library - E-Document were pinned to Version 1.0 (guarded #if not CLEAN29) so the InitValue change does not silently flip the existing receive/flow suites onto the v2 path.
• Static review: the full branch diff was reviewed twice by an independent reviewer; two runtime-regression findings (an unhandled service-card notification, and the factory version-flip) were fixed in 1de9b56a31 and re-confirmed resolved. Preprocessor/pragma balance verified on every changed .al file.

Risk & compatibility

• Deprecations (breaking in a future major, not now): the two inbound interface "E-Document" methods, the "Version 1.0" import-process enum value, and the listed v1-only service fields are obsolete-pending as of 29.0. Extensions implementing the inbound v1 methods should migrate to IStructuredFormatReader / IProcessStructuredData. Table fields follow the two-stage schema removal (Removed in 32.0).
• Default behavior change: new services default to v2. Existing services keep whatever Import Process they already have — no data migration is performed.
• Connectors: no connector app code changes are required; existing connector tests were audited and continue to create v1 services via the shared library helpers.
• Follow-up: the plan/spec docs on main that describe a v1 "deprecation notification" should be reconciled — the notification was intentionally dropped from the UI in favor of the field-level obsoletion.

[github-actions]

Could not find a linked ADO work item. Please link one by using the pattern 'AB#' followed by the relevant work item number. You may use the 'Fixes' keyword to automatically resolve the work item when the pull request is merged. E.g. 'Fixes AB#1234'

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Breaking\ Changes}$

New logic is being added inside members already marked [Obsolete] (since BC 26.0) and inside new #if not CLEAN29 branches in the E-Document test service factory helpers. This ties current behavior to code paths that are themselves scheduled for removal and creates an avoidable extra migration burden when CLEAN29/CLEAN26 is enabled. The same pattern recurs at multiple overloads in this file (e.g. the already-[Obsolete('...','26.0')] CreateService(Integration: Enum "E-Document Integration"), CreateTestReceiveServiceForEDoc(Integration: Enum "E-Document Integration"), and CreateGetBasicInfoErrorReceiveServiceForEDoc(Integration: Enum "E-Document Integration") overloads), all of which gain a new #if not CLEAN29 ... EDocService."Import Process" := ..."Version 1.0" ... #endif statement inside an already-obsolete member. Move the v1 pinning to a supported, non-obsolete helper instead of extending obsolete/transient code paths.

Knowledge:

• microsoft/knowledge/breaking-changes/do-not-modify-code-already-marked-obsolete.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.12.4}

[Groenbech96]

Superseded by #9654. Scoped down to just step 1: default new services to import v2 (InitValue) and expose the version selector on the service card, with no v1 deprecation/obsoletion — the local format apps aren't migrated off v1 yet. This PR was too broad (49 files, obsoletes across many apps); #9654 is 7 files, +26/-4.