Das Buchungsregister prüfen

Das Buchungsregister ist eine mandantenweite Konsole außerhalb einzelner Projekte, in der Finanzwesen und Buchhaltung ERP-Buchungen über alle Projekte und Verbindungen prüfen, für die sie berechtigt sind. Während der ERP-Buchungsverlauf auf ein einzelnes Projekt beschränkt ist, auf das Sie bereits Zugriff haben, ist das Buchungsregister die projektübergreifende Ansicht für Prüfer, die Buchungen aus vielen Projekten und Verbindungen an einer Stelle sehen müssen.

Das Buchungsregister ist in erster Linie für die Prüfung gedacht. Zwei Massenaktionen – das Leeren simulierter Buchungen und das Wiederholen fehlgeschlagener Buchungen –, ein Wiederholen für einzelne Zeilen im Detailbereich, das Stornieren und das gleichzeitige Stornieren eines ganzen Intercompany-Laufs lassen Sie direkt im Raster und im Detailbereich handeln. Der KI-Assistent hilft Ihnen, Buchungen schneller zu finden und zu verstehen, und mit Trends, Lineage, Kontrollsummen, Abschlüssen und Export analysieren Sie Daten, verfolgen sie zur Quelle zurück, versiegeln eine Periode und exportieren Daten. Die Zusammenarbeit ermöglicht es einem Team, eine Buchung gemeinsam zu kommentieren, freizugeben und zu beobachten, ohne dass je ein Geldbetrag in einer Benachrichtigung auftaucht.

Die Konsole ist ein einziger angedockter Arbeitsbereich und kein Satz schwebender Fenster. Eine Navigationsleiste am linken Rand öffnet jeden Bildschirm – Buchungen, Simuliert, Ausnahmen, Genehmigungen, Delegierungen, Zusammenfassung, Trends, Kontrollsummen, Lineage, Exporte und Benachrichtigungen und KI-Assistent – als Bereich an Ort und Stelle. Beim Wechsel zwischen Bildschirmen ändert sich also der Inhalt in der Mitte des Arbeitsbereichs, statt dass ein weiteres Fenster über das vorherige gelegt wird. Wenn Sie eine Buchung öffnen, schiebt sich ihr Detailbereich von rechts herein, ohne die Liste zu verdecken, mit der Sie gerade arbeiten.

Ein angedockter Arbeitsbereich – die Leiste öffnet einen Bildschirm an Ort und Stelle in der Mitte, und die Details einer Buchung öffnen sich in einem Bereich rechts, ohne die Liste zu verdecken.

Wer es öffnen kann

Zum Öffnen des Buchungsregisters ist einer von vier Keycloak-Realm-Scopes erforderlich – erp.register.view, .operate, .approve und .admin. Es sind voneinander unabhängige Berechtigungen und keine aufeinander aufbauende Stufenfolge: Wer .admin besitzt, erhält dadurch nicht automatisch, was .operate gewährt, und jede ändernde oder datenausleitende Aktion prüft ausdrücklich ihren eigenen erforderlichen Scope bzw. ihre eigenen Scopes, statt sie aus einer höheren Stufe abzuleiten.

Scope	Gewährt
`erp.register.view`	Das Register öffnen und Buchungen prüfen – Ausnahmewarteschlange, Raster, Zusammenfassungen, Trends, Lineage und KI-Assistent. Nichts davon wendet etwas an, exportiert oder benachrichtigt.
`erp.register.operate`	Die Grundlage für alles, was den Zustand ändert oder die Konsole verlässt: Massenaktionen, das Auslösen einer Stornierung, das Anfordern einer Genehmigung dafür, das Öffnen des Genehmigungseingangs und das Entscheiden über eine Anfrage, für die Sie zuständig sind, das Einsehen oder Zurückgeben einer Delegierung, das Exportieren oder Planen einer Zustellung, das Abonnieren des Digests des KI-Assistenten sowie das Verfassen eines Kommentars, einer Freigabe oder einer Beobachtung. Aktionen, die durch `.approve` und `.admin` geschützt sind, werden zusätzlich zu `.operate` geprüft, nie an dessen Stelle – siehe unten.
`erp.register.approve`	Genehmigungsbefugnis für eine Stornierung ab dem Schwellenwert des Mandanten für die Funktionstrennung – entweder durch direkten Besitz dieses Scopes oder durch eine aktive Delegierung von jemandem, der ihn besitzt – sowie das Auflösen eines hängenden Stornierungsversuchs (`released` oder `confirmed`). Wer diese Befugnis an jemand anderen delegiert, muss ebenfalls selbst `.approve` besitzen; Verwenden, Einsehen oder Widerrufen einer Delegierung erfordert das nicht. Alles zusammen mit `.operate`.
`erp.register.admin`	Der Prüferexport und das As-of-Leseprofil (nicht maskierte Beträge und Ersteller-Identität) sowie das Festlegen der Aufbewahrungsrichtlinie des Mandanten – jeweils zusammen mit `.operate`. Außerdem können Sie damit den Zeitplan eines anderen Mitglieds löschen oder auslösen.

Vier integrierte Sicherheitsgruppen fassen diese Scopes der Einfachheit halber kumulativ zusammen – Posting Register Viewer (.view), Operator (fügt .operate hinzu), Approver (fügt .approve hinzu) und Admin (alle vier) –, aber die Matrix der Sicherheitsgruppen erlaubt es, beliebige Kombinationen unabhängig voneinander zuzuweisen, da die Scopes einander nicht implizieren. .approve und .admin sind jeweils für sich allein bedeutungslos: Jede Aktion, die sie schützen, erfordert zusätzlich .operate. Eine Gruppe, die Stornierungen auflösen oder Exporte entmaskieren soll, braucht .operate daher ausdrücklich zusätzlich und nicht stillschweigend aus der höheren Stufe abgeleitet. Weisen Sie die Stufe oder Kombination zu, die dem Zweck eines Mitglieds entspricht, und nicht einfach .view für alle.

Die Sichtbarkeitsregel

Der Besitz eines erp.register.*-Scopes öffnet die Konsole, macht aber für sich allein noch keine Buchung sichtbar. Eine Buchung ist im Register nur sichtbar, wenn Sie zusätzlich eine persönliche Verbindungsberechtigung für die Verbindung der Buchung besitzen und – sofern die Buchung zu einem Projekt gehört – Zugriff auf dieses Projekt haben. Eine Buchung ohne Projektbezug wird allein durch die Verbindungsberechtigung gesteuert.

Dies ist eine eigene Berechtigung, getrennt vom oben genannten Register-Scope, und beide sind erforderlich:

Verbindungsberechtigung. Sie müssen ausdrücklicher Eigentümer der Verbindung sein, einzeln namentlich aufgeführt sein oder Mitglied einer auf ihr genannten Sicherheitsgruppe sein – dieselben Berechtigungen, die das Sicherheitsmodell einer Verbindung steuert. Eine auf All Workspace Members gesetzte Verbindung gewährt keine Sichtbarkeit im Register. Diese Einstellung macht die Verbindung für alle nutzbar; sie ist keine persönliche, gruppenbezogene oder Eigentümerberechtigung, und das Register verlangt ausdrücklich eine davon.
Projektzugriff für jede Buchung, die zu einem Projekt gehört – derselbe Zugriff, den Ihre übrige Projektarbeit erfordert.

Ein Mitglied, das erp.register.view besitzt, aber überhaupt keine Verbindungsberechtigungen hat, sieht ein korrekt leeres Register, und die Konsole weist darauf hin, statt defekt zu wirken. Eine widerrufene Verbindungs- oder Projektberechtigung wirkt sich beim nächsten Laden der Seite aus – es gibt keine veraltete Sichtbarkeit, die erst bereinigt werden müsste.

Was Sie je nach Rolle sehen

Die Konsole ist rollenadaptiv: Ein Eintrag in der Navigationsleiste oder eine Aktionsschaltfläche, für die Ihnen der Scope fehlt, ist ausgeblendet und nicht nur ausgegraut, sodass der Arbeitsbereich immer nur zeigt, was Sie tatsächlich tun können. Das spiegelt wider, was der Server durchsetzt, und ersetzt es nicht:

Sie besitzen	Sie sehen
`erp.register.view`	Die Prüfbildschirme – Ausnahmewarteschlange, Raster, Zusammenfassung, Trends, Lineage, Kontrollsummen und KI-Assistent.
`erp.register.operate`	Zusätzlich die Aktionsschaltflächen: Wiederholen, Stornieren und Leeren simulierter Buchungen.
`erp.register.approve`	Zusätzlich den Genehmigungseingang, Genehmigungsentscheidungen und Delegierung.
`erp.register.admin`	Zusätzlich die Aufbewahrungseinstellungen und den nicht maskierten Prüferexport.

Das Ausblenden eines Bedienelements dient nur der Darstellung – es erspart Ihnen Angebote, die abgelehnt würden. Maßgeblich bleibt der Server: Jede ändernde oder datenausleitende Aktion prüft im Moment der Ausführung erneut ihren eigenen erforderlichen Scope sowie Ihre Verbindungs- und Projektberechtigungen. Nichts ist erlaubt, nur weil der Client eine Schaltfläche angezeigt hat, und nichts ist wirklich gesperrt, nur weil der Client eine ausgeblendet hat.

Die Ausnahmewarteschlange

Beim Öffnen des Registers landen Sie in der Ausnahmewarteschlange und nicht im Raster – den Buchungen, die am ehesten Ihre Aufmerksamkeit brauchen, gruppiert in vier Kategorien und in Prioritätsreihenfolge angezeigt:

Ungewiss – die Buchung wurde übermittelt, und nichts bestätigt bisher, was daraus geworden ist.
Unbestätigt – übermittelt und über die Frist hinaus, bis zu der sie bestätigt sein sollte.
Ausstehend – eine asynchrone Buchung, die über die Frist hinaus ist, bis zu der sie abgeschlossen sein sollte.
Fehlgeschlagen – vom ERP abgelehnt.

Jede Kategorie erscheint als Zählkachel über der Warteschlange und zeigt ihre aktuelle Gesamtzahl, sodass der Umfang der Arbeit sichtbar ist, bevor Sie etwas öffnen. Wenn Sie eine Kachel auswählen, wird die Warteschlange auf diese Kategorie gefiltert, während die anderen Kacheln weiterhin ihre eigenen Summen zeigen – der Wechsel zu Fehlgeschlagen lässt die Anzahl bei Ungewiss also nie leer erscheinen.

„Überfällig“ wird an den eigenen Timern der Plattform gemessen und nicht an einem erfundenen Schwellenwert, sodass eine Buchung genau dann in einer Kategorie landet, wenn die Plattform selbst sie als überfällig bezeichnen würde. Innerhalb jeder Kategorie stehen die ältesten Buchungen zuerst.

Simulierte Buchungen erscheinen nie in der Warteschlange oder in ihren Zählern – die Warteschlange gibt an, wie viele ausgeschlossen wurden, sodass eine niedrige Anzahl nie mit „nichts zu prüfen“ verwechselt wird, wenn Simulationen der Grund sind. Das Filtern auf eine Kategorie schränkt die angezeigten Zeilen ein; es ändert nicht, was die Zähler der anderen Kategorien angeben, sodass der Wechsel zu Fehlgeschlagen Ungewiss nie leer erscheinen lässt.

Hier gilt dieselbe Sichtbarkeitsregel wie im Raster: Sie sehen nur Ausnahmen zu Buchungen, die an eine Verbindung gebunden sind, für die Sie persönlich berechtigt sind, in einem Projekt, auf das Sie Zugriff haben.

Noch offene Stornierungen

Die Ausnahmeliste über die API, GET /erp/register/exceptions, meldet außerdem eine fünfte Kategorie, reversal_outstanding: eine gebuchte Buchung, deren Stornierung gesendet, aber nie abgeschlossen wurde – das ERP hat nicht geantwortet, oder der Versuch wurde mitten in der Übermittlung abgebrochen. Sie hat neben den anderen vier einen eigenen Zähler, wird zusammen mit Ungewiss ganz oben einsortiert, und jede Zeile nennt den Stornierungsversuch und seinen Zustand. Eine solche Buchung bleibt in der Liste, bis sie aufgelöst ist, wie unter Stornieren beschrieben; sie verfällt nicht von selbst.

Verbindungsstatus

Ein Banner über der Ausnahmewarteschlange und den Zusammenfassungen (unten) beantwortet eine Frage, die keine von beiden allein beantwortet: Ist eine Ihrer Verbindungen ausgefallen? Für jede Verbindung, für die Sie persönlich berechtigt sind – und nur für diese – zeigt es die letzte erfolgreiche Buchung und ob die Verbindung derzeit Fehler meldet. Eine berechtigte Verbindung ohne Buchungen wird als solche ausgewiesen, statt in der Liste zu fehlen, und wenn die Statusprüfung selbst nicht abgeschlossen werden kann, sagt das Banner auch das, statt stillschweigend „alles in Ordnung“ zu melden.

Betragsformatierung

Jeder Betrag, den das Register anzeigt – Raster, Zusammenfassung, Kontrollsummen, Detailbereich, Ausnahmewarteschlange, Genehmigungseingang, KI-Assistent und der Stornierungsdialog –, wird als Buchhaltungszahl dargestellt: Tausendertrennzeichen, Negativwerte in Klammern und tabellarische (dickengleiche) Ziffern, sodass eine Betragsspalte am Dezimaltrenner ausgerichtet ist. Die Nachkommastellen richten sich nach der Währung selbst und nicht pauschal nach zwei – JPY zeigt keine, KWD drei.

Zwischensummen werden nie über Währungen hinweg addiert. Eine Gruppe oder ein Stapel mit mehr als einer Währung wird in je eine Zeile pro Währung aufgeteilt, jeweils mit der eigenen Währung beschriftet, sowohl in den Zusammenfassungen als auch in den Kontrollsummen – nirgends in der Plattform wird ein Wechselkurs angenommen.
Die Rundung für die Anzeige verbirgt nie eine echte Differenz. Wo das Runden auf die üblichen Nachkommastellen der Währung eine von null verschiedene Ziffer verlieren würde, zeigt der Detailbereich den genau erfassten Wert neben dem gerundeten. Die Werte der Kontrollsummen werden aus demselben Grund nie gerundet: Eine gegen eine Toleranz geprüfte Differenz bleibt in voller Genauigkeit, sodass eine echte Differenz außerhalb der Toleranz wie 0.004 neben einem Befund „Nicht ausgeglichen“ nicht als 0.00 erscheinen kann.

Das Registerraster

Wechseln Sie zum Raster, um alle Buchungen statt nur die Ausnahmen zu sehen – es listet Buchungen aus allen Projekten und Verbindungen auf, die Sie sehen können, eine Zeile pro Buchung. Am oberen Rand des Rasters verläuft eine Bereichsleiste, mit der Sie eingrenzen, was Sie betrachten:

Projekt
Umgebung
Verbindung
ERP-Typ
Entität
Buchungsdatum
Zustand
Buchungsmodus

Um einen eigenen ERP-Typ-Filter aufzubauen, liefert GET /erp/register/erp-types alle ERP-Typen der für Sie sichtbaren Buchungen in sortierter Reihenfolge.

Die Bereichsleiste verwendet Auswahllisten: Sie wählen ein Projekt, eine Verbindung oder eine Entität anhand des Namens aus einer Liste, die auf das beschränkt ist, was Sie sehen dürfen, statt eine Kennung einzutippen. Zustand ist eine Mehrfachauswahl, sodass Sie mehrere Zustände gleichzeitig beobachten können.

Buchungsmodus ist ein stets sichtbarer Schalter mit drei Schaltflächen, an dem Sie auf einen Blick erkennen, was die Zahlen umfassen. Live zeigt nur Buchungen, die das ERP erreicht haben, Simuliert zeigt nur Buchungen aus Ausführungen im Simulationsmodus, und Alle (Standard) zeigt beide. Die Spalte Buchungsmodus des Rasters zeigt, von welcher Art jede Zeile ist. Die Bildschirme Reconcile und Zusammenfassung haben eine eigene Auswahl Buchungsmodus mit denselben Optionen, standardmäßig auf Live. Wenn der Modus nicht Live ist, weist ein Hinweis neben den Betragssummen darauf hin, dass sie simulierte Buchungen enthalten, die das ERP nie erreicht haben, bzw. unter Simuliert, dass keine das ERP erreicht hat. Was immer Sie eingestellt haben, bleibt während der Arbeit auf dem Bildschirm sichtbar, sodass Sie nie raten müssen, was das Raster gerade anzeigt.

Massenaktionen

Wählen Sie im Raster mehr als eine Buchung aus und führen Sie eine Aktion für alle gemeinsam aus. Wählen Sie Buchungen aus, indem Sie ihre Zeilen ankreuzen oder select all matching the current filter wählen – das erfasst jede Buchung, die der Filter über alle Seiten hinweg trifft, und nicht nur die bereits geladenen.

Es stehen zwei Aktionen zur Verfügung:

Simulierte Buchungen leeren – ein Soft Delete für simulierte Buchungen, die Sie nicht mehr aufbewahren müssen.
Fehlgeschlagene Buchungen wiederholen – Buchungen erneut senden, die das ERP abgelehnt hat oder die nie gesendet wurden.

Die Auswirkungsvorschau

Bevor eine der beiden Aktionen ausgeführt wird, zeigt PlaidCloud eine Auswirkungsvorschau: wie viele Buchungen betroffen sind, die beteiligten Beträge (nach Währung aufgeschlüsselt – Beträge werden nie über Währungen hinweg vermischt, und ein nicht erfasster Betrag erscheint leer, nie als 0.00) sowie zu welchen Verbindungen und Entitäten die betroffenen Buchungen gehören. Alles in Ihrer Auswahl, das die Aktion nicht berühren kann, wird gesondert ausgewiesen, sodass „24 Ihrer 30 ausgewählten Buchungen bewirken nichts“ vor der Bestätigung sichtbar ist und nicht erst danach auffällt.

Bestätigung durch Eintippen

Ab einem Schwellenwert bleibt Apply deaktiviert, bis Sie den betroffenen Betrag genau eintippen.

Wiederholen läuft nur gegen das, was Sie angekreuzt haben

Das Leeren simulierter Buchungen kann gegen beide Arten der Auswahl laufen – angekreuzte Zeilen oder alles, was Ihrem Filter entspricht. Das Wiederholen als Massenaktion kann das nicht: Es läuft ausschließlich gegen Buchungen, die Sie einzeln angekreuzt haben. Eine filterweite Auswahl hat keine feste Liste von Buchungen, an die sich das Wiederholen binden ließe. Daher verlangt das Wiederholen, dass Sie die Buchungen wieder einfügen, und lehnt die Ausführung ab, sofern das Eingefügte nicht exakt dem entspricht, was die Vorschau gezeigt hat – dieselben Buchungen, keine Duplikate und dieselbe Anzahl. Diese Bindung hält die Bestätigung ehrlich: Der Stapel, den Sie bestätigt haben, ist der Stapel, der gesendet wird.

Was wiederholt werden kann

Nur eine Buchung, die das ERP abgelehnt hat oder die nie gesendet wurde, kann wiederholt werden. Eine Buchung, die noch unterwegs, ungewiss oder bereits gebucht ist, lässt sich von hier aus nicht wiederholen.

Wo das ERP der Verbindung es unterstützt, fragt PlaidCloud vor dem Wiederholen direkt beim ERP nach: Hält das ERP das Dokument bereits als gebucht, wird das Wiederholen abgelehnt und stattdessen das Stornieren vorgeschlagen. Kann das ERP diese Prüfung nicht beantworten, wird das Wiederholen abgelehnt, statt es zu riskieren – es wird nie geraten. Einige Verbindungen unterstützen diese Prüfung überhaupt nicht; bei ihnen stützt sich das Wiederholen auf die erfasste Ablehnung der Buchung selbst.

Das Wiederholen erfordert erp.register.operate und Ihre eigene persönliche Berechtigung für die Verbindung dieser Buchung – dieselbe Verbindungsberechtigung, die Die Sichtbarkeitsregel verlangt, um die Buchung überhaupt zu sehen.

Wiederholen im Detailbereich

Der Detailbereich einer Buchung enthält neben den Beobachtungssteuerungen auch eine eigene Schaltfläche Wiederholen – dasselbe Wiederholen, jeweils für eine Zeile, erreichbar ganz ohne Umweg über das Raster. Es ist kein Ein-Klick-Vorgang: Beim Öffnen sehen Sie dieselbe Auswirkungsvorschau und ab dem Schwellenwert dieselbe Bestätigung durch Eintippen wie bei der Massenaktion – es gibt genau einen Wiederholungsweg, der von zwei Stellen aus betreten wird. Die Schaltfläche erscheint bei jeder Zeile für ein Mitglied mit erp.register.operate; der Detailbereich beurteilt eine Zeile nie vorab als wiederholbar, bevor er die Schaltfläche anbietet. Eine Zeile, die sich als nicht infrage kommend herausstellt – bereits gebucht, unterwegs oder vom ERP bereits gehalten –, wird daher von der Vorschau mit der eigenen Begründung des Servers abgelehnt und nicht stillschweigend ausgeblendet.

Simulierte Buchungen leeren

Das Leeren ist ein Soft Delete: PlaidCloud erfasst, wer geleert hat und wann, und verlangt eine Begründung, bevor Apply aktiviert wird. Es entfernt die Buchungen aus dem Vorschauspeicher der Simulation und dem eigenen Simulationsjournal des Ledgers – es berührt nie eine Live-Buchung, und es gibt keine Möglichkeit, es auf eine zu richten.

Die Ansicht „Simulierte Buchungen“

Simulierte Buchungen öffnet sich als Bereich aus der Navigationsleiste und listet auf, was im Simulationsspeicher liegt, statt Sie simulierte Zeilen im Hauptraster suchen zu lassen. Filtern Sie nach Verbindung, Projekt, Umgebung oder Simulationslauf-ID.

Geleerte einschließen ist standardmäßig deaktiviert, entsprechend dem eigenen Standard des Servers: Eine geleerte Zeile ist der Prüfnachweis eines Leerens und wird deshalb kurz aufbewahrt, sodass die Ansicht mit dem beginnt, was im Speicher noch aktiv ist, und nicht mit ihrer eigenen Historie.
Das Leeren von hier aus läuft weiterhin über dieselbe Auswirkungsvorschau wie die Massenaktion im Raster – nie als Ein-Klick-Leeren – und ist auf das beschränkt, was die Filter der Ansicht gerade treffen.
Die Zusammenfassungszeile der Ansicht meldet außerdem dieselbe Kennzahl simulated_excluded, die die Ausnahmewarteschlange zeigt – wie viele simulierte Buchungen im Buchungs-Ledger, einer vom Simulationsspeicher getrennten Tabelle, aus der Warteschlange herausgehalten werden, weil eine simulierte Zeile das ERP nie erreicht hat und daher nie eine Ausnahme ist.

KI-Assistent

Assistent öffnet ein Suchfeld, eine Reihe proaktiver Karten und einen Ratgeberbereich pro Zeile – jede darin angezeigte Zahl wird vom Register selbst über Ihre eigenen aktuellen Berechtigungen berechnet; das Modell, sofern eines konfiguriert ist, erklärt oder entwirft nur und erfindet nie eine Zahl oder ein Prädikat.

In einfachen Worten fragen

Tippen Sie einen Satz ein – „Buchungen im Zustand ungewiss für die EMEA-Verbindung der letzten Woche“ –, und er wird mithilfe einer festen Tabelle, nicht durch einen Modellaufruf, in das eigene Filtervokabular des Registers übersetzt: Eine Übersetzung kann die Zeilen, die Ihnen das Raster ohnehin zeigen würde, nur eingrenzen und nie eine Zeile erreichen, für die Sie nicht berechtigt sind. Die einzige Aufgabe des Modells ist es, die Übersetzung in einem Satz zu erklären: Es nennt das Feld, dem zugeordnet wurde, und wie viele Ihrer Zeilen der resultierende Filter findet.

Proaktive Karten

Sieben Karten fassen zusammen, was einen Blick wert ist, jeweils mit einer aktuellen Anzahl und Beispielzeilen, die auf Ihre eigenen Berechtigungen beschränkt sind: Bis zum Abschluss offen, Beinahe-Duplikate, die Nullsaldo-Abweichung bei Intercompany, Geändert gegenüber letztem Abschluss, Im ERP bestätigt, Alterung und Verantwortliche und Bereits storniert. Neben den Zahlen steht ein kurzer erzählender Satz, wenn für Ihren Workspace eine LLM-Verbindung konfiguriert ist; ist keine vorhanden, wird die Karte dennoch vollständig dargestellt und nennt den Grund, warum der Satz fehlt. Ein nicht erfasster Betrag auf einer Karte ist immer leer, nie 0.00 – dieselbe Regel, der auch die Zusammenfassungen folgen.

Hinweise pro Zeile

Wählen Sie eine Buchung aus und erhalten Sie je nach ihrem Zustand zwei Arten von Hinweisen:

Ein Stornoentwurf für jede Buchung – wie ein Stornieren aussehen würde: ob der Treiber der Verbindung es überhaupt unterstützt, welche Kontrollsumme dafür abgestimmt werden müsste und eine Periodenprüfung. Es ist nur ein Entwurf; nichts hier storniert etwas.
Fehlerhinweis für eine abgelehnte oder ungewisse Buchung – warum sie fehlgeschlagen ist, ob sie wiederholt oder zuerst die Quelldaten korrigiert werden sollten, welches Feld zu korrigieren ist und welches Duplikatrisiko ein Wiederholen birgt. Die Fehlermeldung des ERP selbst ist Freitext und wird daher serverseitig einer Ursache zugeordnet, statt Ihnen direkt angezeigt zu werden – dieselbe Regel, die Freitext aus dem restlichen Register heraushält.

Der tägliche Digest

Ein Digest zeigt auf Abruf eine Vorschau der obigen Karten, beschränkt auf eine abschlussrelevante Teilmenge – Bis zum Abschluss offen, Alterung und Verantwortliche, Beinahe-Duplikate, Nullsaldo-Abweichung bei Intercompany und Im ERP bestätigt –, so wie sie Ihnen heute zugestellt würden. Ein Schalter abonniert oder kündigt das Abonnement; das Abonnement speichert nichts außer Ihrer Mitglieds-ID, sodass eine Berechtigung, die Sie danach verlieren, diese Zeilen einfach aus Ihrem nächsten Digest entfallen lässt, statt eine veraltete Ansicht preiszugeben.

Stornieren

Das Stornieren einer Buchung – das Anlegen eines neuen, entgegengesetzten Dokuments im ERP – ist über das Bedienelement Stornieren des Detailbereichs möglich, für die Automatisierung auch direkt über die API.

Die Eignung hängt vom eigenen Zustand der Buchung ab (nur eine gebuchte Buchung mit bestätigter ERP-Dokument-ID kann storniert werden), vom Treiber der Verbindung (Business Central, Oracle Fusion und Acumatica unterstützen überhaupt kein programmgesteuertes Stornieren und sagen das beim Versuch) und davon, ob bereits ein Stornierungsversuch für sie aussteht. Der Detailbereich prüft die Eignung sowohl beim Öffnen von Stornieren als auch unmittelbar vor dem Absenden erneut. Eine Zeile, die dazwischen veraltet ist – etwa weil bereits eine andere Stornierung aussteht –, zeigt daher die Ablehnung des Treibers in dessen eigenen Worten, statt eine zum Scheitern verurteilte Anfrage abzusetzen.
Das Stornieren erfordert erp.register.operate und ist hinter eine Bestätigung durch Eintippen gestellt: Sie geben die eigene ERP-Dokument-ID der Buchung erneut ein, nur im Browser geprüft und nie gesendet, bevor Stornieren freigeschaltet wird – dasselbe Reichweitenmuster wie bei den Massenaktionen, eine Sicherheitsabfrage und kein Genehmigungsschritt.
Beim Stornieren kann die neue Buchung optional in eine andere Zielperiode als die ursprüngliche Buchung umgeleitet werden – unterstützt bei Adaptern, deren ERP eine explizite Buchungsperiode akzeptiert, und mit einer klaren Fehlermeldung abgelehnt bei solchen, die sie nicht ansteuern können. Eine Umleitung kann dennoch in einer anderen Periode als angefordert landen: Manche Adapter erfahren erst nach der Absendung, ob sie sie eingehalten haben, sodass der Detailbereich eine Zielperiode erst nennt, wenn der Versuch tatsächlich als storniert abgeschlossen ist – nie früher – und sich bei jedem anderen Ergebnis auf die eigene Meldung des Servers stützt. Eine harte Datenbanksperre verhindert, dass ein zweiter Stornierungsversuch abgesetzt wird, solange einer aussteht, selbst bei einem Prozessabsturz mitten in der Absendung; eine Ablehnung durch das ERP gibt diese Sperre automatisch frei, da nichts angelegt wurde.
Jeweils nur eine Stornierung, egal wo sie beginnt. Eine Stornierung aus dem Buchungsregister und eine aus einem Workflow oder der Stornierungs-API auf Projektebene teilen sich dieselbe Sperre, und jede liest die Buchung neu ein, sobald sie sie hält, sodass eine Buchung nie doppelt storniert wird – weder durch eine erneute Ausführung noch durch zwei gleichzeitige Anfragen.
Eine unbekannte Antwort wird gehalten, nicht geraten. Wenn das ERP in ein Timeout läuft, einen Serverfehler zurückgibt oder in einer Weise antwortet, die PlaidCloud nicht erkennt, wird die Stornierung als in_doubt erfasst statt als abgelehnt, und die Sperre bleibt gehalten. Ein Stornodokument gilt nur dann als Stornierung, wenn es das Original spiegelt – gleiche Entität und Währung, nicht früher datiert, bei jeder Position Soll und Haben vertauscht; alles andere bleibt ungewiss und muss von Ihnen geprüft werden.
Eine Stornierung im Zustand pending oder in_doubt – ihr Ergebnis ist unbekannt – bleibt so, bis sie geklärt wird. Bei Workday und Dynamics 365 Finance & Operations schlägt PlaidCloud eine Stornierung im Zustand in_doubt beim nächsten Stornierungsversuch dieser Buchung im ERP nach und klärt sie anhand des Gefundenen. Eine Stornierung im Zustand pending bei diesen Verbindungen sowie jede ungeklärte Stornierung bei allen anderen Verbindungen wird mit den Auflösungssteuerungen des Detailbereichs bereinigt, die zusätzlich zu .operate an erp.register.approve gebunden sind: Ein Mensch prüft das ERP direkt und erfasst, was er gefunden hat – Freigeben (dort wurde nichts angelegt, das Ledger bleibt also unberührt, und die Buchung ist wieder stornierbar) oder Als storniert markieren (es existiert ein Stornodokument, mit seiner ID) –, und das ist der einzige Weg, diese Sperre je freizugeben. Das Markieren einer Stornierung als confirmed ist endgültig; über das Produkt gibt es kein Rückgängigmachen.

Funktionstrennung

Eine Stornierung ab dem konfigurierten Schwellenwert Ihres Mandanten erfordert eine Genehmigung, bevor sie fortgesetzt wird – und die Genehmigung ist etwas, das ein Genehmiger tut, kein Name, den der Einreicher in der Anfrage angibt.

Ersteller ≠ Prüfer. Das Mitglied, das die Stornierung einreicht, kann nicht zugleich ihr Genehmiger sein und auch nicht sein eigener Break-Glass-Autorisierer.
Nach Betragshöhe gemessen. Der Schwellenwert vergleicht die Höhe der Stornierung unabhängig vom Vorzeichen – das Stornieren einer Gutschrift wird genauso gemessen wie das Stornieren einer Belastung.
Kürzliche Stornierungen zählen zum Schwellenwert. Ein gleitendes Zeitfenster summiert die eigenen Stornierungen eines Einreichers auf derselben Verbindung, sodass eine große Stornierung nicht in mehrere kleinere aufgeteilt werden kann, um unter dem Schwellenwert zu bleiben. Beträge werden nach Betragshöhe addiert und nicht saldiert – eine negative und eine positive Stornierung heben sich nicht gegenseitig auf.
Im Zweifel gesperrt. Kann eine frühere Stornierung im Zeitfenster nicht verifiziert werden – etwa wegen eines nicht erfassten Betrags oder einer nicht erfassten Währung –, erfordert die Stornierung eine Genehmigung, statt die Prüfung zu überspringen.
Der Genehmiger muss qualifiziert sein. Er braucht erp.register.approve – oder eine aktive Delegierung von jemandem, der es besitzt – und seine eigene Berechtigung für die zu stornierende Verbindung. Besitzen weniger als zwei Mitglieder beides, werden Stornierungen ab dem Schwellenwert abgelehnt, statt sie durchzulassen.
Break-Glass bleibt der einzige Weg, bei dem der Einreicher direkt benennt, wer eine Ausnahme autorisiert hat: ein echter Notfall, entschieden von einem Autorisierer, der von der operativen Kette unabhängig ist – er besitzt erp.register.admin, aber nicht .operate oder .approve, plus seine eigene Berechtigung für die Verbindung –, und jede Ausnahme wird dauerhaft im Prüfpfad erfasst.
Eine Ablehnung nennt den Grund nicht. Ob eine Anfrage keinen qualifizierten Genehmiger hat, von der falschen Person entschieden oder nie geöffnet wurde: Die Stornierung wird mit derselben Meldung abgelehnt – mit Absicht, damit eine Ablehnung nicht dazu benutzt werden kann, auszukundschaften, wer welche Rolle oder Berechtigung hält. Der tatsächliche Grund steht im Prüfpfad, nicht in der Fehlermeldung.
Eine Lauf-Stornierung braucht eine Genehmigung pro Position, nicht eine für den Lauf. Das Stornieren eines ganzen Intercompany-Laufs auf einmal erhält keine einzelne Genehmigung auf Laufebene – jede Position braucht ihre eigene, weil eine Genehmigung an eine Buchung, eine Verbindung und einen Genehmiger mit einer Berechtigung dort gebunden ist und es keinen einzelnen Namen gibt, an den sich die Positionen eines ganzen Laufs binden ließen.
Stornierungen laufen über das Register. Solange die Funktionstrennung aktiv ist, wird eine Stornierung, die über die ERP-Stornierungs-API auf Projektebene angefordert wird – den Weg, den ein Projekt, eine benutzerdefinierte Funktion oder ein Dienstkonto nutzt –, abgelehnt, bevor etwas das ERP erreicht, mit dem Hinweis, stattdessen im Buchungsregister zu stornieren. Eine Buchung, zu der das Register keine Erfassungsdetails hält, kann dort ebenfalls nicht storniert werden und muss im ERP korrigiert werden. Buchungen sind davon nicht betroffen, und Business Central, Oracle Fusion und Acumatica nennen weiterhin ihren eigenen Grund – dass sie das Stornieren nicht unterstützen.

Das Aktivieren der Funktionstrennung und das Festlegen ihres Schwellenwerts wird für Ihren Mandanten von PlaidCloud konfiguriert – dafür gibt es noch keinen Schalter in der Konsole.

Der Genehmigungseingang

Wenn der Schwellenwert eine Genehmigung verlangt, leitet Genehmigung anfordern – im Detailbereich neben Stornieren angeboten – die Stornierung an jeden Genehmiger weiter, der eine aktive persönliche Berechtigung für diese Verbindung besitzt. Es gibt niemanden, an den sie adressiert werden müsste; die Verbindungsberechtigung ist das Routing. Genehmiger bearbeiten die Warteschlange unter Genehmigungen in der Navigationsleiste: ein Eingang mit Anfragen, die auf ihre Entscheidung warten, und eine zweite Warteschlange mit den Anfragen, die sie selbst eingereicht haben. Jede Zeile enthält Betrag, Entität und Periode der Buchung sowie die bisherige Wartezeit, sodass das Entscheiden nie bedeutet, die Warteschlange zu verlassen, um zuerst etwas nachzuschlagen. Genehmigen oder Ablehnen erfordert eine Begründung, die zusammen mit der Entscheidung erfasst wird.

Eine Genehmigung ist an genau das gebunden, wofür sie erteilt wurde – die Buchung, ihre Verbindung, die angegebene Begründung und die Zielperiode – und kann nicht für eine andere Stornierung, eine andere Begründung oder eine geänderte Zielperiode wiederverwendet werden; eine geänderte Anfrage braucht eine neue Genehmigung. Pro Buchung kann nur eine Anfrage gleichzeitig offen sein, und eine Genehmigung ist in dem Moment verbraucht, in dem sie eingelöst wird. Auf jede Genehmigung folgt eine kurze Haltefrist, in der Genehmiger oder Einreicher sie noch abbrechen können – nach Ablauf der Frist kann die Stornierung bereits ein Dokument im ERP sein, und nichts macht das rückgängig. Alles wird in dem Moment, in dem die Stornierung tatsächlich angewendet wird, erneut geprüft – die Rolle des Genehmigers, der Zugriff beider Parteien auf die Verbindung und das Minimum von zwei Genehmigern des Mandanten –, sodass eine früher erteilte Genehmigung nicht überdauert, wenn der Genehmiger zwischenzeitlich den Zugriff verliert.

Delegierung

Ein Genehmiger kann seine Genehmigungsbefugnis für ein begrenztes Zeitfenster an ein anderes Mitglied delegieren, über den Bereich Delegierungen in der Navigationsleiste – nützlich, wenn ein Genehmiger nicht erreichbar sein wird und Stornierungen dennoch entschieden werden müssen. Das Erteilen einer Delegierung erfordert erp.register.approve; das Verwenden, das Einsehen der eigenen und das Zurückgeben einer Delegierung erfordern nur .operate, da der typische Delegierte die Genehmigerrolle gar nicht besitzt – genau darum delegiert man an ihn.

Eine Selbstdelegierung wird abgelehnt, ebenso ein wechselseitiges Paar (an jemanden delegieren, der bereits an Sie delegiert hat) oder jede längere Kette – nichts davon wird anerkannt, damit zwei Mitglieder nicht stillschweigend die Entscheidungen des jeweils anderen so zählen lassen können, dass sie beide abdecken, direkt oder über einen Zwischenschritt. Ersteller ≠ Prüfer gilt auch bei einer Delegierung weiter: Ein Delegierter kann weder eine Anfrage der Person genehmigen, die an ihn delegiert hat, noch in beide Richtungen eine eigene Anfrage. Jede Entscheidung eines Delegierten wird im Prüfpfad als unter der Befugnis des delegierenden Genehmigers getroffen erfasst und nicht so, als besäße der Delegierte die Rolle selbst.

Eskalation

Eine Genehmigung, die zu lange ohne Entscheidung bleibt, löst eine Benachrichtigung aus, damit sie nicht unbemerkt in einer Warteschlange altert, die niemand beobachtet. Jeder Empfänger erfährt nur von den Anfragen, über die er selbst tatsächlich entscheiden könnte – die Eskalations-E-Mail an eine Kollegin oder einen Kollegen nennt nie eine Anfrage, die an die Berechtigungen einer anderen Person geleitet wurde –, und die Benachrichtigung enthält weder einen Betrag noch Freitext, dieselbe Datensparsamkeit, der auch die übrigen Benachrichtigungen des Registers folgen.

Intercompany-Läufe

Ein Intercompany-Lauf ist die Gruppe von Buchungen – seine Positionen –, die gemeinsam für einen Abschluss erstellt wurden, identifiziert durch Abschlusstag und Sequenz, die ihnen zu diesem Zeitpunkt aufgeprägt wurden, nie durch den Workflow-Lauf, der sie erzeugt hat. (Diese Workflow-Lauf-ID lebt separat in der eigenen Historie des Ledgers weiter und kann den Abschlussstempel einer Buchung überdauern, ist also kein sicheres Mittel zur Identifikation eines Laufs.) Listen Sie Läufe auf, öffnen Sie einen, um seine abgestimmten und gepaarten Positionen zu sehen, und stornieren Sie den ganzen Lauf als einzelne gesteuerte Aktion.

Vorerst nur über die API erreichbar – GET /erp/register/runs, GET /erp/register/runs/{run_day}/{sequence} und POST /erp/register/runs/{run_day}/{sequence}/reverse –, es gibt noch keinen Konsolenbildschirm dafür.

Nullsaldo und Paarung

Wenn Sie einen Lauf öffnen, werden seine Positionen auf zwei Arten abgestimmt, beide beschränkt auf die Verbindungen, für die Sie persönlich berechtigt sind – dieselbe Sichtbarkeitsregel wie überall im Register, sodass ein Lauf über Verbindungen, die Sie nur teilweise sehen, als teilweise sichtbar gemeldet wird und nicht als nicht ausgeglichen.

Nullsaldo, pro Währung: ein Befund Ausgewogen, Nicht ausgeglichen oder Unbestimmt, mit den hinter jedem Saldo stehenden Entitäten aufgeschlüsselt. Eine Währung gilt nur dann als abgestimmt, wenn jede Position darin erfasst wurde – eine nicht erfasste Position macht die ganze Währung Unbestimmt, nie ein Saldo, der nur über das berechnet wird, was zufällig gemessen wurde.
Paarung ordnet jede Verbindlichkeitsposition ihrem Forderungsgegenstück über einen Paarungsschlüssel zu, den der Buchungs-Workflow in beide einträgt, bevor eine von beiden übermittelt wird. Ein zugeordnetes Paar saldiert in einer Währung auf null; alles andere trägt einen benannten Grund – keine für Sie sichtbare Gegenposition, ein nicht erfasster Betrag, ein Saldo, der tatsächlich nicht null ist, oder währungsübergreifend, was gemeldet und nie abgestimmt wird, da es nirgends in der Plattform einen Wechselkurs gibt.

Ein Lauf mit mehr als 200 Positionen ist zu groß, um in einer Antwort abgestimmt oder gepaart zu werden: Beides kommt Unbestimmt zurück, statt über einen abgeschnittenen Ausschnitt des Laufs berechnet zu werden, sodass ein großer Lauf nie einen falschen Saldo oder eine falsche fehlende Gegenposition meldet, die allein durch seine Größe verursacht wurde.

Einen Lauf stornieren

Stornieren Sie alle Positionen eines Laufs in einer Aktion über POST /erp/register/runs/{run_day}/{sequence}/reverse.

Die Eignung wird vorab für jede Position geprüft. Alles, was sich im Voraus wissen lässt – Zustand, Adapterunterstützung, ein ausstehender Versuch, Ihre eigene Verbindungsberechtigung –, lehnt den ganzen Lauf ab, bevor eine einzige Anfrage ein ERP erreicht.
Was sich nicht vorab wissen lässt, wird hinterher pro Position gemeldet. Der Live-Zustand des ERP und der Autorisierung kann sich mitten im Lauf ändern, sodass ein Lauf teilweise storniert enden kann, obwohl bei der Vorabprüfung nichts auffällig war. Nichts wird automatisch kompensiert – weitere Dokumente zu buchen, um einen Teilfehler aufzulösen, ist ein riskanterer Schreibvorgang als der, der fehlgeschlagen ist. Ein Teillauf wird Position für Position bereinigt, genauso wie eine einzelne Stornierung.
Das erneute Ausführen einer Lauf-Stornierung ist der Weg, einen Teillauf abzuschließen. Positionen, die ein früherer Versuch bereits storniert hat, werden beiseitegelegt statt abgelehnt, sodass ein neuer Versuch nur das stornierte, was tatsächlich noch übrig ist.
Die Funktionstrennung gilt pro Position, nicht für die Summe des Laufs. Wenn die SoD-Richtlinie Ihres Mandanten durchgesetzt wird, braucht jede Position ihre eigene Genehmigung, bevor der Lauf irgendetwas absetzt – bei jedem Betrag, nicht nur oberhalb des Schwellenwerts. Das ist bewusst konservativ: Die eigene Anforderung einer Position lässt sich erst in dem Moment klären, in dem sie abgesetzt wird – ein gleitendes Anti-Stückelungs-Zeitfenster, das die eigenen Positionen des Laufs beim Stornieren mitzählt, und ein Live-Rücklesen aus dem ERP, das fehlschlagen kann –, sodass das Verlangen aller Genehmigungen im Voraus verhindert, dass ein Lauf die Hälfte seiner Positionen storniert und erst mittendrin feststellt, dass auch der Rest eine Genehmigung braucht.
Massenaktionen decken den ganzen Lauf in einem Aufruf ab. POST /erp/register/runs/{run_day}/{sequence}/approval-requests öffnet für jede Position, für die der Einreicher handeln kann, eine Genehmigungsanfrage, und POST .../approval-decisions entscheidet jede Position, für die ein Genehmiger qualifiziert ist – je ein Aufruf statt einer Anfrage und einer Entscheidung pro Position (20 Aufrufe bei einem üblichen Lauf mit 10 Positionen). Das darunterliegende Sicherheitsmodell bleibt unverändert: Jede Position erhält weiterhin ihre eigene Genehmigung, gebunden an diese Buchung, ihre Verbindung, die Begründung und die Zielperiode, und der Genehmiger braucht weiterhin seinen eigenen Zugriff auf die Verbindung jeder Position – eine Position, die er nicht autorisieren kann, bleibt einfach für jemanden ausstehend, der es kann, und wird nie mitgerissen. Ein Aufrufer ganz ohne Genehmigungsbefugnis wird rundheraus abgelehnt, ohne zu erfahren, für welche Positionen Anfragen offen sind. Die Ergebnisse kommen pro Position zurück, sodass ein teilweise autorisierbarer Lauf genau meldet, welche Positionen entschieden wurden und welche ausstehend blieben, und warum.
Break-Glass ist für eine Lauf-Stornierung nicht verfügbar. Es ist eine Zwei-Personen-Ausnahme für eine einzelne Buchung, und die Autorisierung eines Zeugen auf einen ganzen Lauf anzuwenden, würde sie mit der Anzahl seiner Positionen vervielfachen. Nehmen Sie Break-Glass stattdessen pro Position über POST /entries/{ledger_id}/reverse in Anspruch.
Läufe mit mehr als 200 Positionen können nicht als eine Aktion storniert werden. Stornieren Sie sie stattdessen in Teilen aus der Eintragsliste.

Trends

Trends zeigt Fehlerrate und Latenz, gruppiert nach Verbindung oder ERP-Typ, sowie die Verteilung der Ursachencodes von Stornierungen – jede Zahl, einschließlich jedes Nenners, wird über Ihre eigenen aktuellen Berechtigungen berechnet. Eine Verbindung ohne abgeschlossene Buchungen im Zeitfenster zeigt für ihre Fehlerrate einen Gedankenstrich, nie 0%, da eine perfekte Null eine Verbindung, die niemand nutzt, an die Spitze einer Gesundheitsliste setzen würde. Die Latenz ist eine begrenzte Stichprobe über die jüngsten abgeschlossenen Buchungen und als Stichprobe gekennzeichnet, statt so dargestellt zu werden, als umfasse sie das ganze Zeitfenster. Stornierungsgründe erscheinen nur als ihre strukturierten Codes – der von einer Person eingetippte Freitext wird hier nie zusammengefasst oder angezeigt.

Lineage

Lineage führt von einer Buchung zurück zum Workflow-Lauf, der sie erzeugt hat, und hinaus zum Dokument im ERP selbst. Suchen Sie nach der Lauf-ID oder der Ledger-ID einer Buchung – bei einer Suche über die Ledger-ID wird der Lauf zuerst über Ihre eigenen Berechtigungen aufgelöst, sodass eine Buchung auf einer Verbindung, die Sie nicht sehen können, nichts auflöst, statt preiszugeben, aus welchem Lauf sie stammt. Wo PlaidCloud die URL-Form des ERP-Dokuments für diesen Adapter verifizieren kann, enthält die Lineage einen Deep Link direkt zum Dokument; wo nicht oder wenn die Buchung nie bestätigt wurde, nennt sie, welcher dieser Gründe zutrifft, statt einen Link zu erraten. Der Geschäftsschlüssel des ERP erscheint hier weiterhin nie – der Lineage-Schlüssel ist die run_id des Workflows, und der ERP-Verweis ist confirmation_id, genau wie überall sonst im Register.

Abschlüsse

Fordern Sie einen Abschluss an, um eine Periode – für eine oder mehrere Verbindungen und Entitäten – in einem unveränderlichen Snapshot zu einem Zeitpunkt zu versiegeln: alles, was das Register zu diesen Buchungen in diesem Moment wusste, aufbewahrt, selbst wenn die Live-Zeilen später wiederholt, storniert oder geleert werden. Er zielt auf eine gesperrte Buchhaltungsperiode, in der Sie einen belastbaren, unveränderlichen Nachweis brauchen statt dessen, was das Live-Raster heute zeigt. Das Anfordern oder Lesen eines Abschlusses ist vorerst nur über die API erreichbar; es gibt noch keinen Konsolenbildschirm, um einen anzufordern oder zu durchsuchen.

Das Anfordern eines Abschlusses (erp.register.operate) ist eine mandantenweite administrative Aktion und keine persönliche – die Verbindungen und Entitäten, die Sie nennen, sind genau die, die versiegelt werden, unabhängig von Ihren eigenen Verbindungsberechtigungen. Das erneute Abschließen einer bereits abgeschlossenen Periode ist nie destruktiv: Es erzeugt immer eine neue, separat nummerierte Revision, statt die letzte zu überschreiben.

Abschlüsse werden von selbst materialisiert. Das Anfordern eines Abschlusses versiegelt ihn nicht sofort – ein Hintergrundjob arbeitet täglich nach Zeitplan jeden ausstehenden Abschluss automatisch ab und schreibt seinen Iceberg-Snapshot ohne weiteres Zutun von Ihnen. Kann ein Durchlauf für einen bestimmten Abschluss nicht abgeschlossen werden (etwa bei einem Warehouse-Ausfall), wird dieser Abschluss als fehlgeschlagen markiert, statt hängen zu bleiben, und beim Durchlauf des nächsten Tages automatisch aufgegriffen und wiederholt – er wird nie stillschweigend übersprungen. Ein ungewöhnlich großer Abschluss (mit mehr als etwa 500.000 Buchungen) ist der eine Fall, der sich auf diese Weise nicht von selbst löst: Der Durchlauf weigert sich, ihn in einem Zug zu versiegeln, und es braucht die Hilfe von PlaidCloud, um ihn in kleineren Stapeln abzuschließen. Für die meisten Berichtsperioden ist das ein seltener Randfall.

Sobald ein Abschluss materialisiert ist, gelten beim Zurücklesen die üblichen Regeln des Registers, bei jedem Lesen live neu aufgelöst und nicht zum Zeitpunkt der Versiegelung in den Snapshot eingebacken: Sie sehen nur Zeilen zu Verbindungen und Projekten, für die Sie derzeit berechtigt sind. Anders als das Live-Raster, das Beträge und Ersteller-Identität jedem Betrachter zeigt, der die Zeile überhaupt sehen kann, sind die Zahlen eines Abschlusses maskiert, sofern Sie nicht erp.register.admin besitzen – dieselbe Regel, die auch der Export anwendet. Ein Abschluss meldet außerdem seine eigene Anzahl verspäteter Eingänge: Buchungen, die nach der Höchstmarke des Abschlusses übermittelt oder geändert wurden und daher nie in der Versiegelung erfasst sind – sichtbar nur durch Anfordern eines neuen Abschlusses für dieselbe Periode, da nichts einen alten wieder öffnet.

Export

Exporte und Benachrichtigungen ist die Stelle, an der das Register die Konsole als Datei oder als Benachrichtigung verlässt – und die eine Oberfläche, an der die Kontrollen von PlaidCloud in dem Moment enden, in dem die Bytes das System verlassen. Das Erzeugen eines Exports oder das Planen einer Zustellung erfordert erp.register.operate; das Register zum Ansehen zu öffnen, erfordert es nicht.

Jetzt herunterladen

Exportieren Sie das Register, das Sie gerade ansehen, als Excel-taugliche CSV-Datei oder als JSON, frisch erstellt unter Ihren eigenen aktuellen Berechtigungen. Je nach Ihrer Rolle gelten zwei Maskierungsprofile:

erp.register.operate erhält das standardmäßige, maskierte Profil: Beträge und Ersteller-Identität werden zurückgehalten.
erp.register.admin erhält das Prüferprofil – das einzige, das Beträge und Ersteller-Identität unmaskiert enthält.

Jeder Export folgt denselben Regeln wie das übrige Register: natural_key erscheint nie, Freitextfelder (Kommentare, Dimensions- und Worktag-Werte) werden ausdrücklich ausgeschlossen statt nur bereinigt, und ein nicht erfasster Betrag ist leer – unterschieden von einem maskierten, sodass ein leeres Feld nie als „es wurde nichts gebucht“ gelesen wird, wenn es tatsächlich „Ihre Rolle sieht dies nicht“ bedeutet.

Eine Zustellung planen

Erstellen Sie einen Zeitplan – einen Filter, eine Taktung, ein Format und eine Empfängerliste nach Mitglied oder eine Slack-Verbindung für eine Benachrichtigung ganz ohne Zeileninhalt. Es werden zwei Arten angeboten:

Export – eine wiederkehrende CSV- oder JSON-Zustellung des gefilterten Registers.
Hinweis – eine Benachrichtigung, die durch eine von drei Bedingungen ausgelöst wird: eine fehlgeschlagene Live-Buchung, eine alternde Autorisierung oder eine Stornierung einer Buchung. Sehen Sie sich vor dem Abonnieren eine Vorschau an, was ein Auslöser derzeit für Sie treffen würde.

Die Datei jedes Empfängers wird aus seinen eigenen aktuellen Berechtigungen im Moment des Sendens aufgebaut, nicht aus denen des Zeitplaneigentümers – zwei Empfänger desselben Zeitplans können zwei verschiedene Dateien erhalten, und ein Empfänger, der inzwischen die Exportrolle oder jede Verbindungsberechtigung verloren hat, deaktiviert wurde oder keine hinterlegte Adresse hat, wird einzeln mit einem genannten Grund übersprungen und nicht stillschweigend fallen gelassen. Nur der Eigentümer des Zeitplans oder ein erp.register.admin kann den Zeitplan einer anderen Person löschen oder auslösen.

Aufbewahrung

Legen Sie fest, wie lange das Register drei Arten von Historie aufbewahrt: erfasste Payload-Details, simulierte Buchungen und den Prüfpfad – jeweils als Tageszahl, mandantenweit, erfordert erp.register.admin. Bei jedem Aufruf wird jedes Feld geschrieben; ein ausgelassenes Feld löscht diesen Horizont, statt ihn unverändert zu lassen, und ein nicht konfigurierter Mandant bewahrt alles auf (jeder Horizont ist null und kein versteckter Standard).

Der Aufbewahrungsdurchlauf, der diese Richtlinie umsetzt, läuft inzwischen automatisch einmal täglich mandantenweit – derselbe Mechanismus für periodische Jobs, der auch die geplanten Exporte und Benachrichtigungen antreibt, überfällige Buchungen in die Ausnahmewarteschlange einsortiert und alte simulierte Buchungen ablaufen lässt.

Zusammenfassungsansichten

Zusammenfassung öffnet sich als Bereich aus der Navigationsleiste. Gruppieren Sie das Register nach Lauf, Periode oder Verbindung, um Zwischensummen und eine Statuszusammenfassung statt einzelner Zeilen zu sehen – die Gruppierung ist ein segmentiertes Bedienelement am oberen Rand des Bereichs, sodass Sie zwischen „Nach Lauf“, „Nach Periode“ und „Nach Verbindung“ an Ort und Stelle wechseln, ohne etwas neu zu öffnen.

Ein leerer Betrag bleibt leer. Eine Buchung ohne erfassten Betrag – jede SAP-Buchung, eine von Anfang an abgeschlossene Buchung oder eine, die vor dieser Funktion geschrieben wurde – trägt nichts zu einer Zwischensumme bei und wird nie als 0.00 angezeigt. Jede Gruppe gibt in Worten an, ob jede Buchung darin erfasst wurde, einige nicht oder keine.
Währungen werden nie in einer Summe vermischt. PlaidCloud führt keine Fremdwährungsumrechnung durch, sodass eine Gruppe mit mehr als einer Währung eine Zeile pro Währung erhält statt einer einzigen vermischten Zahl – siehe Betragsformatierung.
Eine gekappte Gruppenliste summiert dennoch korrekt. Erzeugt eine Gruppierung mehr Gruppen, als die Ansicht anzeigt, deckt die Summenzeile weiterhin jede Gruppe ab und nicht nur die angezeigten, und sagt das auch.

Das Banner Verbindungsstatus erscheint auch in dieser Ansicht.

Kontrollsummen

Kontrollsummen öffnet sich als Bereich aus der Navigationsleiste, über denselben Verbindungen und Entitäten, auf die Die Sichtbarkeitsregel Sie bereits beschränkt. Es gruppiert Buchungen in Stapel und nennt für jeden einen dreistufigen Befund – Ausgewogen, Nicht ausgeglichen oder Unbestimmt – mit der eigenen angegebenen Begründung des Servers, nie als bloßes Wort.

Unbestimmt ist eine echte Antwort und kein weiches Bestehen. Ein Stapel ist nur dann Ausgewogen, wenn jede Zeile darin gemessen wurde und seine Gruppen abgestimmt sind. Ein leeres Zeitfenster, ein nicht erfasster Betrag, ein Adapter, der sendet und vergisst, oder ein Scan, der abgebrochen wurde, bevor der ganze Stapel gelesen war, kommen alle als Unbestimmt zurück, mit ausdrücklich genannter Begründung – nie ein standardmäßiges Grün.
Beträge sind leer, nie null. Quell- und Buchungssummen einer Gruppe sowie ihre Differenz sind leer, wann immer der Betrag nicht erfasst oder bestätigt wurde – dieselbe Regel, der die Zusammenfassungen folgen, weil eine erfundene 0.00 einen ungemessenen Stapel zu niedrig ausweisen würde und dabei wie eine verbindliche Zahl aussähe.
Gruppen gelten pro Währung und Entität und werden nie zusammen addiert. PlaidCloud führt keine Fremdwährungsumrechnung durch, sodass ein Stapel mit mehr als einer Währung oder Entität die eigenen Summen jeder Gruppe nebeneinander auflistet, statt sie zu vermischen – siehe Betragsformatierung dazu, wie diese Zahlen dargestellt werden.
Zeilen, die vor der Erfassung entstanden sind, erhalten einen eigenen Behälter (no batch id). Eine Buchung, die vor der Stapelerfassung geschrieben wurde, lässt sich nicht in einen Stapel umgruppieren, den sie nie enthielt, und wird deshalb als eigene Zeile angezeigt, statt eingegliedert oder weggelassen zu werden.

Dieselbe Abfrage deckt außerdem zwei verwandte Fragen ab: die Bereitschaft zum Periodenabschluss pro Entität und Periode, die für einen Behälter, zu dem die Plattform noch keine Zahlen hat – etwa eine Zeile aus der Zeit vor der Erfassung bei einem Umstellungsabschluss –, auf Unbestimmt zurückfällt und nicht fälschlich auf Blockiert; und die Bestätigungsabweichung, die pro Dokument und nicht pro Gruppe gemeldet wird, weil zwei Dokumente, die innerhalb derselben Gruppe aus Währung und Entität in entgegengesetzte Richtungen abweichen, in der Summe aufgehen können und beide verbergen.

Der Detailbereich

Der Detailbereich dockt rechts am Arbeitsbereich an, sodass die Liste sichtbar bleibt, während Sie eine Buchung lesen. Öffnen Sie ihn über das Lupensymbol einer Zeile, indem Sie bei der ausgewählten Zeile Enter drücken oder die Zeile doppelt anklicken. Er ist in Registerkarten gegliedert:

Registerkarte	Zeigt
Journal	Die Soll- und Haben-Positionen der Buchung, so gelesen, wie es ein Buchhalter tun würde. Siehe Die Registerkarte „Journal“.
Anfrage/Antwort	Die ausgehende Anfrage und die Antwort des ERP, zur Datensparsamkeit gefiltert (siehe unten).
Fehler	Jeder Fehler, den das ERP oder der Buchungsschritt zurückgegeben hat.
Zeitleiste	Die Zustände der Buchung in Reihenfolge, von der Übermittlung bis zum aktuellen Zustand.
Verwandt	Die ursprüngliche Buchung und ihre Stornierung, miteinander verknüpft, sofern vorhanden.
Audit	Ein schreibgeschützter Nachweis der Aktivität an dieser Buchung. Vorerst spärlich – siehe Die Registerkarte „Audit“ unten.
Kommentare	Verschachtelte Kommentare zu dieser Buchung mit @Erwähnung per Mitglieds-ID. Siehe Zusammenarbeit.
Freigabe	Der aktuelle Prüfstatus der Buchung – Geprüft, Abgeklärt oder Nachverfolgung erforderlich – mit vollständigem Verlauf. Siehe Zusammenarbeit.

Die Registerkarte „Journal“

Die Registerkarte Journal liest eine Buchung so, wie es ein Buchhalter tun würde – ihre Soll- und Haben-Positionen nach Konto statt der rohen Anfrage-Payload.

Nur die Spalten, die jedes ERP tatsächlich erfasst. Die Registerkarte zeigt die Felder, die ein bestimmtes System sendet, und keine anderen: Eine Acumatica-Buchung zeigt ihr Unterkonto, während ein System, das nie eines sendet, überhaupt keine leere Unterkontospalte zeigt – Sie müssen nicht an Spalten vorbeiscannen, die nie etwas enthalten werden.
Dimensionen und Worktags stehen unter jeder Position. Die analytischen Details einer Position – ihre Dimensionen oder ihre Workday-Worktags – erscheinen unter der Position, zu der sie gehören, und nicht in zusätzlichen Spalten am oberen Rand zusammengedrängt.
Eine Fußsumme pro Währung mit exakter Saldenprüfung. Jede Währung wird für sich summiert; die Prüfung vermischt nie Währungen und rundet eine nicht ausgeglichene Buchung nie auf null, sodass eine echte Differenz als die Zahl erscheint, die sie ist, statt in einer 0.00 zu verschwinden.
Ein Adapter, der keine Positionsdetails erfasst, sagt das. Wo ein Treiber – etwa das lokale SAP – keine Aufschlüsselung pro Position aufzeichnet, stellt die Registerkarte das klar fest, statt ein leeres Raster zu zeigen, das Sie als „keine Positionen“ missverstehen könnten.

Tastaturbasierte Triage

In der Ausnahmewarteschlange wechseln die Pfeiltasten nach oben und unten von einer Buchung zur nächsten, wobei der Detailbereich der Auswahl folgt – so können Sie einen ganzen Triage-Durchgang per Tastatur abarbeiten und die Details jeder Buchung der Reihe nach lesen, ohne zur Maus zu greifen.

Das Hauptraster behält bewusst stattdessen die Mausauswahl, Enter und den Doppelklick: Seine Mehrzeilenauswahl steuert Massenaktionen wie das Wiederholen und das Leeren simulierter Buchungen, sodass die Pfeiltasten dort die Auswahl verschieben, statt den Detailbereich durch jede Zeile zu bewegen.

Zusammenarbeit

Bearbeiten Sie eine Buchung gemeinsam mit Ihrem Team, ohne das Register zu verlassen: Kommentieren Sie sie mit @Erwähnung, erfassen Sie eine Freigabe oder beobachten Sie eine Verbindung oder einen Lauf, um über künftige Aktivität informiert zu werden.

Kommentare sind verschachtelte Nur-Text-Notizen zu einer Buchung, über ihre Registerkarte „Kommentare“. Erwähnen Sie eine Kollegin oder einen Kollegen per Mitglieds-ID mit @, und sie bzw. er wird benachrichtigt – sofern die Buchung derzeit für sie bzw. ihn sichtbar ist; diese Prüfung wird beim Senden erneut durchgeführt und nie aus der Erwähnung angenommen.
Eine Freigabe erfasst einen von drei Zuständen – Geprüft, Abgeklärt oder Nachverfolgung erforderlich – mit einer optionalen Notiz und bewahrt den vollständigen Verlauf auf, wer wann was gesetzt hat. Sie ist eine Aufzeichnung und kein Gatter: Derzeit blockiert nichts eine Buchung oder eine Stornierung aufgrund ihres Freigabezustands.
Beobachten Sie eine Verbindung oder einen Lauf – zwei getrennte Schalter –, um künftig über Aktivität an einem von beiden benachrichtigt zu werden.

Das Verfassen eines Kommentars, einer Freigabe oder einer Beobachtung erfordert erp.register.view und .operate; das Zurücklesen erfordert allein .view.

Datensparsamkeit

Das Register ist so gebaut, dass es zeigt, was ein Prüfer braucht, um zu bestätigen, dass eine Buchung stattgefunden hat, ohne die sensiblen Daten offenzulegen, die ein Buchungsschritt dafür verarbeitet hat.

Anfrage- und Antwort-Payloads werden pro Adapter per Positivliste freigegeben. Ein Feld erscheint nur, wenn es ausdrücklich als unbedenklich aufbewahrbar eingestuft wurde. Bankkontonummern, Bankleitzahlen, IBANs, Steuer-IDs und andere persönliche Kennungen werden entfernt, bevor Sie die Payload je sehen.
Der Geschäftsschlüssel des ERP wird vollständig zurückgehalten. Er kann einen Lieferantennamen oder ein anderes Referenztoken enthalten und erreicht das Register daher nie – auch nicht den KI-Assistenten: Dieselbe Positivliste, die bestimmt, was Sie sehen, bestimmt, was ein Modell-Prompt sehen darf, und ein Wert des natürlichen Schlüssels an beliebiger Stelle dieser Payload wird rundheraus abgelehnt statt gesendet. Identifizieren Sie eine Zeile über ihre Ledger-ID und verwenden Sie confirmation_id als eigenen Verweis des ERP auf das Dokument – dasselbe Feld, das der ERP-Buchungsverlauf confirmation_id nennt.
Freitextfelder werden beim Lesen musterbereinigt und aus dem Digest, jedem KI-Modell-Prompt und jedem Export ausdrücklich ausgeschlossen – nicht nur bereinigt. Die Musterbereinigung erfasst eine Form wie eine IBAN oder eine Steuer-ID; einen in einen Memotext getippten Lieferantennamen erfasst sie nicht, weshalb alles, was die Konsole als Datei verlässt, diese Felder ganz weglässt, statt sich allein auf die Bereinigung zu verlassen.

Die Registerkarte „Audit“

Die Registerkarte „Audit“ dient nur der Anzeige. Ihre Details sind in dieser Version absichtlich spärlich, weil das zugrunde liegende Audit-Vokabular noch nicht klassifiziert wurde – rechnen Sie damit, dass sie sich füllt, sobald diese Arbeit abgeschlossen ist, und nicht damit, dass sich ändert, wie Sie den Rest des Detailbereichs lesen.

Alles andere auf dieser Seite – die Ausnahmewarteschlange, der Verbindungsstatus, die Zusammenfassungen, Massenaktionen, das Wiederholen einzelner Zeilen, das Stornieren, Kontrollsummen, der KI-Assistent, Trends, Lineage, Abschlüsse, Zusammenarbeit und Export – funktioniert heute.