DSFinV_K_2.0 Export

[noisy_master]

Hallo ihr Lieben,

nachdem ich denn mit meiner TSE ein wenig weitergekommen bin habe ich heute mal ein paar Fragen zum DSFinV_K Export:
Das Dokument definiert ja die Export Dateien für die Finanzprüfer. Ich habe aber bisher einige Sachen nicht gefunden/ggf. übersehen:
- Welches ist das Trennzeichen zwischen den Feldern?
- Sollen die Felder gequoted sein? Wenn ja: " oder '?
- Sollen die Dateien die Feldnamen als Header enthalten?
- in cashpointclosing.csv ist ja als erstes Feld die Taxonomieversion(string[5]) anzugeben. Was gehört da rein? V_2.0?

So ein langes Dokument und so viele Unklarheiten.....

Danke schon mal wieder im Voraus!

[Frickler]

Wenn ich den CSV-Export zugrunde lege, den das PHP-Script aus der DFKA-Taxonomie (die die Grundlage der DSFinV-K darstellt) erzeugt, dann ergibt sich folgendes:
- Trennzeichen Semikolon ( ; )
- Felder nicht gequotet
- Erste Zeile Überschriften
- Zeilentrenner \r\n (Windows-Format), d.h. #13#10 in Delphi

Aus der Doku der DFKA-Taxonomie:

Cash_point_closing/taxonomy_version
Feldtyp: string
Feldlänge: 5
Kurzbeschreibung: Die für den erstellten Kassenabschluss verwendete
Kassentaxonomie-Version im Format „^[0-9]+(\\.[0-9]{1,2})?$“.

[noisy_master]

Zitat:

Zitat von Frickler (Beitrag 1450916)

Wenn ich den CSV-Export zugrunde lege, den das PHP-Script aus der DFKA-Taxonomie (die die Grundlage der DSFinV-K darstellt) erzeugt, dann ergibt sich folgendes:

Aus der Doku der DFKA-Taxonomie:

Cash_point_closing/taxonomy_version
Feldtyp: string
Feldlänge: 5
Kurzbeschreibung: Die für den erstellten Kassenabschluss verwendete
Kassentaxonomie-Version im Format „^[0-9]+(\\.[0-9]{1,2})?$“.

Ist schon richtig. Das habe ich auch gesehen. Da ich aber ehrlich gesagt nicht so gut in RegEx Ausdrücken bin: Was heisst das im Klartext? 2.0?
Gibt es das php-script irgendwo zum freien Download?

[Incocnito]

Ich hab mal auf
https://regex101.com/
geschaut.
Das macht aber mehr Sinn, wenn man den doppelten Schräger weglässt:
^[0-9]+(\.[0-9]{1,2})?$
... Dann wäre es tatsächlich ein Euro-Betrag mit maximal 1 Punkt
und maximal 2 Nach-Punkt-Stellen
Also "23", "2.3", "1234.12" oder "0.22" ... der Reguläre Ausdruck scheint
"12." zu verhindern, aber nicht "12.0" oder "12.00" ... wie man
es von Currency-Werten im Alltagsgebrauch auch kennt.

LG Incocnito

[Frickler]

Zitat:

Zitat von noisy_master (Beitrag 1450938)

Gibt es das php-script irgendwo zum freien Download?

Nee leider nicht. Das war bei der ersten Version der DFKA Taxonomie dabei, die jetzt nicht mehr verfügbar ist. Nach Angabe der DFKA arbeiten sie gerade an einer neuen Version des Scriptes. Wird man dann vermutlich unter https://dfka.net/taxonomie bestellen können.

[hhcm]

DFKA JSON Denglisch => Finanzamt alles eingedeutscht CSV.

Das ist auch der Witz des Jahrhunderts. Braucht es später dann einen Webserver beim Kassenbetreiber um das gewünschte Format erzeugen zu können?

[Rollo62]

Zitat:

Zitat von hhcm (Beitrag 1451078)

DFKA JSON Denglisch => Finanzamt alles eingedeutscht CSV.

Das ist auch der Witz des Jahrhunderts. Braucht es später dann einen Webserver beim Kassenbetreiber um das gewünschte Format erzeugen zu können?

<OT>
Kassensicherungsverordnung = Versteckte Subvention für Kassenhersteller = Kampfansage an Mittelstand und KMU

Schade das Deutscland Weltmeister darin ist sich selbst abzubauen ...
</OT>

[jaenicke]

Zitat:

Zitat von Rollo62 (Beitrag 1451081)

Kassensicherungsverordnung = Versteckte Subvention für Kassenhersteller = Kampfansage an Mittelstand und KMU

Schade das Deutscland Weltmeister darin ist sich selbst abzubauen ...

Leider gibt es eben genug schwarze Schafe, die man damit versucht zu erreichen. Die ehrlichen Betreiber müssen unnötigerweise darunter leiden, das stimmt. Dafür wird der unlautere Wettbewerb durch die Steuersünder auch kleiner, insofern ist es auch ein gewisser Vorteil für die ehrlichen Betreiber.

Allerdings sind die Preise hierzulande ja noch moderat. In Griechenland lagen z.B. alleine die Fiskalboxen schon im vierstelligen Bereich...

Wer mit den Preisen, die nun durch die Fiskalisierung entstehen, echte Probleme hat, hat allerdings noch andere Probleme. Trotzdem trifft es die kleineren Firmen natürlich stärker. Aber es gibt ja auch schon ziemlich billige Kassensysteme. Und wer auf einem Wartungsvertrag ist und einigermaßen aktuelle Hardware hat oder ein Mietsystem nutzt, muss bei den meisten Herstellern auch vermutlich lediglich die TSE und die Dienstleistung für die Aktualisierung bezahlen.

[Rollo62]

Schon richtig,
aber wann gab es denn die letzte Kassensystem-Update Verordnung, war das nicht 2015 ?

Haben Kassensysteme jetzt ein Verfallsdatum von 5 Jahren, müssen sich Kunden jetzt alle paar Jahre die Hardware neu kaufen oder teuer updaten ?
Ich fasse es nicht.

Wenn Du mich fragst sitzen da eine ganze Menge Sesselpupser an der Erstellung solcher Gesetze und Verordnungen.
Es wäre sicher mal eine Verordnung für das Verfassen von Verordnungen fällig :stupid:

[Neumann]

Rechnet man mal großzügig TSE + Aktualisierung 300 € so ist das doch viel besser als bei einer Steuerprüfung 10-20 TSd nachzuzahlen. Viele unserer Kunden sind mit den jetzigen Regelungen überfordert und machen formelle Fehler oder verstehen nicht was ins Kassenbuch gehört (nicht etwa Steuerhinterziehung) die sie dann angekreidet bekommen.

Auch Datenverluste ohne Sicherung kommen immer wieder vor.

Das könnte sich bessern, hoffe ich zumindest.

[Rollo62]

Meines Wissens haben die neuen Kassen bis zu 5K gekostet, und die TSE Updates können auch bis zu 2K kosten, wenn man mehrere Kassen kann das schon etwas ins Geld gehen.

[jaenicke]

Zitat:

Zitat von Rollo62 (Beitrag 1451103)

Meines Wissens haben die neuen Kassen bis zu 5K gekostet, und die TSE Updates können auch bis zu 2K kosten, wenn man mehrere Kassen kann das schon etwas ins Geld gehen.

Eine ganz normale neue Touchscreenkasse kostet nicht einmal die Hälfte und die TSE kostet inkl. Drucker vielleicht 500€. Wer bei uns das TSE Update für den Preis pro Kasse bestellt, dem könnten wir sie für den Preis bildlich gesprochen noch vergolden... ;-)

Dazu kommt, dass neue Kassenhardware ja nur erforderlich ist, wenn die schon einige Jahre alt ist. Für einigermaßen aktuelle Hardware sollte ja ein Softwareupdate reichen. Insofern ist der Neukauf ja bei solchen älteren Systemen nicht nur wegen der Fiskalisierung irgendwann sinnvoll. Es geht ja auch um Sicherheit, Zuverlässigkeit und Stabilität...

[Neumann]

Möchte das Thema nochmal aufgreifen.

Ich habe noch nirgends ein Beispiel von kompletten JSON-Dateien gesehen; auch Beispiele für die CSV-Dateien nicht.

Kann man die irgendwo finden?

[hhcm]

Zitat:

Zitat von Neumann (Beitrag 1451568)

Ich habe noch nirgends ein Beispiel von kompletten JSON-Dateien gesehen; auch Beispiele für die CSV-Dateien nicht.

Wozu auch? Wenn man keine Mitgliedsgebühren bezahlt wird man halt im dunkeln stehen gelassen. Jeder kocht jetzt seine eigene Suppe.

Es wird hunderte fehlerhafte Exporte geben, da bin ich sicher. Bei der RKSV gab es viele Beispiele und sogar ein Testprogramm für die Exporte.
Ich habe letztens bei Xing in einer Kassen-Gruppe gelesen, dass es schwierig wäre ein Testprogramm zur Verfügung zu stellen.
In Österreich hats funktioniert.

[Neumann]

Also ich habe die Mitgliedsgebühren bezahlt, trotzdem ist dort sowas nicht zu finden.

Werde den Verein mal fragen. Von einem Testprogramm habe ich auch schon mal was gehört aber nie gesehen.

Das Finanzamt kann sowieso nur nur die CSV-Daten verarbeiten, die sollten nicht so schwer sein.

[Incocnito]

Zitat:

Zitat von Neumann (Beitrag 1451578)

...Das Finanzamt kann sowieso nur nur die CSV-Daten verarbeiten, die sollten nicht so schwer sein.

Ich befürchte diesen Satz werde ich irgendwann an meine Tür kleben, als Running Gag.
Diese optimistische Jugend, herrlich! ;-)

MfG Incocnito

[hhcm]

Zitat:

Zitat von Neumann (Beitrag 1451578)

Also ich habe die Mitgliedsgebühren bezahlt, trotzdem ist dort sowas nicht zu finden.

Werde den Verein mal fragen. Von einem Testprogramm habe ich auch schon mal was gehört aber nie gesehen.

Das Finanzamt kann sowieso nur nur die CSV-Daten verarbeiten, die sollten nicht so schwer sein.

Trotz Gebühren keinen Mehrwert? Hui, das ist Hart.
Ja, Das Finanzamt kann/will/wird nur die CSV Daten verarbeiten. Daher verstehe ich das JSON->CSV über PHP gefrickel nicht.

[Neumann]

Warum über PHP?
CSV-Dateien lassen sich doch auch so erzeugen. Ich werde auch nicht die JSON als Basis für die CSV nehmen,
sondern von den Ausgangsdaten beide erzeugen.

[hhcm]

Zitat:

Zitat von Neumann (Beitrag 1451586)

Warum über PHP?

Weil der DFKA ein PHP Script zur Konvertierung bereitstellen wird? Bzw. es war sogar schonmal in einem Paket dabei.

https://dfka.net/dfka-taxonomie-kassendaten-version2-0/

Wozu überhaupt JSON wenn doch CSV gefordert wird?

[Frickler]

Zitat:

Zitat von hhcm (Beitrag 1451588)

Wozu überhaupt JSON wenn doch CSV gefordert wird?

Es gibt wohl Cloud-Archivierungslösungen, die das JSON-Format verlangen.

[hhcm]

Zitat:

Zitat von Frickler (Beitrag 1451592)

Es gibt wohl Cloud-Archivierungslösungen, die das JSON-Format verlangen.

Das mag sein. Aber wozu?

ACHTUNG FREIE MEINUNGSÄUßERUNG

Es wird keine Cloudlösung geben, die den Vorstellungen des BSI entspricht, auch wenn das BSI es selbst sagt.

Wenn selbst große Anbieter wie Facebook, Sony und Microsoft Datenleaks und Sicherheitslücken zugeben müssen, welcher Anbieter darf denn dann Fiskus Daten sicher Speichen?

[Daniel]

Naja, die "Deutsche Fiskal" ist ein Partner der Bundesdruckerei, bietet eine Cloud-Lösung an und befindet sich mit im Zertifizierungs-Verfahren. Sobald das erfolgreich abgeschlossen ist - und es zeichnet sich ab, dass dies früher oder später passieren wird - haben wir mindestens eine Cloud-Lösung für Kassendaten.

[hhcm]

A-Trust ist mit seiner Cloud-Lösung auch im Zertifizierungs-Verfahren. Das ändert nichts an meiner Meinung.
Abgesehen davon, dass nicht immer ein Internetzugang zur Verfügung steht, ziehe ich eine Offline Lösung vor.
Ich glaube das wird langsam etwas Offtopic 8-)

Ich dachte vielleicht kennt jemand den Grund JSON Dateien erstellen zu wollen, wenn die Finanz doch CSV möchte.

[jaenicke]

Zitat:

Zitat von hhcm (Beitrag 1451607)

Ich dachte vielleicht kennt jemand den Grund JSON Dateien erstellen zu wollen, wenn die Finanz doch CSV möchte.

Weil die DFKA die Taxonomie erst einmal in einem sinnvollen Format erstellt hatte. Da in der Finanzverwaltung alles cutting-edge Technologie ist :lol:, musste das ganze dann eben auf CSV übersetzt werden.

Zitat:

Zitat von Daniel (Beitrag 1451597)

Naja, die "Deutsche Fiskal" ist ein Partner der Bundesdruckerei, bietet eine Cloud-Lösung an und befindet sich mit im Zertifizierungs-Verfahren. Sobald das erfolgreich abgeschlossen ist - und es zeichnet sich ab, dass dies früher oder später passieren wird - haben wir mindestens eine Cloud-Lösung für Kassendaten.

Davon gehen die Cloudanbieter aus. Allerdings ist die Aussage von vielen (inkl. Epson, die da aber natürlich auch parteiisch sind), dass die Zertifizierung nach EAL4 augmented nur mit Hardware möglich ist. Es wird wohl eine "angemessene Übergangsfrist" mit einer light Variante geben, die lediglich eine Zertifizierung nach EAL2 vorsieht. Die sollte für eine Cloudlösung technisch kein Problem sein.

Das Problem ist eben was danach passiert. Wird die Variante nach EAL2 zum Normalzustand erklärt, die Sicherheitsstufe also gesenkt? Oder fallen alle durchs Raster, die nur EAL2 können? Man weiß es nicht...

Insofern priorisieren wir aktuell die reinen Hardwarelösungen oder die mit einer Hardware-TSE kombinierbaren Cloud-Lösungen.

[Frickler]

Zitat:

Zitat von hhcm (Beitrag 1451595)

Zitat:

Zitat von Frickler (Beitrag 1451592)

Es gibt wohl Cloud-Archivierungslösungen, die das JSON-Format verlangen.

Das mag sein. Aber wozu?

ACHTUNG FREIE MEINUNGSÄUßERUNG

Es wird keine Cloudlösung geben, die den Vorstellungen des BSI entspricht, auch wenn das BSI es selbst sagt.

Ich hätte "Archivierung" stärker hervorheben sollen... ich habe nicht auf eine Cloud-TSE abgehoben! Ich meine tatsächlich nur eine Archivierung, d.h. TSE in Hardware, aber jeden Abend lädt die Kasse den Z-Bericht im Taxonomie-Format auf den Cloudserver des Anbieters hoch.