aus Kassensystem Daten für Buchführungen exportieren

[#1]

Hallo Community,

bucht von euch jemand eine Tankstelle und spielt sich die Daten aus der Kasse für die Buchhaltung ein?

Laut Auskunft des Hersteller/Supports gibt es keine Datev-Schnittstelle und auch eine Ausgabe als csv o.ä. ist nicht möglich.

*verzweifelt um Hilfe ruf'*

[#2]

dann würde ich mal sagen, dass entweder die kasse zu alt ist, wenn man sowas nicht programmieren kann und dann wäre ohnhin eine GoBD-Fähigkeit in Frage gestellt, oder es geht wirklich nicht und man muss fleissig per Hand buchen.

[#3]

Sehe ich genauso. Ich bezweifle, dass eine solche Kasse für eine Tankstelle (noch) zugelassen ist.

[#4]

Das ist ein PC-Kassensystem/Wawi wo sämtliche Daten zusammenlaufen und dann irgendwo in den tiefen des Programmes verschwinden

einen gdpdu-Export gibt es - wird aber in einem für mich nicht lesbaren Format ausgegeben

[#5]

dann MUSS es eigentlich möglich sein, sowas zu programmieren. da will nur einer nicht oder kann nicht.

[#6]

Ein GDPdU-Export muss grundsätzlich lesbar sein. Das gibt der Beschreibungsstandard so vor.

Mit meinem Programm "Drehscheibe Buchungssätze" kann ich nahezu alle GDPdU-Buchungsdaten einlesen und für DATEV bereitstellen.

Die Buchungsdaten können dabei ggf. "umkontiert" werden (einzelne Konten oder kompletter KR-Wechsel). Sind keine Konten vorhanden, sondern nur Buchungstexte, kann nach diesen kontiert werden.

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

[#7]

Das kann, muss aber nicht funktionieren. Der GDPdU-Standard ist nicht als Transportformat zwischen Systemen konzipiert.

[#8]

Sehr geehrter Herr Kinzler,

ich versichere Ihnen: es funktioniert!

"Der GDPdU-Standard ist nicht als Transportformat zwischen Systemen konzipiert."

Aber selbstverständlich: auch das System der Finanzverwaltung liest ja die Daten und verarbeitet sie weiter.

Wenn die Daten gemäß GDPdU-Beschreibungsstandard aufgebaut sind und die Finanzverwaltung mit den Daten arbeiten kann (wovon ja eigentlich auszugehen ist), kann meine "Drehscheibe Buchungssätze" diese Daten als Buchungsdaten lesen und weiter verarbeiten.

Wir können gerne gemeinsam in einer Fernwartung einen von Ihnen vorgeschlagenen Fall durcharbeiten.

Carl-Rainer Zeiss

[#9]

Das kann, muss aber nicht funktionieren. Der GDPdU-Standard ist nicht als Transportformat zwischen Systemen konzipiert.

Interessant. Ich hab das immer benutzt um Kanzleidaten auf Prüferlaptops zu transferieren

Bezügl. gdpdu-Import für Fibu-Zwecke kann man mal beim Mitbewerb schauen, bspw. Lexware hat sowas (glaub ich).

johanna

einen gdpdu-Export gibt es - wird aber in einem für mich nicht lesbaren Format ausgegeben

D.h.? gdpdu-Exporte sind bloße Text-/(xml-)Dateien. Kann man mit jedem Editor/Browser/Textverarbeitung öffnen/weiterverabeiten.

[#10]

>>Das kann, muss aber nicht funktionieren. Der GDPdU-Standard ist nicht als  

    Transportformat zwischen Systemen konzipiert.

Interessant. Ich hab das immer benutzt um Kanzleidaten auf Prüferlaptops zu transferieren

Es dient zur Weitergabe der Daten an die Finanzverwaltung zwecks Prüfung und nicht zum Übertrag an ein anderes Buchhaltungssystem.

Es sind nicht unbedingt alle Informationen und Daten enthalten, es kann auch vorkommen, das Sachverhalte mehrfach in verscheidenen Kontexten enthalten sind, z.B. Buchungen sowohl auf Debitor/Kreditor wie auch auf Forderungen/Verbindlichkeiten, zusätzliche Statistikbuchungen usw.

>>einen gdpdu-Export gibt es - wird aber in einem für mich nicht lesbaren Format

    ausgegeben

D.h.? gdpdu-Exporte sind bloße Text-/(xml-)Dateien. Kann man mit jedem Editor/Browser/Textverarbeitung öffnen/weiterverabeiten.

Oft handelt es sich um Textdateien, dass muss aber nicht zwingend so sein. Der GDPdU-Standard schreibt kein Umfang/Format vor, sondern legt fest, wie das verwendete Format und Zuordung zu den Feldern/Funktionen zu Beschreiben ist.

[#11]

Zwingend wäre auch eine index.xml. In dieser wird das Format und die Bedeutung beschrieben.

[#12]

Sehr geehrter Herr Kinzler,

"Es dient zur Weitergabe der Daten an die Finanzverwaltung zwecks Prüfung und nicht zum Übertrag an ein anderes Buchhaltungssystem."

Stimmt. Aber man kann die Daten durchaus dafür verwenden. Die Finanzverwaltung macht im Prinzip doch auch nichts anderes damit.

Es sind nicht unbedingt alle Informationen und Daten enthalten,"

Stimmt. Es kann sein, dass Kostenstelleninformationen nicht ausgegeben werden. Alle für eine Betriebsprüfung erforderlichen Informationen müssen aber vorhanden sein und können entsprechend für die Erzeugung von Buchungssätzen herangezogen werden.

"es kann auch vorkommen, das Sachverhalte mehrfach in verschiedenen Kontexten enthalten sind, z.B. Buchungen sowohl auf Debitor/Kreditor wie auch auf Forderungen/Verbindlichkeiten"

Stimmt. In diesem Fall handelt es sich um Journaldaten, die meine "Drehscheibe Buchungssätze" auch behandeln kann.

"zusätzliche Statistikbuchungen"

Die stören nicht, wenn sie als Buchungssätze verarbeitet werden.

"Oft handelt es sich um Textdateien, das muss aber nicht zwingend so sein. Der GDPdU-Standard schreibt kein Umfang/Format vor, sondern legt fest, wie das verwendete Format und Zuordung zu den Feldern/Funktionen zu Beschreiben ist."

Stimmt nicht. Der Beschreibungsstandard sieht vor, dass es sich zwingend um Text-, Excel-, Access-, dBase-, Lotus123-Dateien handeln muss.

In aller Regel werden Textdateien ausgegeben, aber auch die anderen Formate lassen sich verarbeiten. Nur zur Info: Csv-Dateien sind auch Textdateien.

"Zwingend wäre auch eine index.xml. In dieser wird das Format und die Bedeutung beschrieben."

Stimmt. Diese Datei wird immer bei GDPdU-Daten benötigt.

Siehe auch https://audicon.net/themen/beschreibungsstandard

Sehr geehrte Frau Köpke,

"*.oio, *.osp, *.oej, *.oan, *.ost, *.oiv"

Diese Dateiendungen sind mir unbekannt. Es kann sich aber trotzdem um Textdateien handeln. Gibt es auch eine Datei index.xml? Dann müsste sich aus dieser Datei ersehen lassen, welche Daten die anderen Dateien beinhalten.

Carl-Rainer Zeiss

[#13]

"*.oio, *.osp, *.oej, *.oan, *.ost, *.oiv"

Diese Dateiendungen sind mir unbekannt. Es kann sich aber trotzdem um Textdateien handeln. Gibt es auch eine Datei index.xml? Dann müsste sich aus dieser Datei ersehen lassen, welche Daten die anderen Dateien beinhalten.

Carl-Rainer Zeiss

ost kommt anscheinend aus outlook....https://www.google.de/search?q=ost+file+format&oq=ost+&aqs=chrome.0.69i59j69i57j0l4.2721j0j7&sourceid=chrome&ie=UTF-8

u. über den rest freut sich wahrscheinlich der prüfer (nicht lesbar / zuschätzung gebongt / rest der woche ist frei )

https://www.google.de/search?q=oio+file+format&oq=oio+file+format&aqs=chrome..69i57.6601j0j7&sourceid=chrome&ie=UTF-8
https://www.google.de/search?q=obj+file+format&oq=oej+file+fo&aqs=chrome.1.69i57j0l5.3008j0j7&sourceid=chrome&ie=UTF-8
https://www.google.de/search?q=oan+file+format&oq=oan+file+format&aqs=chrome..69i57.2998j0j7&sourceid=chrome&ie=UTF-8
https://www.google.de/search?q=oiv+file+format&oq=oiv+file+format&aqs=chrome.0.69i59.2991j0j7&sourceid=chrome&ie=UTF-8  

den hersteller der anwendung sollten sie nochmal kontaktieren!