Nach Use Case

Use Cases für die Buchhaltung, und wie weit jeder reicht

Jede Seite unten verfolgt einen Workflow in das Buchhaltungssystem, das Ihr Kunde führt, und zählt je System, was er dort erreicht. Beginnen Sie mit dem Workflow, den Ihr Produkt fährt, nicht mit dem System, in dem er landet.

Demo buchen Alle Use Cases ansehen

Diese Software-Teams vertrauen uns

4,8auf G2

Nach Use Case

Beginnen Sie mit dem Workflow, den Ihr Produkt schon fährt

Jede Seite verfolgt einen Workflow bis in die Buchhaltungssysteme Ihrer Kunden und benennt die Objekte, die Endpunkte und die Grenzen, die dazugehören.

Die vierzehn Abläufe, denen diese Seiten folgen

Wie Sie diese Seiten lesen

Jeder Workflow hat ein breitestes Objekt und ein schmalstes

Jede Seite unten nennt das Objekt, auf dem ihr Workflow am stärksten ruht, und das, welches über seinen Abschluss entscheidet. Stellt man die beiden nebeneinander, zeigt sich jedes Mal dieselbe Form.

Ablauf

Sein am breitesten unterstütztes Objekt

Sein schmalstes

AblaufKreditorenbuchhaltungBreitestesLieferantendatensätzeSchmalstesDimensionen
AblaufDebitorenbuchhaltungBreitestesKundendatensätze, lesenSchmalstesZahlungsbedingungen, lesen
AblaufAusgabenmanagementBreitestesKontenrahmen, lesenSchmalstesDimensionen, lesen
AblaufZahlungsabgleichBreitestesKontenrahmen, lesenSchmalstesBankzeilen, lesen
AblaufBanktransaktionenBreitestesBuchungen, lesenSchmalstesBewegungen, zurücklesen
AblaufFinanzanalyse & FinanzplanungBreitestesDer KontenrahmenSchmalstesBankaktivität
AblaufSteuerautomatisierungBreitestesKontenrahmen, lesenSchmalstesSummen- und Saldenliste, für Auswertungen
AblaufForderungsmanagementBreitestesSchuldnerstammdatenSchmalstesOffene Posten, als Objekt
AblaufB2B-Kreditvergabe & -überwachungBreitestesDer KontenrahmenSchmalstesDer Saldo je Konto, als Bericht
AblaufFactoringBreitestesDer Schuldnerdatensatz dahinterSchmalstesOffene Posten als eigenes Objekt
AblaufKunden- / LieferantensynchronisationBreitestesKunden, lesenSchmalstesKombinierte Liste, lesen
AblaufRechnungserstellungBreitestesKundendatensätze, lesenSchmalstesMengeneinheiten, lesen
AblaufKonzernkonsolidierungBreitestesDer Kontenrahmen jeder GesellschaftSchmalstesEin Saldo je Konto

Jedes Paar stammt aus der Tabelle, die die Seite selbst trägt. Das schmale Ende ist die Zeile, um die herum diese Seite geschrieben ist, und nicht eine, die sie auslässt, und die Seite sagt je System, was das für einen Bau heißt.

Die linke Spalte ist der Grund, warum Integrations-Demos gut laufen: fast jeder Workflow öffnet auf einem Objekt, das nahezu jedes angebundene System zurückgibt, meist der Kundendatensatz oder der Kontenrahmen, die erste Hälfte dieser Bauten funktioniert also faktisch bei jedem Kunden, den Sie anbinden können. Das ist auch der Grund, warum Abdeckungsfragen, abstrakt gestellt, eine optimistische Antwort bekommen, und die Ausnahme bestätigt die Regel: der eine Workflow hier, der nur schreibt, hat einen Schreibweg als breiteste Zeile, und er öffnet deutlich tiefer.

In der rechten Spalte trifft ein Projekt auf die Wirklichkeit, und sie ist die nützlichere von beiden. Das Objekt, das einem Workflow seinen besonderen Wert gibt, ist regelmäßig das dünnste, das er berührt. Diese Zeilen sind keine Auslassungen, zu deren Veröffentlichung man uns überredet hat. Jede davon ist die Zeile, um die ihre Seite herum geschrieben ist, und wo ein Objekt gar keinen Weg hat, sagt die Seite es direkt unter ihrer eigenen Tabelle. Ein Bauplan, der nur die linke Spalte liest, hat bei der Demo recht und bei den letzten zwei Wochen unrecht.

Daraus folgt eine Prüfreihenfolge und kein Urteil. Nehmen Sie die schmale Zeile des Workflows, den Sie brauchen, schlagen Sie dann die Systeme, die Ihre Kunden tatsächlich betreiben, in der Übersicht nach und sehen Sie, ob diese Zeile dort unterstützt ist. Das ist eine bestimmte Frage mit einer bestimmten Antwort, und sie ist meist an einem Nachmittag geklärt und nicht in einem Pilotprojekt. Die Objekte selbst tragen dieselben Namen und dieselbe Form, welches System auch antwortet, denn sie kommen aus einem Datenmodell.

Was darunter liegt

Verschiedene Workflows, darunter dieselbe Anbindung

Nur die Objekte in der Tabelle darüber sind einem Workflow eigen. Alles, was eine Anfrage auf dem Weg dorthin trifft, ist geteilt, und genau deshalb kostet der zweite Workflow, den Sie bauen, einen Bruchteil des ersten. Der Zugriff wird je Kunde und je System einmal erteilt, über einen Freigabeablauf, und kein Use Case hat eine Meinung über die Token-Behandlung danach. Ergebnisse kommen in der Größe und Reihenfolge zurück, die jeder Hersteller entschieden hat, ein Paging- und Filtervertrag ist also das, was "nur lesen, was sich geändert hat" auf allen dasselbe bedeuten lässt. Ein großer Lesezugriff ist auf manchen Systemen eine Antwort und auf anderen ein Auftrag zum Abholen, und das verbirgt Asynchronous Processing. Und Events gibt es auf einem Teil der angebundenen Systeme und auf dem Rest nicht, und das macht aus der Webhooks-Seite vor allem eine Seite darüber, was zu tun ist, wenn es nichts zu abonnieren gibt.

Die zweite Hälfte dieser Liste ist das, was ein Workflow trifft, wenn etwas fehlt statt da zu sein, und es ist dieselbe Hälfte, aus der jene Tabellen kommen. Ein System, das ein Objekt nicht herausgibt, antwortet anders als eines, das kurz nicht erreichbar ist, und diese beiden im eigenen Code für jeden Hersteller einzeln auseinanderzuhalten ist ein Projekt für sich, und genau das nimmt eine Fehlerform weg. Ein Kunde, dessen Installation ein Feld erfunden hat, braucht einen Weg am Modell vorbei und keine Änderung daran. Wenn in drei Monaten jemand fragt, warum eine Buchung so aussieht, wie sie aussieht, ist die nützliche Antwort ein Nachweis dessen, was aufgerufen wurde, und keine Rekonstruktion. Wo der Aufrufer ein Agent ist statt Ihres eigenen Codes, wird dieselbe Anbindung über einen MCP-Server bereitgestellt, und nichts auf diesem Weg behält eine Kopie der Bücher, die es liest, was die Sicherheitsseite vollständig darlegt.

Ein Workflow ist nicht der einzige Einstieg. Teams, die ihren Markt kennen, bevor sie ihre Anbindung kennen, kommen meist weiter, wenn sie bei den Branchenseiten beginnen, die die Workflows sammeln, die eine Produktart üblicherweise zusammen braucht, und die Teamseiten beschreiben dieselbe Anbindung aus der Sicht dessen, der das Ergebnis in Ihrem Unternehmen trägt. Und die Case Studies sind dasselbe Material, aufgeschrieben von den Teams, die darauf gebaut haben, statt von uns.

Use-Case-FAQ

Häufige Fragen

Welche dieser Seiten sollten wir zuerst lesen?

Die, die benennt, was Ihr Produkt für seine Nutzer ohnehin tut, und nicht die, die das System benennt, das Sie anbinden sollen. Das System ist hier die Variable: Ihre Kunden fahren untereinander das, was ihre Steuerberater vor Jahren eingerichtet haben, und jede Seite unten deckt dieselbe Liste ab. Was sich von Seite zu Seite tatsächlich unterscheidet, ist, welche Objekte der Ablauf berührt und wie tief jedes davon unterstützt wird, der Ablauf ist also der nützliche Einstieg und das System das, was Sie danach prüfen.

Ist ein Use Case etwas, das Sie gebaut haben, oder ein Name für das, was wir bauen?

Ein Name für das, was Sie bauen. Maesn ist eine Anbindung an die ERP- und Buchhaltungssysteme, in denen Ihre Kunden ihre Bücher führen, und kein Produkt für die Kreditorenbuchhaltung und keines für Factoring. Jede Seite verfolgt einen Ablauf durch diese Anbindung und sagt, welche Objekte er braucht, wie weit jedes davon unterstützt wird und wo die Grenze verläuft, die Seite ist also eine Karte dessen, was die Anbindung zurückgibt, und keine Funktion, die Sie einschalten.

Wie finden wir heraus, ob ein Objekt für unsere Kunden unterstützt wird?

Je System, und das ist eine Frage mit einer eindeutigen Antwort und keinem Durchschnitt. Die Unterstützung ist Objekt für Objekt und System für System dokumentiert, der nützliche Schritt ist also, die Systeme zu prüfen, die Ihre Kunden tatsächlich fahren: jede Systemseite trägt ihre eigene Abdeckungstabelle, in der Lese- und Schreibzugriffe getrennt stehen. Was jede Seite hier stattdessen tut, ist, die zwei Enden eines Ablaufs zu benennen, das Objekt, auf dem er am meisten lastet, und das, welches über seinen Abschluss entscheidet, damit Sie wissen, welche Zeile zuerst zu prüfen ist.

Welche Zeile sollten wir zuerst prüfen?

Die schmale. Jeder Ablauf hat ein Objekt, auf dem er am meisten lastet, und eines, das über seinen Abschluss entscheidet, und das zweite lohnt es sich vor jeder Zusage gegen die Systeme Ihrer Kunden zu prüfen. Es ist die Zeile, um die herum jede Seite geschrieben ist, und nicht eine, die sie auslässt, und die Seite sagt, was es für einen Bau heißt, wenn diese Zeile dünn ist.

Unser Ablauf steht nicht auf dieser Liste. Heißt das, er geht nicht?

Nein, und die Liste beschreibt, was Teams am häufigsten gefragt haben, und ist keine Grenze. Über die Machbarkeit entscheiden Objekte und keine Namen: wenn Ihr Ablauf etwas aus den Büchern eines Kunden braucht oder etwas hinein, trifft er auf dieselben Systeme und dasselbe Datenmodell wie alles hier. Am schnellsten finden Sie es heraus, indem Sie sagen, welche Objekte Sie brauchen und in welche Richtung, denn das ist die Frage, die diese Seiten beantworten, und es ist auch die Frage, die ein erstes Gespräch beantwortet.

Wie verhalten sich diese Seiten zu den Branchen- und Teamseiten?

Ein Use Case ist ein Ablauf, eine Branchenseite ist ein Käufer, und eine Teamseite ist die Rolle in Ihrem Unternehmen, der das Ergebnis gehört. Sie beschreiben dieselbe Anbindung von drei Seiten und verlinken einander, statt einander zu wiederholen: eine Branchenseite sammelt die Abläufe, die ihre Käufer fahren, und eine Use-Case-Seite verfolgt einen dieser Abläufe von Anfang bis Ende, mit den Endpunkten und den Zahlen daran.

Jede Integration, nach der Ihre Kunden fragen. In Tagen, nicht in Monaten.

Demo buchen