[PEPPOL] Add PEPPOL SE localization: Swedish organisation number for endpoints under scheme 0007 by Franco111000 · Pull Request #8646 · microsoft/BCApps

Franco111000 · 2026-06-17T09:59:17Z

What and why

Swedish PEPPOL BIS 3.0 documents fail at the access point because the supplier/customer electronic address (cbc:EndpointID) and the cac:PartyLegalEntity/cbc:CompanyID are emitted as the full 14-character Swedish VAT number (for example SE733078715601) under schemeID="0007". Scheme 0007 is SE:ORGNR, which per PEPPOL-COMMON-R049 must be exactly the 10-digit Swedish organisation number (7330787156).

Per review feedback, the fix is implemented as a new PEPPOL SE localization app (src/Apps/SE/PeppolSE), following the PEPPOL DE pattern, and the earlier changes to the shared W1 PEPPOL codeunit are fully reverted:

PEPPOL 3.0 Format enum extension adds PEPPOL 3.0 - SE Sales and PEPPOL 3.0 - SE Service, binding the PEPPOL Party Info Provider to a new PEPPOL30 SE Party Info codeunit (standard W1 validation and iterator are reused).
The SE party info provider delegates every method to the standard PEPPOL30 implementation and post-processes only four of them: the endpoint identifiers are reduced to the 10-digit organisation number when the emitted schemeID is 0007, and the legal entity identifiers when the party's Country/Region VAT Scheme is 0007. GLN setups (0088), Denmark (0184), and Swedish parties registered under EAS 9955 (SE:VAT, where the full VAT is correct) are untouched by construction. cac:PartyTaxScheme/cbc:CompanyID (BT-31/BT-48) keeps the full VAT number.
New PEPPOL 3.0 Setup records default to the SE formats on insert, mirroring PEPPOL DE. Existing setups keep their configured format; an install/upgrade step re-defaulting existing SE tenants can be added if preferred.
A PEPPOL SE Tests app covers the provider through the enum interface dispatch, plus a posted sales invoice XML export.

Note: for a blank bill-to country the country scheme falls back to the company's country, which is the same fallback the W1 implementation already uses to emit the endpoint schemeID, so the value stays consistent with the declared scheme.

Linked work

Fixes #7723

How I validated

Unit tests through the SE format dispatch: supplier and customer EndpointID and PartyLegalEntity/CompanyID return 7330787156 under scheme 0007
Regression test: an SE party under scheme 9955 keeps the full VAT (not stripped)
Test: PartyTaxScheme/CompanyID keeps the full VAT
Test: a newly created PEPPOL 3.0 Setup defaults to the SE formats
End-to-end test: a PEPPOL BIS 3.0 sales invoice export asserts both endpoints and the preserved PartyTaxScheme
Relied on PR CI for compilation and the full test run (this repo builds via AL-Go)

Risk and compatibility

The shared W1 PEPPOL app is unchanged in this PR; every other country is byte-for-byte unaffected.
The SE behaviour only activates when the SE formats are selected in PEPPOL 3.0 Setup (defaulted for new setups in the SE localization).
No schema, table, or API changes.

Fixes AB#641595

PEPPOL BIS 3.0 scheme 0007 (SE:ORGNR) requires the 10-digit Swedish organisation number, but the EndpointID and PartyLegalEntity CompanyID carried the full 14-char VAT (SE...01), which access points reject (PEPPOL-COMMON-R049). Extract the organisation number for SE parties whose Country/Region VAT Scheme is 0007, leaving the PartyTaxScheme VAT identifier and all other countries unchanged. Add SE coverage to the PEPPOL BIS billing tests.

…endpoint-orgno

The new Swedish organisation-number branches used else-if, which AA0018 rejects. Split them so the if starts its own line, and document the keep-only-digits extraction in GetSwedishOrgNo.

Franco111000 · 2026-06-22T09:07:41Z

Pushed b4b5c7604 addressing the review feedback and the failing build:

Split the new Swedish organisation-number branches so each if starts its own line (the build was red on AA0018); this is purely stylistic and the logic is unchanged.
Documented the digit-extraction step in GetSwedishOrgNo (per the inline suggestion).
Merged the latest main.

Also replied inline on the silent-fallback point.

github-actions · 2026-06-29T11:34:03Z

Copilot PR Review

Iteration 8 · Outcome: completed

Knowledge source: https://github.com/microsoft/BCQuality@186d8a131465475c79244d994acb872cd5c0d4bf

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

layer-disabled (knowledge) : 2 file(s)

_{Findings produced by the AL review agent v1.7.3. Reply 👎 on any inline comment to flag false positives.}

…ort test Validating a changed Country/Region Code on Company Information clears City, Post Code and County, so the SE export test failed the PEPPOL company checks with "City must have a value". Set City and Post Code after switching the company to SE. Test-only change.

Franco111000 · 2026-07-02T12:39:10Z

Pushed 6fd2805c06 fixing the failing test ExportXml_PEPPOL_BIS3_SalesInvoice_SEOrgNo: validating the changed Country/Region Code on Company Information clears City and Post Code, so the PEPPOL company checks failed with "City must have a value". The test helper now restores both after switching the company to SE. Test-only change; the app code is untouched.

Groenbech96 · 2026-07-09T09:05:00Z

I think the proper design is to create swedish localization, that implemetns the GetAccountingSupplierPartyInfo.
There are examples of this for Norway, BE, and other countries.

So should be fairly trivial change. Long term better design choice.

Groenbech96

See my comment.

…endpoint-orgno

…ndpoints Move the Swedish organisation number handling from the shared W1 PEPPOL codeunit into a new PEPPOL SE localization app, following the PEPPOL DE pattern. The SE party info provider delegates to the W1 implementation and reduces endpoint and legal entity identifiers to the 10-digit organisation number when they are emitted under scheme 0007 (SE:ORGNR), leaving the party tax scheme VAT identifier and all other countries untouched. Default new PEPPOL 3.0 Setup records to the SE formats, add a PEPPOL SE test app covering the provider, and wire both apps into the SE build project.

Co-authored-by: Alexander Holstrup <117829001+aholstrup1@users.noreply.github.com>

This reverts commit 1c20d08.

github-actions · 2026-07-16T15:36:59Z

+        // Keep only digits: the inner DelChr removes all digits, leaving the non-digit characters as a mask;
+        // the outer DelChr then removes that mask from the original, so only the digits remain.
+        DigitsOnly := DelChr(VATRegistrationNo, '=', DelChr(VATRegistrationNo, '=', '0123456789'));
+        if StrLen(DigitsOnly) >= 10 then


$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling} \quad \color{gray}{\texttt{\small Iteration\ 6}}$

When GetSwedishOrgNo receives a value with fewer than 10 digits, it silently returns the original VAT registration number.

For scheme 0007 this can export an invalid EndpointID/CompanyID instead of failing with a clear validation error. Validate that at least 10 digits were found and raise an explicit error when the organisation number cannot be derived.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

Same consideration as in the earlier iteration 1 thread on the former W1 version of this helper: it is a formatter, mirroring the existing FormatVATRegistrationNo helpers, which format rather than raise. A value with fewer than 10 digits only occurs when a party under scheme 0007 has a malformed VAT registration, which already failed PEPPOL-COMMON-R049 at the receiving access point before this change, so passing the value through keeps behaviour no worse than today and surfaces the precise schematron error. Raising here would additionally block a sender when the malformed registration belongs to the customer, which they may not control.

github-actions · 2026-07-16T15:37:01Z

+    begin
+        if Rec.IsTemporary() then
+            exit;
+
+        Rec."PEPPOL 3.0 Sales Format" := Rec."PEPPOL 3.0 Sales Format"::"PEPPOL 3.0 - SE Sales";
+        Rec."PEPPOL 3.0 Service Format" := Rec."PEPPOL 3.0 Service Format"::"PEPPOL 3.0 - SE Service";
+        Rec.Modify();
+    end;


$\textbf{🟡\ Medium\ Severity\ —\ Events} \quad \color{gray}{\texttt{\small Iteration\ 6}}$

The OnAfterInsert subscriber ignores its RunTrigger parameter and still rewrites PEPPOL 3.0 Setup.

When this table is inserted with Insert(false), the trigger event still reaches subscribers, so this localization code applies SE defaults and performs an extra Modify() even though the caller explicitly suppressed trigger logic. Exit when RunTrigger is false to keep the subscriber aligned with trigger-suppressed inserts.

Suggested change

begin

if Rec.IsTemporary() then

exit;

Rec."PEPPOL 3.0 Sales Format" := Rec."PEPPOL 3.0 Sales Format"::"PEPPOL 3.0 - SE Sales";

Rec."PEPPOL 3.0 Service Format" := Rec."PEPPOL 3.0 Service Format"::"PEPPOL 3.0 - SE Service";

Rec.Modify();

end;

begin

if Rec.IsTemporary() then

exit;

if not RunTrigger then

exit;

Rec."PEPPOL 3.0 Sales Format" := Rec."PEPPOL 3.0 Sales Format"::"PEPPOL 3.0 - SE Sales";

Rec."PEPPOL 3.0 Service Format" := Rec."PEPPOL 3.0 Service Format"::"PEPPOL 3.0 - SE Service";

Rec.Modify();

end;

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

Good catch, honored in 2a25684: the subscriber now exits when RunTrigger is false, so trigger-suppressed inserts (for example configuration package imports) keep their values.

github-actions · 2026-07-16T15:37:03Z

+        if Rec.IsTemporary() then
+            exit;
+
+        Rec."PEPPOL 3.0 Sales Format" := Rec."PEPPOL 3.0 Sales Format"::"PEPPOL 3.0 - SE Sales";


$\textbf{🟠\ High\ Severity\ —\ Interfaces} \quad \color{gray}{\texttt{\small Iteration\ 6}}$

The new SE formats are persisted into "PEPPOL 3.0 Setup", but "PEPPOL 3.0 Format" still relies on DefaultImplementation only.

If this localization is later uninstalled, the stored 37450/37451 ordinals become unknown and assigning the setup value to interface variables will raise a runtime error instead of a controlled fallback. Add an UnknownValueImplementation on the base enum, or avoid persisting extension-owned values.

Knowledge:

microsoft/knowledge/interfaces/handle-unknown-enum-ordinals-with-unknownvalueimplementation.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

Fair architectural point, but the fix belongs on the base "PEPPOL 3.0 Format" enum in the W1 PEPPOL app, and this PR is deliberately scoped to the SE localization only (the earlier W1 changes were reverted per review). The same exposure already exists for the persisted DE, BE, NO and NA format values, so it seems better addressed centrally for all country extensions. @Groenbech96 happy to file a follow-up issue proposing an UnknownValueImplementation on the base enum if you agree.

github-actions · 2026-07-16T15:37:05Z

+    [Test]
+    procedure ExportXml_PEPPOL_BIS3_SalesInvoice_SEOrgNo()


$\textbf{🟠\ High\ Severity\ —\ Testing} \quad \color{gray}{\texttt{\small Iteration\ 6}}$

ExportXml_PEPPOL_BIS3_SalesInvoice_SEOrgNo posts a sales invoice through LibrarySales.PostSalesDocument but has no [TransactionModel(TransactionModel::AutoCommit)] attribute.

Test methods default to AutoRollback, so the posting commit path can fail with a transaction-model error before the assertions run.

Suggested change

[Test]

procedure ExportXml_PEPPOL_BIS3_SalesInvoice_SEOrgNo()

[Test]

[TransactionModel(TransactionModel::AutoCommit)]

procedure ExportXml_PEPPOL_BIS3_SalesInvoice_SEOrgNo()

Knowledge:

microsoft/knowledge/testing/transactionmodel-attribute-governs-test-transactions.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

The W1 suite this test mirrors, PEPPOL BIS BillingTests, posts sales and service documents at 13 call sites without a TransactionModel attribute, and the OIOUBL posting tests in the DK localization do the same, so the default transaction model demonstrably handles this posting path in the test framework. Following that precedent here; if the SE pipeline shows otherwise, happy to add the attribute.

github-actions · 2026-07-16T15:37:06Z

+
+        // [THEN] EndpointID keeps the full VAT (scheme 9955 expects the VAT, not the organisation number)
+        Assert.AreEqual(GetSEVATSchemeID(), SupplierSchemeID, '');
+        Assert.AreNotEqual(GetExpectedSEOrgNo(), SupplierEndpointID, 'VAT must not be stripped to the organisation number when the scheme is 9955.');


$\textbf{🟡\ Medium\ Severity\ —\ Testing} \quad \color{gray}{\texttt{\small Iteration\ 6}}$

GetAccountingSupplierPartyInfo_VATScheme9955_SE only checks that EndpointID is not the stripped organisation number and still contains the VAT digits.

A malformed value like a prefixed or suffixed string would still pass. Assert the exact expected VAT registration number instead.

Suggested change

Assert.AreNotEqual(GetExpectedSEOrgNo(), SupplierEndpointID, 'VAT must not be stripped to the organisation number when the scheme is 9955.');

Assert.AreEqual(GetSETestVATRegNo(), SupplierEndpointID, 'EndpointID must keep the full Swedish VAT under scheme 9955.');

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

Done in 2a25684, exact equality asserted.

github-actions · 2026-07-16T15:37:07Z

+        PartyInfoProvider.GetAccountingSupplierPartyTaxScheme(CompanyID, CompanyIDSchemeID, TaxSchemeID);
+
+        // [THEN] CompanyID keeps the full VAT, not the stripped organisation number
+        Assert.AreNotEqual(GetExpectedSEOrgNo(), CompanyID, 'PartyTaxScheme CompanyID must not be the stripped organisation number.');


$\textbf{🟡\ Medium\ Severity\ —\ Testing} \quad \color{gray}{\texttt{\small Iteration\ 6}}$

GetAccountingSupplierPartyTaxScheme_VATRegNo_SE uses a negative check plus substring match for CompanyID, so values that merely contain the VAT digits still pass.

Because the expected full VAT is known, the test should assert exact equality.

Suggested change

Assert.AreNotEqual(GetExpectedSEOrgNo(), CompanyID, 'PartyTaxScheme CompanyID must not be the stripped organisation number.');

Assert.AreEqual(GetSETestVATRegNo(), CompanyID, 'PartyTaxScheme CompanyID must retain the full Swedish VAT.');

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

Done in 2a25684, exact equality asserted.

github-actions · 2026-07-16T15:37:09Z

+    end;
+
+    [Test]
+    procedure PEPPOL30SetupDefaultsToSEFormats()


$\textbf{🟡\ Medium\ Severity\ —\ Testing} \quad \color{gray}{\texttt{\small Iteration\ 6}}$

PEPPOL30SetupDefaultsToSEFormats only covers creating a missing PEPPOL 3.0 Setup record.

This PR also adds OnInstallAppPerCompany migration logic that updates an already-existing setup record only when it still uses the W1 defaults, but the new suite never exercises that upgrade path or the 'do not override a custom format' branch. Add a test for the install-migration behavior.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

Added in 2a25684: the migration procedure is exposed to the test app via internalsVisibleTo, with tests covering both the move-from-W1-defaults branch and the keep-configured-format branch.

github-actions · 2026-07-16T15:37:10Z

+    InherentPermissions = X;
+    Access = Internal;
+
+    trigger OnInstallAppPerCompany()


$\textbf{🟡\ Medium\ Severity\ —\ Upgrade} \quad \color{gray}{\texttt{\small Iteration\ 6}}$

OnInstallAppPerCompany always calls SetSEFormatsOnExistingSetup() without first checking AppInfo.DataVersion().

Per the install guidance, this trigger also runs on reinstall, so first-install migration logic should be gated to Version.Create('0.0.0.0') or split into an explicit reinstall path. As written, reinstalling the app over preserved company data can reapply this migration and overwrite setup values that happen to still equal the W1 defaults.

Knowledge:

microsoft/knowledge/upgrade/first-install-dataversion-zero-check.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

Adopted in 2a25684: the migration now runs only when DataVersion() is 0.0.0.0, per the linked guidance, so a reinstall over preserved data does not re-apply it.

Honor RunTrigger in the PEPPOL 3.0 Setup insert subscriber so trigger-suppressed inserts (for example configuration package imports) are not overwritten. Gate the install migration on a zero DataVersion so a reinstall over preserved data does not re-apply it. Assert exact values in the 9955 and tax scheme tests, and cover the install migration with tests for both the move-from-defaults and the keep-configured-format branches.

github-actions · 2026-07-17T07:35:54Z

+
+using Microsoft.Peppol;
+
+enumextension 37450 "PEPPOL 3.0 Format SE" extends "PEPPOL 3.0 Format"


$\textbf{🟠\ High\ Severity\ —\ Interfaces} \quad \color{gray}{\texttt{\small Iteration\ 7}}$

This app adds new values to the persisted enum "PEPPOL 3.0 Format" and writes them into "PEPPOL 3.0 Setup", but that enum has no "UnknownValueImplementation".

If the SE app is later uninstalled, ordinals 37450/37451 can remain in setup, and later assignments such as "PEPPOL30Validation := PeppolSetup."PEPPOL 3.0 Sales Format";" can resolve an unknown enum value to an interface and fail with a technical runtime error instead of controlled handling.

Knowledge:

microsoft/knowledge/interfaces/handle-unknown-enum-ordinals-with-unknownvalueimplementation.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

Same finding as iteration 6 on PEPPOL30SESubscribers.Codeunit.al, answered in that thread: UnknownValueImplementation can only be declared on the base enum, not on an enum extension, so it is not something an SE-scoped app can add. The persisted DE, BE, NO and NA format values carry the same exposure today, which is why this seems best addressed centrally on "PEPPOL 3.0 Format" for all country apps at once. The offer to file a follow-up issue for that still stands, @Groenbech96.

github-actions · 2026-07-17T07:35:55Z

+    InherentEntitlements = X;
+    InherentPermissions = X;
+
+    var


$\textbf{🟠\ High\ Severity\ —\ Interfaces} \quad \color{gray}{\texttt{\small Iteration\ 7}}$

"StandardProvider" is hard-wired as "Codeunit "PEPPOL30"" even though the collaborator already sits behind the "PEPPOL Party Info Provider" interface.

That concrete dependency prevents this wrapper from accepting an injected interface implementation or test double for the delegated calls. Depend on an "Interface "PEPPOL Party Info Provider"" variable and inject "Codeunit "PEPPOL30"" in production instead of calling a concrete codeunit field directly.

Knowledge:

microsoft/knowledge/interfaces/assign-codeunit-to-interface-for-testability.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

If I am not mistaken this one does not apply here: this codeunit is itself the "PEPPOL Party Info Provider" implementation that the new enum values bind, so it is instantiated through enum dispatch and no caller could inject an alternative into it. The StandardProvider member is the fixed W1 base implementation being wrapped, not a swappable collaborator, and the shipped DE localization (codeunit 37403 "PEPPOL30 DE Party Info") declares the exact same member, which is the pattern this app was asked to follow. Happy to adjust if the maintainers prefer otherwise.

Franco111000 requested a review from a team as a code owner June 17, 2026 09:59

github-actions Bot added AL: Apps (W1) Add-on apps for W1 From Fork Pull request is coming from a fork needs-approval Workflow runs require maintainer approval to start labels Jun 17, 2026

github-actions Bot reviewed Jun 18, 2026

View reviewed changes

Comment thread src/Apps/W1/PEPPOL/App/src/Common/PEPPOL30Impl.Codeunit.al Outdated

github-actions Bot reviewed Jun 18, 2026

View reviewed changes

Comment thread src/Apps/W1/PEPPOL/App/src/Common/PEPPOL30Impl.Codeunit.al Outdated

github-actions Bot removed the needs-approval Workflow runs require maintainer approval to start label Jun 18, 2026

JesperSchulz added the Finance GitHub request for Finance area label Jun 18, 2026

Franco111000 added 2 commits June 22, 2026 12:03

Merge remote-tracking branch 'upstream/main' into fix/7723-se-peppol-…

46a9115

…endpoint-orgno

[PEPPOL] Start the SE org-number if on its own line (AA0018)

b4b5c76

The new Swedish organisation-number branches used else-if, which AA0018 rejects. Split them so the if starts its own line, and document the keep-only-digits extraction in GetSwedishOrgNo.

github-actions Bot added the needs-approval Workflow runs require maintainer approval to start label Jun 22, 2026

github-actions Bot removed the needs-approval Workflow runs require maintainer approval to start label Jun 29, 2026

AndersLarsenMicrosoft added Integration GitHub request for Integration area and removed Finance GitHub request for Finance area labels Jul 1, 2026

github-actions Bot added the needs-approval Workflow runs require maintainer approval to start label Jul 2, 2026

JesperSchulz self-assigned this Jul 7, 2026

JesperSchulz added the Linked Issue is linked to a Azure Boards work item label Jul 7, 2026

github-actions Bot removed the needs-approval Workflow runs require maintainer approval to start label Jul 7, 2026

github-actions Bot added this to the Version 29.0 milestone Jul 7, 2026

Groenbech96 requested changes Jul 9, 2026

View reviewed changes

Franco111000 added 3 commits July 9, 2026 11:19

[PEPPOL] Revert W1 changes in favor of a Swedish localization app

1f3dcfa

Merge remote-tracking branch 'upstream/main' into fix/7723-se-peppol-…

2983ba4

…endpoint-orgno

Franco111000 requested a review from a team as a code owner July 9, 2026 09:59

JesperSchulz added the Linked Issue is linked to a Azure Boards work item label Jul 14, 2026

Groenbech96 previously approved these changes Jul 14, 2026

View reviewed changes

JesperSchulz previously approved these changes Jul 14, 2026

View reviewed changes

JesperSchulz enabled auto-merge July 14, 2026 07:55

gggdttt previously approved these changes Jul 14, 2026

View reviewed changes

aholstrup1 reviewed Jul 15, 2026

View reviewed changes

Comment thread build/projects.json Outdated

Update build/projects.json

1c20d08

Co-authored-by: Alexander Holstrup <117829001+aholstrup1@users.noreply.github.com>

Groenbech96 dismissed stale reviews from gggdttt, JesperSchulz, and themself via 1c20d08 July 15, 2026 07:31

auto-merge was automatically disabled July 15, 2026 07:31
Head branch was pushed to by a user without write access

Revert "Update build/projects.json"

ce37b34

This reverts commit 1c20d08.

github-actions Bot added needs-approval Workflow runs require maintainer approval to start and removed needs-approval Workflow runs require maintainer approval to start labels Jul 16, 2026

github-actions Bot reviewed Jul 16, 2026

View reviewed changes

github-actions Bot added the needs-approval Workflow runs require maintainer approval to start label Jul 16, 2026

github-actions Bot reviewed Jul 17, 2026

View reviewed changes

github-actions Bot removed the needs-approval Workflow runs require maintainer approval to start label Jul 17, 2026

Use the repository ruleset paths for the PEPPOL SE Tests project

2ef74bb

github-actions Bot added needs-approval Workflow runs require maintainer approval to start and removed needs-approval Workflow runs require maintainer approval to start labels Jul 18, 2026

		[Test]
		procedure ExportXml_PEPPOL_BIS3_SalesInvoice_SEOrgNo()

	Assert.AreNotEqual(GetExpectedSEOrgNo(), SupplierEndpointID, 'VAT must not be stripped to the organisation number when the scheme is 9955.');
	Assert.AreEqual(GetSETestVATRegNo(), SupplierEndpointID, 'EndpointID must keep the full Swedish VAT under scheme 9955.');

	Assert.AreNotEqual(GetExpectedSEOrgNo(), CompanyID, 'PartyTaxScheme CompanyID must not be the stripped organisation number.');
	Assert.AreEqual(GetSETestVATRegNo(), CompanyID, 'PartyTaxScheme CompanyID must retain the full Swedish VAT.');


		using Microsoft.Peppol;

		enumextension 37450 "PEPPOL 3.0 Format SE" extends "PEPPOL 3.0 Format"

Uh oh!

Conversation

Franco111000 commented Jun 17, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What and why

Linked work

How I validated

Risk and compatibility

Uh oh!

Uh oh!

Uh oh!

Franco111000 commented Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Copilot PR Review

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

Uh oh!

Franco111000 commented Jul 2, 2026

Uh oh!

Groenbech96 commented Jul 9, 2026

Uh oh!

Groenbech96 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions Bot Jul 16, 2026

Choose a reason for hiding this comment

When GetSwedishOrgNo receives a value with fewer than 10 digits, it silently returns the original VAT registration number.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jul 16, 2026

Choose a reason for hiding this comment

The OnAfterInsert subscriber ignores its RunTrigger parameter and still rewrites PEPPOL 3.0 Setup.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jul 16, 2026

Choose a reason for hiding this comment

The new SE formats are persisted into "PEPPOL 3.0 Setup", but "PEPPOL 3.0 Format" still relies on DefaultImplementation only.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jul 16, 2026

Choose a reason for hiding this comment

ExportXml_PEPPOL_BIS3_SalesInvoice_SEOrgNo posts a sales invoice through LibrarySales.PostSalesDocument but has no [TransactionModel(TransactionModel::AutoCommit)] attribute.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jul 16, 2026

Choose a reason for hiding this comment

GetAccountingSupplierPartyInfo_VATScheme9955_SE only checks that EndpointID is not the stripped organisation number and still contains the VAT digits.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jul 16, 2026

Choose a reason for hiding this comment

GetAccountingSupplierPartyTaxScheme_VATRegNo_SE uses a negative check plus substring match for CompanyID, so values that merely contain the VAT digits still pass.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jul 16, 2026

Choose a reason for hiding this comment

PEPPOL30SetupDefaultsToSEFormats only covers creating a missing PEPPOL 3.0 Setup record.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jul 16, 2026

Choose a reason for hiding this comment

OnInstallAppPerCompany always calls SetSEFormatsOnExistingSetup() without first checking AppInfo.DataVersion().

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Jul 17, 2026

Choose a reason for hiding this comment

This app adds new values to the persisted enum "PEPPOL 3.0 Format" and writes them into "PEPPOL 3.0 Setup", but that enum has no "UnknownValueImplementation".

Uh oh!

Choose a reason for hiding this comment

Franco111000 commented Jun 17, 2026 •

edited by github-actions Bot

Loading

Franco111000 commented Jun 22, 2026 •

edited

Loading

github-actions Bot commented Jun 29, 2026 •

edited

Loading