Default new E-Document services to import v2 and expose the version selector#9654
Open
Groenbech96 wants to merge 2 commits into
Open
Default new E-Document services to import v2 and expose the version selector#9654Groenbech96 wants to merge 2 commits into
Groenbech96 wants to merge 2 commits into
Conversation
…ersion on service card Make Version 2.0 (draft pipeline) the default import process for newly created E-Document services via InitValue on field 31, and surface the "Import Process" version selector on the E-Document Service card so users can view and switch versions. Existing services are unaffected. No v1 deprecation/obsoletion: local format apps are not yet migrated off the v1 inbound path, so v1 remains fully functional and selectable. Test preservation: pin all nine LibraryEDocument service factories to Version 1.0 so the existing receive/flow/E2E suites (which rely on the v1 mock subscribers) keep exercising v1 exactly as before. Add a unit test asserting a freshly initialized service defaults to Version 2.0. Update module docs to note the new default and selectability. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
4 tasks
github-actions
Bot
added
AL: Apps (W1)
Contributor
|
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' |
The ForNAV connector creates its E-Document Service via Insert() without setting "Import Process". Now that the field defaults to "Version 2.0", the service inherited the v2 draft pipeline, which broke the SubmitGetDocuments integration test (codeunit 148221) that asserts the v1 inbound behavior of creating a Purchase Invoice E-Document directly. ForNAV inbound is not migrated to the v2 pipeline, so explicitly pin the service to "Version 1.0" at creation time, matching the pattern already used for the mock services in codeunit "Library - E-Document". Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
Step 1 of moving the E-Document framework's inbound import onto the v2 draft pipeline: make Version 2.0 the default for newly created services and expose the version selector in the UI. Concretely:
InitValue = "Version 2.0"tofield(31) "Import Process"on tableE-Document Service. Any service initialized viaRec.Init()(the service card's "New", programmatic creation) now starts on the v2 draft pipeline. Existing/stored services are untouched.Visible = falsefrom the"Import Process"field on pageE-Document Serviceso users can see and switch the version. The value-drivenPurchaseDraft(v2) andImportParamenters(v1) groups already toggle off this field.Deliberately NOT in scope: no obsoletion/deprecation of v1. The local format apps (PEPPOL, XRechnung, ZUGFeRD, OIOUBL, Factura-E, Verifactu, FacturX, PINT ANZ, EReporting) are not yet migrated off the v1 inbound path, so v1 stays fully functional and selectable. Deprecation is a later step once formats are migrated.
Linked work
Fixes #
How I validated this
What I tested and the outcome
NewServiceDefaultsToImportProcessV2inEDocProcessTest.Codeunit.al: a freshlyInit()-edE-Document Serviceasserts"Import Process" = "Version 2.0".Init()-only factories inLibraryEDocument.Codeunit.alare now pinned toVersion 1.0, so those suites exercise v1 exactly as before — the only observers of the new v2 default are productionInit()and the new unit test. Tests that need v2 already opt in explicitly ("Import Process" := "Version 2.0").InitValuedefault only reaches records viaRec.Init(): the sole non-factory inline service creators areEDocAPITest(version-agnostic), the Microsoft365 Outlook test (noInit()→ unaffected), and demo-data codeunits (not consumed by any test; the inbound demo service is already explicitly v2).Risk & compatibility
InitValuechanges the default for records created viaInit(); existing service records keep their stored value. No upgrade/data migration.Obsoleteand no#if/pragma guards were added.E-DOCUMENTSdemo service inherits the new v2 default (Import Process is irrelevant to its send workflow); the inbound demo service was already v2.