AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein GdPDU-Schnittstelle, welche Daten sind anzuliefern
Thema durchsuchen
Ansicht
Themen-Optionen

GdPDU-Schnittstelle, welche Daten sind anzuliefern

Ein Thema von waldforest · begonnen am 16. Aug 2016 · letzter Beitrag vom 27. Jan 2017
Antwort Antwort
Seite 5 von 5   « Erste     345   
hanvas

Registriert seit: 28. Okt 2010
168 Beiträge
 
Delphi 11 Alexandria
 
#41

AW: GdPDU-Schnittstelle, welche Daten sind anzuliefern

  Alt 18. Nov 2016, 19:13
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ö
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.648 Beiträge
 
Delphi 11 Alexandria
 
#42

AW: GdPDU-Schnittstelle, welche Daten sind anzuliefern

  Alt 18. Nov 2016, 22:43
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.
Das sind ja zwei verschiedene Sachen. Das eine sind die Buchungen wie sie eingegeben werden (1 x Bier, 2 x Bier), das andere ist ggf. eine Aufteilung dieser Buchungen auf mehrere Rechnungen. Trotzdem ist bei uns klar welche Eingabe am Ende auf welcher Rechnung gelandet ist.
Sebastian Jänicke
AppCentral
  Mit Zitat antworten Zitat
arnof

Registriert seit: 25. Apr 2013
1.254 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#43

AW: GdPDU-Schnittstelle, welche Daten sind anzuliefern

  Alt 18. Nov 2016, 23:08
Das Inhaber geführte Gastronomen bescheissen ist doch bekannt, da ich mich immer geweigert habe eine Steueroptimierung zur Verfügung zu stellen ist unsere Gastroversion für viele Kassenhändler nicht verkaufbar!

Letztes. Jahr musste ein Wiederkäuer von mir die komplette Software und Hardware zurücknehmen, weil bei uns auch alle Trainsbuchungen gespeichert werden (Mafia ....)!

Das wissen auch die Prüfer und kassieren die Branche ab!

Ich hoffe das sich das mit der GoDB erledigt hat, da sich sowas kein Hersteller oder Händler mehr erlauben darf, sonst macht er den Hoeness -)

Österreich hat hier die richtige Lösung, dann ist auch Schuss mit versteckten 2 Kassen!
Das kommt 2020 auch bei uns!

Geändert von arnof (18. Nov 2016 um 23:31 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Captnemo
Captnemo

Registriert seit: 27. Jan 2003
Ort: Bodenwerder
1.126 Beiträge
 
Delphi XE4 Architect
 
#44

AW: GdPDU-Schnittstelle, welche Daten sind anzuliefern

  Alt 19. Nov 2016, 23:04
Also mit unzulässiger Verdichtung ist folgendes gemeint:

Da es sich, im Fall der Gastronomie, um anonyme Barverkäufe handelt, also der Rechnungsempfänger nicht namentlich erfasst wird, könnte ja ein Gastronom auf die einfache Rechnung kommen, lediglich festzuhalten das er an einem Abend 27 Bier, 6 Cola und 5 Glas Milch verkauft hat, und eben nur diese als ein Vorgang am Schluss in seine Kasse einbucht. In dem Fall würde unzulässig verdichten.
Werden aber auf einem Bon die Getränke und Speisen einer Bestellung zusammengefasst, dann ist diese keine unzulässige Verdichtung, da diese auch einem Gast (oder eben eine Gruppe, von der aber eben nur ein Bezahlvorgang ausgeht) zuzuordnen ist. Ob eine Gruppe dann vorher das Geld sammelt oder ob die Bedienung dieses aufgeteilt kassiert, ist, denke ich mal unerheblich, und auch schwer nachträglich prüfbar.
Bei der ganzen Sache geht es wohl eher um vergleichende Statistik, und weniger um die einzelne Buchung an sich.

Bei Rechnungen ist ja auch üblich und absolut zulässig eine Menge gleicher Artikel in einer Rechnungsposition zusammenzufassen.

Was aber passieren könnte ist, dass ein Prüfer sich mal eine gewisse Zeit in eine Kneipe setzt, und sich die Bestellungen von Gästen notiert. Später dann bei einer Prüfung genau diese Bestellungen raussucht und auf Richtigkeit prüft. Hat es alles schon gegeben. Aber soviel Zeit investieren die sicher nur bei einen gewissen Verdacht.
Dieter
9 von 10 Stimmen in meinem Kopf sagen ich bin nicht verrückt. Die 10. summt dazu die Melodie von Supermario Bros.
MfG Captnemo

Geändert von Captnemo (20. Nov 2016 um 13:26 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von bernau
bernau
Online

Registriert seit: 1. Dez 2004
Ort: Köln
1.295 Beiträge
 
Delphi 12 Athens
 
#45

AW: GdPDU-Schnittstelle, welche Daten sind anzuliefern

  Alt 23. Dez 2016, 11:12
Ich hole das Thema noch einmal nach vorne.

Habe nun öfters mit dem BMF und Finanzverwaltungen verschiedener Länder gesprochen. Schriftliche Informationen zu bekomme, ist sehr schwer. Aber telefonisch wird etwas mehr erzählt. Alles sehr nette Leute, die sich auch in die Problematik hineinversetzen können. Fakt ist aber, daß es keine Zertifizierung gibt. Ich bin ausserdem darauf aufmerksam gemacht worden, daß es laut Rz179 der GoBD keine Verpflichtung gibt, Zertifizierungen anzuerkennen. Es kann als Entscheidungshilfe verwendet werden. Muss aber nicht.

Siehe http://wiki.gobd-praxis.de/zertifizierung_von_software
Gerd
Kölner Delphi Usergroup: http://wiki.delphitreff.de
  Mit Zitat antworten Zitat
Benutzerbild von Captnemo
Captnemo

Registriert seit: 27. Jan 2003
Ort: Bodenwerder
1.126 Beiträge
 
Delphi XE4 Architect
 
#46

AW: GdPDU-Schnittstelle, welche Daten sind anzuliefern

  Alt 27. Jan 2017, 15:16
Eigentlich dachte ich ja, dass ich diesen Kelch an mir vorbei ziehen lassen kann, aber nun hat's mich doch getroffen.
Ein Kunden von mir (der einzige, dem ich mal ein Kassenbuch geschrieben habe) wollte eigentlich auf ein anderes System umsteigen. So zumindest die Aussage im letzten Jahr. Nun hat er sich überlegt, dass die damit verbundenen Unannehmlichkeiten doch zu groß sind, und ich soll das Kassenbuch jetzt GoDB-Fest machen.
Also muss ich mich jetzt doch ernsthaft damit befassen.

1. Das Kassenbuch selbst. Ich erfasse je Buchung Quittungsnummer, Datum/Uhrzeit, Artikel, Menge, Netto, Brutto, MwSt, MwSt-Satz, Stornokennzeichen, den Kassenbenutzer und den dann gültigen Kassenbestand. Reicht das? Oder müssen noch mehr Informationen erfasst werden.
2. Ich habe hier gelesen, dass eine Kassenbuch nicht willkürlich abgeschlossen werden darf. Als im Falle von Täglich, dann immer täglich. Ansonsten müsse das Kassenbuch neu verfasst werden (Den Satz verstehe ich nicht so wirklich). Hier mal das Zitat
Zitat:
9.Die Tagesfolge darf nicht willkürlich sein (bspw. 16.05. —> 09.05. —> 17.05. ...). Sollte die Verarbeitung eines Tages versehentlich unterblieben sein, muss das Kassenbuch neu verfasst werden.
Bei meinem Kunden bucht an der Kasse mehrere Pförtner, der die Kasse dann abschließt, wenn in der Verwaltung jemand da ist, um den Geldbetrag entgegenzunehmen. Der Pförtner ist 24/7 da, die Verwaltung aber nur 5 Tage die Woche und in Ausnahmefälle auch mal gar nicht. Heißt es kommt zu unterschiedlich langen Kassenzeiten. Ist das gültig?
3. Beim Kassenabschluss wird ja der eingenommene Betrag der Kasse entnommen und nur das Wechselgeld verbleibt in der Kasse. Muss diese Kassenentnahme auch als Kassenbuchung im Kassenbuch ganz normal erscheinen z.B (z.B. als "Transfer zur Bank")?
4. Die Übergabe zur Prüfung: Ich habe in verschiedene Programmen, die laut eigenen Angaben GoBD-Konform sein wollen, gesehen, dass sie lediglich eine CSV erzeugen. Ist die XML bzw. DTD zwingend notwendig? Es handelt sich nur um eine Kasse, und es werden auch nicht mehr werden. Und es handelt sich auch immer nur um Einzelbuchung die immer nur eine Position mit festem Betrag haben. Wenn ja, hat irgendwer mal ein paar Dummy-Dateien, die er mal zur Verfügung stellen möchte Damit man sich das mal anschauen kann. Ich kann sowas immer besser verstehen, wenn ich was zum angucken habe.
Dieter
9 von 10 Stimmen in meinem Kopf sagen ich bin nicht verrückt. Die 10. summt dazu die Melodie von Supermario Bros.
MfG Captnemo
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.648 Beiträge
 
Delphi 11 Alexandria
 
#47

AW: GdPDU-Schnittstelle, welche Daten sind anzuliefern

  Alt 27. Jan 2017, 22:59
1. Das Kassenbuch selbst. Ich erfasse je Buchung Quittungsnummer, Datum/Uhrzeit, Artikel, Menge, Netto, Brutto, MwSt, MwSt-Satz, Stornokennzeichen, den Kassenbenutzer und den dann gültigen Kassenbestand. Reicht das? Oder müssen noch mehr Informationen erfasst werden.
Wir erfassen noch viel mehr. Was davon erforderlich ist, kann ich aber nicht sagen.
Wichtig ist aber zusätzlich die Unveränderbarkeit der Daten. Sprich du brauchst eine passende Signierung / Verschlüsselung / ...
Und das ist in irgendeiner Form auch vorgeschrieben.

Die einfachste Variante ist eine fortlaufende Durchnummerierung aller Buchungen, was in deinem Fall ja unproblematisch ist. Ob das ohne weitere Maßnahmen reicht, kann ich nicht sagen.

2. Ich habe hier gelesen, dass eine Kassenbuch nicht willkürlich abgeschlossen werden darf. Als im Falle von Täglich, dann immer täglich. Ansonsten müsse das Kassenbuch neu verfasst werden (Den Satz verstehe ich nicht so wirklich).
Gemeint ist nur die Reihenfolge! Sprich du kannst nicht zuerst Montag abschließen, dann Mittwoch und dann den Dienstag hinterher.
Was du denke ich auch erzwungenermaßen brauchst ist eine fortlaufende Abschlagsnummer.

Heißt es kommt zu unterschiedlich langen Kassenzeiten. Ist das gültig?
[...]
Muss diese Kassenentnahme auch als Kassenbuchung im Kassenbuch ganz normal erscheinen z.B (z.B. als "Transfer zur Bank")?
Was spricht denn dagegen beides voneinander zu trennen? Ich meine der Tagesabschluss muss ja nicht heißen, dass das Geld aus der Kasse entnommen wird. Man kann z.B. genauso das Geld am nächsten Tag als Anfangsbestand weiterführen, irgendwann die Entnahme buchen, wenn die Abrechnungen abgegeben werden sollen und den Endbestand entsprechend erfassen.

4. Die Übergabe zur Prüfung: Ich habe in verschiedene Programmen, die laut eigenen Angaben GoBD-Konform sein wollen, gesehen, dass sie lediglich eine CSV erzeugen.
Ein bestimmtes Format ist nicht vorgegeben. Man spart sich bei einer normalen Kassenanwendung nur viel Ärger, wenn man sich an das vorgegebene Format hält. In deinem Fall würde ich denken, dass es auch gut mit einem eigenen Format geht. Du hast ja gar nicht so viele Daten.
Sebastian Jänicke
AppCentral
  Mit Zitat antworten Zitat
Alt 23. Aug 2017, 16:58     Erstellt von SOL Republic
Dieser Beitrag wurde von TBx gelöscht. - Grund: Verdacht auf SPAM und den damit verbundenen verschwenderischen Umgang von wertvollen Bits und Bytes
Antwort Antwort
Seite 5 von 5   « Erste     345   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:57 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz