[PEPPOL] Use Swedish organisation number for EndpointID under scheme 0007

[Franco111000]

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). Today only Denmark has country-specific endpoint handling (UseVATSchemeID), so Sweden falls through unformatted and the document is rejected.

This change extracts the Swedish organisation number for parties whose Country/Region VAT Scheme is 0007, in the four procedures that build the supplier and customer EndpointID and PartyLegalEntity/CompanyID. The cac:PartyTaxScheme/cbc:CompanyID (the BT-31/BT-48 VAT identifier) is deliberately left as the full VAT, which is exactly the half that the manual "trim to 10 chars" workaround described in the issue broke.

Why gate on the scheme (0007) rather than the country (ISO = 'SE'): the emitted schemeID already comes from GetVATScheme(country), so gating the value on the same 0007 keeps the value and the scheme consistent by construction. A Swedish company legitimately registered under EAS 9955 (SE:VAT) then keeps its full VAT under schemeID="9955", which an ISO-based gate would have stripped incorrectly.

The PartyLegalEntity/cbc:CompanyID schemeID stays empty for SE, as it already does for every non-DK country. PEPPOL-COMMON-R049 only applies when schemeID="0007" is present, so the bare 10-digit organisation number there is valid and matches the expected output shown in the issue.

Note: the fix takes effect when the SE Country/Region VAT Scheme is set to 0007, which is already required for any Swedish tenant sending PEPPOL (the issue's sample XML shows schemeID="0007").

Linked work

Fixes #7723

How I validated

• Unit tests: 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
• End-to-end test: a PEPPOL BIS 3.0 sales invoice export asserts both endpoints
• Relied on PR CI for compilation and the full test run (this repo builds via AL-Go)

Risk and compatibility

• Denmark and every country whose VAT Scheme is not 0007 are behaviourally unchanged: the new branch is only reached for 0007, and UseVATSchemeID still handles DK in the first branch.
• Only the SE EndpointID and PartyLegalEntity company id change; the VAT identifier in PartyTaxScheme is preserved.
• No schema, table, or API changes.

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Nested DelChr digit-extraction is non-obvious

The double-nested DelChr(x, '=', DelChr(x, '=', '0123456789')) pattern — where the inner call extracts the non-digit mask and the outer call removes it — relies on an implicit BC behaviour that is easy to misread, and any future maintainer touching this line may accidentally invert the arguments.

Recommendation:

• Extract the pattern into a clearly named helper, or document it with an inline comment explaining the two-step inversion so its correctness is immediately obvious.

Suggested change

	DigitsOnly := DelChr(VATRegistrationNo, '=', DelChr(VATRegistrationNo, '=', '0123456789'));
	// Inner DelChr removes all digits, leaving only non-digit chars as the mask.
	// Outer DelChr removes those non-digit chars from the original, leaving only digits.
	DigitsOnly := DelChr(VATRegistrationNo, '=', DelChr(VATRegistrationNo, '=', '0123456789'));

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

[Franco111000]

Good call, thanks. Added a comment in b4b5c7604 explaining the two-step DelChr: the inner call builds the non-digit mask, the outer call removes it, leaving only the digits.

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Silent fallback on malformed Swedish org number

When GetSwedishOrgNo cannot extract 10 or more digits from the VAT registration number, it silently returns the raw input unchanged. This could produce an invalid PEPPOL XML document (wrong-length or non-numeric identifier under scheme 0007) with no error surfaced to the user.

Recommendation:

• Raise an error or at minimum log a warning when fewer than 10 digits are found, so the operator is alerted to fix the VAT registration number rather than sending a silently malformed document.

Suggested change

	exit(VATRegistrationNo);
	local procedure GetSwedishOrgNo(VATRegistrationNo: Text): Text
	var
	DigitsOnly: Text;
	begin
	DigitsOnly := DelChr(VATRegistrationNo, '=', DelChr(VATRegistrationNo, '=', '0123456789'));
	if StrLen(DigitsOnly) >= 10 then
	exit(CopyStr(DigitsOnly, 1, 10));
	Error('Swedish organisation number could not be derived from VAT Registration No. ''%1'': expected at least 10 digits.', VATRegistrationNo);
	end;

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

[Franco111000]

Thanks. This is deliberate. GetSwedishOrgNo is a low-level formatter called for both the supplier and the customer endpoints during export, mirroring the existing FormatVATRegistrationNo helpers, which also format rather than raise. A value with fewer than 10 digits can only occur when a party is configured with scheme 0007 but a malformed VAT, which already produced an invalid document before this change, so returning the input unchanged keeps behaviour no worse than today and lets the receiver's PEPPOL-COMMON-R049 schematron report the precise error. Hard-erroring here would also block a sender from exporting when it is the customer's registration that is malformed, which they may not control. Happy to add an explicit TestField-style guard further upstream (posting/setup) if you would prefer fail-fast.

[Franco111000]

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.