[E-Documents Core] [Peppol] - Enabling EDI capabilities with E-Documents. Send path (Purchase Order → E Document).

[GMatuleviciute]

This pull request does not have a related issue as it's part of the delivery for development agreed directly with @altotovi @Groenbech96

Implementation

Enables electronic document export for purchase orders in PEPPOL BIS 3.0 format, allowing buyers to send structured order documents to vendors.

Key additions:

• Creates an E-Document when a purchase order is released.
• Generates a UBL-compliant XML file for purchase orders, including buyer/seller party info, delivery address, payment terms, monetary totals, and order lines.
• Extends PEPPOL 3.0 infrastructure with purchase-header-aware overloads for all relevant data retrieval methods.
• Adds a "Canceled" status to E-Document Status enum to support order lifecycle management.
• Prevents deletion of purchase orders linked to active (non-canceled) E-Documents to protect data integrity.
• Supports re-export of the same purchase order when triggered again, updating the service status accordingly.
• Adds test coverage for E-Document creation on release, deletion guard, and successful deletion after cancellation.

Fixes #

[github-actions]

Could not find linked issues in the pull request description. Please make sure the pull request description contains a line that contains 'Fixes #' followed by the issue number being fixed. Use that pattern for every issue you want to link.

[Groenbech96]

Thanks for the work here. I'd like to request we restructure the purchase path to preserve the existing PEPPOL extensibility contract before this lands.

The issue

PEPPOL30 implements 8 interfaces exposed through the "PEPPOL 3.0 Format" enum, and that's the documented extensibility surface — partners customize PEPPOL output by extending
the enum and plugging in their own implementations (see extensibility_examples.md). Sales and service consistently go through the interface, e.g. PEPPOL30Common.GetTotals does
PEPPOLTaxInfoProvider := PEPPOLFormat; PEPPOLTaxInfoProvider.GetTaxTotals(...).

This PR takes a different route for purchase:

1. The new PurchaseHeader / PurchaseLine overloads are added to the concrete PEPPOL30 codeunit but not to any interface, so a partner's custom "PEPPOL Party Info Provider" can
   never be invoked for the purchase path.
2. EDocPurchOrderExportToXML declares PEPPOL30: Codeunit PEPPOL30 and calls it directly, bypassing the format enum entirely.

A partner who customizes PEPPOL sales output today will find, when they try to do the same for purchase orders, that the extensibility contract no longer holds. Fixing that
later means either a breaking interface change or yet another parallel API.

What I'm asking for

Please restructure along the existing pattern:

• Add purchase-specific interfaces — e.g. "PEPPOL Purchase Party Info Provider", "PEPPOL Purchase Line Info Provider", "PEPPOL Purchase Monetary Info Provider", etc. — covering
  the data the purchase-order XML needs.
• Add a new value to "PEPPOL 3.0 Format" (e.g. "PEPPOL 3.0 - Purchase Order"), with PEPPOL30 as the default implementation for these interfaces.
• Change EDocPurchOrderExportToXML to resolve the interface from the format enum rather than declaring Codeunit PEPPOL30 directly. This also means to move that to the PEPPOL App.

That keeps the purchase flow on the same extensibility rails as sales/service and lets partners override purchase-order PEPPOL output the same way they override sales today.

Edit:

Separate purchase format enum. Lets use "PEPPOL 3.0 Purchase Format" enum implementing only purchase-specific interfaces ("PEPPOL Purchase Party Info Provider", etc.),

I think its better to have parallel extensibility surfaces — one for outbound sales/service documents, one for outbound
purchase orders.

Another option:
Is to do like Service and map Purchase into a sales buffer, but that might be quite ugly.