GdPDU-Schnittstelle, welche Daten sind anzuliefern

[jaenicke]

Zitat von Lemmy:

dann besserst Du nach

Du hast dann aber nicht mehr die Unveränderbarkeit der Daten vollumfänglich gewährleistet, wenn die GdPDU-Daten nacherzeugt werden. Wir speichern täglich die Pakete und sichern diese jeweils ab. Bei der Zusammenstellung des Pakets für einen Zeitraum kann man dann genau sehen, ob die Daten jeweils noch unverändert waren.

Natürlich kann man so etwas immer mit einigem Aufwand umgehen, aber das erfordert dann schon einiges Fachwissen und kriminelle Energie. Deshalb ist es da nicht so einfach einen Anfangsverdacht zu begründen.
Und das ist für uns das Hauptanliegen: Die Daten in einem Format vorzulegen, die es dem Prüfer einfach macht und Manipulationen so unwahrscheinlich macht, dass normalerweise keine tiefere Prüfung sinnvoll erscheint.
Bisher hat das auch in diesem Format so problemlos geklappt.

[Lemmy]

Zitat von jaenicke:

Zitat von Lemmy:

dann besserst Du nach

Du hast dann aber nicht mehr die Unveränderbarkeit der Daten vollumfänglich gewährleistet, wenn die GdPDU-Daten nacherzeugt werden.

die Prüfdaten fürs FA werden erzeugt wenn sie gebraucht werden. Weshalb sollte hier die (inhaltliche) Unveränderbarkeit der Daten nicht gewährleistet sein?

[Neumann]

Für uns gab es, nachdem etliche Kunden in den letzten Jahren ohne wesentliche Probleme durch die Steuerprüfung gekommen sind, jetzt einen Fall (Gastronomiebetrieb) der fast schiefgegangen wäre.

Der Prüfer monierte folgendes:

Wir würden Daten unzulässig verdichten durch z.B. wie in folgendem Beispiel : Ein Gast bestellt nacheinander über den Abend 3 mal ein gleiches Getränk, wenn dann später die Rechnung gezogen wird rechnet das Programm diese 3 zusammen und schreibt auf den Bon dann eben 3 Pils zu 2€ = 6 E.
Genauso wird es dann gespeichert.

Danach, wenn der Bon gedruckt ist werden diese Daten nie wieder verändert.

Ein weiteres Problem für diesen Prüfer war, das die einzelnen Buchungen (nicht die Rechnungen / Bons, da war alles ok) keine lückenlose fortlaufende Nummerierung haben.

Unser Kunde hatte noch eine ältere Version von dem Kassenprogramm; aber die "Verdichtung" ist jetzt immer noch drin und ich werde da wohl was tun müssen.

[mm1256]

Zitat von Neumann:

Der Prüfer monierte folgendes:

Wir würden Daten unzulässig verdichten durch z.B. wie in folgendem Beispiel : Ein Gast bestellt nacheinander über den Abend 3 mal ein gleiches Getränk, wenn dann später die Rechnung gezogen wird rechnet das Programm diese 3 zusammen und schreibt auf den Bon dann eben 3 Pils zu 2€ = 6 E.
Genauso wird es dann gespeichert.

Man hat als Steuerzahler nicht nur Pflichten, sondern auch Rechte. Wer sich als Steuerzahler solche Schikanen vom Prüfer gefallen lässt, dem ist wirklich nicht mehr zu helfen. Meiner Erfahrung nach werden solche "Repressalien" von Prüfern angewandt um ein Indiz zu erhalten, ob beim Steuerzahler alles sauber gebucht wurde. In diesem Fall ist das Thema die Schwarzgastronomie. Denn, wer wirklich eine weiße Weste hat, der schickt den Prüfer in diesem Fall dahin wo er hin gehört, in die Wüste.

[Neumann]

Das wäre schön wenn man einen Prüfer in die Wüste schicken könnte.

Der Kunde kann nur vor Gericht gehen, mit ungewissem Ausgang und ev. weiteren Kosten.

[jaenicke]

Ich bin ja kein Anwalt, aber wir haben solche Fragen ja auch schon zur Genüge durch.

Zitat von Neumann:

Wir würden Daten unzulässig verdichten durch z.B. wie in folgendem Beispiel : Ein Gast bestellt nacheinander über den Abend 3 mal ein gleiches Getränk, wenn dann später die Rechnung gezogen wird rechnet das Programm diese 3 zusammen und schreibt auf den Bon dann eben 3 Pils zu 2€ = 6 E.
Genauso wird es dann gespeichert.

Das ist korrekt, das ist nicht zulässig. Jede Buchung muss so gespeichert werden wie sie eingegeben wurde. Eine Verdichtung der Daten ist nicht zulässig. Weder direkt bei der Buchung (nur Anzahl hochzählen, ...) noch beim Abschlag (alle Buchungen einzelner Artikel zusammenrechnen, ...).

Sprich dagegen besteht meiner Meinung nach vor Gericht wenig Aussicht auf Erfolg, wenn es deshalb Probleme gibt. Das sollte natürlich trotzdem ein Anwalt anschauen, da es ja vermutlich um einiges Geld geht.
Denn durch die unzulässige Speicherung werden die Daten ja nicht gleich gänzlich ungültig.

Zitat von Neumann:

Ein weiteres Problem für diesen Prüfer war, das die einzelnen Buchungen (nicht die Rechnungen / Bons, da war alles ok) keine lückenlose fortlaufende Nummerierung haben.

Das ist nicht vorgeschrieben. Nicht einmal für die Rechnungen.

Auch Lücken in Rechnungsnummern sind theoretisch kein Problem. Praktisch ist es für viele Prüfer dennoch ein Ansatzpunkt, wenn es eine fortlaufende Nummerierung gibt und dann Lücken vorhanden sind. Eigentlich ist der Schluss, dass deshalb etwas nicht korrekt ist, nicht zulässig.

[Captnemo]

Zitat von arnof:

181 „Zertifikate“ oder „Testate“ Dritter können bei der Auswahl eines Softwareproduktes dem Unternehmen als Entscheidungskriterium dienen, entfalten jedoch aus den in Rz. 179 genannten Gründen gegenüber der Finanzbehörde keine Bindungswirkung.

Ich habe ein Zertifikat von Audicon besorgt, welche Daten drin stehen hat keiner gefragt, die haben nur geprüft, ob es durch Ihren Konverter (IDEA) lief. Was der Inhalt meiner Daten war, hier gab es keinerlei Nachfrage.

Hier geht es darum möglichst schnell einige tausender zu verdienen, soll Ihnen gegönnt sein, auf dem Prospekt kommt das halt gut beim Kunden an.

Was hat das gekostet?

[jaenicke]

Zitat von Lemmy:

die Prüfdaten fürs FA werden erzeugt wenn sie gebraucht werden. Weshalb sollte hier die (inhaltliche) Unveränderbarkeit der Daten nicht gewährleistet sein?

Die Unveränderlichkeit gilt bei uns auch für die täglich beim Tagesabschluss erzeugten GdPDU Exporte. Mehr möchte ich da aber nicht ins Detail gehen.

[mm1256]

Zitat von jaenicke:

Ich bin ja kein Anwalt, aber wir haben solche Fragen ja auch schon zur Genüge durch.

Zitat von Neumann:

Wir würden Daten unzulässig verdichten durch z.B. wie in folgendem Beispiel : Ein Gast bestellt nacheinander über den Abend 3 mal ein gleiches Getränk, wenn dann später die Rechnung gezogen wird rechnet das Programm diese 3 zusammen und schreibt auf den Bon dann eben 3 Pils zu 2€ = 6 E.
Genauso wird es dann gespeichert.

Das ist korrekt, das ist nicht zulässig. Jede Buchung muss so gespeichert werden wie sie eingegeben wurde. Eine Verdichtung der Daten ist nicht zulässig. Weder direkt bei der Buchung (nur Anzahl hochzählen, ...) noch beim Abschlag (alle Buchungen einzelner Artikel zusammenrechnen, ...).

Könntest du mir bitteschön mal die entsprechende Stelle im Gesetzestext bzw. einen Link darauf posten? Der Grund: Ich vermute, dass ihr da was falsch interpretiert. Wenn der Gast ein Getränk ordert und danach (am gleichen Tag und am selben Tisch) ein weiteres Getränk, dann sind dies zwar Bestandteile einer Buchung (des Bon's, den der Gast erhält) aber für sich gesehen keine eigenen Buchungssätze.

[bernau]

Zitat von arnof:

181 „Zertifikate“ oder „Testate“ Dritter können bei der Auswahl eines Softwareproduktes dem Unternehmen als Entscheidungskriterium dienen, entfalten jedoch aus den in Rz. 179 genannten Gründen gegenüber der Finanzbehörde keine Bindungswirkung.

Ich habe ein Zertifikat von Audicon besorgt, welche Daten drin stehen hat keiner gefragt, die haben nur geprüft, ob es durch Ihren Konverter (IDEA) lief. Was der Inhalt meiner Daten war, hier gab es keinerlei Nachfrage.

Hier geht es darum möglichst schnell einige tausender zu verdienen, soll Ihnen gegönnt sein, auf dem Prospekt kommt das halt gut beim Kunden an.

Ich habe mir auch mal die Audicon-Sache angeschaut. Wie du beschrieben hast, wird nur geprüft, ob die Daten eingelesen werden können. Das ist bei einer Steuerprüfung zwar ein Pluspunkt. Aber es gibt noch viel mehr Sachen, die als Minuspunkt verwendet werden können, die von Audicon nicht geprüft werden. Ich habe schon einige Steuerprüfungen hinter mir. alles gut. Aber es gibt auch Steuerprüfer, die werden kleinlich. Ein Kunde wurde von mir geprüft. Alle Buchungsdaten waren vorhanden und sind korrekt. Das wurde mir vom Steuerprüfer bestätigt.

ABER: Er fragte dann nach den Programmier-Protokollen. Dachte zuerst, daß er ein Protokoll zu allen "Programmänderungen", die ich gemacht habe, haben möchte. Ne, ne. Er meine damit die Stammdaten der Kasse. Also z.B. "Wann wurde ein Mitarbeiter angelegt, wann wurde dieser geändert. Welche Berechtigungen wurden dem Mitarbeiter zugefügt oder entzogen. Wurden Formulare geändert. Welches Formular wurde geändert. Was wurde am Formular geändert. Etc.

Alle Tätigkeiten der Mitarbeiter sind natürlich in den Einzelaufzeichnungen protokolliert. Man sieht also, ob jemand stornieren durfte oder nicht. Das hat dem Steuerrprüfer aber nicht genügt. Er wollte wissen, wann die Änderung des Mitarbeiters durchgeführt wurde. Konnte ich auf den Tag nicht liefern. Also Berechtigung zur Schätzung.

Auf so etwas wird man m.w.n. auch bei Audicon nicht hingewiesen. (Korrigiert mich, wenn es nicht so ist.) Was nützt mir dann so eine Zertifizierung. Wenn ein Steuerprüfer schätzen will, dann wird er irgend etwas aus dem Hut zaubern. Und sei es noch so eine winzige Kleinigkeit.