Moin Elise,
ja sehr gerne. Ich schicke Ihnen gleich eine DM.
VG
Guten Morgen,
auch wenn ich das Geschäftsmodell (oder einen Teil) von @heerosoft attackiere... Aber ich hatte nun zwei Projekte Addison2DATEV.
IST:
4-stellige Sachkonten in Addison
6 bzw. 7-stellige Personenkonten in Addison
Mitnahme der verlinkten Belege aus Addison nach DATEV (Unternehmen online)
Ich habe zur Lösung Gemini herangezogen um ein PowerShell-Skript zu erstellen. Bzw. mehrere Skripte (die könnte man auch in ein Skript zusammenfassen).
Ablauf:
1. Export aus Addison (GPDdU inkl. Belegbilder)
2. Export aus Addison als DATEV-Format (monatweise! Insbesondere, da abweichende WJ und Addison in den CSV-Header immer das komplette WJ schreibt.)
3. Das PS-Skript ergänzt
- die fehlenden Stellen bei den 4-stelligen Sachkonten
- die Beleglinks werden in das Feld "Beleginfo - Inhalt 1" geschrieben bzw. umgetragen, falls vorhanden. Hierbei werden die Dateinamen eingetragen. Das Matching kann entweder anhand des Belegfeld1 oder anderen Informationen erfolgen. Da muss man im Projekt nach Möglichkeiten suchen. Kombinationen aus Personenkonto+Belegfeld1 wäre von der Fehleranfälligkeit am besten.
- Ich habe bei der Gelegenheit auch eine Abfrage der Zielberater- und Mandantennummer eingebaut, kann bei Addison mit angegeben werden, wird aber je nach Buchhalter auch gern "ignoriert". Zudem kann auch die Buchungsperiode mit abgefragt werden um den Header vollends zu korrigieren.
Die neuen Buchungsstapel (DATEV-Format / csv) liegen nun in einem Verzeichnis für das "ISWL Beleg2Buchung".
ISWL_B2B kann nun die Buchungsstapel einlesen und die im Beleginfo-Feld Informationen nutzen um DATEV-konforme Beleglinks zu generieren und in die Buchungen einzutragen.
Zudem werden von ISWL_B2B wahlweise eine ZIP der verlinkten Belegbilder erstellt. Dieses kann mit Belegtransfer hochgeladen werden. Wahlweise deshalb, weil auch ISWL_B2B auch den Buchungsdatenservice unterstützt.
ISWL_B2B schreibt die Buchungen dann auch direkt in die Stapelverarbeitung von Rechnungswesen. Buchungen verarbeiten und (fast) fertig.
Fast fertig, da Addison (wie auch andere Buchhaltungssysteme) sich nicht an den DATEV-SKR und seinen Einschränkungen hält. Oder Benutzer in Addison auch gern Konten nutzen, die DATEV anderen Zwecken zuführen möchte. Mal von Buchungsschlüssel abgesehen, die von Addison exportiert wurden aber je nach Konto keinen Sinn ergeben...
Ich hatte in beiden Projekten pro Buchungsperiode mitunter mit 20-25 Buchungsstapeln zu tun. Die Skripte haben hier zuverlässig funktioniert.
Ich poste die Skripte nicht. Jedes Projekt ist anders. Da muss der einzelne sich genau überlegen, wie was wo und womit. Ich wollte hier nur mal eine Gedankenanregung posten, da sie in meinen beiden Fällen sehr gut funktioniert haben und die KI-Systeme hier auch Laien (mich) bei der Erstellung von Skripten sehr gut unterstützt. Nur sollte jeder Nutzer hier genau wissen, wie das Ziel auszusehen hat und das Zielsystem mit seinen Vorgaben genau kennen.
Die Skripte waren mit Tests (extra Rechner) nach 60-90 Minuten fertig zum Einsatz. Nach dem ersten Projekt mussten nur kleinere Anpassungen (Belegbild-Matching, Sachkontenlänge) angepasst werden.
PowerShell war meine Wahl, da auf dem Zielsystem DATEV und somit Windows immer zur Verfügung steht. Hier fallen keine weiteren Kosten an und man kann sich darauf verlassen, das die PowerShell keine Abweichungen zum Testsystem hat.
Beste Grüße
Christian Ockenfels
Hallo @chrisocki ,
vielen Dank für die ausführliche Lösung.
Ggf ist DATEV ISWL Rechnungswesen-Konverter eine Lösung ohne den eigenen Aufwand zu gehen?
Hallo @chrisocki ,
es gibt viele Möglichkeiten. In der Regel ist es aber so, dass Zeitdruck ist. Es möchte sich keiner unbedingt derart mit dem Thema auseinandersetzen.
VG
@Andreas_Thaler schrieb:Hallo @chrisocki ,
vielen Dank für die ausführliche Lösung.
Ggf ist DATEV ISWL Rechnungswesen-Konverter eine Lösung ohne den eigenen Aufwand zu gehen?
Hatte ich mir angesehen. Aber allein die Anpassung der 4-stelligen Sachkonten habe ich dort auf die Schnelle nicht gefunden... Das Tool ist mächtig und entsprechend komplex.
Da war der Zeitdruck auch zu hoch um sich damit genauer auseinander zusetzen. Dann lieber die bekannten Dinge.
Beste Grüße
Christian Ockenfels
@heerosoft schrieb:Hallo @chrisocki ,
es gibt viele Möglichkeiten. In der Regel ist es aber so, dass Zeitdruck ist. Es möchte sich keiner unbedingt derart mit dem Thema auseinandersetzen.
VG
Zum Glück war der Zeitdruck noch nicht so hoch. Aber ich war ehrlich gesagt auch kurz davor bei Ihnen anzurufen. Letzen Endes war es ein Gedankenblitz in einer stillen Minute am Wochenende gepaart mit dem sportlichen Ehrgeiz. Dann schnell noch getestet und für gut befunden...
Beste Grüße
Christian Ockenfels
Freut mich, wenn so gut geklappt hat. Die Tücken stecken meistens im Detail. Falsch verwendetet Steuerschlüssel, Konten, die in DATEV nicht bebucht werden dürfen oder fehlende Beleglinks. Da habe ich halt viel Arbeit reingesteckt.
... wir haben auch gerade ein Mandat von einer Steuerkanzlei übernommen, die mit Addison arbeitet.
Zum Zweck der Datenübernahme haben wir ein Konvolut aus Buchungsstapeln erhalten.
Auf den ersten Blick sehen die Buchungsstapel (optisch) gut aus.
Ob auch buchhalterisch alles 'in Butter' ist, wird sich noch zeigen.
Was mich allerdings irritiert hat, ist, dass alle Buchungsstapel (... und es ist eine mittlere 2-stellige Anzahl an Buchungsstapeln pro Wirtschaftsjahr ...) mit "DTVF_Buchungsstapel ..........csv" bezeichnet sind.
Ich war immer der Meinung, dass "Fremdbuchhaltungen" die Datei-Bezeichnungen "EXTF.............csv" verwenden (müssen) und dass nur Original-Datev-Programme exklusiv das 'sprechende' Kürzel "DTVF" in der Dateibezeichnung verwenden.
Frage:
kann Addison ebenfalls Buchungsstapel mit den Dateibezeichnungen "DTVF.....csv" erstellen oder hatte vielleicht schon eine Datev-Software bzw. ein Datev-Tool 'seine Finger im Spiel' ?
Apropos:
das erwähnte Benutzerhandbuch "ADDISON - Buchungsexport Datev" (Stand November 2022) scheint mE auf den ersten Bick nicht mehr "State Of The Art" zu sein. Dort wird immer noch von Postversandformat gesprochen, das laut meinem Gedächtnis so etwa seit 2017 von DATEV REWE nicht mehr unterstützt wird.
... oder anders gesagt: Postversandformat ist in REWE nicht mehr importierbar
Tatsächlich heissen die BS DTVF. Kann man so machen, soll man lt. Datev nicht. Ist aber kein Problem. Sie werden dort massive Probleme mit Buchungsschlüsseln bekommen. Bei dieser Ausgabe werden keine Belegbilder transportiert. Diese werden nur über die GDPdU ausgegeben.
Danke für die hilfreiche Antwort, Herr Heering (@heerosoft)
Inzwischen habe ich die Buchungsstapel von mehreren Wirtschaftsjahren importiert und verarbeitet ...
... mit einigen Fehlern und mit vielen Hinweisen in den Primanoten ... was auch zu erwarten war ...
... ja, die Belege wurden nicht mitgeliefert
Mir ist allerdings nicht klar, wie man mit dem Export/Import von GDPdU-Daten (inkl. der Belege) an die Einzelbuchungssätze bzw. an die Primanoten inkl. der Belegverknüpfungen kommt.
Vermutlich geht das nur mit (Ihren oder anderen) speziellen Tools, oder ?
Mit Datev-Bordmitteln ist mir jedenfalls kein Weg bekannt.
@vogtsburger schrieb:
Mir ist allerdings nicht klar, wie man mit dem Export/Import von GDPdU-Daten (inkl. der Belege) an die Einzelbuchungssätze bzw. an die Primanoten inkl. der Belegverknüpfungen kommt.
Vermutlich geht das nur mit (Ihren oder anderen) speziellen Tools, oder ?
Mit Datev-Bordmitteln ist mir jedenfalls kein Weg bekannt.
1. Export der Buchungen aus Addison für DATEV
2. Export der GDPdU-Buchungen inkl. Belege (hier muss ein extra Export-Profil definiert werden)
3. Zusammenführung mit "DATEV ISWL Beleg2Buchung". Hier sind ggf. Vorarbeiten notwendig (siehe meinen Post vor ein paar Tagen)
Beste Grüße
Christian Ockenfels
DATEV erwartet eine Belegverknüpfung sowohl im Buchungssatz als auch bei den Belegen selber. Daher ist es sehr komplex. Ich habe da etwa zwei Jahre dran entwickelt. Mal wurden Belege nicht erkannt, dann waren welche doppelt usw.
@chrisocki schrieb:[...]
1. Export der Buchungen aus Addison für DATEV
2. Export der GDPdU-Buchungen inkl. Belege (hier muss ein extra Export-Profil definiert werden)
3. Zusammenführung mit "DATEV ISWL Beleg2Buchung". Hier sind ggf. Vorarbeiten notwendig (siehe meinen Post vor ein paar Tagen)
[...]
... riecht nach viel, viel Arbeit ... und das für eine einmalige Datenübernahme
In meinem aktuellen Fall scheinen sich die Komplikationen in Grenzen zu halten ...
... also gehe ich den Sankt-Jakobs-Weg (zu Fuß) und hoffe, dass ich unterwegs nicht abbrechen, zusammenbrechen oder mich erbrechen muss 😅
(Nachtrag)
@chrisocki , die Idee, 'Datenmaterial' per KI und per Powershell-Script in einen datev-kompatiblen Buchungsstapel zu konvertieren, motiviert mich jetzt auch, das zu versuchen, allerdings mit deutlich abgeschwächtem Schwierigkeitsgrad.
Ich will mal versuchen, das was ich zur Zeit monatlich und manuell konvertiere, zukünftig möglichst per ki-generiertem Script zu automatisieren, nämlich unvollständig kontierte Kassenberichte in fix-und-fertige Datev-Buchungsstapel zu konvertieren.
Ich kenne die Ergebnisse solcher Konvertierungen ja, da ich solche Buchungsstapel schon einige Male manuell erzeugt habe. Daher lässt sich das ki-generierte Script leicht testen, mit alten oder mit neuen Daten.
Falls ich dadurch eine Menge an Zeit 'gewinne', kann ich mich wieder mehr der Freizeit- und/oder der Familienplanung widmen 😅
Ich wäre da trotzdem vorsichtig.
Ich hatte letztens eine Fach-KI um eine etwas einfachere Aufgabe gebeten. Ich hatte eine PDF, die sich mit Excel und PDF 24 usw. nicht in eine Excel bzw. csv umwandeln lies. Hauptbestandteil der PDF war tatsächlich eine Tabelle.
Ich habe die KI gefragt und Sie hat mir bestätigt, dass sie das könne. Sprich sie hat mir die Tabellenwerte Zeilenweise mit Semikolontrennung der Spalten ausgegeben und ich musste das nur noch als CSV abspeichern. Das hat alles soweit funktioniert. Um das Ergebnis zu optimieren, sprich eine Lösung zu finden, wo ich zukünftig weniger nachbearbeiten muss, habe ich noch eine Weile mit der KI rumgespielt. Irgendwann hat sie dann gesagt: Ich habe dir die Zeilen 1-5 und 10-42 wunschgemäß umgestellt. Und da ist mir erst aufgefallen, dass von Anfang an die Zeilen 6-9 gefehlt haben. Wäre mir so nie aufgefallen und die Tabelle ist mit >40 Zeilen keine ganz kleine gewesen.
Als ich die KI darauf hingewiesen habe, meinte Sie nur: Stimmt. Jetzt habe ich dir alle Zeilen wunschgemäß ausgegeben.
Es gab von meiner Seite her keine Vorgaben zu irgendwelchen Einschränkungen. Die Bildqualität der PDF war auch top. Es gab keinen Grund die Zeilen weg zu lassen. Hat die KI so entschieden.
Also Vorsicht mit KI auch bei solchen Sachen. Immer eine Möglichkeit haben, das Ergebnis nachzukontrollieren.
Hallo @vogtsburger ,
für Datenübernahmen aus Vorsystemen bieten die Kolleginnen und Kollegen von ISWL folgenden kostenpflichtigen Service an: Prozessbeschreibung Datenübernahme von Rechnungswesen-Daten nach DATEV Kanzlei-Rechnungswesen
@Andreas_Thaler schrieb:Hallo @vogtsburger ,
für Datenübernahmen aus Vorsystemen bieten die Kolleginnen und Kollegen von ISWL folgenden kostenpflichtigen Service an: Prozessbeschreibung Datenübernahme von Rechnungswesen-Daten nach DATEV Kanzlei-Rechnungswesen
Danke für den Hinweis.
Ein ISWL-Consulting-Projekt 'riecht' allerdings immer ziemlich intensiv nach relativ hohen Kosten.
Bei 'gängigen' Vorsystemen, wie z.B. bei den 'üblichen Verdächtigen' bzw. bei den verbreitetsten und bekanntesten Mitbewerbern auf dem 'Markt' für Steuerkanzleien würde ich eigentlich 'standardisierte' Prozesse erwarten, bei denen sich die Datenübernahmen vergleichsweise einfach gestalten lassen, weil sich die erforderlichen Schritte bereits vielfach bewährt haben.
Die Kollegen vom Datev-Consulting haken in solchen Fällen vermutlich eine oder mehrere vorbereitete Checklisten ab und müssen eigentlich nichts Neues erfinden.
Ich könnte mir vorstellen, dass man als ambitionierter Self-Made-Installateur solche Checklisten auch selbst 'abhaken' könnte, anstatt dabei zuzusehen, wie Andere das tun.
Eine Gebühr für die Datenübernahme (mit Hilfe von fertigen Datev-Checklisten) erscheint mir als fair, aber es könnte ja auch eine feste Standard-Gebühr für eine 'Standard-Datenübernahme' sein, abhängig vom Vorsystem und von den Gegebenheiten (mit/ohne Digitale Belege, Kontenrahmen, mit/ohne Anlagevermögen etc)
@vogtsburger schrieb:Eine Gebühr für die Datenübernahme (mit Hilfe von fertigen Datev-Checklisten) erscheint mir als fair, aber es könnte ja auch eine feste Standard-Gebühr für eine 'Standard-Datenübernahme' sein, abhängig vom Vorsystem und von den Gegebenheiten (mit/ohne Digitale Belege, Kontenrahmen, mit/ohne Anlagevermögen etc)
Ja, so handhabe ich das 😉
Guten Morgen @vogtsburger ,
siehe meinen Beitrag weiter oben vom 07.04.:
Ggf ist DATEV ISWL Rechnungswesen-Konverter eine Lösung ohne den eigenen Aufwand zu gehen?
Sie haben daher die Wahlmöglichkeit die Übernahme der Daten als Comfort-Lösung einmalig durch die Kolleginnen und Kollegen durchführen zu lassen oder, den Import anhand der verfügbaren Schemata für den ISWL Rechnungswesen-Konverter selbst durch zu führen.