GdPDU-Schnittstelle, welche Daten sind anzuliefern

[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.

[arnof]

@Captnemo: 7500,- EUR +MwSt

ich habe nun alles was mit Kasse zu tun hat um 100,- EUR vom Preis erhöht für die Finanzierung.

@Neumann:@jaenicke:3 Pils zu 2€ = 6 E.

Verdichtung ist unzulässig, das ist richtig, es ist aber erst nach den BON unzulässig, vor dem BON kann man verdichten. Es geht um die unveränderliche Datenvorhaltung zwischen BON und späterer GoBD Ausgabe, das muss übereinstimmen.

@all: ich war erst ende August auf einer Tagung in der Hauptstadt. Hier waren auch die obersten Steuerprüfer aus NRW (Bundesweit wohl für Kassen die Ansprechpartner für andere Bundesländer).

Fazit: Es gibt keine Vorgaben, Unveränderlichkeit von Daten heist nicht unveränderbar (es muss halt dokumentiert sein was geändert wurde); Änderung für 2020 keiner weiss was, jeder Wünscht sich was .....

[Neumann]

Hallo Arnulf,

der Meinung war ich ja auch. Sobald der Bon gedruckt oder gespeichert ist, nichts mehr an den Daten ändern. Der besagte Prüfer sieht das allerdings anders. Keine Eingabe darf korrigiert oder verändert werden, auch schon wenn nur eine Bestellung eingegeben wird.
Ich tendiere jetzt dazu, alles parallel auf einen Secumem-Stick zu schreiben, z.B. als CSV-Datei. Die kann dann mit den verarbeiteten Daten verglichen werden.

Der Prüfer hat sich auch in tagelanger Arbeit durch unsere Datenbank gekämpft und vieles mokiert, wie schon angesprochen die nicht lückenlosen Buchnummern oder die doppelte Speicherung von Daten in Tabellen und Views, wobei die Daten in den Views "Überhaupt nicht sortiert waren", sein Kommentar dazu.

Übrigens wurden alle Gastronomiebetriebe die von diesem Prüfer dort geprüft wurden zu Nachzahlungen verdonnert, egal von welchem Hersteller das Kassensystem war, alle wurden als manipulierbar beschuldigt.

[arnof]

Zitat von Neumann:

Hallo Arnulf,

der Meinung war ich ja auch. Sobald der Bon gedruckt oder gespeichert ist, nichts mehr an den Daten ändern. Der besagte Prüfer sieht das allerdings anders. Keine Eingabe darf korrigiert oder verändert werden, auch schon wenn nur eine Bestellung eingegeben wird.
Ich tendiere jetzt dazu, alles parallel auf einen Secumem-Stick zu schreiben, z.B. als CSV-Datei. Die kann dann mit den verarbeiteten Daten verglichen werden.

Der Prüfer hat sich auch in tagelanger Arbeit durch unsere Datenbank gekämpft und vieles mokiert, wie schon angesprochen die nicht lückenlosen Buchnummern oder die doppelte Speicherung von Daten in Tabellen und Views, wobei die Daten in den Views "Überhaupt nicht sortiert waren", sein Kommentar dazu.

Übrigens wurden alle Gastronomiebetriebe die von diesem Prüfer dort geprüft wurden zu Nachzahlungen verdonnert, egal von welchem Hersteller das Kassensystem war, alle wurden als manipulierbar beschuldigt.

Prüfer sind auch oft Ahnungslos,der hat halt gelesen "Verdichtung ist verboten" und sonst ....

Hier muss man sich halt rumärgern.

Ich hatte auch die GoDB via AutoInc Felder verknüpft ausgegeben und der gute Prüfer hat das nicht gerafft und kam mit einer Lückenprüfung, das dort nichts fehlen darf ... Es darf aber keine Bonnummer fehlen, hier musste ich den Kunden auch mehrmals schriftlich zur Seite stehen!
Es ging halt bis zu seinem Vorgesetzten, dann war alles OK!

Man lernt immer dazu, ich habe deshalb beim GOBD Export die Autoinc Felder raus genommen und via Nummern verknüpft, damit ich mir diese Diskussionen ersparen kann.

[bernau]

Zitat von arnof:

Prüfer sind auch oft Ahnungslos,der hat halt gelesen "Verdichtung ist verboten" und sonst ....

Hier muss man sich halt rumärgern.

Leider. Und man hat nicht wirklich eine Chance als Programmierer etwas dagegen zu machen. Kannst den ja theoretisch nicht verklagen. Er prüft ja nicht dich sondern deinen Kunden. Der Kunde klagt lieber nicht sondern nimmt das kleinste übel. Und du hast das schlechte ansehen.

Laut Prüfer müssen sämtliche Änderungen in den Stammdaten protokolliert werden. Das ist noch verständlich, wenn die Preise der Produkte alle 2-3 Monate geändert werden. Was aber, wenn Goldpreise die sich stündlich ändern, in der Kasse kassiert werden sollen? Soll der Preis tatsächlich Protokolliert werden? Eigentlich ist doch nur der Preis relevant, zu dem ein Produkt verkauft wurde. Erzähl das mal einem Steuerprüfer.

[jaenicke]

Zitat von hanvas:

Weil Du (gerade aber nicht nur in der Gastronomie) oft vor dem Bezahlen gar nicht weist ob überhaupt eine Verdichtung vorliegt.

Doch. Der Bediener hat zum Beispiel 3 mal ein einzelnes Pils gebucht. Dann sind das auch erst einmal drei Transaktionen.
Dass man diese als 3 Pils anzeigt, ist klar, aber das heißt doch nicht, dass man dafür die Datensätze zu einem Datensatz verdichten muss.
Und was ist, wenn ich zwei Schnitzel buche, in der Küche drucke und dann eins wieder storniere? Unterschlägt du dann den Storno und speicherst nur das eine Schnitzel verdichtet ab?

Zitat von bernau:

Was aber, wenn Goldpreise die sich stündlich ändern, in der Kasse kassiert werden sollen? Soll der Preis tatsächlich Protokolliert werden?

Wir protokollieren tatsächlich jede einzelne Änderung. Interessieren sollten unbenutzte Zwischenergebnisse allerdings wirklich nicht...

[mm1256]

Hallo,

mittlerweile habe ich ja nichts mehr mit Gastrokasse zu tun, aber früher zu DOS-Zeiten hatte ich mal eine programmiert. Die gibt es zwar heute unter Windows auch noch, aber ich entwickle sie nicht mehr.

Da war es so, und ist es auch heute noch, dass alle aktuellen Buchungen an den Tischen einzeln in einer separaten Datenbank gespeichert wurden. Erst beim Bezahlen wurde verdichtet. Anders bekommt man meiner Meinung nach die Probleme nicht so gut in den Griff. Stichworte Netzwerkfähigkeit, Übersicht offene Tische, Umbuchen einer oder mehrerer Gäste auf einen anderen Tisch, Kellnerwechsel, Schichtwechsel, Stornierungen, Fehlbestellungen, Notizen zu den einzelnen Bestellungen (Kartoffelsalat anstatt Pommes zum Schnitzel, das Steak medium...usw) und allem was sonst nicht zwingend im Journal stehen muss.

Wenn dann beim Bezahlen die einzelnen Positionen verdichtet in das Journal geschrieben werden, dann ist das - um zurück zum Thema zu kommen - meiner Meinung nach steuerrechtlich in Ordnung.

[bernau]

Zitat von jaenicke:

Wir protokollieren tatsächlich jede einzelne Änderung. Interessieren sollten unbenutzte Zwischenergebnisse allerdings wirklich nicht...

Änderungen im Artikelstamm müssen Protokolliert werden, egal ob die Produkte verkauft werden. Es ist egal, ob die Preise alle 5 min. geändert werden oder alle 5 Tage.

Du müsstes den Preis vom Glas "Alt-Bier", welches in Köln nicht getrunken wird, erst zwei drei mal senken, bevor es das erste mal verkauft wird. Die 2-3 Preissenkungen wirst du doch in der Gastrokasse protokollieren. Oder? Wo ist der Unterschied zum Goldpreis, welcher dann nicht protokolliert werden soll? (Ausser dass Gold tatsächlich mehr Wert ist als Alt-Bier)

[hanvas]

Zitat von jaenicke:

Zitat von hanvas:

Weil Du (gerade aber nicht nur in der Gastronomie) oft vor dem Bezahlen gar nicht weist ob überhaupt eine Verdichtung vorliegt.

Doch. Der Bediener hat zum Beispiel 3 mal ein einzelnes Pils gebucht. Dann sind das auch erst einmal drei Transaktionen.

Ob es sich wirklich um 3 einzelne Bier handelt (3 verschiedene Gäste, jeweils ein Bier, 3 Transaktionen) oder um 3 Bier die auf einmal gekauft werden (ein Gast spendiert sich und seinen Freunden jeweils ein Bier - eine Transaktion) wird oft aber erst zum Zeitpunkt des Bezahlens klar.

Zitat:

Dass man diese als 3 Pils anzeigt, ist klar, aber das heißt doch nicht, dass man dafür die Datensätze zu einem Datensatz verdichten muss.

Natürlich muss man die 3 Einzelpositionen bei 3 unterschiedlichen Bestellungen nicht zusammenfassen, aber es ist ebenso inkorrekt - auch wenn der Prüfer möglicherweise glücklicher ist - den Einzelvorgang in 3 einzelne Vorgänge aufzusplitten. Beides kann vorkommen und beides kann korrekt sein.

cu Ha-Jö