Extended introduction

What does it mean?

Palisis has a master account with Fiskaly and every German customer will need to have a sub account starting at the end of March 2021.

In 2016, Germany passed a law to protect against the manipulation of records in electronic recording systems. According to the regulation, the Kassensicherungsverordnung needed to be implemented by December 31, 2019, at the latest. As of January 1, 2020, all recording systems had to meet the requirements of the KassenSichV, which includes the integration of a so-called TSS (technical security system) in an electronic recording system.

The TSS records each operation in the recording system and the recorded data is cryptographically signed. These signatures make it possible to determine if existing data has been manipulated. The TSS is thus the central technical component for securing basic data records against subsequent manipulation. It consists of three modules / sub-components: a security module, a storage medium and a uniform digital interface. The detailed requirements for these modules were developed by the BSI and published in technical guidelines and protection profiles.

The requirements for the safety module are defined in a technology-independent protection profile according to ISO / IEC 15408 (Common Criteria, CC). In order to meet these requirements, the manufacturers - the TSS, not the cash registers - must have their technical devices certified by the BSI. The aim of this certification is to ensure a uniform minimum level of trust and security from all TSSs and compliance with the necessary interoperability requirements.

Functional requirements

Figure. Basic structure of the technical safety device [Source: BSI TR-03153]

Palisis is able to provide this functionality to German customers due to an integration with Fiskaly (www.fiskaly.com), who are experts in fiscalization solutions.

The TSS is required for all non e-commerce sales, therefore all device or box office sales require a digital signature. When a customer checks out, the Palisis system sends information about the transaction to a TSS which creates a signature that is printed on the ticket. In Germany, each cash register needs its own TSS. 

There are a few requirements and limitations:

• Devices need to be up to date for this functionality. Fiskaly will only work on devices running v4.47.8 onwards for Pidions and v4.51.9 onwards for Adyen.
• Once activated, Fiskaly cannot be switched on and off. 
• There is no test mode in the live system.
• Bookings cannot be deleted from the live system.
• Bookings cannot be cancelled from the cash settlement screen in the backoffice.

TSS Management 

The basic change for you as a client is that each Palisis account has only one TSE.

Each device, as well as the back office, needs a registration as a client.

The TSE for your account is created by Palisis. During this process, a PIN code is generated to create the clients, which we will provide to you.

Palisis is invoiced monthly for each active TSS.

Therefore, we will deactivate any unused TSS automatically. Every night there is a background process that checks the last usage of each configured TSS and proceeds as follows:

• a TSS without an initial transaction will be deactivated after 60 days
• a TSS without a transaction in the last 28 days will be deactivated

Once the TSS has been DISABLED, either automatically or manually, a customer cannot enable it again, only a Palisis Tech user can. 

Exports 

The DSFINV-K regulation requires specified exports which the customer can configure in the Fiskaly Dashboard.

1. Setting up a Fiskaly customer account

Palisis Fiskaly Accounts

Palisis has one master account in Fiskaly, for live and test, called “Palisis AG" :

All our customers will be sub organizations. Every Palisis user will have only one login and need to switch between customer accounts accordingly.

Palisis customers can also have a user, so when the support team creates a sub account for a customer, we need to provide them with their login information. 

It is essential that created users only have access to their corresponding sub account and not to other customer accounts.

Further down, we’ll explain how to create the sub organizations.

What should I do in Fiskaly?

a) Go to https://dashboard.fiskaly.com/ and enter the username and password previously provided by our Palisis Tech department. 

b) Select the “Palisis AG” account and create a new TEST sub account for the customer (owner) in the Fiskaly Dashboard.

Collect all necessary data from the customer in advance. It is important that the data is 100% accurate. Fiskaly will automatically register all TSS with the tax office.

Don’t forget to tick “Create managed organization” and select “Palisis AG” as the master organization.

After that, enter the address of the organization. Here you can specify a different billing address if needed.

c) Create a user for the sub organization with customer data (WE CAN SKIP THIS PART)

d) Activate LIVE mode for the owner.

2. Create API keys for the sub organization in LIVE mode. You need to enter a name that fulfills certain requirements (lower case characters (a-z), numbers (0-9), dash (-)).

The API Key name should be the owner name. Please, take into account that the API key generated includes this name, so it should be a short one.

Enter a name that is similar to the account name and make sure it isn't too long.

Important: the API secret is only visible at the moment you create it, so be sure to copy it before going to the Palisis backoffice.  It also copies automatically when you click on it.

What should I do in the backoffice?

3) Apply Blackbox configurations: under Configuration > Owner Management > Blackbox:  

a. Set blackbox:

       - pit.blackbox.mode: LIVE

       - pit.blackbox.type:   DE_FISKALY

b. Set the API key information (API key and API secret) created in Fiskaly according to the instructions outlined in the previous section.

4) Creation of TSS, Client and Serial Number in Backoffice:

      a) Go to Configuration > Internal > Owner-Management > go to the Fiskaly and TSS section and create a Fiskaly TSS for the owner:

Then, the TSS is created with a client in the UNINITIALIZED status:

The data is automatically filled out in the Owner Management > Blacbox section, so no need to enter it manually:

   b) Change the status of the TSS to INITIALIZED, but only a backoffice admin user can do that. There are three possible statuses: 

• UNINITIALIZED: The first status after the TSS is created. This status cannot be set manually.
• INITIALIZED: This is the correct status for an active terminal. It needs to be set manually after the UNINITIALIZED status.
• DISABLED: A TSS may be automatically disabled due to inactivity or duplication. A customer can also set the TSS to this status manually.

However, as mentioned above, once the TSS has been DISABLED, only a Palisis Tech user can change the status.

The possible workflows are:

• UNINITIALIZED -> DISABLED
• UNINITIALIZED -> INITIALIZED
• INITIALIZED -> DISABLED

  c) Once the TSS is created in the backoffice, Fiskaly automatically registers the device and the corresponding TSS with the tax offices in Germany. This process requires the time to be synchronized with a time server, so be sure that the correct timezone is configured  in Configuration > Owner Management. The time zone should be “(1h) Europe/Berlin''.

What should the customers do?

Terminals

5) Create a Client id for each device: Every device needs its own "Client Id" which the customer has to create directly from the backoffice. However, it will only be possible to do it once the blackbox type DE_FISKALY is enabled and activated for the whole account. 

In order to create the Client Id, the customer should go to Configuration > Devices > Manage Device, enter the device details according to the "Devices: brand model and serial number" article, and click on “Create Fiskaly Client''. It is very important that the serial number entered matches exactly what is written on the hardware! 

The serial number field is pre-filled according to the serial numbers in our database. The customer must verify that it’s the correct serial number.

Please, note that you will have to confirm the action by entering the PIN number already created in a previous step.

And the Client is created with the REGISTERED state:

VAT Rates

6) The customer need to check that the VAT rate is correctly configured:  go to Configuration > Business data > VAT rates.

There are several types as follows:

• FISKALY_NORMAL
• FISKALY_NULL
• FISKALY_REDUCED_1
• FISKALY_SPECIAL_RATE1
• FISKALY_SPECIAL_RATE2

These blackbox types match with the different VAT types in Germany. 

The VAT rate entries (Configuration > Business data > VAT Rate Entries) should also have the correct percentage amount according to current German regulations. 

For a priceplan (Configuration > Transportation > Priceplan):

Receipts

The receipt is a mandatory requirement for all bookings, so all operation lines must have one receipt assigned in Transportation > Operation line:

There are some mandatory fields that need to be printed on a receipt. The following fields must be added manually by going to Configuration > Business Data > Receipt Layouts:

• Full name and address of the company. A Text block can be used for that.
• Count and type of services / articles. A Tickets block can be used for that.
• Payment. A Payment block can be used for that.
• Tax. The VAT block can be used for that.
• Date of print -> printed by default at the end of the receipt
• Transaction start time
• Transaction end time
• Serial number of the signing TSS -> also printed by default at the end of the receipt