[DE] Support registration numbers in E-Documents by djukicmilica · Pull Request #10349 · microsoft/BCApps

Milica Đukić (djukicmilica) · 2026-08-18T11:12:17Z

Summary

add Registration No. as the final fallback when matching imported E-Document vendors
support German FC tax identifiers in XRechnung, ZUGFeRD, and PEPPOL exports
validate imported receiving-company Registration No. against Company Information
add focused coverage for Registration No. vendor matching and XRechnung/ZUGFeRD exports

Validation

AL editor diagnostics report no errors in all 12 changed files
git diff --check passes
package build was not available because the VS Code workspace root is a generic multi-project container and does not resolve an active app.json

…XRechnung/ZUGFeRD

github-actions · 2026-08-18T11:28:25Z

    /// <param name="PhoneNo">Vendor's Phone number.</param>
    /// <returns>Vendor number if exists or empty string.</returns>
    procedure FindVendorByPhoneNo(PhoneNo: Text): Code[20]
+


$\textbf{🟡\ Medium\ Severity\ —\ Agent}$

The new OnBeforeValidateReceivingCompanyInfo integration event (with its [IntegrationEvent(false, false)] attribute, header, and empty begin...end; body) is inserted directly between the procedure FindVendorByPhoneNo(PhoneNo: Text): Code[20] header and its own var/begin section. A procedure header must be followed immediately by that procedure's own optional var section and begin...end — nesting a second, complete procedure declaration in between is invalid AL syntax and will fail to compile. Move the new event procedure to its own location (e.g. immediately after ValidateReceivingCompanyInfo, or at the end of the codeunit near other [IntegrationEvent] declarations) so FindVendorByPhoneNo's header is directly followed by its var/begin block.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

procedure FindVendorByPhoneNo(PhoneNo: Text): Code[20] var Vendor: Record Vendor; RecordMatchMgt: Codeunit "Record Match Mgt."; PhoneNoNearness: Integer; begin

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

github-actions · 2026-08-18T11:28:27Z


-        if CompanyInfo.GLN + CompanyInfo."VAT Registration No." = '' then
-            Error(MissingCompInfGLNOrVATRegNoErr, CompanyInfo.TableCaption());
+        if CompanyInfo.GLN + CompanyInfo."VAT Registration No." + CompanyInfo."Registration No." = '' then


$\textbf{🟠\ High\ Severity\ —\ Error\ Handling}$

This validation raises a plain Error when Company Information has no GLN, VAT Registration No., or Registration No., but the user can correct that setup directly on the related record. Use ErrorInfo with a Show-it navigation action to Company Information instead of a dead-end dialog.

Knowledge:

microsoft/knowledge/error-handling/prefer-errorinfo-for-actionable-errors.md

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

github-actions · 2026-08-18T11:28:29Z

        CompanyInformation: Record "Company Information";
+        IsHandled: Boolean;
    begin
+        OnBeforeValidateReceivingCompanyInfo(EDocument, IsHandled);


$\textbf{🟠\ High\ Severity\ —\ Events}$

ValidateReceivingCompanyInfo raises OnBeforeValidateReceivingCompanyInfo(…, IsHandled) without first resetting IsHandled := false;. That matches the IsHandled anti-pattern: the publisher becomes non-deterministic if this variable is ever reused, and subscribers can inherit a stale handled state. Reset IsHandled immediately before publishing.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

IsHandled := false; OnBeforeValidateReceivingCompanyInfo(EDocument, IsHandled); if IsHandled then exit;

Knowledge:

microsoft/knowledge/events/initialize-ishandled-to-false-before-publishing.md

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

github-actions · 2026-08-18T11:28:30Z

+        if RegistrationNo = '' then
+            exit('');
+
+        Vendor.SetRange("Registration No.", RegistrationNo);


$\textbf{🟡\ Medium\ Severity\ —\ Performance}$

FindVendorByRegistrationNo filters Vendor and reads only "No." from the first match, but it does not call SetLoadFields before FindFirst. On the wide Vendor table this still materializes the full row for a lookup that only needs the primary key.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

Vendor.SetLoadFields("No."); Vendor.SetRange("Registration No.", RegistrationNo); if Vendor.FindFirst() then

Knowledge:

microsoft/knowledge/performance/use-setloadfields-for-partial-records.md

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

github-actions · 2026-08-18T11:28:32Z

+    var
+        CompanyInformation: Record "Company Information";
+        EDocumentErrorHelper: Codeunit "E-Document Error Helper";
+        InvalidCompanyRegistrationNoErr: Label 'The receiving company registration number %1 does not match Company Information.', Comment = '%1 = Registration No.';


$\textbf{🟠\ High\ Severity\ —\ Privacy}$

This error message interpolates the receiving company registration number into the text passed to EDocumentErrorHelper.LogErrorMessage. That helper forwards Message as a FeatureTelemetry custom dimension and also uses it as the FeatureTelemetry.LogError ErrorText fallback, so the registration number is sent to telemetry verbatim.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

InvalidCompanyRegistrationNoErr: Label 'The receiving company registration number does not match Company Information.'; begin if EDocument."Receiving Company Reg. No. DE" = '' then exit; IsHandled := true; CompanyInformation.Get(); if CompanyInformation."Registration No." <> EDocument."Receiving Company Reg. No. DE" then EDocumentErrorHelper.LogErrorMessage( EDocument, CompanyInformation, CompanyInformation.FieldNo("Registration No."), InvalidCompanyRegistrationNoErr);

Knowledge:

microsoft/knowledge/privacy/featuretelemetry-customdimensions-no-pii.md

microsoft/knowledge/privacy/featuretelemetry-logerror-implicit-errortext.md

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

github-actions · 2026-08-18T11:28:34Z

+        field(13916; "Receiving Company Reg. No. DE"; Text[20])
+        {
+            Caption = 'Receiving Company Registration No.';
+            DataClassification = CustomerContent;


$\textbf{🟡\ Medium\ Severity\ —\ Privacy}$

The new "Receiving Company Reg. No. DE" field stores a company registration number, but privacy guidance classifies organization identifiers such as company registration numbers as OrganizationIdentifiableInformation rather than CustomerContent.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

DataClassification = OrganizationIdentifiableInformation;

Knowledge:

microsoft/knowledge/privacy/data-classification-required-on-pii-fields.md

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

github-actions · 2026-08-18T11:28:36Z

        CompanyInformation: Record "Company Information";
+        IsHandled: Boolean;
    begin
+        OnBeforeValidateReceivingCompanyInfo(EDocument, IsHandled);


$\textbf{🟠\ High\ Severity\ —\ Security}$

OnBeforeValidateReceivingCompanyInfo exposes a mutable var IsHandled gate, and ValidateReceivingCompanyInfo exits when a subscriber flips it to true. That makes the receiving-company validation advisory: any subscriber on the tenant can bypass the publisher's check instead of only tightening it. Keep the decision inside the publisher and expose a post-check or tighten-only hook instead.

Knowledge:

microsoft/knowledge/security/integrationevent-var-parameter-bypasses-security-guards.md

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

github-actions · 2026-08-18T11:28:38Z

+    var
+        CompanyInformation: Record "Company Information";
+        EDocumentErrorHelper: Codeunit "E-Document Error Helper";
+        InvalidCompanyRegistrationNoErr: Label 'The receiving company registration number %1 does not match Company Information.', Comment = '%1 = Registration No.';


$\textbf{🟡\ Medium\ Severity\ —\ Style}$

InvalidCompanyRegistrationNoErr is declared inside the procedure-local var block. Per the style guidance, Labels should live in the codeunit's top-level var section so XLIFF extraction and translation review do not depend on fragile procedure-scope behavior.

Knowledge:

microsoft/knowledge/style/labels-declared-at-object-scope.md

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

github-actions · 2026-08-18T11:28:39Z

+    var
+        SalesInvoiceHeader: Record "Sales Invoice Header";
+        TempXMLBuffer: Record "XML Buffer" temporary;
+        SupplierTaxSchemeTok: Label '/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme', Locked = true;


$\textbf{🟡\ Medium\ Severity\ —\ Style}$

SupplierTaxSchemeTok is declared inside a test procedure's local var block. The style rule requires Labels at object scope so the token remains stable for XLIFF extraction and object-level review instead of being hidden inside one procedure.

Knowledge:

microsoft/knowledge/style/labels-declared-at-object-scope.md

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

github-actions · 2026-08-18T11:28:41Z

+    var
+        SalesInvoiceHeader: Record "Sales Invoice Header";
+        TempXMLBuffer: Record "XML Buffer" temporary;
+        SellerTaxRegistrationTok: Label '/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID', Locked = true;


$\textbf{🟡\ Medium\ Severity\ —\ Style}$

SellerTaxRegistrationTok is declared inside a test procedure's local var block. Even in test code, procedure-scoped Labels are fragile for localization tooling; move the token Label to the codeunit's top-level var section.

Knowledge:

microsoft/knowledge/style/labels-declared-at-object-scope.md

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

github-actions · 2026-08-18T11:28:43Z


+    [Test]
+    procedure FindVendorByRegistrationNo()
+    var


$\textbf{🟠\ High\ Severity\ —\ Testing}$

FindVendorByRegistrationNo hand-rolls a Vendor with Init/manual "No." assignment/Insert instead of creating it through a test Library codeunit. That bypasses number-series and mandatory-field setup, so the fixture can break as the vendor schema evolves rather than validating the registration-number lookup behavior.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

var Vendor: Record Vendor; EDocumentImportHelper: Codeunit "E-Document Import Helper"; LibraryPurchase: Codeunit "Library - Purchase"; LibraryUtility: Codeunit "Library - Utility"; RegistrationNo: Text[20]; begin // [SCENARIO 646793] A vendor can be resolved by Registration No. when other identifiers are unavailable. RegistrationNo := CopyStr(LibraryUtility.GenerateGUID(), 1, MaxStrLen(RegistrationNo)); LibraryPurchase.CreateVendor(Vendor); Vendor.Validate("Registration No.", RegistrationNo); Vendor.Modify(true);

Knowledge:

microsoft/knowledge/testing/use-library-codeunits-for-test-fixtures.md

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

…om/djukicmilica/BCApps into bug/646793-edoc-de-registration-no

github-actions · 2026-08-18T11:54:57Z

+        if EDocument."Receiving Company Reg. No. DE" = '' then
+            exit;
+
+        IsHandled := true;


$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

ValidateReceivingCompanyInfoByRegistrationNo marks the event handled and then calls CompanyInformation.Get() unconditionally. If the Company Information record is missing, importing a document with "Receiving Company Reg. No. DE" now aborts with an unhandled record-not-found error instead of falling back to the standard validator or logging a setup problem. Guard Get() and surface missing setup explicitly before setting IsHandled.

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

github-actions · 2026-08-18T11:54:59Z

        EDocument."Receiving Company Address" := CopyStr(GetNodeByPath(TempXMLBuffer, '/' + DocumentType + 'rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:PostalTradeAddress/ram:LineOne'), 1, MaxStrLen(EDocument."Receiving Company Address"));
-        EDocument."Receiving Company VAT Reg. No." := CopyStr(GetNodeByPath(TempXMLBuffer, '/' + DocumentType + '/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:SpecifiedTaxRegistration'), 1, MaxStrLen(EDocument."Receiving Company VAT Reg. No."));
+        TaxRegistrationPath := '/' + DocumentType + '/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:SpecifiedTaxRegistration/ram:ID';
+        case GetAttributeByPath(TempXMLBuffer, TaxRegistrationPath + '/@schemeID') of


$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

ParseBuyerTradeParty handles only scheme IDs 'VA' and 'FC' and has no else/guard branch for any other or malformed value. When an incoming ZUGFeRD document carries an unexpected tax-registration scheme, the import silently drops the identifier and continues with blank receiving-company identifiers, which can lead to weaker matching and unclear downstream validation errors.

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

github-actions · 2026-08-18T11:55:00Z

+        if CompanyID <> '' then
+            exit;
+
+        CompanyInformation.SetLoadFields("Registration No.");


$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

The new registration-number fallback in GetAccountingSupplierPartyTaxScheme calls CompanyInformation.Get() unconditionally after the standard provider leaves CompanyID blank. In a company without a Company Information record, PEPPOL export now fails with a raw record-not-found error instead of a clear setup/validation failure.

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

github-actions · 2026-08-18T11:55:01Z

+        if PartyLegalEntityCompanyID <> '' then
+            exit;
+
+        CompanyInformation.SetLoadFields("Registration No.");


$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

SetRegistrationNoAsLegalEntityFallback also assumes Company Information always exists and calls Get() without a guard. If that singleton record is absent, the new legal-entity fallback throws an unhandled record-not-found error while composing PEPPOL party data.

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

github-actions · 2026-08-18T11:55:03Z

    /// <param name="PhoneNo">Vendor's Phone number.</param>
    /// <returns>Vendor number if exists or empty string.</returns>
    procedure FindVendorByPhoneNo(PhoneNo: Text): Code[20]
+


$\textbf{🟡\ Medium\ Severity\ —\ Events}$

The new [IntegrationEvent(false, false)] publisher OnBeforeValidateReceivingCompanyInfo is physically inserted between the FindVendorByPhoneNo procedure signature (line 572) and that same procedure's var/begin/end body (lines 579-597) — i.e. a second procedure's full declaration (signature + begin/end) sits inside what should be one contiguous FindVendorByPhoneNo member. This is not merely a style nit: as written, FindVendorByPhoneNo's var section and body are separated from its own header by an entire nested procedure, which is not valid top-level AL member layout and blocks compilation of this codeunit. Move OnBeforeValidateReceivingCompanyInfo to its own standalone position in the codeunit, after a complete, uninterrupted FindVendorByPhoneNo procedure.

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

github-actions · 2026-08-18T11:55:05Z

+        IsHandled := true;
+        CompanyInformation.Get();
+        if CompanyInformation."Registration No." <> EDocument."Receiving Company Reg. No. DE" then
+            EDocumentErrorHelper.LogErrorMessage(


$\textbf{🟠\ High\ Severity\ —\ Privacy}$

The error message raised in ValidateReceivingCompanyInfoByRegistrationNo embeds the incoming receiving-company registration number and is passed to EDocumentErrorHelper.LogErrorMessage. That helper forwards Message to FeatureTelemetry.LogError, where it becomes telemetry payload (ErrorText/alErrorText), so the registration number is emitted to telemetry as system metadata rather than kept purely in the user-facing error.

Knowledge:

microsoft/knowledge/privacy/featuretelemetry-logerror-implicit-errortext.md

microsoft/knowledge/privacy/featuretelemetry-customdimensions-no-pii.md

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

github-actions · 2026-08-18T11:55:06Z

+    var
+        SalesInvoiceHeader: Record "Sales Invoice Header";
+        TempXMLBuffer: Record "XML Buffer" temporary;
+        SupplierTaxSchemeTok: Label '/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme', Locked = true;


$\textbf{🟡\ Medium\ Severity\ —\ Style}$

SupplierTaxSchemeTok is introduced as a procedure-local Label inside ExportPostedSalesInvoiceInXRechnungFormatVerifySupplierRegistrationNo. Per the referenced guidance, Labels should be declared at object scope rather than inside a procedure var block.

Knowledge:

microsoft/knowledge/style/labels-declared-at-object-scope.md

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

github-actions · 2026-08-18T11:55:08Z

+    begin
+        // [SCENARIO 646793] A vendor can be resolved by Registration No. when other identifiers are unavailable.
+        RegistrationNo := CopyStr(LibraryUtility.GenerateGUID(), 1, MaxStrLen(RegistrationNo));
+        Vendor.Init();


$\textbf{🟠\ High\ Severity\ —\ Testing}$

The new FindVendorByRegistrationNo test hand-rolls a Vendor with Init/Insert and an invented primary key. BCQuality testing guidance requires using the maintained test Library codeunits for fixtures so the record stays valid as table requirements evolve. Create the vendor through a library helper, then set the registration number needed by the scenario.

Knowledge:

microsoft/knowledge/testing/use-library-codeunits-for-test-fixtures.md

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

github-actions · 2026-08-18T11:55:09Z

+        ShipToAddress.SetLoadFields(GLN);
+        if (ShipToCode <> '') and ShipToAddress.Get(CustomerNo, ShipToCode) then
+            DeliveryGLN := ShipToAddress.GLN;
+        if DeliveryGLN = '' then


$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The new ZUGFeRD delivery branch falls back to the customer GLN when the ship-to GLN is blank, but the added ZUGFeRD tests only cover the ship-to-present and GLN-disabled cases. Add a case with a blank ship-to GLN and assert ShipToTradeParty/GlobalID falls back to the customer GLN so this new branch is exercised.

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

github-actions · 2026-08-18T11:55:11Z

+
+using Microsoft.Foundation.Company;
+
+codeunit 13916 "E-Doc. Import Subscribers DE"


$\textbf{🟡\ Medium\ Severity\ —\ Upgrade}$

The PR introduces codeunit 13916 "E-Doc. Import Subscribers DE" (src/Apps/DE/EDocumentDE/app/src/EDocumentImportSubscribersDE.Codeunit.al), but the same EDocumentDE app already defines codeunit 13916 "Export XRechnung Document" (src/Apps/DE/EDocumentDE/app/src/XRechnung/ExportXRechnungDocument.Codeunit.al). Two codeunits in the same app cannot share an object ID; this blocks compilation/publishing of the app as-is. Assign the new subscriber codeunit an unused ID in the app's reserved range.

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

github-actions · 2026-08-18T11:57:56Z

    /// <param name="PhoneNo">Vendor's Phone number.</param>
    /// <returns>Vendor number if exists or empty string.</returns>
    procedure FindVendorByPhoneNo(PhoneNo: Text): Code[20]
+


$\textbf{🟡\ Medium\ Severity\ —\ Style}$

Two leaves (al-style-review and al-events-review) independently flagged the same defect, merged here: the new OnBeforeValidateReceivingCompanyInfo integration-event publisher (with its [IntegrationEvent(false, false)] attribute) is inserted between FindVendorByPhoneNo's procedure signature and its own var/begin block. This nests one full procedure declaration inside another and leaves the codeunit syntactically malformed — the affected object will not compile as written. Real-world impact is build-breaking (would normally be blocker/major), but per the DO contract this is capped at minor because it has no direct BCQuality citation; it should be promoted to a knowledge-backed rule and treated as blocking before merge. Move the event publisher out from between FindVendorByPhoneNo's header and its var section so the phone-number procedure's var/begin/end stays contiguous.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

procedure FindVendorByPhoneNo(PhoneNo: Text): Code[20] var Vendor: Record Vendor; RecordMatchMgt: Codeunit "Record Match Mgt."; PhoneNoNearness: Integer; begin if PhoneNo = '' then exit(''); PhoneNo := DelChr(PhoneNo, '=', DelChr(PhoneNo, '=', '0123456789')); Vendor.SetCurrentKey(Blocked); Vendor.SetLoadFields("Phone No."); if Vendor.FindSet() then repeat PhoneNoNearness := RecordMatchMgt.CalculateStringNearness(PhoneNo, Vendor."Phone No.", MatchThreshold(), NormalizingFactor()); if PhoneNoNearness >= RequiredNearness() then exit(Vendor."No."); until Vendor.Next() = 0; end; [IntegrationEvent(false, false)] local procedure OnBeforeValidateReceivingCompanyInfo(EDocument: Record "E-Document"; var IsHandled: Boolean) begin end;

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

ventselartur · 2026-08-18T12:08:37Z

+        LibraryUtility: Codeunit "Library - Utility";
+        RegistrationNo: Text[20];
+    begin
+        // [SCENARIO 646793] A vendor can be resolved by Registration No. when other identifiers are unavailable.


github-actions · 2026-08-18T13:20:26Z

            until Vendor.Next() = 0;
    end;

+    [IntegrationEvent(false, false)]


$\textbf{🟠\ High\ Severity\ —\ Events}$

The new integration event OnGetReceivingCompanyRegistrationNo fires at the start of ValidateReceivingCompanyInfo, but its name does not encode either the host routine or the firing position. Rename it to follow the OnBefore.../OnAfter... convention (e.g. OnValidateReceivingCompanyInfoOnBeforeCheckRegistrationNo or similar) so subscribers can tell when it runs without reading the publisher.

Knowledge:

microsoft/knowledge/events/name-events-by-publisher-position.md

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

github-actions · 2026-08-18T14:10:13Z

+        OnGetReceivingCompanyRegistrationNo(EDocument, ReceivingCompanyRegistrationNo);
        CompanyInformation.Get();

+        if ReceivingCompanyRegistrationNo <> '' then begin


$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

When ReceivingCompanyRegistrationNo is present, the unconditional exit; stops validation immediately after the registration-number comparison. That means a matching registration number now suppresses the existing GLN/VAT checks, and a mismatch hides any additional identifier errors, so inbound documents can miss or under-report receiving-company validation failures. Continue into the existing identifier-validation path instead of exiting unconditionally.

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

github-actions · 2026-08-18T14:10:16Z

+            exit('');
+
+        Vendor.SetLoadFields("No.");
+        Vendor.SetRange("Registration Number", RegistrationNo);


$\textbf{🟠\ High\ Severity\ —\ Performance}$

The new Registration Number fallback filters Vendor on "Registration Number" and immediately calls FindFirst(), but the W1 Vendor table has no key on that field. That matches this article's anti-pattern: once the GLN/VAT lookups miss, FindFirst() has to read vendors through an unindexed filter instead of an indexed access path, which also scales poorly as vendor volume grows. Add a supporting key for "Registration Number" (for example via a Vendor tableextension) or route this match through an existing keyed lookup before using it in import matching.

Knowledge:

microsoft/knowledge/performance/setcurrentkey-aligns-key-with-filters.md

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

github-actions · 2026-08-18T14:10:18Z

    end;

    procedure GetAccountingSupplierPartyTaxScheme(var CompanyID: Text; var CompanyIDSchemeID: Text; var TaxSchemeID: Text)
+    var


$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

PEPPOL 3.0 DE now falls back to Company Information."Registration No." for supplier tax-scheme/legal-entity data, but the diff does not add a PEPPOL test that exports with blank GLN/VAT and asserts the new FC/legal-entity output. Because these DE-only fallback branches are new behavior, leaving them untested makes it easy to break the Registration No. mapping without any PEPPOL test failing.

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

github-actions · 2026-08-18T14:10:20Z

    procedure ValidateReceivingCompanyInfo(EDocument: Record "E-Document")
    var
        CompanyInformation: Record "Company Information";
+        ReceivingCompanyRegistrationNo: Text[20];


$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The import flow now has a new registration-number path, but the diff only adds an isolated helper test for FindVendor('', '', '', RegistrationNo). There is still no test that imports an FC-identified XRechnung/ZUGFeRD document and verifies that the parsed registration number drives vendor matching and the new receiving-company registration-number validation/subscriber path. Without an end-to-end import test, regressions in the new DE wiring can ship unnoticed.

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

github-actions Bot and others added 7 commits August 18, 2026 10:34

[E-document DE] GLN information generated in PEPPOL also be added to …

15856e6

…XRechnung/ZUGFeRD

Respect customer GLN setup in XRechnung

bfefa58

Fix ZUGFeRD seller email indentation

9a57099

Address GLN export review feedback

9ac2e4e

Optimize GLN lookups and extend coverage

3853089

tests update

d1bfa46

[DE] Support registration numbers in E-Documents

15e0fad

Milica Đukić (djukicmilica) requested review from a team August 18, 2026 11:12

Milica Đukić (djukicmilica) requested a review from a team as a code owner August 18, 2026 11:12

Milica Đukić (djukicmilica) deployed to triage August 18, 2026 11:12 — with GitHub Actions Active

Milica Đukić (djukicmilica) mentioned this pull request Aug 18, 2026

[DE] Support registration numbers in E-Documents djukicmilica/BCApps#1

Closed

github-actions Bot added this to the Version 29.0 milestone Aug 18, 2026

github-actions Bot reviewed Aug 18, 2026

View reviewed changes

fix

8dc7b28

github-actions Bot added 2 commits August 18, 2026 13:41

fix namespaces

7f8ff4f

Merge branch 'bug/646793-edoc-de-registration-no' of https://github.c…

2a2d7bb

…om/djukicmilica/BCApps into bug/646793-edoc-de-registration-no

github-actions Bot reviewed Aug 18, 2026

View reviewed changes

ventselartur reviewed Aug 18, 2026

View reviewed changes

new

0b2f770

github-actions Bot reviewed Aug 18, 2026

View reviewed changes

Fix vendor registration number field references

ef28576

github-actions Bot reviewed Aug 18, 2026

View reviewed changes

Fix remaining E-Document build errors

299ccdc


		using Microsoft.Foundation.Company;

		codeunit 13916 "E-Doc. Import Subscribers DE"

Uh oh!

Conversation

Milica Đukić (djukicmilica) commented Aug 18, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Validation

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

ventselartur Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Aug 18, 2026

Milica Đukić (djukicmilica) commented Aug 18, 2026 •

edited by github-actions Bot

Loading