Frequently asked questions in Germany

FAQs in English

The receipt must contain three date/time pairs, in cases of long-lasting sales preparation processes even four:

Date and time of receipt issuance/creation (DE: Datum der Belegausstellung)
Date and time of the start transaction (DE: Zeitpunkt des Vorgangbeginns)
End date and time of the transaction (DE: Zeitpunkt der Vorgangsbeendigung)
In the special case of long-lasting sales preparation processes (DE: lang anhaltende verkaufsvorbereitende Vorgänge): Start date and time of the first transaction (order); (DE: Startzeitpunkt der ersten Transaktion „Bestellung“)

The time of the receipt creation can be transmitted in the receipt request by using the field ReceiptRequest.cbReceiptMoment. It must be provided in UTC.

For a receipt request of type pos-receipt, fiskaltrust.Middleware returns three dates in the signature block that can be used for printing the receipt:

Time of the start transaction as provided by the TSE (ftSignatureType: 0x4445000000000019).
Time of the finish transaction as provided by the TSE (ftSignatureType: 0x444500000000001A).
Calculated start time of the Start date and time of the first transaction (order) = the minimum of the date/time pairs (ReceiptRequest.cbReceiptMoment,ftChargeItem[i].Moment, ftPayItem[i].Moment) sent to fiskaltrust.Middleware in the pos-receipt request. The entry has the signature type: ftSignatureType: 0x444500000000001F.

Depending on your use case you have to decide which of the returned date and times you have to print. For example, in normal cases (no long-lasting sales preparation process) you may print the calculated start time of the transaction (ftSignatureType: 0x444500000000001F) as the start time of the transaction (DE: Zeitpunkt des Vorgangbeginns) on your receipt.

On the other hand, if your use case includes long-lasting sales preparation process - assuming that you sent the first ordered charge item having the datetime (ftChargeItem.Moment) of that order - you may want to use the calculated start time of the transaction (ftSignatureType: 0x444500000000001F) as the start time of the first sales preparation (DE: Startzeitpunkt der ersten verkaufsvorbereitenden Vorgangs). Furthermore, you may use the returned time of the start transaction (ftSignatureType: 0x4445000000000019) as the start time of the transaction (DE: Zeitpunkt des Vorgangbeginns).

You can find start time examples here.

Type of data

Client-related data (= name, address, contact data, UID number, orders, etc. from cash register manufacturers, cash register dealers, cash register operators)
Configuration and status data (= TSE certificate, ClientId, status of the queue, etc.)
Mass data (= ReceiptRequest, ReceiptResponse)
Revision-secured client-related mass data (= .Tar-File, DSFinV-K-File, etc.)
General customer-related bulk data (= copy of everything that is manually stored in revision-secured customer-related bulk data, invoices, contracts, etc.)

Based on the legal situation, no personal data must be stored. The cash register manufacturer decides which data is disclosed during registration in the portal and on the cash register receipts (bulk data).

If a cash register manufacturer registers in the portal, for example, then it could also use anonymised data. Please note that you do not print names or the like on the receipt data, for example, if you want to prevent the disclosure of personal data. In practice, it will probably hardly be possible to prevent the use of personal data, but the law does not provide for any necessity here.

Processing locations

Azure Region West-Europe (a104, a105)
Azure-Region Germany-West-Central (a110, a111)
Azure-Region France-Central (a107, a108)
Equinix-Datacenter Amsterdam (nl18) (https://www.equinix.com/locations/europe-colocation/netherlands-colocation/amsterdam-data-centers/)
RRZ-Datacenter Raaba / Graz (at11) (https://www.rrz.co.at/)

Storage locations

SQL Azure West-Europe -> Mirror ( Azure North-Europe, Azure Germany-West-Central, Azure France-Central)
Dynamics365 EMEA Region (=crm4)
Massendaten Azure West-Europe -> Mirror Azure North-Europe
Kundenbezogene Massendaten Deutschland Azure Germany-West-Central

Processing

General workloads are processed in West-Europe.
CPU-intensive workloads are processed in North-Europe and at11.
Customer-related data is managed exclusively in a separate Dynamics365 instance per country.
All services ending with "fiskaltrust.de" are processed with Azure Germany-West-Central (Microsoft Azure in Germany).
Customer-related mass data for configurations created with services ending in "fiskaltrust.de" are stored in Azure Germany-West-Central.

How the data is stored

The data is stored in the form in which it is sent to the middleware in accordance with the legal requirements.

How long is the data stored

The data is stored at least in accordance with the statutory retention periods (currently at least 10 years), or the storage period is extended if other procedures are pending.

Depending on the communication type and the language you are using, you have different options about how to retrieve more detailed error messages. We recommend the following steps:

Inspect the request result

HTTP & SOAP

When using HTTP/REST or WCF/SOAP, the error message of the request should already contain useful information, like e.g. in the following screenshot:

Since the error message is returned as HTML document, it can be helpful to test a failing request via Postman (which supports the rendering results).

gRPC

If an error occurs in a gRPC request, the Middleware returns detailed information (like the error message, error details, and even the stacktrace) in the gRPC trailer metadata.

How this metadata can be read strongly depends on the platform/programming language you are using.

For example, in C# the metadata can be read like this:

try 
{
    await pos.SignAsync(nonWorkingRequest);
}
catch (RpcException ex)
{
    foreach (var entry in ex.Trailers)
    {
        // Metadata is structured in key/value pairs
        Console.Error.WriteLine($"[{entry.Key}] {entry.Value}");
    }
}

// Example output:
// [exception-message] The XYZ cloud TSE could not connect to the internet; a timeout occured
// [exception-type] TseSpecificClientError
// [origin] fiskaltrust.Middleware.SCU.DE.SomeTse, Version=1.3.1.0
// ....

Change the logging verbosity

By default, the fiskaltrust Launcher logs only messages on informational level and above. To easily enable debug logging (and optionally include logging to an output file as well), use the following parameters:

fiskaltrust.exe -cashboxid=XYZ -accesstoken=XYZ -verbosity=Debug -logfile=myfile.log

This will, among many other messages, enable logging the following information:

In- and outgoing requests of gRPC requests, including their content (in JSON)
TSE lifecycle events and timing information (e.g. when a self test is executed)

Please do not use debug logging in production scenarios, as it might significantly impact the performance of the Middleware.

Fiskaltrust is NOT a technical security unit (TSE). Fiskaltrust offers a free of charge fiscalization middleware that is able to communicate with any officially certified TSE. Therefore fiskaltrust is not certified according to BSI TR-03153, but the supported TSEs such as Swissbit, Cryptovision, Diebold, Epson TSE are officially certified by the german Federal Office for Information Security (BSI).

We offer a test system called sandbox. The sandbox is fully functional just like our live system. Depending on the country, it can be reached via the following URL:

Germany: https://portal-sandbox.fiskaltrust.de

In the sandbox portal you can register your company just like you would in our live system. The difference is: It’s only for trying out the functions of the fiskaltrust.Portal and fiskaltrust.Middleware without any legal obligations.

In the portal you can configure a cashbox for testing. When you start it on your local machine, it will show you that it operates in sandbox mode:

(Cashbox started in sandbox mode")

Here you can find a JS/jQuery example calling the REST Web Service.

The obligation to issue receipts to the customer (§ 146a Abs. 2 AO) is a legal requirement that must be fulfilled by the POS system itself.

The process of printing and handing out receipts is not part of the fiskaltrust compliance. We assume that once the order is being processed and the receipt is sent to fiskaltrust.Middleware, the receipt is being handed out as required. Therefore there is no requirement to log that issue into our journal by the fiskaltrust.Middleware.

We recommend trying to reprint, once the POS service is available again.

Question

Was versteht man unter „zu Analysezwecken“?

Question

Wozu werden Daten auch über die Vertragsdauer hinaus gespeichert?

Question

Welche Dritte bzw. Partner sollen Zugriff auf Daten bekommen?

Question

Welche Daten werden verarbeitet?

Question

Wo werden die Daten verarbeitet?

Question

Wo werden die Daten gespeichert?

Metadata tags

lang-de, market-de, middleware, PosCreator, PosDealer

Rechte und Pflichten der Parteien laut Nutzungsvertrag

Hintergrund

Kassenhändler haben sich vermehrt mit der Frage an uns uns gewandt, wie der dritte Paragraph im Nutzungsvertrag zu verstehen ist: Der Betreiber erklärt sich damit einverstanden, dass sämtliche Daten (Auftragsdaten und Massendaten) zu Analysezwecken verarbeitet und gespeichert werden dürfen, auch über die Vertragsdauer hinaus. Des Weiteren erklärt sich der Betreiber damit einverstanden, dass seine Daten, egal welcher Art, an Dritte bzw. Partner von fiskaltrust weitergegeben werden dürfen, sofern es für die Erfüllung der versprochenen Leistungen notwendig ist.

Querverweise

Im Rahmen der Erstanmeldung beim Portal der fiskaltrust gmbh ist ein Nutzungsvertrag zu unterzeichnen. Dieser ist bei der zweiten E-mail an eingeladene KassenBetreiber:

als Anhang beigefügt
sowie in deren Text hinterlegt bei "Der Inhalt des zugrunde liegenden Vertrags kann unter diesem Link abgerufen werden."

KassenBetreiber, welche den Nutzungsvertrag unterzeichnet haben, finden diesen im Portal wieder unter Firma → Übersicht.

Die Fragen nach "Welche Daten ... " und Wo werden ..." finden Sie beantwortet in den FAQ unter An welchem Speicherort werden die Daten ... archiviert?

Erläuterung „zu Analysezwecken“:

fiskaltrust gmbh führt unterschiedlichste Arten von Analysen durch, die aufgrund ihrer Diversität nicht vollständig aufgezählt werden können. Hier eine beispielhafte Aufzählung:

fiskaltrust gmbh führt zum Beispiel Analysen zur Ermittlung der benötigten Speicherkapazität durch. Dies ist einerseits notwendig, um genügend Speicherkapazität für alle eingehenden Belegdaten sicherzustellen und andererseits ist es wichtig für die Ermittlung der internen Kostenstruktur.
Ein weiteres Beispiel wäre die Durchführung einer Analyse der in Umlauf gebrachten Produkte, ob cloud- oder hardwarebasierend bzw. welches Herstellers. Die Ergebnisse aus dieser Analyse dienen dazu, die Verfügbarkeit der benötigten Produkte bei unserem Distributor sicherzustellen.
Letztes Beispiel sind Analysen von eingehenden Supportanfragen. Werden z.B. häufig Supportanfrage der gleichen Art gestellt, dann wird fiskaltust Verbesserungskonzepte ausarbeiten, es muss eventuell die vorhandene Dokumentation genauer ausformuliert, es müssen neue Anwendungen im Portal zur Verfügung gestellt oder der Rolloutprozess muss vereinfacht werden, usw.

Sie können anhand dieser beispielhaften Aufzählung die Vielfältigkeit der unterschiedlichen Analysen erkennen.

Erläuterung „über die Vertragsdauer hinaus"

Wenn der Vertrag mit der fiskaltrust gmbh gekündigt wird bzw. die vertragliche Grundlage wegfällt, kann die fiskaltrust gmbh, abhängig vom jeweiligen Produkt, aufgrund von gesetzlichen Bestimmungen dazu verpflichtet sein, die Daten über die Vertragsdauer hinaus zu speichern. Die Datenspeicherung ist eine Verpflichtung, die aus dem jeweiligen Produkt in Verbindung mit den gesetzlichen Verpflichtungen resultiert.

Wer sind „Dritte bzw. Partner“ von fiskaltrust gmbh?

Um dem KassenBetreiber ein Komplettpaket anbieten zu können arbeitet fiskaltrust gmbh mit Dritten und Partnern zusammen:

fiskaltrust gmbh stellt zum Beispiel die TSE (Technische Sicherheitseinrichtung) nicht selbst her, sondern kauft sie von diversen Anbietern zu. Diese liefern cloud- und hardwarebasierende TSE. Damit kann die fiskaltrust gmbh Lösungen für die unterschiedlichsten Kassensysteme anbieten und dem KassenBetreiber eine gesetzeskonforme Umsetzung ermöglichen.
Weiters bedient sich fiskaltrust gmbh eines Distributors, um die bestellte Hardware zuverlässig und zeitnah dem KassenBetreiber zukommen zu lassen.

Eine Liste der bestehenden Subunternehmer von fiskaltrust gmbh kann jederzeit angefordert werden. Sie finden diese im Portal unter Werkzeuge → Download.

Beabsichtigt die fiskaltrust gmbh einen neuen Subunternehmer als Partner heranzuziehen, werden sämtliche Kunden einerseits über unser Portal und andererseits per Mail an die vom KassenBetreiber genannte Kontaktadresse darüber informiert. Ist der Kunde mit der Zusammenarbeit zwischen der fiskaltrust gmbh und dem neuen Subunternehmer nicht einverstanden, kann er der beabsichtigten Kooperation widersprechen. In diesem Fall wird versucht, gemeinsam eine Lösung zu finden, die für alle Beteiligten zufriedenstellend ist.

Question

What is meant by "for analysis purposes"?

Question

What is the purpose of storing data beyond the contract period?

Question

Which third parties or partners should have access to data?

Question

What data is processed?

Question

Where is the data processed?

Question

Where is the data stored?

Metadata tags

lang-en, market-de, middleware, PosCreator, PosDealer

Rights and obligations of the parties according to the user agreement

Background

Cash dealers have increasingly approached us with the question of how to understand the third paragraph in the user agreement: Der Betreiber erklärt sich damit einverstanden, dass sämtliche Daten (Auftragsdaten und Massendaten) zu Analysezwecken verarbeitet und gespeichert werden dürfen, auch über die Vertragsdauer hinaus. Des Weiteren erklärt sich der Betreiber damit einverstanden, dass seine Daten, egal welcher Art, an Dritte bzw. Partner von fiskaltrust weitergegeben werden dürfen, sofern es für die Erfüllung der versprochenen Leistungen notwendig ist.

Cross-references

As part of the initial registration with the portal of fiskaltrust gmbh, a user agreement must be signed. This contract is attached to the second e-mail sent to the invited cash register operators

as an attachment
as well as deposited in their text at "Der Inhalt des zugrunde liegenden Vertrags kann unter diesem Link abgerufen werden."

Cash register operators who have signed the user contract can find it again in the portal under Company → Overview.

The questions for "What data ... " and "Where are ..." can be found answered in the FAQ under Where does fiskaltrust store which data?

Explanation "for analysis purposes":

fiskaltrust gmbh performs a wide variety of analyses, which cannot be listed completely due to their diversity. Here is an exemplary list:

fiskaltrust gmbh, for example, performs analyses to determine the required storage capacity. On the one hand, this is necessary to ensure sufficient storage capacity for all incoming document data and, on the other hand, it is important for determining the internal cost structure.
Another example would be to perform an analysis of the products in circulation, whether cloud-based or hardware-based or which manufacturer. The results from this analysis are used to ensure the availability of the required products at our distributor.
Last example is analysis of incoming support requests. If, for example, support requests of the same type are received frequently, then fiskaltust will work out improvement concepts, the existing documentation may need to be formulated more precisely, new applications may need to be made available in the portal, or the rollout process may need to be simplified, etc.

You can see the diversity of the different analyses from this exemplary list.

Explanation "beyond the term of the contract".

If the contract with fiskaltrust gmbh is terminated or the contractual basis ceases to exist, fiskaltrust gmbh may be obliged, depending on the respective product, to store the data beyond the contract period due to legal requirements. The data storage is an obligation resulting from the respective product in connection with the legal obligations.

Who are "third parties or partners" of fiskaltrust gmbh?

In order to offer the cash register operator a complete package, fiskaltrust gmbh works together with third parties and partners:

For example, fiskaltrust gmbh does not manufacture the TSE (Technical Security Equipment) itself, but purchases it from various providers. These deliver cloud- and hardware-based TSE. This enables fiskaltrust gmbh to offer solutions for a wide variety of cash register systems and to enable cash register operators to implement them in compliance with the law.
Furthermore, fiskaltrust gmbh uses a distributor to deliver the ordered hardware reliably and promptly to the cash register operator.

A list of the existing subcontractors of fiskaltrust gmbh can be requested at any time. You can find it in the portal under Tools → Download.

If fiskaltrust gmbh intends to use a new subcontractor as a partner, all customers will be informed about this on the one hand via our portal and on the other hand by mail to the contact address given by the cash register operator. If the customer does not agree with the cooperation between fiskaltrust gmbh and the new subcontractor, he can object to the intended cooperation. In this case, an attempt will be made to find a solution together that is satisfactory for all parties involved.

This special VAT Rate IDs to be used in the DSFinV-K export for the range > 1000 can be adderessed in the carge items by using a ftChargeItemCase that is intended for an "unknown vat":

0x4445000000000007- undefined type of service for DE unknown vat
0x4445000000000017- delivery unknown vat
0x444500000000001F- other services unknown vat
0x444500000000001F- returnable vat unknown
0x444500000000002F- returnable reverse vat unknown
0x4445000000000037- discount unknown vat
0x444500000000003F- extra charge unknown vat
0x4445000000000047- unreal grant unknown vat
0x4445000000000057- tip to owner unknown vat
0x4445000000000067- coupon sales unknown vat
0x444500000000006F- coupon redeem unknown vat
0x4445000000000077- receivable creation unknown vat
0x444500000000007F- receivable reduction unknown vat
0x4445000000000087- down payment creation unknown vat
0x444500000000008F- down payment reduction unknown vat

Additionally the field chargeItem.VATRate must be set to the value of the special VAT Rate to be used. For example:

"cbChargeItems":[
   {
      "VATRate":14.25,
      "ftChargeItemCase":4919338167972134943
   }
]

If you set the field chargeItem.VATRate to 0.0, than the ft.Middleware will map to the DSFinV-k VAT ID 7. For any other value the ft.Middleware will map to a DSFinV-k VAT ID > 1000 by multiplying the given chargeItem.VATRate value with 100 and adding 1000. In our example above this will result into the DSFinV-k VAT ID = (14.25 * 100) + 1000 = 2425.

If the TSE (and therefore the Middleware) infrequently takes higher amounts time for processing requests, or some requests are infrequently processed by the TSE at all, it might be connected to the USB power saving mode. This should not be confused with the regular Windows power saving mode (which should also be disabled in case of errors), and can be set in the Windows Device Manager.

Open the Device Manager
Identify the USB device that represents the TSE, and also the USB controllers, card readers, and all other devices that might be involved
Open the Properties of these devices, check if there's a Power Management tab (German: Energieverwaltung)
Disable the checkbox left to 'Allow the computer to turn off this device to save power' (German: 'Computer kann das Gerät ausschalten, um Energie zu sparen')
Either plug the device out and in again, or restart the machine

We have observed the following TSE-specific behaviors that could be connected to this issue:

Swissbit Hardware TSE: After a few minutes of idle time, the first request to the Middleware takes very long (up to 30 seconds)
CryptoVision/Bundesdruckerei Hardware TSE: The Middleware fails on processing requests and e.g. prints one of the following error messages to the log:
- Response headers didn´t match.
- Expected <QWRWYW5jRUQgU2VDdVJlIFNEL01NQyBDQXJkAQ==>, but instead got <AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==>

It's also possible to deactivate this power saving mode via Powershell, as described e.g. in this Technet thread.

Executing templates can be easily automated via our HTTP API, which should be supported in all common scripting and programming languages. All you need is the template as a string (e.g. read from a file), your account ID, and your access token. Both are displayed in the fiskaltrust.Portal.

The request should look like this:

Method: POST
Headers:
- accountid: <your-account-id>
- accesstoken: <your-access-token>
Body: JSON template
URLs:
- Sandbox: https://helipad-sandbox.fiskaltrust.cloud/api/configuration
- Production: https://helipad.fiskaltrust.cloud/api/configuration

The following example illustrates how a template can be sent to our API:

$headers = @{ accountid = "your-account-id" ; accesstoken = "your-access-token" }
$uri = "https://helipad-sandbox.fiskaltrust.cloud/api/Configuration"
# Read from template.json and escape JSON string
$template = (Get-Content .\template.json -Raw).Replace('\', '\\').Replace('"', '\"')

Invoke-WebRequest -uri  $uri -Headers $headers -Method POST -ContentType "application/json" -Body "`"$template`""

Parametrization

Additionally, you can add variables to the query string of the URL that will then be automatically replaced in the template you sent. For example, altering the URL above to the value https://helipad.fiskaltrust.cloud/api/configuration?my_variable=123 will replace all occurrences of |[my_variable]| in the template text with 123 before executing it.

Some variables are automatically set if they are not specified in the query string:

Variable	Default value
outlet_number	`{max(outlets used in account's existing cashboxes) + 1}`
description	`ft{yyyyMMddHHmmss}`
cashbox_description	`ft{yyyyMMddHHmmss}`
cashbox_id	Random GUID
cashbox_ipaddress	Empty string
scu{0-9}_id	Random GUID
scu{0-9}_description	`{description}`
scu{0-9}_url	`net.pipe://localhost/{scu_id}`
helper{0-9}_id	Random GUID
helper{0-9}_description	`{description}`
helper{0-9}_url	`net.pipe://localhost/{helper_id}`
queue{0-9}_id	Random GUID
queue{0-9}_id_base64withoutspecialchars	`{queue_id}`, converted to Base64 without special characters
queue{0-9}_description	`{description}`
queue{0-9}_url	`http://localhost:1200/fiskaltrust` for the first queue, `http://localhost:1200/fiskaltrust{1-9}` for others

Dynamic values are highlighted via {} in this table.

With the registration of your company in the fiskaltrust.portal on the one hand an account and on the other hand a contact is created. This contact has as primary contact every possible authorization in the account of the company. If you create additional contacts under Company name → Employee, you can click on the record and assign specific permissions. The highlighted record is the one with the primary role. Below the permissions you will further find the Primary Contact button, which you can use to set a contact as the new primary contact. By changing the primary contact, all permissions of the previous primary account are revoked and its account owner will not be able to log on to the fiskaltrust.Portal any longer, as that action requires the read permission as minimum. The new primary contact may assign permissions to this contact again, if desired.

If the Middleware is showing errors which suggest connection issues to one of our cloud services (e.g. "configuration cannot be downloaded" or "an error occured while uploading data"), it might be a firewall problem. Pinging our servers won't work, as they are configured to not respond to those requests - but users should try to run the following requests in Powershell:

Invoke-RestMethod 'https://helipad.fiskaltrust.cloud/version'
Invoke-RestMethod 'https://packages.fiskaltrust.cloud/version'

If one of those fails, it's most likely a network or firewall issue and is not related to a malfunction of the Middlware. Please refer to our respective documentation about how to configure the Windows Firewall.

The stop receipt is required for scheduled decommissioning of the fiskaltrust.SecurityMechanism and/or cash registers. The stop receipt is used to switch off any further: receipt chaining, up-counters, and totalizer storage. It also concludes the data collection log.

This receipt has a meaningful response from fiskaltrust.SecurityMechanism only the one time in order to stop operative calculations and the operation of a queue. After receiving a stop receipt the queue will be closed. There will be no positive response from the fiskaltrust.SecurityMechanism to the cash register when a receipt is sent to a closed queue.

A closed queue cannot be reopened with a start receipt. Instead, a new queue must be created and initialised with a start receipt.

A zero receipt is a universal data carrier and storage. The cash register sends a receipt with an empty charge items block (ftChargeItem) and an empty pay items block (ftPayItem) which logically contain a total amount of “0”.

The fiskaltrust.SecurityMechanism sends the necessary blocks, such as the receipt header, the charge item block, and the signature block in the response. This response is either printed or issued electronically and has to be archived.

For example a start receipt or stop receipt is a special case of a zero receipt.

FAQs in German

Nach dem 25.11.2010 und vor dem 01.01.2020 angeschaffte Kassen, welche die Anforderungen des BMF erfüllen, aber bauartbedingt nicht aufrüstbar sind, so dass sie die Anforderungen des § 146a AO nicht erfüllen, dürfen längstens bis zum 31.12.2022 weiterhin verwendet werden (Art. 97 § 30 Abs. 3 EGAO). Die Nachweise des Vorliegens dieser Voraussetzungen sind für die jeweils eingesetzte Kasse der Verfahrensdokumentation beizufügen. Von der Ausnahmeregelung des Art. 97 § 30 Abs. 3 EGAO sind PC-Kassensysteme nicht umfasst.

Welche Daten werden verarbeitet

Kundenbezogene Daten (= Name, Adresse, Kontaktdaten, UID-Nummer, Aufträge, usw. von KassenHerstellern, KassenHändlern, KassenBetreibern)
Konfigurations- und Statusdaten (= TSE-Zertifikat, ClientId, Status der Queue, usw.)
Massendaten (= ReceiptRequest, ReceiptResponse)
Revisionsgesicherte kundenbezogene Massendaten (= .Tar-File, DSFinV-K-File, usw.)
Allgemeine kundenbezogene Massendaten (= Kopie von allem, was in revisionsgesicherte Kundenbezogene Massendaten gespeichert wird, Rechnungen, Verträge, usw.)

Resultierend aus dem Gesetz müssen keine personenbezogenen Daten gespeichert werden. Der KassenHersteller entscheidet, welche Daten bei der Registrierung im Portal und auf den Kassenbelegen (Massendaten) bekannt gegeben werden.

Wenn ein KassenHersteller sich z.B. im Portal registriert, dann könnte er auch anonymisierte Daten verwenden. Bitte beachten Sie, dass Sie z.B. bei den Belegdaten keine Namen oder dergleichen aufdrucken, wenn Sie die Bekanntgabe von personenbezogenen Daten verhindern möchten. In der Praxis wird es wohl kaum zu verhindern sein, personenbezogene Daten zu verwenden, das Gesetz sieht hier jedoch keine Notwendigkeit vor.

Wo werden die Daten verarbeitet

Azure-Region West-Europe (a104, a105)
Azure-Region North-Europe
Azure-Region Germany-West-Central (a110, a111)
Azure-Region France-Central (a107, a108)
Equinix-Datacenter Amsterdam (nl18) (https://www.equinix.com/locations/europe-colocation/netherlands-colocation/amsterdam-data-centers/)
RRZ-Datacenter Raaba / Graz (at11) (https://www.rrz.co.at/)

Wo werden die Daten gespeichert

SQL Azure West-Europe -> Mirror (Azure North-Europe, Azure Germany-West-Central, Azure France-Central)
Dynamics365 EMEA Region (=crm4)
Massendaten Azure West-Europe -> Mirror Azure North-Europe
Kundenbezogene Massendaten Deutschland Azure Germany-West-Central

Allgemeine Workloads werden in West-Europe verarbeitet.
CPU-Intensive Workloads werden in North-Europe und at11 verarbeitet.
Kundenbezogene Daten werden ausschließlich in einer eigenen Dynamics365 - Instanz pro Land verwaltet.
- Alle Services mit der Endung "fiskaltrust.de" werden mit Azure Germany-West-Central (Microsoft Azure in neuen Cloudregionen in Deutschland verfügbar | Azure-Updates | Microsoft Azure) verarbeitet.
- Kundenbezogene Massendaten für Konfigurationen, welche mit Services mit der Endung "fiskaltrust.de" erzeugt wurden, werden in Azure Germany-West-Central gespeichert.

Wie werden die Daten gespeichert

Die Daten werden gemäß den gesetzlichen Vorgaben in der Form gespeichert, in der sie an die Middleware geschickt werden.

Wie lange werden die Daten aufbewahrt

Die Daten werden mindestens entsprechend der gesetzlichen Aufbewahrungsfristen aufbewahrt (dzt. mindestens 10 Jahre), bzw. die Speicherdauer verlängert sofern anderweitige Verfahren anhängig sind.

Der Prozess ist immer derselbe, unabhängig davon ob die TSE von fiskaltrust bezogen wird oder von einem anderen Reseller - wobei wir uns natürlich noch mehr darüber freuen, wenn auch die TSE von uns bezogen wird:

Erstellung einer SCU im Portal mit dem Package passend für den Hersteller der mitgebrachten TSE
Diese SCU muß mit der entsprechenden Cashbox verbunden werden
Die TSE kann in Verbindung mit unserer kostenfreien fiskaltrust.Middleware verwendet und mit Addons bzw. Produkt-Bundles, wie z.B. dem fiskaltrust.Sorglos ohne TSE Bundle, ergänzt werden.

Hinweis: Falls der PIN der TSE gem. Anleitung des Herstellers geändert wurde, müssen PIN & User in der Konfiguration gemäß Dokumentation aktualisiert werden.

Liste der von fiskaltrust unterstützten TSE & Konfiguration

Storno von Vorgängen und Positionen

Storno von Vorgängen
- Nachträgliche Vorgangsstornierung (DSFinV-K 4.2.2)
  - Der Stornobeleg ist ein separater Beleg, der durch BON_STORNO = „1“ zu kennzeichnen ist. Die Vorzeichen von MENGE, BRUTTO, NETTO sowie UST sind umzukehren. Zur eindeutige Identifizierung ist cbPreviousReceiptReferenze entsprechend zu verwenden.
  - Der neu zu erstellende Stornobeleg ist mit dem ReceiptCaseFlag „reverse/voided receipt“, 0x0000000000040000 zu kennzeichnen.
  - Dadurch wird der Beleg im DSFinV-K mit BON_STORNO = „1“ gekennzeichnet.
  - Die Aussage in DSFinV-K S. 80, dass BON_STORNO nicht verwendet werden darf, wenn eine negative Rückbuchung des Vorgangs erfolgt ist dahingehend korrekt, da sich dies auf den ursprünglichen zu stornierenden Beleg bezieht.
- Sofortige Vorgangsstornierung (DSFinV-K 4.2.1)
  - Die sofortige Vorgangsstornierung erfolgt ausschließlich wie die „Nachträgliche Vorgangs-Stornierung“.
  - Da fiskaltrust keine „alte“ Kassen unterstützt, die noch nicht mit einer TSE verbunden sind, wird die sofortige Vorgangsstornierung durch nachträgliches Markieren des Belegs mit dem Storno-Flag „BON_STORNO“ durch das ft.Interface NICHT unterstützt.
  - Der Vorgangstyp „AVBelegstorno “ kann daher ebenso nicht verwendet werden.
- Storno von Positionen (DSFinV-K 4.2.3)
  - Ebenso wie bei der Vorgangsstornierung ist ein zusätzlicher Positionsdatensatz zu erstellen Die Vorzeichen von MENGE, BRUTTO, NETTO sowie UST sind umzukehren.
  - Die Stornierung von Positionen durch nachträgliches Markieren der Position mit dem Storno-Flag „P_STORNO“ darf nicht verwendet werden.

DSFinV-K

Darstellung besonderer Vorgänge

4.2.1 Sofortige Vorgangsstornierungen

Eine sofortige Vorgangsstornierung kommt nur bei Systemen in Betracht, die nicht mit einer TSE verbunden sind (z.B. Kassen, die mit Übergangsregelung bis 31.12.2022 ein-gesetzt werden können), wenn ein Kassenbeleg erzeugt wurde, das Geschäft aber unmittelbar nicht zustande kommt (z. B. weil der Kunde das Geld vergessen hat). Aus-schließlich in diesen Fallkonstellationen kann ein Sofortstorno vorgenommen werden. Die Darstellung kann auf zwei Arten erfolgen:

BON_STORNO wird auf „1“ gesetzt, ansonsten bleibt der Datensatz unverändert (insbesondere wird kein zweiter Datensatz erzeugt; nur in diesen Fällen darf der Vorgangstyp „AVBelegstorno“ genutzt werden), oder
Vorgehensweise wie nachfolgend zu „Nachträgliche Vorgangs-Stornierung“ dargestellt.

4.2.2 Nachträgliche Vorgangs-Stornierungen

Für die nachträgliche Stornierung eines Vorgangs gelten besondere Vorschriften:

Der Ursprungsbeleg bleibt unverändert.
Der Stornobeleg ist ein separater Beleg, der durch BON_STORNO = „1“ zu kennzeichnen ist. Der Vorgangstyp ist in diesem Fall (analog zu dem Ursprungsbeleg) mit „Beleg“ anzugeben. Die Vorzeichen sind umzukehren. Um einen Bezug zum ursprünglichen Vorgang zu ermöglichen, sind spezielle Referenz-Felder zur eindeutigen Identifizierung in der DSFinV-K enthalten. Aus umsatzsteuerlicher Sicht gehört eine Stornorechnung zum Bereich der Rechnungskorrekturen. Ebenso wie für Rechnungen gelten auch für Rechnungskorrekturen die gesetzlichen Pflichtangaben nach § 14 Abs. 4 UStG.

4.2.3 Stornierung von Positionen

Vorzunehmende Stornierungen auf Positionsebene finden im Bereich der Bonpos statt. Dabei ist entweder in der ursprünglichen Position P_STORNO auf „1“ zu setzen (ohne eine zweite Datenzeile zu erstellen) oder ein zusätzlicher Positionsdatensatz zu erstellen, bei dem MENGE, BRUTTO, NETTO sowie UST mit negativen Vorzeichen dargestellt werden. In diesem Fall darf P_STORNO nicht auf „1“ gesetzt werden. Sobald die Transaktion in der TSE signiert ist, darf das Feld P_STORNO nicht mehr verwendet werden.

4.2.5 Vorgänge mit Negativpositionen

Kommen in einem Bon Positionen mit negativem Vorzeichen durch z. B. Warenrücknahmen, Rabatte oder Positionsstornos vor, so erfolgt eine Darstellung wie bei einem normalen Verkauf. Lediglich das Vorzeichen für das Feld MENGE ändert sich (und damit automatisch das Vorzeichen von POS_BRUTTO, POS_NETTO und POS_UST in der Datei Bonpos_UST, vgl. 3.1.1.1).

Anhang B BON_TYP (Vorgangstyp)

Es werden folgende Vorgangstypen (Bontypen) unterschieden: …

AVBelegstorno AVBelegstorno Der Vorgangstyp „AVBelegstorno“ kennzeichnet alle Vorgänge, die vollständig storniert werden. Die Verwendung ist nur innerhalb eines Kassenabschlusses zulässig. Der Einsatz von AVBelegstorno ist kassensystemabhängig und für die Kassensysteme gedacht, die anstatt einer Gegenbuchung nur ein Storno-Kennzeichen am Originalbeleg verwenden. Der AVBelegstorno zeigt eine vollständige Stornierung des Originalbelegs an, so dass sämtliche Beträge nicht mehr im Kassenabschluss berücksichtigt werden. Hinweis: Mit dem AVBelegstorno ist nicht die negative Darstellung eines Beleges gemeint. Hierfür muss weiterhin der Vorgangstyp „Beleg“ mit umgekehrten Vorzeichen und ohne Storno-Kennzeichen genutzt werden. Zu beachten ist in diesen Fällen, dass eine Referenz auf den ursprünglichen Vorgang erfolgen muss. Achtung! Sobald eine TSE an einer Kasse eingesetzt wird, ist es technisch nicht mehr möglich, den Vorgangstyp „AVBelegstorno“ korrekt zu verwenden, da jeder Beleg schon vor dem Setzen des Storno-Kennzeichens bereits durch die TSE signiert wurde. Insofern ist ein nachträgliches „Nullen“ eines Beleges nicht mehr möglich.

Kapitel: Einzelaufzeichnungsmodul

11. Datei “Bonkopf” (transactions.csv)

BON_STORNO

Feldtyp: Zeichen Feldlänge: 1 Kurzbeschreibung: Die Aktivierung (Wert: „1“) dieses Feldes kennzeichnet die Stornierung eines einzelnen Beleges. Eine Angabe ist zwingend erforderlich („0“ oder „1“). BON_STORNO darf nur auf „1“ gesetzt werden, wenn ein kompletter Vorgang sofort und ohne Gegenbuchung „aufgehoben“ wird, nicht aber, wenn eine negative Rückbuchung des Vorgangs erfolgt. Vgl. hierzu Ausführungen zu Tz. 4.2.1 und 4.2.2.

P_STORNO

Feldtyp: Zeichen Feldlänge: 1 Kurzbeschreibung: Positionsstorno-Kennzeichnung. Bei Aktivierung des Feldes (Wert = „1“) handelt es sich um eine (sofort während der Erfassung) stornierte Position.

Anhang I Definition “Art” und “Daten” des Vorgangs; QR-Code

1. Definition der Datenstrukturen zur Übergabe an das Sicherheitsmo-dul

…

Kassenbeleg

processType: Kassenbeleg-V1 processData: <Vorgangstyp>^<Brutto-Steuerumsätze>^<Zahlungen> Trennzeichen: ^ (Unicode U+005E) <Vorgangstyp>: Der Vorgangstyp laut DSFinV-K kann folgende Werte annehmen:

AVBelegstorno

Cancellation of operations and items

Cancellation of operations
- Subsequent process cancellation (DSFinV-K 4.2.2)
  - The cancellation-receipt is a separate receipt which is to be identified by BON_STORNO = "1". The signs of MENGE, BRUTTO, NETTO and UST must be reversed. For unique identification cbPreviousReceiptReference is to be used accordingly.
  - The new cancellation-receipt to be created must be marked with the ReceiptCaseFlag "reverse/voided receipt", 0x000000000004000000.
  - This marks the receipt in DSFinV-K with BON_STORNO = "1".
  - The statement in DSFinV-K p. 80 that BON_STORNO may not be used if a negative reversal of the transaction is made is correct in this respect, as this refers to the original receipt to be reversed.
- Immediate process cancellation (DSFinV-K 4.2.1)
  - Immediate transaction cancellation is only carried out in the same way as "Subsequent transaction cancellation".
  - Since fiskaltrust does not support "old" cash registers which are not yet connected to a TSE, the immediate transaction cancellation by subsequent marking of the document with the cancellation flag "BON_STORNO" by the ft.interface is NOT supported.
  - The transaction type "AV document reversal" can therefore not be used either.
- Cancellation of positions (DSFinV-K 4.2.3)
  - As with the transaction cancellation, an additional item data record must be created. The signs of MENGE, BRUTTO, NETTO and UST must be reversed.
  - The cancellation of items by subsequently marking the item with the cancellation flag "P_STORNO" must not be used.

DSFinV-K

Representation of special events

4.2.1 Immediate process cancellations

Immediate transaction cancellation is only possible for systems that are not linked to a TSE (e.g. cash registers that can be used with transitional arrangements until 31.12.2022), if a cash voucher has been generated but the transaction does not take place immediately (e.g. because the customer has forgotten the money). Only in these cases can an immediate cancellation be made. The display can be done in two ways:

BON_STORNO is set to "1", otherwise the data record remains unchanged (in particular, no second data record is created; only in these cases may the transaction category "AV document reversal" be used), or
Proceed as described below for "Subsequent operation cancellation".

4.2.2 Subsequent process cancellations

Special rules apply to the subsequent cancellation of a transaction:

The original document remains unchanged.
The reversal document is a separate document, which must be identified by BON_STORNO = "1". In this case, you must specify the activity category with "Document" (analogous to the original document). The signs should be reversed. In order to enable a reference to the original transaction, special reference fields for unique identification are included in the DSFinV-K. From a sales tax perspective, a cancellation invoice is part of the invoice correction process. Just as for invoices, the statutory mandatory information according to § 14 para. 4 UStG (German VAT Act) also applies to invoice corrections.

4.2.3 Cancellation of positions

Cancellations to be carried out at item level take place in the area of bonuses. Either set P_STORNO to "1" in the original position (without creating a second data row) or create an additional position data record in which QUANTITY, GROSS, NET and UST are displayed with negative signs. In this case P_STORNO must not be set to "1". Once the transaction has been signed in the TSE, the field P_STORNO may no longer be used.

4.2.5 Operations with negative positions

If items with a negative sign occur in a receipt due to, for example, goods returns, discounts or position cancellations, they are displayed as in a normal sale. Only the sign for the field QUANTITY changes (and thus automatically the sign of POS_BRUTTO, POS_NETTO and POS_UST in the file Bonpos_UST, see 3.1.1.1).

Appendix B BON_TYP (transaction type)

The following transaction types (receipt types) are distinguished: …

AVBelegstorno AV document cancellation The transaction category "AVBelegstorno" indicates all transactions that are completely reversed. The use is only permitted within a cash balance. The use of AVBelegstorno is dependent on the POS system and is intended for POS systems that only use a reversal indicator on the original document instead of an offsetting entry. The AVBelegstorno displays a complete reversal of the original receipt, so that all amounts are no longer included in the cash balance. Note: The AVBelegstorno does not mean the negative representation of a document. For this, you must continue to use the transaction category "Document" with reversed debit/credit signs and without a reversal indicator. In these cases, it should be noted that a reference to the original operation must be made. Look out! As soon as a TSE is used at a cash register, it is technically no longer possible to use the transaction type "AVBelegstorno" correctly, since each document has already been signed by the TSE before the reversal indicator is set. In this respect, subsequent "zeroing" of a document is no longer possible.

Chapter: Single Recording Module

11. file "Bonkopf" (transactions.csv)

BON_STORNO

Field type: Character Field length: 1 Short description: The activation (value: "1") of this field marks the cancellation of a single receipt. An entry is mandatory ("0" or "1"). BON_STORNO may only be set to "1" if a complete transaction is "cancelled" immediately and without an offsetting entry, but not if a negative reverse posting of the transaction is made. Cf. comments on points 4.2.1 and 4.2.2.

P_STORNO

Field type: Character Field length: 1 Brief description: Position reversal indicator. If the field is activated (value = "1"), this is a cancelled item (immediately during data entry).

Annex I Definition of "type" and "dates" of the operation; QR code

1. definition of the data structures for transfer to the security module

…

Cash voucher

processType: Kassenbeleg-V1 processData: <Vorgangstyp>^<Brutto-Steuerumsätze>^<Zahlungen> Trennzeichen: ^ (Unicode U+005E) <Vorgangstyp>: The transaction type according to DSFinV-K can have the following values:

AVBelegstorno

Nein. Die Verträge werden auf unbestimmte Dauer abgeschlossen. Jeder Vertragsteil kann diesen Vertrag unter Einhaltung einer dreimonatigen Kündigungsfrist jeweils zum Vertragsende aufkündigen, gemessen an dem Monat der Vertragsunterfertigung. Vertragsbeginn ist das Datum der Vertragsunterfertigung. Das Abrechnungsjahr beginnt mit dem Monatsersten des Monats der Vertragsunterfertigung und endet nach 12 Monaten.

Entgeltzahlungen gemäß der aktuell von fiskaltrust publizierten Preise, welche im Portal veröffentlicht sind, erfolgen auf Jahresbasis im Vorhinein. Die Aufrechnung mit Gegenforderungen des Kunden ist ausgeschlossen.

Beispiel:

Ereignis	Datum
Vertragsunterfertigung	20.08.2020
Beginn Abrechnungsjahr	01.08.2020
Ende Abrechnungsjahr	31.07.2021
Letzter Kündigungstermin	30.04.2021
Kündigungsfrist	01.5.2021 bis 31.07.2021
Ende der Leistung (z.B. Pos Archiv)	19.08.2021
Ende der grace-period zur Verlängerung der Leistung	19.08.2021

Steuerliche Beurteilung

1. Befristeten Absenkung der Umsatzsteuersätze von 19% auf 16% und von 7% auf 5%

Durch das zweite Corona-Steuerhilfegesetz werden vom 01.07.2020 bis 31.12.2020 der allgemeine Umsatzsteuersatz von 19% auf 16% (§ 12 Abs. 1 UStG) sowie der ermäßigte Umsatzsteuersatz von 7% auf 5% (§ 12 Abs. 2 UStG) gesenkt.

2. Befristete Absenkung des Umsatzsteuersatzes für Speisen in Restaurants und Gaststätten von 19% auf 7%

Die Regelung gilt ab dem 01.07.2020 und ist bis zum 30.06.2021 befristet. Da die obige Regelung der Reduktion von 7% auf 5% (siehe 1.) auch für diesen Fall gilt, beträgt der Umsatzsteuersatz auf Speisen in Restaurants und Gaststätten

vom 1.7.2020 bis 31.12.2020: 5%
vom 1.1.2020 bis 30.06.2020: 7%

Dies führt dazu, dass in allen Kassen zweimal, in Restaurants und Gaststätten dreimal Anpassungen vorgenommen werden müssen.

Keine Änderung des fiskaltrust.iPOS

Das fiskaltrust.iPOS ist seit Beginn an derart flexibel aufgebaut und auf eine Änderung eines Steuersatzes vorbereitet, dass keine grundsätzliche Änderung erforderlich ist.

Abbildung im json-request an die ft.Middleware

Änderung am 01.07.2020, am 01.01.2021 sowie am 01.07.2021

Die geänderte steuerliche Vorgabe ist durch korrekte json-requests an die ft.Middleware zu senden. Es ändert sich nur der Steuersatz, nicht jedoch die Leistungsart. Dies bedeutet, dass die bisherigen ftChargeItemCases für den allgemeinen Umsatzsteuersatz (z.B. für Lieferungen 0x4445000000000011) sowie für den ermäßigten Umsatzsteuersatz (z.B. für Lieferungen 0x4445000000000012) ab 01.07.2020 weiter verwendet werden müssen. https://docs.fiskaltrust.cloud/doc/interface-doc/doc/appendix-de-kassensichv/reference-tables/type-of-service-ftchargeitemcase.html

Die Kassa hat jedoch immer den korrekten Mehrwertsteuersatz im Feld VATRate zu senden.

https://docs.fiskaltrust.cloud/doc/interface-doc/doc/general/data-structures/data-structures.html

Daher ist

der"alte" Steuersatz von 19% bis zum 30.06.2020 und
der temporär, "neue" Steuersatz von 16% ab 01.07.2020 im request zu senden.

Die Umstellung vom "alten" auf den "neuen" Steuersatz ist durch einen Tagesabschlusses (daily-closing request) zu trennen bzw. dadurch zu markieren.

Zeitliche Zuordnung

Der Zeitpunkt der Ausführung einer Lieferungen bzw. einer sonstige Leistung ist für die Anwendung des korrekten Steuersatzes relevant. Hiefür ist die steuerliche Beurteilung des Unternehmens z.B. durch eine/n SteuerberaterIn maßgeblich.

Behandlung von Sonderfällen

Beispielsweise sind Anzahlungen, Vorauszahlungen, Jahreskarten, Abonnements, Dauerleistungen, Bauleistungen, Pfand, Einzweck- und Mehrzweckgutscheine in Hinblick auf diese zeitliche Zuordnung besonders zu behandeln. In diesen Sonderfällen, welche zur Verwendung eines anderen (alten) Umsatzsteuersatzes führen, sind die jeweils korrekten Umsatzsteuersätze (19%, 16%, 7% oder 5%) im VATRate eines json-request zu verwenden. Die ft.Middleware trennt die Umsatzsteuersätze aufgrund der gesendeten Information für den korrekten Export im DSFinV-K.

TSE-ProcessData-Container sowie DSFinV-K Steuerpositionen

Die ft.Middleware verwendet die TSE entsprechend der BSI-Richtlinien sowie des DSFinV-K.

TSE-ProcessData-Container

Dies bedeutet, die fünf bestehenden TSE-ProcessData-Container bleiben erhalten und werden nicht erweitert. 1. Regelsteuersatz, 2. ermäßigter Steuersatz, usw.

DSFinV-K Steuerpositionen

In der folgenden Übersicht werden die Umsatzsteuerschlüssel mit Beschreibung und den Umsatzsteuersätzen dargestellt. Über die IDs 1 – 4 werden die im Zeitpunkt der Erfassung des Geschäftsvorfalls gültigen Umsatzsteuersätze nach §§ 12 und 24 UStG erfasst.

Ist für die Erfassung des Geschäftsvorfalls auch ein vormals gültiger Umsatzsteuersatz zu verwenden, werden hierfür die historischen Umsatzsteuersätze unter den IDs 11 bzw. 21 (allgemeiner Steuersatz) und 12 bzw. 22 (ermäßigter Steuersatzsatz) berücksichtigt.

Anpassungen (ab ID 1000) können individuell für den Unternehmer nach einem Kassenabschluss jederzeit vorgenommen werden und sind in den entsprechenden Systembeschreibungen bzw. Verfahrensdokumentationen zu dokumentieren.

Anpassungen der IDs bis 999 bleiben der DFKA-Taxonomie und der DSFinV-K vorbehalten und sind in den Begleitdokumenten bei Änderungen zu dokumentieren und zu erläutern." (Kap. 3.2.6)

ID	USt-Satz	Beschreibung
1		Zum Zeitpunkt der Erfassung des Geschäftsvorfalls geltender allgemeiner Steuersatz (§ 12 Abs. 1 UStG)
2		Zum Zeitpunkt der Erfassung des Geschäftsvorfalls geltender ermäßigter Steuersatz (§ 12 Abs. 2 UStG)
3	10,70%	Durchschnittsatz (§ 24 Abs. 1 Nr. 3 UStG) übrige Fälle
4	5,50%	Durchschnittsatz (§ 24 Abs. 1 Nr. 1 UStG)
5	0,00%	Nicht Steuerbar
6	0,00%	Umsatzsteuerfrei
7	0,00%	UmsatzsteuerNichtErmittelbar
11	19,00%	Historischer allgemeiner Steuersatz (§ 12 Abs. 1 UStG)
12	7,00%	Historischer ermäßigter Steuersatz (§ 12 Abs. 2 UStG)
21	16,00%	Historischer allgemeiner Steuersatz (§ 12 Abs. 1 UStG)
22	5,00%	Historischer ermäßigter Steuersatz (§ 12 Abs. 2 UStG)
bis 999		reserviert für Änderungen DSFinV-K
ab 1000		individuelle Sachverhalte (§ 13b UStG, o.ä.)

Da die Container (für die TSE) oder die IDs (für DSFinV-K) nicht für einen Steuersatz sondern einen Steuertyp stehen, sind durch die ft.Middleware alle Abbildungen möglich.

BMF-Entwurf eines begleitenden BMF-Schreibens "Befristete Absenkung des allgemeinen und ermäßigten Umsatzsteuersatzes zum 1. Juli 2020":

======= Bundesregierung: Steuerentlastungen-Coronavirus

BMWI, 12.06.2020 -PRESSEMITTEILUNG: Wirtschaftliche Entwicklung - Unbürokratische Umsetzung der Mehrwertsteuersenkung bei Preisangaben durch pauschale Rabatte möglich

Die fiskaltrust Lösung kann bei Bedarf unter bestimmten Rahmenbedingungen auch im eigenen Rechenzentrum des KassenHerstellers (PosCreator) betrieben werden.

Voraussetzungen

Der Kunde installiert und wartet das gemeinsam geplante Gewerk eigenständig
Internetverbindung
SQL Datenbank (MSSQL oder MySQL) für die Speicherung der Middlewaredaten

Detailinformationen

Leistungen Kunde		Leistungen fiskaltrust		Kosten
Bereitstellung & Betrieb gewarteter Kubernetes Cluster gem. ft. Anforderungen/sizing im Rechenzentrum (Eigenleistung oder wahlweise Beauftragung an Dritte)				unbekannt
Rechenzentrum Name:	(bitte bekanntgeben)

Briefing für Sizing-Berechnung Kubernetes Cluster		Sizing Berechnung Kubernetes Cluster		keine
Anzahl Cashboxen:	(bitte bekanntgeben)	total Backend PODs	(wird von ft ermittelt)
Max. Anzahl Receipts/Tag/Cashbox:	(bitte bekanntgeben)	Datenbankspeicher	(wird von ft ermittelt)

		Onboarding/Consulting		einmalige Kosten
		Interview - Anforderungsanalyse
		Onboarding-Workshop
		Umsetzungs-Support
		Abschlusstermin, Projektabschluss


		fiskaltrust Produkte		monatliche Kosten pro Cashbox
		Standard Produkt-Bundle mit TSE as a Service & Archiv

Für weitere Informationen oder ein individuelles Angebot wenden sie sich bitte an den fiskaltrust Support Team.

Laut Nichtbeanstandungsregelung ist von der Mitteilung (Meldung der TSE an das Finanzamt, Anm.) nach § 146a Absatz 4 AO bis zum Einsatz einer elektronischen Übermittlungsmöglichkeit abzusehen. Der Zeitpunkt des Einsatzes der elektronischen Übermittlungsmöglichkeit wird im Bundessteuerblatt Teil I gesondert bekannt gegeben.

Daher ist der Zeitpunkt der zu übermittelnden Informationen bis zur oben beschriebenen Veröffentlichung der elektronischen Übermittlungsmöglichkeit aktuell noch nicht bekannt.

Wer aufzeichnungspflichtige Geschäftsvorfälle oder andere Vorgänge mit Hilfe eines elektronischen Aufzeichnungssystems, hat dem zuständigen Finanzamt nach amtlich vorgeschriebenen Vordruck (bzw. dem zukünftigen elektronischen Verfahren) mitzuteilen:

Name des Steuerpflichtigen,
Steuernummer des Steuerpflichtigen,
Art der zertifizierten technischen Sicherheitseinrichtung,
Art des verwendeten elektronischen Aufzeichnungssystems,
Anzahl der verwendeten elektronischen Aufzeichnungssysteme,
Seriennummer des verwendeten elektronischen Aufzeichnungssystems,
Datum der Anschaffung des verwendeten elektronischen Aufzeichnungssystems,
Datum der Außerbetriebnahme des verwendeten elektronischen Aufzeichnungssystems.

Diese Mitteilung ist innerhalb eines Monats nach Anschaffung oder Außerbetriebnahme des elektronischen Aufzeichnungssystems zu erstatten.

Im Falle eines Verlustes bzw. Diebstahls einer TSE empfehlen wir den Vorfall im Rahmen der Verfahrensdokumentation zu dokumentieren, eine Abmeldung der TSE beim Finanzamt vorzunehmen (falls elektronische Übermittlungsmöglichkeiten vorhanden sind, siehe oben), eine neue TSE zu beschaffen und diese im Rahmen des üblichen Verfahrens der Beschaffung mit einer neuen Cashbox-Konfiguration inkl. neuer Queue in Betrieb zu nehmen. Eine gesonderte Sperrung im Portal oder beim Finanzamt ist hierbei nicht notwendig.

Ja unbedingt. Für die rechtskonforme Verwendung ist es notwendig, dass jeder Standort (Outlet) von jeder rechtlichen Einheit (Unternehmen des PosOperators) zumindest eine eigene CashBox der fiskaltrust.Middleware verwendet. Jede für einen Standort konfigurierte Instanz darf daher beim richtigen KassenBetreiber (PosOperator) nur einmal eingesetzt werden. Es können jedoch mehrere Kassen-Terminals an diesem Standort diese Instanz verwenden. Info zu den möglichen Rollout-Szenarien sind hier zu finden. Um den Rollout für viele Kunden mit grundsätzlich gleicher Konfiguration zu vereinfachen, können Vorlagen (Templates) im fiskaltrust.Portal angelegt werden, die als Basis dienen. https://docs.fiskaltrust.cloud/doc/productdescription-de-doc/for-posdealers/02-pre-sales/automatisierter-rollout.html

Die Middleware (der Launcher) kann nicht aus dem Portal heruntergeladen werden

Rebuild Configuration Button klicken im Portal, danach herunterladen
Einen anderen Browser zum Download verwenden
Einen anderen Computer zum Download verwenden

Der Online Launcher kann die Pakete beim Starten nicht herunterladen

Eine andere Internetverbindung verwenden
Bei restriktiven Firewalls kann der Upload in das fiskaltrust.Portal blockiert werden. Hier hilft es auf dem Gerät, auf dem der fiskaltrust.Service und als der Benutzer der den Dienst startet (wegen Proxy Problemen) die Verbindung zur fiskaltrust.Cloud zu prüfen. Geben sie folgendes in den Browser ein:
Helipad: https://helipad.fiskaltrust.cloud/api/version (für den Upload der Daten)
Packages: https://packages.fiskaltrust.cloud/api/version (für den Download der Pakete beim ersten Start) Wenn die Verbindung erfolgreich ist, erhalten Sie jeweils ein JSON mit Versionsinformationen angezeigt.

Der Dienst startet nicht richtig

Unser Service benötigt .net Framework (am besten 4.8) und eine Microsoft C++ Runtime als Voraussetzung, genaueres hier /fiskaltrust/productdescription-de-doc/blob/master/product-service-description/compliance-as-a-service/produkte/lokal-installierte-middleware.md
Eine bestimmte Instanz eines fiskaltrust.Dienstes (eine Cashbox mit einer CashboxId und einem Accesstoken) kann auf einem Gerät nur einmal laufen. Sonst würde versucht werden, die gleichen Endpunkte mehrmals zu verwenden. Mehrere unterschiedliche Cashboxen können bei richtiger Konfiguration auf einem Gerät gleichzeitig laufen.
Wurde der Dienst mit Administrator Rechten gestartet? Der Benutzer, unter dem der Dienst ausgeführt wird muss Administrator Rechte besitzen.
Zur Fehlersuche kann es sehr hilfreich sein, den fiskaltrust.Service mit test.cmd direkt aufzurufen (Achtung nur ENTWEDER mit test.cmd aufrufen, ODER als Windows Dienst im Hintergrund starten, eine Instanz darf nicht 2 Mal auf einem Gerät gestartet werden UND AUCH NICHT AUF VERSCHIEDENEN GERÄTEN). Wenn man die test.cmd editiert, kann man auch den Parameter -verbosity=debug und -logfile="C:\t\fiskaltrust.log" anhängen um mehr Informationen angezeigt zu bekommen. Siehe auch die FAQ Debugging. https://docs.fiskaltrust.cloud/doc/faq/qna/DE-debugging.html?q=debugging

Nach dem Neustart des Geräts startet der Dienst nicht selbständig. Wird er manuell gestartet, funktioniert der Dinest einwandrei.

Den Windows Dienst auf die Startart „Automatisch (verzögerter Start)“ setzen. Damit wird sichergestellt, dass benötigte Dienste beim Aufruf schon bereit sind.

Es kommt keine Signatur zurück (überhaupt nicht, von Anfang an nicht)

Ist in der Konfiguration der TSE/Signaturerstellungseinheit der richtige Laufwerksbuchstabe, COM Port eingetragen?
Wird die TSE richtig erkannt, sehe ich den Laufwerksbuchstaben im Explorer, den COM Port im Gerätemanager?

Die fiskaltrust.Middleware liefert plötzlich zu einem Request keine ftSignaturType im Response zurück.

Senden sie einen zero-receipt als Request. Beim Senden eines zero-receipt wird von der fiskaltrust.Middleware versucht, die Verbindung zur TSE wiederherzustellen.
Ist eine verwendete Hardware-TSE (versehentlich) vom Gerät getrennt worden?
Ist keine Internetverbindung zur Kommunikation mit einer Cloud-TSE vorhanden?
Ist eine erforderliche Konfiguration eines Laufwerksbuchstabes oder COM Port noch korrekt?
Wurde am System etwas geändert, Updates eingespielt, neue Hardware angeschlossen, alte Hardware entfernt?

Es kommt keine Signatur zurück (nach längerem Betrieb)

War der Computer im Energiesparmodus? Eventuell hilft ein Ausschalten der Energiesparmodi.

Die Kasse meldet, dass die fiskaltrust.Middleware nicht erreichbar ist, wie kann ich das prüfen?

Ist der Endpunkt der Middleware erreichbar? Man erhält eine Antwort im Browser, wenn man in den Browser den Endpunkt eingibt (Bei GRPC kommen nur “Sonderzeichen”, erhält man diese, so kann man aber zumindest davon ausgehen, dass der fiskaltrust.Service gestartet wurde und auf Eingaben wartet). z.B. (je nach konfiguriertem Endpunkt bei der Queue)
REST: http://localhost:1200/ftrest
WCF SOAP: http://localhost:1200/fiskaltrust
GRPC: http://localhost:10103/ Siehe auch die FAQ Debugging.

Die Belege werden korrekt signiert, im fiskaltrust.Portal sind die Belege aber auch nach einiger Zeit noch nicht sichtbar.

Bei restriktiven Firewalls kann der Upload in unser Portal blockiert werden. Prüfen Sie die Verbindung zur fiskaltrust.Cloud auf dem Gerät als der Benutzer, der den Service ausführt. Um Proxy-Probleme auszuschließen empfiehlt es sich, immer den Benutzer des Services für Tests zu verwenden. Geben Sie folgendes in die Adresszeile des Browsers ein:
Helipad: https://helipad.fiskaltrust.cloud/api/version (für den Upload der Daten)
Packages: https://packages.fiskaltrust.cloud/api/version (für den Download der Pakete beim ersten Start) Sie erhalten jeweils eine JSON-Struktur mit Versionsinformationen angezeigt, falls die Verbindung fehlerfrei ist.
Wenn im fiskaltrust.Service die interne Kommunikation mit GRPC erfolgt (der Endpunkt der TSE/Signaturerstellungseinheit ein GRPC Endpunkt ist), dann kann ein verwendeter Proxy zu Problemen führen. Dies kann durch setzen der Environement-Variable no_grpc_proxy auf localhost (wenn localhost verwendet wird) umgangen werden https://github.com/grpc/grpc/blob/master/doc/environment_variables.md

Meine fiskaly TSE scheint nicht zu funktionieren, wie kann ich die Verbindung zu fiskaly prüfen?

Kann man die Adresse kassensichv.io über einen ping erreichen (in einer Eingabeaufforderung ping kassensichv.io eingeben, hier sollte eine Antwort kommen)?
Fehlermeldungen in der Firewall (lokal am Gerät, oder im Netzwerk)?

Ich habe alles versucht, was kann noch eine Ursache eines Problems sein?

Lokaler Virenscanner | Dieser kann den Zugriff auf vom fiskaltrust.Service benötigte Dateien sperren. z.B. im Ordner C:\Programdata\fiskaltrust
Lokale Firewall | Der fiskaltrust.Service kommuniziert auch intern auf einem Computer über Netzwerkports (außer bei net.pipe)
Windows Updates installiert | Dies kann selten zu Änderungen der erkannten Geräte führen.
Registry Cleaner | Könnten Änderungen am Startverhalten des fiskaltrust.Service vorschlagen.

Bei einem Ausfall der fiskaltrust.Middleware darf mit der Kasse weiter gearbeitet werden (siehe Punkt 7 des AEAO zu § 146a: https://www.bundesfinanzministerium.de/Content/DE/FAQ/2020-02-18-steuergerechtigkeit-belegpflicht.html)

Die TSE ist in dem Fall ebenso nicht erreichbar.

Die Kasse kann im „Ausfallmodus“ weiter betrieben werden.
Durch die Nacherfassung der ausgefallenen Belege können alle Daten, die während des Ausfalls von der Kasse gespeichert wurden, an die fiskaltrust.Middelware gesendet werden, sobald diese wieder erreichbar ist.

Durch die Nacherfassung können alle gesetzlich erforderlichen Funktionen wie z.B. DSFinV-K-Export, PosArchiv, AKO, usw. dennoch erfüllt werden. Die Behandlung des Ausfalls wird in der Interface-Dokumentation in docs.fiskaltrust beschrieben.

Weil nicht alle Kassen mit einer technischen Sicherheitseinrichtungen (TSE) vor dem 01.01.2020 ausgestattet werden konnten, hat das BMF am 06.11.2019 eine Nichtbeanstandungsregelung veröffentlicht.

Laut diesem BMF-Schreiben werden keine Strafen verhängt, falls bis zum 30.9.2020 die Anbindung einer TSE erfolgt.
Für diesen Zeitraum sind keine individuellen Anträge der Steuerpflichtigen notwendig, um nachzuweisen, dass aufgrund nicht selbst verschuldeter Umstände noch keine TSE verwendet werden kann.
Für diesen Zeitraum gilt außerdem keine Pflicht zum Export der Daten im DSFinV-K Format.
Die Pflicht zur Belegerteilung an alle Kunde bleibt davon jedoch unberührt.

fiskaltrust stellt über das fiskaltrust.Portal für jeden fiskaltrust Kunden, der einen Kooperationsvertrag mit fiskaltrust unterzeichnet hat, eine Bestätigung zur Verfügung, dass vom Kunden die Aufrüstung der Kasse mit der fiskaltrust.Middleware geplant ist.

Regionale Ergänzungen zur Nichtbeanstandungsregelung

Stand: 21.08.2020

Trotz Ablehnung durch das Bundesfinanzministerium haben einige Bundesländer aufgrund der Corona-Krise entschieden, eine eigene Ergänzungen zur oben genannten Regelung herauszugeben.

Der 30.09.2020 als vom BMF festgelegte Termin bleibt bestehen und somit entsprechen nicht konforme Kassensysteme danach auch nicht den BMF Vorschriften.
Einige Bundesländer sichern jedoch zu, von einer entsprechen Prüfung der Sachlage bis Ende März 2021 abzusehen, sofern:
- die erforderliche Anzahl an TSEs bei einem Kassenfachhändler oder einem anderen Dienstleister bis zum 30. September 2020 (bzw. in manchen Bundesländern bis zum 31. August 2020!) nachweislich verbindlich bestellt wurden, beziehungsweise in Auftrag gegeben wurden oder
- die Verwendung einer zertifizierten, cloudbasierten TSE vorgesehen ist (z.B. bei einer Zentralkasse in Unternehmen mit einer Vielzahl von Filialen), solche zertifizierte, cloudbasierte TSE jedoch nachweislich noch nicht verfügbar sind.

Als KassenBetreiber sollten Sie unbedingt bis spätestens August/September 2020 die konforme Kasse / konforme Aufrüstung der Kasse nachweislich bei Ihrem Händler bestellen. Fordern Sie eine Auftragsbestätigung an und legen Sie diese der Verfahrensdokumentation zur Kassenführung bei. Bewahren Sie die Dokumente gemäß der gesetzlichen Aufbewahrungsfrist für einen Zeitraum von mehr als 10 Jahren auf!

Im Folgenden haben wir für Sie, ohne Anspruch auf Vollständigkeit und Rechtssicherheit, eine Linksammlung mit den Regelungen der einzelnen Bundesländer zusammengetragen.

Aktuelle Regelungen der Bundesländer zur Fristverlängerung:

Bundesland (inkl. Link zum Dokument)	Voraussetzung bei stationärer oder cloudbasierter TSE-Lösung und weitere Voraussetzungen	letzter Bestelltermin	Nichtbeanstandungs-regelung verlängert bis	Antrag beim Finanzamt
Baden Württemberg	- Der Unternehmer hat die erforderliche Anzahl an TSE bei einem Kassenfachhändler oder einem anderen Dienstleister nachweislich bis zum 30. September 2020 verbindlich bestellt oder in Auftrag gegeben oder - es ist der Einbau einer cloudbasierten TSE vorgesehen, eine solche ist jedoch nachweislich noch nicht verfügbar.	30.09.2020	31.03.2021	nein
Bayern	- Der Unternehmer hat die erforderliche Anzahl an TSE bei einem Kassenfachhändler oder einem anderen Dienstleister bis zum 30. September 2020 nachweislich verbindlich bestellt oder in Auftrag gegeben oder - es ist der Einbau einer cloudbasierten TSE vorgesehen, eine solche aber nachweislich noch nicht verfügbar.	30.09.2020	31.03.2021	nein
Berlin	- der Einbau der technischen Sicherheitseinrichtung muss bis zum 30. August 2020 mit einem konkreten Termin beauftragt sein, - Firmen, die die technische Sicherheitseinrichtung anbieten oder den Einbau vornehmen, haben bestätigt, dass die Umrüstung nicht bis zum 30. September 2020 möglich ist, - der Einbau muss spätestens bis zum 31. März 2021 erfolgen, - gemäß Abgabenordnung (§ 146a) müssen alle Verpflichtungen erfüllt werden, - für die Veranlagungszeiträume 2010 bis 2020 liegt kein Straf- oder Ordnungswidrigkeitsverfahren wegen Steuerhinterziehung beziehungsweise Steuergefährdung vor, das mit einer Verurteilung, einem Strafbefehl, einer Auflage oder einem Bußgeldbescheid abgeschlossen wurde.	30.08.2020	31.03.2021	nein
Brandenburg	1. Die Unternehmerin/der Unternehmer hat die erforderliche Anzahl an TSE bei einer Kassenfachhandlung, einer Kassenherstellung oder einer anderen Dienstleistung im Kassenbereich nachweislich bis spätestens 31.08.2020 mit dem fristgerechten Einbau von TSE beauftragt und - diese muss schriftlich versichern, dass der Einbau der TSE bis zum 30.09.2020 nicht durchgeführt werden konnte - es muss ein konkreter Einbautermin der TSE in das elektronische Aufzeichnungssystem benannt werden (spätestens bis zum 31.03.2021). 2. Bei einem geplanten Einsatz einer cloudbasierten TSE müssen Unternehmen spätestens bis zum 31.08.2020 den fristgerechten Einsatz nachweislich beauftragt haben. Die Implementierung ist schnellstmöglich, spätestens bis zum 31.03.2021 abzuschließen. 3. Es werden die übrigen bereits erfüllbaren Anforderungen des § 146a AO (insbesondere Belegausgabepflicht) beachtet. 4. Die Billigkeitsmaßnahme kann nicht gewährt werden, wenn für die Veranlagungszeiträume 2010 - 2020 ein Straf- oder Ordnungswidrigkeitsverfahren wegen Steuerhinterziehung bzw. Steuergefährdung durchgeführt wurde, das rechtskräftig mit einer Verurteilung, einem Strafbefehl, einer Auflage oder einem Bußgeldbescheid abschloss. 5. Nachweise der Voraussetzungen sind mit der Verfahrensdokumentation zur Kassenführung aufzubewahren.	31.08.2020	31.03.2021	nein
Bremen	Aktuell keine Verlängerung der Nichtbeanstandungsregel! Folge: Individueller Antrag nach § 148 AO, der detailliert begründet werden muss.			ja
Hamburg	a) Es muss durch geeignete Unterlagen belegbar sein, dass die erforderliche Anzahl an TSE bis zum 30. September 2020 bei einem Kassenfachhändler, einem KassenHersteller oder einem anderen Dienstleister im Kassenbereich verbindlich bestellt oder der Einbau der TSE beauftragt worden ist. b) Ist der Einbau einer cloudbasierten TSE vorgesehen, eine solche aber noch nicht verfügbar, ist die Nichtverfügbarkeit durch geeignete Dokumente nachzuweisen. Der Einsatz der cloudbasierten oder eine anderen TSE muss auch in diesen Fällen bis zum 31. März 2021 sichergestellt werden.	30.09.2020	31.03.2021	nein
Hessen	Der Steuerpflichtige muss bis spätestens 30. September 2020 eine TSE verbindlich bestellt oder einen Kassenfachhändler, einen KassenHersteller oder einen anderer Dienstleister im Kassenbereich verbindlich mit dem fristgerechten funktionsfertigen Einbau der TSE in das elektronische Aufzeichnungssystem beauftragt haben. - Ist der Einbau einer cloudbasierten TSE beabsichtigt, eine solche aber noch nicht verfügbar, ist die Nichtverfügbarkeit durch geeignete Dokumente nachzuweisen. Der funktionsfertige Einbau einer TSE bis zum 31. März 2021 muss auch in diesen Fällen sichergestellt werden.	30.09.2020	31.03.2021	nein
Mecklenburg-Vorpommern	a) bis spätestens 30. September 2020 ein Kassenfachhändler, ein KassenHersteller oder ein anderer Dienstleister im Kassenbereich mit dem fristgerechten Einbau einer TSE nachweislich beauftragt worden ist, b) bei geplantem Einsatz einer cloudbasierten TSE, der fristgerechte Einsatz nachweislich bis zum 30. September 2020 beauftragt wurde. Im Grundsatz bleibt es dabei, dass die technisch notwendigen Anpassungen und Aufrüstungen der elektronischen Aufzeichnungssysteme, soweit möglich, umgehend durchgeführt werden müssen und die rechtlichen Voraussetzungen unverzüglich zu erfüllen sind. Die Nachweise sind mit der Verfahrensdokumentation zur Kassenführung nach den allgemeinen Aufbewahrungsfristen aufzubewahren und auf Verlangen vorzulegen.	30.09.2020	31.03.2021	nein
Niedersachsen	die TSE bei einem Kassenfachhändler, einem KassenHersteller oder einem anderen Dienstleister bis zum 31. August 2020 nachweislich verbindlich bestellt hat und dieser bestätigt, dass der Einbau bis zum 30. September nicht möglich ist oder der Einbau einer cloudbasierten TSE vorgesehen, eine solche jedoch nachweislich noch nicht verfügbar ist. Ein gesonderter Antrag bei den Finanzämtern ist hierfür nicht erforderlich. Das Aufbewahren der den Härtefall bestätigenden Belege reicht in diesen Fällen aus.	31.08.2020	31.03.2021	nein
Nordrhein-Westfalen	die erforderliche Anzahl an TSE bei einem Kassenfachhändler oder einem anderen Dienstleister bis zum 30. September 2020 nachweislich verbindlich bestellt beziehungsweise in Auftrag gegeben oder der Einbau einer cloudbasierten TSE vorgesehen (z.B. bei einer Zentralkasse in Unternehmen mit einer Vielzahl von Filialen), eine solche jedoch nachweislich noch nicht verfügbar ist.	30.09.2020	31.03.2021	nein
Rheinland-Pfalz	wenn eine der beiden nachfolgenden Fallgruppen vorliegt: a) Der Steuerpflichtige hat bis spätestens 31. August 2020 einen Kassenfachhändler, einen KassenHersteller oder einen anderen Dienstleister im Kassenbereich mit dem Einbau einer TSE verbindlich beauftragt und von diesem eine Bestätigung eingeholt, dass eine Implementierung bis zum 30. September 2020 nicht möglich ist. b) Der Steuerpflichtige hat den Einbau einer cloudbasierten TSE vorgesehen.	30.09.2020	31.03.2021	ja
Saarland	Dies gilt auch für die cloudbasierten TSE-Lösungen. Voraussetzung ist, dass Unternehmer vor dem 30.09.2020 einen Kassenfachhändler, KassenHersteller oder einen anderen Dienstleister im Kassenbereich mit dem fachgerechten Einbau einer TSE oder Einsatz einer cloudbasierten TSE-Lösung beauftragt haben.	30.09.2020	31.03.2021	nein
Sachsen	wenn der Einbau einer TSE bis zum 31. August 2020 nachweislich in Auftrag gegeben wurde. Das gilt auch, wenn der Einbau einer cloudbasierten TSE vorgesehen ist und eine solche jedoch nachweislich noch nicht verfügbar ist.	31.08.2020	31.03.2021	nein
Sachsen-Anhalt	a) Es muss bis spätestens 30. September 2020 ein Kassenfachhändler, ein KassenHersteller oder ein anderer Dienstleister im Kassenbereich mit dem fristgerechten Einbau einer TSE nachweislich beauftragt worden sein. b) Bei einem geplanten Einsatz einer cloudbasierten TSE müssen Unternehmen spätestens bis zum 30. September 2020 den fristgerechten Einsatz nachweislich beauftragt haben.	30.09.2020	31.03.2021	nein
Schleswig-Holstein	bis spätestens 30. September 2020 einen Kassenfachhändler, einen KassenHersteller oder einen anderen Dienstleister im Kassenbereich mit dem fristgerechten Einbau einer TSE nachweislich beauftragt haben bei einem geplanten Einsatz einer cloudbasierten TSE spätestens bis zum 30. September 2020 den fristgerechten Einsatz nachweislich beauftragt haben. - Die Nachweise dazu sind mit der Verfahrensdokumentation zur Kassenführung nach den allgemeinen Aufbewahrungsfristen aufzubewahren und auf Verlangen vorzulegen. Alle übrigen Anforderungen des Paragraph 146a AO bleiben unberührt.	30.09.2020	31.03.2021	nein
Thüringen	a) Der Steuerpflichtige hat die erforderliche Anzahl an TSE bis spätestens zum 30. September 2020 bei einem Kassenfachhändler, einem KassenHersteller oder einem anderen Dienstleister im Kassenbereich verbindlich bestellt oder den fristgerechten Einbau der TSE verbindlich beauftragt. oder b) Der Steuerpflichtige hat den Einbau einer cloudbasierten TSE vorgesehen.	30.09.2020	31.03.2021	nein, muss jedoch formlos oder über Vordruck dem Finanzamt erklärt werden

Weiterführende Informationen zur Nichtbeanstandungsregelung

Rechtsgrundlagen Deutschland

PDF Download

Download dieses Dokumentes im PDF-Format: DE-Nichtbeanstandungsregelung.pdf

Im fiskaltrust.Portal finden Sie unter Shop → Produkte das Angebot der fiskaltrust. Das sind neben dem Basis-Produkt, der fiskaltrust.Middleware, kostenpflichtige Addon-Produkte, wie z.B. das POS-Archiv, die Finanzamtsmeldung, technische Sicherheitseinrichtungen (TSE), das Kassenarchiv Online (AKO) sowie fiskaltrust.Sorglos-Bundles, siehe auch fiskaltrust.Docs. Der KassenHändler verkauft die fiskaltrust.Produkte auf dem ihm üblichen Weg. Nach dem Verkauf der Produkte an den KassenBetreiber dient das Portal dem KassenHändler dazu, diese auf die gewünschten Standorte der KassenBetreiber zu übertragen. Dabei werden diese als Entitlements oder „Ansprüche“ bezeichnet und unter Shop → Entitlements aufgelistet.

Vorbereitung

Wir empfehlen, die Bestellung eines fiskaltrust.Sorglos-Pakets mit TSE vorzubereiten, indem Sie im eigenen Account unter Shop → Entitlements den Bestand kontrollieren und falls nötig durch weitere Bestellungen aufstocken.

Warenkorb befüllen

Nach dem Wechsel in den Account des KassenBetreibers unter PosOperator → Übersicht wählen Sie Shop → Produkte . Mit der Wahl des Standorts (oder „Outlets“) legen Sie die Buchung an und für den Versand der TSE die Zieladresse fest. Wählen Sie Sie zuerst die Angebote, deren Bezeichnung mit „Anspruch übertragen“ ergänzt ist. Wählen Sie zum Beispiel:

TSE-as-a-Service – Anspruch übertragen, danach
fiskaltrust.Sorglos – Anspruch übertragen.
Beachten Sie diese Reihenfolge, damit Ihre Bestellung korrekt verarbeitet werden kann. Kontrollieren Sie vor der Auswahl der weiteren Ansprüche nochmals, ob der gewünschte Standort gewählt ist. Wählen Sie dann:
fiskaltrust.Sorglos Betreiber-Abo – aus Anspruch erzeugen sowie
die gewünschte TSE-as-a-Service – aus Anspruch erzeugen.
Ergänzen Sie noch das gewünschte Template. Wiederholen Sie den Vorgang bei weiteren Outlets und/oder KassenBetreibern.
Bestellung abschließen
Schließen Sie die Bestellung dann im eigenen Account als KassenHändler unter Shop → Warenkorb ab. Kontrollieren Sie beim Checkout nochmals die gewählten Ansprüche sowie die gewählten Standorte und schließen Sie mit
verbindlich bestellen den Vorgang ab. Mit diesem zweigeteilten Bestellvorgang wird sichergestellt, dass der Versand einer TSE an das gewünschte Outlet erfolgt. Weiter wird Ihre Bestellung im Rahmen Ihres Rahmenvertrages und Ihres Kreditlimits durchgeführt.

Variante

Als Variante kann der Bestellvorgang auch im Account des KassenBetreibers begonnen werden. Damit entfällt das Übertragen der Entitlements. Dazu wählen Sie zu Beginn den Account des KassenBetreibers und unter unter Shop → Produkte den gewünschten Standort aus. Danach wählen Sie:

das fiskaltrust.Sorglos mit TSE -Händlereinkaufsprodukt
dann fiskaltrust.Sorglos Betreiber-Abo – aus Anspruch erzeugen
sowie die gewünschte TSE-as-a-Service – aus Anspruch erzeugen
Ergänzen Sie noch das gewünschte Template.

Schließen Sie die Bestellung dann im eigenen Account als KassenHändler unter Shop → Warenkorb ab. Kontrollieren Sie beim Checkout nochmals die gewählten Ansprüche sowie die gewählten Standorte und schließen Sie mit verbindlich bestellen den Vorgang ab. Damit entstehen zwar mehr Rechnungen je Kunde, aber ein Vorgang wird eingespart.

Kontrolloption

Kontrollieren können Sie die Bestellung und Übertragung unter PosOperator → Übersicht, indem Sie wieder wechseln in den Account des KassenBetreibers. Dort ist unter Firmenname → Standorte zu sehen, ob das Sorglospaket übertragen wurde. Unter Konfiguration → Cashbox ist ein Eintrag entsprechend des gewählten Templates zu finden.

Bei einem Ausfall der TSE darf mit der Kasse weiter gearbeitet werden.

Die fiskaltrust.Middleware (ft.MW) signalisiert die Nichterreichbarkeit der TSE über den Service-Status ftState = 0x4445000000000002. Siehe dazu: docs.fiskaltrust.

Die lokale ft.MW speichert dennoch in der lokalen Datenbank die erhaltenen Requests und kann somit alle Funktionen – insbesondere DSFinV-K-Export, PosArchiv, AKO, usw. weiter lückenlos und sicher zur Verfügung stellen.

Nach Nr. 1.3 des AEAO zu § 146a muss ein elektronisches Aufzeichnungssystem oder eine Gruppe elektronischer Aufzeichnungssysteme bei störungsfreier Verwendung genau einer zertifizierten technischen Sicherheitseinrichtung zugeordnet sein. Im Falle einer Störung darf also auf eine zweite TSE zugegriffen werden.

Nach Wiederherstellung der Kommunikation mit der TSE ist das Senden eines Nullbeleges durch die Kasse an die ft.MW erforderlich. Mit diesem Nullbeleg versucht die Middleware den ordnungsgemäßen Betrieb mit der TSE wieder herzustellen. Wir empfehlen, diesen Nullbeleg durch einen Benutzereingriff zu veranlassen, da hierdurch der laufende Betrieb der Kasse möglichst wenig beeinflusst wird. Falls die Kommunikation mit der ft.MW weiterhin nicht möglich ist (erneut ftState = 0x4445000000000002), dann muss der Vorgang, ein Nullbeleg zu senden, wiederholt werden, bis die Kommunikation mit der TSE wieder ordnungsgemäß erfolgt.

Für die Cryptovision, Swissbit und Diebold Nixdorf Hardware TSEs können mit Hilfe des ft.Portals diverse PINs durch den Nutzer gesetzt oder angegeben werden. Dies geschieht durch die Konfiguration der entsprechenden SCU (TSE Signatur-Erstellungs-Einheit / Signature Creation Unit) im ft.Portal. Die PUK kann nicht explizit durch den Nutzer im ft.Portal angegeben oder gesetzt werden.

PINs bei Inbetriebnahme einer neuen TSE vergeben

Bei einer neuen, noch nicht initialisierten TSE können optional vor Inbetriebnahme der TSE PINs für die TSE expizit in der SCU Konfiguration gesetzt werden (zum Beispiel mit dem Parameter AdminPIN kann die admin PIN gesetzt werden). Werden PINs nicht explizit über Parameter gesetzt, so verwendet das System gleichbleibende Default-PINs. Werden PINs durch die Konfiguration vor der ersten Inbetriebnahme explizit gesetzt, so müssen für alle weiteren SCUs die auf diese TSE in Zukunft zugreifen wollen die gleichen PINs in der SCU Konfiguration angegeben werden.

PINs einer TSE ändern

Mit dem fiskaltrust System ist es zur Zeit nicht möglich die PINs einer bereits in Betrieb genommenen TSE zu ändern. Es ist lediglich möglich PINs für die erste Inbetriebnahme der TSE zu setzen.

PINs für eine bereits in Betrieb genommene TSE angeben

Wurde die TSE bereits in Betrieb genommen, so müssen die bei der Inbetriebnahme explizit gesetzten PINs bei jeder weiteren SCU Konfiguration angegeben werden, die auf diese TSE zugreifen möchte.

Wurde die TSE ohne explizit gesetzte PINs durch die fiskaltrust.Middelware in Betrieb genommen - es wurden also Default-PINs verwendet - so müssen keine weiteren Angaben zu den PINs in den darauf folgenden SCU Konfigurationen zu dieser TSE vorgenommen werden.

Wurde die TSE durch ein Fremdsystem zum ersten Mal in Betrieb genommen, so müssen die dabei verwendeten PINs in der SCU Konfiguration für diese TSE mit hilfe des ft.Portals angegeben werden.

Im folgenden finden Sie Angaben darüber, welche PINs pro TSE genau mit Hilfe der SCU Konfiguration gesetzt oder angegeben werden können:

Das Gesetz und die Verordnungen rund um KassenSichV geben vor, dass die TSE in der Verfügungsgewalt des KassenBetreibers betrieben werden muss.

Das bedeutet:

Eine Hardware-TSE soll im lokalen Netzwerk des Betreibers laufen.
Der Zugriffsclient einer Cloud TSE soll direkt im Rechenzentrum oder im lokalen Netzwerk des Betreibers laufen.

Diese rechtliche Vorgabe erlaubt es nicht, dass fiskaltrust die Middleware im eigenen Rechenzentrum betreibt. Das führt wiederum dazu, dass die Installation und der Betrieb der Middleware beim KassenBetreiber vor Ort erbracht werden muss.

Beim KassenBetreiber vor Ort kennt sich derjenige am besten aus, der dort die Hardware/Kasse Vor-Ort eingerichtet hat - der KassenHändler.

Das ist der Grund wieso fiskaltrust die Vor-Ort-Installation / Integration und vor allem laufende Betreuung nicht anbietet, sondern diese Leistungen vom Händler oder Servicepartner erledigt werden.

fiskaltrust bietet Produkte und Dienstleistungen im Bereich Compliance-as-a-Service und revisionssichere Daten-as-aService für Kassensysteme an.
Das Kernprodukt von fiskaltrust ist die kostenfreie fiskaltrust.Middleware für KassenHersteller. Damit können die wichtigsten Fiskalisierungsanforderungen in Deutschland umgesetzt werden.
Zusätzlich bietet fiskaltrust eine Vielzahl an Addon-Produkte für KassenHändler. Diese können entweder einzeln, oder kostengünstig als Sorglos-Pakete für All-in-One-Fiskalisierungslösungen gebündelt (z.B. Compliance Lösung + Revisionssichere Datenspeicher-Lösung + Technische Sicherheitseinrichtung aus einer Hand) für den Resale an KassenBetreiber erworben werden.
Information, Dokumentation zur Implementierung bzw. Verwendung, Beispiele und FAQ für fiskaltrust Produkte in allen Ländern findet man zentral hier bzw. auf github.

Getting started (als KassenHersteller)

Kassenherstellern empfehlen wir die Implementierung der Middleware wie in nachfolgender Anleitung Schritt für Schritt beschrieben:

https://github.com/fiskaltrust/getting-started/tree/main/poscreators

Für weitere Fragen steht ihnen auch das Support Team zur Verfügung.

Die Sandbox ist für Integrations-, Test- bzw. Lernzwecke geeignet und stellt keine rechtsgültige Fiskalisierung von Belegen zur Verfügung.

Auch fiskaltrust testet auf der Sandbox neue Entwicklungen unter möglichst produktionsnahen Bedingungen. Im Zuge dessen werden z.B. Test-Produkte, Daten oder Informationen erzeugt, denen nie bestimmt ist, in Produktion zu gelangen.

Webshop Bestellungen von Hardware-Produkten werden in der Sandbox realitätsnah abgebildet, inklusive Auftragsbestätigung und Rechnungsversand, wobei die Rechnungen um den Vermerk ergänzt werden, dass es sich um eine Test-Rechnung aus der Sandbox-Umgebung handelt. Im Gegenzug zum Produktiv-Portal wird im Hintergrund der Bestell-Auftrag aus der Sandbox nicht an unseren Logistikpartner übermittelt.

In der Sandbox kommt daher keine rechtsverbindliche Beauftragung und auch kein Versand von Hardware zustande. "Echte" Bestellungen können ausschliesslich über den Webshop in Produktion durchgeführt werden.

Mit der Registrierung Ihrer Firma im fiskaltrust.Portal wird einerseits ein Account, andererseits ein Kontakt erstellt. Dieser besitzt als Primärkontakt jede mögliche Berechtigung im Account der Firma. Legen Sie unter Firmenname → Mitarbeiter weitere Kontakte an, können Sie den Datensatz anklicken und gezielt Berechtigungen vergeben. Der hervorgehobene Datensatz ist derjenige mit der primären Rolle. Unter den Berechtigungen finden Sie weiter die Schaltfläche Primärer Kontakt, mit welcher Sie einen Kontakt als neuen Primärkontakt festlegen. Mit dem Wechsel des Primärkontakts werden für den gewählten Kontakt alle Rechte widerrufen und die Berechtigungen komplett deaktiviert. Damit ist mit diesem Kontakt keine Anmeldung im Portal mehr möglich, dazu sind mindestens Leserecht notwendig. Der neue Primärkontakt kann dem Kontakt wieder Berechtigungen zuweisen, falls gewünscht.

Der Stopp-Beleg ist für die geplante Außerbetriebnahme von Sicherheitsmechanismen und/oder Registrierkassen erforderlich. Mit diesem Beleg wird die Verkettung der Belege, das Summieren der Umsatzzähler und die fortlaufende Belegnummerierung angehalten. Er schließt auch das Datenerfassungsprotokoll ab.

Dieser Beleg erhält nur beim ersten Mal eine aussagekräftige Antwort vom fiskaltrust.SecurityMechanism. Nach Erhalt eines Stopp-Belegs wird die Queue endgültig und unwiderruflich geschlossen. Falls eine Quittung an eine geschlossene Warteschlange gesendet wird, sendet der fiskaltrust.SecurityMechanism keine positive Antwort.

Eine geschlossene Warteschlange kann mit einem Start-Beleg nicht mehr erneut eröffnet werden. Stattdessen muss eine neue Warteschlange erzeugt und mit einem eigenen Start-Beleg initialisiert werden.

Ein Null-Beleg ist für den fiskaltrust.Middleware ein universeller Datenträger und Speichermedium. Die Registrierkasse sendet einen Beleg mit einem leeren Produktblock (ftChargeItem) und einem leeren Zahlungsblock (ftPayItem), die logischerweise einen Gesamtbetrag von “0,00” enthalten.

Der fiskaltrust.SecurityMechanism sendet die erforderlichen Blöcke, z. B. den Belegkopf, den Produktblock und den Signaturblock in der Antwort. Diese Antwort wird entweder gedruckt oder elektronisch ausgegeben und muss archiviert werden.

Beispielsweise ist ein Start- oder Stoppbeleg ein Sonderfall eines Null-Belegs.

FAQs in French

Le stop receipt est requis pour la mise hors fonction programmée des mécanismes de sécurité et / ou des caisses enregistreuses. Le stop receipt permet de désactiver: le chainage des tickets, la numérotation séquentielle et le stockage des totaux. Il clôture également le journal de collecte des données.

Ce reçu a une réponse significative du fiskaltrust.SecurityMechanism seulement la première fois afin d’arrêter les calculs opérationnels et le fonctionnement d’une queue. Après avoir reçu un accusé de réception, la queue sera fermée. Il n’y aura pas de réponse positive de la caisse enregistreuse lorsqu’un reçu est envoyé à une queue fermée.

Une queue fermée ne peut pas être rouverte avec un start receipt. Au lieu de cela, une nouvelle queue doit être générée et initialisée avec un start receipt.

Un zero receipt est un support et un stockage de données universels. La caisse enregistreuse envoie un reçu avec un bloc d’articles vide (ftChargeItem) et un bloc de paiement vide (ftPayItem) qui contiennent logiquement un montant total de “0”.

Le fiskaltrust.SecurityMechanism envoie les blocs nécessaires dans la réponse, tels que l’en-tête du reçu, le bloc d’articles et le bloc de signature. Cette réponse est imprimée ou publiée électroniquement et doit être archivée.

Par exemple, un reçu d’ouverture ou de clôture sont des cas particuliers de zero receipt.

Frequently asked questions in Germany

FAQs in English​

How is the start time of a transaction (business case) determined for the German market? How can I set the start time of a transaction for the German market? Which start times of a transaction must be printed on the receipt in Germany?

Where does fiskaltrust store which data? Where is the POSArchive and AKO data stored in an audit-proof manner? Where are the archived DSFinV-K and TSE TAR files located? At which storage location is the data archived by fiskaltrust in an audit-proof manner?

Is there any certified Cloud TSE available for Germany?

Exceptions or errors occur when I am sending requests to the fiskaltrust Middleware. How can I get additional debug information about what is failing?

When will the ordered products be shipped? Are you only delivering on certain days a week? Are orders shipped individually or in bulk? Which courier service are you using?

Is the fiskaltrust solution certified in Germany? Is fiskaltrust certified in Germany? Is fiskaltrust officially certified according to BSI TR-03153?

Does fiskaltrust offer a test system? How can I test my cash register integration? How can I test my implementation? What is the fiskaltrust sandbox?

Can I run the fiskaltrust.Middleware on Linux? Can I run the fiskaltrust.Middleware on macOS? What are the requirements and limitations of the Middleware when running on Linux or macOS?

What should I do when the order and the receipt is processed including the answer of the fiskaltrust.middleware but the receipt can't be print because of an internal technical reason of the POS?

* Was versteht man unter „zu Analysezwecken“? * Wozu werden Daten auch über die Vertragsdauer hinaus gespeichert? * Welche Dritte bzw. Partner sollen Zugriff auf Daten bekommen? * Welche Daten werden verarbeitet? * Wo werden die Daten verarbeitet? * Wo werden die Daten gespeichert?

* What is meant by "for analysis purposes"? * What is the purpose of storing data beyond the contract period? * Which third parties or partners should have access to data? * What data is processed? * Where is the data processed? * Where is the data stored?

How can I set a special case VAT ID (DE: Umsatzsteuer-Identifikationsnummer/USt-IdNr.) to my charge item for the German market? How can I use the iPOS interface to address special DSFinV-k VAT (USt-IdNr.) IDs greater than 1000?

Can a TSE be operated with more than one cash register? If yes, what is the recommended architecture?

What can I do if my hardware TSE takes a lot of time to respond after some idle time, or if the Middleware cannot access it infrequently?

How can I automate or script creating Cashboxes via templates?

General-entitlement-primary-contact-ENG.md What is the Primary Contact and how can I change it?

Why is the Move-Entitlement product missing?

How can I test the connection to fiskaltrust's cloud services in case the fiskaltrust.Middleware has connection issues?

What is a start receipt?

What is a stop receipt?

What is a zero receipt?

FAQs in German​

Wie lange darf ich Kassen verwenden, welche bauartbedingt nicht aufrüstbar sind um die KassenSichV zu erfüllen? Welche Kassen müssen bis spätestens wann aufgerüstet bzw. ersetzt werden?

Wie ist die das Storno von Vorgängen und Positionen im iPOS abzubilden? Wie werden Belege storniert?

How is the cancellation of activities and items to be represented in the iPOS? How are receipts reversed?

Gibt es eine zertifizierte Cloud-TSE für den deutschen Markt?

Als KassenBetreiber, wenn ich meinen Vertrag mit fiskaltrust kündige, wird der Differenzbetrag der bereits beglichenen Rechnung rücküberwiesen oder gutgeschrieben?

Welche Änderungen ergeben sich aufgrund der befristeten Absenkung der Umsatzsteuersätze ab dem 01.07.2020? Wird das fiskaltrust.iPOS aufgrund der Umsatzsteuersatzsenkung geändert?

Kann ich eine erstellte SCU bzw. Queue löschen?

Welche Exportschnittstellen werden von fiskaltrust unterstützt? Wann bietet fiskaltrust den DSFinV-K Export an?

Wann muss ich die Verwendung einer TSE dem Finanzamt melden? Welche Informationen muß ich dem Finanzamt übermitteln? Ist im Falle eines TSE-Verlusts oder -Diebstahls eine Meldung und Sperrung der TSE, z. B. im Portal oder ggü. dem Finanzamt notwendig?

Muss ich die fiskaltrust.Middleware für jeden Standort (Outlet) in einer eigenen CashBox im Portal anlegen?

Ich bekomme die fiskaltrust.Middleware bei einem Kunden nicht zum Laufen. Welche technischen Ursachen kann das haben?

Was passiert wenn die fiskaltrust.Middleware nicht erreichbar ist?

Welche Inhalte müssen auf eine Rechnung gedruckt werden? Welche Inhalte müssen auf einen Beleg (Quittung, Bon) gedruckt werden? Ist es wirklich notwendig dass der Beleg so lang wird?

Was ist der Unterschied zwischen einem Entitlement und dem eigentlichen Produkt?

Was ist bei der Bestellung im Shop zu beachten?

Was ist der Unterschied zwischen Bestellungen und Subscriptions?

FAQs in English

How is the start time of a transaction (business case) determined for the German market?
How can I set the start time of a transaction for the German market?
Which start times of a transaction must be printed on the receipt in Germany?

Where does fiskaltrust store which data?
Where is the POSArchive and AKO data stored in an audit-proof manner?
Where are the archived DSFinV-K and TSE TAR files located?
At which storage location is the data archived by fiskaltrust in an audit-proof manner?

When will the ordered products be shipped?
Are you only delivering on certain days a week?
Are orders shipped individually or in bulk?
Which courier service are you using?

Is the fiskaltrust solution certified in Germany?
Is fiskaltrust certified in Germany?
Is fiskaltrust officially certified according to BSI TR-03153?

Does fiskaltrust offer a test system?
How can I test my cash register integration?
How can I test my implementation?
What is the fiskaltrust sandbox?

Can I run the fiskaltrust.Middleware on Linux?
Can I run the fiskaltrust.Middleware on macOS?
What are the requirements and limitations of the Middleware when running on Linux or macOS?

* Was versteht man unter „zu Analysezwecken“?
* Wozu werden Daten auch über die Vertragsdauer hinaus gespeichert?
* Welche Dritte bzw. Partner sollen Zugriff auf Daten bekommen?
* Welche Daten werden verarbeitet?
* Wo werden die Daten verarbeitet?
* Wo werden die Daten gespeichert?

* What is meant by "for analysis purposes"?
* What is the purpose of storing data beyond the contract period?
* Which third parties or partners should have access to data?
* What data is processed?
* Where is the data processed?
* Where is the data stored?

How can I set a special case VAT ID (DE: Umsatzsteuer-Identifikationsnummer/USt-IdNr.) to my charge item for the German market?
How can I use the iPOS interface to address special DSFinV-k VAT (USt-IdNr.) IDs greater than 1000?

Can a TSE be operated with more than one cash register?
If yes, what is the recommended architecture?

General-entitlement-primary-contact-ENG.md
What is the Primary Contact and how can I change it?

FAQs in German

Wie lange darf ich Kassen verwenden, welche bauartbedingt nicht aufrüstbar sind um die KassenSichV zu erfüllen?
Welche Kassen müssen bis spätestens wann aufgerüstet bzw. ersetzt werden?

Wie ist die das Storno von Vorgängen und Positionen im iPOS abzubilden?
Wie werden Belege storniert?

How is the cancellation of activities and items to be represented in the iPOS?
How are receipts reversed?

Welche Änderungen ergeben sich aufgrund der befristeten Absenkung der Umsatzsteuersätze ab dem 01.07.2020?
Wird das fiskaltrust.iPOS aufgrund der Umsatzsteuersatzsenkung geändert?

Welche Exportschnittstellen werden von fiskaltrust unterstützt?
Wann bietet fiskaltrust den DSFinV-K Export an?

Wann muss ich die Verwendung einer TSE dem Finanzamt melden?
Welche Informationen muß ich dem Finanzamt übermitteln?
Ist im Falle eines TSE-Verlusts oder -Diebstahls eine Meldung und Sperrung der TSE, z. B. im Portal oder ggü. dem Finanzamt notwendig?

Welche Inhalte müssen auf eine Rechnung gedruckt werden?
Welche Inhalte müssen auf einen Beleg (Quittung, Bon) gedruckt werden?
Ist es wirklich notwendig dass der Beleg so lang wird?