DATEV Unternehmen Online oder Rechnungswesen: ein Objekt geht an beide

DATEV Unternehmen Online ist die Cloud-Plattform, auf der ein deutsches Unternehmen und sein Steuerberater Belege und Buchführungsdaten austauschen. DATEV Rechnungswesen ist die Anwendung, in der die Buchung endgültig erfasst wird, und sie ist auf dem Server eines Anbieters oder auf dem des Kunden installiert.

Welches ein Unternehmen hat, folgt daraus, wer die Buchführung macht. Ein Unternehmen, das sie seinem Steuerberater übergibt, arbeitet in Unternehmen Online, und der Steuerberater arbeitet in Rechnungswesen. Ein Unternehmen, das im Haus bucht, hat Rechnungswesen und trotzdem Unternehmen Online, als Cloud-Weg in die eigene Instanz.

Keiner der beiden Fälle hindert eine Anbindung daran, Rechnungswesen zu erreichen. Auch dort, wo nur Unternehmen Online im Einsatz ist, ist die Instanz beim Steuerberater des Kunden erreichbar, identifiziert über Berater- und Mandantennummer. Die Frage ist also nicht, welches Produkt ein Kunde besitzt. Sie ist, welches die Daten hält, um die es in Ihrem Feature geht.

Dieser Artikel beantwortet genau diese eine Frage. Wie Sie gegen das eine oder das andere Produkt bauen, sobald Sie gewählt haben, ist ein Thema für sich, und jedes hat seinen eigenen Leitfaden: der Leitfaden zu Unternehmen Online behandelt asynchrone Schreibzugriffe und den zweistufigen Token, der Leitfaden zu Rechnungswesen behandelt drei Zielsysteme und zwei Token-Laufzeiten.

Die kommerziellen Angaben und die Coverage je Produkt stehen auf der Seite zur DATEV Unternehmen Online Schnittstelle und auf der Seite zur DATEV Rechnungswesen Schnittstelle, und die Herstellerebene, also die vollständige Liste der Datenservices und der Partnerstatus, steht eine Ebene höher in der DATEV-Übersicht.

Unternehmen Online nimmt 4 Objekte an und Rechnungswesen 3, und die beiden Listen teilen sich 1: Files. Diese Überschneidung ist keine Wahl, die Sie treffen. Ein Beleg geht immer an Unternehmen Online, auch dann, wenn die Buchung, zu der er gehört, gerade in Rechnungswesen geschrieben wird. Die beiden Produkte teilen sich die Zeile also, weil sie sich eine Station teilen. Die Nutzlast selbst geht trotzdem nur einen Weg.

Das bedeutet außerdem, dass das Mapping, das die meisten Teams zuerst versuchen, auf keinem der beiden Produkte existiert. Eine Rechnung in Ihrem System wird keine Rechnung in DATEV: Invoices, Bills und Credit notes sind hier keine schreibbaren Objekte, und der Beleg reist als Datei, während die Daten über ihn als etwas reisen, das das Zielprodukt kennt.

Was dieses Etwas ist, hängt vom Produkt ab, und das ist die Zeile, die über die meisten Bauvorhaben entscheidet. Ein Buchungsvorschlag ist ein Vorschlag, den der Steuerberater prüft, und nur Unternehmen Online nimmt einen an. Ein Buchungssatz ist eine fertige Buchung, und nur Rechnungswesen nimmt einen an.

Files · create ist auf beiden DATEV-Produkten freigeschaltet, einen Beleg zu liefern ist also der Teil, der nichts entscheidet. Zu entscheiden, was der Beleg bedeutet, ist die Stelle, an der die beiden Produkte auseinandergehen.

Über maesn antworten beide Produkte auf einer Schnittstelle, die Wahl unten ist also ein Ziel und eine Nutzlast und keine zwei Anbindungen. Sie schicken das gemeinsame Datenmodell, und die Übersetzung in die Form, die jedes Produkt erwartet, passiert auf unserer Seite.

In Rechnungswesen, und unter einem anderen Namen. Das Personenkonto ist in unserem Modell Contacts. Es lässt sich in Rechnungswesen anlegen und an Ort und Stelle aktualisieren, zurücklesen lässt es sich nicht, und in Unternehmen Online gibt es das Objekt gar nicht.

Drei Vokabulare treffen auf diesem einen Objekt zusammen, und sie meinen alle denselben Datensatz. Was die deutsche Buchführung einen Debitor oder einen Kreditor nennt, nennen die meisten Produktteams einen Kunden oder einen Lieferanten, und beide erreichen DATEV über Contacts. Der Unterschied zwischen den beiden ist die Kontonummer: ein Debitorenkonto liegt in dem einen Nummernkreis und ein Kreditorenkonto in dem anderen, und geschrieben werden beide als Personenkonto.

Deshalb sind Customers und Suppliers hier keine eigenen Objekte, und ein Team, das auf diese beiden Namen mappt, sucht nach etwas, das es unter ihnen nie gegeben hat. Mappen Sie auf Contacts, dann ist der Datensatz da.

Die Folge ist in einem echten Projekt leichter zu sehen als in einer Tabelle. Ein Produkt, das Lieferantenstammdaten synchronisiert und außerdem Eingangsrechnungen liefert, hat zwei Hälften, die auf zwei verschiedenen Produkten landen: die Rechnung erreicht Unternehmen Online als Beleg plus Vorschlag, das Konto erreicht Rechnungswesen als Kontakt.

Wenn Ihr Feature eine beidseitige Synchronisation von Kunden- und Lieferantendaten ist, gibt es die lesende Hälfte davon für dieses Objekt auf keinem der beiden DATEV-Produkte. Planen Sie die einseitige Fassung und führen Sie selbst Buch über das, was Sie geschrieben haben.

Drei Datenservices, und Sie benutzen genau einen je Call. Der Belegbilderservice nimmt ein Belegbild für sich. Der Rechnungsdatenservice 1.0 nimmt dasselbe Bild zusammen mit seinen strukturierten Daten, der Steuerberater bekommt also einen Buchungsvorschlag, den er nur noch prüfen muss. Der Buchungsdatenservice nimmt einen fertigen Buchungssatz.

Die ersten beiden liefern in Unternehmen Online und enden bei etwas, auf das ein Mensch noch reagieren muss. Der dritte schreibt in Rechnungswesen und endet bei einer Buchung im Hauptbuch. Welchen Sie aufrufen, folgt daraus, was Sie haben: ein PDF allein, ein PDF mit seinen Daten, oder eine Buchung, die auf Ihrer Seite bereits abgestimmt ist.

Was als Nächstes passiert, ist ein Schritt, den Ihr Call nicht macht. Die strukturierten Daten laufen nicht von selbst weiter nach Rechnungswesen: sie werden aus der Oberfläche von Unternehmen Online an das DATEV-Rechenzentrum übergeben, vom Unternehmen oder vom Steuerberater, nachdem die Kasse geprüft ist, und von dort in die Rechnungswesen-Instanz abgeholt.

Auch die Voraussetzungen unterscheiden sich je Weg, und sie liegen alle auf der Seite Ihres Kunden.

Ein Belegbild zu senden braucht Unternehmen Online mit dem Belegbilderservice. Buchungsvorschläge brauchen stattdessen den Rechnungsdatenservice 1.0. Buchungssätze direkt zu senden braucht Rechnungswesen und obendrein den Buchungsdatenservice.

Eine Voraussetzung hängt man leicht an den falschen Call: die Kasse, die ein DATEV-Anwender von Hand als Verrechnungskonto anlegt, gehört zu POST /expenses. POST /bookingProposals braucht keine.

Jeder Weg hat außerdem sein eigenes Dateiformat, und das Ziel entscheidet darüber: welches DATEV-Format zu welchem Ziel gehört, ist ein Thema für sich. Eine dieser Dateien schreiben Sie nie selbst. Sie schicken JSON an unsere REST-API, und wir bauen die CSV oder die XML, die das Ziel erwartet.

Rechnungswesen gibt 8 Objekte zurück und Unternehmen Online 5. Welche Objekte sie zurückgeben, ist das, was über den Bau entscheidet. Beide Produkte geben Accounts, Async task, Fiscal years, Tax rates, Users zurück, und Accounts in dieser Liste ist der Kontenrahmen, gegen den jede Buchung gebucht wird, also der Lesezugriff, den Teams am häufigsten unterschätzen. Rechnungswesen legt dann das nach, worauf ein Reporting- oder Abstimmungsprodukt aus ist: Journal entries, Payment terms, Trial balance.

Journal entries ist das eine Objekt, das den Hin- und Rückweg macht. Sie senden eine Buchung und können sie zurück abfragen, und das ist es, was ein Abstimmungsfeature von einem Lieferfeature trennt und warum ein Reportingprodukt bei Rechnungswesen selbst landet.

Eine Bedingung kommt mit dem Lesezugriff, und sie ändert Ihr Design. Verfügbar sind nur festgeschriebene Daten: Buchungen werden exportierbar, nachdem die Buchungsstapel der Festschreibung unterzogen und über DATEVs Standard-Buchungsprozess übergeben worden sind. Eine Buchung, die in der Oberfläche des Steuerberaters existiert, ist damit nicht automatisch eine Buchung, die Sie abfragen können.

Was der Export zurückgibt und was die Festschreibungsregel mit einem Synchronisationsplan macht, steht im Leitfaden zum DATEV Datenservice Export Rechnungswesen. Für ein Produkt, das auf den Zahlen aufbaut, ist dieser Lesezugriff der ganze Grund, warum DATEV auf der Roadmap steht, und Finanzanalyse und Finanzplanung ist das, was Teams damit machen.

Die Entscheidung folgt daraus, was Ihr Produkt erzeugt, und jede Zeile trägt den Objektzustand, auf dem sie beruht.

Die letzte Zeile ist die, die Teams überrascht, weil eine E-Rechnung wie eine Rechnung aussieht und eine Rechnung wie Buchführung. DATEV betreibt dafür ein drittes Ziel, und der Leitfaden zur E-Rechnungsplattform behandelt, was dort heute möglich ist und was nicht.

Die meisten Produkte landen auf beiden Produkten dieses Vergleichs, und das ist das normale Ergebnis. Was die Tabelle verhindert, ist der andere Fall: die liefernde Hälfte gegen Unternehmen Online zu bauen und während eines Abstimmungsfeatures festzustellen, dass das Hauptbuch von dort nie lesbar war.

Drei Eigenschaften gelten für beide Produkte, und jede davon ändert eine Designentscheidung. Nur Contacts lässt sich an Ort und Stelle aktualisieren, und das nur in Rechnungswesen. Kein Objekt auf einem der beiden Produkte unterstützt ein Löschen. Und kein Objekt auf einem der beiden Produkte sendet ein natives Ereignis.

Die ersten beiden folgen der Buchführungspraxis statt einer Lücke in der Schnittstelle. Eine erfasste Buchung bleibt, wie sie ist, und eine Korrektur ist eine Gegenbuchung, so wie ein Prüfer es auch erwartet. Einen Aktualisierungspfad für Buchungssätze zu bauen wäre Arbeit, die die Fachlichkeit selbst dann ablehnen würde, wenn es den Endpunkt gäbe.

Die dritte Eigenschaft hat eine zweite Hälfte, die man leicht übersieht. Ohne Ereignisse, die sich abonnieren lassen, ist ein Zeitplan der Reflex, und geplante Lesezugriffe sind in Ordnung. Was DATEV in seinen Schnittstellenvorgaben im Abschnitt Ökonomie & Ökologie als DONT führt, ist Polling rund um die Uhr ohne ein Kundeninteresse dahinter. Ein DONT ist keine technische Sperre und nichts weist den Call ab; es gefährdet die Freigabe Ihrer Anbindung, und das ist die teure Sorte Problem, weil sie spät auftaucht.

In der Praxis verläuft die Linie beim Anlass des Calls. Ein Lesezugriff, der auf etwas folgt, das Ihr Kunde getan hat, oder auf eine Regel, die er konfiguriert hat, ist das, worum DATEV bittet. Eine Schleife, die jede Minute über jeden Mandanten läuft, ob nun jemand auf die Daten wartet oder nicht, ist das, wogegen DATEV argumentiert.

Aktualität ist auf beiden Produkten damit eine Produktentscheidung, und wie unterschiedlich die Ereignis-Coverage über Systeme hinweg ausfällt, macht diese Entscheidung über Ihren restlichen Katalog hinweg vergleichbar.

Drei Dinge hören auf, Ihre zu sein, sobald Sie über maesn anbinden, und der Rest bleibt bei Ihnen. Beide Hälften sollten Sie kennen, bevor Sie die Arbeit planen:

• Zugang zu DATEV ohne den Partnerprozess vorweg. Sie bauen auf dem maesn-Client, es muss also vor Ihrem ersten Call nichts beantragt, bezahlt oder abgewartet werden, und das gilt für beide Produkte. Was DATEV freigibt, ist eine Anbindung statt eines Produkts, und welche Datenservices sie benutzt, ist das, was sie definiert. Wenn Sie später im eigenen Namen offizieller DATEV Schnittstellenanbieter werden wollen, führen wir diesen Prozess mit Ihnen und Sie ziehen auf Ihren eigenen Client um; die DATEV-Gebühren dafür sind Ihre, und Sie bauen in der Zwischenzeit weiter. Der Leitfaden zur Partnerschaft behandelt, was DATEV prüft und wann.
• Die Formate und die Services hinter jedem Weg. Ob eine Nutzlast als Belegbild, als strukturiertes XML oder als Buchungssatz im DATEV-Format hinausgeht, und durch welchen Datenservice sie reist, wird hier entschieden.
• Zwei Produkte hinter einer einzigen Art von Zugangsschlüssel. Zu welchem Zielsystem ein Call gehört, und welcher Login und welcher Token dahinterstehen, klärt sich während der Verbindung und nicht an Ihren Aufrufstellen.

Drei Dinge bewegen sich nicht, und zwei davon sind Entscheidungen, die Sie einmal treffen:

• Auf welches Produkt ein Feature zielt. Das Objekt, das Ihr Feature erzeugt, engt das auf eine Antwort ein, und welches Feature zuerst kommt, ist Ihre Sache.
• Was Ihre Oberfläche dem Kunden sagt. Geliefert ist nicht gebucht, und ein Kontakt, den Sie geschrieben haben, lässt sich nicht zurücklesen. Beides sind Fragen der Formulierung in Ihrem Produkt, und keine Oberfläche kann sie verbergen, ohne zu lügen.
• Was einen Call auslöst. Eine Kundenaktion oder eine vertretbare Regel ist eine Produktentscheidung, und dort sind DATEVs Vorgabe und Ihre eigene Roadmap in Einklang zu bringen.