[Extensibility]: Add IntegrationEvent to allow customization of Workflow selection per document type in E-Document Framework

[pamura1977]

Describe the issue

The E-Document Framework currently selects a single workflow per Document Sending Profile from the field "Electronic Service Flow". When multiple document types from a single posting (e.g. Sales Shipment + Sales Invoice from a posted Sales Order) need to be processed with different workflows — for example, because they require different E-Document formats — there is no extension point to customize this selection.

Example scenario:

• Sales Shipments should be sent via PEPPOL BIS 3.0
• Sales Invoices should be sent via XRechnung
• Sales Credit Memos should be sent via ZUGFeRD

In the current architecture, partners have no extensibility mechanism to handle this case cleanly, resulting in incorrect or empty files being produced and potentially sent to the wrong endpoints.

Add a single IntegrationEvent in Codeunit "E-Doc. Export", procedure CreateEDocument, that allows extensions to override the workflow code used for the current document type.

The event should be raised just before the workflow is loaded from the document sending profile. It receives the document sending profile and the document type as read-only parameters and exposes only the workflow code as a var parameter, making the intent explicit: extensions are only allowed to override the workflow selection, not the rest of the profile.

Proposed event signature:

[IntegrationEvent(false, false)]
local procedure OnBeforeGetWorkflowForEDocument(
    DocumentSendingProfile: Record "Document Sending Profile"; 
    DocumentType: Enum "E-Document Type"; 
    var WorkflowCode: Code[20])
begin
end;

Proposed change in Codeunit "E-Doc. Export", procedure CreateEDocument (around line 60-98 in BC 28.2):

internal procedure CreateEDocument(DocumentHeader: RecordRef; DocumentSendingProfile: Record "Document Sending Profile"; EDocumentType: Enum "E-Document Type")
var
    WorkFlow: Record Workflow;
    WorkflowCode: Code[20];
    EDocument: Record "E-Document";
    ...
begin
    WorkflowCode := DocumentSendingProfile."Electronic Service Flow";
    OnBeforeGetWorkflowForEDocument(DocumentSendingProfile, EDocumentType, WorkflowCode);

    if not WorkFlow.Get(WorkflowCode) then
        Error(DocumentSendingProfileWithWorkflowErr, WorkflowCode, ...); 

    WorkFlow.TestField(Enabled);
    ...
    EDocument."Workflow Code" := WorkFlow.Code;
    ...
end;

Expected behavior

Extensions can subscribe to the new event and override the workflow per document type without manipulating the document sending profile record. The change is purely additive: when no subscriber overrides the workflow code, the existing behavior is preserved.

Example subscriber implementation in a partner extension:

[EventSubscriber(ObjectType::Codeunit, Codeunit::"E-Doc. Export", 
    'OnBeforeGetWorkflowForEDocument', '', false, false)]
local procedure OverrideWorkflowPerDocumentType(
    DocumentSendingProfile: Record "Document Sending Profile";
    DocumentType: Enum "E-Document Type"; 
    var WorkflowCode: Code[20])
begin
    case DocumentType of
        DocumentType::"Sales Invoice", DocumentType::"Service Invoice":
            if DocumentSendingProfile."Workflow Sales Invoice EXT" <> '' then
                WorkflowCode := DocumentSendingProfile."Workflow Sales Invoice EXT";
        DocumentType::"Sales Credit Memo", DocumentType::"Service Credit Memo":
            if DocumentSendingProfile."Workflow Sales Credit Memo EXT" <> '' then
                WorkflowCode := DocumentSendingProfile."Workflow Sales Credit Memo EXT";
    end;
end;

The extension would also add the corresponding fields via a TableExtension on Document Sending Profile.

Steps to reproduce

Current limitation can be reproduced as follows:

1. Configure one Document Sending Profile with Electronic Document = "Extended E-Document Service Flow" and a workflow that triggers a single E-Document service per supported document type.
2. Post a Sales Order that creates both a Sales Shipment and a Sales Invoice.
3. Observe: both posted documents are processed using the same workflow, regardless of document type. There is no extension point to influence the workflow selection per document type.

Additional context

Why a single event with these specific parameters:

• The event is placed at a central location (Codeunit "E-Doc. Export", CreateEDocument), so a single integration point covers all sources (Sales-Post, Service-Post, Purchase-Post, Transfer-Order-Post, Whse.-Activity-Post). No changes needed at the calling subscriber sites.
• DocumentSendingProfile is passed by value (read-only) so subscribers can read additional extension fields but cannot accidentally modify the profile.
• DocumentType is passed by value (read-only) since it is informational.
• WorkflowCode is the only var parameter, making the contract with extensions explicit: only the workflow code may be overridden.
• The change is minimal-invasive: one event declaration plus three additional lines in the existing procedure (var WorkflowCode, assignment, event call). The existing Workflow.Get(...) line is modified to use the new variable.
• Purely additive: existing behavior is preserved when no subscriber is registered.

Reference to the code location (BC 28.2):
src/Apps/W1/EDocument/app/src/Processing/EDocExport.Codeunit.al, procedure CreateEDocument (lines 60-98).

I will provide a fix for a bug

• I will provide a fix for a bug

[JesperSchulz]

🤖 AI triage completed. Product group, please validate the triage report (Microsoft internal access only, use Ctrl+Click to open in new tab).

---

_{Was this triage helpful? React with 👍 or 👎 on this comment to provide feedback.}