ich habe in den letzten Wochen an einem Python Skript gearbeitet, welches meine jVerein Buchungen in ein DATEV lesbares Format konvertiert (https://developer.datev.de/portal/de/dtvf/formate). Ich arbeite dafür direkt auf meiner MySQL Datenbank (man kann es natürlich relativ simpel auf H2 erweitern). Das Skript nutzt meine eigene "Zweck" Syntax:
Der Name einer Buchung ist die Belegnummer.
Für den korrekten Export von Buchungen mit Steuersatz müssen diese eine Splitbuchung sein
Des Weiteren verwende ich für den Zweck einer Buchung des Steuerbetrages immer den gleichen Zweck wie für die Buchung vom Nettobetrag + einen beliebigen Postfix (bspw. - 7% VSt.). Das ist wichtig, damit ich einen korrekte Zuordnung zwischen den Buchungen hinkriege, und mich nicht nur auf einen passenden Betrag verlassen muss. Der Export generiert dann eine Bruttobuchung mit BU Schlüssel.
Falls der Steuersatz einer Buchung für das Belegdatum nicht mehr gültig ist, wird dem Export ein Leistungsdatum hinzugefügt + eine zusätzliche Ausgleichsbuchung mit einem Kreditoren / Debitoren Konto angelegt (anders habe ich es mit Lexware nicht zum Laufen bekommen).
Die Konten (Girokonto, Barkasse, etc.) müssen in der Liste KONTO_MAPPING auf entsprechende Konten im SKR gemapped sein.
Die Liste JVEREIN_STEUER_KONTEN wird verwendet um Steuerbuchungen zu identifizieren (ich habe in der Datei example_custom_defines.py Beispiele angelegt).
Da die Zukunft von jVerein aktuell ein bisschen offen ist, und ich keinerlei Feedback zu meinen offenen PRs bekommen habe, wollte ich diesmal keine Integration in jVerein vornehmen, sondern erst einmal nur eine quick&dirty Lösung haben. Ich hoffe dennoch, dass einige von euch das Skript ggf. wiederverwenden (können). Ihr findet das Skript auf Github: https://github.com/VinRud/DatevExport
ich habe ähnliches gemacht - eher mit Perl (aber bezogen auf die PDF-Summen - will das aber eher in jverein implementieren für alle)
Du hast geschrieben, daß deine PRs nicht geprüft werden. Leider weiß ich auch nicht wie die PRs in der bisherigen Orga geprüft werden oder ob es sogar eine One-Man-Show von Heiner war. Egal - kannst Du nicht auch zur openjverein.github.io Orga stoßen und Deine Requests erneut pullen?
Wir müssen hier mit einem harten Fork leider weitermachen und ich habe Deinen PR gesehen. Finde ihn interessant - also warum nicht zusätzlich implementieren. Wir müssen allerdings auf Philipp warten, weil die PRs in der neuen Orga sich auch keiner traut zu reviewen und solange das so ist, muß er das tun - alternativ ...die Rechte ausweiten. Etwas Geduld brauchen wir noch ... aber der Anfang ist ja gemacht.
Ich finde es auch etwas schade, dass die PRs im JVerein-Fork unter https://github.com/openjverein/jverein/pulls derzeit so zögerlich übernommen werden. Es sind ja wirklich sinnvolle und/oder nötige Änderungen dabei. Wenn sich keiner so richtig an die Reviews traut, würde ich das folgende Vorgehen empfehlen: Die PRs nicht direkt in den master-Branch mergen sondern erstmal in einen Beta/Nightly-Branch. Aus dem kann dann automatisch tagesaktuell ein Nightly-Build erzeugt werden, das von mutigen Usern getestet werden kann. Wenn nach ein paar Wochen keine Fehlermeldungen von Usern kommen, kann es in den Master-Branch übernommen werden. Dann müssen die Reviews nicht mehr so umfangreich sein und User, die nicht programmieren können, haben trotzdem die Möglichkeit, mitzuhelfen.
ja das wird auch so kommen müssen - sonst gehts nicht weiter. Das macht momentan keinen Spaß. Es wird noch etwas dauern, bis wir hier vorwärts kommen - weil ich selber erstmal noch mit Github übe, um das sauber abzubilden. Meinen PRs habe ich testsweise mal für mich in ein Release gepackt. Die Anpassungen sind fehlerfrei umgesetzt. Wenn jemand Tips hat, wie man das zügig in Github bauen könnte (automatisierte Nightlys sofern commits vorhanden waren - immer her damit).
Das geht mit "Github Actions". Für Jameica, HIbiscus & Co. brauche ich das nicht, weil ich einen eigenen Server betreibe und das dort ausführen lasse. Wenn nur Github verfügbar ist, würde ich es mit den "Actions" dort machen. Unter https://docs.github.com/en/actions/auto ... a-with-ant ist beschrieben, wie man Ant-Scripts da ausführen kann. Unter https://github.com/willuhn/jameica/pull/37 und https://github.com/willuhn/hibiscus/pull/76 finden sich zwei Pull-Requests für Jameica und Hibiscus, die diese Funktionalität dort nachrüsten sollen. Daran kann man sich orientieren. Im Wesentlichen muss man im Ordner ".github/workflows" nur eine YML-Datei anlegen, in der die auszuführenden Build-Instruktionen stehen. Unter https://docs.github.com/en/actions/quickstart findet sich ein Quickstart-Tutorial.
