[E-Document Formats] Fix defects in V2 draft migration for XRechnung, PINT A-NZ and Factura-E

[Groenbech96]

Fixes AB#644279

Summary

Verification of the local e-document formats migrated to the V2 (draft) import pipeline found several defects where the migrated formats deviate from the DK OIOUBL reference implementation. This PR fixes the high-confidence functional defects.

Related migrations: #9426 (PINT A-NZ, Factura-E), #9682 (OIOUBL), #9690 (XRechnung).

Fixes

XRechnung (DE) — EDocumentXRechnungHandler.Codeunit.al

Defect	Impact
ResetDraft was never called from ReadIntoDraft	Re-running Read into Draft appended a second set of purchase lines, because GetNextLineNo keeps incrementing. ResetDraft was dead code.
ResetDraft used GetFromEDocument + Delete(true)	Errors when no draft header exists yet. Now deletes the header/line ranges, matching EDocumentOIOUBLHandler.
Root element case had no else and did not validate the root namespace	Unsupported documents (e.g. CII CrossIndustryInvoice) silently produced an empty draft and returned an uninitialised "E-Doc. Process Draft". Now rejected with an error, matching OIOUBL.

PINT A-NZ (APAC)

Defect	Impact
GetVendorRelatedData declared VendorParticipantId / VendorName / VendorAddress by value (PINTANZImport.Codeunit.al)	The participant-id and name+address vendor-matching fallbacks in TryMatchVendor always received empty strings — dead fallback logic.
Credit notes did not map cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID	"Applies-to Ext. Invoice No." stayed empty, so EDocCreatePurchCrMemo could not apply the credit memo to the original invoice. Core PEPPOL and OIOUBL both map this.

Factura-E (ES)

Defect	Impact
InvoiceHeader/Corrective/InvoiceNumber mapped to "Purchase Order No."	Finish draft treats that field as a vendor order number. Rectificative invoices were never applied to the original invoice. Now mapped to "Applies-to Ext. Invoice No.".

Tests

Added three regression tests to XRechnungStructuredTests.Codeunit.al, mirroring the existing OIOUBL suite:

• TestXRechnungUnsupportedRootElement_IsRejected
• TestXRechnungUnexpectedRootNamespace_IsRejected
• TestXRechnungInvoice_ReadIntoDraftTwice_DoesNotDuplicateLines

Not included (tracked separately)

The following gaps were also identified during verification and are being filed as work items rather than fixed here, since they need schema review and new test fixtures:

• Tax/VAT totals read from derived arithmetic instead of cac:TaxTotal/cbc:TaxAmount (OIOUBL, PINT A-NZ)
• Document- and line-level allowances/charges not mapped (all four formats)
• Embedded attachments (cac:AdditionalDocumentReference) not imported (OIOUBL, PINT A-NZ, Factura-E, XRechnung)
• Factura-E: invoice-level GeneralDiscounts / line DiscountsAndRebates not mapped; multi-invoice batches merge all lines into one draft
• XRechnung: CII (UN/CEFACT) syntax not supported; test suite sets up the service with "E-Document Format"::Mock rather than the real format

---

Reviewer note: Factura-E mapping deliberately diverges from V1

The V1 importer maps Corrective/InvoiceNumber to a different field than this PR does:

Path	Corrective/InvoiceNumber target
V1 (FacturaEImport.Codeunit.al:217-218)	"Applies-to Doc. No."
V2 before this PR (EDocumentFacturaEHandler.Codeunit.al:116)	"Purchase Order No."
V2 after this PR	"Applies-to Ext. Invoice No."

EDocCreatePurchCrMemo.Codeunit.al:62-73 treats the two draft fields differently:

• "Applies-to Doc. No." is used verbatim as a BC posted-invoice number.
• "Applies-to Ext. Invoice No." is resolved by looking up Purch. Inv. Header."Vendor Invoice No." for the vendor, and only then sets "Applies-to Doc. No.".

On an inbound credit memo, Corrective/InvoiceNumber is the original invoice number as issued by the vendor, not a BC document number. Therefore the resolving field is the correct target, and this matches every other V2 reader:

• core PEPPOL — EDocumentPEPPOLHandler.Codeunit.al:151-152
• DK OIOUBL — EDocumentOIOUBLHandler.Codeunit.al:144

V1's direct write to "Applies-to Doc. No." only applies correctly when the vendor's numbering happens to equal BC's posted invoice number; otherwise it fails to apply or mis-applies to an unrelated document. This PR intentionally does not preserve that V1 behavior. Please confirm this is acceptable.