Release Notes

Leere Metadaten eines Folgeauftrags werden beim Öffnen einer Dokumentvorlage als leeres JSON-Objekt übernommen. Bisher konnte ein von der Schnittstelle gelieferter leerer Listenwert eine Fehlermeldung auslösen und das Speichern blockieren – auch bei deaktiviertem Folgeauftrag.

Vorhandene Metadaten bleiben erhalten. Ungültiges JSON und Listen als zusätzliche Metadaten werden weiterhin zurückgewiesen.

Das Profil EXTENDED unterstützt Rechnungen, die nicht steuerbare Positionen (Kategorie O) zusammen mit anderen Steuerkategorien enthalten. Die Kategorien bleiben erhalten. Die Profilprüfung unterscheidet EXTENDED von EN 16931; für EN 16931 und XRechnung bleiben die bisherigen Einschränkungen aktiv.

EXTENDED-Dokumente erhalten die passende Profilangabe im PDF und eine eingebettete factur-x.xml. Die Verarbeitung der anderen Profile bleibt unverändert.

Ein fehlgeschlagener Webhook konnte bisher den Download eines bereits erstellten Dokuments in der Oberfläche verhindern. Der Download steht jetzt zur Verfügung, sobald eine gerenderte Datei vorhanden ist. Das gilt für den Dateinamen in der Liste und der Detailansicht sowie für die Download-Aktion.

Der Prozess behält seinen tatsächlichen Status. Ein Download löst keinen erneuten Webhook-Aufruf aus. Ohne gerenderte Datei wird kein Download angeboten.

Der Editor für Datenmapping-Regeln erhält Sonderzeichen beim Speichern und erneuten Öffnen. Bisher konnte etwa ein Eurozeichen dazu führen, dass eine Regel scheinbar erfolgreich gespeichert wurde, zugehörige Rendering-Anfragen aber anschließend mit einem PHP-Parserfehler blockierten.

Fehlerhaft kodierter Code wird jetzt bereits beim Speichern zurückgewiesen. Auch die Verarbeitung und die Simulation melden bei solchen Bestandsregeln einen verständlichen Kodierungsfehler. Vorhandene Regeln lassen sich im Editor öffnen und durch erneutes Speichern korrigieren.

Vorlagen, die in Word bearbeitet und gespeichert wurden, lassen sich über MCP wieder öffnen und hochladen. Bisher wurden manche dieser Dateien als beschädigt abgelehnt, obwohl Word und die Vorlagenverwaltung sie problemlos verarbeiten.

Öffnen Sie einen Datei-Link in einer anderen Browser-Anmeldung als der, in der Sie die Verbindung bestätigt haben, nennt der Datei-Dialog jetzt den Grund: Verbinden Sie Output.Rocks in Ihrem KI-Assistenten neu und öffnen Sie den Link danach im selben Browser.

Änderungsvorschläge zu einer Version, die inzwischen durch eine neuere ersetzt wurde, lehnt MCP gleich beim Vorschlagen ab. Bisher scheiterten sie erst bei der Freigabe.

Binect liefert Links zur Deutschen Post teilweise mit dem URL-Parameter trackingId. Output.Rocks gibt diese Links mit dem passenden Parameter piececode aus. Dadurch funktionieren auch bereits gespeicherte Links in der Detailansicht und in der API, ohne die Trackingdaten erneut abzurufen oder einen Brief erneut zu versenden.

Ein Merkmal wie isRerender musste bislang per Datenmapping-Regel aus den Request-Metadaten in die Renderdaten übernommen werden. Dokumentvorlagen können jetzt direkt darauf zugreifen:

<<cs_or.metadata.isRerender>>
Dieses Dokument wurde erneut erstellt.
<<es_>>

Auch verschachtelte Werte wie <<or.metadata.source.reason>> sind verfügbar. Dokumentbausteine und die Dokumentvorschau der Request-Simulation erhalten denselben Kontext. Ohne Request-Metadaten ist er leer.

Der Pfad or.metadata ist für die Metadaten der aktuellen Anfrage reserviert. Gleichnamige Payload-Werte werden in der Übergabe an die Vorlage vollständig ersetzt; die gespeicherten Kundendaten werden dadurch nicht verändert. Gruppen-Bedingungen verwenden weiterhin metadata['isRerender'] == true.

Eine Gruppen-Bedingung wie metadata['isRerender'] == true erhielt in der Request-Simulation bisher leere Metadaten. Dadurch konnte eine Vorlage in der Simulation fehlen, obwohl der echte Rendering-Workflow sie zuordnete.

Simulation und Vorschau verwenden jetzt die Metadaten der aktuellen Anfrage, bei bearbeiteten Vorschauen einschließlich der Änderungen im Entwurf. Der Zugriff in Dokumentvorlagen bleibt <<or.metadata.isRerender>>.

Binect-Sendungen lassen sich nach Normalbrief, Einschreiben, Einwurf-Einschreiben und den weiteren verfügbaren Sendungsarten filtern. Die Filterung berücksichtigt auch bestehende Sendungen, sofern die damalige Sendungsart gespeichert ist.

Über Spalten konfigurieren können Sendungsnummer und Sendungsart direkt in der Übersicht eingeblendet werden. Die Auswahl und Reihenfolge lassen sich persönlich oder als Mandantenstandard speichern.

Binect-Sendungsnummern und Trackinglinks werden an der Drucksendung gespeichert und in deren Detailansicht angezeigt. Sind die Daten erst später verfügbar, lädt Output.Rocks sie mit begrenzten Wiederholungen nach. Berechtigte Personen können auch abgeschlossene Einschreiben gezielt nachladen, ohne einen Brief erneut zu versenden.

Die neue lesende Schnittstelle /api/print-deliveries/tracking liefert berechtigten API-Token-Inhabern die Sendungsnummern samt Prozess- und externer Referenz. Der Versandstatus bleibt vom tatsächlichen Zustellergebnis getrennt.

Für Binect-Dokumente und PDF-Anhänge aus E-Mail-Prozessen lässt sich jetzt die Anmeldung per API-Key wählen. Bestehende Verbindungen verwenden weiterhin Benutzername und Passwort. Schlüssel können über die verschlüsselte Zugangsdaten-Verwaltung referenziert werden.

Der Verbindungstest prüft bei API-Keys auch die für den Briefversand nötigen FULL-Rechte. Ungültige oder abgelaufene Schlüssel und fehlende IP-Freigaben werden verständlich gemeldet. Statusabfragen und Sendungsverfolgung verwenden dieselbe gewählte Anmeldung.

Unter Benutzer → Benutzer bearbeiten können Administratoren die Berechtigung Support-Zugang vergeben oder entziehen. Bestehende Benutzer mit Admin-Rechten erhalten sie bei der Einführung einmalig. Danach bleibt sie unabhängig von der Admin-Rolle verwaltbar; bei neuen Benutzern wird sie bewusst ausgewählt.

Bei freigeschalteten Kunden wird der Support-Kontakt beim ersten Aufruf automatisch zugeordnet. Eine zusätzliche manuelle Einrichtung im Support ist nicht mehr nötig. Nutzer sehen ihre eigenen Anfragen; Admins ohne Bindung an einen Umgebungs-Mandanten sehen zusätzlich alle Anfragen ihres Kunden.

Ein Entzug sperrt auch den weiteren Zugriff über eine bestehende Supportsitzung. Die Berechtigung bleibt bei einer erneuten SSO-Anmeldung erhalten und wird in Output.Rocks verwaltet. Die Freischaltung des Kunden für den Support ist weiterhin Voraussetzung.

Die XML-Prozessliste bietet zusätzlich zu Status und „Nur blockierte“ Filter für Rechnungsnummer, Profil und eigenständige oder eingebettete XML. Alle Filter lassen sich kombinieren und gemeinsam zurücksetzen.

ID, Rechnungsnummer, Profil, Status und Zeitstempel lassen sich über die Spaltenüberschrift auf- und absteigend sortieren. Die Tabelle verwendet die gemeinsame, besser lesbare Darstellung der anderen Prozesslisten.

Über Spalten konfigurieren wählen und ordnen Sie die sichtbaren Spalten. Persönliche Einstellungen und Mandantenstandards werden gespeichert. Ergänzend stehen Änderungs- und Abschlussdatum, externe ID, verknüpfte Prozesse sowie Umgebungs-Mandant zur Auswahl.

Bestätigte Bounce-Rückmeldungen setzen den E-Mail-Workflow automatisch fort. Aktiviertes Bounce-Re-Rendering und die konfigurierten Folgeaktionen benötigen damit keine zusätzliche manuelle Zustellentscheidung.

Sehr frühe Zustellrückmeldungen und gleichzeitig laufende Workflows verlieren die Fortsetzung nicht mehr. Die Korrektur gilt auch für erfolgreiche Zustellungen.

• Oben im Dashboard steht jetzt Output Pulse: Output.Rocks als animierte Platine mit den Stationen Quellsystem, API-Gateway, Rendering-Engine, E-Rechnung, E-Mail-Server, Druck und Kuvertierung, Empfänger und Archiv. Die bisherigen Hinweise und Diagramme folgen darunter.
• Die Animation folgt der aktuellen Last. Gehen viele E-Mails hinaus, fliegen viele E-Mail-Symbole; ist es ruhig, steht die Szene still und nennt den Zeitpunkt der letzten Anfrage. Bis zu einem Ereignis pro Sekunde erscheint jedes einzeln, darüber wird die Darstellung gedämpft. Die aktuelle Rate pro Minute steht im Kopf der Ansicht.
• Die Kennzahlen an den Stationen zählen live mit, wahlweise für die letzten 24 Stunden oder den laufenden Monat: Anfragen, Dokumente und Seiten, E-Rechnungen mit Profil, E-Mails, Zustellungen und Bounces, Briefe und Porto sowie die abgeschlossenen Vorgänge. Ändert sich ein Wert, zählt die Karte zum neuen Wert hoch und zeigt den Zuwachs kurz als „+n“ an.
• Welche Stationen aktiv sind, ergibt sich aus Ihrer Konfiguration. Nicht genutzte Stationen erscheinen grau.
• Bei Umgebungs-Mandanten zeigt eine Liste unter der Szene die Dokumente je Umgebungs-Mandant; jede Zeile und die Datenpakete in der Szene tragen die Farbe, die beim Umgebungs-Mandanten hinterlegt ist – dieselbe wie in den Diagrammen. Umgebungs-Mandanten selbst sehen nur ihre eigenen Zahlen.
• Der Zeitraffer spielt die letzten 24 Stunden Stunde für Stunde ab. Die Ansicht lässt sich einklappen und bleibt dann eingeklappt.

• Im Tab Folgeauftrag konfigurieren Sie eine Zielkennung sowie optionale Eigenschaften für den neuen Request. Webhooks lassen sich übernehmen, abschalten oder ersetzen.
• Der Folgeauftrag beginnt erst nach erfolgreicher Dokumentverarbeitung einschließlich aller Webhooks und gegebenenfalls bestätigter Druckübergabe. Abgelehnte Freigaben lösen keinen Folgeauftrag aus.
• Gespeicherte Archivantworten werden mit den Geschäftsdaten übernommen. Statische Anhänge werden nicht automatisch kopiert. Quellprozess und Folgeauftrag sind miteinander verlinkt.
• Wiederholungen erzeugen keinen zweiten Folgeauftrag. Mehrstufige Ketten sind mit Schleifenschutz und einer Grenze von zehn Folgeschritten möglich.
• Bestehende Vorlagen bleiben unverändert, bis die Funktion aktiviert wird. Die jeweilige Archivintegration muss die erforderliche Abrufbarkeit bestätigen.

• Die Oberfläche folgt dem CONUTI-Anwendungsstandard: Deep Azure als Markenfarbe, helle Navigation und ruhige, kompakte Darstellung in Cabinet Grotesk.
• Schaltflächen, Eingabefelder, Tabellen, Dialoge und Seitenköpfe haben einheitliche Größen, Abstände und Rundungen. Statusanzeigen nennen ihren Zustand immer auch als Text.
• Der aktive Navigationspunkt ist hinterlegt und hervorgehoben. Gehört die aktuelle Seite zu einem Untermenü, ist der übergeordnete Eintrag markiert.
• Der dunkle Modus bleibt erhalten und verwendet dieselben Farben in heller Abstufung, damit Links, Symbole und Hervorhebungen gut lesbar sind.
• Installationen mit eigener Markenfarbe übernehmen diese durchgängig: Schaltflächen, Navigation, Links und Hervorhebungen erscheinen in der jeweiligen Markenfarbe.
• Im Dashboard folgen die Archivkennzahlen jetzt auf die Diagramme. Sie trennen den aktuellen Bestand von den Werten des Berichtsmonats, nennen Größen in kB, MB oder GB und zeigen die Aufschlüsselung nach Umgebungs-Mandant, Aufbewahrungsklasse und Quelle bei Bedarf.
• Diagramme ohne Werte im Zeitraum sagen das ausdrücklich. Der Hauptmandant heißt in den Legenden „Hauptmandant“, und dunkle Vorlagen- oder Mandantenfarben bleiben im dunklen Modus erkennbar.

• Der KI-Assistent erhält konkrete Versionsregeln für waagerechte Balkendiagramme und behält die eingestellte Diagrammgröße bei, sofern keine Änderung gewünscht ist.
• Fehlgeschlagene Diagramm- und QR-Code-Vorschauen zeigen die Fehlermeldung des Renderers statt unlesbarer Bilddaten. Fehlt eine Textmeldung, erscheint eine allgemeine Fehlermeldung.
• Abgelehnte Entwürfe werden mit einem Warnsymbol und „Entwurf nicht freigegeben“ gekennzeichnet. Die Übernahme bleibt gesperrt.

Scheitert nach einer Datenkorrektur im Cockpit ein wiederholbarer Dokument- oder E-Mail-Webhook, wird der ausstehende Schritt automatisch an die Hintergrundverarbeitung übergeben. Diese nutzt die vorhandenen begrenzten Wiederholungen. Bereits erfolgreich ausgeführte Webhooks werden dabei nicht erneut ausgeführt.

Nicht wiederholbare Fehler und Fehler, die auch nach den Wiederholungen bestehen bleiben, sind weiterhin im Cockpit sichtbar.

Der KI-Assistent im Diagramm-Editor berücksichtigt jetzt dieselben App-Daten wie die Diagrammvorschau: Standardwerte, Vorlagenkomponenten und or-Werte des Mandanten, des ausgewählten Umgebungs-Mandanten und der Marke. Vorhandene App-Platzhalter wie <<standard.farbe_primaer>> gelten damit auch ohne zusätzliche Testdaten als vorhanden. Ausgangsdiagramm und Entwurf werden mit diesen Werten geprüft und gerendert.

Innerhalb der App-Namensräume haben die App-Werte Vorrang vor gleichnamigen Testdaten. Nach einem Wechsel des Umgebungs-Mandanten oder der Marke muss ein KI-Entwurf erneut geprüft werden, bevor er übernommen werden kann.

Wenn Binect beim Dokument-Upload eine nicht lesbare Fehlerantwort liefert, enthält die Fehlermeldung jetzt den HTTP-Status. Der Inhalt der Antwort und Zugangsdaten werden dafür nicht übernommen. Die Behandlung und Wiederholung der Sendung bleiben unverändert.

Die Archiv-Referenzen in der Dokument-Abholung und in Archiv-Ereignissen setzen nun einen eindeutig aktivierten Archivmodulstatus voraus. Uneindeutige oder ungültige Einstellungen blenden diese Zusatzdaten aus; die Dokument-Abholung selbst bleibt nutzbar.

In der API-Token-Verwaltung können Sie bestehende Token und OAuth-Geheimnisse rotieren. Der neue Wert ist sofort gültig. Der bisherige Wert bleibt für eine wählbare Übergangszeit von einer Minute bis sieben Tagen gültig; voreingestellt sind 24 Stunden.

Die Detailansicht zeigt den Ablaufzeitpunkt und die ungefähre letzte Verwendung beider Werte. Sobald alle Anbindungen umgestellt sind, können Sie den alten Wert vorzeitig sperren. Bei Verdacht auf Kompromittierung sperrt eine Notfallrotation alle bisherigen Werte sofort.

Im Dialog E-Rechnung bearbeiten steht jetzt der Abschnitt Lieferempfänger zur Verfügung. Dort können Sie Name, Kennung / Marktlokation und die vollständige Lieferanschrift korrigieren. Der Wechsel in die erweiterte JSON-Ansicht ist dafür nicht mehr erforderlich.

Speichern & neu erzeugen übernimmt die Korrektur und startet die Erzeugung und Validierung erneut. Weitere Rechnungsdaten bleiben erhalten. Wenn die Rechnung keinen Lieferempfänger enthält und Sie die neuen Felder nicht bearbeiten, bleibt er auch nach dem Speichern unverändert abwesend.

Beim Erstellen und Bearbeiten eines zentralen API-Tokens können Sie Umgebungs-Mandanten nach ID, Name oder externer ID suchen. Die Auswahl zeigt die Anzahl der gewählten Mandanten und behält sie beim Wechsel der Suche bei. Auch bei mehreren hundert Umgebungs-Mandanten bleibt die Liste auf eine feste Höhe begrenzt.

Integratoren und Admins des Hauptmandanten können bei aktiviertem Modul „Umgebungs-Mandanten“ ein zentrales API-Token mit einer Liste erlaubter Umgebungs-Mandanten erstellen. Jede Anfrage übermittelt weiterhin X-AUTH-TOKEN und zusätzlich X-SUB-CLIENT mit der externen ID des gewünschten Mandanten. Ohne gültigen, erlaubten Umgebungs-Mandanten wird die Anfrage abgewiesen; es gibt keinen Standardzugriff auf den Hauptmandanten.

Die Erlaubnisliste eines zentralen Tokens lässt sich später bearbeiten. Bereits fest zugeordnete Tokens funktionieren ohne den zusätzlichen Header unverändert. Wird X-SUB-CLIENT mitgesendet, muss er zur festen Zuordnung passen; Hauptmandanten-Tokens akzeptieren keine Auswahl eines Umgebungs-Mandanten. Bestehende Kundenzugangsdaten werden nicht automatisch geändert.

Für eine Prüfung lässt sich ein Nur-Lese-Zugang mit Ablaufdatum, Archivierungszeitraum, Aufbewahrungsklassen und bei Bedarf einem Umgebungs-Mandanten einrichten. Außerhalb dieser Grenzen sind Archivdaten auch über direkte Links nicht verfügbar.

Eine Archivsuche kann als Prüfpaket im Hintergrund vorbereitet werden. Das Paket enthält Originaldateien, vorhandene E-Rechnungs-XML, einen Index als CSV und JSON, das Prüfprotokoll sowie SHA-256-Prüfsummen. Den Fortschritt und den befristeten Download zeigt die Archivsuche. Noch nicht gespeicherte oder bereits gelöschte Treffer bleiben im Index mit ihrem Zustand sichtbar; bei gelöschten Einträgen liegt der verfügbare Löschungsnachweis bei. Kann ein eigentlich verfügbares Original nicht auf seine geschützte Version und Prüfsumme geprüft werden, schlägt der Export sichtbar fehl. Für einen einzelnen Eintrag kann das Prüfprotokoll außerdem als PDF oder CSV geladen werden.

Bei E-Rechnungen aus Output.Rocks legt das Archiv neben PDF und Rechnungs-XML nun auch den tatsächlich gespeicherten KoSIT-Prüfbericht ab. Der Bericht gehört als eigener geschützter Bestandteil zum selben Archiveintrag.

Wurde die Prüfung übersprungen oder liegt kein Prüfbericht vor, vermerkt der Archivprozess den Grund und legt keinen Bericht an.

Für einen ausdrücklich eingerichteten Archivmandanten verschlüsselt das System neue Dokumente und zugehörige Archivbestandteile mit dessen eigenem Schlüssel. Die Sicherungskopie in Irland erhält einen separaten Schlüssel. Andere Mandanten und bereits vorhandene Versionen behalten ihre bisherigen Schlüssel.

Ein Schlüsselwechsel betrifft nur neue Versionen. Alte Schlüssel müssen für die Dauer der Aufbewahrung und für Wiederherstellungen verfügbar bleiben. Fehlt die Berechtigung für einen zugeordneten Schlüssel, schlägt die Ablage fehl, statt auf den gemeinsamen Archivschlüssel auszuweichen.

Die Anwendung zeigt Archivfunktionen nur an, wenn das Archivmodul für den aktuellen Mandanten aktiviert ist. Das gilt auch für Archivrollen in der Benutzerverwaltung, Archiv-Rechte und deren Änderungsverlauf bei API-Tokens sowie Archiv-Webhooks. Allgemeine Benutzer-, Token- und Webhookfunktionen bleiben verfügbar.

Beim Bearbeiten eines API-Tokens oder Benutzers in einem Mandanten ohne Archivmodul bleiben bereits gespeicherte Archivrechte erhalten. Direkte Archivseiten und neue Archiv-Webhook-Konfigurationen sind dort nicht zugänglich.

Auch bei einem ungültigen Wert für die Archivaktivierung bleibt die allgemeine Benutzeransicht erreichbar; Archivfunktionen gelten dann als deaktiviert.

Das Dashboard zeigt Archivkennzahlen für den aktuellen UTC-Monat. Im Monatsbericht können berechtigte Benutzer einen Monat wählen und einen gesonderten Archivbericht als PDF herunterladen. Er zeigt den heutigen Archivbestand und die Ereignisse des gewählten Monats, jeweils nach Umgebungs-Mandant, Aufbewahrungsklasse und Quelle. Der Abruf berücksichtigt den aktuellen Mandanten- und Prüferumfang. Die bisherigen Monatsberichte bleiben erhalten.

Berechtigte Benutzer können die Aufbewahrungsfrist mit Begründung verlängern. Das Archivdetail zeigt E-Rechnungs-XML, Prüfberichte und Metadatenrevisionen mit Speicherversion und Prüfsumme sowie einen geschützten Download.

Löschaufträge zeigen nach einem Neuladen ihren tatsächlichen Status. Offene oder fehlgeschlagene Aufträge erscheinen nicht als abgeschlossen; den Löschnachweis gibt es erst nach bestätigter Löschung.

Beim Dokument-Archiv-Webhook lassen sich Postwunsch, fehlende E-Mail-Adresse und ein Bounce nach Wartezeit als Auslöser für ein QR-Anschreiben wählen. Die Auswahl wirkt erst nach bestätigter Archivierung und wird pro Dokument nur einmal automatisch ausgeführt. Die Archivdetailansicht zeigt Druckstatus, Abruf und Nichtabruf sowie das archivierte Anschreiben. Eine begründete Erinnerung erhält einen eigenen neuen Link und berührt frühere Briefe nicht.

Die beigelegte A4-Standardvorlage zeigt Rechnungsnummer und Zugangscode nur bei vorhandenem Wert und erzeugt ihren QR-Code direkt aus dem Kurzlink.

Dateien, die über die Archiv-API oder den manuellen Upload eingehen, bleiben unverändert im revisionssicheren Archiv. Ein Download ist erst möglich, wenn die Schadsoftware-Prüfung erfolgreich abgeschlossen wurde. Das gilt auch für zusätzliche Dateikomponenten und bereits vorhandene externe Archiveinträge.

Ein Fund oder ein technischer Prüffehler sperrt den Zugriff. Der Prüfstatus ist in der Archivansicht und über die API sichtbar. Nach einem technischen Fehler kann die Prüfung erneut gestartet werden; ein bestätigter Fund wird nicht durch eine Wiederholung freigegeben.

Administratoren können Benutzern Rollen für das Lesen und Verwalten des Archivs sowie für Schutzänderungen und Löschaufträge zuweisen. Prüfer erhalten eine eigene, nur lesende Rolle. Schutz- und Löschrechte müssen ausdrücklich vergeben werden; die allgemeine Administratorrolle enthält sie nicht. Die Rollen können auch über Microsoft Entra ID zugeordnet werden.

Archiv-Rechte von API-Tokens lassen sich in der Token-Verwaltung ändern. Änderungen gelten für neue Anfragen sofort und erscheinen im Änderungsverlauf des Tokens. Bestehende Suchsitzungen werden bei Rechteänderungen ungültig.

Nach bestätigter Archivierung können Fachsysteme die Archiv-ID, den geschützten Download-Link, die Prüfsumme und das früheste Aufbewahrungsende direkt aus nachfolgenden Webhooks oder der Dokument-Abholung übernehmen. Ein neuer Ereignis-Webhook meldet Speicherung, Änderungen des Legal Hold, Abrufe von Freigabelinks und abgeschlossene Löschungen. Fehlgeschlagene Zustellungen werden mit stabiler Ereignis-ID wiederholt. Archivlisten und -suche lassen sich nach Dokument-, E-Mail- und XML-Prozess-ID filtern. Ohne aktiviertes Archiv bleibt die Dokument-Abholung unverändert nutzbar.

Der Dokument-Archiv-Webhook kann nach bestätigter Ablage einer PDF ein separates Anschreiben erzeugen und über einen konfigurierten Binect-Dokument-Webhook verschicken. Der QR-Code führt zu genau dieser unveränderten archivierten PDF; für Empfänger ist kein Output.Rocks-Konto nötig. Der Link ist standardmäßig 30 Tage ab Archivbestätigung gültig, kann auf 1 bis 365 Tage eingestellt und in der Archivdetailansicht widerrufen werden.

Die Funktion bleibt bei bestehenden Webhooks ausgeschaltet. Bei Aktivierung müssen eine Anschreibenvorlage und ein passender Binect-Webhook gewählt werden. Archivierung und Aufbewahrung sind vom Versandstatus und der Linkfrist unabhängig.

Bei neu abgelegten PDFs prüft veraPDF die tatsächliche PDF/A-Konformität. Profil, Ergebnis und fehlgeschlagene Prüfungen sind am Archiveintrag sichtbar. Ein technischer Prüffehler wird getrennt von einem nicht konformen Dokument angezeigt.

Optional kann beim Upload, über die Archiv-API oder im Archiv-Webhook eine zusätzliche PDF/A-3b-Fassung angefordert werden. Sie erhält eine eigene Prüfsumme und denselben WORM-Schutz wie das Original. Die Originaldatei bleibt unverändert und maßgeblich. Auch eine bereits eingebettete Rechnungs-XML wird bytegleich in die zusätzliche Fassung übernommen. Eine fehlgeschlagene Umwandlung wird angezeigt und kann erneut angestoßen werden.

Für die Archiv-API lassen sich jetzt OAuth-2.0-Zugänge mit Client-ID und Geheimnis anlegen. Ein Zugriffstoken gilt zehn Minuten und enthält nur die ausdrücklich gewählten Archiv-Rechte. Auch statische API-Tokens können ablaufen, auf Ablegen, Lesen oder Verwalten begrenzt und mit einer Überlappungszeit gewechselt werden. Bestehende Tokens behalten ihre bisherigen Rechte.

Archiv-Anfragen akzeptieren auth-token in der URL oder im Formular nicht mehr. Senden Sie ein bestehendes API-Token im Header X-AUTH-TOKEN oder verwenden Sie ein OAuth-Zugriffstoken im Header Authorization: Bearer.

Archiv-Trefferlisten lassen sich jetzt als benannte Hold-Vorgänge oder Fristverlängerungen übernehmen. Vor dem Start zeigt die Anwendung die genaue Trefferzahl. Die Verarbeitung läuft je Dokument im Hintergrund; bestätigte Schutzaufträge, offene Schritte und Einzelfehler sind im Vorgang sichtbar und können wiederholt werden.

Beim Aufheben eines Hold-Vorgangs bleiben andere Vorgänge und unabhängig gesetzte Holds auf denselben Dokumenten erhalten. Fristverlängerungen verkürzen keine bestehende Aufbewahrung. Neue Dokumente werden einem bestehenden Vorgang nicht automatisch hinzugefügt.

Treffen ein Hold-Vorgang und eine Fristverlängerung auf dasselbe Archivdokument, kann der Hold jetzt regulär aufgehoben werden. Die verlängerte Aufbewahrungsfrist bleibt erhalten. Weitere Hold-Vorgänge und unabhängig gesetzte Holds schützen das Dokument weiterhin.

In der Archivdetailansicht lassen sich Freigabelinks für das Hauptdokument, XML oder beide Komponenten erstellen, als QR-Link drucken, verlängern, neu ausgeben und widerrufen. Einmal-Links gelten nur wenige Minuten und erlauben genau einen Abruf. Mandanten können Standardlaufzeit, Höchstlaufzeit, Abrufzahl und Zugangscodepflicht festlegen.

Empfänger öffnen eine für Mobilgeräte geeignete Seite in Deutsch oder Englisch mit Absender und Markenbild. Die Datei wird nur nach der bestehenden Archivprüfung ausgeliefert. Vorhandene QR-Anschreiben und ihre bereits ausgegebenen Links bleiben gültig; optional können neue Anschreiben einen Zugangscode und eine Abrufgrenze erhalten.

Die Antwort der Archiv-API liefert zusätzlich eine viewUrl für Menschen. Wer diesen Link ohne Anmeldung öffnet, gelangt nach der bestehenden Anmeldung – auch über Microsoft Entra – zur ursprünglichen Dokumentadresse zurück. Die Ansicht zeigt Kerndaten und bei PDF-Dateien eine Vorschau. Archiv-Leserecht, das aktive Archivmodul sowie Mandanten- und Prüfergrenzen gelten auch für direkte Links und für die Vorschau. Befristete externe Freigabelinks bleiben ein getrennter Zugangsweg.

Im Archiv stehen neben den drei gesetzlichen Klassen eigene Klassen mit Dauer, Fristbeginn, Löschverhalten, Beschreibung und Rechtsgrundlage zur Verfügung. Beim Ablegen kann das Belegdatum über API, Upload oder Archiv-Webhook übergeben werden. Ohne Belegdatum gilt weiterhin der Ablagezeitpunkt.

Ereignisbasierte Klassen halten alle Archivbestandteile geschützt, bis das Ereignis gemeldet wird. Danach wird die Frist berechnet und der technische Hold aufgehoben. Eine bestehende Aufbewahrungsfrist lässt sich nur verlängern. Eine verlängerte Klassenfrist gilt sofort für die Löschprüfung. Die technische Verlängerung bereits abgelegter Bestandteile kann noch ausstehen; die API meldet diese Einträge als ausstehend und kennzeichnet kurze Restfristen ausdrücklich. Bis die technische Verlängerung bestätigt ist, dürfen betroffene Einträge nicht gelöscht werden.

Wenn das Modul „Umgebungs-Mandanten“ aktiviert ist, können Integratoren und Admins des Hauptmandanten beim Erstellen eines API-Tokens einen Umgebungs-Mandanten auswählen. Liste und Detailansicht zeigen die Zuordnung. Ohne Auswahl bleibt das Token beim Hauptmandanten; Tokens werden nicht an andere Umgebungs-Mandanten vererbt.

Die Zuordnung bestimmt den Kontext aller Anfragen mit diesem Token, einschließlich POST /api/renderings. Für einen anderen Kontext wird ein neues Token erstellt; die Zuordnung bestehender Tokens bleibt fest. Die Anmeldung des verwaltenden Benutzers bleibt unverändert.

Custom- und Custom-OAuth2-Webhooks können Metadaten des Rendering Requests in URL, Headern und Payload verwenden. Die verfügbaren Platzhalter und ihre Unterschiede zu Bedingungen, PHP-Mappings, Validatoren und Archiv-Metadaten sind jetzt in einer gemeinsamen Kontextübersicht erklärt.

Für ungültige Prozesse nach einer fehlgeschlagenen Datenvalidierung und blockierte Prozesse nach einem technischen Fehler gibt es acht neue Custom- und Custom-OAuth2-Webhook-Typen für Dokumente und E-Mails. Ihr Fehlerkontext enthält Status, Phase und Fehlermeldung; bei ungültigen Prozessen können auch die Fehlermeldungen der gescheiterten Validatoren übertragen werden. Die Callbacks benötigen keine fertige Datei und ein fehlgeschlagener Callback ändert den ursprünglichen Prozessstatus nicht. Ein blocked-Callback folgt erst nach ausgeschöpften Wiederholungsversuchen, obwohl der Prozess schon vorher als blockiert erscheinen kann. Für die Datenvalidierung muss das Modul beim jeweiligen Mandanten aktiv sein und eine Vorlage Validatoren verwenden.

Beim Prüfen eines Webhooks zeigt die Payload-Vorschau die aufgelöste Anfrage ohne Versand. Ein tatsächlicher Testversand wird ausdrücklich gestartet. Beim Löschen weist die Oberfläche auf noch vorhandene Referenzen hin, damit keine genutzte Konfiguration unbemerkt entfernt wird.

Alle Nutzer können Supporttickets erstellen und ihre eigenen Tickets lesen und beantworten. Nutzer mit der ausdrücklich zugewiesenen Rolle „Admin“ ohne Umgebungs-Mandanten können zusätzlich alle Tickets ihres Kunden lesen, aber fremde Tickets nicht beantworten. Die separate Rolle „Kundensupport-Administrator“ entfällt. Die Supportfreigabe und Nutzerzuordnung müssen eingerichtet sein; Tickets anderer Kunden oder Produkte bleiben unzugänglich.

Bei aktiviertem Umgebungs-Mandanten-Modul können Hauptmandanten-Admins im Benutzerformular einen eigenen Umgebungs-Mandanten auswählen. Eine leere Auswahl ordnet den Benutzer dem Hauptmandanten zu. Liste und Detailansicht zeigen die Zuordnung mit Beschreibung und Farbe.

Admins eines Umgebungs-Mandanten verwalten weiterhin ausschließlich dessen Benutzer und können deren Mandantenzuordnung nicht ändern.

Der CSV-Export der gesperrten Dokumente, E-Mails und Rendering-Aufträge lädt jetzt alle Seiten. Bisher enthielt die Datei höchstens 100 Einträge, auch wenn mehr Treffer vorhanden waren.

Aktive Filter und sichtbare Spalten bleiben erhalten. Auch der Export ungültiger Dokumente berücksichtigt alle Treffer. Schlägt das Laden einer Seite fehl, wird keine unvollständige CSV als erfolgreicher Export ausgegeben.

E-Rechnungen als PDF/A-3 mit eingebettetem XML (ZUGFeRD/Factur-X) bestehen die Konformitätsprüfung wieder, zum Beispiel mit veraPDF. Dieselbe Korrektur wirkt bei allen anderen Dokumenten, die als PDF/A erzeugt werden.

Zuvor meldete die Prüfung Verstöße gegen Abschnitt 6.1.7 der Norm ISO 19005: Vor dem Schlüsselwort endstream fehlte ein Zeilenumbruch, und die Längenangabe einzelner Datenströme wich um ein Byte ab.

Die Korrektur gilt auch für Dokumente mit statischen PDF-Anhängen. Seiteninhalt, Schriften und das eingebettete Rechnungs-XML waren nicht betroffen. Bereits erzeugte Dokumente bleiben unverändert.

Abgelehnte und abgelaufene Vorschläge bleiben im Browser für ihren Eigentümer innerhalb desselben Mandanten bis zum Ende der bestehenden Aufbewahrungsfrist nachvollziehbar. Der Aufräumjob entfernt zuerst alte Vorschläge und anschließend deren nicht mehr benötigte, abgelaufene Sitzungen.

Sitzungsablauf und Widerruf sperren MCP-Zugriffe weiterhin sofort. Eine aufbewahrte Sitzung erlaubt keine erneute Freigabe oder Bearbeitung.

Parallele Aufgaben desselben MCP-Clients können die bereits ausgegebene Tokenantwort innerhalb einer begrenzten Übergangsfrist erneut erhalten. Dabei findet keine weitere Rotation statt; die Antwort enthält die verbleibende Access-Token-Laufzeit. Sitzung, Browseranmeldung, Nutzer, Mandant und Scopes werden erneut geprüft.

Die Standardfrist beträgt 60 Sekunden. Betrieblich kann sie über MCP_REFRESH_RETRY_GRACE_SECONDS auf 0 bis 60 Sekunden eingestellt werden; 0 deaktiviert die Ausnahme. Ältere Tokens, falsche Clients und Wiederholungen ab Ablauf der Frist bleiben durch den Replay-Schutz gesperrt. Antworten werden verschlüsselt aufbewahrt und nach Ablauf bereinigt.

Nach einer neuen Anmeldung zeigen offene Arbeiten die Werkzeuge zum direkten Verwerfen an. close_template_edit entfernt den eigenen Entwurf mit seinen temporären Dateien. release_artifact räumt eine eigene Datei auf; gehört sie zu einem offenen Entwurf einer früheren Verbindung, wird dieser gemeinsam verworfen. Laufende Operationen müssen zuerst beendet sein.

Die neue Verbindung muss aktiv sein und mcp:files besitzen. Nutzer und Mandant müssen übereinstimmen. Lese- und Bearbeitungsrechte bleiben an die ursprüngliche Verbindung gebunden; gespeicherte Vorlagen werden durch das Aufräumen nicht verändert.

Die vorhandene Anleitung beschreibt den zusammenhängenden Weg von der eindeutigen Vorlagen- und Testfallauswahl über Textänderung oder geschützten Dateitransfer bis zum Vergleich und zur ausdrücklichen Browserfreigabe. Erfolgreiches Rendering ist weiterhin keine Sichtprüfung. Die Wiederaufnahme erklärt neue Datei-IDs, aktuelle Quellenrechte und unveränderte Aufbewahrungsfristen.

Die dokumentierte Grenze für sämtliche MCP-Eingaben zusammen beträgt 64 KiB. Größere Vorlagenkontexte werden abschnittsweise gelesen; die bisherige pauschale 2-MiB-Kontextgrenze entfällt aus der Anleitung. Technische Grenzen und Berechtigungen werden dadurch nicht verändert. Werkzeugbeschreibungen bereits früher produktiv freigegebener Funktionen tragen keinen veralteten Staging-Hinweis mehr.

Die Anleitung unterscheidet den kompakten Vergleichsstatus von den vollständigen, prüfsummengebundenen Vorschlagsinhalten. Vorschauseiten werden erst nach Abschluss aller Vergleichsschritte geprüft; ein belegter Bearbeitungslock erfordert keinen neuen Renderauftrag. Vollständig geladene Seiten bleiben während des Kontextladens vorgemerkt; Fallbestätigung und Übernahme warten auf den vollständigen Kontext. Der Dateiweg erklärt die Bindung an die ursprüngliche Browser-Sitzung und die ausdrückliche Wiederaufnahme nach einer neuen OAuth-Verbindung.

Noch keine Gesamtfreigabe: Die finale native Codex-Abnahme steht am 2. Oktober 2026 bei 0 von 5 aufeinanderfolgenden vollständigen Durchläufen. Historische Einzelbelege vom 16. September bleiben erhalten. Die installierte Codex-App hat Version 26.930.21537; die finale Prüfung dieses Clients steht aus. Claude wird unabhängig in OR-244 geprüft und blockiert weder Codex-Abnahme noch Produktionsrelease. Copilot bleibt ungeprüft. Frühere Produktionsfreigaben gelten für ihren damaligen Umfang. Separate Produktionsfreigabe und Live-Verifikation bleiben erforderlich.

Die Anleitung ergänzt das ausdrückliche Verwerfen eigener temporärer Arbeit nach Neuanmeldung, die bestehende Aufbewahrung von Vorschlägen nach Sitzungsablauf und die auf höchstens 60 Sekunden begrenzte Wiederholung paralleler Token-Erneuerungen. Ablauf, Widerruf, aktuelle Rechte und Mandantenbindung bleiben wirksam.

Beim Übernehmen einer vorhandenen Konfiguration führt der Import deren Versionskette weiter. Das gilt auch dann, wenn Aktivstatus oder Gültigkeitsbeginn auf der Quellumgebung abweichen. Frühere Vorlagendateien bleiben erhalten; ein identischer erneuter Import erzeugt keine zusätzliche Version.

Aktivierungsoptionen werden vor der Versionsbildung angewandt. Vergangene Zeitpunkte aus dem Export schreiben die Historie der Zielumgebung nicht rückwirkend um. Neue Identifier werden weiterhin angelegt.

Existieren mehrere offene Ketten oder eine geplante Version für denselben Identifier, stoppt der Import mit einem Hinweis zur Klärung. Auch doppelte logische Einträge innerhalb einer ZIP-Datei werden zurückgewiesen.

Wenn eine E-Mail-Vorlage ein Dokument als PDF-Anlage rendert, enthält dessen Vorschau jetzt auch die statischen PDF-Seiten der Dokumentvorlage. Das gilt ebenfalls für die Vorschau-EML, den Testversand und die Rendering-Request-Vorschau. Die festgelegte Reihenfolge und Gruppenbedingungen bleiben erhalten.

Ein Fachsystem kann Individualschreiben mit einem Link wie /renderings/input-mask?identifier=angebot&id=123456 öffnen. Konfigurierte Webhooks laden die Daten für diese ID. Die Gruppenkennung und die Bedingung der Eingabemaske entscheiden, ob die Maske direkt öffnet oder eine Auswahl angezeigt wird. Felder werden aus den geladenen Daten vorbelegt; fehlende Pflichtfelder müssen ergänzt werden, bevor die Vorschau gestartet wird.

Die Vorschau bleibt bis zur Freigabe gespeichert. Änderungen am Formular erfordern eine neue Vorschau. Bearbeitete E-Mails und aus SharePoint zurückgeladene Dokumente gehören zum freizugebenden Stand. Erst nach Individualschreiben erstellen laufen Versand und nachgelagerte Webhooks. Der Abschluss zeigt Warte- und Fehlerzustände und bietet nach erfolgreicher Verarbeitung Dokumente als PDF sowie E-Mails als EML, HTML und PDF zum Download an.

Im Tab Statische PDF-Anhänge zeigt eine nummerierte Liste die Reihenfolge der ausgewählten Anhänge. Mit Nach oben und Nach unten lässt sich festlegen, in welcher Folge sie hinter dem gerenderten Dokument erscheinen. Die Reihenfolge bleibt nach dem Speichern erhalten; ausgeschlossene Anhänge werden übersprungen.

In E-Mail-Inhalten und Grundgerüsten können Vorlagenentwickler einzelne Text- und Bildbereiche freigeben. Kunden bearbeiten diese Bereiche anschließend visuell und fügen geeignete Standardwerte und Komponenten über eine Suche ein. Der übrige HTML-Quelltext bleibt erhalten; Bedingungen, Schleifen und Vorlagenverweise bleiben der HTML-Ansicht vorbehalten. Die neue Vorschau rendert den ungespeicherten Stand mit Grundgerüst und ausgewählten Testdaten. Die HTML-Ansicht und die bestehende E-Mail-Testansicht stehen weiterhin zur Verfügung.

Beim Testen von Dokument-Vorlagen werden große PDFs jetzt zuverlässig angezeigt. Das behebt die leere Vorschau, die in Chrome insbesondere bei aktiviertem Legacy-Rendering auftreten konnte, obwohl das Dokument erfolgreich erzeugt wurde.

Die Korrektur gilt auch beim Anwenden und Zurücksetzen eines PDF-Overlays.

Umgebungs-Mandant löschen meldete in der Oberfläche einen Serverfehler, obwohl der Mandant gelöscht wurde. Dabei blieben seine API-Tokens, Benutzer, Einstellungen und Standardwerte zurück. Hatte der Mandant eigene Marken, Zugangsdaten, Datenmapping-Regeln, QR-Codes oder Overlays, ließ er sich weder in der Oberfläche noch über die API löschen.

Oberfläche und API löschen jetzt auf dieselbe Weise: Mit dem Umgebungs-Mandanten werden seine eigene Konfiguration, seine Einstellungen, API-Tokens und Benutzer entfernt. Elemente des Hauptmandanten und anderer Umgebungs-Mandanten bleiben unberührt. Hat der Mandant bereits etwas verarbeitet, etwa Render-Anfragen, Berichte oder Importe, lehnen beide das Löschen mit dem Grund ab (HTTP 400) statt mit einem Serverfehler.

Für jeden statischen Anhang lässt sich jetzt festlegen, ob er direkt an das bisherige PDF angefügt wird oder auf einer ungeraden Seite beginnen soll. Im zweiten Fall zählt Output.Rocks die tatsächlich zusammengestellten Seiten einschließlich vorheriger Anhänge. Würde der nächste Anhang auf einer geraden Seite beginnen, wird genau eine Leerseite eingefügt.

Bestehende und neue Anhänge verwenden weiterhin standardmäßig Direkt anhängen. Die Einstellung gilt nur für statische PDFs in Dokument-Vorlagen. Separate E-Mail-Anhänge bleiben unverändert; statische Anhänge und Leerseiten werden weiterhin nicht als abrechnungsrelevante Seiten gezählt.

Im Test einer E-Mail-Vorlage kann der aktuell bearbeitete HTML-Quelltext jetzt direkt als neue Vorlagenversion gespeichert werden. Die neue Version wird wahlweise sofort oder zu einem zukünftigen Zeitpunkt in der angezeigten lokalen Zeitzone wirksam.

Gespeichert wird ausschließlich der Quelltext. Testdaten, Vorschauparameter, Bedingungen und alle weiteren Einstellungen der Vorlage bleiben unverändert. Nach dem Speichern zeigt die App die neue Versionsnummer und den Gültigkeitsbeginn an; bisherige Versionen bleiben in der Versionshistorie erhalten.

Der Schalter Standard für Umgebungs-Mandanten war bei Datenmapping-Regeln bisher ohne Wirkung: Umgebungs-Mandanten führten nur ihre eigenen Regeln aus, jede gemeinsame Regel musste je Umgebungs-Mandant kopiert werden. Jetzt laufen markierte Regeln des Hauptmandanten auch für die Rendering-Requests der Umgebungs-Mandanten – in der Anfrage-Strecke wie in der Request-Simulation, die geerbte Regeln als Umgebungs-Standard kennzeichnet.

Hat ein Umgebungs-Mandant eine eigene aktive Regel mit gleichem Namen, läuft weiterhin nur diese. Bereits angelegte Kopien laufen dadurch nicht doppelt. Bei gleicher Priorität läuft die geerbte Regel vor der eigenen. Regeln ohne den Schalter und Requests des Hauptmandanten verhalten sich unverändert.

Webhooks bieten im Details-Tab jetzt wie Vorlagen und Standardwerte die Felder Umgebungs-Mandant und Standard für Umgebungs-Mandanten; die Liste zeigt dazu die passenden Spalten. Ein als Standard markierter Webhook des Hauptmandanten wird auch für die Rendering-Requests der Umgebungs-Mandanten ausgeführt, etwa ein zentral gepflegtes E-Rechnungs-Mapping. Ein eigener Webhook des Umgebungs-Mandanten mit gleichem Identifier hat weiterhin Vorrang.

Nutzer eines Umgebungs-Mandanten sehen geteilte Webhooks als Umgebungs-Standard, können sie aber weder ändern noch löschen; maskierte Zugangsdaten bleiben für sie maskiert. Das Umschalten erzeugt wie jede Änderung eine neue Version des Webhooks.

Webhooks bleiben die bevorzugte Zustellung. Für Systeme, die ausschließlich ausgehende HTTPS-Verbindungen aufbauen können, lässt sich nun pro Mandant oder Untermandant eine Abholschnittstelle aktivieren.

Fertige Dokumente und eigenständige E-Rechnungs-XMLs erhalten dann einen zeitlich begrenzten Zustellnachweis mit stabiler ID, Dateigröße und SHA-256-Prüfsumme. Der Abholer lädt die Datei vollständig, prüft sie lokal und bestätigt die dauerhafte Übernahme anschließend mit einem idempotenten ACK. Offene Nachweise bleiben auch bei einem verlorenen Cursor auffindbar; die reguläre Anonymisierungsfrist wird durch Polling oder ACK nicht verlängert.

Nicht aktivierte Mandanten erzeugen keine zusätzlichen Zustellmetadaten. Eine Deaktivierung stoppt neue Nachweise sofort, während vorhandene offene Lieferungen regulär auslaufen. Bestehende Webhooks werden nicht verändert und können parallel weiterlaufen.

Platzhalter in Diagrammkonfigurationen wurden bisher nur gegen die Daten der Anfrage aufgelöst. Ein <<standard.diagramm_farbe_1>> brach deshalb mit „Failed to resolve placeholder“ ab; Standardwerte ließen sich nur über eine Datenmapping-Regel in die Anfragedaten kopieren, und die greift im Vorlagen-Test nicht.

Jetzt stehen in Diagrammen dieselben Standardwerte (<<standard.…>>), Komponenten (<<component.…>>) und or-Werte wie <<or.requestDateClientTimezone>> zur Verfügung wie in der Vorlage – für den Mandanten, den Umgebungs-Mandanten und die Marke, für die gerendert wird. So lassen sich etwa Diagrammfarben je Umgebungs-Mandant als Standardwerte pflegen. Das gilt gleichermaßen im Rendering, im Vorlagen-Test und Vorlagen-Editor, in der Request-Simulation und in der Vorschau des Diagramm-Editors; dort gelten der gewählte Umgebungs-Mandant und die Marke des bearbeiteten Diagramms.

Enthält eine Anfrage selbst Werte unter diesen Schlüsseln, gilt wie in der Vorlage der Wert der App; zusätzliche Schlüssel der Anfrage bleiben erhalten. Bilder, Root-Level-Komponenten und andere Diagramme sehen Diagramme weiterhin nicht, damit gleichnamige Anfragedaten nicht überdeckt werden. Bestehende Konfigurationen, auch solche mit Datenmapping-Regeln, arbeiten unverändert weiter.

Im Test von E-Mail-Vorlagen werden Diagramme und QR-Codes der Anhänge außerdem in der Marke der E-Mail aufgelöst – wie beim Versand.

Die Webhook-Typen custom-email und custom-oauth2-email boten den gerenderten E-Mail-Body bisher nur base64-codiert an (<<email.html.base64File>>). Für Zielsysteme, die die E-Mail anschließend selbst versenden, war das unbrauchbar: Ein Ticketsystem, das daraus einen ausgehenden Artikel anlegt, erwartet das Markup und keine Datei.

Neu steht dafür <<email.html.content>> zur Verfügung - das rohe HTML, wie es auch die SharePoint- und Dropbox-Webhooks schon übergeben. Zusammen mit dem Weglassen von emailServer im Request, das den Versand durch Output.Rocks überspringt, lässt sich eine E-Mail damit vollständig rendern und die Zustellung einem anderen System überlassen.

Vorab-Aufrufe auf Ebene des Rendering-Requests gab es bisher nur als prerender-custom-oauth2-request, also mit OAuth2-Anmeldung. Für APIs hinter einem festen Token - viele Ticketsysteme arbeiten so - war der Typ nicht nutzbar.

Neu steht prerender-custom-request zur Verfügung. Er läuft zum selben Zeitpunkt, einmal je Request vor der Auflösung von Vorlagen und E-Mails, nutzt aber gewöhnliche Header. Damit lässt sich zum Beispiel zuerst ein Ticket anlegen und dessen Nummer anschließend im Betreff der E-Mail verwenden, während Output.Rocks die Mail weiterhin selbst rendert und versendet.

Die Antwort wird wie bei den übrigen Vorab-Webhooks über responseDataKey in den Renderdaten abgelegt und steht danach in Bedingungen, Betreff, Empfängerauflösung und allen folgenden Prozessen bereit.

Bei der Bearbeitung von Dokument-Vorlagen zeigt die Auswahl statischer PDF-Anhänge jetzt Dateiname und Marke an. Der Markenfilter bleibt dabei vollständig sichtbar und kann per Tastatur bedient werden.

Statische Anhänge können aus der Übersicht, der Detailansicht und der Versionshistorie heruntergeladen werden. PDFs werden direkt in der Detailansicht angezeigt. Bei anderen Dateiformaten weist die Oberfläche auf den Download hin. In der Historie beziehen sich Vorschau und Download immer auf die ausgewählte Version und verwenden deren gespeicherten Dateinamen.

Die Detailansicht eines Rendering-Berichts zeigt den ausgewerteten Zeitraum einschließlich lokaler Zeitzone. Zeiträume ohne Dauer oder mit vertauschten Grenzen werden bereits bei der Eingabe abgewiesen. Außerdem funktioniert die Sortierung der Testdaten-Tabelle wieder für ID, Name sowie Erstellungs- und Änderungszeitpunkt.

Der KI-Assistent im Diagramm-Editor fordert Änderungen jetzt mit einem verbindlichen Antwortformat an. Dadurch führen Anführungszeichen in deutschen Erläuterungen nicht mehr zu ungültigen Antworten. Auch umfangreiche Chart.js-Konfigurationen werden vollständig berücksichtigt.

Kann eine Antwort wegen ihrer Größe oder eines vorübergehenden KI-Fehlers nicht verarbeitet werden, zeigt der Editor eine passende Meldung. Vor der Übernahme prüft Output.Rocks weiterhin Platzhalter und die renderbare Vorschau des Entwurfs.

Beim erneuten Versuch mit Retry-Zeitpunkt verwenden noch offene Webhooks jetzt die zum gewählten Zeitpunkt gültige Konfigurationsversion. So greifen beispielsweise korrigierte Zugangsdaten auch bei bereits blockierten Dokument- und E-Mail-Prozessen. Das gilt für Einzel- und Sammelaktionen sowie das Prozesskontrollzentrum.

Bereits erfolgreich ausgeführte Webhooks, erzeugte Dokumente und der Versandstatus bleiben erhalten. Zugestellte E-Mails werden dadurch nicht erneut versendet. Beim Wechsel zurück auf Originaler Request-Zeitpunkt werden offene Webhooks wieder anhand des ursprünglichen Zeitpunkts aufgelöst. Versionswechsel sind im Prozessprotokoll nachvollziehbar.

Alle versionierbaren Konfigurationen zeigen jetzt getrennt, welche Version die neueste ist, ob sie aktiviert ist und ob sie derzeit zur Verarbeitung verfügbar ist. Eine deaktivierte neuere Version bedeutet nicht automatisch, dass ältere aktivierte Versionen nicht mehr verfügbar sind. Listen und Versionshistorie heben verfügbare Versionen mit einem grünen Badge und Häkchen hervor. In Listen steht dieser Hinweis vor dem Status der angezeigten Version.

Geplante Versionen zeigen ihren Startzeitpunkt und ihre Aktivierungseinstellung. Fehlt ein Enddatum, wird dies als Kein Enddatum angezeigt. Lässt sich der Status nicht laden, erscheint eine Fehlermeldung mit der Möglichkeit, die Abfrage zu wiederholen.

Verfügbar bedeutet aktiviert und im gültigen Zeitraum. Ob eine Version tatsächlich verwendet wird, hängt zusätzlich von Marke, Untermandant, Bedingungen, Prioritäten und gegebenenfalls dem Ausführungszeitplan ab. Die Verarbeitung selbst bleibt unverändert.

Ein Vergleich rendert je Testfall zwei PDFs und belegt die Bearbeitungssitzung dabei in kurzen Abständen immer wieder. Fiel das Lesen einer Vorschauseite in eines dieser Zeitfenster, wurde es mit CONFLICT und dem Hinweis auf eine belegte Bearbeitungssitzung abgewiesen, obwohl das angeforderte PDF längst fertig war. Dieselbe Seite war unmittelbar davor oder danach lesbar, was die geforderte Sichtprüfung aller Seiten unnötig unterbrach.

Das Lesen einer Seite eines bereits fertigen Vorschau-PDFs ändert nichts an der Bearbeitungssitzung und wartet deshalb nicht mehr auf eine laufende Operation. Die Seitenzahl- und Seitenmaßabfrage verhält sich unverändert.

Alle Prüfungen bleiben bestehen: Verbindung, Zustimmungen, Rolle, Mandant, Eigentümer der Bearbeitungssitzung, Ablaufzeiten und die Bindung des PDFs an genau diese Sitzung werden vor und nach der Bildausgabe geprüft. Schreibende Operationen bleiben unverändert abgewiesen, solange die Bearbeitungssitzung belegt ist; das gilt auch für die Seitenvorschau mit einem temporären Vergleichs-PDF als Überlagerung, weil sie das gemerkte Artefakt in der Bearbeitungssitzung festhält.

Im Dialog E-Rechnung bearbeiten enthält der Abschnitt Zahlung jetzt IBAN, BIC, Kontoinhaber, Zahlungsart und Zahlungsbedingungen. Eine wegen ungültiger IBAN ausgesteuerte Rechnung können Sie damit direkt im Formular korrigieren.

Speichern & neu erzeugen übernimmt die korrigierten Daten und startet die Erzeugung und Validierung erneut. Weitere Rechnungs- und Zahlungsdaten bleiben erhalten. Formular und erweiterte JSON-Ansicht übernehmen Änderungen gegenseitig.

Remote-Zugriffe auf Vorlagen, Bilder und MCP-Dateien verwenden jetzt Zeitgrenzen auch beim Öffnen von Streams und beim Löschen. Die bestehenden strengeren MCP-Einstellungen für einzelne Anfragen bleiben erhalten.

Vorlagen und Bilder werden vor der Übergabe an einen Download vollständig gelesen. Ein abgebrochener oder unvollständiger Transfer führt zu einem Fehler, bevor eine erfolgreiche Downloadantwort beginnt. Bestehende Größen- und Prüfsummenkontrollen für MCP-Dateien bleiben unverändert.

Die HTTP-Zeitgrenzen begrenzen einzelne Speicherzugriffe. Sie sind keine maximale Laufzeit für einen gesamten Vergleichsauftrag; die Lesezeitgrenze gilt je Lesevorgang. Für diese beiden Downloadpfade wird die Datei vorübergehend vollständig im Speicher gehalten, bevor ein temporärer Stream bereitsteht. Die Änderung betrifft weder Archivdateien noch andere gemeinsam genutzte S3-Zugriffe.

Wird eine MCP-Verbindung wegen eines bereits verbrauchten Anmeldecodes oder Refresh-Tokens widerrufen, hält das Auditprotokoll nach erfolgreicher Speicherung den Grund, die Grant-Art, die Verbindungs-ID und einen Hash der registrierten Client-ID fest. Tokenwerte, Tokenhashes und persönliche Angaben werden dabei nicht protokolliert.

Der Schutz vor wiederverwendeten Anmeldedaten bleibt unverändert: Die Verbindung wird widerrufen, und die Anfrage wird weiterhin mit invalid_grant abgewiesen. Ist die Verbindung beim Prüfen bereits widerrufen, entsteht kein neuer Widerrufseintrag. Auch ein Fehler beim Schreiben des Auditprotokolls verändert diese Sicherheitsentscheidung nicht.

Bei Vergleichen mit mehreren Testfällen verwenden die Vorschau-PDFs dieselben Original- und Entwurfsdateien. Innerhalb einer vollständigen Vergleichsprüfung werden diese gemeinsamen Quellen einmal vollständig gelesen und anhand ihrer Prüfsumme geprüft. Dadurch entfallen wiederholte vollständige Lesezugriffe für jedes Vorschau-PDF.

Jedes Pflicht-PDF wird weiterhin vollständig geprüft. Rechte, Ablaufzeiten, Quellbindungen und verwendete Abhängigkeiten bleiben Bestandteil der Prüfung. Ändert sich eine bereits geprüfte Quellbindung oder der Vergleich währenddessen, wird die Prüfung abgewiesen. Jede neue Anfrage und jede erneute Prüfung beim Speichern beginnt ohne übernommene Prüfnachweise. Der direkte Zugriff auf einzelne Artefakte behält seine vollständigen Prüfungen.

Beim Erstellen eines Freigabevorschlags werden die PDF-Seiteninformationen direkt aus den bereits vollständig geprüften Dateien ermittelt. Das erste Vergleichspaar wird für die bisherige Einzelansicht wiederverwendet. Eine ungenutzte DOCX-Ausgabe für das spätere Speichern entfällt.

Vor dem Veröffentlichen bleibt eine zweite, unabhängige Prüfung aller ausgewählten Fälle, PDFs, Abhängigkeiten und der aktiven Vorlage bestehen. Änderungen an den Dateien, Ablaufzeiten oder Berechtigungen verhindern den Vorschlag. Die Schreibberechtigung wird nach dem Aktualisieren der Verbindung erneut kontrolliert, auch beim Bestätigen und Speichern. Die tatsächliche Speicherung behält ihre eigenen Prüfungen unter der Speichersperre.

Textentwürfe und serverseitig erzeugte PDF-Vorschauen speichern ihre bereits vollständig vorliegenden Dateien in einem gemeinsamen Schreibvorgang. Bei größeren Dateien entfällt dadurch das wiederholte vollständige Lesen der Quelldatei für jeden 16-KiB-Block. Die benötigten Speicherzugriffe wachsen mit der Dateigröße.

Sitzung, Rechte, Quellen, Prüfsummen und Ablaufzeiten werden vor und nach der Übertragung geprüft. Ändern sich diese Voraussetzungen oder schlägt ein Schreiben fehl, wird kein erfolgreicher Upload bestätigt. Die abschließende DOCX-Prüfung bleibt erhalten. Manuelle Datei-Uploads, Archiv- und Exportdownloads sowie die Wiederaufnahme behalten ihren bisherigen Ablauf. Eine feste Gesamtlaufzeit wird hierdurch nicht zugesichert.

Die Browserprüfung lädt Original, Entwurf und Überlagerung einer Seite gemeinsam. Alle Pflicht-PDFs und verwendeten Abhängigkeiten werden weiterhin geprüft. Innerhalb dieses Abrufs werden die bereits geprüften Dateien für die Bilder wiederverwendet; eine ungenutzte DOCX-Ausgabe für das spätere Speichern entfällt.

Nach der Bilderzeugung werden die aktuellen Rechte, Ablaufzeiten, Dateibindungen, der Vergleich und die aktive Vorlage erneut kontrolliert. Bei einer ungültigen Prüfung wird kein Teil der Bildgruppe ausgeliefert. Jeder weitere Seitenabruf beginnt mit einer neuen vollständigen Prüfung.

Die visuelle Bestätigung wird erst möglich, wenn alle erforderlichen Bilder und der Vorlagenkontext geladen sind. Das Speichern behält seine unabhängigen Prüfungen und übernimmt weiterhin exakt den bestätigten Entwurf.

Neu fertiggestellte temporäre Dateien erhalten eine unveränderliche vollständige Dateikopie. Dadurch benötigen auch große Vorlagen beim Vergleich und Speichern keinen separaten Speicherabruf für jeden übertragenen Teil. Jede Prüfgrenze kontrolliert weiterhin den vollständigen Dateiinhalt und seine Prüfsumme sowie Berechtigungen, Ablaufzeiten, Quellen und alle erforderlichen Vergleichsergebnisse. Die Prüfung unter der tatsächlichen Speichersperre bleibt unabhängig bestehen.

Nach einem Verbindungsabbruch zeigt der Browser den Speicherausgang als unklar an. Über Speicherstatus prüfen lässt sich eine später abgeschlossene Änderung feststellen. Solange der Ausgang offen ist, bleibt ein erneutes Speichern gesperrt; es erfolgt keine automatische Wiederholung. Das gilt auch beim Öffnen aus der Liste: Nach einem Neuladen bleibt die einzelne Änderung erreichbar, wenn sie inzwischen abgeschlossen oder abgelaufen ist und deshalb nicht mehr in der offenen Liste steht.

Beim Bereitstellen von Downloads werden nach dem Schreiben auch geänderte Mandanten- und Untermandantenzuordnungen sowie entzogene Archiv- oder Exportrechte berücksichtigt. Eine inzwischen unzulässige Quelle wird nicht als fertige Datei freigegeben.

Für den Betrieb: Vorhandene Dateien bleiben im bisherigen Teilformat lesbar. Fehlende oder beschädigte vollständige Kopien werden abgewiesen. Die Teile bleiben für einen Rückwechsel der Anwendung erhalten; dadurch steigt der tatsächliche Speicherbedarf dieser Dateien auf ungefähr das Doppelte. Die logische Dateiquote zählt jede Datei weiterhin einmal. Ablauf und Bereinigung entfernen beide Darstellungen. Beim Rückwechsel bleiben die additive Formatspalte und die Dateien erhalten; ein Lesezugriff führt keine Migration aus.

Beim Lesen temporärer MCP-Dateien aus dem Remote-Speicher gilt pro Anfrage eine Verbindungsgrenze von fünf Sekunden und eine Übertragungsgrenze von 15 Sekunden. Der Speicherzugriff darf einen fehlgeschlagenen Versuch einmal wiederholen. Bei anhaltenden Lesefehlern erscheint der vorhandene Dateilesefehler; die Vorschau kann anschließend erneut angefordert werden.

Diese Grenzen gelten für die einzelnen Speicheranfragen, nicht für die gesamte Vorschau mit mehreren Dateiblöcken. Andere Dateispeicher und der globale S3-Client bleiben unverändert. Entwürfe, Prüfergebnisse und Freigabebindungen ändern sich dadurch nicht. Die beobachtete lange Vorschauantwort allein belegt keinen bestimmten Speicher- oder Netzwerkfehler.

prepare_template_edit zeigt die konkrete Vorlagenversion, Vorschaumarke, Untermandant und Zuordnungen sowie benannte, durchsuchbare Testdaten zur Auswahl. Mehrere Treffer erfordern eine ausdrückliche Auswahl.

Vorschauen können gespeicherte Testdaten, direkt übergebenes JSON oder eine finalisierte JSON-Datei verwenden. Temporäre Daten bleiben im Entwurf. Kleine Kontexte sind direkt lesbar; größere bleiben vollständig abrufbar. Rechte und Ablaufzeiten gelten während der gesamten Bearbeitung.

Der vollständige aktivierte Werkzeugkatalog steht bereits in der ersten tools/list-Antwort. Bisher lagen drei Werkzeuge auf einer zweiten Seite; Clients ohne weitere Seitenabfrage konnten dadurch die Importvorschau, den Importvorschlag und die Vorlagenfreigabe nicht finden.

Die Werkzeugausführung prüft weiterhin die nötigen Scopes, Rollen und Objektberechtigungen. Die vollständige Anzeige erteilt keine zusätzlichen Rechte und ersetzt weder die Clientabnahme noch die ausdrückliche Browserfreigabe.

Vergleichsläufe liefern pro Original und Entwurf weiterhin Status, PDF-Artefakt und Prüfsummen. Die vollständigen aufgelösten Rendering-Eingaben werden nicht mehr bei jeder Statusabfrage erneut übertragen. Das gilt auch für bereits gespeicherte Läufe und wiederholte Vergleichsaufträge mit derselben Request-ID.

Die vollständigen Versionen und Dateiprüfsummen bleiben im Vergleich und in der Browserfreigabe gebunden. Nach dem Freigabevorschlag sind sie über get_pending_change_content vollständig und in begrenzten Blöcken abrufbar. Große Vorschläge und deren Status wechseln anhand der tatsächlichen MCP-Antwortgröße auf diesen vorhandenen Detailzugriff. Die Aktualitätsprüfung vor der Freigabe bleibt unverändert.

Die Belege beschreiben die aufgelösten, an das Rendering übergebenen Eingaben. Ob ein Eingang tatsächlich im PDF sichtbar wird, muss weiterhin visuell geprüft werden.

Der vorhandene Freigabedialog zeigt alle ausgewählten Testfälle mit Original, Entwurf und transparenter Überlagerung. Neue und entfernte Seiten sind markiert; aufgezeichnete Textänderungen werden zusammengefasst. Externe DOCX-Bearbeitungen weisen ausdrücklich auf die Grenzen der Textzusammenfassung hin.

Jeder Testfall benötigt eine ausdrückliche visuelle Bestätigung aller Seiten. Die Übernahme bindet genau den geprüften Entwurf und sämtliche Vergleichsergebnisse. Geänderte Quellen, Berechtigungen oder Abhängigkeiten verhindern das Speichern. Die bestehende Vorlagenversionierung, Ablehnung und einmalige Anwendung bleiben erhalten.

Das neue Werkzeug get_mcp_context zeigt Serveradresse, Mandant und Untermandant, gewährte Scopes, aktivierte Module und Ablaufzeit der Verbindung. Fehlende Scopes werden einzeln genannt; Rollen-, Modul-, Konflikt- und Ablaufprobleme erhalten konkrete nächste Schritte.

Die Serverhinweise erklären die Testdatenauswahl über list_entities und den Vorlagenablauf bis zur Vorschau. Ein reiner Testauftrag erzeugt keinen Speichervorschlag. Die Anleitung unterscheidet außerdem vom Client blockierte Werkzeuge von fehlenden Serverrechten. Aktive Vorlagen und bestehende Freigaberegeln bleiben unverändert.

Die neuen Werkzeuge find_template_text und replace_template_text zeigen Texttreffer mit Kontext und ändern nur ausdrücklich ausgewählte Stellen. Das Ergebnis ist ein unveränderlicher Entwurf mit Dateihash und Zusammenfassung; die aktive Vorlage bleibt erhalten.

Wiederholte identische Aufträge liefern denselben Entwurf. Geschützte Bereiche, veraltete Quellen und widersprüchliche Aufträge werden abgewiesen. Der Entwurf kann anschließend mit den bestehenden Werkzeugen gerendert, visuell geprüft und zur Browserfreigabe vorgelegt werden. Rechte und Ablaufzeiten gelten auch für abgeleitete Entwürfe.

MCP-Assistenten können bis zu fünf unveränderliche Testfälle für eine Vorlagenbearbeitung auswählen. Der Vergleich erstellt für jeden ausgewählten Fall PDFs von Original und Entwurf mit denselben Daten und demselben Zeitpunkt. Der Fortschritt ist sofort abrufbar; Fehler einzelner Schritte bleiben sichtbar.

Die Ergebnisse enthalten geprüfte Quellen und Abhängigkeiten. Veraltete Vergleiche werden erkannt, unklare Renderaufträge nicht automatisch wiederholt. Ein gemeinsames Speicherbudget begrenzt die Ausgaben; geschützte Vorschauen und die vorhandene Overlay-Funktion unterstützen die anschließende visuelle Prüfung.

Die aktive Vorlage wird dabei weder gespeichert noch aktiviert.

Beim Laden des Prüfkontexts werden nicht mehr für jeden Abschnitt sämtliche Vergleichsdateien und Rendering-Abhängigkeiten erneut gelesen. Rechte, Verbindung, Aufbewahrungsfrist und Zuordnung zur Vorlage werden weiterhin geprüft. Die vollständige Aktualitätsprüfung der Vorschaubilder und beim Speichern bleibt erhalten.

Bereits vollständig angezeigte Seiten bleiben für die visuelle Prüfung vorgemerkt, auch wenn der Kontext noch lädt. Die ausdrückliche Bestätigung eines Testfalls und die Freigabe bleiben gesperrt, bis der Kontext vollständig geladen ist und alle Pflichtseiten geprüft wurden. Fehler setzen die Prüfbestätigungen weiterhin zurück.

Unter MCP-Verbindungen → Dateien lassen sich temporäre Dateien direkt im Browser herunterladen und hochladen. Die App prüft Größe und SHA-256-Prüfsumme. Unterbrochene Uploads können mit derselben Datei fortgesetzt werden; bereits empfangene Blöcke bleiben erhalten. Fertige Dateien werden vor der Verwendung auf Format und Inhalt geprüft.

Der Dialog zeigt Fortschritt, Ablauf und belegten temporären Speicher. Es gelten weiterhin 10 MiB je Datei sowie 100 Dateien und 64 MiB je Nutzer und Mandant. Dateien bleiben an die ursprüngliche Verbindung und Browseranmeldung gebunden. Der Upload allein verändert keine aktive Vorlage und ersetzt keine Freigabe.

MCP erhält geschützte Dialoglinks und kann mit get_artifact_status den aktuellen Stand beziehungsweise die Dateien der eigenen Verbindung abrufen. Die bisherigen Blockwerkzeuge bleiben für programmatische Clients verfügbar; Binärdateien müssen nicht durch das Sprachmodell rekonstruiert werden.

Offene MCP-Vorlagenarbeiten sind mit Namen, Testfällen, Dateien und Ablaufzeit auffindbar. Dieselbe Verbindung verwendet vorhandene IDs weiter. Nach einer neuen Anmeldung zeigt ein Browserdialog die benötigten Eingaben; erst die ausdrückliche Bestätigung erstellt geprüfte Kopien mit neuen IDs.

Aktuelle Berechtigungen, Quoten und ursprüngliche Aufbewahrungsfristen gelten auch für die Übernahme. Der Renderzeitpunkt bleibt erhalten. Vorschauen, Vergleiche und Freigaben werden neu erstellt; alte Verbindungen werden nicht reaktiviert.

Mit der Bereichsauswahl oder einem Klick auf einen Bereichs-Tag sehen Sie nur die passenden Release Notes. Die Auswahl bleibt beim Neuladen erhalten und lässt sich über die URL teilen.

Ein erneuter Klick auf den aktiven Tag oder Alle anzeigen zeigt wieder sämtliche Einträge. Einheitliche Bereichsnamen, klar getrennte Tags und ein passendes Inhaltsverzeichnis erleichtern die Orientierung.

Mit der erweiterten Anonymisierung vom 10. September entfernt die Anonymisierung eines E-Mail-Prozesses neben dem HTML-Text auch Empfänger, Kopie- und Blindkopieempfänger, Antwortadresse, Absendername, Betreff, die Textfassung, die zusätzlichen Angaben und die gespeicherte .eml-Datei. E-Mail-Prozesse, die schon vorher anonymisiert worden waren, trugen diese Angaben weiterhin.

Diese älteren Prozesse werden jetzt nachträglich bereinigt. Anschließend sehen sie genauso aus wie neu anonymisierte: Empfänger und Betreff tragen den Vermerk anonymized, die übrigen Felder sind leer, und die gespeicherte E-Mail-Datei ist gelöscht. Die technische Nachrichtenkennung und Ihre eigenen Kennungen aus der Rendering-Anfrage bleiben erhalten.

Noch nicht anonymisierte E-Mail-Prozesse sind nicht betroffen. Für sie gelten unverändert die Aufbewahrungsfristen Ihres Mandanten.

Die zuvor auf Staging beschriebenen MCP-Erweiterungen sind jetzt auch unter https://app.output.rocks/api/mcp verfügbar. Dazu gehören geschützte Dateiübertragung, Vorlagenvorschauen, browserbestätigte Konfigurations- und Prozessvorschläge sowie Prozessdiagnose. Reports und Archivzugriffe setzen weiterhin das jeweilige Mandantenmodul und die passenden Benutzerrechte voraus.

Melden Sie Ihre Verbindung erneut an und genehmigen Sie nur die benötigten zusätzlichen Berechtigungen: mcp:files, mcp:data, mcp:process-data und mcp:reports-archive. Bestehende Verbindungen erhalten keine zusätzlichen Rechte automatisch. Änderungen benötigen weiterhin die ausdrücklich angezeigte Browserfreigabe; Mandanten- und Untermandantengrenzen gelten unverändert.

Die Hinweise auf Staging in älteren Release Notes beschreiben die damalige Einführungsphase. Maßgeblich für die aktuelle Nutzung ist die verlinkte Anleitung in deutscher und englischer Sprache. Praktisch getestet wurde Codex; Claude/Cowork und GitHub Copilot in VS Code wurden nicht praktisch getestet.

Die Anonymisierung eines E-Mail-Prozesses hat bisher nur den HTML-Text durch den Vermerk anonymized ersetzt. Empfängeradresse, Kopie- und Blindkopieempfänger, Antwortadresse, Absendername, Betreff, die Textfassung und die zusätzlichen Angaben des Prozesses blieben erhalten, ebenso die gespeicherte .eml-Datei mit dem vollständigen Inhalt der Nachricht samt allen Anhängen.

Ab sofort entfernt die Anonymisierung diese Angaben mit. Empfänger und Betreff tragen anschließend den Vermerk anonymized, die übrigen Felder sind leer, und die gespeicherte E-Mail-Datei wird gelöscht. Für einen anonymisierten Prozess steht der Download der E-Mail damit nicht mehr zur Verfügung; das gerenderte Dokument des zugehörigen Dokumentprozesses wurde schon bisher gelöscht.

Erhalten bleibt die technische Nachrichtenkennung, über die verspätete Zustellmeldungen ihrem Prozess zugeordnet werden, sowie Ihre eigenen Kennungen aus der Rendering-Anfrage, damit ein Abgleich mit Ihrem Vorsystem weiterhin möglich ist.

Die Änderung wirkt auf alle künftig anonymisierten E-Mail-Prozesse. Die Aufbewahrungsfristen Ihres Mandanten gelten unverändert, und blockierte Vorgänge bleiben wie gewohnt vollständig erhalten.

Zwei Wege, auf denen eine Rendering-Anfrage abgeschlossen wird, haben bisher keine Anonymisierungsfrist gesetzt. Die Daten dieser Anfragen blieben deshalb dauerhaft erhalten.

Das betraf Duplikate: Ist für Ihren Mandanten die Duplikatprüfung aktiv, wird eine Anfrage mit bereits bekannter externer ID als Duplikat abgewiesen. Diese Anfragen erreichten nie den regulären Abschluss und bekamen deshalb nie eine Frist, obwohl sie dieselben Daten tragen wie die ursprüngliche Anfrage. Außerdem betraf es Anfragen, die im Cockpit auf erledigt gesetzt werden, wobei die zugehörigen Prozesse gelöscht werden.

Beide erhalten ab sofort dieselbe Frist wie jede regulär abgeschlossene Anfrage, nach der in den Einstellungen Ihres Mandanten hinterlegten Aufbewahrungsdauer für Rendering-Anfragen. Für bereits früher abgeschlossene Anfragen ist die nachträgliche Vergabe einer Frist ein separater Wartungsschritt. Dieser wird durch dieses Release nicht automatisch ausgeführt.

Blockierte Anfragen bleiben wie gewohnt unberührt, solange die Aufbewahrungsdauer für blockierte Prozesse auf nie steht.

Die planmäßige Anonymisierung verarbeitet fällige Rendering-Anfragen sowie Dokument-, E-Mail- und XML-Prozesse ab sofort in Sammelvorgängen. Bisher wurde jeder Eintrag einzeln angestoßen, wodurch die Bereinigung bei größeren Mengen dem täglichen Zulauf hinterherlief.

Am Ergebnis ändert sich nichts: Es werden dieselben Felder geleert und dieselben gerenderten Dokumente gelöscht wie zuvor, und die in den Einstellungen hinterlegten Aufbewahrungsfristen jedes Mandanten gelten unverändert. Blockierte Vorgänge bleiben nach wie vor vollständig erhalten, solange die Einstellung Aufbewahrungsdauer für blockierte Prozesse und Daten auf nie steht.

Jeder Lauf arbeitet mit einem festen Zeit- und Mengenbudget und pausiert selbsttätig, wenn die Datenbank stärker ausgelastet ist. Läuft parallel eine manuelle Bereinigung, setzt der planmäßige Lauf aus und nimmt seine Arbeit beim nächsten Termin wieder auf. Einträge, deren zugehörige Datei sich nicht löschen ließ, gehen weiterhin den bisherigen Einzelweg und erscheinen bei wiederholtem Fehlschlag wie gewohnt als blockierter Vorgang im Cockpit.

Nur auf Staging: Korrigierte Rendering-Requests lassen sich über MCP als neue Requests einplanen oder vorab nach Browserfreigabe simulieren. Der Quellrequest bleibt erhalten. Die bestehende Request-Simulation liefert ihre zulässigen Daten vollständig in prüfbaren Teilen.

Für ausgesteuerte E-Rechnungen stehen bestätigte Payload-Korrektur, Regenerierung und Neuzuordnung bereit. Zustände, Rollen und bestehende Workflowregeln werden weiterverwendet. Eine reine Payload-Korrektur startet noch keinen Workflow. Regenerierung und Neuzuordnung können angehaltene Dokumentprozesse fortsetzen.

Die Freigabe zeigt Ausgangszustand, vollständige Parameter und mögliche Folgezustellungen. Paralleländerungen werden übersprungen. Große JSON-Eingaben nutzen geschützte Artefakte; Geheimnisse bleiben ausgeschlossen.

Produktionsfreigabe erfolgt separat. Praktische Client-Abnahme mit Codex; Claude/Cowork und GitHub Copilot in VS Code werden nicht als praktisch getestet ausgewiesen.

Nur auf Staging: MCP liest Monats- und Rendering-Berichte, SLA-Auswertungen und berechtigte Archiveinträge. Dateien werden geschützt in prüfbaren Teilen übertragen; Archivdownloads nutzen die bestehende Protokollierung.

Administratoren können eine feste Auswahl von Konfigurationen als ZIP exportieren. Importe verwenden die bestehende Vorschau und Konflikterkennung. Die Browserfreigabe zeigt Datei-Prüfsumme, Aktivierung, Inhalte und jede Importentscheidung. Erst danach werden die bestätigten Einträge mit den bestehenden Versionsregeln übernommen. Paralleländerungen stoppen den Import; doppelte Bestätigung wiederholt ihn nicht.

Dateien sind auf 10 MiB und Transfers auf 100 Einträge begrenzt. Geheimnisse, allgemeines Löschen und Archivänderungen bleiben ausgeschlossen. Datei- und Datenrechte müssen ausdrücklich erteilt werden.

Produktionsfreigabe erfolgt separat. Praktische Client-Abnahme mit Codex; Claude/Cowork und GitHub Copilot in VS Code werden nicht als praktisch getestet ausgewiesen.

Berichts- und Archivzugriff benötigt eine neue ausdrückliche OAuth-Freigabe (mcp:reports-archive). Vorhandene Verbindungen erhalten keine zusätzlichen Rechte automatisch. Die Anmeldung erläutert auch den Download von Berichts-PDFs und archivierten Originaldokumenten.

Lokale Zwischenkopien von Bildern, DOCX-Dateien und E-Mail-Anhängen werden auch bei einem fehlgeschlagenen Import automatisch entfernt.

Archiv und Untermandanten bleiben optionale Mandantenmodule. MCP umgeht ihre Freischaltung nicht; auch Untermandanten-Zuordnungen und Standardfreigaben werden beim Vorschlag und erneut vor der bestätigten Änderung geprüft.

Die deutsche und englische Anleitung beschreibt die Anmeldung mit Codex, Claude/Cowork und GitHub Copilot in VS Code. Produktionsadressen bleiben der Standard; die erweiterten Datei-, Vorlagen- und Prozessfunktionen sind ausdrücklich auf Staging begrenzt. Zusätzliche Zugriffsrechte benötigen eine neue OAuth-Freigabe.

Beispielaufträge erläutern den Binect-Overlay-Vergleich, Tabellenabstände auf Seite 2 und die bestätigte Wiederholung fester Prozessauswahlen. Archiv und Untermandanten setzen weiterhin das jeweils freigeschaltete Mandantenmodul voraus.

Die praktische Client-Abnahme erfolgt mit Codex einschließlich Dateiübertragung, DOCX-Bearbeitung, Template-Editor-Vorschau und Browserfreigabe. Claude/Cowork und GitHub Copilot in VS Code sind nicht praktisch getestet. Die Produktionsfreigabe der Erweiterungen erfolgt separat.

Nur auf Staging: Gerenderte Vorlagenvorschauen liefern jetzt Seitenzahl, Seitengrößen und einzeln abrufbare MCP-Seitenbilder. Damit kann ein KI-Client beispielsweise die Tabelle auf Seite 2 tatsächlich visuell prüfen.

Für den Vergleich stehen gespeicherte Overlays sowie geschützte, temporäre PDF-Uploads bereit. Der vorhandene Template-Editor-Vergleich wird wiederverwendet. Das Overlay verändert ausschließlich das Vergleichsbild, niemals die DOCX-Datei oder die ursprünglichen Vorschau-PDFs.

Datei-, Seiten- und Verarbeitungsgrenzen sowie erneute Berechtigungsprüfungen schützen den Zugriff. Verwendete temporäre Overlays werden mit der Bearbeitungssitzung bereinigt. Browserbestätigtes Speichern folgt separat. Claude/Cowork und GitHub Copilot in VS Code sind nicht praktisch getestet.

Nur auf Staging: Ein MCP-Client kann die Übernahme einer gerenderten DOCX vorschlagen. Der Freigabelink zeigt Ausgangsversion, Änderungsbeschreibung, Testdaten und Original-/Entwurfsvorschau mit Seitennavigation. Ein optionales PDF-Overlay bleibt ausschließlich Teil des Vergleichs.

Die Bestätigung speichert über die vorhandene Vorlagenversionierung und ihre Aktivierungsregeln. Die Freigabe gilt für genau die geprüfte Datei. Ablehnung, Paralleländerungen, abgelaufene oder widerrufene Verbindungen verhindern die Übernahme; wiederholte Bestätigung erzeugt keine weitere Version.

Die Erweiterung erfordert Datei-, Daten- und Schreibfreigabe sowie die passende Vorlagenberechtigung. Claude/Cowork und GitHub Copilot in VS Code sind nicht praktisch getestet. Eine Produktionsfreigabe erfolgt separat.

Nur auf Staging: Mit einer eindeutig ausgewählten Vorlagenversion und Testdaten können MCP-Clients eine geschützte Bearbeitungssitzung starten. Original-DOCX, vollständige Metadaten und Testdaten stehen zum Abruf bereit.

Original und hochgeladener DOCX-Entwurf lassen sich durch den bestehenden Template-Editor mit denselben Testdaten und demselben Datum rendern. Die Vorschau-PDFs sind vollständig über MCP abrufbar. Vorlagen werden weder gespeichert noch aktiviert; parallele Konfigurationsänderungen führen zum Konflikt.

Datei- und Datenzugriff benötigen ausdrückliche OAuth-Freigabe und die Template-Editor-Rolle. Sitzungen und Dateien laufen automatisch ab; beim Schließen werden zugehörige Kopien und Vorschauen entfernt. Der Editor räumt temporäre Renderingdateien auch im Fehlerfall auf.

Seitenbilder, Overlays und browserbestätigtes Übernehmen folgen separat. Claude/Cowork und GitHub Copilot in VS Code sind nicht praktisch getestet.

Nur auf Staging: Drei zusätzliche MCP-Werkzeuge bieten Suche und Diagnose für Rendering-Requests, Dokument-, E-Mail-, XML- und Datensammler-Prozesse. Bestehende UI-Berechtigungen und Untermandantengrenzen gelten auch über MCP. Prozessnutzdaten benötigen die neue ausdrückliche Freigabe mcp:process-data. Bestehendes mcp:data gewährt diesen Zugriff nicht automatisch; Geheimnisse und Authentifizierungsheader werden nicht ausgegeben.

Der Workflow erfasst fehlgeschlagene Operationen strukturiert. Der Webhook-Filter berücksichtigt ausschließlich dazu passende, weiterhin blockierte Prozesse. Ältere Fehler ohne diesen Nachweis bleiben unklassifiziert. Vollständige Metadaten, Protokolle und Nutzdaten können mit Prüfsumme in Teilen gelesen werden. Die Prozesssuche verwendet die Sortierung und Seitennavigation der jeweiligen vorhandenen UI-Liste, auch bei kleinen Seiten für eine gezielte Trefferprüfung.

Die vorhandenen MCP-Werkzeuge bleiben kompatibel. Prozessaktionen sind in dieser Erweiterung noch nicht enthalten. Claude/Cowork und GitHub Copilot in VS Code sind nicht praktisch getestet. Eine Produktionsfreigabe erfolgt separat.

Nur auf Staging: propose_process_action bereitet Wiederholungen, Fortsetzung, Validierung, fachliche Freigabe oder Ablehnung sowie E-Mail-Neuverarbeitung für konkrete IDs vor. Erst die Browserfreigabe plant den Auftrag ein.

Der Browser zeigt die vollständige Auswahl und mögliche Neuberechnung oder Zustellung. Der Standard für Wiederholungen bleibt die ursprüngliche Auflösung mit Fortsetzung am fehlgeschlagenen Schritt. Strukturierte Webhook-Fehler können gezielt ausgewählt werden; spätere Treffer werden nicht automatisch aufgenommen.

get_process_job liefert paginierte Einzelergebnisse und Gesamtzahlen. Rechte, Verbindung und Zustand werden vor Ausführung erneut geprüft. Veränderte Einträge werden übersprungen; doppelte Bestätigung erzeugt keinen zweiten Auftrag. Unklare Worker-Abbrüche werden sichtbar ausgewiesen, damit keine externe Aktion blind wiederholt wird. Der gemeinsame E-Mail-Pfad prüft das Kennzeichen für bewusstes erneutes Senden jetzt in der richtigen Reihenfolge.

Der Konfliktvergleich verwendet die gespeicherte Zeitgenauigkeit. Reguläre Worker-Wiederholungen werden dadurch nach einem erneuten Datenbankzugriff nicht fälschlich als zwischenzeitliche Änderung übersprungen.

Produktionsfreigabe sowie XML-Korrektur und Regenerierung erfolgen separat. Claude/Cowork und GitHub Copilot in VS Code sind nicht praktisch getestet.

Nur auf Staging: MCP kann die 15 bisher lesbaren Konfigurationsarten sowie E-Mail-Anhänge mit ihren Zuordnungen, Aktivierungsdaten und Dateifeldern zur Erstellung oder Bearbeitung vorschlagen. Große Feldobjekte lassen sich als JSON-Datei übertragen; umfangreiche Vorschläge bleiben vollständig in Teilen lesbar. Der vollständige Lesezugriff ergänzt Dateinamen und Detailmetadaten. Mit explizitem Datenzugriff sind auch E-Mail-Adressen und reine Zuordnungskennungen lesbar; Geheimnisse und interne Verbindungsdaten bleiben ausgeschlossen.

Neue DOCX-Vorlagen erhalten vor der Browserfreigabe eine Vorschau über den bestehenden Template-Editor. Dateien werden auf Typ, Größe und Prüfsumme geprüft. Für bestehende DOCX-Vorlagen bleibt der Vergleich von Original und Entwurf erhalten.

Versionswiederherstellung und Rücknahme zukünftiger Versionen erfordern ebenfalls Browserfreigabe. Änderungen an Vorlagenzuordnungen oder Versionshistorien führen zum Konflikt. Die vorhandenen UI-Dienste prüfen und speichern die Änderungen; Umbenennen, allgemeines Löschen und Administrationszugriffe bleiben ausgeschlossen.

Die Erweiterung benötigt ausdrücklich erteilte Daten- und Schreibrechte sowie bei Dateien Dateizugriff. Claude/Cowork und GitHub Copilot in VS Code sind nicht praktisch getestet. Eine Produktionsfreigabe erfolgt separat.

Diese Erweiterung ist ausschließlich für Staging vorgesehen. Vorlagendateien können anhand ihrer Versions-ID vollständig heruntergeladen und temporäre DOCX-Entwürfe in begrenzten Abschnitten hochgeladen werden. Prüfsummen schützen die Übertragung; beschädigte, unsichere und zu große DOCX-Dateien werden abgewiesen. Die Dateiberechtigung verwendet dieselbe Mandanten- und Untermandantenprüfung wie die Anwendung und wird bei jedem erneuten Dateiabruf geprüft.

Die zusätzlichen Berechtigungen mcp:files und mcp:data müssen bei einer neuen OAuth-Anmeldung ausdrücklich genehmigt werden. Bestehende Verbindungen erhalten sie nicht automatisch. Dateien bleiben an Benutzer, Mandant und Verbindung gebunden.

Lange Konfigurations- und Testdaten lassen sich ohne Text- oder Listenkürzung in Abschnitten abrufen. Geheimnisse und interne Felder bleiben ausgeschlossen. Temporäre Dateien können sofort freigegeben werden und werden spätestens nach 24 Stunden automatisch bereinigt, solange die geplante Bereinigung läuft.

Das Rendern und Übernehmen von Vorlagenentwürfen folgt separat. Ein Upload ändert noch keine aktive Vorlage. Claude/Cowork und GitHub Copilot in VS Code wurden nicht praktisch getestet.

Codex kann eine Testvorlage über standardisierte MCP-Werkzeuge herunterladen, lokal bearbeiten und zurückübertragen sowie die gerenderten Seitenbilder prüfen. Der technische Machbarkeitsnachweis verwendet eine isolierte Testdatei.

Die Bearbeitung gespeicherter Output.Rocks-Vorlagen ist damit noch nicht freigeschaltet. Die Anbindung an den Template-Editor, geschützte Dateiablage und Browserfreigabe werden in den folgenden Erweiterungen umgesetzt. Claude/Cowork und GitHub Copilot in VS Code wurden nicht praktisch getestet.

Automatische Änderungszusammenfassungen, Fehleranalysen und Backend-Assistenten fordern ihre Antwort direkt in einem Modellaufruf an. Der bisherige zusätzliche Versuch nach einer unbrauchbaren JSON-Modus-Antwort entfällt.

Leere, ungültige oder unvollständige Antworten werden weiterhin als Fehler behandelt. Bestehende lokale Ersatzverfahren bleiben verfügbar. Die Nutzungsaufzeichnung erfasst jeden Modellversuch genau einmal und behält seine Kunden- und Funktionszuordnung.

Eine Marke kann jetzt einen Briefbogen tragen — eine Word-Datei mit Kopf- und Fußzeile, Logo, Seitenrändern und Adressfeld, die beim Rendern um die Inhaltsvorlage gelegt wird. Die Inhaltsvorlage enthält damit nur noch den Text des Schreibens und wird einmal gepflegt, statt je Marke dupliziert zu werden.

Was der Briefbogen bestimmt: Seitenformat und Ränder, Kopf- und Fußzeile samt Logos, Seitennummerierung. Eigene Kopf- und Fußzeilen der Inhaltsvorlage entfallen im gerenderten Dokument. Absatz- und Zeichenformate des Inhalts bleiben unverändert — ein Briefbogen formatiert den Text nicht um.

Wo er nicht greift: bei der Marke default, bei E-Mail-Vorlagen, bei Vorlagen mit aktiviertem Legacy-Rendering und bei Vorlagen, für die Briefbogen nicht anwenden gesetzt ist. Hat eine Marke keinen Briefbogen, wird unverändert wie bisher gerendert.

Beim Hochladen wird der Briefbogen geprüft: Er muss eine makrofreie .docx sein und genau einmal das Feld <<refLookup:or.brandLayoutContentTemplate>> enthalten — die Stelle, an der die Inhaltsvorlage eingesetzt wird. Schriften, Formatvorlagen und Seitengeometrie werden als Bericht neben dem Upload angezeigt.

Hinweise beim Speichern einer Inhaltsvorlage: Trägt eine Vorlage eigene Kopf- oder Fußzeilen, prüft Output.Rocks beim Speichern, welche Marken einen Briefbogen haben und ob deren Briefbogen denselben Text zeigt. Fehlt er dort, wird die betroffene Zeile im Wortlaut genannt — zusammen mit den Marken, in deren Dokumenten sie nicht erscheinen würde. Auch ein zweiter Abschnitt in der Vorlage wird gemeldet, weil dessen Seiteneigenschaften und Kopf-/Fußzeilen beim Rendern entfallen. Die Hinweise blockieren nichts: Entweder wandert der Text in die Briefbögen, oder die Vorlage bekommt Briefbogen nicht anwenden.

Vorschau in einer Marke: Der Vorlagen-Test und der Vorlagen-Editor rendern nicht mehr immer als default. Beide haben jetzt eine Markenauswahl; Briefbogen, Bilder, Standardwerte, Komponenten, Diagramme, QR-Codes und Anhänge werden für die gewählte Marke aufgelöst. Eine Vorlage, die selbst zu einer Marke gehört, zeigt diese an und lässt sie nicht wechseln — anders käme ein Dokument heraus, das es produktiv nicht geben kann.

Was eine Marke erbt: Der Bearbeiten-Dialog einer Marke zeigt unter Effektive Konfiguration, wie viele Elemente je Typ von der gemeinsamen Konfiguration übernommen werden und wo die Marke eigene Zeilen hat. Ein Identifier mit dem Hinweis veraltet wurde überschrieben, bevor die gemeinsame Version zuletzt geändert wurde — die Marke arbeitet dort mit einem älteren Stand.

Filtern nach Marke: Die markenfähigen Listen hatten das Marken-Filtermuster schon in der URL, aber kein Bedienelement zum Setzen. Jetzt lässt sich in jeder dieser Listen eine Marke auswählen; solange eine gewählt ist, zeigt jede Zeile zusätzlich, ob sie für diese Marke geerbt oder überschrieben ist.

Renderdauer: Ein Dokument mit Briefbogen wird aus zwei Dateien zusammengesetzt, und das kostet Zeit. Gemessen wurde der Aufschlag in zwei Umgebungen mit deutlich unterschiedlichem Ergebnis: lokal rund 10 %, auf der Testumgebung im verschränkten A/B-Vergleich etwa das 1,7-fache (Median 1027 ms ohne, 1752 ms mit Briefbogen, also gut 700 ms je Dokument). Der Wert hängt an der Auslastung und Dimensionierung des Rendering-Dienstes und ist deshalb je Umgebung zu messen, nicht aus einer Zahl abzuleiten. Wo die Zeit ins Gewicht fällt, bleibt Briefbogen nicht anwenden je Vorlage der Ausweg.

Nachvollziehbarkeit: Jeder Renderprozess hält fest, mit welcher Marke, welcher Markenversion und welchem Briefbogen das Dokument entstanden ist, und wie lange das Rendern gedauert hat. Der Konfigurations-Transfer nimmt die Briefbogen-Datei beim Export und Import mit.

Damit eine Inhaltsvorlage sowohl mit als auch ohne Briefbogen richtig aussieht, kann ihr eigener Briefkopf in einen bedingten Abschnitt gesetzt werden: <<cs_{!or.brandLayoutApplied}>> … <<es_>>. Der Abschnitt wird nur dann gerendert, wenn kein Briefbogen greift.

Die MCP-Werkzeuge unterstützen die Markenauswahl beim Testen und Bearbeiten von Vorlagen, Markenfilter mit Vererbung sowie die effektive Markenkonfiguration. Briefbögen können nach Browserfreigabe hochgeladen und entfernt werden und sind im Konfigurationstransfer enthalten. Auch der Vorlagen-Schalter zum Aussetzen des Briefbogens ist über MCP verfügbar.

Die produktive MCP-Schnittstelle ist unter https://app.output.rocks/api/mcp verfügbar. Die Verbindungsanleitungen enthalten Produktionsbeispiele sowie einen gesonderten Hinweis zur Testumgebung.

Dokumentations- und Fachzugriffe verwenden Ihre bestehenden Berechtigungen. Änderungen bleiben Vorschläge, bis Sie sie in der App ausdrücklich bestätigen. Eigene Vorschläge können Sie auch aus einer anderen aktiven, nicht delegierten Browser-Sitzung desselben Mandanten verwalten; die ursprüngliche MCP-Verbindung muss weiterhin gültig sein.

Die Mandanteneinstellung Aufbewahrungsdauer für blockierte Prozesse und Daten bietet neben den Tageswerten die Option nie. Mit dieser Option bleiben eine Rendering-Anfrage und alle damit verbundenen Dokument-, E-Mail- und XML-Prozesse vollständig erhalten, solange die Anfrage selbst oder einer ihrer Prozesse blockiert ist. Ein blockierter Vorgang kann dadurch jederzeit mit den ursprünglichen Daten erneut angestoßen werden.

Die Option ist für alle Mandanten aktiviert und ersetzt die bisher hinterlegten Tageswerte. Bereits blockierte Vorgänge, die noch einen Bereinigungstermin trugen, verlieren diesen Termin. Sobald ein Vorgang entblockt wird und regulär abschließt, greift wieder die gewohnte Aufbewahrungsdauer für gerenderte Dokumente, und die Bereinigung läuft wie bisher.

Wer für einen Mandanten weiterhin einen Tageswert wünscht, kann ihn in den Einstellungen unter Datenschutz wieder auswählen. Dann werden blockierte Vorgänge wie bisher nach Ablauf der Frist bereinigt, auch wenn sie noch blockiert sind.

Unter Integration → MCP-Verbindungen sehen angemeldete Benutzer ihre eigenen Verbindungen, die angeforderten Berechtigungen und offene Änderungsvorschläge. Verbindungen können dort sofort widerrufen werden.

Ein KI-Assistent kann Änderungen an ausgewählten Standardwerten, Vorlagenkomponenten, E-Mail-Vorlagen und Testdaten vorschlagen. Die App zeigt Typ, Operation, Ablaufzeit sowie den Vorher-/Nachher-Vergleich und führt die Änderung erst nach einer ausdrücklichen Bestätigung aus. Löschen, Umbenennen und sicherheits- oder betriebsrelevante Felder bleiben ausgeschlossen. Wurde das Zielobjekt zwischenzeitlich geändert, wird der Vorschlag als veraltet markiert und muss neu erstellt werden.

In der Webhook-Liste öffnet die neue Aktion Ablaufübersicht alle Treffer der aktuellen Filter als grafischen Prozess – auch wenn sie auf mehreren Tabellenseiten liegen. Die Darstellung gruppiert Webhooks nach ihrer Aufrufgruppe, trennt Rendering Request, Dokument und E-Mail sowie Pre-Rendering und anschließende Ausführung und ordnet die Knoten nach Priorität und Webhook-ID.

Status, Gruppenbedingungen und E-Mail-Zustelltrigger sind direkt am jeweiligen Knoten sichtbar. Ein Klick auf einen Knoten öffnet die bestehende Detailansicht; die Übersicht selbst bleibt schreibgeschützt.

Über den neuen Endpunkt POST /api/renderings/preview können Integrationen eine gespeicherte Dokumentvorlage mit ihren Daten testen und die Vorschau direkt als PDF anzeigen. Wenn mehrere Dokumentvorlagen zum Identifier passen, werden sie in ihrer bestehenden Reihenfolge zusammengefügt.

Jede Seite trägt das feste graue, diagonale VORSCHAU-Wasserzeichen. Optionale staticAttachments werden nach den gerenderten Dokumenten in Request-Reihenfolge angefügt und ebenfalls markiert – wie beim regulären Rendering aber nur dann, wenn der Request keine E-Mails erzeugt. Die Vorschau verwendet dieselben Mappings, Marken, Standardwerte, Charts, QR-Codes und Prerender-Webhooks wie ein reguläres Rendering, speichert aber keinen Rendering-Request und versendet keine E-Mails.

Die Vorschau ist bewusst kein Ersatz für das Produktivdokument: Für das Wasserzeichen wird das PDF neu aufgebaut, wodurch nur die sichtbare Seitenebene erhalten bleibt. Eingebettete Dateien wie ZUGFeRD-/Factur-X-XML, die PDF/A-Konformität, die PDF/UA-Tag-Struktur, XMP-Metadaten, Lesezeichen und Formularfelder sind in der Vorschau nicht enthalten. E-Rechnungs- und Barrierefreiheits-Anforderungen prüfen Sie weiterhin am Ergebnis von POST /api/renderings.

Neben der kVASy-Schnittstelle gibt es jetzt einen generischen XML-Endpunkt.

• POST /api/rendering/xml nimmt beliebiges wohlgeformtes XML entgegen; die Vorlage wird über den Pflicht-Query-Parameter template benannt.
• Das Wurzelelement bleibt in den Renderdaten erhalten. Attribute landen unter _attributes, gemischter Text unter _text.
• In der DTD deklarierte interne Entities werden aufgelöst; externe Entities werden weiterhin nicht geladen.
• Geschwisterelemente oder Attribute desselben Elements, deren Namen auf denselben Schlüssel fallen, sowie Wurzelelemente auf dem reservierten Schlüssel or werden mit HTTP 400 abgelehnt, statt Daten still zusammenzuführen. Elemente werden über Namespace und lokalen Namen verglichen, damit dasselbe Element mit unterschiedlichen Präfixen weiterhin als Wiederholung gilt.
• template, externalId, webhook und emailServer werden auf 255 Zeichen geprüft und liefern bei Überlänge HTTP 400 statt eines Serverfehlers. Das gilt auch für POST /api/rendering/kvasy; die dort automatisch erzeugte externe ID wird auf die Spaltenlänge gekürzt.

Eingabemasken für Individualschreiben lassen sich jetzt direkt über den Vorlage-Identifier öffnen. Parameter mit dem Präfix field. befüllen passende Formularfelder vor; Select-Felder verwenden dabei den technischen Options-Key. Reset stellt diese URL-Werte erneut her, während Vorschau und Erstellung weiterhin bewusst manuell gestartet werden.

Die Vorbelegung wird gegen die tatsächliche Maskenkonfiguration geprüft. Unbekannte oder ungültige Felder werden ohne Anzeige ihrer Werte ignoriert, Rich-Text wird als Klartext sicher escaped. Der reguläre Login führt anschließend einschließlich aller Query-Parameter zum Deep Link zurück. Die bestehenden Rollen-, Mandanten-, Umgebungs-Mandanten-, Aktivitäts- und Rendering-Prüfungen bleiben unverändert.

Da URLs in Browser-Verläufen und Logs sichtbar werden können, ist die Funktion nur für kurze, nicht sensible Werte vorgesehen. Personenbezogene oder vertrauliche Inhalte gehören nicht in Deep-Link-Parameter.

Die Monatsberichte sind neu gestaltet und entsprechen jetzt dem Design der Anwendung: gleiches Logo, gleiche Farben, gleiche Tabellen.

Der Gesamtbericht beginnt mit den drei Kennzahlen des Zeitraums – abrechenbare Einheiten, Dokumente und E-Mails. Darunter stehen nur noch die Clients, die im Zeitraum tatsächlich etwas erzeugt haben, sortiert nach abrechenbaren Einheiten und mit einer Gesamtzeile abgeschlossen. Über der Tabelle steht, wie viele der insgesamt vorhandenen Clients das betrifft. Für einen typischen Monat schrumpft der Bericht damit von über fünfzig Seiten auf eine.

Client-Namen und Dokumentbezeichnungen werden nicht mehr mitten im Wort umbrochen, Tabellenzeilen nicht mehr über Seitenwechsel zerrissen, und die Fußzeile ist durchgängig deutsch.

Für White-Label-Installationen lassen sich Logo, Akzentfarbe, Textfarbe und Name der Berichte über Umgebungsvariablen setzen. Ohne Konfiguration bleibt das Standarddesign aktiv.

Ist in den Mandanteneinstellungen eine E-Mail-Adresse für allgemeine Meldungen hinterlegt, wird der monatliche Gesamtbericht jetzt direkt als PDF-Anhang versendet.

Die einzelnen Client-Berichte bleiben im Berichtsarchiv verfügbar und können dort gezielt heruntergeladen werden.

Alle versionierten Ressourcen zeigen ihre Versionsnummer jetzt als eigene Spalte. Neue Spaltenkonfigurationen blenden sie standardmäßig ein; bei bereits gespeicherten Konfigurationen kann sie über Spalten konfigurieren ergänzt werden.

Beim Erstellen und Bearbeiten lässt sich die Aktivierung direkt als Sofort wirksam oder Für einen zukünftigen Zeitpunkt planen festlegen. Geplante Versionen zeigen ihren Starttermin in der Übersicht. Ist für eine aktuell gültige Version bereits ein Nachfolger geplant, wird dort außerdem der nächste Aktivierungstermin angezeigt, ohne dass die Versionshistorie geöffnet werden muss.

Die Monatsübersicht fasst alle Dateien eines Kalendermonats in einer Zeile zusammen. Der Gesamtbericht steht direkt zum Download bereit und enthält die Systemsumme sowie die Gesamtzahlen je Haupt- und SubClient.

Über die aufklappbare, durchsuchbare Client-Liste lassen sich die Detailberichte einzeln herunterladen. Ein Detail-PDF wird nur für Clients mit mindestens einem abrechenbaren Element im jeweiligen Monat erzeugt. Dadurch bleiben die einzelnen Dokumente kompakt und die Berichtserzeugung funktioniert auch bei sehr vielen Clients zuverlässig.

Der Powercloud-ZUGFeRD-Webhook bietet ein optionales IBAN-Override für Testumgebungen. Ist es konfiguriert, ersetzt es die IBAN aus den Eingangsdaten ausschließlich im erzeugten E-Rechnungs-XML.

Das Override greift bewusst nur bei SEPA-Lastschriften, weil die IBAN dort das Konto des Zahlungspflichtigen beschreibt. Bei allen anderen Zahlungsarten steht an derselben Stelle das Empfängerkonto – eine Ersetzung würde dort die Zahlungsanweisung im XML umlenken, während das Dokument weiterhin das ursprüngliche Konto ausweist. Für Selbstzahler bleibt daher das bestehende Feld „IBAN für Selbstzahler“ zuständig.

Die ursprünglichen Eingangs- und Render-Daten, die PDF-Darstellung sowie alle weiteren Zahlungsdaten bleiben unverändert. Jede angewandte Ersetzung wird protokolliert, damit die Abweichung zwischen Dokument und E-Rechnung nachvollziehbar bleibt.

Custom-, OAuth2- und Powercloud-Custom-Webhooks unterstützen jetzt dieselben optionalen Felder für Zielwurzel, Schlüssel, Teilwert-Auswahl und rekursives Zusammenführen einer JSON-Antwort. Powercloud-E-Mail-Webhooks speichern zusätzlich die Antworten einzelner Anhänge unter stabil bereinigten Template-Schlüsseln.

• Der Custom-E-Mail-Webhook verwendet beim Auflösen seiner E-Mail-Platzhalter wieder die korrekten E-Mail-Prozessdaten.
• Eine bestehende Beispielkonfiguration mit responseDataKey: "keyToStoreResponseIn" beginnt durch die korrigierte Auswertung jetzt mit der additiven Antwort-Speicherung unter diesem Schlüssel. Ein leerer oder fehlender Schlüssel speichert weiterhin nichts.
• Webhooks mit gleicher Priorität laufen stabil nach ihrer ID, sodass verkettete Aufrufe reproduzierbar bleiben.
• Gültige JSON-Antworten mit dem Wert null bleiben beim Speichern typgerecht null und werden nicht als Text abgelegt.

Marken-Chips und Markenauswahllisten laden nur noch die benötigten Angaben über einen mandantensicheren Lesezugriff. Nutzer mit Dashboard- oder Vorlagenberechtigung sehen damit Anzeigenamen und Farben zuverlässig; Einstellungen und die Markenverwaltung bleiben weiterhin CI-Managern vorbehalten.

Im Prozess-Leitstand lässt sich der Konfigurationsstand jetzt vor der Vorschau oder dem erneuten Verarbeiten auswählen. Standardmäßig bleiben Requests reproduzierbar und verwenden die zum ursprünglichen Request-Zeitpunkt gültigen Versionen. Mit Retry-Zeitpunkt greifen Vorschau und erneute Verarbeitung stattdessen auf inzwischen korrigierte Mappings, Vorlagen und weitere aktuell gültige Konfigurationen zu.

Fehlgeschlagene oder vom Binect-Provider stornierte Drucksendungen wechseln jetzt zuverlässig in die manuelle Prüfung. Der zugehörige Dokument- oder E-Mail-Prozess erhält den Status print_failed, bleibt abrechnungs- und datenschutzkonform abgeschlossen und kann nach Retry oder manueller Klärung fortgesetzt werden.

Das Dashboard zeigt die Anzahl der betroffenen Drucksendungen je Mandantenkontext und öffnet direkt die gefilterte Liste. Benutzer mit der Dashboard-Rolle können diese Fälle lesen; Retry, Synchronisierung und manuelles Erledigen bleiben der Druckversand-Rolle vorbehalten.

Die neue Anleitung führt durch Callback-Token, Mandantenbezug und Provider-Einrichtung für Amazon SES/SNS und Mailjet. Sie erklärt außerdem die automatische SNS-Bestätigung, Provider-Wiederholungen, Zustellhistorie, Complaint-Behandlung und die manuelle Bearbeitung von Prozessen ohne Callback.

Beim direkten Öffnen eines Validators werden seine Dokument- und E-Mail-Vorlagen jetzt zuverlässig aufgelöst. In E-Mail-Vorlagen bieten die Felder für Bounce-Re-Rendering-Webhooks und E-Mail-Server passende Identifier als Vorschläge an; Freitext und Platzhalter bleiben weiterhin möglich.

Marken-Chips verwenden jetzt den lesbaren Anzeigenamen in der normalen UI-Schrift. Der technische Identifier bleibt im Tooltip sichtbar und wird weiterhin unverändert für API-Aufrufe und Filter verwendet.

Umgebungs-Mandanten erscheinen jetzt überall als farbige Chips mit ihrer Beschreibung — im Vorlagen-Management, in der Integration, im Prozess-Kontrollzentrum, in allen Renderings-Listen und in den Testwerkzeugen, in den Listen wie in den Detailansichten. Administratoren der Hauptinstanz gelangen per Klick direkt zur Detailansicht des zugehörigen Mandanten.

Workflow-Status verwenden jetzt in allen Prozessansichten dieselbe Farbsemantik: Grün steht für erfolgreich abgeschlossen, Blau für aktive Verarbeitung, Gelb für wartende Prozesse, Rot für Fehler und Grau für neutrale Zustände. Blockierte Requests, Dokumente und E-Mail-Prozesse erscheinen in Liste und Detail rot und nennen „Blockiert" im Tooltip, damit Liste und Prozess-Leitstand denselben Prozess nicht unterschiedlich einfärben. E-Rechnungs-Chips zeigen ihren aktuellen Zustand direkt an; bei ungültigen Dokumenten steht der erste Validierungsgrund zusätzlich im Tooltip.

Beim Aktivieren oder Deaktivieren der SharePoint-Bearbeitung bleibt der Wert sharePointEdit in der JSON-Konfiguration von Eingabemasken jetzt erhalten.

In der Detail-Ansicht von Renderdaten führt die verknüpfte ID direkt zur zugehörigen Render-Anfrage.

Beim Bearbeiten von Umgebungs-Mandanten werden Änderungen an externer ID, Beschreibung und Farbe wieder korrekt gespeichert.

Die drei Identifier-Felder bieten beim Öffnen beziehungsweise beim ersten Fokus passende Vorschläge an. Freitext und Platzhalter können weiterhin unverändert eingegeben werden.

Der Dokumentationslink in der Microsoft-Entra-Rollenverwaltung öffnet jetzt direkt den passenden Abschnitt der Produktdokumentation.

Die Dashboard-Diagramme wechseln ohne Neuladen zwischen deutschen und englischen Beschriftungen.

Die Rendering API akzeptiert jetzt bis zu zehn benannte PDF-Anhänge pro Request.

• Bei reinen Dokument-Renderings werden die PDFs in der übergebenen Reihenfolge an das erzeugte PDF angefügt.
• Erzeugt der Request E-Mails, werden die PDFs stattdessen als Anhänge an jede E-Mail übernommen.
• Die API prüft Dateinamen, Base64-Inhalt, PDF-Struktur sowie die gemeinsame Größenbegrenzung vor der Verarbeitung.
• Die Funktion steht sowohl für JSON-Requests als auch für die kVASy-XML-Schnittstelle zur Verfügung.

Output.Rocks versioniert jetzt alle Verwaltungsobjekte — Vorlagen, E-Mail-Vorlagen, Bausteine, Standardwerte, Bilder, Diagramme, QR-Codes, E-Mail-Anhänge, E-Mail-Rahmen, Marken, Eingabemasken, Mapping-Regeln, Validierungen, Zugangsdaten, Datensammler, E-Mail-Server und Webhooks.

• Copy-on-Write: Jede inhaltliche Änderung erzeugt eine neue, unveränderliche Version (sofort oder geplant per „Gültig ab"). Bereits erzeugte Dokumente und E-Mails bleiben exakt auf der Version, mit der sie erstellt wurden. Reines Aktivieren/Deaktivieren erzeugt keine Version.
• Versionshistorie: Neue Historien-Aktion in allen Verwaltungslisten — mit Versionsnummer, Status, Gültigkeitszeitraum, Ersteller und einer automatischen KI-Zusammenfassung der Änderungen in Deutsch und Englisch.
• Keine Geheimnisse in der KI-Zusammenfassung: Zugangsdaten-Werte, E-Mail-Server-DSNs sowie Webhook-Verbindungs- und Konfigurationsdaten werden vor der KI-Zusammenfassung entfernt. Die Zusammenfassung nennt nur, dass sich ein solches Feld geändert hat, nie den Inhalt.
• Wiederherstellen: Jede frühere Version kann als neue Version wiederhergestellt werden — sofort oder zu einem geplanten Stichtag.
• Lokaler Stichtag: Das gewählte Datum für geplante Versionen und Wiederherstellungen bleibt unabhängig von der Browser-Zeitzone erhalten.
• Löschen ist jetzt endgültig-sicher: Löschen beendet die Gültigkeit eines Eintrags, historische Versionen und ihre Dateien bleiben für die Reproduzierbarkeit erhalten.
• Retry mit Versions-Zeitpunkt: Beim Retry blockierter Requests, Dokumente und E-Mails ist wählbar, ob die Konfiguration zum originalen Request-Zeitpunkt (Standard, reproduzierbar) oder zum Retry-Zeitpunkt (nutzt Korrekturen) aufgelöst wird. Die Wahl ist dauerhaft am Request hinterlegt und gilt auch für automatische Wiederholungen.
• Statistiken aggregieren weiterhin pro Eintrag über alle Versionen hinweg; Name und Farbe stammen aus der aktuell gültigen Version.

Verhaltensänderungen:

• Webhook-Definitionen, Diagramme, QR-Codes und Vorlagen-Bausteine werden beim Rendern und bei Retries jetzt konsistent zum Request-Zeitpunkt aufgelöst (bisher teilweise zum Ausführungszeitpunkt). Diagramme/QR-Codes mit zukünftigem „Gültig ab" werden nicht mehr stillschweigend übersprungen: Gerendert wird die zum Request-Zeitpunkt gültige Version — existiert keine, wird der Rendervorgang mit einer klaren Fehlermeldung blockiert.
• Zugangsdaten (Credentials) in Webhooks werden durchgängig zum Ausführungszeitpunkt aufgelöst — rotierte Secrets brechen Retries nicht mehr.
• API-Token sind von der Versionierung ausgenommen (Zugangs-Prinzipale).

E-Mail-PDFs können jetzt vor dem eigentlichen E-Mail-Inhalt einen einheitlichen, sicheren Text-Header anzeigen.

• Der Header wird unter Mandanten-Einstellungen → E-Mail-PDF aktiviert und als Textvorlage mit bis zu 255 Zeichen gepflegt.
• Platzhalter stehen für Absender, Empfänger, CC, BCC, Betreff, Erstell- und Versandzeitpunkt, Message-ID, Anhänge und Dateiname zur Verfügung.
• HTML-PDF-Downloads und PDF-Varianten der E-Mail-Webhooks verwenden dieselbe Konfiguration.
• Umgebungs-Mandanten erben die Mandanteneinstellung und können Vorlage oder Aktivierungsstatus überschreiben.

Die E-Mail-Test- und Upload-Flows wurden erweitert.

• In der E-Mail-Vorlagen-Testansicht können Vorschauen mit Anhängen gerendert, als PDF oder .eml heruntergeladen und direkt an eine manuelle Empfängeradresse gesendet werden.
• Beim Senden einer gerenderten Vorschau werden Anhänge mitgesendet, wenn die Vorschau mit Anhänge mit rendern erzeugt wurde.
• E-Mail-Prozessdetails bieten Downloads für .eml, HTML-PDF und einzelne Anhänge.
• E-Mail-Webhooks unterstützen zusätzlich HTML-Inhalt als PDF und HTML-Inhalt als PDF und Anhänge.

E-Mail-Folgeaktionen können jetzt gezielter auf Zustellereignisse reagieren, und Bounce-Fälle lassen sich direkt in einen neuen Rendering Request überführen.

• E-Mail-Webhooks für Upload, Archiv, Druckversand und Custom/OAuth2 können auf Immer, Nur bei Zustellung oder Nur bei Bounce gestellt werden.
• Die E-Mail-Prozessliste bietet bei bounced die Aktion Neuen Rendering-Request auslösen mit vorausgefüllten Werten aus dem Quell-Request.
• E-Mail-Vorlagen können automatisches Bounce-Re-Rendering aktivieren und optional Template, Format, Webhook, Mailserver, External-ID-Pattern und Metadaten überschreiben.
• Automatische Bounce-Re-Renderings setzen einen internen Marker, damit ein erneut gebouncter Folge-Request keine Re-Rendering-Schleife auslöst.

DOCX-Vorlagen können statische PDF-Anhänge referenzieren. Bei PDF-Ausgaben werden die ausgewählten Dateien hinter das gerenderte Dokument gehängt.

• Der Verwaltungsbereich heißt jetzt Statische Anhänge und bleibt technisch unter der bestehenden Route erreichbar.
• Die Auswahl in Dokument-Vorlagen nutzt dieselbe Identifier-, Gruppen- und Bedingungsauflösung wie statische Anhänge in E-Mail-Vorlagen.
• Nur gültige PDF-Dateien werden an Dokument-PDFs angefügt; andere Dateitypen bleiben für E-Mail-Vorlagen nutzbar und werden beim Dokument-Append übersprungen.
• billablePages und documentPages bleiben auf das gerenderte Hauptdokument bezogen.

Output.Rocks erhält ein revisionssicheres Archivmodul. Archivierte Dokumente liegen unveränderbar (WORM, S3 Object Lock) in einem eigenen, pro Mandant getrennten Speicherbereich.

• Aktivierung pro Mandant: Das Archiv wird ausschließlich vom Superadmin pro Mandant freigeschaltet.
• Befüllung:
  • Archiv-Webhook „Archiv (WORM)" im Render-/E-Mail-Prozess — als Dokument oder für E-Mails wahlweise vollständige .eml, nur HTML-Inhalt, nur Anhänge oder HTML-Inhalt und Anhänge.
  • Konfigurierbare Archiv-Metadaten: Der Archiv-Webhook speichert nur noch explizit gemappte JSON-Metadaten aus data, Prozess-Metadaten, Dokument- oder E-Mail-Kontext. Alternativ kann ein einzelner Platzhalter wie <<data.archiveMetadata>> ein vorbereitetes Metadaten-Objekt übernehmen. Leeres Mapping bedeutet: keine Metadaten speichern. Über die M2M-API können Archiv-Einträge mit metadata[key]=value nach diesen Metadaten gefiltert werden.
  • Externe API für Drittanwendungen (Ingest, Suche, Metadaten, Download) — pro Mandant über API-Token abgesichert.
  • Manuelles Hochladen direkt in der Oberfläche.
• Archiv-Link: Nach dem Ablegen wird ein dauerhafter, auch von außerhalb abrufbarer Download-Link zurückgeliefert; jeder Abruf wird protokolliert.
• Aufbewahrung & Löschung: Je Dokument gilt eine gesetzliche Aufbewahrungs-Untergrenze (6/8/10 Jahre), die der Speicher erzwingt und die nie unterschritten werden kann. Ein zusätzlich wählbarer Löschzeitpunkt wird automatisch auf diese Untergrenze angehoben. Gelöscht wird erst nach Ablauf — kontrolliert und mit Löschnachweis.
• Legal Hold: Einzelne Dokumente lassen sich gegen jede Löschung sperren (mit Begründung), unabhängig von der Aufbewahrungsfrist.
• Audit-Trail: Jeder Zugriff und jede Änderung (Ablage, Download, Metadaten, Legal Hold, Disposition) wird manipulationssicher (verkettet) protokolliert.
• Integrität: Beim Ablegen wird eine SHA-256-Prüfsumme gebildet und beim Lesen/Export erneut verifiziert.
• E-Rechnung: Strukturierte XML (XRechnung/ZUGFeRD) wird byte-genau und unverändert archiviert (kein Flattening), zusätzlich zur Visualisierung.
• Oberfläche: Eigener Archiv-Bereich mit Liste, Suche/Filter, Detailansicht inkl. Metadaten-Bearbeitung, Audit-Timeline und Download.

• Fehlen JSON-Werte für Platzhalter im QR-Text oder in der Chart.js-Konfiguration, nennt die Vorschau den betroffenen Pfad (z. B. document.qrCode.url) und hebt das Feld JSON-Daten hervor.
• Im QR-Code-Editor werden Platzhalterfehler nicht mehr fälschlich als Quickchart-Ausfall angezeigt.
• Dasselbe Verhalten gilt im Vorlagen-Editor für Chart- und QR-Platzhalter vor dem PDF-Render; fehlende Docmosis-Felder aus Tornado liefern weiterhin nur Freitext-Fehlerzeilen.

• Neuer Prozesstyp XML-Prozesse (E-Rechnung) unter Renderings – neben Dokumenten- und E-Mail-Prozessen. Er bildet den Lebenszyklus einer E-Rechnungs-XML ab (Mapping → Erzeugung → KoSIT-Validierung → Auslieferung) für eingebettete ZUGFeRD-Rechnungen und eigenständige XRechnungen.
• Dokumente mit E-Rechnung sind jetzt klar erkennbar. Ein ZUGFeRD-Dokument wird zurückgehalten (Status waiting_for_e_invoice), bis seine XML erzeugt und gültig ist, und bettet sie anschließend automatisch in das PDF ein.
• Aussteuerung als eigener, benannter Status (statt eines generischen „blockiert"): Schlägt Mapping, Erzeugung oder KoSIT-Validierung fehl, landet die E-Rechnung im Status rejected mit Fehlerstufe und -meldung – sicht- und filterbar im Dashboard.
• Korrektur im Cockpit: Ausgesteuerte E-Rechnungen lassen sich über ein strukturiertes Formular (Rechnungskopf, Verkäufer/Käufer, Positionen) bearbeiten und mit „Speichern & neu erzeugen" erneut erzeugen und validieren. Danach läuft ein zurückgehaltenes Dokument automatisch weiter.
• Abrechnung: Jede erfolgreich erzeugte XML zählt als ein abrechenbares Element (1 XML = 1 Element, analog zu einer E-Mail) und erscheint im Dashboard-Chart „XML Amount" sowie in den Monats- und Rendering-Berichten.
• Dashboard: Neue Warnkarten für Aussteuerung (E-Rechnungen) und Dokumente, die auf E-Rechnung warten sowie das neue XML-Mengen-Chart.
• Zugriff analog zu Dokumentenprozessen: Vollzugriff mit der Rolle Vorlagen-Editor, dashboard-bezogener Zugriff (Aussteuerung/blockiert) mit der Dashboard-Rolle, Bearbeiten und Neu-Erzeugen mit der Rolle Cockpit.

• Die Menüpunkte rund um Eingabemasken heißen jetzt Individualschreiben – sowohl im Vorlagen-Management (Konfiguration) als auch unter Renderings (Erstellung).
• SharePoint-Bearbeitung: Gerenderte Individualschreiben können vor dem Prozessstart vollständig in Word Online bearbeitet werden. Das bearbeitete Dokument wird als PDF zurückgeladen und der Prozess damit fortgesetzt. Konfiguration je Mandant unter Einstellungen → Dokumentbearbeitung (SharePoint-Site, Dokumentbibliothek, optionale eigene Entra-App-Registrierung, Freigabe für Umgebungs-Mandanten).
• Neue Rollen Individualschreiben (ROLE_INDIVIDUAL_LETTER_EDITOR, inkl. SharePoint-Bearbeitung) und Individualschreiben ohne SharePoint-Bearbeitung (ROLE_INDIVIDUAL_LETTER_CREATOR).
• Benutzer-Einstellungen (Profil): Jeder Benutzer kann eine persönliche Unterschrift (PNG) hinterlegen, die bei Eingabemasken-Renderings automatisch über den Platzhalter img_user.signature eingesetzt wird, sowie eine abweichende Microsoft-365-E-Mail für die SharePoint-Bearbeitung.
• Neuer Feldtyp richtext in Eingabemasken: formatierter Text (Fett, Kursiv, Listen) wird über <<html:...>>-Platzhalter in die Vorlage übernommen.
• Die Eingabemasken-Vorschau führt Prerender-Webhooks aus und zeigt damit echte Daten; beim finalen Erstellen werden die Daten wiederverwendet statt erneut abgerufen. E-Mail-Inhalte können direkt in der Vorschau bearbeitet werden.
• Neuer Webhook-Typ Pre-Render Webhook (Rendering Request) (prerender-custom-oauth2-request): ruft Daten einmal pro Rendering Request ab – vor der Zuordnung auf Dokumente und E-Mails.
• Je Eingabemaske kann ein eigener E-Mail-Server für ausgehende E-Mails gewählt werden.
• Rendering-Workflows starten spürbar schneller: Worker werden sofort über neue Aufträge benachrichtigt (bisher bis zu 60 Sekunden Verzögerung möglich).

• Neue Custom-OAuth2-Webhooks können API-Daten vor dem Rendering abrufen und in die Rendering-Daten schreiben.
• After-Rendering-Webhooks können gerenderte Dokumente oder E-Mail-Artefakte per OAuth2 an externe APIs senden.

• Die Request-Simulation hat einen neuen Schalter für Dokument- und E-Mail-Preview. Standardmäßig bleibt die Simulation rein entscheidungsorientiert; bei aktivierter Preview werden transiente Artefakte gerendert.
• Im Prozess-Leitstand kann der aktuell bearbeitete Payload vor Daten speichern und erneut versuchen als Preview gerendert werden.
• Im Modal Request erstellen beziehungsweise Anfrage bearbeiten & erneut verarbeiten gibt es eine Preview vor der finalen Erstellung oder dem finalen Reprocess.
• Das Preview-Modal zeigt Workflow-Summary, Template-Zuordnungen, Webhook-Entscheidungen, Validierungen mit Fehlergründen, Dokumente, E-Mail-HTML/Text, Anhang-Dokumente und Artefaktfehler. Inline-Previews können per Vollbild geprüft werden.
• Preview-Läufe verändern keinen produktiven Request-Status, speichern keine finalen Prozesse und lösen keinen Versand oder Webhook aus.

• Rendering-Berichte werden als Hintergrundjobs erzeugt. Nutzer können die Seite verlassen und später den fertigen Bericht wieder öffnen.
• Die Berichtsübersicht zeigt laufende, fertige und fehlgeschlagene Jobs mit Status und Zeitraum.
• Monatsberichte speichern Ergebnisse stabiler.
• Custom-Mapping-Tests geben Debug-Ausgaben zurück, damit Mapping-Probleme schneller gefunden werden können.
• Die Dokumentation beschreibt den neuen Berichtsworkflow.

• Binect und E-POSTBUSINESS stehen als Druckversand-Integrationen bereit, inklusive Monitoring, Retry-Logik und Provider-Status.
• Powercloud-OAuth-Authentifizierung kann getestet werden; Webhook- und Integrationslisten haben Suchfilter und Sortierung erhalten.
• QR-Code- und Chart-Editoren können bestehende Konfigurationen laden, speichern und für neue Elemente nutzen.
• Invalid Document Renderings zeigen bessere Gründe, damit Fehler schneller eingeordnet werden können.
• Exportspalten orientieren sich staerker an den sichtbaren Tabellenspalten.
• Für E-Mail-Vorlagen wurde ein KI-Assistent mit Validierung und Subclient-Scope ergänzt.

• DOCX-Uploads können gegen konfigurierte CI-Regeln einer Marke geprüft werden.
• Große gefilterte Batch-Aktionen werden asynchron verarbeitet, damit die Oberfläche reaktionsfähig bleibt.
• Der Prozess-Leitstand erlaubt zusätzliche Retry- und Reprocess-Aktionen für blockierte Workflows.
• Wartende Delivery-E-Mails und Bounce-Fälle können gezielter als bearbeitet markiert werden.
• Die Template-Management-Suche wurde für mehrere Felder erweitert.

• Marken können verwaltet und in der Vorlagenlogik für Corporate-Identity-Varianten genutzt werden.
• Rendering-Konfigurationen beruecksichtigen Marken, um CI-spezifische Elemente bevorzugt auszuwaehlen.
• PDF-Overlays sind als eigener Verwaltungs- und API-Bereich verfügbar.
• Der SPA-Cutover wurde vorbereitet: Backend-rendered UI wurde reduziert, Kompatibilitätsrouten und Password-Reset-Flows wurden ergänzt.
• Swagger und App-Oberfläche wurden weiter an das Branding angepasst.

• Die SPA verlinkt Hilfen und Assistant-Funktionen auf or-documentation.
• Dokumentations-Preview-Buttons wurden auf weitere App-Bereiche ausgeweitet und optisch verbessert.
• Die Dokumentation erhielt lokale MDX-Vorschau, Suche und Assistant-Grundlagen.
• Für kVASy wurde ein Rendering-API-Endpunkt ergänzt.
• Fehlerhafte oder fehlende Referenzen werden in der Oberfläche klarer markiert und können gezielter bereinigt werden.

• Rendering-Requests können nun simuliert werden, inklusive Abkürzungen aus relevanten Prozessansichten.
• Bedingungen in Simulationen lassen sich besser inspizieren, sodass komplexe Vorlagenlogik leichter nachvollziehbar wird.
• Template-Listen unterstuetzen Multi-Field- und Exact-Search-Filter.
• Modale warnen bei ungespeicherten Änderungen, bevor Nutzer versehentlich Inhalte verlieren.
• Fake-Data- und Subclient-Workflows wurden stabilisiert, damit Testdaten sicherer in produktionsnahen Szenarien verwendet werden können.

• Die App erhielt eine integrierte Dokumentationshilfe, damit Fragen direkt im Arbeitskontext beantwortet werden können.
• Der neue Chart Agent unterstuetzt bei der promptgestuetzten Konfiguration von Diagrammen.
• Rendering-Daten und Rendering-Anfragen bieten erweiterte Filter und Suchhervorhebung.
• E-Mail-Vorlagen, Testdaten und Subclient-bezogene API-Aufrufe beruecksichtigen den Mandantenkontext genauer.
• E-Mail-Template-Vorschauen laufen isolierter im iframe, wodurch Styles stabiler und besser pruefbar sind.

• Blockierte Rendering-Elemente können nun per KI analysiert werden. Die Auswertung hilft dabei, Ursachen schneller zu erkennen und betroffene IDs gezielter zu filtern.
• Die neue SPA-Oberfläche unterstuetzt Dark Mode auf authentifizierten Seiten und wichtigen Komponenten.
• Importer und Exporter wurden für Admin-Workflows verbessert, einschließlich klarerer Rollenbegrenzungen.
• Rendering-Listen laden große Datenmengen effizienter: exakte Zaehler und Relation-Counts werden nur noch geladen, wenn sie wirklich benoetigt werden.
• In den Benutzereinstellungen steht eine neue Settings-Verwaltung für authentifizierte Nutzer bereit.