[Bug]: E-Documents for Germany - FindEDocumentService always selects last matching service, ignoring which service triggered the export

[miljance]

Describe the issue

When posting a document that triggers an E-Document export, the FindEDocumentService function in the Export Codeunit (e.g. codeunit 13916 "Export XRechnung Document") uses FindLast() to locate the E-Document Service by format. This means it always picks the last service matching the document format - regardless of which service actually triggered the export.

This is a problem when multiple E-Document Services share the same format (e.g. two XRechnung services — one with embedded PDF, one without). The service-level settings that influence the output (such as PDF embedding, Your Reference, or Debitor Reference) will always be taken from the last service in the list, not the one that was actually used.

The correct E-Document Service is already known at the time the export is triggered (it is passed as a parameter to Create(EDocumentService: Record "E-Document Service"; ...)), so there is no need to search for it at all.

Expected behavior

The Export Codeunit should use the EDocumentService record that is already passed in as a parameter - or alternatively retrieve it from the Record Export Buffer - rather than performing a FindLast() lookup by format. The FindEDocumentService function should either be passed the correct service code directly, or removed entirely in favor of passing the service through the call chain.

Steps to reproduce

1. Use Business Central for Germany (E-Documents DE / E-Documents Core).
2. Create two E-Document Services with the same Document Format (e.g. XRechnung):
   • XRECHNUNG — Description: "XRechnung w/o PDF"
   • XRECHNUNG+PDF — Description: "XRechnung with PDF" (with PDF embedding enabled)
3. Create two separate Document Sending Profiles, each with a dedicated Workflow pointing to the respective E-Document Service.
4. Assign XRECHNUNG (without PDF) to a customer via its sending profile.
5. Create and post a Sales Invoice for that customer.
6. Open the resulting E-Document and export the XML.
   • Actual result: The PDF is embedded in the XML — settings from XRECHNUNG+PDF (the last service) are used.
   • Expected result: No PDF is embedded — settings from XRECHNUNG (the triggered service) should be used.

Additional context

A workaround exists: add a field for the E-Document Service Code to the Record Export Buffer, populate it in CreateSourceDocumentBlob, and then use SetRange(Code, EDocumentCode) in FindEDocumentService. However, the cleaner and correct long-term fix is to pass the service directly through the call chain, making FindEDocumentService obsolete entirely.

I will provide a fix for a bug

• I will provide a fix for a bug

[miljance]

@pri-kise

[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.}

[miljance]

@marschmar

[pri-kise]

wouldn't it be possible to use manual event binding or instead add a setter to the codeunit and call it before OnRun

[miljance]

Manual Binding sounds like too much from my point of view. If should be clear while entering the codeunit what is the service being passed. Whether this will be done using a setter function or passed to the buffer table - both are possible. For some reason I think using the new field in the Buffer table sounds more appealing to me as I could imagine some other parameters might be transferred as well in the future.