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.
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.
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 ?
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.
[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.
ein Interessent hat nach DATEV Online Connect gefragt. Wenn man der Doku von DATEV glauben darf ist das einfach nur die online Anbindung der DATEV csv/xml über eine API. Gibt es hierzu bereits Erfahrungen in der Runde?
DATEV Online Connect ermöglicht es, Rechnungen im PDF- und/oder XML-Format an DATEV Unternehmen online zu übertragen. Andere Daten, beispielsweise Zahlungen, können auf diesem Wege nicht übertragen werden. Für einen vollständigen Export an DATEV Rechnungswesen wird der Export per CSV-Datei empfohlen.
Von den verwendeten Technologien her wäre eine Integration sicher möglich.
Eine von ERPNext erzeugt e-Rechnung, die auf irgendeinem Weg an DATEV Unternehmen online übertragen wird, hätte wahrscheinlich den gleichen Effekt, ja.
Ich möchte nochmal die Idee eines temporären Gegenkontos aufgreifen. Das Gegenkonto hat in den Hauptbucheinträgen von ERPNext derzeit keine richtige Bedeutung und kann auch mal zwei Konten oder den Namen des Kunden enthalten. Daher wird es aktuell “erraten”, was natürlich nicht sonderlich elegant ist und zu Fehlern führen kann. Daher wäre mein Vorschlag, den Export so anzupassen, dass immer ein temporäres Verrechnungskonto als Gegenkonto (z.B. 9999) verwendet wird. Damit sind die Buchungssätze auf jeden Fall korrekt. Unser Steuerberater sieht in diesem Ansatz jedoch folgende Schwierigkeiten:
Die Buchführung kann in DATEV nicht mehr so gut nachvollzogen werden, da bspw. für jeden Kreditor über das Verrechnungskontos geprüft werden muss, wo die Buchung im Aufwand gelandet ist.
Einige Automatikfunktionen von DATEV funktionieren nicht mehr richtig und erhöhen den Aufwand des Steuerberaters (bspw. die Umbuchung der fälligen Umsatzsteuer).
Hallo @rmeyer,
das ist meiner Meinung nach der (einzig) richtige Weg.
Wie ich oben in einem älteren Post geschrieben hatte, mag das Buchungsschema von DATEV mit Konto → Gegenkonto zwar in den meisten Betrieben funktionieren, bei denen nur ein Mehrwertsteuersatz Anwendung findet und die Kunden hauptsächlich per Banküberweisung bezahlen, allerdings haben wir als Hotel- und Restaurantbetrieb schon immer Schwierigkeiten mit diesem Buchungsschema.
Sobald mehrere Mehrwertsteuersätze angewendet werden und die Kunden mehr als eine Zahlart pro Rechnung verwenden, funktioniert das von DATEV vorgesehene Schema nicht mehr. Aus diesem Grund verwendet auch proprietäre Software in der Hotellerie und Gastronomie immer ein Verrechnungs-/Transferkonto für den Export der Buchungssätze an DATEV (z. B. beim PMS Protel unter dem Punkt „Transferkonto“). Das ist also in bestimmten Branchen nichts ungewöhnliches, sondern ganz normal.
Unser Steuerberater bekommt schon seit Monaten die Buchungssätze so. Anfangs hatte er sich auch beschwert, aber es gibt halt in unserer Branche keinen anderen Weg und so wäre ERPNext dann auch ein Stück universeller einsetzbar.
Moin,
da es im develop nun die Möglichkeit des temporary against account gibt, würde ich das gerne ausprobieren. Gibt es eine kurze Anleitung, wie eine Buchung abläuft?
Nach https://wiki.erpnext.org/display/GER/18.+Debitoren-+und+Kreditorenbuchhaltung und folgende kann ich die Schritte soweit nachvollziehen.
Nach Rücksprache mit meinem Buchhalter wäre das eine Möglichkeit das operativ einzusetzen.
Von meinem Buchhalter kam der Hinweis, dass in der Kontobeschriftung.csv die Kontonummern in der ersten Spalte nicht in “” stehen dürfen, damit diese importiert werden können. Die Beispiel-Dateien von DATEV sind auch ohne.
Ein weiterer Hinweis ist, dass im Buchungsstapel.csv in Spalte 14 Buchungstext, der Text, wie von DATEV beschrieben, auf 60 Zeichen beschränkt ist. In der .csv-Datei ist ein Zeilenumbruch mitten im Feld. Auch hier gibt es Probleme beim Import. Das Entfernen des Zeilenumbruchs brachte noch keine Besserung, erst die Kürzung auf weniger Zeichen ließ einen Import zu.
Ist es möglich das Feld auf 40 oder 50 Zeichen zu begrenzen und ohne Zeilenumbruch auszugeben?
Glückwunsch zum neuen Unternehmen und viel Erfolg!
Ein Weg, einen neuen Buchungssatz zu erzeugen, ist ein Journal Entry. Du kannst aber auch einfach eine neue Rechnung schreiben und buchen. Dadurch wird ein Buchungssatz mit Erlösen, Umsatzsteuer und Forderungen erzeugt.
Die Dateien wurden vom DATEV-Prüfprogramm als korrekt befunden und unser Steuerberater importiert diese jeden Monat ohne Probleme. Die Darstellung als String ist beispielsweise für Kontonummern mit führenden Nullen sinnvoll.
Der Buchungstext ist bereits auf 60 Zeichen beschränkt, Zeilenumbrüche werden jedoch derzeit nicht ersetzt.
Falls Ihr Unterstützung bei der Einrichtung benötigt oder eine Weiterentwicklung des DATEV-Exports finanzieren wollt, kannst du dich gerne bei mir melden (raffael@alyf.de).
Freds Variante könnte ebenfalls über eine entsprechende Einstellung ermöglicht werden.
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 ?