Allowing E-Document Attachments to be PDF

[miljance]

Summary

• Allowing E-Document module to support any extension for an E-document. Currently *.xml for most of the services except for ZUGFeRD where PDF is used.
• Each connector that does not use *.xml format should subscribe to OnAfterGetFileExtension and ship file extension back.
• There is another Pull Request on ALApExtension for ZUGFeRD
• Base for Managing PDF File Extension for ZUGFeRD ALAppExtensions#29341

Work Item(s)

Fixes #5220 and #5104

Fixes AB#611441

[duichwer]

I'm not sure if it's good to have the extension with the . here.
When I look at other places of the BaseApp (e.g. the Document Attachment table then it's common to only us the extension without the . separater between the extension an the filename.

It would be useful to have some documentation at the event.

[miljance]

I agree that, in principle, a "File Extension" should not include the . separator. However, after reviewing the E-Documents module, I found that the current approach of including the dot is used consistently throughout. To avoid introducing discrepancies within the module, I would prefer to keep this behavior aligned with the existing pattern, even if it looks unusual compared to other areas like the Document Attachment table. @djukicmilica You are the boss on this one, should this function return the file extension without dot?

Documentation - makes sense, will add the documentation for the event, but also for a function.

[duichwer]

Thanks for the documentation.

I can live with a dot and without a dot.
When we look at the .net Method then we will get a Extension with dot.
In contrast the common method that is used within the BaseApp is the method GetExtension of codeunit 419 "File Management" that will trim the dot.

    procedure GetExtension(Name: Text): Text
    var
        FileExtension: Text;
    begin
        FileExtension := PathHelper.GetExtension(Name);

        if FileExtension <> '' then
            FileExtension := DelChr(FileExtension, '<', '.');

        exit(FileExtension);
    end;

I will approve the PR from my side. I just wanted to tell my concerns that we should be careful when new events/method are different to the well known methods in the BaseApp.

If I could wish me something then I would ask for a post processing of the File Extension.
Would it be bad if we had an additional check on the extension - something like:

// Prevent extension without dot
if not FileExtension.StartsWith('.) then
    FileExtension :=  '.' + FileExtension;

[miljance]

I may not have made it clear earlier, but I really appreciate the concerns you’ve raised—please keep them coming!

// Prevent extension without dot
if not FileExtension.StartsWith('.) then
    FileExtension :=  '.' + FileExtension;

This generally makes sense as a safety net. However, I usually avoid adding such checks when the surrounding processes already enforce a different approach. In this case, the entire module consistently assumes the presence of a leading dot.

In ideal world, the file management and extension management probably should not event be incorporated in the E-Documents module but in Base App or Foundation or System Application instead.

[duichwer]

I understand that we need a solution that will work pretty soon.
I can live with this but I would still prefer some solution that will store the file extension at the e-document log table.

Therefore I would suggest to rename this procedure and the event to something like GetDefaultFileExtension.
In the future this can be improved that one will use the file extension of a e-document log when it's set and otherwise the default file extension for this service.

Another solution:
Alternatively I would suggest to instead refactor the event in the E-Document Log.
https://github.com/microsoft/BCApps/blob/main/src/Apps/W1/EDocument/App/src/Logging/EDocumentLog.Table.al
And extract the File extension from there.

[miljance]

I fully agree that having the file extension stored in the Log table would make things much easier and more consistent. I personally would love it. However, introducing that change is outside the scope of this pull request and could also impact existing Microsoft connectors that rely on the current behavior. For now, I think your suggestion to rename the procedure to GetDefaultFileExtension is a good fit for this scope, and I’ll make that adjustment. I also find this name much better.

Regarding the idea of refactoring the OnBeforeExportDataStorage event: if the file extension were available in the Log table, this IntegrationEvent would likely not be necessary at all. After reviewing its usage, I noticed it’s also leveraged by OneDrive, SharePoint, and Outlook integrations, which makes it clear that this is an area where Microsoft would need to drive the change. For now, I’ll keep the current approach aligned with the existing design.

[duichwer]

I understand that some parts are out of the scope of this PR, but I appreciate the name change. Thank you.

[JesperSchulz]

Looks like we've got another codecop issue: Possible overflow assigning 'Text' to 'Text[4]'.