Release 26.5.55 on 18.09.2026

This release opens a second route to Cegedim (XimantiX): a ZUGFeRD document is no longer built and mailed by mseDoc365 itself but handed over to Cegedim, which merges the PDF and the xInvoice XML into the ZUGFeRD PDF/A-3 and delivers it — steered by a conversion context that can now be set per format in the mseDoc365 Setup. The unit of an xInvoice line is also resolved more carefully: instead of falling straight back to C62 (piece) whenever a unit of measure carries no mseDoc365 mapping, the writer now consults Business Central's own International Standard Code and a new default in the setup first. And a sending target list no longer loses its first entry when a second one is added from the list.

Feature

• ZUGFeRD documents can now be sent through Cegedim (XimantiX) with the new sending type Mail / CEGEDIM-ZUGFERD ("ZUGFeRD via Cegedim"). The PDF and the xInvoice XML are handed over together, and the ZUGFeRD PDF/A-3 is assembled, validated and delivered by Cegedim instead of being produced by our own Function Server — the same route eBeleg already uses. What makes Cegedim convert rather than simply relay the document is the conversion context, which the send now transmits with every document; the two new setup fields Cegedim Conversion Context xInvoice and Cegedim Conversion Context ZUGFeRD override the built-in standard contexts for the whole company and can be left empty. Authentication stays the existing user name and password of the XimantiX connection, and the scope is the posted sales invoice and the posted sales credit memo. The existing routes — Mail/CEGEDIM for the signed PDF mail, the lettershop print jobs, Mail/ZUGFERD and xInvoice/XINVOICE — are unchanged. Sending an XRechnung through Cegedim is implemented as well, but is not yet accepted on Cegedim's side and therefore ships without a sending type; it will be released once Cegedim processes those documents (CHN-427)

• The unit of an xInvoice line (BT-130) now falls back to the International Standard Code of the Unit of Measure and to a new Default Unit Code in the mseDoc365 Setup, group Sending Options. Until now the code was taken from the mseDoc365 UNECE Code alone, so every unit without that mapping was exported as C62 — a kilogram, a metre or an hour all left the house as "piece". The resolution order is now: the mseDoc365 UNECE Code of the unit, then its standard Business Central International Standard Code, then the Default Unit Code, and only then C62 as the last resort. Existing mappings therefore keep winning and nothing that is configured today changes its behaviour; a value counts as maintained as soon as it is filled and is not checked against the mseDoc365 unit list, with one exception: an International Standard Code longer than three characters cannot be a UN/ECE Rec. 20 code and is skipped instead of being truncated into an invalid unit. Invoices and credit memos use the same resolution, and it is code rather than schema data, so existing tenants do not need to update the schema from standard. See General settings for the field and the full order

Bugfix

• Adding a second entry to an mseDoc365 Sending Target List no longer overwrites the entry that is already there. The columns of the entry list are filled exclusively through their drill-downs, and those used the result of a save attempt to decide between changing and creating a record. A new line still carries a blank No. — the number is only drawn from the number series when the entry is actually written — so as soon as a stored entry had a blank number as well, the save hit that stored entry and silently replaced its customer, vendor or contact instead of adding a second one. Lists created by the upgrade are affected in particular, because their entries were written by code and kept a blank number. The decision is now made on the record itself, so an entry is created when it is new and updated when it already exists, and the same correction applies to the Sending Type drill-down on the entry pages, which previously dropped the selected sending type on an unsaved entry without any message. In addition, an entity that is already in the list is now refused with a clear error instead of being written a second time. Entries that already carry a blank number from an earlier upgrade are not repaired by this fix and have to be corrected manually (CHN-476, INC-1733)