Skip to main content

Release 26.5.58 on 23.10.2026

· 4 min read

This release introduces the eDocument status Subsequently Sent: a new optional process step marks failed eDocuments of a document as subsequently sent once the document has been sent successfully in a later process, so Repeat in the old process no longer sends it a second time. The process card now shows the document number of each eDocument, XRechnung CII no longer writes an empty seller tax registration (PEPPOL-EN16931-R008) without a Registration No., and the AutoFlow process step calls AutoFlow by its new object ID.

Feature​
  • New eDocument status Subsequently Sent and new process step MARK_SUBSEQ_SENT (Mark failed eDocs of this document as subsequently sent). Placed after the SEND step of a process template, the step looks for other eDocuments of the same document with the status Failed: those with the same sending type are set to Subsequently Sent and get a response naming the process and eDocument that sent the document; those with a different sending type keep the status Failed and only get a response. If the eDocument has no finished SEND step, the step is skipped and nothing is marked. A process whose remaining eDocuments are all Completed or Subsequently Sent is no longer open, and Repeat only picks up the eDocuments that are still Failed. The new column No. of Subsequently Sent Documents on the process list shows how many documents of a process were sent later. Subsequently sent eDocuments are shown in yellow. The step is opt-in — nothing changes until it is added to a process template — and existing eDocuments are not changed. See Status "Subsequently Sent" (CHN-554)
  • The eDocument lines on the process card now have a Document No. column, as on the eDocument list: for outgoing documents the number of the sent sales document, for incoming documents the external document number from the xInvoice. Drill down to open the related document. (CHN-553)
Bugfix​
  • XRechnung CII (and ZUGFeRD, which embeds the same output): when Registration No. in Company Information is empty, the seller's SpecifiedTaxRegistration with schemeID FC (BT-32) was written as an empty element and the KoSIT validator rejected the invoice with PEPPOL-EN16931-R008. The schema line is now filled from Company Information Registration No. and controlled by Check to Process or Ignore, like BT-30; with a Registration No. the output is unchanged. There is no upgrade code — existing schemas must be updated with Update Schema from Standard on XRECHNUNG-OUT (SALES-INVOICE and SALES-CR.MEMO), or the line must be adjusted manually (CHN-546)
  • The AutoFlow process step now calls AutoFlow's External Start by its new object ID 5564812, because the previous ID is used by another AutoFlow object in upcoming AutoFlow releases. The step also checks the object's name, so it never runs a different codeunit under a reused ID. Install this version before updating AutoFlow (CHN-534)
  • The process card and the eDocument card stopped refreshing automatically after a failed refresh round-trip, for example while an eDocument failed, and stayed static after Continue or Repeat. Both actions now restart the automatic refresh (CHN-381)
Enhancements​
  • New integration events for extensions: OnAddRecordsToRecRefInstances in the XML reader (register an own table for an incoming element the reader does not handle, so the schema can map the element's children into it), OnAfterGetFieldValue in the XML writer (change an element's value after formatting), OnAfterParseXInvoice (carry values from the eDocument over to the newly read xInvoice) and OnAfterCollectLockFromSchemaLine / OnAfterApplyLockToSchemaLine (keep an extension's own fields on locked schema lines across a schema update)
  • The PDF request handler exposes the Function Server endpoint pdf/build (procedure Build), which draws page objects onto an existing PDF and returns it in the requested conformance
Changes​
  • A process step fails with the error Process step parameter %1 is not handled. when no subscriber handles its parameter. Before, such a step finished as if it had done its work
  • A step that fails because the table was changed by another session while the step ran (Die Aktivität wurde aufgrund einer Änderung der Tabelle …) is now retried, like the other transient concurrency conflicts, instead of failing the eDocument