Release Notes

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.