GdPDU-Schnittstelle, welche Daten sind anzuliefern

[waldforest]

Hallo,
ich suche nach eine Beschreibung, welche Daten (Datenfeldbeschreibung) für eine GoBD (alt GdPDU) für die Steuerprüfung zu liefern sind.

Ich habe gefunden, das mehrere Dateiformate, aber nicht was im Detail geliefert werden muss.
Hat diesbezüglich jemand bereits Erfahrungen, ggf. eine Beschreibung.
Auf die beim Finanzministerium verwiesenen Seiten kann ich diese nicht finden.

mfg

[jaenicke]

Links dazu hatte ich gerade erst in einem anderen Thread gepostet:

Zitat:

Zitat von jaenicke (Beitrag 1344939)

Ja, gibt es... da du bei der Konkurrenz bist, kann ich dir dazu nicht viel weiterhelfen, aber ich denke dieser Link sollte weiterhelfen, der ist ja kein Geheimnis:
http://audicon.net/dienstleistungen/gobd-zertifizierung

In der Liste der zertifizierten Kassenhersteller findest du auch uns:
http://audicon.net/themen/gobd-gdpdu...ssenhersteller

Diese Exporte können von den Steuerprüfern direkt in ihre Software eingelesen werden und dort direkt ausgewertet werden.

[waldforest]

Hallo,
danke, diese Seite hatte ich auch schon einmal aufgerufen, aber leider keine Feldbeschreibungen für eine Grunddatenlieferung gefunden, was muss z.B. alles aus einer Kundenrechnung geliefert werden muss, was von den Lieferantenrechnungen.

[jaenicke]

Die Beschreibung bekommst du im Rahmen der Zertifizierung.

[Lemmy]

Zitat:

Zitat von jaenicke (Beitrag 1345052)

Die Beschreibung bekommst du im Rahmen der Zertifizierung.

d.h. ein Softwarehersteller der diese Schnittstelle unterstützen muss hat 2 Optionen:
1. Entweder zahlt er dem FA / seinem Kunden die Strafen die fällig werden wenn die Software keinen Datenexport hat
2. Er zahlt einer Privatfirma jeglichen aufgerufenen Fantasiepreis (z.B. einen halben Tag Consulting für 600€ um zu erklären warum eine 15 zeilige XML nicht eingelesen werden kann (von XSD haben die zumindest letztes Jahr noch nichts gehört)) für die Information welche Felder exportiert werden müssen.

Und noch keine deutsche Firma hat dagegen Klage erhoben? Oder hat sich die Informationslage seit letztem Jahr geändert?



Nebenbei (ich bin weder Steuerprüfer, noch Anwalt,...): Bei einer Software habe ich die GoBD Schnittstelle in Absprache mit dem Eigentümer umgesetzt und dabei die für ihn relevanten Felder in eine einfache csv exportiert (d.h. insbesondere Belegnummer, Belegdatum, Empfänger, Betrag und ausgewiesene MwSt). Bei der kurz nach Einführung stattfindenden Prüfung bei einem Kunden (dem schon mit Zwangsgeld gedroht wurde - d.h. die Kommunikation zwischen Prüfer und Betriebsinhaber war schon etwas angespannt) hat der Prüfer die csv-Datei eingelesen (auch ohne XML-Infodatei) und war glücklich und zufrieden... Was nicht heißen muss, dass das beim nächsten mal genauso abläuft.

[kretabiker]

Wir haben das damals in Absprache mit einem Mitarbeiter eines Finanzamts gemacht und die relevanten Daten - in unserem Fall der Fibu-Kontenplan, die Summen- und Saldenliste und die Buchungen des Betrachtungszeitraums aus der programmeigenen Fibu - in drei csv-Dateien geschrieben. Dazu wird eine index.xml mit der (Feld-)Beschreibung der Dateien und eine .dtd-Datei geliefert. Mehrere Prüfungen hat unser Programm seitdem ohne Beanstandung (zumindest von der technischen-formalen Seite her, buchhalterische Unklarheiten sind nicht unser Problem) überstanden.

Keine Zertifizierung, kein Testat, kein Consulting war dafür notwendig.

Dem FA-Menschen war es nur wichtig, dass er anhand der Daten die Buchungsabläufe nachvollziehen kann. Fragen dazu - und die kommen immer, denn das ist deren Job - werden auf anderem Wege geklärt, da geht es vor allem um Belege und buchhalterische "Kreativität".

[waldforest]

Hallo,
danke, aber ich strebe weder eine Zertifizierung noch eine kommerzielle Weitervermarktung an.
Mich interessiert, was da wirklich abgefragt wird.
Wenn diese Anforderungen nicht öffentl. zugänglich sind, kann auch kein Steurprüfer erwarten, dass ihm seine Mindestanforderungen geliefert werden. Denn wenn ich nicht weiß was er haben will, kann ich es ihm auch nicht geben.
Nicht jeder verwaltet seine Firma über zertifizierte Anwendungen, ggf. sogar nur über Excel oder Papier.

[sh17]

Ist das evtl. die Bescheibung?

https://audicon.net/downloads/330

[jaenicke]

Richtig, das ist sie.

Dass die dort auch öffentlich zur Verfügung steht, wusste ich nicht bzw. habe ich nicht gefunden, weil sie von den anderen Seiten aus nicht verlinkt ist (gesehen habe ich das zumindest nicht).

[sh17]

Ich konnte sie auch nur über Google finden.

[bernau]

Wobei dort immer noch nicht sicher gestellt ist, ob die Zertifizierung von Audicon eine rechtliche Sicherheit bietet.

Habe nirgends auf der Seite gefunden, daß das Finanzamt das Zertifikat von Audicon bindend akzeptiert. Letztendlich ist, nach meiner bisheriegen Erfahrung, immer der Gemütszustand des Steuerprüfers ausschlaggebend, ob die exportierten Daten akzeptiert werden, oder nicht. Habe schon viele Steuerprüfungen bei Kunden gehabt, die einfach durchgewunken wurden, weil anscheinend alles vorhanden war. Für einen Kunden bin ich mich aber schon seit einem halben Jahr mit einem Steuerprüfer am streiten.



Ich habe vor einigen Tagen/Wochen mal ein WIKI und ein Forum zum Thema GoBD eingerichtet, weil es mich stört, daß es nicht wirklich einen ausgeglichenen Informationspool zu diesem Thema gibt. Ist noch nicht wirklich viel drauf. Aber wer Informationen liefern kann, ist herzlich eingeladen diese zu veröffentlichen.

http://wiki.gobd-praxis.de
http://forum.gobd-praxis.de

(Die Endung "Praxis" habe ich von der Delphi-Praxis abgekupfert ;-) )

[sh17]

Toll.da bin ich gleich dabei. Hab schon ein paar Infos, aber auch Fragen.

[pliese]

Hallo,

die Daten von Audicon beschreiben den Aufbau der Dateien (index.xml + Daten im CSV Format), die in Summe den Beschreibungsstandard bilden. Wenn es um die Frage geht, welche Daten für eine Betriebsprüfung aus einer Finanzbuchhaltung, Warenwirtschaft oder Kasse anzuliefern sind, liefert das "Braunschweiger Modell" erste Anhaltspunkte (http://elektronische-steuerpruefung....f?m=1444059834)

Mit einem Produkt wie Opti.View (http://optiview.hsp-software.de/) können zum Beispiel beliebige Tabellen aus der Datenbank übergeben und dann in den Beschreibungsstandard (XML + CSV) konvertiert werden. Damit entfällt ggf. eine aufwändige Eigenentwicklung.

Viele Grüße,

Paul Liese

Zitat:

Zitat von sh17 (Beitrag 1350434)

Ist das evtl. die Bescheibung?

https://audicon.net/downloads/330

[bernau]

Zitat:

Zitat von pliese (Beitrag 1350473)

die Daten von Audicon beschreiben den Aufbau der Dateien (index.xml + Daten im CSV Format), die in Summe den Beschreibungsstandard bilden.

Wer hat diesen Standard festgelegt bzw. definiert.?

[jaenicke]

Zitat:

Zitat von bernau (Beitrag 1350529)

Wer hat diesen Standard festgelegt bzw. definiert.?

Das Finanzministerium gemeinsam mit Audicon. Das Finanzministerium wird dir aber nie eine schriftliche Bestätigung geben, dass du alles richtig machst. Daher ist die Zertifizierung durch Audicon die höchste Bestätigung, die du bekommen kannst.

Der Punkt ist nicht, dass du damit nie Probleme bekommen kannst. Der Punkt ist, dass es durch den standardisierten Export und durch die Zertifizierung in Kombination mit einer guten Lösung zur Unveränderbarkeit der Daten deutlich schwieriger ist einen konkreten Verdacht zu rechtfertigen. Bis dahin steht aber der Prüfer in der Beweispflicht, dass etwas nicht stimmt. Sobald er etwas findet, muss umgekehrt der Betreiber (bzw. du als Softwarehersteller in einem Gutachten) beweisen, dass das so in Ordnung ist.

Wenn du einen eigenen Export bereit stellst, der dann nicht so gut in IDEA einlesbar ist, ist das erst einmal auch kein Problem, zumindest aktuell noch nicht. Es macht dem Prüfer aber mehr Arbeit und erhöht nicht gerade das Vertrauen.

[mm1256]

Zitat:

Zitat von jaenicke (Beitrag 1350532)

...Es macht dem Prüfer aber mehr Arbeit und erhöht nicht gerade das Vertrauen.

So ist es :thumb: Und wenn er/sie dann schon etwas angefressen ist, sucht er/sie auch an Stellen, die oftmals nicht so genau durchleuchtet werden. Ich hatte schon mal einen Fall, da hat der Prüfer tatsächlich alle relevanten Datenbanken des WWS (Auftragsdaten, Rechnungsjournal) miteinander verglichen, ob es irgendwelche "Abweichungen" bzw. Unregelmäßigkeiten gibt. Man tut sich und seinen Kunden als Softwarehersteller keinen Gefallen, wenn man bei der GdPDU-Ausgabe spart.

[Captnemo]

Zitat:

Zitat von jaenicke (Beitrag 1350532)

Das Finanzministerium gemeinsam mit Audicon. Das Finanzministerium wird dir aber nie eine schriftliche Bestätigung geben, dass du alles richtig machst. Daher ist die Zertifizierung durch Audicon die höchste Bestätigung, die du bekommen kannst.

Hier mal ein kleiner Auszug aus folgendem Dokument http://www.bundesfinanzministerium.d...cationFile&v=3

Zitat Seite 37 Punkt 181

Zitat:

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

Zertifikat hin oder her...am Ende ist es nichts, worauf man sich berufen könnte.

Überigens, die Firma Audicon wird in dem ganzen Dokument nicht einmal als Referenz erwähnt. Somit ergibt sich aus der Aussage von Audicon auch kein Rechtsanspruch auf die Richtigkeit der Datenübergabe nach deren Format. (Auch wenn es tatsächlich aus deren Feder stammt).

Zitat:

Zitat von pliese (Beitrag 1350473)

Mit einem Produkt wie Opti.View (http://optiview.hsp-software.de/) können zum Beispiel beliebige Tabellen aus der Datenbank übergeben und dann in den Beschreibungsstandard (XML + CSV) konvertiert werden. Damit entfällt ggf. eine aufwändige Eigenentwicklung.

Hast du eine Ahnung was deren Produkt kostet?

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

[jaenicke]

Es kommt einerseits beim Kunden gut an, ja, aber andererseits weißt du auch, dass die Daten fehlerfrei lesbar sind.
Damit ist die Wahrscheinlichkeit hoch, dass die Daten auch korrekt sind. Die Summen, konkrete Beispiele usw. kann man ja selbst prüfen, insofern sollte da auch nichts ganz Falsches drin sein.

Die Alternative wäre zu warten bis bei einem Kunden eine Prüfung läuft. Aber wenn die Daten dann nicht einlesbar sind...

Natürlich hätten wir wie gesagt solch ein Zertifikat lieber wie in anderen Ländern vom Finanzamt. Aber da es diese Alternative nicht gibt... (was ich persönlich sehr kritisch für alle Beteiligten sehe)

[Lemmy]

Zitat:

Zitat von jaenicke (Beitrag 1354066)

Die Alternative wäre zu warten bis bei einem Kunden eine Prüfung läuft. Aber wenn die Daten dann nicht einlesbar sind...

dann besserst Du nach. Ich habe so eine Schnittstelle für eine alte BDE Software mal eben aus dem Hut gezaubert - am Ende war gaben wir eine einzige csv Datei ab. Der Kunde stand schon etwas unter Druck (Androhung von Zwangsgeld durch den FA Beamten). Am Ende kam er vorbei, las die CSV Datei ein und zog wieder an.

Zitat:

Zitat von jaenicke (Beitrag 1354066)

Natürlich hätten wir wie gesagt solch ein Zertifikat lieber wie in anderen Ländern vom Finanzamt. Aber da es diese Alternative nicht gibt... (was ich persönlich sehr kritisch für alle Beteiligten sehe)

sehe ich auch so. Und ich gönne denen nicht die 1-2k€ für ein solches "Zertifikat". Die Schnittstelle könnte durch ein simples SDK beschrieben werden und die Lesbarkeit durch ein XSD einfachst nachgewiesen werden. Die inhaltliche Vollständigkeit muss man in jeden Fall selbst garantieren

[jaenicke]

Zitat:

Zitat von Lemmy (Beitrag 1354068)

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:

Zitat von jaenicke (Beitrag 1354072)

Zitat:

Zitat von Lemmy (Beitrag 1354068)

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:

Zitat von Neumann (Beitrag 1354080)

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:

Zitat von Neumann (Beitrag 1354080)

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:

Zitat von Neumann (Beitrag 1354080)

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:

Zitat von arnof (Beitrag 1354053)

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:

Zitat von Lemmy (Beitrag 1354073)

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:

Zitat von jaenicke (Beitrag 1354101)

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

Zitat:

Zitat von Neumann (Beitrag 1354080)

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:

Zitat von arnof (Beitrag 1354053)

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 :cyclops: 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.

[jaenicke]

Zitat:

Zitat von mm1256 (Beitrag 1354113)

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.

Ich finde keine Stelle, an der es eine Ausnahme von der Einzelaufzeichnungspflicht innerhalb einzelner Rechnungen gibt. Es steht überall nur, dass die Verdichtung generell nicht erlaubt ist. Warum sollte es einen Unterschied machen, ob ich innerhalb einer Rechnung verdichte, wenn dies nicht explizit anders geregelt ist?

Wir zeichnen jedenfalls ohnehin jede Buchung einzeln auf und ändern daran danach nichts fiskalisch Relevantes mehr, schon aus Gründen der Nachvollziehbarkeit, insofern kann es uns egal sein, ob der andere Weg theoretisch auch ginge.

[hanvas]

Zitat:

Es steht überall nur, dass die Verdichtung generell nicht erlaubt ist. Warum sollte es einen Unterschied machen, ob ich innerhalb einer Rechnung verdichte, wenn dies nicht explizit anders geregelt ist?

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

Jeder ist wohl schon zusammen mit anderen, in ein Lokal gegangen und wurde erst beim Bezahlen gefragt : "jeder für sich oder alle zusammen" Das heißt das bis zu diesem Zeitpunkt sowohl 3 Bier an einen Rechnungsempfänger gehen können (und wohlmöglich eine Verdichtung vorliegt) oder aber auch 3 * 1 Bier an jeweils eine Person gegangen ist - und dementsprechend korrekterweise 3 Belege zu erstellen sind.

Und was ist wenn Gäste habe die Ihren "Deckel" nicht sofort begleichen, ist das eine Verdichtung oder habe ich nur unterschiedliche Leistungs und Rechnungszeitpunkte (wobei dann die Zusammenfassung ja wieder erlaubt ist).

Die gleichen Fragen stellt sich - zwar nicht aus Sicht des Programierers aber zumindest rechtlich - wenn die Bedienung im wahrsten Sinne des Wortes einen Deckel schreibt und erst beim Bezahlvorgang boniert - ist das eine Verdichtung oder ein vom Rechnungszeitpunkt abweichender Leistungszeitpunkt - und wenn die Bedienung das darf, warum darf man das mit einer Kasse nicht.

cu Ha-Jö

[arnof]

Zitat:

Zitat von Neumann (Beitrag 1354127)

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.

[Neumann]

Nächste Möglichkeit ist noch, dass ich auf die Rechnung schreibe:

3 Pils 6 € und dies in Tabelle A speichere,

und in Tabelle B speichere ich:

1 Pils 19:30
1 Pils 20:00
1 Pils 20:15
Dann kann ich nachweisen heute 157 Artikel gebucht, die Summe der Anzahl müsste ja in beiden gleich sein. A könnte ich noch mit B verknüpfen.

Über den Fall, das die fröhliche Runde 10 Pils bestellt und der Kellner 10*Pils einbucht und es nachher drei Leute bezahlen (3,3,4) muss ich noch nachdenken.

[bernau]

Zitat:

Zitat von arnof (Beitrag 1354132)

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:

Zitat von hanvas (Beitrag 1354131)

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:

Zitat von bernau (Beitrag 1354139)

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:

Zitat von jaenicke (Beitrag 1354141)

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)