Rechnungen erstellen mit Zeilen, die ihr System liest
Ihr Produkt kennt schon, woraus eine Rechnung besteht: die geleistete Arbeit, die Mengen, die Preise. Was es nicht kennt, ist der Artikel, das Sachkonto und der Steuersatz, auf die sich die Zeile im System des Kunden beziehen muss. Maesn liefert das und schreibt dann die Rechnung.
- Einen Artikel aus ihrem Katalog
- oder ein Sachkonto, und einen Steuersatz
Über die angebundenen Systeme hinweg nehmen 10 eine von Ihnen geschriebene Rechnung an. Weniger sagen Ihnen, was auf ihre Zeilen gehört.
Die Rechnung ist schnell geschrieben, die Arbeit steckt in der Zeile
Zwei Zahlen, von denen man erwartet, dass sie sich gemeinsam bewegen, und das tun sie nicht. Das Dokument zu schreiben gehört zu den besser abgedeckten Vorgängen im Modell. Zu wissen, was in seine Zeilen gehört, nicht.
Eine Rechnungszeile ist ein kleines Objekt mit einer großen Abhängigkeit. Beschreibung, Menge und Preis kommen aus Ihrem Produkt, und sie sind der leichte Teil, weil Sie sie schon haben. Worauf die Zeile verweisen muss, sind fremde Daten: ein Artikel aus dem Katalog des Kunden oder ein Sachkonto, und ein Steuersatz, den es in seinem System unter seinem Code gibt.
Diese Abhängigkeit ist die ganze Schwierigkeit dieses Use Cases, und sie ist der Grund, warum der dokumentierte Ablauf mehr Schritte mit Lesen als mit Schreiben verbringt. Sie ist auch der Grund, warum drei dieser Schritte als optional markiert sind. Optional genannt klingt das nach einer Nettigkeit. Gegen die Abdeckung gelesen ist es etwas anderes, denn auf der Hälfte der Systeme, die eine Rechnung annehmen, gibt es schlicht keinen Artikelkatalog zu lesen. Der Steuersatz hat eine zweite Komplikation für sich, denn ein Satz kommt häufig an, ohne zu sagen, wie er anzuwenden ist.
Nichts davon macht den Use Case fragil. Es macht ihn genau: was Sie Ihren Nutzern versprechen können, hängt davon ab, auf welchen Systemen sie sind, und das lässt sich vorher wissen und nicht erst bei der ersten fehlgeschlagenen Buchung.
Eine Anbindung für den Katalog, die Konten und die Sätze
Die Lesezugriffe, die eine Zeile gültig machen, kommen aus jedem System in einer Form, und genau das lässt Ihre Nutzer ihre eigenen Daten auf ihre eigene Buchhaltung abbilden, statt dass Sie es je Hersteller tun.
Der erste dokumentierte Schritt handelt gar nicht von Rechnungen: der Kunde muss auf beiden Seiten existieren und dasselbe bedeuten, und das ist ein eigener Use Case unter Synchronisation von Kunden- und Lieferantenstammdaten. Es ist das robusteste Glied der Kette, denn Kundendatensätze sind das am besten abgedeckte Objekt im Modell, beim Lesen wie beim Schreiben.
Danach beantworten die Lesezugriffe alle dieselbe Frage in anderen Worten: worauf darf eine Zeile verweisen. Artikel, Sachkonten und Steuersätze kommen über dieselben normalisierten Objekte von jedem angebundenen System, die Oberfläche, in der Ihre Nutzer einen Standardartikel wählen oder eine Leistung einem Konto zuordnen, wird also einmal gebaut. Wo ein System etwas führt, wofür das gemeinsame Modell kein Feld hat, ist am Modell vorbeizugreifen dokumentiert, und der Kunde gibt das alles einmal über einen Authentifizierungsablauf frei.
Was Maesn nicht tut, ist den Bezug zu erfinden. Gibt ein System keinen Artikelkatalog heraus, kann keine Schicht einen erzeugen, und eine Zeile trägt dort Ihre Beschreibung und ein Sachkonto. Zwei Systeme können beide eine Rechnung annehmen und sich trotzdem uneinig sein, was eine Zeile sagen darf, und das ist die Art Unterschied, deren Form eine Integrationsschicht vereinheitlichen kann, deren Substanz aber nicht.
Ihr Auslöser, ihre Rechnung, keine Doppelerfassung
Das Ende des Ablaufs ist bewusst klein. Sind die Bezüge bekannt, ist die Rechnung ein einziger Aufruf, und die interessante Entscheidung, die bleibt, ist der Zeitpunkt.
Alle drei Lesezugriffe sind im Leitfaden optional, weil nicht jedes System alle drei anbietet.
- Eine echte Rechnung, kein Export
- Zeilen, die auf ihre Daten zeigen
- Gebucht, wo ihr Buchhalter hinsieht
- Keine zweite Erfassung von Hand
Der Auslöser gehört Ihnen, und das ist Absicht. Der Leitfaden bietet einen Knopf in Ihrer Oberfläche, eine Reaktion auf ein Event oder einen planmäßigen Lauf an, und er bevorzugt keinen davon, denn die richtige Antwort hängt an einem Ablauf, den Ihre Nutzer schon haben, und nicht an irgendetwas an der Anbindung. Ein Produkt, das Rechnungen nachts überträgt, und eines, das sie überträgt, sobald ein Auftrag abgenommen ist, sind dieselbe Anbindung mit einer anderen Entscheidung davor.
Was ankommt, ist ein echter Beleg in ihrem System und keine Datei, die jemand importiert. Halten Sie die fertige Rechnung stattdessen schon als PDF, schickt der Leitfaden Sie in einem Satz woanders hin, und diese Grenze lohnt sich einzuhalten: einen erzeugten Beleg hochzuladen und einen aus strukturierten Daten zusammenzusetzen sind verschiedene Aufgaben. Wo die Rechnung ein Schritt in einer längeren Forderung ist, einschließlich der Zahlung darauf, deckt Debitorenbuchhaltung den Rest ab, und sobald ein System Events aussendet, sagen Webhooks Ihnen, wenn sich auf deren Seite etwas geändert hat.
Erfasste Leistung, abgerechnet in den Systemen ihrer Kunden
Clockin macht aus erfasster Arbeit Rechnungen in den Systemen seiner Kunden.
“Wir nutzen Maesn, um Integrationen und Partnerschaften erfolgreich als wesentlichen Treiber für Leadgenerierung und für die Expansion in neue Märkte und Kundensegmente einzusetzen. Indem wir Clockin an die Buchhaltungssysteme unserer Kunden anbinden, fließen Projektdaten direkt in deren vorhandene Werkzeuge, und der Datenaustausch mit den Systemen, die sie ohnehin nutzen, läuft reibungslos und verlässlich.”
Clockin ist dieser Use Case in seiner einfachsten Form: Zeit- und Projektdaten werden in einem Produkt erfasst, und eine Rechnung muss in dem Buchhaltungssystem erscheinen, das der Kunde ohnehin nutzt. Das Zitat benennt den Mechanismus statt des Ergebnisses, und das ist der nützliche Teil, denn dass die Daten direkt in die vorhandenen Werkzeuge fließen, ist genau das, was den Schritt des erneuten Erfassens entfernt, um den es auf dieser Seite geht. Systeme wie Lexware Office und Xero nehmen beide eine geschriebene Rechnung an, und sie unterscheiden sich darin, ob eine Zeile auf einen Katalogartikel zeigen kann, und um diesen Unterschied geht es im Abschnitt darüber.
Abdeckung bei der Rechnungserstellung, Objekt für Objekt
Zuerst der Schreibvorgang, dann alles, worauf eine Zeile verweisen muss, gezählt aus der Dokumentation des jeweiligen Systems.
| Was Sie brauchen | Heute | Auf Anfrage | System kann es nicht |
|---|---|---|---|
| Rechnungen, schreiben | 10 | 17 | 2 |
| Kundendatensätze, lesen | 20 | 2 | 7 |
| Kontenrahmen, lesen | 19 | 8 | 2 |
| Steuersätze, lesen | 12 | 14 | 3 |
| Artikel, lesen | 6 | 20 | 3 |
| Rechnungszeilen, lesen | 6 | 17 | 5 |
| Mengeneinheiten, lesen | 1 | 15 | 13 |
Die Tabelle beantwortet die einzige Frage, die hier über die Machbarkeit entscheidet, und das ist nicht, ob die Rechnungserstellung funktioniert, sondern wie genau eine Zeile auf den Systemen sein kann, die Ihre eigenen Kunden fahren. Die oberen zwei Zeilen sind stark, und der Rest wird schmaler, je genauer es wird, und das ist die übliche Form einer Integrationsfläche und kein Mangel.
Eine Zeile verdient die Betonung, die ihr ihre Größe nicht gibt. Eine Mengeneinheit gibt ein einziges System heraus, und ein Produkt, dessen Rechnungen davon abhängen, dass Stunden, Kilogramm oder Quadratmeter als Einheit ins Hauptbuch kommen und nicht als Teil einer Beschreibung, sollte das als Frage je System behandeln. Nur das zu lesen, was sich seit dem letzten Lauf geändert hat, funktioniert hier wie auf jedem anderen Listen-Endpunkt, und das zählt für Kataloge, die Kunden bearbeiten, während Ihr Produkt läuft.
Wir liefern die Bezüge, Sie stellen die Rechnung zusammen
In diesem Use Case verläuft die Grenze innerhalb eines einzigen Objekts, was sie ungewöhnlich leicht benennbar macht: die Zeile gehört Ihnen, worauf sie verweist gehört dem System, und die Anbindung bringt Ihnen das Zweite.
- Der Kunde, in beide Richtungen
- Artikel, Konten und Steuersätze
- Eine Form auf jedem System
- Die Rechnung, zurückgeschrieben
- Was jede Zeile wirklich sagt
- Welcher Artikel, welches Konto
- Wann übertragen wird
- Wie Ihre Rechnung aussieht
Alles links ist die Anbindung: dieselben Objekte unter denselben Namen, auf welchem System der Kunde auch läuft, und ein Schreibvorgang, der als Beleg landet und nicht als Import. Das ist der Teil, der sonst eine Anbindung je Buchhaltungsplattform wäre, jede mit einer eigenen Vorstellung davon, was ein Artikel ist.
Alles rechts ist Ihr Produkt, und in diesem Use Case ist es die Substanz der Rechnung selbst. Was eine Zeile sagt, auf welchen Artikel oder welches Konto sie abgebildet wird, wann die Übertragung stattfindet und wie der fertige Beleg für Ihren Nutzer aussieht, sind Ihre Entscheidungen, geprägt davon, wie Ihre Kunden ohnehin arbeiten. Eine Schicht, die sie träfe, schriebe Ihre Rechnungen für Sie.
Eine Sache gehört hierher, weil die Seite, die sie ersetzt, sie woandershin gestellt hat. Dieser Use Case macht eine Rechnung nicht konform mit einem Regime zur elektronischen Rechnungsstellung, und nichts auf dieser Seite behauptet das. Die Rechnung entsteht im Buchhaltungssystem des Kunden, und dort gelten dessen örtliche Regeln ohnehin, und Fragen zu Netzwerken für elektronische Rechnungen stellen Sie am besten direkt uns. Der lastModified-Filter auf den Lese-Endpunkten ist das, was die Kataloge, die Sie zwischenspeichern, in der Zwischenzeit vor dem Veralten bewahrt.
Eine Rechnung, die beim ersten Mal richtig ankommt, ist die, die Finanzteams nicht mehr von Hand korrigieren.
Häufige Fragen
Was gehört dazu, eine Rechnung im Buchhaltungssystem eines Kunden anzulegen?
Warum sind drei der dokumentierten Schritte als optional markiert?
Was steht eigentlich auf einer Rechnungszeile?
Können wir stattdessen eine PDF-Rechnung schicken?
Unterstützen Sie E-Rechnungsformate oder PEPPOL?
Wie entscheiden wir, wann eine Rechnung übertragen wird?
Muss der Kunde zuerst im Buchhaltungssystem vorhanden sein?
In welche Systeme können wir Rechnungen schreiben?
Was, wenn ein System ein Feld braucht, das das gemeinsame Modell nicht trägt?
Entscheidet Maesn über die steuerliche Behandlung auf der Rechnung?
Einmal bauen, auf der Unified API.
Sehen Sie, wie Rechnungserstellung für Ihre Integration funktioniert, oder steigen Sie in die technische Referenz ein.