Visma e-conomic Schnittstelle und API-Integration
Visma e-conomic ist eine Cloud-Buchhaltungsplattform, die KMU und Kanzleien in Dänemark und Norwegen einsetzen, und deckt Rechnungsstellung, Mehrwertsteuer, Bankabstimmung und Auswertungen ab. Es ist zugleich das Visma-Produkt, das am wenigsten wie die anderen authentifiziert: zwei eigene Tokens bei jeder Anfrage, zwei aktive APIs darunter und Cursor-Paging auf beiden. Maesn stellt eine REST-Schnittstelle vor das Ganze.
Zwei e-conomic-Tokens je Aufruf, und keines davon halten Sie
Drei Dinge an Visma e-conomic kosten Zeit, bevor Sie eine Zeile Geschäftslogik schreiben, und alle drei enden an dieser Schicht.
Ein eigenes Auth-Modell, hinter einem Standardablauf
Visma e-conomic benutzt kein OAuth. Jeder Aufruf trägt ein X-AppSecretToken, das Ihre Anwendung ausweist, und ein X-AgreementGrantToken, das zu einem Kunden gehört, und das zweite muss je Verbindung beschafft, verwahrt und angehängt werden. Maesn fährt diesen Ablauf. Ihre Nutzer erleben das Verbinden also wie überall sonst, und Ihr Code hält einen Account-Key.
Eine Schnittstelle über ein System mit zweien davon
Visma e-conomic betreibt eine REST-API und eine OpenAPI gleichzeitig, mit unterschiedlichem Verhalten bei der Paginierung und mit Funktionen, die sich auf beide verteilen. Direkt zu arbeiten heißt, zu wissen, welche der beiden welchen Endpunkt beantwortet, und dieses Wissen aktuell zu halten. Über Maesn ist die Aufteilung nicht sichtbar: eine Schnittstelle, eine Form, und das Routing passiert auf dieser Seite.
Einen Datensatz anlegen ohne die Kette vorheriger Abrufe
Ein Objekt in Visma e-conomic anzulegen verlangt Referenzen, die zuerst je Mandant geholt werden müssen: Layout, Zahlungsbedingungen, Umsatzsteuerzone, Währung und das Sachkonto. Fehlt eine, schlägt der Schreibzugriff fehl, statt abzufallen. Maesn löst sie im Hintergrund auf. Ein Anlegen bleibt also ein Anlegen und wird nicht zu einer Folge von Abfragen, die Sie pflegen, und ein neuer Mandant braucht keinen eigenen Durchgang für die Zuordnung.
In Ihrem Code kommen ein REST-Aufruf und ein Account-Key an. Die Tokens, die zwei APIs und die Referenzkette bleiben auf dieser Seite, und das nächste Buchhaltungssystem, das Sie unterstützen, kommt auf derselben Schnittstelle an.
Ein kurzes Gespräch genügt meist, um zu klären, ob Maesn zu Ihrem Anwendungsfall passt.
Findity bettet den Ausgabenabgleich in die Produkte seiner Partner ein
Findity ist eine Plattform für die Ausgabenverwaltung, die White-Label- und API-Produkte verkauft. Ihre Buchhaltungsintegrationen werden also in der Software anderer ausgeliefert statt in der eigenen.
“Maesn hat uns geholfen, Integrationen zu Buchhaltungssystemen zu bauen, und wir können uns dadurch auf andere Prioritäten in unserer Roadmap konzentrieren. Besonders schätzen wir die Unterstützung, die wir jedes Mal bekommen haben, wenn wir erweiterte Funktionen in einer Integration brauchten, die Maesn für uns eingerichtet hat.”
Drei Gründe, die Visma e-conomic Schnittstelle über Maesn anzubinden
Visma e-conomic für sich ist eine überschaubare Integration. Überschaubar ist sie nicht mehr beim zweiten nordischen System, denn das nächste teilt mit diesem einen Mutterkonzern und keine seiner Mechaniken.
Das Auth-Modell wird abgefangen, nicht dokumentiert
Ein Modell mit zwei Tokens kostet wenig im Verstehen und einiges im Pflegen, und der Pflegeaufwand vervielfacht sich mit jeder weiteren Verbindungsform in einer Codebasis. Maesn hält das App-Token und die Freigabe je Kunde und gibt Ihrem Code denselben Account-Key, den er überall sonst bekommt.
Zwei APIs, eine Schnittstelle
e-conomic betreibt eine REST-Oberfläche und eine ältere nebeneinander, und welche Funktion wo liegt, sollte Ihr Produkt nicht verfolgen müssen. Maesn liest aus beiden und antwortet auf einer Schnittstelle. Eine Fähigkeit, die zwischen ihnen wandert, ist damit unsere Migration und nicht Ihre.
Eine Integration, und sie gilt nicht nur für e-conomic
Dieselbe Schnittstelle erreicht Visma eAccounting, Holded und über 30 weitere ERP- und Buchhaltungssysteme. Ein dänischer Kunde heute und ein niederländischer im nächsten Quartal sind eine Änderung an der Konfiguration und kein Projekt, und das zweite System kostet einen Bruchteil des ersten.
Visma e-conomic führt einen Marketplace, den die anderen Visma-Produkte nicht haben
Die meisten Anbieter hören bei der API auf. Visma e-conomic betreibt einen eigenen App-Marketplace, getrennt von den Marketplaces der anderen Visma-Produkte, und hineinzukommen ist ein Verfahren und kein Formular.
Technische Unterstützung
Eine Integration gegen die Unified API und ein Datenmodell, identisch für Visma e-conomic und für alles andere, was Maesn unterstützt. Ihre Entwickler treffen auf eine Schnittstelle und nicht auf eine je Produkt.
Unterstützung bei der Partnerschaft
Maesn stößt den Eintrag gezielt für Visma e-conomic an, in den Märkten, in denen dieses Produkt tatsächlich verkauft wird, und unterstützt das Co-Marketing, das dazugehört. Der Eintrag trägt den Namen Ihres Produkts und nicht unseren.
Ein eigener Marketplace
Der Marketplace von Visma e-conomic ist nicht der von eAccounting und kein konzernweites Verzeichnis. Dort vertreten zu sein sagt nichts über die anderen Visma-Produkte, und das ist dieselbe Zersplitterung, die auch die API-Seite hat.
Ein nordisches Publikum
Die Unternehmen, die über diesen Marketplace erreichbar sind, sind die, die e-conomic betreiben, also Dänemark und Norwegen und nicht jeder Markt, in dem Visma tätig ist. Ein Eintrag hier erreicht deshalb weniger Unternehmen, als die Größe des Konzerns nahelegt, und dafür näher die, für die ein dänischer oder norwegischer Anwendungsfall gebaut ist.
Co-Marketing in zwei Märkten
Der Eintrag ist der Anfang und nicht der ganze Nutzen. Was folgt, ist gemeinsame Sichtbarkeit mit Visma in Dänemark und Norwegen, und dort wird aus einem Eintrag Pipeline statt einer Verzeichniszeile, zu der niemand scrollt.
Die Integration läuft unter dem Namen Ihres Produkts, und der Eintrag gehört Ihnen und nicht uns. Maesn ist die Schicht dahinter.
Wir stoßen den Prozess für dieses Produkt mit Ihnen an.
Ein Visma-e-conomic-Aufruf trägt ein App-Token und eine Kundenfreigabe
Visma e-conomic ist das eine angebundene Visma-System, das kein OAuth spricht, und der Unterschied ist bei jeder einzelnen Anfrage sichtbar statt nur beim Verbinden. Zwei Header reisen gemeinsam: X-AppSecretToken weist Ihre Anwendung aus und ist für alle Ihre Kunden gleich, X-AgreementGrantToken weist die Vereinbarung eines Kunden aus und ist für jeden verschieden. Der Ablauf ist ein einfacher Redirect ohne Firmenauswahl, denn die Vereinbarung, zu der eine Freigabe gehört, ist die, in der Ihr Kunde angemeldet ist.
- Modell mit zwei Tokens
- App-Token plus eine Freigabe je Kunde
- Das Anwendungstoken
- Das AppSecretToken aus Ihrer App im Entwicklerportal, einmal eingereicht und an jede Anfrage gehängt, die Maesn für Sie stellt. Es erreicht Ihre Laufzeitumgebung nie.
- Die Freigabe je Kunde
- Das Agreement-Grant-Token gehört zu einem Kunden und wird an dieser Verbindung verwahrt. Ihr Code spricht einen Kunden über den Account-Key an und sieht nie, welches Grant-Token dahintersteht.
Der praktische Wert daran, dieses abzufangen, sind weniger die Tokens als die Einheitlichkeit. Ein Team, das Visma e-conomic und ein OAuth-System direkt unterstützt, pflegt zwei Verbindungsmodelle, zwei Refresh-Verhalten und zwei Fehlerfälle. Über Maesn sind beide dieselben drei Zeilen.
- 1
Ihr Kunde startet in Ihrem Produkt
Sie schicken ihn in den Ablauf, und Maesn öffnet den Zustimmungsbildschirm von Visma e-conomic. Er trägt den Namen Ihrer Anwendung, denn die App ist auf Ihr Unternehmen registriert.
- 2
Er stimmt der Vereinbarung zu
Die Zustimmung erzeugt das Agreement-Grant-Token für diesen Kunden. Unterwegs gibt es nichts zu wählen. Die Freigabe landet also auf der Vereinbarung, in der er angemeldet ist, und der Ablauf kehrt sofort zurück.
- 3
Sie arbeiten mit einem Account-Key
Maesn speichert die Verbindung und gibt einen Account-Key zurück. Jede Anfrage trägt dann Ihren Maesn-API-Schlüssel und diesen Account-Key, und das Modell mit zwei Tokens taucht in Ihrem Code nie auf.
Ein eigenes Token-Modell ist für sich genommen nicht schwierig. Teuer wird es, wenn es die vierte Verbindungsform in einer Codebasis ist, jede mit eigenem Refresh-Verhalten und eigener Art zu scheitern. Unified Authentication macht daraus einen einmaligen Aufwand: Der Zustimmungsdialog, die Token-Speicherung und der Account-Key verhalten sich hier genauso wie bei einem System, das sich mit nichts als einem Schlüssel authentifiziert.
Visma-e-conomic-Events gibt es auf Anfrage
Visma e-conomic kann Events senden, und für diese Anbindung ist heute keines eingeschaltet. Bei den meisten Objekten ist das Event als auf Anfrage markiert. Das ist also eine Frage der Freischaltung und keine danach, was das System unterstützt.
Nichts, was Sie empfangen, ohne es vorher zu vereinbaren. Eine Änderung im Visma-e-conomic-Konto eines Kunden bleibt unsichtbar, bis etwas sie liest, obwohl das System selbst benachrichtigen kann.
Ein geplanter Lesezugriff, auf demselben Filter und derselben Paginierung wie bei jedem anderen System, das Sie anbinden. Wo die Events eines Objekts Ihr Produkt verändern würden, lassen sie sich für dieses Objekt freischalten.
Die Paginierung ist der Teil, der hier wissenswert ist. Die REST-Oberfläche von e-conomic und seine ältere API paginieren beide über einen Cursor. Es gibt also kein Springen zu einer Seite und kein Limit und Offset: Tief in einen Datenbestand zu reichen heißt, alles davor zu durchlaufen. Über Maesn antworten beide auf gewöhnliches Offset-Paging, und das Durchlaufen passiert auf dieser Seite.
Nach Zeitplan zu lesen ist die Stelle, an der eine Integration je System ihre Kosten am deutlichsten zeigt, weil jedes System anders paginiert und dieses hier auf beiden seiner APIs über einen Cursor paginiert. Ein Weg, zu filtern und zu paginieren nimmt das weg, und das Event-Modell ist der Ort, an dem ein Visma-e-conomic-Objekt landet, sobald eines dieser Events eingeschaltet wird.
Was eine Visma-e-conomic-Anbindung braucht, vor dem ersten Aufruf
Visma e-conomic nennt in seiner Dokumentation genau eine Voraussetzung, und der Rest dieser Liste ist die Arbeit, die daraus folgt. Nichts davon ist Code.
- Ein aktives Visma-e-conomic-Konto
- Die ganze Voraussetzungsliste der Dokumentation ist eine Zeile: ein aktives Visma-e-conomic-Konto. Das sollte man im Qualifizierungsgespräch bestätigen, denn ohne eines gibt es nichts anzubinden.
- Eine App im Visma-e-conomic-Entwicklerportal
- Sie melden sich im Entwicklerportal an, legen eine Anwendung an und tragen die Callback-URL von Maesn dort ein. Die App ist auf Ihr Unternehmen registriert. Der Zustimmungsbildschirm, den Ihr Kunde sieht, trägt also Ihren Namen und nicht unseren.
- Das AppSecretToken, einmal an Maesn übergeben
- Ein Wert, an Ihren Ansprechpartner bei Maesn übergeben und danach für jeden Kunden benutzt, den Sie anbinden. Das Grant-Token je Kunde wird beim Verbinden beschafft und nicht von Ihnen geliefert.
- Ein Testkonto, bevor ein Kunde den Ablauf sieht
- Die Sandbox-Dokumentation von Maesn führt Visma e-conomic sowohl mit einer kostenlosen Testphase als auch als von Maesn bereitgestellt, beide Wege stehen also offen. Einen davon zuerst zu nutzen lohnt sich, denn die Kette an Referenzen hinter einem Anlegen ist der Teil, den ein direkter Bau meist spät entdeckt.
Wir gehen die Registrierung im Entwicklerportal mit Ihnen durch.
Eine Form für e-conomic, und für das nächste nordische System
Eine Anbindung liest hier die Hauptbuchseite einer dänischen und norwegischen Buchhaltungsplattform. Dafür zu bauen lohnt sich, weil das nächste System in dieser Region in derselben Form antwortet.
Benannte Objekte statt einer Zahl
Konten, Kunden, Journale und Lieferanten sind zum Lesen freigeschaltet, Buchungsvorschläge und Zahlungen zum Schreiben. Der Rest der Matrix steht auf Anfrage, und das heißt, dass er freigeschaltet wird, wenn ein Anwendungsfall ihn braucht, und nicht, dass er nicht verfügbar ist.
Korrekturen sind neue Datensätze
Ein Datensatz wird hier nicht an Ort und Stelle geändert. Ein Produkt, das Zahlen im Gleichschritt hält, schreibt also einen korrigierenden Beleg, statt das Original zu bearbeiten. Die Buchhaltungspraxis arbeitet genauso, und deshalb ist das eine Entwurfsentscheidung, die früh fällt, und keine Einschränkung, um die man herumarbeitet.
Eine gebuchte Rechnung ist endgültig
Visma e-conomic trennt Rechnungen in Entwürfe und gebuchte, und eine gebuchte Rechnung lässt sich nicht mehr ändern: Eine Korrektur ist eine Gutschrift. Das ist das Modell des Systems und keine Einschränkung dieser Verbindung, und deshalb sieht ein Korrekturablauf hier anders aus als auf einem System, das eine Änderung an Ort und Stelle erlaubt.
Die Beschaffungsobjekte liegen außerhalb dieses Systems
Wareneingänge, Bestellungen und deren Positionen gehören nicht zu dem, was e-conomic bereitstellt, und eine Summen- und Saldenliste wird aus dem Hauptbuch zusammengestellt, statt als eigenes Objekt geliefert zu werden. Wo ein Produkt das braucht, erreicht dieselbe Schnittstelle die Systeme, die es führen.
Was noch nicht eingeschaltet ist, ist eine Anfrage und keine Absage. Diese Objekte sind solche, die auf dieser Anbindung bisher niemand gebraucht hat, und der Weg, das zu ändern, ist zu sagen, welches Objekt Ihr Anwendungsfall liest oder schreibt.
Was Sie abrufen, kommt im selben Common Data Model an wie bei jedem anderen angebundenen System, und genau das macht ein zweites nordisches System günstig statt zu einem zweiten Projekt. Der Rest des Portfolios steht auf der Seite Visma API.
Sagen Sie uns, welche Objekte Ihr Anwendungsfall braucht, und wir bestätigen, was möglich ist.
