Ich habe gerade diese Email von DATEV bekommen 
ab dem 01.01.2020 stehen Ihnen alle Inhalte auf dem DATEV Developer Portal (https://developer.datev.de) kostenlos zur Verfügung.
Neben dem Blog mit aktuellen Informationen und den Dokumentationen API Kassenarchiv und Login mit DATEV, stehen ab diesem Zeitpunkt auch die Schnittstellendokumentationen DATEV-Format, DATEV XML-Schnittstelle online, DATEVconnect sowie DATEVconnect online kostenlos auf dem Portal zur Verfügung.
Betrifft: ERPNext Version 13
Der Buchungsstapel des DATEV Export lässt sich zukünftig auf einen Buchungstyp (Eingangsrechnung, Ausgagsrechnung, etc.) beschränken:
Die exportierte Datei wurde vom DATEV-Format Prüfprogramm als korrekt befunden:
I propose some further development:
Hallo zusammen,
erstmal vielen Dank für die Entwicklung der DATEV-Schnittstelle!
Ich bin derzeit noch dran ERPNext für mein Unternehmen einzurichten und habe leider noch ein paar Probleme mit dem Export:
Zum einen fehlen bei mir teilweise die Gegenkontonummern. Das liegt daran, dass der Bericht sich momentan die Gegenkontonummern aus der “Party Account”-Tabelle zieht, d. h. wenn dort kein spezielles Kreditoren-/Debitorenkonto hinterlegt ist bleibt das Feld leer, anstatt das Standard-Unternehmenskonto für Verbindlichkeiten oder Forderungen zu verwenden. Im Screenshot sollte hier in Zeile 19 und 20 beispielsweise 3300 stehen. Das kommt bei uns deshalb häufig vor, da wir bei einigen Lieferanten ausschließlich Bar bezahlen und diese daher kein eigenes Kreditorenkonto bei unserem Steuerberater bekommen haben.
Ein weiteres Problem dieses Ansatzes ist der, dass sich das Gegenkonto einer Rechnung nachträglich verändern lässt, wenn es im Lieferanten-Master geändert wird.
Wäre es hier nicht sinnvoller auf die Felder “credit_to” und “debit_to” der Eingangs-, bzw. Ausgangsrechnungen zuzugreifen? Die beiden Felder bekommen ihre Werte ja vom Unternehmensstandard und der “Party Account”-Tabelle und sind nach der Buchung der Rechnung unveränderlich.
Weiterhin wundert mich Zeile 18 im Screenshot ein bisschen. Ist diese wirklich notwendig für DATEV? Von meinem Verständnis von Buchungssätzen her sollten Zeile 19 und 20 eigentlich ausreichen. Das Problem ist nur, dass ich das nicht nachprüfen kann, da ich selbst kein DATEV habe und unser Steuerberater sich derzeit etwas quer stellt.
Ich habe für mich den Code für den Bericht entsprechend angepasst und bezüglich Eingangs- und Ausgangsrechnungen funktioniert auch alles, allerdings wollte ich zunächst hier im Forum nachfragen ob mein Gedankengang da überhaupt richtig ist bevor ich weiter daran arbeite oder eine Pull-Request erstelle.
Hallo @P-Froggy,
danke für deine Anregungen. Der Gedanke war ursprünglich, alle Hauptbucheinträge (GL Entry), die ERPNext erstellt, zu exportieren.
Im Hauptbuch kannst Du sehen, dass ERPNext für deine Zeilen 19 und 20 gar kein Gegenkonto hinterlegt, sondern lediglich den Namen des Kunden bzw. Lieferanten. Daher wird hier nur ein Konto angezeigt, wenn dem entsprechenden Kunden/Lieferanten eines zugeordnet ist. Ein Workaround wäre möglicherweise, dafür das Standard-Unternehmenskonto zu hinterlegen.
Unser Steuerberater hätte sogar gerne nur die Zeile 18, mit einem entsprechenden Automatik-Konto. Wahrscheinlich wäre es sinnvoll, den DATEV Export auf die einzelnen DocTypes aufzuteilen und speziell, beispielsweise an Eingangsrechnungen, anzupassen. Damit könnte man auch besser auf Felder wie credit_to und debit_to zugreifen als in einem generischen Export des Hauptbuches.
Ich würde mich freuen, wenn Du deinen Code hier mit uns teilst. Dann haben wir eine konkrete Diskussionsgrundlage.
Vielen Dank für die Rückmeldung @rmeyer!
Meiner Meinung nach ist das auch der beste Ansatz, die Daten aus dem Hauptbuch zu ziehen, da man dann eine allgemeingültige Lösung hat, welche mit allen Bilanz- und GuV-wirksamen Transaktionen funktioniert.
Im Prinzip stecken im Hauptbuch auch ohne die Nutzung des Gegenkontos alle Informationen, die man für den Export brauchen würde.
Das Problem hier finde ich liegt auch nicht an ERPNext, sondern der Art wie DATEV die Exportdaten verlangt. Theoretisch könnte man alle Einträge aus “GL Entry” abrufen und die alle Soll/Debit mit den Haben/Credit matchen. Das funktioniert allerdings nur, wenn entweder im Soll oder im Haben nur ein Konto bebucht wird, da ansonsten nicht mehr klar zuordnungsbar ist, welcher Betrag an welches Konto geht. Hier zeigt sich meiner Meinung nach, dass DATEV bei der Festlegung ihres Formates etwas kurzsichtig, bzw. zu klassisch buchhalterisch gedacht hat.
Eine Möglichkeit wäre natürlich auch, dass das Gegenkonto immer ein Verrechnungskonto ist. Dieses würde sich ja automatisch immer ausgleichen. Ich weiß allerdings nicht, ob das für die Steuerbüros ein akzeptables Vorgehen wäre.
Wegen mir müsste jetzt auch nicht unbedingt etwas am Export geändert werden, ich wollte mich nur versichern, dass alles passt. Wie gesagt bekomme ich derzeit von unserem Steuerberater keine Hilfe und auf der anderen Seite wird erwartet, dass ab der Umstellung in unserem Betrieb auf ERPNext auf Anhieb alles funktioniert. Das macht es für mich ein bisschen schwieriger als nötig wäre.
Ich suche den Code später noch heraus, ist allerdings nichts spannendes. Im Prinzip habe ich den Left-Join von “Party Account” nur durch einen Left-Join von “Purchase Invoice”, bzw. “Sales Invoice” abhängig vom DocType des Beleges im Hauptbuch ersetzt.
erpnext 12.9.4
frappe 12.6.2
Ich wollte nun auch mit dem DATEV Export starten, aber wenn ich auf “Download DATEV Export” klicke, erhalte ich eine latin-1 Fehlermeldung (wohl wegen dem Euro Zeichen). Der CSV Export hat das Problem nicht und latin-1 steht ja wirklich explizit in der datev.py drin… Ist latin-1 vorgeschrieben aus DATEV Gründen?! Wieso nicht UTF-8 nutzen?
https://…/api/method/erpnext.regional.report.datev.datev.download_datev_csv?filters={%22company%22:%22firma%22,%22from_date%22:%222020-05-01%22,%22to_date%22:%222020-05-31%22}
Traceback (most recent call last):File “/home/frappe/bench/apps/frappe/frappe/app.py”, line 62, in application
response = frappe.api.handle()
File “/home/frappe/bench/apps/frappe/frappe/api.py”, line 56, in handle
return frappe.handler.handle()
File “/home/frappe/bench/apps/frappe/frappe/handler.py”, line 22, in handle
data = execute_cmd(cmd)
File “/home/frappe/bench/apps/frappe/frappe/handler.py”, line 61, in execute_cmd
return frappe.call(method, **frappe.form_dict)
File “/home/frappe/bench/apps/frappe/frappe/init.py”, line 1055, in call
return fn(*args, **newargs)
File “/home/frappe/bench/apps/erpnext/erpnext/regional/report/datev/datev.py”, line 512, in download_datev_csv
frappe.response[‘result’] = get_datev_csv(data, filters)
File “/home/frappe/bench/apps/erpnext/erpnext/regional/report/datev/datev.py”, line 489, in get_datev_csv
data = data.encode(‘latin_1’)
UnicodeEncodeError: ‘latin-1’ codec can’t encode character ‘\u20ac’ in position 27221: ordinal not in range(256)
Hallo zusammen,
habe mich jetzt seit einiger Zeit nicht mehr gemeldet da mich die Mehrwertsteuersenkung ziemlich viel Zeit gekostet hat. Das Ganze hat mir jetzt aber auch gezwungenermaßen in der Praxis gezeigt, dass ein Verrechnungskonto als Gegenkonto meiner Meinung nach die einzige sinnvolle Lösung ist, da eine Transformation vom Buchungsschema in ERPNext (zusammengesetzte Buchungssätze) in das Schema von DATEV (nur einfache Buchungssätze (Konto → Gegenkonto)) nicht möglich ist.
Kleines Beispiel von unserem Restaurantbetrieb aus der Praxis:
Seit 1. Juli werden Getränke mit 16% Umsatzsteuer und Speisen mit 5% Umsatzsteuer besteuert. Begleicht ein Gast nun beispielsweise eine Rechnung zum Teil mit einem Gutschein, zum Teil in bar, entsteht folgender Buchungssatz:
1600 Kasse 200 €
3786 Ausgegebene Geschenkgutscheine 100 €
an 5400 Erlöse 16% USt 180 €
an 5300 Erlöse 5% USt 120 €
Da im Soll und im Haben jeweils mehr als ein Konto genutzt wird ist eine Transformation in einfache Buchungssätze mit Konto und Gegenkonto nicht möglich. SAP und andere Kassensysteme haben das gleiche Problem. Das hat unser Steuerberater inzwischen auch eingesehen, weshalb wir seit Anfang Juli besagtes Verrechnungskonto verwenden.
@rmeyer: Ich hatte versprochen meinen Code zu posten, wegen oben angesprochenen Umstand habe ich diesen allerdings wieder verworfen. Wenn es im Interesse aller ist, würde ich aber demnächst ein Pull-Request mit folgenden Änderungen für die Develop-Branch einreichen:
Offen bleibt noch die Thematik mit der Umsatzsteuerautomatik, das könnte man hinbekommen wenn in den DATEV-Einstellungen eine Child-Table erstellt, welche die jeweiligen Konten mit den dazugehörigen Umsatz-/Vorsteuerkonten mappt.
Hallo, @P-Froggy !
Sorry - kann sein, dass ich Dich falsch verstehe, aber ich sehe Dein Problem nicht.
Dein Geschäftsvorfall ist für mich wie folgt zu buchen :
Konto Gegenkonto Betrag
leer 1600 200
leer 3786 100
5400 leer 155,17
UST 16% leer 24,83
5300 leer 114,29
UST 5% leer 5,71
Und so sind die Buchungssätze an Datev zu übergeben. Und so - wenn die Schnittstelle so befüllt wird - akzeptiert auch Datev die Buchungen.
Damit sollte ERPNext ohne Zusatzfelder einwandfrei funktionieren.
Viele Grüße
Hallo @FHammer,
ich wusste nicht, dass man das Konto/Gegenkonto auch leer lassen kann. Bin davon ausgegangen, dass DATEV immer beide Konten verlangt.
Ich kann das halt nicht selbst testen und bin deshalb von Fällen wie diesen hier ausgegangen, laut denen es nicht möglich ist: Import von Buchungssätzen ohne Gegenkonto - DATEV-Community - 75283
Aber falls das so möglich ist und der Steuerberater da nicht händisch Buchungen abändern muss, wäre das natürlich super.
Hallo, @P-Froggy !
Leider setze ich selbst eine Datev-kompatible Software ein, die mit Splitbuchungen bei denen explizit das Gegenkonto leer gelassen wird kein Problem hat. Mit Datev direkt kann ich nicht testen. Sollte Datev hierbei Ärger machen, würde ich als Gegenkonto grundsätzlich ein Dummy-Konto (9990 o.ä.) angeben, da am Ende eines Buchungsstapels dieses Konto ja grundsätzlich 0 sein muss.
Unter Willkommen | DATEV Developer Portal gibt es seit Anfang des Jahres die Spezifikation sowie ein Windows-Programm, mit dem die von ERPNext produzierten Dateien geprüft werden können (funktioniert mit wine auch unter Ubuntu).
Den Ansatz mit Verrechnungs- oder Dummy-Konto können wir gerne aufnehmen. 
Freds Variante könnte ebenfalls über eine entsprechende Einstellung ermöglicht werden.
hallo Leute,
benutzt den DATEV Export eigentlich nun jemand erfolgreich ? Irgendwie ruhig geworden um das Thema. Man liest zwischen den Zeilen "implementiert nach bestem Wissen und Gewissen aber nix genaues weiß man nicht ". Wär aber schad drum, denn das braucht ebenso wie Banking doch jeder.
Wenn wir das nicht so ganz fit kriegen bastelt mangels Vertrauen wahrscheinlich jeder selbst an einer kleinen Lösung damit “man weiß was man hat”. Wär super schade.
Grüße
Otmar
Hallo Otmar,
der Stand ist wie folgt: Der von ERPNext erzeugte Buchungsstapel übersteht das Prüfprogramm von DATEV ohne Fehler. Es können also alle Hauptbucheinträge aus ERPNext im DATEV-Format exportiert werden.
Aufgrund der unterschiedlichen Formate und Funktionen von ERPNext und DATEV (bspw. Split-Buchungen, Automatikkonten) kann es dennoch, je nach Anwendungsfall, zu Schwierigkeiten kommen. Außerdem interessiert sich ein Steuerberater möglicherweise nicht für alle Hauptbucheinträge (Filter nach Belegart kommt in Version 13). Wir überlegen derzeit, die zu exportierenden Daten für die einzelnen Belegarten explizit zu definieren statt pauschal die Hauptbucheinträge zu exportieren.
Zur Zeit kann man also in der Regel nicht einfach auf einen Knopf drücken und die Buchhaltung landet vollständig und korrekt beim Steuerberater. Wir sind kontinuierlich dabei alle Probleme, die uns im Produktivbetrieb auffallen, zu beheben und die Lösungen zu ERPNext beizutragen. Unternehmen, die mit ihrem Anwendungsfall auf Probleme stoßen, können uns gerne damit beauftragen, diese für sich und die Allgemeinheit zu lösen.
Viele Grüße
Raffael
danke Rafael,
scheint irgendwie komplizierter als man sich das vorstellt. Kenn das Thema von Kivitendo , das benutzen wir. Es funktioniert zwar jetzt im 3. Jahr aber es kam auch schon zu Poblemen. Es ist wohl so, daß entweder die Steuerbuchungen gar nicht im csv export drin sind oder jedenfalls der Berater die Steuerbuchungen ignoriert und aufgrund der SKR04 Konten automatisch nochmal bucht oder berechnet, was auch schon dazu geführt hatte daß österreichische Steuern in Deutschland nochmal deklariert wurden 
vermutlich weil ich ein Umsatzkonto für in österr. zu deklariernde Steuern aus dem Datev Kontenraum für deutsche Steuern verwendet hatte. Ein Witz, was gilt denn was in meiner Buchführung = Export gebucht ist oder definiert der Kontenrahmen impliziert die Steuern ? Oder ein Mix aber was gilt dann wann ?
Ist mir wirklich spanisch warum da soviele Freiräume sind dass Export / Import sich nicht selbstverständlich und 100% verstehen. Das Feld scheint eine Spezifikation oder Implementierungen zu sein wie Schweizer Käse.
Mir schwant schon, wenn wir auf ERPNext umsteigen fängt der ganze Terz von vorne an. Und wenn Ihr auch keine wasserdichte Lösung habt werden wir was Eigenes machen, denn es ist immer noch besser eine eigene Teillösung zu haben wo man weiß was man hat als was Fremdes wo man nicht weiß was funktioniert und wo es hakt.
Da frag ich mich wie machen das dann Lexware, Exact, SAP, SAGE , ADDISSON und Co oder DATEV selbst mit seinen Anwendungen ?
Grüße Otmar
Wie passt das zusammen?
Hallo, Otmar !
Nach meiner Erfahrung liegt beim Thema Datev-Import das Problem bei den meisten Steuerberatern darin, dass sich dort niemand “mit den komischen IT-Schnittstellen” auskennt. Um es beim Buchen (beim STB) einfach zu haben, sind dort im Kontenplan in der Regel alle denkbaren Automatismen eingestellt. Diese lassen sich natürlich deaktivieren (automatische Steuerbuchung etc.), ist aber nicht “normal”. Wenn Du sicher gehen willst, würde ich die empfehlen (wenn Du es nicht ohnehin schon hast) Dir eine Client-Version vom Kanzleirechnungswesen zu besorgen und die Daten einzuspielen. Ich setzte eine kompatible Software ein und habe schon alle Buchungen (incl. Steuer, Kundenstamm, Lieferantenstamm etc.) automatisch von ERPNext übernommen. Allerdings mit einer eigenen Schnittstelle. Da ich auch schon Datev-Buchungsschnittstellen aus anderen (größeren) ERP-Systemen gebaut habe, die einwandfrei funktioniert haben, hat Datev m.E. kein grundsätzliches Problem. Und zu Deiner Frage - DEINE Buchungen haben immer Vorrang, sonst bräuchtest Du ja gar nicht zu buchen. Mal von GOB, GDPdU etc. Voraussetzungen ganz abgesehen. Und zu den “anderen ERP-Systemen” : auch Schnittstellen zu SAP, MAS, Infor etc. habe ich nach “Deiner Denke” schon gebaut (aus anderen Fibu und ERP-Systemen) die - mal von normalen Startschwierigkeiten abgesehen - einwandfrei laufen/gelaufen sind.
Also - so negativ wie es zu sein scheint - ist es m.E. nicht. Man muss sich nur mal kümmern und ein paar Testläufe machen.
Grüße Fred
[quote=“FHammer, post:98, topic:44127”]
Um es beim Buchen (beim STB) einfach zu haben, sind dort im Kontenplan in der Regel alle denkbaren Automatismen eingestellt.
danke Fred,
das macht ja dann doch Hoffnung, ja so war das wohl auch das mit den Steuerberaterautomatismen. Schon ein wenig zum Kopfschütteln, denn das geht ja schief wenn man sich nicht strikt an den DATEV Kontenplan gehalten hat den die Automatismen unterstellen - wozu es keine Vorschrift gibt und in dem man im Buchungsprogramm auch abweichen kann. Aber das ist kein ERPNext Problem oder das von Rafaels Implementierung sondern ein “Problem im größeren Kontext des Zusammenwirkens via atev Schnittstelle - zuviele Freiheiten beidseitig, zuwenige harte Vorschriften”. Es war bei Kivitendo LX-Office nicht besser.
Aber grundsätzlich machen Deine Erfahrungen dann doch Mut, es scheint ja machbar,
danke
Otmar
War nur ein Seufzer der Ernüchterung. Ich weiß noch nicht wirklich wie wir selbst damit umgehen werden. Immerhin Fred meinte, es sei in der Praxis dann doch nicht so dramatisch viele Probleme lägen auch an empfängerseitigen Einstellungen … und ließen sich dort beheben.
So schnell kommen wir nicht an diese Baustelle, wir werden sehen.
