Wie "Massenhaft als Bezahlt Markieren" Wirklich Funktioniert

Einen Stapel Rechnungen auszuwählen und auf "als bezahlt markieren" zu klicken, fühlt sich an, als sollte es ein einfacher Statuswechsel sein, der auf jede ausgewählte Zeile angewendet wird. Im Hintergrund geschieht etwas Bewussteres — und Korrekteres — aus einem Grund, der offensichtlich wird, sobald man weiß, wie der Rechnungsstatus anderswo im Produkt tatsächlich berechnet wird.

Das Statusfeld Ist Abgeleitet, Nicht Maßgeblich

Der bezahlte Betrag und der Status einer Rechnung sind keine Werte, die Sie durch direktes Bearbeiten dauerhaft festlegen können, weil sie bei jedem Zahlungsereignis, das diese Rechnung berührt — eine neue Zahlung erfasst, eine gelöscht, eine abgeglichen —, von Grund auf neu berechnet werden. Diese Neuberechnung gewinnt immer: Sie summiert jede aktuell zugeordnete Zahlung gegen die Rechnung und leitet daraus den Status ab, wobei sie überschreibt, was zuvor dort stand. Würde "massenhaft als bezahlt markieren" einfach status: "paid" auf die Daten jeder ausgewählten Rechnung schreiben, würde diese Änderung nur so lange bestehen, bis das nächste Zahlungsereignis jeglicher Art die Rechnung berührte — woraufhin die Neuberechnung liefe, keine Zahlungsdatensätze fände, die den Status "bezahlt" stützen, und ihn still zurück auf unbezahlt oder überfällig kippen würde. Der Code-Kommentar, der dies umsetzt, ist bei der Begründung explizit: Ein von Hand gesetztes Feld würde "still und heimlich zurückgesetzt... beim nächsten Hinzufügen, Löschen oder Abgleichen einer Zahlung".

Was Stattdessen Tatsächlich Geschieht

Für jede ausgewählte Rechnung berechnet die Massenaktion deren Gesamtbetrag, summiert die bereits zugeordneten Zahlungen dagegen und fügt einen neuen Zahlungsdatensatz für genau die Differenz ein — den noch offenen Betrag — gekennzeichnet mit der Methode "Bulk mark as paid" und der Quelle "manual", datiert auf das Zahlungsdatum der Rechnung, falls gesetzt, sonst auf das heutige Datum. Diese neue Zahlung ist es, die die Rechnung tatsächlich in einen bezahlten Status bringt, denn dieselbe Neuberechnungslogik, die eine direkte Statusänderung still hätte zunichtemachen können, läuft nun zugunsten der Zahlung: Sie summiert die Zahlungen, stellt fest, dass sie nun den vollen Betrag decken, und leitet "bezahlt" aus echten, dauerhaften Daten ab, statt aus einem Feld, das beim nächsten Mal, wenn irgendetwas anderes diese Rechnung berührt, auseinanderdriften würde.

Teilweise Bezahlte Rechnungen Erhalten Nur Den Restbetrag

Hier ist der Unterschied in der Praxis am wichtigsten. Hat eine Rechnung bei einem Gesamtbetrag von 1.000 € bereits 300 € zugeordnet, fügt "massenhaft als bezahlt markieren" keine neue Zahlung über 1.000 € ein — es berechnet die noch offenen 700 € und erfasst nur diese. Das Ergebnis ist eine Rechnung mit zwei Zahlungsdatensätzen, die zusammen den vollen Betrag ergeben, eine korrekte kombinierte Historie, statt einer Zahlung, die überzeichnet, was tatsächlich eingegangen ist, oder einer zweiten Zahlung, die die bereits erfassten 300 € doppelt zählen würde. Hat eine Rechnung aus einem anderen Grund bereits Zahlungen, die den Gesamtbetrag vollständig decken, wird überhaupt kein neuer Zahlungsdatensatz eingefügt — es gibt nichts Offenes zu erfassen.

Es Hinterlässt Dieselbe Spur Wie Eine Manuelle Zahlung

Weil "massenhaft als bezahlt markieren" über den echten Zahlungserfassungspfad läuft statt über eine Abkürzung, löst es alles aus, was eine normale Zahlung auslöst: Der Zahlungsschnappschuss der Rechnung wird aus der Transaktion aktualisiert, ein Prüfpfad-Eintrag wird geschrieben, der ein "bezahlt"-Ereignis mit einer Massenaktionsquelle kennzeichnet erfasst, und — für die anderen Massenaktionen im selben Stapelvorgang, etwa das Archivieren — wird ebenfalls ein entsprechender Prüfeintrag geschrieben. Sieht man sich später die Historie dieser Rechnung an, gibt es keinen visuellen Unterschied, der nahelegt, die Zahlung sei irgendwie weniger legitim als eine, die einzeln über das normale Zahlungsformular eingegeben wurde; es ist ein normaler Zahlungsdatensatz, der zufällig über eine Massenaktion erstellt wurde, wobei das Methodenfeld die einzige Spur davon ist, wie er dorthin gelangt ist.

Warum Das Über Diese Eine Funktion Hinaus Wichtig Ist

Die zugrunde liegende Lehre verallgemeinert sich über Massenaktionen hinaus: Nirgendwo im Produkt ist der bezahlte Status einer Rechnung etwas, das Sie dauerhaft auf einen bestimmten Wert erzwingen können, ohne ihn mit einem echten Zahlungsdatensatz zu untermauern. Das ist eine bewusste Einschränkung, kein fehlender Abkürzungsweg — sie garantiert, dass "diese Rechnung zeigt sich als bezahlt" und "diese Rechnung hat Zahlungsdatensätze, die ihren Gesamtbetrag decken" nie auseinanderdriften können, genau die Eigenschaft, die Sie von einer Zahl erwarten, die am Ende in Ihren Finanzberichten landet.