GDPdU und andere Importe über Konto 9090?

[#1]

Ein immer wieder gestellter Wunsch ist ja die Möglichkeit GDPdU-Daten in Rechnungswesen einspielen zu können. Dies ist derzeit nicht möglich, auch manche andere Systeme sind nicht oder nicht richtig einspielbar.

Soweit ich dies verstanden habe liegt dies daran, dass die jeweiligen Buchungslogik nicht mit der von DATEV kompatibel ist, da DATEV einen kompletten Buchungssatz erzeugt, an dem beispielsweise auch die Steuerbuchungen hängen, während bei GDPdU beispielsweise jede Buchung "für sich" im "luftleeren" Raum alleine steht.

Wäre es möglich, die Daten unter Verwendung des Kontos 9090 einspielen zu lassen? Dass konsequent jede Buchung entsprechend zerlegt und gegen 9090 eingebucht wird? Dies wäre zwar sicherlich keine ideale Lösung, aber meiner Meinung nach immer noch ein Fortschritt gegenüber "geht nicht gibt's nicht". Man hätte immerhin beispielsweise Buchungstexte vorliegen und hätte auch einen Bestand mit dem man arbeiten kann.

Mit freundlichen Grüßen,

Florian Mayer

[#2]

Auch dann wäre der Import nicht grundsätzlich garantiert, da das GDPdU-Format nicht dafür entwickelt wurde.

Eine und die selbe Buchung ist u.U. auch mehrfach vorhanden ( Kreditor/Debitor und Verbindlichkeit/Forderung; Statistikbuchungen). Es kann funktionieren, muss aber nicht.

[#3]

Hallo Herr Mayer,

das wird aus unterschiedlichen Gründen nicht möglich sein. Herr Kinzler nannte schon den Grund der doppelten Buchungen.

GDPdU dient eigentlich nur zum Visualieren der Daten. Ein Mensch kann diese problemlos deuten und interpretieren. Der Aufbau einer GDPdU Datei beschreibt lediglich den Aufbau der XML Daten, welche wiederum in Inhalt der mit Buchungen gefüllten csv Dateien somit darstellen können. Nun ist dieser Aufbau aber völlig frei. Das Belegfeld 1 kann benannt werden mit

Belegfeld 1

Beleg 1

Beleg1

Beleg

B1

usw.

Das kann kein System interpretieren. Gerne bringen viele Systeme den Buchungssatz auch noch ein 2tes mal mit rein. Direkt hinter dem ersten, mit negiertem Betrag und/oder Soll/Haben Konten getauscht. So kommt entweder jede Buchung 2mal ins System oder hebt sich auf. Addison z.B. bringen eine Bruttobuchung, dann die Nettobuchung und dann noch die Steuerbuchung. Dazu noch die Buchungen gegen 1400 und 1600.

Das kurz zur Problematik. Daher kann es keine Standard-Schnittstelle zum Import geben.

Gerne kann ich SIe aber bei Ihren Kunden unterstützen. Ich habe bereits mehrere Kundenanfrage für derartige Schnittstellen gehabt und kann z.B. die Addison Daten problemlos ins Datev Format überführen.

Bei Fragen können SIe mich gerne kontaktieren.

Viele Grüße

HeeroSoft

Michael Heering

info@heero.de

www.heerosoft.de

Tel: 040-61189175

[#4]

"Der Aufbau einer GDPdU Datei beschreibt lediglich den Aufbau der XML Daten, welche wiederum in Inhalt der mit Buchungen gefüllten csv Dateien somit darstellen können. Nun ist dieser Aufbau aber völlig frei."

Danke Herr Heering für Ihre Ausführung! Aber: wäre es denn z.B. möglich "standardisierte" GdPdU-Formate für Daten aus "bekannten" Programme zu erstellen?

Z.B. das Format (GdPdU) für Auswertungen aus Sage nach DATEV (ich weiss, Sage kann auch Postversand, aber ich wollte nur mal einen Hersteller nennen).

Zumindest ist Ihre von mir zitierte Aussage mal plausibler als "geht nicht"....

Es gibt nämlich immer mal (leider auch schon mal öfter) die Aussage "klar, GdPdU ist das kleinste Problem"....Aber dann fangen ja die Probleme an.

Leider lassen sich die GdPdU-Daten zwar mittels ACL einlesen, aber dann nicht mehr als Buchführungsdaten exportieren.....

Danke also nochmal für Ihre Aussage und weitere Antwort..

MfG

A. Hofmeister

[#5]

Hallo Herr Hofmeister,

mit Einschränkungen: ja.

Das Problem ist nicht nur der große Pflegeaufwand, sondern überhaupt erstmal die Entwicklung des Algorhythmus, die Daten zu interpretieren. Das wird sich Datev nicht antun wollen. Es ist zu aufwendig. Daher fülle ich als kleiner Programmierer diese Lücke.

Zu Sage: Das geht z.B. gar nicht. Sage gibt die Buchungen nicht nur doppelt aus. Irgendwann in dem ganzen Wust aus Daten kommen die Buchungen einfach noch ein drittes und manchmal auch viertes Mal vor. Ich habe das selber auch noch nicht lösen können. Ich verwende hier eine Ausgabe des Kontodrucks, um die Daten zu ttransportieren.

VG

Michael Heering

[#6]

Ok. Vielen Dank aber trotzdem für Ihre Antwort.

Wie gesagt, Sage ist nur ein Name. Nicht das Problem; da Sage Postversanddaten ausgeben kann.

Es gibt aber hin und wieder schon mal System, wo GdPdU zumindest ein "Kompromiss" ist. Meist der einzige.

Zumindest gibt es Leute, die man dann "in petto" hätte. Ist müßig, ich weiß!

VG

A. Hofmeister

[#7]

Mal eine Frage, der GDPdU-Export ist doch der, mit welchem das Finanzamt die Dateien einspielt oder ist dies eine spezielle Unterart? Meine Vermutung war, dass die Finanzverwaltung sich kein Bein ausgerissen haben wird bei der Programmierung Ihrer Software und stattdessen auf stark standarisierte Importdateien besteht. Und was die Finanzverwaltung einspielen kann sollte auch bei DATEV zumindest erfassbar sein, so war zumindest mein Gedanke.

[#8]

Klar,  Herr Mayer, sie haben Recht in Ihrer Annahme. Das Analysieren der Daten führt die Finanzverwaltung mit der Software von IDEA durch, deren Prüfroutinen selbst aber nicht für den "allgemeinen Markt" verfügbar sind.

DATEV arbeitet mit ACL, das ist quasi das Konkurrenzprodukt aus anderem Haus (bzw. DATEV entwickelt das Produkt nun selbst).

Für Kontenanalysen bzw. Auswertungen können Sie die Daten im GdPdU-Format auch in DATEV-ACL einlesen.  Und entsprechende,  wie die Finanzverwaltung,  Analysen (ACL=Idea) unternehmen.

Sie werden daraus nur keine Buchhaltungsdaten zum Erstellen von JA etc. bekommen. Oder vielleicht doch und es liest jemand mit und hat das Konzept in der Schublade?

[#9]

IDEA basiert m.W. auch auf ACL. Der Import in Rewe kann/muss aber nicht funktionieren, die Gründe wurden ja schon ausgeführt.

[#10]

Zumindest eine weiter Meinung in die selbe Richtung!

[#11]

Mit meinem Programm "Drehscheibe Buchungssätze" ist es möglich, die GDPdU-Daten nahezu aller Fibu-Systeme einzulesen. Die Buchungsdaten können dabei ggf. "umkontiert" werden (einzelne Konten oder kompletter KR-Wechsel). Nach dem Import können die Buchungsdaten geprüft und ggf. überarbeitet werden (Excel-Tabelle). Am Ende können die Buchungsdaten im DATEV-Format ausgegeben werden.

Ggf. liegen die GDPdU-Daten als Journal vor. Auch diese Daten können verwertet werden.

Carl-Rainer Zeiss

www.crz.de

[#12]

Guten Abend Herr Zeiss,

liegen Ihnen also verwertbare Ergebnisse vor? Kann man Ihr Produkt testen?

MfG

A. Hofmeister

[#13]

Hallo Herr Hofmeister,

wie ich zu Angang mitgeteilt habe, kann ich mit meinen Schnittstellen unterstützen und viele Formate verarbeiten.

VG HeeroSoft - Michael Heering

[#14]

Guten Morgen Herr Hofmeister,

es arbeiten ca. 100 Kanzleien mit dem Programm, die ganz unterschiedliche Daten verarbeiten, natürlich auch GDPdU-Daten mit Journalsätzen

Ich habe z.B. vor 4 Wochen im Auftrag einer Kanzlei GDPdU-Daten (Journaldaten) aus Diamant eingelesen (ca. 170,000 Datensätze), mit Kontenrahmen-Wechsel von SKR03 nach SKR04, mit Kontoerweiterung von 4 nach 8 Stellen, mit Gegenkonto 9090 und diese Daten dann im DATEV-Format wieder ausgegeben.

Das Programm lässt sich durchaus testen. Sinnvoll ist aber auf jeden Fall eine Präsentation bzw. Kurzeinweisung über Fernwartung, denn die Buchungs-Drehscheibe muss für jedes GDPdU-Datenformat einmalig eingerichtet werden.

Carl-Rainer Zeiss

[#15]

Guten Morgen Herr Zeiss, vielen Dank für Ihre Antwort.

Ich werde mich über die PN mit Ihnen in Verbindung setzen..

MfG

A. Hofmeister

[#16]

Hallo Herr Hofmeister,

Sie können unsere Programme sehr gerne vergleichen.

Ich kann die gleichen Funktionalitäten bestätigen.

VG HeeroSoft - Michael Heering

[#17]

Sehr Herr Heering,

Ihre Aussagen vom 8.08.2016 waren:

"Das kann kein System interpretieren. Gerne bringen viele Systeme den Buchungssatz auch noch ein 2tes mal mit rein. Direkt hinter dem ersten, mit negiertem Betrag und/oder Soll/Haben Konten getauscht. So kommt entweder jede Buchung 2mal ins System oder hebt sich auf. Addison z.B. bringen eine Bruttobuchung, dann die Nettobuchung und dann noch die Steuerbuchung. Dazu noch die Buchungen gegen 1400 und 1600.

Das kurz zur Problematik. Daher kann es keine Standard-Schnittstelle zum Import geben."

"Zu Sage: Das geht z.B. gar nicht. Sage gibt die Buchungen nicht nur doppelt aus. Irgendwann in dem ganzen Wust aus Daten kommen die Buchungen einfach noch ein drittes und manchmal auch viertes Mal vor. Ich habe das selber auch noch nicht lösen können."

Meine Aussage war:

Meine Buchungs-Drehscheibe kann es standardmäßig.

Ich glaube nicht, dass man das als "die gleichen Funktionalitäten" bezeichnen kann ...

Sehr geehrter Herr Hofmeister,

Sie wollten sich mit mir in Verbindung setzen ...

Carl-Rainer Zeiss

[#18]

Auch jetzt zum Ende 2024 hat sich die Problematik noch nicht geändert:

Herr Zeiss leistet perfekte Unterstützung für DATEV-konforme Importe aus wiederkehrenden Quellen ohne DATEV-Schnittstelle. Die Quellen können Daten aus GOBD-Archiven sein, individuelle EXCEL-Listen, Kassenarchive. Herr Zeiss unterstützt hier gerne indem er die Quelle sichtet und richtet die gewünschte Übersetzung für die Buchhaltung mit ein. Im Anschluss kann eigenständig der weitere Import und Export nach DATEV umgesetzt werden. Gerade wenn Kassendaten übernommen werden sollen, wäre es möglich je Kassenhersteller bzw. Archiv-Lösung einen Import zu stricken, den man dann abgesehen von Kontenrahmen und individuellen Abweichungen in der Buchhaltung immer weiter verwenden kann.

Klares Fazit: Wer oft GOBD-Archive als Datenquelle erhält um diese auch in der Finanzbuchhaltung zu als Quelle für die Buchhaltung nutzen will, sollte sich mit Hr. Zeiss unterhalten.

Wir sind sehr zufrieden mit der Unterstützung durch Herrn Zeiss! Er hat uns bereits bei vielen Projekten begleitet!