Changelog

This release introduces Notification Management Process

Affected markets: DE

Overview

In accordance with Section 146a (4) of the German Fiscal Code (AO), every electronic cash register or recording system must be reported to the responsible tax office within one month after being put into operation or taken out of operation. To support this legal requirement, we have implemented a complete Notification Management Process, including:

• Notification Management Page
• POS Operator Data pages
• Notification Worker (Azure Function)

New Features & Components

1. Notification Management Page (Dealer Portal) A new management interface is available for dealers, providing the ability to:

   <ul>
       <li>View and manage all operators under their dealership</li>
       <li>Enable or disable automatic or manual notifications for each operator</li>
       <li>Review all sent notifications along with their statuses (successful, failed, pending)</li>
       <li>Trigger notifications manually for specific operators if needed</li>
   </ul>
   

2. Operator Data Page

   A dedicated page where the operator can update all required data. The dealer sends the operator a link to this page. All necessary information for notifications is collected and validated here.

3. Notification Worker (Azure Function)

   A background worker runs every night at midnight, collecting the operator’s data and sending notifications to ERIC (third-party communication interface for German tax authorities).

Required Data for the Notification

Every notification must include:

• Operator information
• Outlet information
• Electronic recording system information
• Type of certified TSE
• Number of electronic recording systems
• Serial number of the electronic recording system
• Purchase date
• Commissioning date
• TSE information (extracted from the TseInfo JSON)

Common Issues Below is a list of frequently occurring errors and how to resolve them.

1. Invalid Tax Number Possible Causes a) The tax number does not match the scheme for the Bundesland (state) b) The company must report to another state than where it physically operates c) A regional 10–11 digit tax number is used instead of the required 13-digit number

   

2. Missing or Invalid Data: Third-Party CashRegister (TSE Serial Number)

   Error: TSE serial number must be at least 64 characters and hexadecimal (0-9, a-f, A-F)

3. Invalid TSE BSI Certification Number Required format: YYYY-NNNN

   

4. Missing Notification Product in the Outlet Problem: The outlet does not have an active notification product or carefree package.

   

5. ERIC Exception: Duplicate Serial Numbers Error: ERIC reports that the same recording system serial number is used multiple times. Cause: More than one queue shares the same Queue name. Solution: Operator → Configuration → Queues Remove duplicates: • Send “Out of Operation” receipt, or • Hide queue if it does not exist physically Then re-trigger the notification.

   

6. Missing TSE Information (TseInfoJson) Cause: No TSE data found in the last End-of-Day receipt → possible TSE connection problem. Solution: Check last End-of-Day receipt: • If TSE data exists → re-trigger notification • If not → fix the TSE connection problem or send a zero receipt to restore connection

   

7. Missing POS System Data (Model, Manufacturer) Cause: No valid POS System ID in the last End-of-Day receipt.

   

8. Invalid Date Order (PurchaseDate vs CommissioningDate) Error: Purchase date cannot be later than commissioning date.

   

9. ERIC Exception: Illegal Characters in Fields Error: Some characters in the legal company name or address are invalid.

Additional Notes

• To check if a POS System is assigned:

Operator → Related Queue → Receipt Journal

Last daily closing must show a correct POS System ID that exists in DE Dynamic

• A notification is only sent when:

✔ Notification state = true in Account Settings

✔ At least one outlet has an active notification subscription. And outlet should have at least one active queue or third party queue

✔ Operator has confirmed all required data

• Postal code and tax number both should be valid while validating the tax number ( The tax number must match the correct state (Bundesland) based on the postal code)

• We have implemented Notification_API and gradually extracting common logic from worker and portal into this API to centralize and simplify the validation and processing steps

• Notification will be send for active queues . Hidden queues or queues that became inactive before July 1st, 2025 will not receive notifications

Useful links:

• Knowledge base article on Notification Management:( you can find solutions for common error messages here) https://portal.fiskaltrust.de/KBArticle#/KA-01146/Tax%20office%20notifications:%20Solutions%20for%20error%20messages

• Correct tax identification number formats: https://de.wikipedia.org/wiki/Steuernummer

• 13-digit tax identification number converter: https://www.ueberbrueckungshilfe-unternehmen.de/DE/Infothek/Steuernummer-Umrechner/steuernummer-umrechner.html

This release introduces Subscription Management Page Improvements.

Affected markets: ALL

Subscription Page Overview

As a PosDealer, you can get an overview of all your PosOperators' subscriptions in the PosDealer / Subscriptions tab of the fiskaltrust.portal. You can filter the list to display overdue or upcoming subscriptions and renew payments for multiple subscriptions simultaneously. On this page, you can also manage subscriptions by opting for automatic renewals, performing manual renewals, or canceling a subscription.

Improved: The Subscription Management page has been enhanced to provide a clearer overview of subscriptions. Users can now easily manage subscriptions renewal and cancellations. The interface has been redesigned for better usability and accessibility.

Users can now opt for automatic renewals for their subscriptions, ensuring uninterrupted service.

Once user opt out for automatic renewals a contract shows up. After signing that contract feature will be active .

Once the renewal is enabled ,Invoicing Type will be set to automatic and all subscriptions that PosDealer has been managing will be automatically renewed upon expiration.

If PosDealer decides to opt out from automatic renewals, a contract will be presented. After signing the contract, the automatic renewal feature will be deactivated. At that time ,the Invoicing Type will be set to manual, and all subscriptions managed by the PosDealer will require manual renewal upon expiration.

PosDealer is able to set automatic renewal individually for each subscription as well.Once the individual renewal is enabled for a subscription that subscription will be renewed automaticaly upon expiration.

Renewals can be performed in bulk, allowing users to select multiple subscriptions and renew them simultaneously.

For bulk renewals and cancellations users will be able to select multiple subscriptions using checkboxes and perform actions using buttons at the bottom of the page.

For individual subscriptions, action buttons are available in end of each subscription row. Once clicked, a confirmation dialog will appear to confirm the action. Using the action buttons you can pay for the individual subscription to extend it or choose to cancel it.

If PosDealer want to manage subscription manually they can either select multiple subscriptions using checkboxes and click on "Pay Subscription" button at the bottom of the page or use the action buttons available at the end of each subscription row to pay individual subscription.

There are 2 options while paying the subscription manually.

1) Dealer Package Option, If There is no entitlement for extending the subscription PosDealer can use DealerPackage option to add required entitlements to the shopping basket.

2) Entitlement Option, If there is enough entitlement to extend the subscription PosDealer can use Entitlement option to extend then entitlements will be assigned to selected subscriptions at the shopping basket.

After selecting the desired option and clicking on Pay button user will be informed via banner notification that the selected subscriptions have been added to the shopping basket.

There will be also easy access link to shopping basket in that notification. Clicking it will redirect user to shopping basket page where user can complete the payment process.

PosDealer can proceed to checkout from shopping basket page to complete the payment process.

Cancellation

Subscriptions can be canceled either individually or in bulk. PosDealer can select multiple subscriptions using checkboxes and click on the "Cancel Subscription" button at the bottom of the page to cancel them in bulk.

For individual subscriptions, action buttons are available at the end of each subscription row to cancel them.

Once cancel subscription is clicked a confirmation dialog will appear to confirm the action.

In that dialog user will be informed about the cancellation status and the remaining validity period of the subscription. Dealer can choose wheter to inform PosOperator via Email by using the Notify PosOperator checkbox in the dialog or not.

By confirming the cancellation the selected subscriptions will be canceled and PosDealer will receive a notification indicating the cancellation status and the remaining validity period of the subscription.

If notify PosOperator option was selected in the confirmation dialog PosOperator will receive an email notification about the cancellation.

Why it matters: These improvements streamline subscription management, making it easier for users to handle their subscriptions efficiently.

Access Links:

• Sandbox: https://portal-sandbox.fiskaltrust.de/PosDealer/Subscriptions
• Production: https://portal.fiskaltrust.de/PosDealer/Subscriptions

Tax Id Validation (Syntax and Erict Checks)​

Affected markets: DE

Improved: Adding full tax id validation in Notification/company data page for Germany market. The system will now check the syntax and perform Erict checks when entering a tax id.

Why it matters: This enhancement helps ensure that tax IDs are valid and correctly formatted, reducing notification errors and improving data.

Change Portal Versioning​

Affected markets: ALL

Improved: Changing the fiskaltrust.portal versioning schema. Moved to date based versioning.

Why it matters: Moving to a new date base schema better reflects our current development and release cycle.

This release we've improved TAR-File export handling in the Queue, FiskalyCertified and SwissbitCloudV2 SCUs for the German market.

🇩🇪 Feature: Improved TAR-File Export handling in Zero Receipt (fiskaltrust/middleware#549)​

When performing a Zero-Receipt with the flag "Requests a download of the TSE-device TAR file" (0x0000_0000_0200_0000) the TAR-File export is now also attempted if the signing failed.

Affected packages:​

• fiskaltrust.Middleware.Queue.AzureTableStorage
• fiskaltrust.Middleware.Queue.SQLite
• fiskaltrust.Middleware.Queue.EF
• fiskaltrust.Middleware.Queue.MySQL

🇩🇪 Feature: Allow TAR-File deletion from SwissbitCloudV2 with open transactions (fiskaltrust/middleware#549)​

The TAR-File can now be deleted from the SwissbitCloudV2 TSE after an export even if there are open transactions on the TSE.

::: note

If the TSE refuses to sign receipts because its storage is full, sending a Zero-Receipt with the "Requests a download of the TSE-device TAR file" (0x0000_0000_0200_0000) from a Queue >= v1.3.80 fixes the issue.

:::

Affected packages:​

• fiskaltrust.Middleware.SCU.DE.SwissbitCloudV2

🇩🇪 Fix: Fiskaly TAR-File Export fails with E_TOO_MANY_REQUESTS (fiskaltrust/middleware#561)​

We've fixed an issue where TAR-File Exports from a FiskalyCertified TSE would fail with a E_TOO_MANY_REQUESTS error.
In some cases long running TAR-File Exports might take a few seconds longer due to this change.

Affected packages:​

• fiskaltrust.Middleware.Queue.AzureTableStorage
• fiskaltrust.Middleware.Queue.SQLite
• fiskaltrust.Middleware.Queue.EF
• fiskaltrust.Middleware.Queue.MySQL
• fiskaltrust.Middleware.SCU.DE.FiskalyCertified

This release includes a new feature to automatically close open transactions on a TSE in the German market.

🇩🇪 Feature: Automatically close open transactions on the TSE with the Daily-Closing (fiskaltrust/middleware#554)​

We've added a queue configuration parameter CloseOpenTSETransactionsOnDailyClosing which is set to false per default. When set to true the queue will close all open transactions on the TSE automatically with each daily closing.

Affected packages:​

• fiskaltrust.Middleware.Queue.AzureTableStorage
• fiskaltrust.Middleware.Queue.SQLite
• fiskaltrust.Middleware.Queue.EF
• fiskaltrust.Middleware.Queue.MySQL

This release includes stability improvements and fixes for the German and Italian markets, as well as the 1.3 preview for the Austrian market.

🇮🇹 Feature: Added Support for Unreferenced Refunds with Epson RT Printers (fiskaltrust/middleware#515)​

With this release, we have added support for performing unreferenced refunds with Epson RT Printer based SCUs.
This allows us to support this scenario across all currently available SCUs.

While we still recommend using referenced refunds in most cases, there are situations that require the cashier to perform unreferenced refunds (e.g., when the original receipt was lost).

Affected packages:​

• fiskaltrust.Middleware.Queue.AzureTableStorage
• fiskaltrust.Middleware.Queue.SQLite
• fiskaltrust.Middleware.Queue.EF
• fiskaltrust.Middleware.Queue.MySQL
• fiskaltrust.Middleware.SCU.IT.EpsonRTPrinter

🇩🇪 Fix: Corrected Public Key Handling for SwissbitCloudV2 SCU (fiskaltrust/middleware#503)​

We've fixed an issue where the wrong public key was displayed in the QR code for SwissbitCloudV2 SCUs.
This fix has already been rolled out to the cloudcashbox.

Affected packages:​

• fiskaltrust.Middleware.SCU.DE.SwissbitCloudV2

🇩🇪 Fix: Improved SCU Switch Stability (fiskaltrust/middleware#525)​

We've fixed a problem where the Finish-SCU-Switch receipt would fail if the old SCU was in a broken state.

Affected packages:​

• fiskaltrust.Middleware.Queue.AzureTableStorage
• fiskaltrust.Middleware.Queue.SQLite
• fiskaltrust.Middleware.Queue.EF
• fiskaltrust.Middleware.Queue.MySQL

🇩🇪 Feature: Improved DSFinV-K export​

We've improved the DSFinV-K export on multiple fronts.

• Include none VAT receipts
• Fix Bestellung-V1
• Add default values for REF_NAME
• Eliminate multiple entries allocation_groups.
• Use calculation on UMS_BRUTTO for vouchers

Affected packages:​

• fiskaltrust.Middleware.Queue.AzureTableStorage
• fiskaltrust.Middleware.Queue.SQLite
• fiskaltrust.Middleware.Queue.EF
• fiskaltrust.Middleware.Queue.MySQL

🇦🇹 Feature: Improved Startup Performance (fiskaltrust/middleware#539)​

We've improved the startup performance of the queue, specifically the performance of the first receipt processed after queue startup.

Affected packages:​

• fiskaltrust.Middleware.Queue.AzureTableStorage
• fiskaltrust.Middleware.Queue.SQLite
• fiskaltrust.Middleware.Queue.EF
• fiskaltrust.Middleware.Queue.MySQL

🇦🇹 Fix: Backup SCU Handling (fiskaltrust/middleware#483)​

We've fixed a problem with the handling of backup SCUs. Now, when a normal SCU is not available, the backup SCU is used correctly and the ftState flag 0x80 is returned when a backup SCU is used.

Affected packages:​

• fiskaltrust.Middleware.Queue.AzureTableStorage
• fiskaltrust.Middleware.Queue.SQLite
• fiskaltrust.Middleware.Queue.EF
• fiskaltrust.Middleware.Queue.MySQL

This release introduces Belgian market support and various platform enhancements.

Belgian Portal Launch​

Affected markets: 🇧🇪

Improved: Added Belgian portal functionality, now available in sandbox and production environments for testing and validation. The portal includes all features required for management of the configuration, users and connections.

Access Links:

• Sandbox: https://portal-sandbox.fiskaltrust.be
• Production: https://portal.fiskaltrust.be

Interested in the Belgian market? Contact our sales team to learn more about fiskaltrust services in Belgium.

Why it matters: Expands platform reach to the Belgian market, enabling local customers to access fiskaltrust services with proper localization and regulatory compliance.

CashBox Configuration Hidden Entity Fix​

Affected markets: ALL

Fixed: Resolved issue where hidden queues and signature creation units (SCUs) were still appearing in CashBox configuration. Hidden entities are now properly filtered out from selection lists, while previously selected hidden entities remain visible when already assigned to a CashBox.

Why it matters: Makes CashBox setup much easier as only relevant items are shown as options to choose from.

Helper Configuration Migration to React​

Affected markets: ALL

Improved: Migrated helper configuration to React implementation. The new React-based configuration supports all helper packages including balancer, REST API, POS API, helipad, and others. Enhanced cache management ensures changes made in CashBox pages are immediately visible without manual page reloads.

Why it matters: Provides a consistent, modern user experience across all configuration pages while improving performance and eliminating cache synchronization issues that previously required manual page refreshes.

[Exports] Exports stuck in pending state fix (#1011)​

Affected markets: ALL

Improved: In certain scenarios it was happening that a Export got stuck in a pending state, even though it was already finished. This change fixes this behavior and users should now only see the in progress state for exports that are still running

Why it matters: The in progress state lead to the blocking of downloads since we considered the export unfished. Fixing this issue resolves this and makes sure that users are always able to download the results in case of exports being finished.

[Exports][DE] DFKA export does export VATId even if it is invalid (#1018)​

Affected markets: DE

A fix for the DFKA export has been rolled out that handles wrongly configured VAT Numbers more gracefully. There are certain scenarios where accounts are setup with a correct TaxId, but a invalid VATId. In the past we have always included both of these numbers into the DFKA export as soon as they have been set. With this change we hande invalid VAT numbers the same way as if it would not be configured and do not include them in the export. This allows accounts that have setup a correct TaxId to correctly validate the DFKA and as a result of that transfer to MeinFiskal.

This version of the Middleware is a maintenance release. It focuses on ensuring stability, reliability, and continued compatibility. No functional changes or new features are included.