[Bug]: VAT Registration No. should not be mandatory for Public Sector customers in XRechnung/ZUGFeRD

[miljance]

Describe the issue

In the German localization of Business Central, when using XRechnung or ZUGFeRD via the E-Document framework, the system currently enforces that a Customer must have either a GLN or a VAT Registration No. before an invoice can be posted/exported.

While this is correct for B2B transactions, it creates a blocking issue for transactions with the German Public Sector (B2G). Public sector entities in Germany often do not have a VAT Registration Number because they are not "taxable businesses". Instead, they are uniquely identified by their E-Invoice Routing No. (Leitweg-ID). Currently, even if a valid Leitweg-ID is provided, the system fails the validation if the VAT Registration No. is missing.

Expected behavior

The validation logic should be updated to recognize the E-Invoice Routing No. (Leitweg-ID) as a valid identification for the buyer in the context of XRechnung and ZUGFeRD.

If the customer belongs to the public sector (identified by the presence of a Leitweg-ID/Routing No.), the requirement for VAT Registration No. or GLN should be bypassed, allowing the invoice to be posted and exported successfully.

Steps to reproduce

1. Environment: Use a Business Central environment with German localization (DE).

2. E-Document Setup:

   • Enable E-Document Service for ZUGFeRD and XRechnung.
   • Set Buyer Reference Mandatory = Yes.
   • Set Buyer Reference = Customer Reference.

3. Workflow & Profiles:

   • Configure a Workflow for the selected e-document format.
   • Configure and assign a Document Sending Profile (with the e-document format) as default for a test customer.

4. Customer Configuration:

   • Select a Customer that does not have a VAT Registration No..
   • Ensure the Customer has a valid E-Invoice Routing No. (Leitweg-ID).

5. Transaction:

   • Create a new Sales Invoice for this Customer.
   • Add a Sales Line with any value.
   • Attempt to Post the Sales Invoice.
   • Observe the error: You must specify either GLN or VAT Registration No. for Customer XXXXX

Additional context

No response

I will provide a fix for a bug

• I will provide a fix for a bug

[duichwer]

I guess that the German e document app now needs to implement the Peppol Validation interface, since there aren't any events to extend the gln vat registration no. Check.
https://github.com/microsoft/BCApps/blob/main/src/Apps/W1/PEPPOL/App/src/Sales/PEPPOL30SalesValidationImpl.Codeunit.al

[miljance]

I hope not. There is actually already an IntegrationEvent that makes possible to skip check for VAT Registration No. and GL:

At least this is how our teams implemented it inside of PTE for the moment.

[github-actions]

This issue has been approved for contribution ✅ Thanks for contributing.

[duichwer]

The event exists in the current peppol validation logic that is part of the baseapp:
https://github.com/microsoft/BusinessCentralApps/blob/main/App/Layers/W1/BaseApp/Sales/Peppol/PEPPOLValidation.Codeunit.al

The new peppol logic is missing such an event.
https://github.com/microsoft/BCApps/blob/main/src/Apps/W1/PEPPOL/App/src/Sales/PEPPOL30SalesValidationImpl.Codeunit.al

Currently the EDocPeppol Validation uses the "Old" peppol validation codeunit
https://github.com/microsoft/BCApps/blob/main/src/Apps/W1/EDocument/App/src/Format/EDocPEPPOLBIS30.Codeunit.al

therefore you're right and one could subscribe to the IsHandled event.

I don't know what the plans are to move to the new app for peppol validation.

[miljance]

At the moment the Codeunit "PEPPOL Validation" is called from all PEPPOL implementations, including "EDoc PEPPOL BIS 3.0 DE" making it centralized. I would therefore not call it "old" even though it is in the Base App. If Microsoft decides to extract PEPPOL it would still need to support the same ideally "non-breaking" scope of functionalities for all dependant implementations of PEPPOL.