Ich habe im Netz noch kein Dokument gefunden, also ist eine Ableitung aus den Musterdaten erforderlich.
Teilweise sind die Daten in ERPNext noch nicht zu finden, da die Stammdaten in den DocTypen noch nicht vorgesehen sind (wie ich in meiner 1. Mail geschrieben hatte).
Eine Import-Frequenz von 1x monatlich wird m.E. nicht funktionieren. Was ist mit Zahlungseingangsverbuchung aus Bankauszügen mit OP-Ausgleich für lfd. Rechnungen oder Lastschriften, oder autom. Zahlungsausgang oder Mahnungen. Da wird an mind. wöchentlich wenn nicht täglich nichts vorbeigehen. Und wenn der Export vollautomatisch läuft spricht ja auch nichts gegen täglich.
Nachfolge die Spaltenbeschreibungen für den Kopfsatz :
A = DATEV-Format (DTVF - von DATEV erzeugt, EXTF Fremdprogramm)
B = Version des DATEV-Formats (141 bedeutet 1.41, aktuell ist 510 = 5.10; hat nichts mit der KARE-Version zu tun)
C = Datenkategorie (21 = Buchungsstapel, 67 = Buchungstextkonstanten, 16 = Debitoren/Kreditoren, 20 = Kontenbeschriftungen usw.)
D = Formatname (Buchungsstapel, Buchungstextkonstanten, Debitoren/Kreditoren, Kontenbeschriftungen usw.)
E = Formatversion (bezogen auf Formatname)
F = erzeugt am
G = importiert am
H = Herkunft (z. B. RE = wurde von KARE erzeugt)
I = exportiert von
J = importiert von
K = Beraternummer
L = Mandantennummer
M = Wirtschaftsjahresbeginn
N = Sachkontenlänge
O = Datum Beginn Buchungsstapel
P = Datum Ende Buchungsstapel
Q = Bezeichnung (Vorlaufname, z. B. Buchungsstapel)
R = Diktatkürzel
S = Buchungstyp (1 = Buchungsstapel / 2 = Jahresabschluss)
T = Rechnungslegungszweck
U = Festschreibung
V = Kontoführungs-Währungskennzeichen des Geldkontos
Die DATEV-CSV-Dateien für Buchungssätze und Stammdaten, jeweils mit Kopfzeile, gebündelt in einer ZIP-Datei sind jetzt Teil des offiziellen develop Branches. Damit wird diese Funktion in ERPNext v13 bereitstehen.
Außerdem bin ich im Gespräch mit DATEV, um einen kostenfreien Zugang zum DATEV-Entwicklerportal für die ERPNext Foundation zu erhalten. Damit können wir sicherstellen, dass DATEV unsere Datensätze einwandfrei versteht.
Zu Guter letzt, for the record, mein Vortrag zu diesem Thema auf der Konferenz in Wiesbaden (November 2019):
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.
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.
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.
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.
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?
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:
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:
In den DATEV-Einstellungen kann optional ein Verrechnungskonto hinterlegt werden. Geschieht dies, wird als Gegenkonto immer das Verrechnungskonto verwendet, andernfalls bleibt alles wie bisher.
Per (neuer) Checkbox in den DATEV-Einstellungen kann festgelegt werden, ob die Buchungssätze in DATEV festgeschrieben werden sollen.
ERPNext erstellt separate Buchungssätze für verschiedene Kostenstellen. Da die Kostenstellen aber nicht exportiert werden, sollten diese gruppiert/summiert werden.
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 :
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.
Freds Variante könnte ebenfalls über eine entsprechende Einstellung ermöglicht werden.