Release 26.5.55 am 18.09.2026

Dieses Release öffnet einen zweiten Weg zu Cegedim (XimantiX): Ein ZUGFeRD-Beleg wird nicht mehr von mseDoc365 selbst erzeugt und versendet, sondern an Cegedim übergeben — dort werden PDF und xInvoice-XML zum ZUGFeRD-PDF/A-3 zusammengeführt, geprüft und zugestellt, gesteuert über einen Konvertierungskontext, der sich jetzt je Format in den mseDoc365 Einrichtungen hinterlegen lässt. Auch die Einheit einer xInvoice-Zeile wird sorgfältiger ermittelt: Statt sofort auf C62 (Stück) zurückzufallen, sobald eine Einheit keine mseDoc365-Zuordnung trägt, zieht der Export zuerst den internationalen Standardcode von Business Central und einen neuen Standardwert aus den Einrichtungen heran. Und eine Versandzielliste verliert ihren ersten Eintrag nicht mehr, sobald ein zweiter hinzukommt.

Feature

• ZUGFeRD-Belege lassen sich jetzt über Cegedim (XimantiX) versenden, über die neue Versandart Mail / CEGEDIM-ZUGFERD („ZUGFeRD über Cegedim“). PDF und xInvoice-XML gehen gemeinsam an Cegedim, und das ZUGFeRD-PDF/A-3 wird dort erzeugt, validiert und zugestellt — nicht mehr auf unserem eigenen Function Server. eBeleg nutzt denselben Weg bereits. Dass Cegedim den Beleg konvertiert und nicht nur weiterreicht, entscheidet der Konvertierungskontext, den der Versand nun bei jedem Beleg mitschickt; die beiden neuen Felder Cegedim Konvertierungskontext xInvoice und Cegedim Konvertierungskontext ZUGFeRD in den Einrichtungen überschreiben die eingebauten Standardkontexte mandantenweit und dürfen leer bleiben. Angemeldet wird weiterhin mit Benutzername und Kennwort der XimantiX-Verbindung. Unterstützt werden die gebuchte Verkaufsrechnung und die gebuchte Verkaufsgutschrift. Die bestehenden Wege — Mail/CEGEDIM für die signierte PDF-Mail, die Lettershop-Druckaufträge, Mail/ZUGFERD und xInvoice/XINVOICE — bleiben unverändert. Der Versand einer XRechnung über Cegedim ist ebenfalls umgesetzt, wird auf Cegedim-Seite aber noch nicht angenommen und ist deshalb ohne Versandart ausgeliefert; er wird freigeschaltet, sobald Cegedim diese Belege verarbeitet (CHN-427)

• Die Einheit einer xInvoice-Zeile (BT-130) greift jetzt auf den Internationalen Standardcode der Einheit und auf den neuen Standard-Einheitencode in den mseDoc365 Einrichtungen, Bereich Sendeoptionen, zurück. Bisher stammte der Code allein aus dem mseDoc365 UNECE-Code, jede Einheit ohne diese Zuordnung ging deshalb als C62 hinaus — Kilogramm, Meter und Stunde gleichermaßen als „Stück“. Ermittelt wird nun in dieser Reihenfolge: mseDoc365 UNECE-Code der Einheit, dann deren Internationaler Standardcode aus dem Business-Central-Standard, dann der Standard-Einheitencode, und erst danach C62. Bestehende Zuordnungen haben damit weiterhin Vorrang, an heute eingerichteten Belegen ändert sich nichts. Ein Wert gilt als gepflegt, sobald er gefüllt ist, und wird nicht gegen die mseDoc365-Einheitenliste geprüft — mit einer Ausnahme: Ein Internationaler Standardcode mit mehr als drei Zeichen kann kein UN/ECE-Rec.-20-Code sein und wird übersprungen, statt zu einer ungültigen Einheit gekürzt zu werden. Rechnungen und Gutschriften ermitteln identisch, und es handelt sich um reinen Code und keine Schemadaten, bestehende Mandanten müssen das Schema also nicht vom Standard aktualisieren. Feld und vollständige Reihenfolge stehen unter Allgemeine Einstellungen

Bugfix

• Ein zweiter Eintrag in einer mseDoc365 Versandzielliste überschreibt nicht mehr den bereits vorhandenen. Die Spalten der Eintragsliste werden ausschließlich über ihre Drilldowns gefüllt, und diese entschieden anhand des Ergebnisses eines Speicherversuchs, ob geändert oder angelegt wird. Eine neue Zeile trägt aber noch eine leere Nr. — die Nummer zieht die Nummernserie erst beim tatsächlichen Schreiben —, sodass der Speicherversuch einen vorhandenen Eintrag traf, sobald auch dieser eine leere Nummer hatte: Dessen Debitor, Kreditor oder Kontakt wurde stillschweigend ersetzt, statt einen zweiten Eintrag anzulegen. Betroffen sind vor allem Listen aus dem Upgrade, deren Einträge per Code geschrieben wurden und deshalb ohne Nummer geblieben sind. Die Entscheidung fällt jetzt am Satz selbst: Ein neuer Eintrag wird angelegt, ein vorhandener geändert. Dasselbe gilt für den Drilldown Versandart auf den Eintragsseiten, der die getroffene Auswahl auf einem ungespeicherten Eintrag bisher kommentarlos verwarf. Zusätzlich wird ein Debitor, Kreditor oder Kontakt, der bereits in der Liste steht, jetzt mit einer klaren Fehlermeldung abgewiesen, statt ein zweites Mal geschrieben zu werden. Einträge, die aus einem früheren Upgrade bereits ohne Nummer in der Liste stehen, repariert die Korrektur nicht — sie müssen manuell bereinigt werden (CHN-476, INC-1733)