Ausgabenmanagement in der Form, die jedes System verlangt
Ihr Produkt weiß, was ausgegeben wurde, von wem und wofür. Was es nicht weiß, ist, welchen von drei Feldnamen das System dieses Kunden für das Sachkonto verwendet, und ob die Zeile den Netto- oder den Bruttobetrag tragen muss. Maesn liefert das und bucht dann die Ausgabe.
- accountId
- accountNumber
- accountCode
Die Systeme, die eine von Ihnen geschriebene Ausgabe annehmen, sind sich einig, was die Zeile braucht, und nicht darüber, wie es heißt.
Ein Ausgabenobjekt, sieben verschiedene Verträge
Eine Ausgabe zu schreiben ist auf jedem System, das es unterstützt, ein einziger Aufruf. Was dieser Aufruf enthalten muss, ist auf allen sieben verschieden, und die Unterschiede sind nicht kosmetisch.
Das Objekt selbst ist einfach, und es ist überall dasselbe. Ein Kopf sagt, wann das Geld geflossen ist und in welcher Währung; eine Zeile sagt, auf welches Sachkonto die Ausgabe gehört, wie hoch sie war und zu welchem Steuersatz. Jedes System, das eine Ausgabe annimmt, will genau so viel. Keine zwei von ihnen verlangen es unter denselben Namen.
Das Konto ist der sichtbare Fall. Alle sieben verlangen, dass die Zeile eines benennt, und untereinander nennen sie es accountId, accountNumber und accountCode. Das kostet Sie eine Zuordnungstabelle und sonst nichts. Der Betrag ist der, bei dem es still schiefgeht, denn beide Zahlen sind völlig gültige Werte und nur eine davon ist die, nach der dieses System gefragt hat. Eine Zeile, die brutto geschickt wird, wo netto verlangt war, wird nicht abgelehnt, sie wird gebucht, und sie wird genau um die Steuer falsch gebucht. Dass der Steuersatz selbst oft ohne eine Regel zu seiner Anwendung veröffentlicht wird, ist die zweite Hälfte desselben Problems.
Über die gemeinsame Form hinaus verlangt jedes der sieben etwas, wonach keines der anderen fragt. QuickBooks will eine Zahlungsart, und das Konto im Kopf muss von der passenden Art sein. Xero will wissen, ob der Beleg eine Ausgabe oder eine Erstattung ist, und es will entweder einen Lieferanten oder einen Kunden statt keines von beidem. Exact Online und Twinfield wollen einen Journalcode. Lexware Office will eine Belegnummer und auf jeder einzelnen Zeile einen Steuersatz in Prozent, und dazu gehört eine zweite Tatsache über dieses System: es ist das einzige der sieben, dessen Steuersatz-Lesezugriff als auf Anfrage verfügbar markiert ist statt als heute unterstützt. Nichts davon ist unvernünftig. Zusammen sind sie der Grund, warum eine Ausgaben-Integration nach dem ersten System selten fertig ist.
Eine Anbindung für die Konten, die Sätze und die Dimensionen
Alles, worauf eine Ausgabe verweisen muss, kommt aus jedem angebundenen System in einer Form zurück, und genau das lässt Ihre Nutzer ihre Ausgaben einmal auf ihre eigene Buchhaltung abbilden statt einmal je Hersteller.
Von den 30+ angebundenen Systemen nehmen sieben eine Ausgabe an und zehn einen Buchungssatz an, und das ist der Weg, den der Leitfaden in seinem Schlusssatz nennt. Nur fünf nehmen beides an, und damit ist das keine Rückfallebene für die schwächeren Systeme: DATEV Unternehmen Online und Lexware Office nehmen eine Ausgabe und keinen Buchungssatz, während fünf weitere einen Buchungssatz und keine Ausgabe nehmen. Zählt man beide Wege, können die meisten Systeme heute Ausgaben aus Ihrem Produkt entgegennehmen.
Der Kontenrahmen ist der tragende Lesezugriff dieses Use Cases, und er ist zugleich der stärkste: dasselbe normalisierte Objekt ist fast überall lesbar, und auf jedem einzelnen System, das eine Ausgabe annimmt. Was sich unterscheidet, ist, wie viel jedes hineinlegt. Das Feld, nach dem der Leitfaden zu gruppieren vorschlägt, damit ein Nutzer Aufwandskonten sieht statt einer flachen Liste von Hunderten, taucht in sieben dieser neunzehn dokumentierten Feldlisten auf, und der Verweis auf das übergeordnete Konto, mit dem sich die Hierarchie zeichnen ließe, in zweien. Keine der beiden Lücken stoppt den Use Case. Beide entscheiden, wie gut die Kontoauswahl in Ihrem Produkt für einen bestimmten Kunden sein kann, und das ist genau die Art Sache, die man vor einem Design-Review wissen will und nicht danach.
Der Rest der Kette ist gewöhnlich, sobald die Verbindung steht. Ihr Kunde gibt sie einmal über einen Ablauf frei, welches System er auch betreibt, Steuersätze und Lieferanten kommen überall als dieselben Objekte an, und nur zu lesen, was sich seit dem letzten Lauf geändert hat, hält einen zwischengespeicherten Kontenrahmen ehrlich, während Ihre Nutzer ihren bearbeiten. Wo ein System etwas führt, wofür das gemeinsame Modell kein Feld hat, ist am Modell vorbeizugreifen dokumentiert statt improvisiert.
Was eine Anbindung nicht kann, ist die Daten zu erfinden. Dimensionen sind das ehrliche Beispiel. Drei Systeme geben heute eine lesbare Liste davon heraus, und die meisten übrigen tragen in ihrer eigenen Dokumentation eine Markierung auf Anfrage, und das ist eine Markierung und kein Versprechen. Unabhängig davon dokumentiert kaum ein System ein Dimensionsfeld auf der Ausgabenzeile selbst, und es sind nicht dieselben zwei. Eine Kostenstellen-Funktion ist also baubar, und sie ist für benannte Systeme baubar und nicht allgemein, und das ist ein deutlich besserer Satz vor einem Kunden als die Zusicherung, dass alles unterstützt wird.
Die Ausgabe landet dort, wo der Buchhalter ohnehin hinsieht
Das Ergebnis von all dem ist unspektakulär, und genau das ist der Punkt: Ausgaben, die in Ihrem Produkt entstanden sind, erscheinen im Hauptbuch Ihres Kunden, auf seinem Konto, zu seinem Satz, ohne dass jemand eine Datei exportiert. Am klarsten zeigt sich, was dafür nötig ist, an einem einzigen System, auf das die gewohnten Wörter nicht passen.
Zwei Felder, und type nimmt einen von drei Werten an: CASH, ACCOUNTS_RECEIVABLE, ACCOUNTS_PAYABLE. Keine Nummer, keine Klasse, kein Saldo. Das ist eine Liste von Buchungsordnern und kein Kontenrahmen, und genau das meint der Leitfaden, wenn er beiläufig anmerkt, dass der Endpunkt für DATEV nur Namen von Buchungsordnern liefert.
Der Ordnername geht unverändert wieder hinein, und er muss einer vom Typ CASH. Die Antwort ist eine Aufgaben-Kennung und keine Buchung, und über GET /asyncTask erfahren Sie, ob sie gelandet ist. Der synchrone Endpunkt führt dieses System weiterhin und markiert es als veraltet, mit einem Verweis hierher.
DATEV Unternehmen Online gibt überhaupt keinen Kontenrahmen heraus. Zurück kommt eine kurze Liste von Buchungsordnern mit einem Typ, und der Schreibvorgang will einen dieser Namen zurück, und zwar einen vom Kassen-Typ. Ein Produkt, das auf der Annahme gebaut ist, dass jedes System nummerierte Konten zurückgibt, hat seinem Nutzer hier nichts zu zeigen. Ein Produkt, das auf dem gebaut ist, was jedes System wirklich zurückgibt, hat eine Liste, die sein Nutzer wiedererkennt, und eine Buchung, die ankommt, und denselben Unterschied macht die DATEV-Anbindung auch in jedem anderen Use Case.
Die zweite Hälfte dieses Kastens ist der Teil, den die meisten Anbindungen spät entdecken. Dieser Schreibvorgang ist asynchron: die Antwort ist eine Auftragskennung, und ein eigener Aufruf sagt Ihnen, ob die Buchung angekommen ist. Das richtig zu behandeln heißt, dass Ihr Nutzer von einem Fehlschlag Minuten später erfährt statt nie, und es ist weit billiger, von Anfang an dafür zu bauen, als es Code nachzurüsten, der annahm, eine Antwort käme mit der Anfrage.
Zwei kleinere Dinge gehören ebenfalls zum Ergebnis. Der Beleg reist auf fast allen mit der Ausgabe mit, weil der Schreibvorgang eine mehrteilige Anfrage ist und die Datei neben den Daten nimmt, der Beleg, den Ihr Nutzer fotografiert hat, liegt also dort, wo sein Buchhalter ihn erwartet, und nicht in einem Ordner, den später jemand abgleichen muss. Und der Auslöser bleibt Ihrer: ob eine Ausgabe in dem Moment abgeglichen wird, in dem sie freigegeben ist, in einem nächtlichen Lauf, oder erst wenn jemand einen Knopf drückt, ist eine Entscheidung über den Ablauf, den Ihre Nutzer schon haben, und nicht über die Anbindung.
Ausgabenmanagement, eingebettet in die Buchhaltung ihrer Kunden
Findity bringt den Ausgabenabgleich in die Produkte seiner Partner.
“Maesn hat uns geholfen, Integrationen zu Buchhaltungssystemen zu bauen, und wir konnten uns dadurch auf andere Prioritäten unserer Roadmap konzentrieren. Besonders zufrieden sind wir mit der Unterstützung, die wir jedes Mal bekommen haben, wenn wir in einer Integration erweiterte Funktionalität brauchten, die Maesn für uns eingerichtet hat.”
Findity baut Ausgabenmanagement als White-Label- und API-Produkt, und das heißt, ihre Integrationen gehören nicht ihnen allein: jeder Partner, der sie einbettet, erbt, welche Buchhaltungssysteme Findity erreicht. Das ist dieser Use Case in seiner anspruchsvollsten Form, und der Teil des Zitats, der zweimal gelesen werden sollte, ist der zweite Satz, über die erweiterte Funktionalität, die vereinbart wurde, als eine Integration mehr brauchte, als sie hatte. Systeme wie Lexware Office, Xero und QuickBooks nehmen alle eine Ausgabe an und sind sich über fast jedes ihrer Felder uneinig, und das ist die Arbeit, die hier aufgenommen wird. Die Kunden mit einer veröffentlichten Case Study sind eine andere Menge, und dies hier ist ein Zitat und keine Studie.
Jeder Schritt des Abgleichs, je System gezählt
Zuerst beide Schreibwege, dann alles, worauf die Ausgabe verweisen muss, gezählt aus der Dokumentation des jeweiligen Systems.
| Was Sie brauchen | Heute | Auf Anfrage | System kann es nicht |
|---|---|---|---|
| Ausgaben, schreiben | 7 | 19 | 3 |
| Buchungssätze, schreiben | 10 | 11 | 8 |
| Kontenrahmen, lesen | 19 | 8 | 2 |
| Lieferanten, lesen | 19 | 2 | 8 |
| Lieferanten, schreiben | 14 | 4 | 11 |
| Steuersätze, lesen | 12 | 14 | 3 |
| Dimensionen, lesen | 3 | 17 | 9 |
Die Tabelle beantwortet die Frage, die tatsächlich über die Machbarkeit entscheidet, und das ist nicht, ob der Ausgabenabgleich funktioniert, sondern wie viel davon für die Systeme funktioniert, die Ihre eigenen Kunden fahren. Von oben nach unten gelesen erklärt sie auch die Form des Leitfadens: der Schreibvorgang ist schmal, der Kontenrahmen dahinter ist breit, und alles, was eine Buchung genauer macht, wird dünner, je genauer es wird.
Eine Zeile lohnt einen zweiten Blick aus einem Grund, der nicht ihre Größe ist. Buchungssätze erreichen mehr Systeme als Ausgaben, und die Dokumentation erwähnt diesen Weg fast beiläufig, als den einfacheren Weg, Ausgaben zu buchen. Für ein Produkt, dessen Nutzer nur den Betrag auf dem richtigen Konto brauchen und kein Ausgabendokument mit Lieferant und angehängtem Beleg, gibt es diesen Weg auf Systemen, die dieser hier nicht erreicht. Lieferanten sind hier die bequemen Zeilen, und wo sie angelegt und nicht nur gelesen werden müssen, ist das ein eigener dokumentierter Use Case.
Wir liefern die Struktur, die Kategorisierung gehört Ihnen
In diesem Use Case zieht die Dokumentation die Grenze selbst, denn ihr längster Schritt beschreibt Entscheidungen, die sie ausdrücklich Ihrem Produkt überlässt.
- Konten, Sätze und Dimensionen
- Eine Form auf jedem System
- Die Ausgabe, zurückgeschrieben
- Der Beleg, mit der Buchung
- Das Konto jeder Ausgabe
- Die Regeln Ihrer Nutzer
- Wann der Abgleich läuft
- Was als Ausgabe zählt
Alles links ist die Anbindung: die echte Buchhaltungsstruktur des Kunden, geliefert unter denselben Namen, auf welchem System er auch läuft, und ein Schreibvorgang, der als Buchung landet und nicht als Datei, die jemand importiert. Das ist der Teil, der sonst eine Anbindung je Buchhaltungsplattform wäre, jede mit einer eigenen Vorstellung davon, was eine Kontokennung ist.
Alles rechts ist Ihr Produkt, und hier ist das mehr als sonst. Die Dokumentation widmet ihren längsten Schritt der Kategorisierung und gibt die ganze Sache dann ab: ein einzelnes Standardkonto für den einfachen Fall, Regeln mit Bedingung für den schwereren, Kategorisierung im Moment der Synchronisation und Nutzer, die überschreiben, was auch konfiguriert war. Sie sagt, die Geschäftslogik hänge an Ihrer Anwendung, und damit hat sie recht. Was eine Ausgabe bedeutet, auf welches Konto sie gehört und wer das ändern darf, sind Produktentscheidungen, die nah an dem liegen, wofür Ihre Nutzer Sie tatsächlich bezahlen.
Eines gehört hierher, weil die Seite, die diese ersetzt, es in die Überschrift gestellt hat. Maesn macht Ausgaben nicht steuerkonform. Wir liefern die Sätze, die ein System veröffentlicht, und schreiben zurück, was Ihr Produkt zusammengestellt hat, und das Buchhaltungssystem, in dem es landet, ist die Stelle, an der die lokalen Regeln gelten, genau wie vorher. Wo die Ausgabe Ihre Nutzer als Eingangsrechnung erreicht und nicht als Kartenumsatz, ist der benachbarte Use Case mit eigenen Endpunkten das Buchen von Eingangsrechnungen und ihren Zahlungen, und der lastModified-Filter sorgt dafür, dass die Konten und Sätze, die Sie zwischengespeichert haben, nicht von denen abweichen, die Ihre Nutzer sehen.
Eine Ausgabe, die bereits kontiert ankommt, ist die, die Finanzteams nicht mehr abtippen.
Häufige Fragen
Was gehört dazu, eine Ausgabe in das Buchhaltungssystem eines Kunden abzugleichen?
Welche Systeme nehmen heute eine Ausgabe an?
Warum unterscheidet sich der verlangte Betrag je System?
Kategorisiert Maesn die Ausgaben?
Können wir den Beleg anhängen?
Was ist mit Kostenstellen und Abteilungen?
Müssen wir den Lieferanten zuerst anlegen?
Ist eine abgeglichene Ausgabe steuerkonform?
Was passiert, wenn eine Buchung länger dauert als eine Anfrage?
Was, wenn ein System ein Feld braucht, das das gemeinsame Modell nicht trägt?
Einmal bauen, auf der Unified API.
Sehen Sie, wie Ausgabenmanagement für Ihre Integration funktioniert, oder steigen Sie in die technische Referenz ein.