DSFinV_K-, GDPdU-, AmadeusVerify Export
Dieser Export dient Prüfungen und ermöglicht die Ausgabe von Stammdaten (teils historisch) und Bewegungsdaten
Bewegungsdaten sind meist zeitlich relevant und liefern die Informationen für Auswertungen. In der Hypersoft-Suite z.B.Kassenbuchungen.. Häufig wird hierfür das Programm Amadeus Verify von Prüfern verwendet. Hypersoft prüft die Daten ebenfalls mit dem jeweils aktuellen Amadeus Verify Programm.
Weiterführende Dokumentation: KassenSichV Export nach DSFinV-K.
Für statistische Zwecke können Sie auch Journal für Statistiken exportieren verwenden.
Sie können den beschriebenen Export automatisieren.
| Element / Schalter | Funktion / Beschreibung |
|---|---|
| Daten gemäß DSFinV-K exportieren |
Wählen Sie den gewünschten Zeitraum und gegebenenfalls anderer Einstellungen. Betätigen Sie den benannten Knopf um die Daten zu exportieren. Die Daten werden von den aktuell angeschlossenen TSE Sticks exportiert. Achten Sie darauf, wenn Sie nicht genau den beschriebenen Knopf vorfinden, befinden Sie sich vermutlich in einem anderen Exportdialog und erhalten andere Daten. |
| TSE Export |
Export nur der TSE-Stick Daten ( evtl. für Stichproben). Es gilt der gleiche Ablageort wie beim DSFinV_K exportieren. Details weiter unten. |
| GoBD / GDPdU Export | Export nach GDPdU für Prüfungen in Deutschland (Standard bereits vor der Kassensicherungsverordnung). |
| Datenerfassungsprotokoll lt. RKSV (AT) exportieren |
Dieser Knopf wird nur angezeigt, wenn entsprechenden AT-Signaturdaten vorliegen.
Der Knopf erzeugt das so genannte DEP für Österreich im vom Österreichischen Finanzamt geforderten Format.
Der Export erfolgt im anzugebenen Ablageort im Ordner HS-EXPORT-DEP. Weiterführende Dokumentation: Fiskalgesetz in Österreich RKSV |
| Öffnungstag oder Zeitraum | Wählen Sie den Öffnungstag oder den exakten Zeitraum. Bedenken Sie Überschneidungen, wenn Ihr Betrieb nach 0:00 Uhr geöffnet hat. |
| Jahresdateien (nicht DSFinV_K) |
Exportiert Jahresdateien. Im rechten Textfeld erscheinen während des Exports Informationen über die aktuell gelesenen Informationen. |
| Monatsdateneien (nicht DSFinV_K) | Exportiert MOnatsdateien. Im rechten Textfeld erscheinen während des Exports Informationen über die aktuell gelesenen Informationen. |
| Ohne Aufteilung |
Die Alternative ohne Aufteilung ermöglicht die Zusammenfassung des Exports in einer Datei. |
| Pro Abschlusstag (nur DSFinV_K) |
Diese Auswahl entspricht DSFinV_K: Pro Abschlusstag werden einzelne Dateien erzeugt. Hiermit werden die Daten pro Abschlusstag sofort gesichert. Damit ist es möglich beliebig große Zeiträume zu sichern ohne Dateiobergrenzen bezüglich deren Größe berücksichtigen zu müssen. |
| Ablageort |
Der Dateiname des Exports ergibt sich anhand des Mandanten / Zeitraums, daher kann nur der Ablageort vorgegeben werden. HS-EXPORT Darin enthalten ist je nach Exportvariante ein oder mehrere Ordner ( Pro Datumsbereich / Monate / Jahre). Der Name einer Exportdatei ist: Mandant # vonDatum-vonZeit bisDatum-bisZeit Beispiel: MANDANT_1_20120101_60000-20120201_55959.XML Bzw. wenn der Export über die Option Öffnungstag erfolgt, ohne Uhrzeiten. Beispiel: MANDANT_1_20120101-20120131.XML Verzeichnisaufbau... Der Order TAR wird von den DSFinV-K Daten getrennt, da AmadeusVerify in diesem Ordner nach Exportdaten sucht. Sofern bei Ihnen die Hypersoft Lizenz TSE-Online-Archiv vorhanden ist, werden die TAR-Archive in monatsweisen Archiven separiert. Es werden dann nur die zu dem Export passenden Archive exportiert. Technisch bedingt kann es passieren, das noch einige wenige Signaturen im Archiv des jeweiligen Vormonats liegen. Damit diese ggf. geprüft werden können, liegen diese nun zusätzlich im Ordner TAR-VOR-EXPORTBEREICH und können auf Wunsch eingelesen werden.
Der Ordner enthält die Dateien, die vom Finanzamt benötigt werden.Die vollständige Beschreibung ist der Datei „index.xml“ enthalten. Der Ordner kann direkt an das Finanzamt übergeben werden oder mit pkzip / winzip etc. im Zip-Format komprimiert werden. Beides wird vom Finanzamt akzeptiert. Die Steuernummer aus den Stamminformationen wird in den Export eingetragen. Daher ist hier auf korrekte Stammdaten zu achten. |
| Trinkgelder (AN) als... exportieren |
Bitte wählen Sie die Behandlung von Trinkgeld für den Export.
|
| Einzahlung als... exportieren |
Bitte wählen Sie die Behandlung von Einzahlungen für den Export.
|
| Auszahlung als... exportieren |
Bitte wählen Sie die Behandlung von Auszahlungen für den Export.
|
Pro TSE wird eine Anforderung gesendet, diese sind im obigen Statusfenster zu sehen. Die Anforderungen stehen zusätzlich im Feld Angefordert.
Ist eine TSE in Betrieb, wird der Status auf in Arbeit gesetzt. Je nach Laufzeit des Sticks kann der Export mehrere Minuten dauert ( bis zu Stunden ). Es gibt währenddessen einen blinkenden Hinweis, dass das System auf „Rückmeldung“ wartet. Nach erfolgreichem Export oder einen Fehler, werden diese je nachdem in dem Feld Fertig oder Fehler angezeigt. Ist ein System nicht erreichbar ( ausgeschaltet ) bleibt die Anforderung stehen. Diese kann mit dem KnopfZurücksetzen dann wieder aufgehoben werden, da der Knopf Dateien anzeigen nur aktiv wird, wenn alle Anforderungen abgearbeitet wurden. Klickt man den Knopf Dateien anzeigen öffnet sich ein Windowsdialog mit den Dateien. Diese wird im Ordner „X:\Hypers-!\ETC\CLNTxxxx\TSEEXPORT“ zur Verfügung gestellt ( Das X steht für Serverlaufwerk oder xxxx die Mandantennummer).
Zur Zeit noch keine manuelle LÖSCHFUNKTION integriert, da es noch keinen Workflow für das Sichern der manuell exportieren Dateien gibt (bitte warten sie auf Archivlösungen).
Manueller Export der TAR Files...
Beim manuellen Export der TAR Files über den Journalexport erfolgt die Ablage automatisch dort, wo der Export sie ggf. exportieren würde.
Beim Export wird eine zusätzliche Datei mit ausgegeben, anhand der sich Änderungen in den Einstellungen und Eingaben wichtiger Stammdaten nachvollziehen lassen (Anmerkung: Änderungen im Artikelstamm können direkt aus dem Artikelstamm ausgegeben werden).
Die Änderungshistorie wird als changelog.csv exportiert, da es kein offizielles Format gibt.
Die Historie beinhaltete Informationen über Erstellung oder Änderung in folgenden Bereichen:
- Verkaufsstellenbezeichnungen
- Mitarbeiter Name, Vorname, Geburtstag, Berechtigungsvorlage
- Ca. 40 der relevanten Einstellungen aus den Bedienerberechtigungen
-
Stationsnamen, Stationsnummern, Berechtigungsgruppe / Station
- Nummernkreise ( Rechnungen etc. )
- Preisebenen, Verlustgründe, Stornogründen
- Warengruppen
Weitere Informationen (obsolet für IDEA Import, da hierfür bereits beschrieben)
Der Exporttyp Journal komplett inkl. Stammdaten erzeugt eine XML Ausgabedatei die 22 Tabellen beinhaltet.
Der Export überprüft die Datenbank auf Manipulationen (wie das Programm Status Buchungsjournal). Die Hashcodeprüfung dauert sehr lange, gerade bei großen Datenmengen.
Es wird dann eine Protokoll-Datei erzeugt. Der Inhalt listet den Status der Vorerfassung (Funktion seit 2016 entfernt) und Prüfsummenfehler im Hashcode auf. Treten keine Fehler auf und war keine Vorerfassung (Funktion seit 2016 entfernt) im Exportzeitraum aktiviert, wird dies auch dargestellt.
Die Tabellen Journal und Payment enthalten die Buchungsdaten und Zahlungsdaten. Der Inhalt der weiteren Tabellen sind Stammdaten. Der Name der Tabelle entspricht dem Namen der Spalte in Journal / Payment.
| TrainingJournal | Trainingsbuchungen (leer wenn keine Trainingsbuchungen vorhanden). |
| PaymentStatus | Status der Zahlung ( Auslage, Trinkgeld etc.) |
| ItemStatus | ist separat dokumentiert |
| ItemStatusDetail | Ergänzende Informationen zum ItemStatus |
| CurrencyID | Verwendete Währungen |
| PayType | Art der Zahlung ( Bar, Kredit etc. ) |
| EmpID | Mitarbeiter |
| Station | Stationen |
| StockID | Verkaufsstellen |
| CancelMode | Storno-Varianten |
| DiscountType | Rabatt-Varianten ( Artikel, Vorgang etc. ) |
| UnitType | Typen bei Einheitenverkauf (Zeit, Gewicht, Volumen etc. ) |
| PrintFormNo | Formulare ( Rechnungsdruck ) |
| CancelReason | Stornogründe |
| PriceLevel | Preisebenen |
| LossesID | Verlustgründe |
| HGR/WGR/UGR | Hauptgruppen / Warengruppen / Untergruppen |
| SHIFT/SHIFT2 | Schichten |
| RefStatus |
Status der Wiederöffnung: 0 normaler Vorgang, 1 Gutschrift, 2 gutgeschriebener Vorgang. |
Wenn eine Negative Buchungsanzahl mit dem Cancelmode Null vorhanden ist, dann sind dies automatisch erstellte Gegenbuchungen von Vorgängen, die nach Rechnungsstellung wieder geöffnet wurden. Hierzu wird auch der Stornobeleg erstellt (wenn zuvor eine Rechnung erstellt wurde). Die Buchungen und der originale Vorgang bleiben unverändert. Der originale Vorgang wird kopiert und die Artikelbuchungen mit einem negativen Vorzeichen versehen. Der Cancelmode bleibt Null, da es sich um Gegenbuchungen handelt. Gleichzeitig wird der Originalvorgang ein weiteres Mal kopiert, aber als neuer offener Vorgang der die Buchungen in positiver Anzahl enthält. Die Artikelbuchung ist sozusagen dreimal vorhanden, die alte positive und die negative Gegenbuchung, sowie die neue positive Buchung. Für die Funktion gibt es in der Praxis unterschiedliche Gründe, wie zum Beispiel nachträglicher Wunsch die Rechnung zu teilen. Einer der üblichen Gründe für dieses Vorgehen ist das Vorlegen einer Rechnung, die ohne weitere Informationen vom Kunden angefordert wurde und für die der Kunde dann unvorbereitet eine bargeldlose Zahlung wünscht. Wenn nun ein EC Terminal mit Buchhaltungsanbindung und bargeldlosem Trinkgeld verwendet wird, entstehen solche Gegenbuchungen für die ursprüngliche Rechnung. CancelMode 10: "Storno vor Order und "CancelMode 11: "Storno nach Order".
Zum RefStatus: Wenn ein abgeschlossenen Vorgang wieder geöffnet wird werden Gegenbuchungen erzeugt, damit der Vorgang zur sicheren Nachbearbeitung angeboten werden kann. Um bei Prüfungen dieser natürlichen Buchungen mit negativer Anzahl sicherer von Storni abgrenzen zu können berücksichtigen Sie das RefStatus Feld entsprechend. Für den Export erhält die ursprünglich positive Buchung im Feld RefStatusden Wert 2 (gutgeschriebener Vorgang). Die Gegenbuchung mit negativer Anzahl erhält der RefStatus den Wert 1 (Gutschrift).
Anzeige im Payment: Positionen werden mit Abschluss des Vorgangs im Payment angezeigt. Dies kann eine Zahlung sein (Standard) oder zum Beispiel ein Transfer auf Kundenkonto (Zahlung mit nachfolgendem System), eine Weitergabe an ein Hotelsystem (zur späteren Zahlung beim Hotel Check Out im PMS Nachfolgesystem) oder z.B. Abschluss als Einladung (ein abgeschlossener Vorgang als Einladung hat den Zahlbetrag 0,0). Je nach Einstellung wird ein Tagesabschluss mit offenen Vorgängen nicht ausgeführt oder verbliebene offene Vorgänge werden automatisch abgerechnet.
Umstellung des Stornosystems
Das Stornosystem wurde mit dem SP 5 angepasst.
Es galt bis Version SP 5...
Sofern innerhalb des Journals Buchungen mit negativen Artikelmengen und dem Cancelmode Null vorhanden sind, dann sind dies automatisch erstellte Gegenbuchungen von Vorgängen, welche nach Rechnungsstellung wieder geöffnet wurden. Zu diesen Gegenbuchungen wird ein Stornobeleg erstellt. Die Buchungen zum originalen Vorgang bleiben jedoch unverändert. Der originale Vorgang wird kopiert und die einzelnen Artikelbuchungen mit einem negativen Vorzeichen versehen. Der Cancelmode bleibt Null, da es sich um Gegenbuchungen handelt. Gleichzeitig wird der Originalvorgang ein weiteres Mal kopiert, aber als neuer offener Vorgang, der die Buchungen in positiver Anzahl enthält.
Die Artikelbuchung ist sozusagen dreimal vorhanden, die alte positive und die negative Gegenbuchung, sowie die neue positive Buchung. Für die Funktion gibt es in der Praxis unterschiedliche Gründe, wie zum Beispiel nachträglicher Wunsch die Rechnung zu teilen. Einer der üblichen Gründe für dieses Vorgehen ist das Vorlegen einer Rechnung, die ohne weitere Informationen vom Kunden angefordert wurde und für die der Kunde dann unvorbereitet eine bargeldlose Zahlung wünscht. Wenn nun ein EC Terminal mit Buchhaltungsanbindung und bargeldlosem Trinkgeld verwendet wird, entstehen solche Gegenbuchungen für die ursprüngliche Rechnung.
Ab Version SP 5...
Um mit Hilfe des Journals nachträglich herleiten zu können, aufgrund welcher Umstände ein Storno durch den jeweiligen Bediener herbeigeführt wurde, erfasst das Kassensystem entsprechend folgender Tabelle zu jedem Storno den sog. Canclemode. Je nach dem mit Hilfe welcher Funktion bzw. durch welchen Systembestandteil ein Storno erstellt wurde, ist anhand des Cancelmodes erkenntlich welcher Ursprung, dem jeweiligen Storno zugrunde liegt. Folgende Cancelmodes sind vorgesehen:
Mit Hilfe des Cancelmodes lassen sich im Journal erfasste Storni darüber hinaus der Situation zuordnen, innerhalb welcher sie erzeugt wurden.
- Storni mit Cancelmode-IDs von 0-99 wurden während des regulären Kassenbetriebs durchgeführt
- Storni mit Cancelmode-IDs von 100-199 wurde mit Hilfe der Funktion Zahlungsart ändern durchgeführt
- Storni mit Cancelmode-IDs von 200-299 wurden mit Hilfe der ReOpen-Funktion durchgeführt (Wiederöffnung von Vorgängen)
Hierbei ist es nützlich zu verstehen, dass ein systematischer Zusammenhang zwischen den ID-Nummern besteht. Jede ID-Nummer unter 100 hat jeweils ein vergleichbares Pendant in den Nummernbereichen zwischen 100 -199 und 200 – 299.
Weiterführende Dokumentation: Spezielle Preis- und Verlustbehandlung
Tagesumsatz errechnen aus allen Datensätzen die in Vat-Tab einen Wert größer „0“ enthalten
Alle Buchungen in Journal.csv mit „VatTab = 0“ sind auch nicht umsatzrelevant.
Die Tagesumsätze können Sie der Journal.csv entnehmen.
Rechnen Sie für jeden Öffnungstag (Opendate) Quant * Price
Folgende Nummern im Itemstatus sind nicht umsatzrelevant.
1,3,5,7 = Trainingsbuchungen aus früheren Programmversionen. (Bis Hypersoft Suite 2012 (SP 60) vom 18.05.2011)
9 = aus Konvertierung alter wieder geöffneter Daten. (Bis Hypersoft Suite 2012 (SP 60) vom 18.05.2011)
10 = Verkauf eines umsatzneutralen Wertgutscheins (auch Web-Gutschein)
11 = Artikelgutschein
12 = Bonusgutschein
30,31 = Mehrwertsteuerverteilung Zusatzinfo, der umsatzrelevante Datensatz hat dann die 31 (siehe auch 80 81).
36 = Umsatzverteilung Zusatzinfo, der umsatzrelevante Datensatz hat dann den Itemstatus 31, Kombination aus Salesmix und Umsatzverteilung (möglich mit Daten ab Hypersoft Suite 2017 (SP 1) vom 07.11.2017).
60,61 = Umsatzverteilung Zusatzinfo (siehe auch 80 81).
80, 81 = Ab HF 11 für SP 11 2020 bekommen die Datensätze für MwSt. Verteilung nicht mehr den ItemStatus 30 und 31 und für die Umsatzverteilung 60 und 61, sondern alles gleichzeitig mit 80 und 81. Damit ist auch eine Kombination von MwSt. Verteilung und Warengruppenverteilung auswertbar.
90, 92 = Interne Buchungen ohne Umsatz. (Sonderfunktion Kartenvorverkauf)
Die Tabelle ItemStatus
Das Hypersoft Journal kann zu einer Buchung zusätzliche Informationen in weiteren Buchungen enthalten. Daher ist es wichtig, im Journal die Spalte ItemStatus zu berücksichtigen. Die Spalten Anzahl / Umsatz und Mehrwertsteuer steuern die jeweilige Auswertung der Daten.
- Buchungssätze mit ItemStatus mit dem Wert „1“ in Artikelanzahl werden zur Berechnung von Artikelstückzahlen verwendet.
- Buchungssätze mit ItemStatus mit dem Wert „1“ in Umsatz werden zur Berechnung von Umsätzen verwendet.
- Buchungssätze mit ItemStatus mit dem Wert „1“ in Mehrwertsteuer werden zur Berechnung der Ust. Verwendet.
Beispiel an einem "Salesmix" ( Artikel die mehr als eine Steuerstufe enthalten, Speisen+Getränke in einem Menü außer Haus):
Der gebuchte Artikel erhält den ItemStatus 30 ( SalesMix_Master ) mit dem kompletten Verkaufspreis. Das Hypersoft System erzeugt nun je Steuerstufe einen weiteren Buchungssatz mit dem ItemStatus 31 ( Salesmix_Slave ). Diese Datensätze sind identisch mit dem vorherigen Datensatz, weisen als Preis jedoch nur noch die Summe des jeweiligen Steuersatzes aus. Daher dient der ItemStatus 30 zur Berechnung von Stückzahlen und Umsatz, nicht jedoch zur Berechnung der Steuer, da der Artikel mehr als einen Steuersatz enthält. Hierzu werden dann die passenden Buchungen mit dem Status 31 ausgewertet.
- Status 30: 1 * Menü ( außer Haus ) 3,50 Euro
- Status 31: 1 * Menü ( außer Haus ) 2,00 Euro ( Umsatz für 19% Steueranteil, Getränk )
- Status 31: 1 * Menü ( außer Haus ) 1,50 Euro ( Umsatz für 7% Steueranteil, Speise )
Der ItemStatus 70 betrifft "Storno vor Order", kein Artikelbuchung, kein Umsatz, keine MwSt.
Umsatzverteilung der Warengruppen bei einem Artikel
Anstelle der MwSt. können bei einem Artikel auch mehrere Warengruppen angesprochen werden.
Das Feld NH_ProzValue dient zur Abspeicherung der Umsatzverteilungsprozente. Sehen Sie für Definitionen bitte die Tabelle ItemStatus.
Weiterführende Dokumentation: Umsatz- und Mehrwertsteuerverteilung
Legende der Tabellen und Felder
Die Legenden werden deutschsprachig bereitgestellt.
Beispiel: Legende_Tabelle_Journal...
| ID | eindeutige Schluesselnummer |
| TransactionID | eindeutiger Index auf den Vorgang und Verlinkung zu den uebrigen Tabellen |
| Station | Stationsnummer (Kassierstation) |
| OriginalStation | Stationsnummer (Buchungsstation) |
| SysDate | Systemdatum des Rechners Format =JJJJMMTT |
| usw... |
Hypersoft Updates und deren Abgrenzung im Journal
Die meisten Hypersoft Updates werden nicht am Tag der Veröffentlichung installiert, sondern unbestimmt später. Im Buchungsjournal wird zu jeder Buchung die Versionsnummer der verwendeten Programmversion hinterlegt.
Das Programm trägt zudem bei wichtigen Updates einen Platzhalter im Journal ein und signalisiert die Umstellung der Version von Version (zum Beispiel auf die "GDPdU Version 2012"). Beim Export wird der Datensatz dann korrekt ausgeschlossen.
Beispiel: TransactionID:66170 ist die dazugehörige Transactions Nr. Hierdurch können wir das Update im Journal sogar buchungsgenau abgrenzen.
Die Hypersoft-Versionsnummer z.B. „2014 080 00“ setzt sich wie folgt zusammen.
2014 Programmversion
080 Servicepack
00 Revision
Eine Versionshistorie inkl. Changelog sowie der Zeitpunkt der Veröffentlichung kann unserer öffentlichen Dokumentationen unter: https://dokumentation.hypersoft.de/Content/Hypersoft/Neu.htm entnommen werden.
Dezimalwerte
Dezimalwerte werden unabhängig der Ländereinstellung immer mit einem Punkt gespeichert. Dies lässt sich auch nicht ändern, da XML in allen Programmen und immer als „Invariante Länderkultur“ gespeichert wird, ansonsten könnte man keine Daten mit anderen Servern austauschen.
Um das Einlesen zu vereinfachen, wird das "Schema" der Datentabellen als ".XSD" erstellt. Dies ermöglicht verarbeitenden Programmen die korrekte Interpretation der Daten. Zu jeder XML Tabelle gibt existiert eine „.XSD“ Datei ( auch Standard ) in denen die Datentypen der einzelnen Felder angegeben sind.
Zum Datum
Das Datum ist numerisch. Dies entspricht den ISO Standard 8601 „Nur numerisch, Jahr Monat Tag“.
ISO 8601 legt eine Grundstruktur zum Austausch von Datums- und auch Zeitinformationen fest, die ausschließlich aus numerischen Komponenten besteht und auf sprachspezifische Bezeichner (Wörter) verzichtet.
Für die Eindeutigkeit numerischer Datumsangaben ist die strikte Einhaltung einer vorgegebenen Form unabdingbar. Wesentliches Merkmal der in ISO 8601 festgelegten Grundstruktur ist die „absteigende“ Anordnung in der Form Jahr-Monat-Tag.
Weiterführende Dokumentation: Bereich Automatischer Berichtsexport
Zurück zur übergeordneten Seite: Journal und Export auch für AmadeusVerify