September 30, 2020
This release of the Middleware includes the stabilized version of the DSFinV-K export and automatically archives the TSE's .tar files on daily closing receipts.
After publishing a preview version of our local DSFinV-K export in version 1.3.6, we're happy to announce that this feature now leaves the preview state and is fully available as a stabilized, final functionality. We'd like to thank everyone who sent us their highly-valued feedback so far!
This version is required for POSOperators that use the free Middleware only (without any add-ons like the revision-safe cloud storage) to be compliant to the tax authorities' regulations. The cloud-version of our DSFinV-K export (which can be queried via the Portal and is included in our POS Archive) is of course up-to-date as well.
The ftJournalType for getting a DSFinV-K export is
0x4445000000000002, the returned file is a .zip stream. More details about how to access this endpoint can be found in our docs.
Starting with this version, we automatically export the TSE .tar files - which include transaction, audit and system logs - and store them in the Queue's database. The functionality to export TAR files is required in the BSI's Secure Element API (TR-03151), and thus standardized. Auditors may require these .tar files, hence we want to make them available as easy as possible.
Exporting and storing this in the Queue's database has several advantages:
- Depending on the TSE, .tar file exports may take a lot of time, especially when the storage gets full. Exporting and deleting this from the TSE regularly therefore greatly enhances the performance in case it needs to be accessed quickly.
- Similarly, many TSEs tend to get slow over time due to their low memory size. Exporting and deleting the data from the device obviously also resolves this issue.
- Customers who use our POS Archive profit from our regular revision-safe storage mechanisms and can download an aggregated .tar export directly via the Portal. Therefore, the data is still available to them, even if the TSE e.g. is damaged or lost.
We ensure to not delete TSE data that was not properly exported by combining the internal security mechanisms of the TSEs with additional, software-based checks. Only data that was exported to the queue is deleted from the device.
There are two options to trigger a .tar file export:
- Via a daily-closing receipt (automatically). To prevent this, please add the receipt case flag
- Via a zero receipt (optionally). To execute this, please add the receipt case flag
To solve some special cases of customers with unusually slow TSEs, we made two SCU communication parameters configurable:
scu-timeout-ms: Determines the timeout value of the Queue to SCU communication, in ms. Default is 70 seconds.
scu-max-retries: The maximum number of retries in case an SCU operation fails with an unexpected exception. Default is 2.
Both these values can be set via the Queue configuration page in the Portal - just add the Key-Value pairs there. A rebuild of the affected Cashbox is required to propagate these changes to the Middleware.
We fixed two small, but important issues in the Diebold Nixdorf and the CryptoVision SCUs:
- CryptoVision: Instead of the correct logTimeFormat, this SCU returned
- Diebold Nixdorf: The serial number was returned as a Base64-encoded string instead of the required Octet string.
Both issues are now resolved.
Some customers with rapidly growing queues (mostly in test scenarios) reported that the Queue data was not properly uploaded to our POS Archive sometimes. The log often showed timeout errors in this case. This issue was due to a wrongly set default upload limit for requests and is now resolved. As designed, large queues are now uploaded in chunks.
Existing configurations with versions greater than 1.3.1 continue to work, but we strongly recommend users to update to be able to use this new, required functionality.
As always, updates can be rolled out by selecting the new version in the fiskaltrust.Portal and re-building the configuration. The updated Middleware instances will then automatically pull the new packages at the next startup.
Packages not listed here were not updated, as we decided to not increase the version of unchanged packages. All packages with versions greater or equal to 1.3.1 are compatible with each other (it is e.g. possible to use fiskaltrust.Middleware.SCU.Swissbit.1.3.1 with the new queue packages).
- fiskaltrust.Middleware.Queue.EF v1.3.8
- fiskaltrust.Middleware.Queue.SQLite v1.3.8
- fiskaltrust.Middleware.Queue.MySQL v1.3.8-rc2
- fiskaltrust.Middleware.SCU.DE.CryptoVision v1.3.8
- fiskaltrust.Middleware.SCU.DE.DieboldNixdorf v1.3.8
We will continue to improve the stability of our Middleware in the next sprints. As always, we're happy to hear feedback and suggestions via firstname.lastname@example.org or directly via issues in our GitHub repositories.