====== Datenexport Betriebsprüfung ====== :!: GoBD: Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff Über **Umsätze/Datenexport Betriebsprüfung** gelangen Sie zum Datenexport Betriebsprüfung. Die hiermit ausgegebenen Dateien werden im CVS Format gespeichert und können vom Finanzamt eingelesen werden. Achten Sie bitte darauf, in welchem Kontenbereich Sie sich befinden. Wenn Sie die Daten aus einem Kassenkontenbereich, wie zum Beispiel UMSATZ, ausgeben möchten, wechseln Sie bitte vor dem GoBD-Export den entsprechenden Kontenbereich. Wie Sie den Kontenbereich wechseln, erfahren Sie hier [[http://doku.pccaddie.com/doku.php?id=de:umsaetze:kontenbereichwaehlen:kontenbereichwaehlen|Kontenbereich wählen]] Sollten Sie Exportdaten aus einem Archiv-Bereich benötigen, wechseln Sie bitte vorher in den jeweiligen Archiv-Bereich. Wenn Sie den Menü-Punkt **Datenexport Betriebsprüfung** anwählen, öffnet sich das folgende Fenster **Datenexport Betriebsprüfung**: {{:de:umsaetze:gobd:datenexport.png?500|}} Sie können nun die gewünschten Einstellungen vornehmen: {{:de:umsaetze:gobd:datenexport nummeriert.png?500|}} Bei Punkt (1) wird der zu exportierende Zeitraum definiert. Punkt (2) Hier haben Sie die Möglichkeit zwischen zwei Rechnungs PDF Exporten zu wählen. * **Per Mail versendete Rechnungen**. Es werden nur die tatsächlich per Mail versendeten Rechnungen exportiert. oder * **Alle Rechnungen**: Es werden alle in dem oben definierten Zeitraum geschriebenen Rechnungen als PDF Datei exportiert. {{:de:umsaetze:gobd:datenexport rechnungen.png?500|}} Punkt (3) legen Sie ein Ausgabeverzeichnis fest, wohin die CVS Dateien exportiert werden sollen. {{:de:umsaetze:gobd:datenexport nummeriert.png?500|}} Sofern Sie die Dateien beim Öffnen mit einem Passwort verschlüsseln wollen, tragen Sie bei Punkt (4) ein entsprechendes Passwort ein. Dieses wird dann gegebenenfalls später beim Öffnen der Export-Dateien benötigt. Danach klicken Sie auf **Export** Punkt (5) Pcc fragt noch einmal nach, ob der Fiscal Export für den gewählten Kontenbereich gestartet werden soll. {{:de:umsaetze:gobd:datenexport starten.png|}} Bestätigen Sie mit **Exportieren** Nachdem der Export durchgelaufen ist, bekommen Sie noch einige Informationen zum Fiscal Export angezeigt. Diese sind der ausgegebene Kontenbereich, der Zeitraum, Datum und Zeitpunkt des Exports, Name des Computers, des Windows-Benutzers, des Pcc-Benutzers und das Ausgabeverzeichnis. {{:de:umsaetze:gobd:datenexport zusammenfassung.png?500|}} Bestätigen Sie mit **OK**. Danach öffnet sich der Datei-Explorer (Windows-Explorer) mit dem ausgewählten Link (1) und einem ZIP-Ordner (2). Im Namen des ZIP-Ordners können Sie bereits den exportierten Kontenbereich und Zeitraum erkennen. Sie können mit einem Doppelklick den ZIP-Ordner öffnen. {{:de:umsaetze:umsaetze:gobd_explorer.png|}} In diesem ZIP-Ordner befindet sich ein weiterer Unterordner, der den Namen des Kontenbereichs hat. Auch diesen Ordner können Sie mit einem Doppelklick öffnen. Darin befinden sich dann die CVS-Dateien, die Sie mit Ihrem Standart-Tabellenprogramm öffnen können. {{:de:umsaetze:umsaetze:gobd_umsatz_neu.png|}} Die Export-Dateien sehen dann wie folgt aus: {{:de:umsaetze:umsaetze:gobd_dateien.png?600|}} Falls Sie ein Passwort vergeben haben und eine der oben genannten Dateien öffnen wollen, bekommen Sie folgende Meldung. Hier müssen Sie dann das vormals in Pcc eingegebene Passwort eintragen und nach Passworteingabe mit **OK** bestätigen. {{:de:umsaetze:umsaetze:gobd_pw.png|}} ===== Export-Dateien ===== In der nachstehenden Auflistung sind die Inhalte der einzelnen Dateien aufgelistet: ==== ARTICLE.CSV ==== Verwendete Artikel im definierten Zeitraum des exportierten Kontenbereichs ^ Feldname ^ Beschreibung ^ | CODE | Eindeutige ID | | NAME | Name | | WAGR | Warengruppen ID | | NETTO | Netto-Preis | | BRUTTO | Brutto-Preis | | MWST | Steuersatz in Prozent | | FIBU | FiBu-Nummer | ==== ARTICLE_GROUP.CSV ==== Verwendete Warengruppen im definierten Zeitraum des exportierten Kontenbereichs ^ Feldname ^ Beschreibung ^ | CODE | Eindeutige ID | | NAME | Name | | AREACODE | Buchungsbereich ID | | AREANAME | Buchungsbereich Name | | FIBU | FiBu-Nummer | ==== BOOKINGS.CSV ==== Es werden alle Buchungen aus dem ausgewählen Kontenbereich aufgelistet. :!: Die für wirtschaftliche Auswertungen wichtigen Felder sind fett markiert. :!: Bitte filtern Sie für Addition über KONTBRUTTO die Zeilen mit KONTTYP "a" und "p" heraus, da diese nicht umsatzrelevant sind. Die Gesamtsumme über alle Buchungen sollte im Normalfall 0 ergeben, da sich Verkaufs-Buchungen und Zahlungsbuchungen betragsmässig aufheben. Den Umsatz erhalten Sie also, indem Sie noch die Zeilen mit KONTTYP "Z" wegfiltern. Wenn sie nur auf KONTTYP "Z" filtern, erhalten Sie die Zahlungen. {{tablelayout?rowsHeaderSource=Auto}} ^ Feldname ^ Beschreibung ^ | **KONTMITGCO** | Kundennummer Feld CODE aus CUSTOMER.CSV (MITGCODE aus GOLFMITG.DBF) | | **KONTBEITCO** | Interne Artikelnummer Feld CODE aus ARTICLES.CSV (BEITCODE aus GOLFBEIT.DBF) | | KONTBEITSU | Erste vier Zeichen der öffentlichen Artikelnummer | | **KONTBEITNA** | Buchungstext; Preis:..... = Preisänderungen | | KONTEKNET | Einkaufspreis des gebuchten Artikels (selten verwendet) (Netto) | | KONTVKORG | Original-Verkaufspreis im Falle von Rabatten (Brutto) | | **KONTBRUTTO** | Bruttopreis für die Positionszeile inklusive Mwst. (Gesamtpreis für alle Artikel zusammen - nur Zeilen, bei denen hier ein Betrag steht, sind buchungstechnisch relevant - ist hier der Betrag 0, sind die Datensätze zur Information der Vollständigkeit halber exportiert) | | **KONTNETTO** | Nettopreis für die Positionszeile ohne Mwst. | | **KONTMWST** | Steuersatz in % | | KONTZAHLT | Bezahlter Betrag – nur in Spezialfällen verwendet | | KONTWAEHR | Währung bei Fremdwährungs-Zahlungen | | **KONTDATUM** | Buchungsdatum | | **KONTZEIT** | Buchungszeit | | **KONTSTATUS** | Status des Eintrags | | | 0 = Vermerke ohne eigenen Buchungswert (Rechnungskopf etc.) | | | 3 = Normale Buchungen | | | 4 = Buchung mit variablem Preis (Artikel „Divers“ etc.) | | | 5 = Buchung mit variablem Text | | | 7 = Kartenbuchungen (Aufladungen auf Wertkarten) | | **KONTTYP** | Buchungstyp | | | = Normal | | | a = Anfangssalden aus einer Saldenübernahme vom Vorjahr (im aktuellen Jahr nicht Umsatz-relevant) | | | B = Buchung | | | R = Rechnungskopf | | | Z = Zahlung | | | D = Gelöscht (Deleted) | | | p = Preisänderungen (Im Falle einer Preisänderung von Artikeln mit Bestand wird zur Dokumentation der alte Wert zum alten Preis in KONTBRUTTO ausgebucht und zum neuen Preis der neue Wert wieder eingebucht - deshalb müssen Datensätze mit KONTTYP=p bei Umsatzanalysen ignoriert werden) | | | A = Anpassung Artikelanzahl | | | U = Umbuchen | | | K = Kasse | | | k = Kassenbuch | | | V = Haupt-Wert-Buchung (Value) im Falle des Verteilens auf mehrere Bestandteile, bei denen der Betrag hier in der Hauptbuchung bleibt und die Unterbuchungen mit Status "w" nur für Warenbewegungen genutzt werden. | | | W = Waren-Bewegungs-Buchung (Wenn ein Artikel auf mehrere Verteilt wird, diese Buchung darf nicht in den Saldo gerechnet werden) | | | x = Entsprechende Gegenbuchung, wenn der Wert auf die Bestandteile verteilt wird, damit sich die effektiven Beträge nicht verdoppeln | | | y = Verbindungs-Datensatz, wenn ein Bestandteil nochmals Unter-Bestandteile hat | | | v = Entsprechende-Tochterbuchungen mit auf den Bestandteil gebuchten Werten | | | w = Warenbewegungs-Tochterbuchungen, wenn nicht der Verkaufspreis auf die Bestandteile verteilt wird, sondern nur die Zählung interessiert (dann sind KONTBRUTTO und KONTNETTO deshalb auch leer) | | | e = Einkaufs-Preis-Änderung - paarweise Datensätze, Ausbuchung zum alten Preis, Wiedereinbuchung zum neuen Preis. Mit Diesen Datensätzen werden Anpassungen der Preise im Warenbestand vermerkt - es handelt sich hierbei nicht um tatsächliche Kassenvorgänge. | | | f = Transfer-Buchung zwischen Familienmitgliedern (sollten sich gegenseitig aufheben) | | | q = OP-Konten-Transfer - Quittungs-Detail: Dies sind Buchungszeilen, mit denen beim Ausgleich eines OP-Kontos durch Bezahlung oder Verrechnung mit anderen Guthaben dokumentiert wird, welche OP-Belege beim Vorgang berührt wurden. Diese Datensätze selbst dürfen nicht wertmässig erfasst werden (KONTBRUTTO ist 0), da die zugrunde liegenden Vorgänge an anderer Stelle in der Ausgangsbelegen schon erlöswirksam gebucht wurden. | | | t = Mwst. Umstell-Buchung für Ausser-Haus-Verkauf | | **KONTBEZ** | Status | | | 0 = Unverbucht | | | 1 = In Rechnung | | | 2 = Eingezogen | | | 4 = Teilbezahlt | | | 5 = Bezahlt | | KONTSUMME | //Aktuell nicht verwendet// | | KONTZAHL | Anzahl Artikel - bei Storno-Gegenbuchungen mit negativem Betrag - bei Zahlungsdatensätze der Zahlbetrag in der Ausgangs-Währung | | KONTEINHFA | Einheiten-Faktor (Für spezielle Fälle, in denen bezogen auf den Warenbestand der Verkaufsfaktor beispielsweise 1 Glas nur zum Abgang von 0.2 Litern führt - nur in Ausnahmefällen genutzt und wohl nicht für die Wertermittlung relevant. Mit einem Offset von 100000 zudem genutzt, um bei Abo-Systemen die Punkteguthaben abzurechnen.) | | KONTMAHND | Mahndatum | | KONTMAHN | Mahnstufe | | **KONTRGNR** | Rechnungs-/Beleg-Nummer (Bei Datensätzen ohne Beleg-Nummer handelt es sich nicht um Kassenvorgänge, sondern interne Buchungen zur Dokumentation. Belegnummern werden zum Beginn eines Bezahlvorganges vergeben, um auch im Hinblick auf EC-Zahlungs-Geräte eine eindeutige Referenz zu haben. Deshalb kann es beim Abbruch von Zahlvorgängen beispielsweise durch Zahlungsabbruch am EC-Gerät zu reservierten, aber ungenutzten Beleg-Nummern kommen, die entsprechend in KONTBEITNA dokumentiert sind.) | | **KONTRGDAT** | Rechnungs-Datum | | KONTBEZDAT | Zahldatum | | KONTFIBU | Verbuchungsstatus in die Finanzbuchhaltung (bei Buchhaltungs-Schnittstelle) | | KONTAREA | Kassenbereich (bei Grossinstallation mit mehreren Kassenbereichen) | | KONTSTAREA | Statistikbereich (für Auswertungen nach Kundentypen, selten genutzt) | | KONTXINFO | Erweiterte Informationen für Spezialfälle | | KONTSTORNO | //Aktuell nicht verwendet// | | KONTRABATT | Rabattsatz in % | | KONTNUTZER | Verschlüsselte Benutzerkennung | | KONTPLEVEL | Preislevel | | KONTDTAPP | //Aktuell nicht verwendet// | | KONTDTBOOK | //Aktuell nicht verwendet// | | KONTPOS | Bestandsteil-Subposition | | KONTFISCAL | Fiskalisierung im Rahmen der DSFinV-K: Transaktions-Information | | KONTFISGRP | DSFinV-K: Fiskalisierungsgruppe (Buchungskreis) | | KONTFISBON | DSFinV-K: Fiskalisierungs-Bonnummer | | KONTFISTYP | DSFinV-K: Vorgangs-Typ | | KONTFISFLG | DSFinV-K: Fiskalisierung-Flags | | KONTTABLE | //Aktuell nicht verwendet// - Tischnummern-Feld ggf. mit Platz-Nummer | | KONTREVINF | Storno-Informationen | | KONTCHKSUM | Zeilenprüfsumme üblicherweise nicht verwendet | | KONTINDX01 | Interne Verknüpfung | | KONTINDX02 | Interne Verknüpfung | | KONTINDX03 | Interne Verknüpfung | ==== CASH_PROTOCOL.CSV ==== Es werden detaillierte Informationen zu Kassenbuchungen ausgegeben. Ähnlich dem Kassenprotokoll [[http://doku.pccaddie.com/doku.php?id=de:umsaetze:kassenprotokoll:kassenprotokoll|Kassenprotokoll]] Das Kassenprotokoll wurde Anfang des Jahres 2016 eingeführt. Es aktivierte sich beim Kunden automatisch, sobald das nötige Update eingespielt wurde. :!: Buchungen vor der Aktivierung werden nicht rückwirkend protokolliert und werden daher nicht ausgegeben. ^ Feldname ^ Beschreibung ^ | KAPOVER | Kassen-Protokoll Version | | KAPODATE | Datum | | KAPOTIME | Uhrzeit | | KAPOTYPE | Typus des Eintrags | | | B = Buchung | | | S = Storno | | | C = Tagesabschluss | | | I = Information | | KAPONR | Belegnummer | | KAPONRREF | Referenz-Beleg | | KAPOINFO | Information | | KAPOTOT | Total-Betrag | | KAPOTOTCNT | Summenzähler | | KAPOVNP | Normal-Satz Prozent | | KAPOVNN | Normal-Satz Netto | | KAPOVNB | Normal-Satz Brutto | | KAPOVR1P | Reduzierter Satz 1 Prozent | | KAPOVR1N | Reduzierter Satz 1 Netto | | KAPOVR1B | Reduzierter Satz 1 Brutto | | KAPOVR2P | Reduzierter Satz 2 Prozent | | KAPOVR2N | Reduzierter Satz 2 Netto | | KAPOVR2B | Reduzierter Satz 2 Brutto | | KAPOVSP | Spezieller Satz Prozent | | KAPOVSN | Spezieller Satz Netto | | KAPOVSB | Spezieller Satz Brutto | | KAPOV0P | Ohne Steuer Prozent (= 0) | | KAPOV0N | Ohne Steuer Netto | | KAPOV0B | Ohne Steuer Brutto | | KAPOVNTOT | Mehrwertsteuer-Total | | KAPOATT | Anhang | | KAPOKONT | Kontenbereich / Mandant-Kennung | | KAPOCRRNCY | Währung | | KAPOKASSNR | Kassen-Nummer | | KAPOUSER | Kassen-Bediener | | KAPOPCNAME | Computer-Name | | KAPOPCUSER | Computer-Anmeldung | | KAPOCKSREC | Datensatz-Nummer | ==== CASHBOOK.CSV ==== Kassenbuch-Buchungen ^ Feldname ^ Beschreibung ^ | KABUBELEG | Belegnummer – für Tagesabschlüsse, die in das Kassenbuch aufgenommen werden wird hier die Tagesabschluss-Nummer mit vorangestelltem «TA» verwendet. | | KABUDATUM | Datum der Buchung | | KABUBELDAT | ggf. abweichendes Belegdatum | | KABUZEIT | Uhrzeit der Buchung | | KABUTEXT | Belegtext | | KABUDEKRCO | Verlinkung mit MITGCODE in der Kundentabelle (Debitoren bzw. Kreditoren-Nummer) | | KABUBEITCO | Verlinkung mit BEITCODE in der Artikeltabelle (Konto-Artikel) | | KABUZARTCO | Verlinkung mit BEITCODE in der Artikeltabelle (Gegenkonto bzw. Zahlart) | | KABUZARTNA | Gegenkonto bzw. Zahlart-Bezeichnung | | KABUBRUTTO | Buchungsbetrag Brutto | | KABUNETTO | Buchungsbetrag ohne Mwst. | | KABUMWST | Mehrwertsteuersatz | | KABUSALDO | Saldo des Kontos nach der Buchung | | KABUSALDOG | Saldo des Gegenkontos nach der Buchung | | KABUSTATUS | Status der Buchung | | | K = aus der Kasse eine Ein- oder Auszahlung vorerfasst | | | U = aus dem Backoffice eine Buchung vorerfasst | | | V = Verbucht | | | Hinweis: für verbuchte Kassenbuch-belege entstehen zwei Datensätze in der GOLFKONT.DBF (Bookings), jeweils Konto und Gegenkonto | | KABUNUTZER | Benutzerkennung des Mitarbeiters | | KABUDSTAT | Storno-Status | | KABUDUSER | Benutzerkennung Storno | | KABUDDATE | Datum Storno | | KABUDTIME | Uhrzeit Storno | | KABUDWAY | Weg-Kennung Storno | | KABUAREA | Kassen-Nummer der Erfassung | ==== CHANGE_PROTOCOL.CSV ==== In dieser Datei werden alle Änderungen protokolliert. * Artikeländerungen * Benutzeränderungen (Neu, Ändern, Löschen) * Kassenbestand bestätigen * GoDB-konformes Kassenbuch deaktivieren * Tages-Abschluss * Mehrere Rechnungen zurücknehmen * Rechnung zurücknehmen * Änderung der Rechnungsnummer ^ Feldname ^ Beschreibung ^ | DATE | Datum | | TIME | Zeit | | TYPE | Art des Eintrags | | | CHG = Konfiguration | | | CASH = Kassen-Buchung | | KONT | Kontenbereich / Mandant-Kennung | | USER | Kassen-Bediener | | LINK | Verbindung zur weiteren Informationen (Belegnummer, Artikel-Tabelle, Benutzer etc.) | | INFO | Weitere Detailinformationen zur Dokumentation | ==== CUSTOMER.CSV ==== Verwendete Kunden im definierten Zeitraum des exportierten Kontenbereichs ^ Feldname ^ Beschreibung ^ | CODE | Mitglieds ID | | SUCH | Suchkürzel | ==== INFO.TXT ==== Informationen zum Fiscal-Export * Ausgegebener Kontenbereich * Zeitraum der Buchungen / Rechnungen * Datum und Zeitpunkt des Exports * Computername * Windows-Benutzer * PC CADDIE-Benutzer * Datenpfad zum PC CADDIE-Hauptverzeichnis =====Praktische Antworten zu Einzelbelegen===== ====1. Ausser-Haus-Artikel mit 19%==== **Rundengetränk im Haus verzehrt - Mwst. dennoch 7%** Der Artikel "Rundengetränk" ist wohl grundsätzlich als "Ausser-Haus-Artikel" mit 7% Mwst. angelegt worden. Das ist zundächst wohl inhaltlich auch korrekt, weil es sich bei so einem Rundengetränk üblicherweise um kleine PET-Flaschen handelt, die der Golfer auf die Runde mitnimmt und nicht in der Gastronomie trinkt. (so kenne ich es jedenfalls aus der Praxis, zum konkreten Fall kann ich nichts inhaltliches sagen) Ich vermute, dass in diesem Fall dann doch mal diese Flasche im Restaurant geöffnet werden sollte und der Kassenmitarbeiter unwissend diesen Artikel verwendet hat und den Preis auf 3.80 für Vor-Ort-Verzehr erhöht hat. Der Ergänzungstext "Im Haus" wurde als Begründung der Preiserhöhung jedenfalls manuell eingegeben. Nur gibt es bei solchen manuellen Änderungen natürlich keinen technischen Zusammenhang mit der Mwst. - das ist reiner Text, die Kasse kann die steuerrechtliche Komponente in solch einem Fall nicht beurteilen und dem Mitarbeiter war sie wohl auch nicht bewusst. {{:de:umsaetze:gobd:betr1.png|}} ====2. Datensätze in BOOKINGS ohne KONTRGNR==== Insbesondere Einlösung und Aufladungen Gutscheinkarte. ► Grundsätzlich können Belegpositionen mit leerer KONTRGNR bei der Auswertung weggelassen werden. In diesem Fall handelt es sich um Dokumentationsbuchungen zu den Guthabenkarten, die prinzipiell bereichsübergreifend (also auch im Golfbetrieb beispielseweise für den Bezug von Übungsbällen) genutzt werden. Wie das beim konkreten Kunden genau gehandhabt wird, haben wir nicht geprüft – da sind die Kunden in der Gestaltung recht frei. Jedenfalls kann deshalb gut sein, dass innerhalb der Restaurant-Kasse Guthaben von dieser Karte verwendet werden, die an der Kasse der Golfanlage aufgebucht wurden. Hierbei handelt es sich letztlich um Vorgänge, die nach meiner Einschätzung ohne Kenntnis der konkreten Gestaltung beim Kunden eine Verrechnung zwischen Gastronom und Golfbetrieb zur Folge hätten. Letztlich könen wir aber nur alle Möglichkeiten anbieten, diese Vorgänge korrekt abzubilden. Bei den beiden von Ihnen angsprochenen Buchungen ohne Belegnummer handelt es sich um reine Transfers von einer Person auf eine andere – wenn beispielsweise mit der Guthabenkarte des Mannes die Rechnung der Partnerin bezahlt wird. Diese Buchungen sind letztlich nur infromativ zur Dokumentation, aber letztlich nicht Bestandteil des Kassenbelegs, bei dem es ja nur darum geht, dass beispielsweise Speisen mit Kartenguthaben bezahlt werden, deshalb haben diese Umbuchungen keine Belegnummer. (Sie heben sich vom Betrag in KONTBRUTTO sowieso auf.) {{:de:umsaetze:gobd:betr2.png|}} ====3. Familien-Transfer ==== KONTRGNR 2019009971: 22 Datensätze, 2 davon mit KONTTYP f ► Grundsätzlich handelt es sich bei Buchungen mit KONTTYP "f" um Familien-Transfers. Mit diesen wird üblicherweise dokumentiert, wenn beispielsweise das Essen von der Tochter auf den Vater transferiert wird, wenn dieser für die Kinder die Rechnung begleicht – daher die Bezeichnung. Hier sieht man den konkreten Eintrag grau – technisch handelt es sich um zwei Datensätze, beim einen Kunden wird der Betrag ausgebucht, beim anderen eingebucht – der Vorgang hebt sich auf und spielt letztlich aus reiner Kassen-Umsatzbetrachtung auch keine Rolle: {{:de:umsaetze:gobd:betr31.png|}} Hier in diesem Falle wurde ein Beleg über insgesamt EUR 135,30 mit einem Betrag von EUR 30,00 durch Guthabenkarte beglichen, die restlichen EUR 105.30 wurden bar bezahlt – soweit eigentlich ein relativ normaler Vorgang. Vermutlich durch Missverständnisse bei der Bedienung ist hier ein "Familientransfer" im übertragenen Sinne versehentlich passiert: Der Umsatz, der ursprünglich ohne konkreten Kunden auf das Standardkonto "Laufkundschaft" gebucht wurde, ist beim Bezahlvorgang auf einen Kunden namens "Gutschein, Gutschein" – also offensichtlich ein Verrechnungskonto – umgebucht worden. {{:de:umsaetze:gobd:betr4.png|}} ====4. Bonpositionen ohne Positionsnummer==== KONTRGNR 2019011082: 214 Datensätze in der Datei Bookings - davon haben 212 den Datensatztyp (KONTTYP) "q". ► In diesem Falle handelt es sich um die Bezahlung einer Schuld im Kundenkonto mittels Guthaben-Karte. Es ist so, dass es in der Kasse die Möglichkeit gibt, Belege in ein Konto "auf Rechnung" zu buchen. Diese Buchungen erscheinen dann in den Kassenkonten in dieser Art – hier im Beispiel Beleg 2019001207: {{:de:umsaetze:gobd:betr52.png|}} Für diese Kunden wird dann ein OP-Konto geführt, in dem diese Überträge zusammengefasst werden und aus dem heraus manche Kunden Lastschriften oder monatliche Abrechnungen erzeugen. In diesem konkreten Fall wurde in der Kasse die Funktion genutzt, die Schuld aus dem OP-Konto zu bezahlen – dann werden alle Belege mit Ihren Details zusammengesucht und der zu zahlende Gesamtsaldo berechnet – in diesem Fall EUR 35.57: {{:de:umsaetze:gobd:betr61.png|}} In dem Fall führt die Einlösung des Gutschein-Guthabens letztlich zu einer Gutschrift auf das OP-Konto, das die Forderung dort ausgleicht und damit ist alles erledigt. Die einzelnen Datensätze mit der Kennung "*" gefolgt von "PER", "INV" bzw. "DET" (für Person, Invoice und Detail) dienen nur der internen Dokumentation, welche Positionen durch diesen Vorgang tangiert wurden. Zusätzlich sind diese Datensätze mit KONTTYP "q" gekennzeichnet. Die eigentlichen Vorgangs-Datensätze sind aber natürlich schon an anderer Stelle vorhanden (sollten Sie auch im Export an den entsprechenden Stellen auch finden). Da diese Datensätze nur der Dokumentation dienen, sind die Felder KONTBRUTTO und KONTNETTO hier auch 0. Insgesamt ist die Kasse so programmiert, dass KONTBRUTTO den wirklich entscheidenden Wert enthalten muss. {{:de:umsaetze:gobd:betr7.png|}} ====5. Nur Bonpositionen, 2 Datensätze: wo sind Bonkopf und Zahlung zu finden?==== KONTRGNR 2019018907 - Bestellungen und Zahlungen mit auseinanderliegendem Datum ► In unserer Kassenlösung war es möglich, bestehende Bestellungen, die, wie Sie hier im Beispiel sehen, im Oktober bereits getippt ("bestellt") wurden, in der Kasse stehen zu lassen. Sie waren dann bereits fix gebucht und nicht mehr löschbar (ggf. nur noch durch dokumentierte Gegenbuchung stornierbar). Damit wurde das im Clubbereich übliche Zahlen beispielsweise zum Monatsende etc. vereinfacht, wobei wir eigentlich empfehlen, in solchen Fällen über den OP-Bereich zu buchen, wie unter 4. dargestellt. {{:de:umsaetze:gobd:betr81.png|}} In diesem Falle ist der Zeitraum zudem recht extrem ausgefallen: Der Kunde hat seine zwei Bonpositionen vom Oktober 2019 erst im Mai 2020 schliesslich bezahlt. Da der Export auf die Vorgänge im Jahre 2019 begrenzt wurde, sind zwar die Bestell-Buchungen in Ihrem Export vorhanden, der Belegkopf, die Bestellposition vom Mai 2020 und die Bezahlung des Gesamtbetrages hingegen gehören in den Export für das Jahr 2020. ====6. Behandlung von Gutscheinen==== KONTRGNR 2019007581 Behandlung von Gutscheinen ► In diesem Falle handelt es sich wiederum wie unter Punkt 4. um den Ausgleich einer Schuld im Kundenkonto mittels Guthaben-Karte. Dann wird ein Beleg mit den Bestellpositionen erzeugt, der durch einen Transfer in das OP-Konto ausgeglichen wird. Aus Kassen-Sicht sieht das dann so aus: {{:de:umsaetze:gobd:betr10.png|}} Im OP-Konto (hier des Restaurants) erscheinen die Buchungen dann in dieser Form: {{:de:umsaetze:gobd:betr11.png|}} Hier werden letztlich nur die Beleg-Summen gesammelt und als Kunden-Konto geführt. Beim fraglichen Beleg 2019007581 wurde nun der Kunden-Saldo 106,78 bezahlt, indem dafür das Guthaben der Guthaben-Karte verwendet wurde. Deshalb wird auch wiederum die Guthaben-Entnahme von der Guthaben-Karte gegen dieses OP-Konto gebucht, damit dieses letztlich ausgeglichen ist. Mehr Details gibt es in diesem Beleg dann so unmittelbar nicht – die Verbindung zu den damit bezahlten Leistungen über das OP-Konto ist dadurch sehr indirekt geworden. Im Einzelfall kann man dies dann nur über die Konten in der Software natürlich nachvollziehen. Wo die Gutscheinkarte geladen wurde, kann man hier in den Vorgängen nicht sehen, dazu gibt es Auswertungen innerhalb der Software zur einzelnen Guthaben-Karte – je nach Konstellation beim Kunden ist denkbar, dass die Ladung im Golfbetrieb unabhängig von der Gastronomie vorgenommen wird und eine Nutzung dieses Guthabens im Restaurant zu einer Verrechnung zwischen Anlagen-Betrieb und Gastronomie-Betrieb führt. (siehe auch Punkt 2.) ====7. 3 Datensätze, 100,00 Gutschein Verkauf (mit Stornierung) und (trotzdem) Zahlung 100,00==== KONTRGNR 2019016690 ► Hier handelt es sich um drei Vorgänge, die unmittelbar nacheinander erfolgt sind. Da Herr Axel Heck bei uns im Team ist, vermute ich, hier sollte die Gutschein-Funktion getestet oder demonstriert werden. 1. Beleg 2019016687 13:12 Uhr: Verkauf eines Gutscheines über EUR 100,00 und Barzahlung desselben. {{:de:umsaetze:gobd:betr12.png|}} 2. 13:27 Uhr wurde dieser Beleg storniert, deshalb wurde ein Aufhebungs-Beleg 2019016690 erzeugt, der mit umgekehrten Vorzeichen den eigentlichen Verkaufsvorgang aufhebt. Der Gutschein ist damit wieder in der Kasse als bestelltes Produkt. 3. In der Kasse wurde dann der Gutschein-Verkauf an sich wiederum storniert und gegengebucht. Damit handelt es sich nun um einen 0-Beleg, der um 13:33 mit Beleg-Nummer 2019016691 ausgebucht wurde. Letztlich heben sich alle Buchungen in diesem Zusammenhang gegenseitig auf und dokumentieren lediglich einen wieder vollständig stornierten Verkaufsvorgang eines Gutscheins.