ZUGFeRD Export with custom reports

[pri-kise]

Summary

Enable ZUGFeRD export for custom reports.

Work Item(s)

Fixes #29254
AB#609600

[pri-kise]

This is a first draft on how it would be possible to allow custom reports for the sales invoice for the ZUGfERD format.

A partner would need to add the following the their custom sales invoice/cr. memo report.

• The code that exists in the report extensions
• an interface implementation to manual bind events that the custom report knows if the xml should be included
• an event subscriber to the event OnGetZUGFeRDReportIntegrations

[mynjj]

Cool PR @pri-kise 😄

Pros I see of the approach:

• Allows extenders to subscribe to any events needed throughout the process, so it's very flexible, even if there are events that the original implementation doesn't consider.

"Coding by convention" observations:

• implementers of BindSubscriptionForReportIntegration have to bind the subscription, but that is of course in their own best interest, so that's probably fine. Also there's no way of calling BindSubscription on an interface, which would avoid the need of the interface, so this is currently a good solution.
• Nothing restricts the subscriber to delete all other interfaces in the list: this one could be solved by providing a wrapper codeunit to the event that allows only to add.

One thing I don't like that much is that it's a bit too flexible, and we are losing a bit control of the extensibility story - anything in the stacktrace is now possible to be modified if there's an event and it will only happen when coming from "Export Zugferd Document" which might make things difficult to troubleshoot if things go wrong. I'm usually a bit more conservative and more explicit about what can be modified. That being said, there's nothing wrong with the flexibility, and the scenario may warrant it.

An alternative approach could be keep the manual subscription as it is, but in the events of interest where "Export Zugferd Document" subscribes manually, provide hooks (either via events or interfaces) for implementers.

The main question I have is: do we envision that there will be several events called while running ExportSalesDocument that the main implementation "Export ZUGFeRD Document" doesn't subscribe to, but that extenders want to subscribe to?

We'll have a closer look with Nikola, Milica and Magnus over the week 😃

[JesperSchulz]

@mynjj, I'll create a DevOps PR for us to check that all tests pass etc. I'll add the suggested reviewers.

[github-actions]

Processing this PR. The branch is now locked 🔒 Please don't push updates unless otherwise agreed.

[pri-kise]

The code will be refactored to the following design:

Adding the following to codeunit 13917 "Export ZUGFeRD Document" :

    EventSubscriberInstance = Manual;

    /// <summary>
    /// Use this procedure to check if the current report print is for the ZUGFeRD export
    /// </summary>
    /// <returns>true when the XML should be embedded</returns>
    procedure IsZUGFeRDPrintProcess() Result: Boolean
    begin
        Result := false;
        OnIsZUGFeRDPrintProcess(Result);
    end;


    [EventSubscriber(ObjectType::Codeunit, Codeunit::"Export ZUGFeRD Document", OnIsZUGFeRDPrintProcess, '', false, false)]
    local procedure EnableOnIsZUGFeRDPrintProcess(var Result: Boolean)
    begin
        Result := true;
    end;

    [InternalEvent(false)]
    local procedure OnIsZUGFeRDPrintProcess(var Result: Boolean)
    begin
    end;

Note: The event EnableOnIsZUGFeRDPrintProcess would be manually binded as alternative to the current event subscribers OnBeforeInitializePDFSalesInvoice / OnBeforeInitializePDFSalesCrMemo

Instead of the event in the reportextension / report we would simple call the method ExportZUGFeRDDocument.IsZUGFeRDPrintProcess()

[JesperSchulz]

Merged the latest changes internally. Giving this another go.