DSFinV_K, GDPdU, AmadeusVerify export
This export is used for checks and enables the output of master data (partly historical) and transaction data. The Amadeus Verify programme is often used by auditors for this purpose. Hypersoft also checks the data with the latest Amadeus Verify programme.
Further documentation: KassenSichV Export according to DSFinV-K.
For statistical purposes, you can also use Export Journal for Statistics.
You can automate the described export.
| Element / Switch | Function / Description |
|---|---|
| Export data according to DSFinV-K |
Select the desired time period and any other settings. Press the named button to export the data. The data is exported from the currently connected TSE sticks. Be aware that if you do not find the exact button described, you will probably be in a different export dialogue and receive different data. |
| TSE export |
Export only the TSE stick data (possibly for random samples). The same storage location applies as for DSFinV_K export. Details below. |
| GoBD / GDPdU Export | Export according to GDPdU for audits in Germany (standard even before the Cash Security Ordinance). |
| Data acquisition protocol acc. to. Export RKSV (AT) | This button is only displayed if corresponding AT signature data is available. The button generates the so-called DEP for Austria in the format required by the Austrian tax office. The export takes place in the specified storage location in the folder HS-EXPORT-DEP. Further documentation: Fiscal Law in Austria RKSV |
| Opening day or period | Select the opening day or the exact time period. Consider overlaps if your business is open after 0:00. |
| Annual files (not DSFinV_K) |
Exports annual files. During the export, information about the currently read information appears in the right text field. |
| Monthly data series (not DSFinV_K) | Exports monthly files. During the export, information about the currently read information appears in the right text field. |
| Without division |
The alternative without splitting allows the export to be summarised in one file. |
| Per final day (DSFinV_K only) |
This selection corresponds to DSFinV_K: Individual files are generated per closing day. This immediately saves the data per closing day. This makes it possible to save periods of time of any size without having to consider file size limits. |
| filing location |
The file name of the export is determined by the client / time period, so only the storage location can be specified. HS-EXPORT Depending on the export variant, this contains one or more folders (per date range / months / years). The name of an export file is: Client # fromdate to date to time Example: MANDANT_1_20120101_60000-20120201_55959.XML Or if the export takes place via the Open day option, without times. Example: MANDANT_1_20120120101-20120131.XML Directory structure... The TAR order is separated from the DSFinV-K data, as AmadeusVerify searches for export data in this folder. If you have a Hypersoft TSE Online Archive licence, the TAR archives are separated into monthly archives. Only the archives matching the export are then exported. For technical reasons, a few signatures may still be in the archive from the previous month. So that these can be checked if necessary, they are now also stored in the TAR-VOR-EXPORTBEREICH folder and can be read in if required.
The folder contains the files required by the tax office and the complete description is contained in the "index.xml" file. The folder can be transferred directly to the tax office or compressed with pkzip / winzip etc. in zip format. Both are accepted by the tax office. The tax number from the master information is entered in the export. You must therefore ensure that the master data is correct. |
| Export tips (AN) as... |
Please select the treatment of tips for export.
|
| Export deposit as... |
Please select the treatment of deposits for export.
|
| Export payout as... |
Please select the handling of payouts for export.
|
One request is sent per TSE, these can be seen in the status window above. The requirements are also in the field Requested.
If a TSE is in operation, the status is set to in progress. Depending on the running time of the stick, the export can take several minutes (up to hours). Meanwhile, there is a flashing indication that the system is waiting for "feedback". After a successful export or an error, these are displayed in the field Finished or Error, depending on the case. If a system is not accessible (switched off), the request stops. This can then be voided with the button Reset, as the button Show files only becomes active when all requests have been processed. Clicking the button Show Files opens a Windows dialogue with the files. This is made available in the folder "X:\Hypers-!\ETC\CLNTxxxx\TSEEXPORT" ( The X stands for server drive or xxxx the client number).
Currently no manual DELETE FUNCTION integrated, as there is no workflow for saving the manually exported files (please wait for archive solutions).
When exporting the TAR files manually via the journal export, they are automatically stored where the export would export them if necessary.
When exporting, an additional file is also output, which allows changes in the settings and entries of important master data to be tracked (Note: Changes in the item master can be output directly from the item master).
The change history is exported as changelog.csv because there is no official format.
The history contained information on creation or modification in the following areas:
- outlet names
- Employee Name, First Name, Birthday, Authorization Template
- Approx. 40 of the relevant settings from the operator authorizations
-
Station names, station numbers, authorization group / station
- Number ranges ( invoices etc.) )
- Price levels, reasons for loss, reasons for voids
- categories
Further information (obsolete for IDEA import, as already described)
The export type Journal complete incl. master data creates an XML output file containing 22 tables.
The export checks the database for manipulations (such as the program status booking journal). The hash code check takes a very long time, especially with large amounts of data.
A log file is then created. The content lists the status of the pre-recording (function removed since 2016) and checksum errors in the hash code. If no errors occur and no pre-recording (function removed since 2016) was activated in the export period, this is also displayed.
The Journal and Payment tables contain the posting data and payment data. The contents of the other tables are master data. The name of the table corresponds to the name of the column in Journal / Payment.
| TrainingJournal | Course bookings (empty if no course bookings exist). |
| Payment status | Status of the payment (disbursement, tip, etc.) |
| ItemStatus | is documented separately |
| ItemStatusDetail | Additional information on the ItemStatus |
| CurrencyID | Currencies used |
| PayType | Type of payment (cash, credit, etc.) ) |
| EmpID | staff |
| station | stages |
| StockID | points of sale |
| CancelMode | Void variants |
| DiscountType | Discount variants (item, transaction, etc.) ) |
| UnitType | Types for unit sales (time, weight, volume, etc.) ) |
| PrintFormNo | Forms ( invoice printing ) |
| CancelReason | Void reasons |
| PriceLevel | price levels |
| LossID | reasons for loss |
| HGR/WGR/UGR | Main groups / Commodity groups / Subgroups |
| SHIFT/SHIFT2 | shifts |
| RefStatus |
Reopening status: 0 normal transaction, 1 credit, 2 credit. |
If there is a negative number of bookings with cancelmode zero, these are automatically created offsetting entries of transactions that were reopened after billing. The reversal document is also created for this (if an invoice was previously created). The postings and the original transaction remain unchanged. The original transaction is copied and the item postings are marked with a negative sign. The void mode remains zero, since these are counter postings. At the same time, the original transaction is copied a second time, but as a new open transaction that contains the postings in positive numbers. The item posting exists three times, the old positive and negative offsetting entry, as well as the new positive posting. In practice, there are different reasons for the function, such as a subsequent request to split the bill. One of the usual reasons for this procedure is the presentation of an invoice that has been requested by the customer without further information and for which the customer then wants a cashless payment unprepared. If an EC terminal with an accounting interface and a cashless tip is used, such counter entries are created for the original invoice. CancelMode 10: "Cancellation before order and "CancelMode 11: "Void after order".
For RefStatus: When a completed activity is reopened, offsetting entries are created so that the activity can be offered for safe postprocessing. To be able to differentiate these natural postings with a negative number from voids during checks, consider the RefStatus field accordingly. For the export, the originally positive posting in the RefStatusfield receives the value 2 (credited transaction). The offsetting entry with a negative number receives the RefStatus value 1 (credit memo).
Display in payment: Items are displayed in payment when the transaction is completed. This can be a payment (standard) or, for example, a transfer to a customer account (payment with subsequent system), a transfer to a hotel system (for later payment at Hotel Check Out in the PMS successor system) or, for example, conclusion as an invitation (a completed process as an invitation has the payment amount 0.0). Depending on your settings, day-end closing with open transactions is not executed or remaining open transactions are settled automatically.
Changeover of the void system
The void system was adapted with the SP 5.
It was valid until version SP 5...
If there are bookings within the journal with negative item quantities and the void mode zero, these are automatically created counter entries of transactions, which were reopened after invoicing. A reversal document is created for these offsetting entries. However, the postings for the original transaction remain unchanged. The original transaction is copied and the individual item postings are given a negative sign. The void mode remains zero, since these are counter postings. At the same time, the original transaction is copied a second time, but as a new open transaction that contains the postings in positive numbers.
The item posting exists three times, the old positive and negative offsetting entry, as well as the new positive posting. In practice, there are different reasons for the function, such as a subsequent request to split the bill. One of the usual reasons for this procedure is the presentation of an invoice that has been requested by the customer without further information and for which the customer then wants a cashless payment unprepared. If an EC terminal with an accounting interface and a cashless tip is used, such counter entries are created for the original invoice.
From version SP 5...
In order to be able to subsequently deduce with the help of the journal which circumstances caused a voids by the respective operator, the POS system records the so-called void mode for each void according to the following table. Depending on which function or system component was used to create a reversal, the void mode can be used to determine the origin of the reversal. The following void modes are planned:
Using the void mode, voids entered in the journal can also be assigned to the situation in which they were generated.
- Voids with cancelmode IDs from 0-99 were performed during regular checkout operation.
- Reversals with Cancelmode IDs from 100-199 were carried out using the Change payment type function.
- Voids with Cancelmode IDs of 200-299 were performed using the ReOpen function (reopening of operations).
Here it is useful to understand that there is a systematic relationship between the ID numbers. Each ID number below 100 has a comparable counterpart in the number ranges between 100 -199 and 200 - 299.
Further documentation: Special price and loss treatment
Calculate daily turnover from all data records that contain a value greater than "0" in Vat-Tab.
All entries in Journal.csv with "VatTab = 0" are also not relevant for sales.
The daily turnover can be found in Journal.csv.
Calculate for each opening day (Opendate) Quant * Price
The following numbers in the item status are not sales-relevant.
1,3,5,7 = Training bookings from previous program versions. (Until Hypersoft Suite 2012 (SP 60) of 18.05.2011)
9 = from conversion of old reopened data. (Until Hypersoft Suite 2012 (SP 60) of 18.05.2011)
10 = Sale of a turnover-neutral value voucher (also web voucher)
11 = item voucher
12 = Bonus voucher
30,31 = VAT distribution Additional info, the turnover-relevant record then has the 31 (see also 80 81).
36 = Sales distribution Additional info, the sales-relevant data record then has item status 31, combination of sales mix and sales distribution (possible with data from Hypersoft Suite 2017 (SP 1) of 07.11.2017).
60,61 = Turnover distribution additional info (see also 80 81).
80, 81 = From HF 11 for SP 11 2020 get the records for VAT. distribution no longer the item status 30 and 31 and for the turnover distribution 60 and 61, but everything at the same time with 80 and 81. This also allows a combination of VAT. Distribution and merchandise group distribution can be evaluated.
90, 92 = Internal postings without sales. (Special function for advance ticket sales)
The ItemStatus table
The Hypersoft Journal can contain additional information to a booking in other bookings. Therefore, it is important to include the ItemStatus column in the journal. The columns Number / Turnover and Value added tax control the respective evaluation of the data.
- Posting records with ItemStatus with the value "1" in Item Count are used to calculate item quantities.
- Posting records with ItemStatus with the value "1" in Sales are used to calculate sales.
- Posting records with ItemStatus with the value "1" in VAT are used to calculate the VAT. Used.
Example of a "Salesmix" (items containing more than one tax level, food+beverages in a menu outside the house):
The booked item receives the ItemStatus 30 ( SalesMix_Master ) with the complete sales price. The Hypersoft system now generates an additional posting record with item status 31 ( Salesmix_Slave ) for each control level. These data records are identical to the previous data record, but only show the sum of the respective tax rate as the price. Therefore, ItemStatus 30 is used to calculate quantities and sales, but not to calculate the tax, as the item contains more than one tax rate. The system then evaluates the appropriate postings with status 31.
- Status 30: 1 * Menu ( outside ) 3,50 Euro
- Status 31: 1 * menu ( outside ) 2,00 Euro ( turnover for 19% tax share, drink )
- Status 31: 1 * Menu ( outside ) 1,50 Euro ( turnover for 7% tax share, food )
The ItemStatus 70 concerns "Void before Order", no item booking, no turnover, no VAT.
Sales distribution of merchandise categories for an item
Instead of VAT several merchandise categories can be addressed for one item.
The field NH_ProzValue is used to store the sales distribution percentages. For definitions, please see the ItemStatus table.
Further documentation: Splitting of turnover and value added tax
The legends are provided in German.
Example: Legend_Table_Journal...
| ID | unique key number |
| TransactionID | unique index to the process and link to the other tables |
| station | Station number (cashier station) |
| OriginalStation | Station number (booking station) |
| SysDate | System date of the computer Format =YYYYMMDTT |
| etc... |
Hypersoft updates and their delimitation in the journal
Most Hypersoft updates are not installed on the day of release, but indefinitely later. The version number of the program version used is stored for each posting in the posting journal.
The program also enters a placeholder in the journal for important updates and signals the conversion of the version from version (for example to the "GDPdU Version 2012"). The data record is then correctly excluded during export.
Example: TransactionID:66170 is the corresponding transaction number. This even allows us to delimit the update in the journal to the exact booking.
The Hypersoft version number e.g. "2014 080 00" is composed as follows.
2014 Program version
080 Service pack
00 Revision
A version history including changelog and the time of release can be found in our public documentation at: https://dokumentation.hypersoft.de/Content/Hypersoft/Neu.htm.
decimal values
Decimal values are always stored with a dot, regardless of the country setting. This cannot be changed either, because XML is stored in all programs and always as "invariant country culture", otherwise you could not exchange data with other servers.
To simplify reading, the "schema" of the data tables is created as ".XSD". This enables processing programs to interpret the data correctly. For each XML table there exists a ".XSD" file ( also standard ) in which the data types of the individual fields are specified.
To date
The date is numeric. This corresponds to ISO Standard 8601 "Numeric only, year month day".
ISO 8601 defines a basic structure for the exchange of date and time information which consists exclusively of numerical components and does not include language-specific identifiers (words).
Strict adherence to a given form is indispensable for the uniqueness of numerical dates. An essential feature of the basic structure defined in ISO 8601 is the "descending" arrangement in the form year-month-day.
Further documentation: Automatic report export area
Back to the parent page: Journal and export also for AmadeusVerify