Zahlungsabgleich, gebucht dort, wo das Hauptbuch liegt

Die Arbeit, die Ihr Produkt vorgelagert leistet, ist der Teil, den niemand sonst für Sie tun kann: verzögerte Gutschriften, gebündelte Auszahlungen, Gebühren, Währung, Erstattungen. Das Ergebnis davon ist sauber und einfach, ein Satz Buchungen, bereit zum Buchen. Dann sagt ein Kunde, er sei auf DATEV, oder auf Twinfield, oder seine niederländische Gesellschaft laufe auf Exact Online, und aus einem begrenzten Entwicklungsproblem wird ein offenes.

Offen wird es nicht durch die Zahl der Anbindungen, sondern dadurch, dass sie sich über das Objekt uneinig sind. Ein Buchungssatz verlangt, beide Seiten der Buchung zu benennen, und das heißt, den Kontenrahmen des Kunden zu kennen und zu entscheiden, welches Konto jede Seite trifft. Eine Zahlung verlangt weniger und etwas anderes: ein Konto, einen Betrag, und die Kennung der Rechnung, die sie ausgleicht, denn das System führt diese Rechnung bereits und ordnet ihr das Geld zu. Das sind verschiedene Funktionen in Ihrem Produkt und nicht zwei Adapter um eine Funktion.

Und die Aufteilung ist auf eine Weise ungleich, die bei der Planung zählt. Der Weg, der die meisten Systeme erreicht, ist zugleich der, der Ihnen am meisten abverlangt, also erreicht ein Produkt, das nur den leichteren umsetzt, eine Handvoll Systeme, und eines, das nur den schwereren umsetzt, verfehlt die, die ihn nicht annehmen. Die Lesezugriffe hinter beiden Wegen kommen aus Stammdaten, die vorher zusammenpassen müssen, und das ist ein eigener dokumentierter Use Case.

Rally ist der Gegenstand dieser Seite von der anderen Seite her. Das Zitat nennt DATEV, und es nennt die Sandbox, und das ist der Teil, auf den es einem Team ankommt, das Buchungen schreibt: ein Ort, an dem man die Form eines Buchungssatzes richtig hinbekommt, bevor er in den Büchern eines Kunden landet. Ihr veröffentlichter Bericht beschreibt, wie eine komplexe Direktintegration ersetzt wurde, und der Abschnitt darüber ist die konkrete Fassung dessen, was damit ersetzt wird. Systeme wie Business Central sitzen auf der anderen Seite der Teilung und nehmen beide Wege, und sevdesk nimmt nur die Zahlung, und um diesen Unterschied geht es im ersten Abschnitt.

Alles links ist die Anbindung: zwei Wege ins Hauptbuch statt einer Anbindung je Buchhaltungsplattform, die Stammdaten, auf die ein Buchungssatz verweisen muss, unter einem Satz Feldnamen, der Stapelweg, wo ein System ihn anbietet, und eine Datei, die mit der Buchung mitreist. Das ist der Teil, der sonst mit jedem Kunden wächst, der etwas Neues einsetzt.

Alles rechts ist Ihre Engine, und in diesem Use Case ist das die Substanz. Welche Zahlung welche Rechnung ausgleicht, ist eine Frage nach Daten, die wir nicht sehen, denn Bankzeilen sind über kein angebundenes System lesbar. Wie sich eine gebündelte Auszahlung aufteilt, auf welches Konto eine Gebühr gehört und wann ein Zyklus bucht, sind Entscheidungen über die Bücher Ihres Kunden und den Ablauf Ihres Produkts.

Zwei Dinge gehören hierher, weil die Seite, die diese ersetzt, sie unter die falsche Überschrift gestellt hat. Dass eine Buchung zweimal gebucht wird, verhindert Ihr Schreibvorgang dadurch, dass er einmal stattfindet, und keine Zusage von uns, und weil kein Objekt Löschen freigeschaltet hat, ist die Korrektur einer Doppelbuchung eine Stornierung und keine Entfernung. Und die steuerliche Behandlung eines Buchungssatzes bleibt bei Ihnen: wir liefern die Sätze, die das System veröffentlicht, in der Form, in der es sie veröffentlicht. Der lastModified-Filter sorgt dafür, dass die Konten und Sätze, die Sie zwischengespeichert haben, nicht von denen abweichen, die Ihr Kunde sieht.

Eine Zahlung einem offenen Posten zuzuordnen ist die Monatsabschlussarbeit von Finanzteams, und sie ist der Grund, warum die zwei Schreibwege für sie überhaupt zählen.