Frequently asked questions in France
FAQs in English
Edit* 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?
expand_moreQuestion
- 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.
* 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?
expand_moreQuestion
- 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.
The service for the cloud-solution is not free of charge, but you can try the service in the sandbox without incurring any cost.
To create a cloud CashBox, certain conditions must be met beforehand:
- A valid SIREN number must be entered and checked in the basic data of the company.
- A valid branch must be registered. For this, the address of the branch and its SIRET number must be entered and verified.
Once these two conditions are met, a cloud CashBox can be created in following steps:
Step One:
Get in contact with the French sales team to receive a quote for a ChaîneCloud. The quote will be free of charge, but is necessary for producing the product.
Step Two:
Open the Shop menu on the left hand sidebar on the fiskaltrust.Portal. Then click on “Quotes” and put the quote in the shopping cart. Select the outlet in the field “Location Id” (located at the top of the page) for which you use ChaîneCloud. This is important because the outlet can not be changed afterwards!
Step Three:
Click on the green button “Binding order”. After the order was successfully placed, you will receive an email with the order confirmation and the invoice for the purchased product(s).
You can see the state of your order(s) under the Shop menu subsection “Orders” and/or “Invoice”.
Step four:
The CashBox will be created automatically within several minutes after the order is confirmed. You will find it in the Configuration menu, subcategory “CashBox”. The name starts with “fiskaltrust.ChaîneCloud” and has an upcounting number on the end.
Step Five:
Click on the rebuild configuration button (refresh circle arrows) in the row of the relevant CashBox.
Hint:
For easier identification, you can change the description of the CashBox and/or Queue in the Configuration menu.
The ChaîneLocale product allows the use of fiskaltrust.middleware on a POS system with a local installation. This product is free of charge and can be created at any time via the fiskaltrust.Portal.
Several requirements must be fulfilled.
Requirements
Log on to the fiskaltrust.Portal as a PosDealer.
Activate cash register operator (PosOperator)
Open the menu PosOperator and then click on the overview page. Next click on the magnifying glass in the first widget.
Click on the matching PosOperator name in the first column to activate the account.
Enter SIREN and company name
First, a valid SIREN must be entered and checked in the company's master data. To do this, activate the master data of the company.
Enter the company name as it appears in the commercial register at 1. At 2 enter the SIREN of the company. (In sandbox mode, any 9-digit number can be used, for example 987654321). Then click on the check button 3 to check the SIREN against the commercial register. Save the data with the button at the end of the window.
Register outlet and SIRET
Click on Outlets at the end of the company menu to display the list of branches.
The first branch is always the company headquarters, all others can be added. Open the corresponding branch or create a new one.
In the window please enter the address 1 of the branch office and then in the field Location Id the SIRET of the branch office 2. (In sandbox mode, any 14-digit number can be used, for example 98765432100012. However, the first 9 digits must correspond to the SIREN used). Now check the Siret with the button on the right side 3 and save the data with the button at the bottom of the window.
Creating a signature creation unit (SCU)
The signature creation device is the basis for the security and inalterability of the data. Once created, it cannot be deleted. It is a basic component of the configuration of the fiskaltrust.Middleware. Open the window for the SCUs in the Configuration menu.
Click on the button Create to create a new SCU. You only need one signature creation unit per outlet. One SCU can be used for several CashBoxes.
Give the SCU a descriptive name 1, and then select the 2 outlet for this signature creation unit. Press the button at the bottom of the window to save the entries.
Create a Queue
The queue is the storage location of all documents of a outlet. It can be created and managed in the Configuration menu.
Create a new queue with the button New. You need at least one queue per outlet. One queue can manage up to 10 POS systems. For this purpose, the queue must be accessible from every single POS system in the network.
Complete the values in this window. The description 1 is only for your convenience to identify the queue. The version number 2 must be selected correctly to comply with the law. The identification of the CashBox 3 must be unique around the account and serves as internal identification. Before saving, please select the appropriate outlet.
*When selecting the outlet, always make sure to use the correct one and always the same one. This cannot not* be changed afterwards!
Save this configuration and add an http URL in the following window without changing any of the other values. Save the configuration.
Assigning the SCU to the queue
To ensure the security of the documents stored in the queue, the signature creation device must be connected to the queue.
Find the recently created queue in the list. There are four configuration buttons on the right side. Click the first one (the square with an arrow).
Select the SCU you created in the first step and click Save and close.
**Be careful with this step, the SCU for this queue cannot be changed afterwards!
Setup CashBox
To connect the POS system with the fiskaltrust.Middleware you need the virtual configuration container CashBox.
In the CashBox command of the configuration menu, you must click the Add button.
Enter a description 1 and select the same branch 2 as in the previous steps again. After clicking on Save you will find a new CashBox in the list.
Click on the button with the hand symbol.
Now drag the recently created queue from right to left. Check that the correct branch is selected and click on Save.
Rebuild configuration
After each change to the CashBox, you must put together a new one.
Click on the Rebuild Configuration button (circular arrows) 1 in the CashBox line. Now you can download one of the three launchers 2 and install the fiskaltrust.Middleware on your local POS system.
It is necessary to create at least one branch, in order to use the fiskaltrust.Middleware in accordance with French laws. By registering on the fiskaltrust.Portal, the first outlet is created automatically. Depending on the data you entered during the registration process you can change it at this point.
First, make sure you have entered a valid SIREN in the master data of your company. You can verify/change the number, by clicking on the company name in the left sidebar of the fiskaltrust.Portal and then on the subcategory “Master data”. For ease of access, you can follow the links below for the sandbox https://portal-sandbox.fiskaltrust.fr/AccountProfile/Edit and for live https://portal.fiskaltrust.fr/AccountProfile/Edit.
You can now modify or correct the “SIREN” field. You must enter your SIREN number here and click the button on the right to verify it. In “sandbox” mode, you can enter any 9-digit number.
The second step is to click on the “Outlets” command in the company menu. For ease of access, you can follow the links below for the sandbox: https://portal-sandbox.fiskaltrust.fr/AccountOutlet or for the live system: https://portal.fiskaltrust.fr/AccountOutlet.
Next, you must verify the outlet that the system already created is correct. After verification, you can add a new outlet by using the button “Add new outlet”, located on the top right side of the screen. As for an existing outlet, in order to create a new outlet, you must enter the SIRET for the outlet in the data field Location ID and the address of the outlet. The outlet number is up counting and should be the same as used in the SIRET (digits 10 to 13). The outlet number must be unique.
In the fiskaltrust.Portal, you must use the numbers provided by the French authorities. The SIREN number, to be entered in the master data, is composed of nine digits. The SIRET number, used to create an outlet, corresponds to the SIREN number followed by 5 unique digits to identify the establishment. In “sandbox” mode, you can use any 5 random digits to extend the SIREN number and form a SIRET number.
For further use in the fiskaltrust.Portail, the SIRET must be checked with the “Data verification” button on the right. SIREN and SIRET must have a green check mark on the right side of the field for continued use.
If the receipt can not be signed by the fiskaltrust.SecurityMechanism the POS-System must print mode dégradé on the receipt.
When the fiskaltrust.Middleware can sign the receipts again all the receipts signed with the “degraded” mode, have to be entered (manually/automatically), sent to the fiskaltrust.SecurityMechanism and printed again, as regular receipts. Then the degraded and the new receipts must be archived together.
A good practice is to send a message in the technical log with the following content:
{
"code": 70,
"description": "Start of degraded mode",
"moment": "2020-03-22T06:10:52.6395741Z"
}
to document the beginning of the degraded mode. When normal functionality returns, the following message should be sent to the technical log, to document the event.
{
"code": 120,
"description": "End of degraded mode",
"moment": "2020-03-22T09:23:22.6015741Z"
}
When a ticket is sent to the fiskaltrust.Middleware, all of the data is secured by the fiskaltrust.SecurityMechanism. Therefore the request is processed and some security data or data required by national laws is sent back as response.
To begin the process, a receipt needs to be created by the POS-System. To accomplish this, some information from the POS-System itself and some information from the header of the receipt has to be gathered in a JSON-format.
See the below example assuming a coffee and a cheesecake is sold to a client in a restaurant and the bill is paid with cash.
1) The header of a receipt:
This is general information for the receipt itself. The fields shown here are the minimal data set necessary. All possible fields are described in the middleware documentation.
{
"ftCashboxId": "487b7a77-fbc3-414f-8b3a-57930fb58f97",
"ftPosSystemId": "058c4299-1657-5ad2-8ce3-fbbeb317a7b3",
"cbTerminalId": "term01",
"cbReceiptReference": "ticket 2020-4456",
"cbReceiptMoment": "2020-04-05 10:49:20",
"ftReceiptCase": "5067112530745229313",
2) The list of products sold:
This is an array of products or lines items for a ticket. In the fiskaltrust.Universe, these are called ChargeItems. The data set shown below, is the absolute necessary set to be compliant with the French law. All the fields and possible values are described in depth in the middleware documentation.
"cbChargeItems": [
{
"Quantity": 1.0,
"Description": "Café, espresso double",
"Amount": 5.2,
"VATRate": 20.0,
"VATAmount": 0.87,
"ftChargeItemCase": "5067112530745229315",
"Moment": "2020-04-05 10:49:50",
"ftChargeItemCaseData": "{\"NetAmount\": 4.33}"
},
{
"Quantity": 1.0,
"Description": "Cheescake",
"Amount": 7.9,
"VATRate": 20.0,
"VATAmount": 1.32,
"ftChargeItemCase": "5067112530745229315",
"Moment": "2020-04-05 10:49:50",
"ftChargeItemCaseData": "{\"NetAmount\": 6.58}"
}
],
3) How the ticket is payed:
In the fiskaltrust.Universe, this block is called PayItems. This a list of all the means of payment, used by the client. The example shown below is only the obligatory dataset, more information can be found in the middleware documentation.
"cbPayItems": [
{
"Quantity": 1.0,
"Description": "Cash",
"Amount": 13.1,
"ftPayItemCase": "5067112530745229313",
"Moment": "2020-04-05 10:50:20"
}
]
}
Depending on the protocol used, the whole receipt is sent in the payload as JSON-string with SOAP or REST. The type of protocol defines which credentials you have to send in the header of the request. Usually, it is the CashBoxID and an AccessToken. Both can be found in the Configuration menu in the fiskaltrust.Portal.
The fiskaltrust.Middleware will answer this request with a response as JSON-string like this:
{
"ftCashBoxID": "487b7a77-fbc3-414f-8b3a-57930fb58f97",
"ftQueueID": "0f68a617-c0cd-4249-9c48-c48da217ff77",
"ftQueueItemID": "d4bfd2b0-973f-4e1a-90de-c63884cde8db",
"ftQueueRow": 298886,
"cbTerminalID": "term01",
"cbReceiptReference": "posAction444",
"ftCashBoxIdentification": "RueHelder_1(2)",
"ftReceiptIdentification": "ft48F82#T293614",
"ftReceiptMoment": "2020-04-05T11:03:58.4319402Z",
"ftSignatures": [
{
"ftSignatureFormat": 3,
"ftSignatureType": 5067112530745229313,
"Caption": "www.fiskaltrust.fr",
"Data": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9...MEQCIC7YDBVwEoBqGtlMfUznu4ExAYZ3t6qph5_nIJXuOelHAiBge_EPSeCirPma881ElrNvGf2sGYfCPo5nkYZujs1P4w"
},
{
"ftSignatureFormat": 1,
"ftSignatureType": 5067112530745229312,
"Caption": "S A N D B O X",
"Data": "0f68a617-c0cd-4249-9c48-c48da217ff77"
}
],
"ftState": 5067112530745229312
}
Most of this information must be printed on the receipt, but best practice is to print everything. Each signature sent back by the fiskaltrust.Middleware must be printed. Therefore, the fields Caption and Data are obligatory and must be shown on the receipt. There can be more than one signature. If this occurs each signature must be printed. Signatures with a type 3, contain a JWT, displayed as an encoded QR-Code in the Data-field, which must be printed before the footer, on the receipt.
Any data sent to the fiskaltrust.Middleware cannot be deleted afterwards. For this reason, all changes must done by sending a new receipt. In this example we use a ticket to “void”, but this can be used for any type of receipt. For example, if you bill a simple coffee for a client you must send a ticket to fiskaltrust.Middleware:
{
"ftCashboxId": "cashbox-identification",
"ftPosSystemId": "pos-system-identification",
"cbTerminalId": "terminal-identification",
"cbReceiptReference": "pos-action-identification",
"cbReceiptMoment": "receipt-moment",
"ftReceiptCase": "0x4652000000000001",
"cbChargeItems": [
{
"Quantity": 1.0,
"Description": "Café",
"Amount": 2.2,
"VATRate": 10.0,
"VATAmount": 0.2,
"ftChargeItemCase": "0x4652000000000002",
"Moment": "moment-chargeitem",
"ftChargeItemCaseData": "{\"NetAmount\": 2}"
}
],
"cbPayItems": [
{
"Quantity": 1.0,
"Description": "Cash",
"Amount": 2.2,
"ftPayItemCase": "0x4652000000000001",
"Moment": "moment-payitem"
}
]
}
This is a normal request with one charge item for the coffee and one pay item for the cash payment. Please be aware that all security relevant data is masked with general words (e.g. ftCashBoxId, ftPosSystemId, …)
To continue our example, the client leaves the restaurant without paying. You now need to cancel this ticket, because you didn’t receive any payment. To accomplish this, you must send the same ticket with negative values to the fiskaltrust.Middleware.
{
"ftCashboxId": "cashbox-identification",
"ftPosSystemId": "pos-system-identification",
"cbTerminalId": "terminal-identification",
"cbReceiptReference": "pos-action-identification",
"cbReceiptMoment": "receipt-moment",
"ftReceiptCase": "0x4652000000040001",
"cbPreviousReceiptReference": "number of voided ticket",
"cbChargeItems": [
{
"Quantity": -1.0,
"Description": "Café",
"Amount": -2.2,
"VATRate": 10.0,
"VATAmount": -0.2,
"ftChargeItemCase": "0x4652000000000002",
"Moment": "moment-chargeitem",
"ftChargeItemCaseData": "{\"NetAmount\": -2}"
}
],
"cbPayItems": [
{
"Quantity": -1.0,
"Description": "Cash",
"Amount": -2.2,
"ftPayItemCase": "0x4652000000000001",
"Moment": "moment-payitem"
}
]
}
Two things have to be changed on the receipt. The field ftReceiptCase stays the same than the original but gets the flag for voided ticket set. (The value 4 on position 12).
And the field cbPreviousReceiptReference should be added. The value has to be the number of the voided receipt.
The sandbox is fully functional just like the live system of fiskaltrust. It can be accessed by using the URL https://portal-sandbox.fiskaltrust.fr/. In the sandbox you can register your company just like you would in the live-system, the simple difference is: It’s only for learning and trying out the functions of the fiskaltrust.Portal without any legal obligations.
While communicating with the sandbox, the fiskaltrust.Middleware always sends an additional signature for each receipt, indicating the sandbox usage. Each receipt printed in sandbox-mode must show this signature.
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
- Sandbox:
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.
How can I test the connection to fiskaltrust's cloud services in case the fiskaltrust.Middleware has connection issues?
expand_moreIf 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
Der Service für die Cloud-Lösung ist nicht kostenlos, aber Sie können dies kostenlos in der Sandbox ausprobieren.
Für die Erstellung einer CashBox müssen einige Voraussetzungen erfüllt sein.
Zunächst muss eine gültige SIREN in den Stammdaten des Unternehmens eingetragen und geprüft werden. Der zweite Schritt ist eine gültige Niederlassung (Outlet). Dazu muss die Adresse und eine SIRET beim Outlet eingegeben und überprüft werden.
Erster Schritt:
Nehmen Sie Kontakt mit dem Support von Frankreich auf um eine Angebot über eine ChaîneCloud-Lösung zu erhalten. Dieses Angebot ist kostenfrei, jedoch zur Anlege des Produkts notwendig.
Zweiter Schritt:
Öffnen Sie den Shop-Bereich in der linken Seitenleiste im fiskaltrust.Portal. Klicken Sie hier auf Angebote und übernehmen Sie es in den Warenkorb. Wählen Sie die Verkaufsstelle im Feld Standort-ID aus, für die Sie ChaîneCloud verwenden. Dies ist wichtig, denn die Verkaufsstelle kann danach nicht mehr verändert werden!
Dritter Schritt:
Klicken Sie auf die grüne Schaltfläche "Verbindlich bestellen". Nach erfolgreicher Bestellung erhalten Sie eine E-Mail mit der Bestellung und der Rechnung.
Den Status der Bestellung können Sie jederzeit mit dem Menüpunkt Bestellungen und/oder Rechnung überprüfen.
Vierter Schritt:
Die CashBox wird innerhalb weniger Minuten nach der Bestellung automatisch erstellt. Sie finden es im in der Liste des Menüpunkts "CashBox" im Konfigurationsmenü. Der Name beginnt mit fiskaltrust.ChaîneCloud und hat am Ende eine fortlaufende Nummer.
Letzter Schritt:
Klicken Sie in der Zeile der kürzlich erstellten CashBox auf die graue Schaltfläche zum erneuten Erstellen der Konfiguration (Rebuild Configuration, Kreispfeile).
Tipp:
Zur leichteren Identifizierung können Sie die Beschreibung der CashBox und/oder Warteschlange im Konfigurationsmenü ändern.
Das Produkt ChaîneLocale ermöglicht die Verwendung der fiskaltrust.Middleware auf einem Kassensystem mit einer lokalen Installation. Diese Produkt ist kostenfrei und kann jederzeit über das fiskaltrust.Portal erstellt werden.
Dazu müssen mehrere Voraussetzung erfüllt sein.
Voraussetzungen
Melden Sie sich als KassenHändler (PosDealer) am fiskaltrust.Portal an.
KassenBetreiber (PosOperator) aktivieren
Öffnen Sie das Menü PosOperator und dort die Überblicksseite und klicken Sie auf die Lupe im ersten Widget.
Klicken Sie auf den passenden PosOperator-Namen in der ersten Spalte um das PosOperator-Konto zu aktivieren.
SIREN und Firmennamen eintragen
Zunächst muss eine gültige SIREN in die Stammdaten des Unternehmens eingetragen und geprüft werden. Dazu aktivieren Sie die Stammdaten des Unternehmens.
Tragen Sie bei 1 den Firmennamen wie er im Handelsregister eingetragen ist ein. Bei 2 geben Sie die SIREN des Unternehmens ein. (Im Sandbox-Modus kann jede Zahl aus 9 Ziffern beispielsweise 987654321 verwendet werden). Danach klicken Sie auf den Prüfknopf 3 um die SIREN gegen das Handelsregister zu prüfen. Speichern Sie Daten mit dem Knopf am Endes des Fensters.
Niederlassung und SIRET eintragen
Klicken Sie am Ende des Menüs auf Outlets um die Liste der Niederlassungen anzuzeigen.
Die erste Niederlassung ist immer der Firmensitz alle weiteren können zusätzliche ergänzt werden. Öffnen Sie die entsprechende Niederlassung bzw. legen Sie eine neue an.
In dem Fenster tragen Sie bitte die Adresse 1 der Niederlassung ein und danach im Feld Location Id die SIRET der Niederlassung ein 2. (Im Sandbox-Modus kann jede Zahl aus 14 Ziffern beispielsweise 98765432100012 verwendet werden. Die ersten 9 Ziffern müssen jedoch der verwendeten SIREN entsprechen.) Nun prüfen Sie die Siret mit dem Knopf an der rechten Seite 3 und speichern die Daten mit dem Knopf am unteren Fensterrand.
Anlegen einer Signaturerstellungseinheit (SCU)
Die Signaturerstellungseinheit ist die Grundlage für die Sicherheit und Unveränderbarkeit der Daten. Einmal angelegt kann sie nicht mehr gelöscht werden. Sie ist ein grundlegender Bestandteil der Konfiguration der fiskaltrust.Middleware. Öffnen Sie im Menü Konfiguration das Fenster für die SCUs.
Klicken Sie auf den Knopf Anlegen um eine neue SCU zu erzeugen. Sie benötigen pro Outlet nur eine Signaturerstellungseinheit. Diese kann für mehrere CashBoxen verwendet werden.
Geben Sie der SCU einen beschreibenden Namen 1 und wählen Sie danach die Niederlassung 2 für diese Signaturerstellungseinheit aus. Speichern Sie die Eingaben mit Knopf am unteren Rand des Fensters.
Anlegen einer Queue
Die Queue ist der Speicherort aller Belege einer Filiale. Sie kann im Menü Konfiguration angelegt und verwaltet werden.
Legen Sie eine neue Queue mit dem Knopf Neu an. Sie brauchen pro Niederlassung mindestens eine Queue. Diese kann bis zu 10 POS System verwalten. Dazu muss sie von jedem einzelnen POS System im Netzwerk erreichbar sein.
Ergänzen Sie die Werte in diesem Fenster. Die Beschreibung 1 dient nur Ihnen um die Queue leichter zu identifizieren. Die Versionsnummer 2 muss richtig ausgewählt werden um den Gesetzen zu entsprechen. Die Identifikationder CashBox 3 muss um Konto einmalig sein und dient als interne Identifikation. Vor dem Speichern, wählen Sie noch die passende Niederlassung aus.
Achten Sie bei der Auswahl der Niederlassung immer darauf, die richtige und immer dieselbe zu verwenden. Diese kann nachträglich nicht mehr verändert werden!
Speichern Sie diese Konfiguration und fügen Sie im folgenden Fenster eine http-URL hinzu, ohne einen der anderen Werte zu ändern. Speichern Sie die Konfiguration.
Zuordnen der SCU zur Queue
Um die Sicherheit der gespeicherten Belege in der Queue zu gewährleisten muss die Signaturerstellungseinheit mit der Queue verbunden werden.
Suchen Sie die kürzlich erstellte Warteschlange in der Liste. Auf der rechten Seite befinden sich vier Konfigurationsschaltflächen. Klicken Sie auf die erste (das Rechteck mit dem Pfeil).
Wählen Sie die SCU aus, die Sie im ersten Schritt erstellt haben, und klicken Sie auf Speichern und schließen.
Seien Sie vorsichtig bei diesem Schritt, die SCU kann für diese Warteschlange nachträglich nicht mehr geändert werden!
CashBox einrichten
Um das POS-System mit der fiskaltrust.Middleware zu verbinden benötigen Sie den virtuellen Konfigurationscontainer CashBox.
Im CashBox-Befehl des Konfigurationsmenüs müssen Sie auf die Schaltfläche Hinzufügen klicken.
Geben Sie eine Beschreibung 1 ein und wählen Sie erneut dieselbe Niederlassung 2 wie in den vorherigen Schritten. Nachdem Sie auf Speichern geklickt haben, finden Sie eine neue CashBox in der Liste.
Klicken Sie auf die Schaltfläche mit dem Hand-Symbol.
Ziehen Sie nun die kürzlich erstellte Warteschlange von rechts nach links. Überprüfen Sie, ob die richtige Niederlassung ausgewählt ist, und klicken Sie auf Speichern.
Konfiguration erstellen
Nach jeder Änderung an der CashBox müssen Sie diese neue zusammenstellen.
Klicken Sie in der Zeile der CashBox auf die Schaltfläche Rebuild Configuration (Kreispfeile) 1. Jetzt können Sie einen der drei Launcher 2 herunterladen und die fiskaltrust.Middleware auf Ihrem lokalen POS-System installieren.
Damit der fiskaltrust.Middleware entsprechend den französischen Gesetzen eingerichtet werden kann, muss ein Outlet vorhanden sein. Sobald Sie das Unternehmen beim Portal registrieren, wird automatisch ein Outlet angelegt. Abhängig von den Daten, die Sie während der Registrierung eingegeben haben, müssen Sie das Outlet im fiskaltrust.Portal noch anpassen.
Stellen Sie zunächst sicher, dass Sie in den Stammdaten Ihres Unternehmens einen gültigen SIREN eingegeben haben. Sie können die Nummer überprüfen/ändern, indem Sie auf den Firmennamen in der linken Seitenleiste des fiskaltrust.Portal und dann auf die Unterkategorie Stammdaten klicken. Wenn Sie sich gerade angemeldet sind, können Sie diesem Link für die Sandbox https://portal-sandbox.fiskaltrust.fr/AccountProfile/Edit und diesem Link für das Livesystem https://portal.fiskaltrust.fr/AccountProfile/Edit folgen.
Nun müssen Sie das Feld SIREN überprüfen. Hier geben Sie die SIREN ihres Unternehmens ein und klicken auf die Schaltfläche Datenprüfung auf der rechten Seite, um sie zu bestätigen. Im Sandbox-Modus können Sie eine beliebige 9-stellige Nummer eingeben.
Der zweite Schritt ist der Befehl Outlets im Menü der Firma. Folgen Sie diesem Link für die Sandbox: https://portal-sandbox.fiskaltrust.fr/AccountOutlet oder diesem für das Live-System: https://portal.fiskaltrust.fr/AccountOutlet.
Zunächst sollten Sie das bereits vom System erstellte Outlet überprüfen. In einem zweiten Schritt können Sie mit der Schaltfläche oben rechts auf dem Bildschirm ein neues Outlet hinzufügen. Für jede Zweigstelle müssen Sie den SIRET des Outlets in das Datenfeld Standort-ID und die Adresse eingeben. Die Nummer des Outlets zählt hoch und sollte mit der im SIRET verwendeten übereinstimmen (Ziffer 10 bis 13). Die Outlet-Nummer muss eindeutig sein.
Beachten Sie, dass Sie die SIREN der Stammdaten als die ersten neun Ziffern verwenden Danach folgen 5 Ziffern, um die Nummer zu einer SIRET zu erweitern. Im fiskaltrust.Portal müssen Sie die von den französischen Behörden vergebenen Nummern verwenden. Im Sandbox-Modus können Sie die SIREN mit 5 beliebigen Ziffern erweitern.
Für die spätere Verwendung im fiskaltrust.Portal muss die SIRET mit dem Knopf Datenprüfung an der rechten Seite des Feldes überprüft werden. Sowohl SIREN als auch SIRET benötigen zur weiteren Verwendung das grüne Häkchen auf der rechten Seite.
Wenn der Beleg nicht vom fiskaltrust.SecurityMechanism signiert werden kann, muss das POS-System mode dégradé auf den Beleg drucken.
Wenn der fiskaltrust.Middleware die Belege wieder signieren kann, müssen alle diese nicht-signierten Belege (manuell oder automatisch) eingegeben, an den fiskaltrust.SecurityMechanism gesendet und erneut als reguläre Belege gedruckt werden. Dann müssen die nicht-signierten und die signierten Belege zusammen archiviert werden.
Es empfiehlt sich, im technischen Protokoll eine Nachricht mit folgendem Inhalt zu senden:
{
"code": 70,
"description": "Start of degraded mode",
"moment": "2020-03-22T06:10:52.6395741Z"
}
Damit wird der Beginn des Offline-Modus dokumentiert. Wenn die normale Funktion wieder hergestellt ist, sollte die folgende Nachricht an das technische Protokoll gesendet werden, um dies ebenfalls zu dokumentieren.
{
"code": 120,
"description": "End of degraded mode",
"moment": "2020-03-22T09:23:22.6015741Z"
}
Wenn ein Beleg an fiskaltrust.Middleware gesendet wird, werden alle Daten vom fiskaltrust.SecurityMechanism gesichert. Daher wird die Anfrage verarbeitet und einige Sicherheitsdaten oder Daten, die nach nationalem Recht erforderlich sind, als Antwort zurückgesendet.
Zunächst muss der Beleg vom POS-System erstellt werden. Dazu müssen einige Informationen aus dem POS-System selbst und einige Header-Informationen der Quittung und Verkaufsdaten in einem JSON-Format gesammelt und übertragen werden. Nehmen wir an, es wird ein Kaffee und ein Käsekuchen an einen Kunden in einem Restaurant verkauft und mit Bargeld bezahlt.
1) Der Header einer Quittung:
Dies ist eine allgemeine Information der Quittung. Die hier gezeigten Felder sind der minimal erforderliche Datensatz. Alle verfügbaren Felder sind in der Middleware Dokumentation beschrieben.
{
"ftCashboxId": "487b7a77-fbc3-414f-8b3a-57930fb58f97",
"ftPosSystemId": "058c4299-1657-5ad2-8ce3-fbbeb317a7b3",
"cbTerminalId": "term01",
"cbReceiptReference": "ticket 2020-4456",
"cbReceiptMoment": "2020-04-05 10:49:20",
"cbReceiptAmount": 13.1,
"ftReceiptCase": "5067112530745229313",
2) Die Liste der verkauften Produkte:
Dies ist eine Reihe von Produktzeilen auf einem Beleg, im fiskaltrust.Universum werden dies als ChargeItems bezeichnet. Der gezeigte Datensatz ist das absolut notwendige Minimum, um den französischen Gesetzen zu entsprechen. Alle Felder und Werte sind in der Middleware Dokumentation ausführlich beschrieben.
"cbChargeItems": [
{
"Quantity": 1.0,
"Description": "Café, espresso double",
"Amount": 5.2,
"VATRate": 20.0,
"VATAmount": 0.87,
"ftChargeItemCase": "5067112530745229315",
"Moment": "2020-04-05 10:49:50",
"ftChargeItemCaseData": "{\"NetAmount\": 4.33}",
"Unit": "tasse",
"UnitPrice": 5.2
},
{
"Quantity": 1.0,
"Description": "Cheescake",
"Amount": 7.9,
"VATRate": 20.0,
"VATAmount": 1.32,
"ftChargeItemCase": "5067112530745229315",
"Moment": "2020-04-05 10:49:50",
"ftChargeItemCaseData": "{\"NetAmount\": 6.58}",
"Unit": "pièce",
"UnitPrice": 7.9
}
],
3) Wie der Beleg bezahlt wird:
Im fiskaltrust.Universum heißt dieses Array PayItems. Dies ist eine Liste aller vom Kunden verwendeten Zahlungsmittel. Auch hier wird nur der obligatorische Datensatz angezeigt, weitere Informationen finden Sie in der Middleware Dokumentation.
"cbPayItems": [
{
"Quantity": 1.0,
"Description": "Cash",
"Amount": 13.1,
"ftPayItemCase": "5067112530745229313",
"Moment": "2020-04-05 10:50:20"
}
]
}
Je nach verwendetem Protokoll wird die gesamte Quittung als JSON-String mit SOAP oder REST im Payload gesendet. Der Protokolltyp definiert, welche Anmeldeinformationen Sie im Header der Anforderung senden müssen. Normalerweise ist es die CashBoxID und ein AccessToken. Beide finden Sie im Konfigurationsmenü im fiskaltrust.Portal.
Der fiskaltrust.Middleware beantwortet diese Anfrage mit einer Antwort als JSON-String wie folgt:
{
"ftCashBoxID": "487b7a77-fbc3-414f-8b3a-57930fb58f97",
"ftQueueID": "0f68a617-c0cd-4249-9c48-c48da217ff77",
"ftQueueItemID": "d4bfd2b0-973f-4e1a-90de-c63884cde8db",
"ftQueueRow": 298886,
"cbTerminalID": "term01",
"cbReceiptReference": "posAction444",
"ftCashBoxIdentification": "RueHelder_1(2)",
"ftReceiptIdentification": "ft48F82#T293614",
"ftReceiptMoment": "2020-04-05T11:03:58.4319402Z",
"ftSignatures": [
{
"ftSignatureFormat": 3,
"ftSignatureType": 5067112530745229313,
"Caption": "www.fiskaltrust.fr",
"Data": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9...MEQCIC7YDBVwEoBqGtlMfUznu4ExAYZ3t6qph5_nIJXuOelHAiBge_EPSeCirPma881ElrNvGf2sGYfCPo5nkYZujs1P4w"
},
{
"ftSignatureFormat": 1,
"ftSignatureType": 5067112530745229312,
"Caption": "S A N D B O X",
"Data": "0f68a617-c0cd-4249-9c48-c48da217ff77"
}
],
"ftState": 5067112530745229312
}
Die meisten dieser Informationen müssen auf dem Beleg gedruckt werden. Es wird jedoch empfohlen, alle Informationen auszugeben. Jede vom fiskaltrust.Middleware zurückgesendete Signatur muss gedruckt werden. Dabei müssen die Felder Caption und Data auf der Quittung angegeben werden. Es kann mehr als eine Signatur übermittelt werden, in diesem Fall muss jede gedruckt werden. Die Signatur mit Typ 3 enthält einen JWT als bereits codierten QR-Code im Datenfeld Data, der vor der Fußzeile des Belegs gedruckt werden muss.
An fiskaltrust.Middleware gesendete Daten können anschließend nicht mehr gelöscht werden. Hierzu müssen alle Änderungen durch Senden eines neuen Belegs vorgenommen werden. In diesem Beispiel wird ein Kassenbon (Ticket) zum Stornieren verwendet, dieses Beispiel kann jedoch für jede Art von Beleg adaptiert werden. Wenn Sie beispielsweise einem Kunden einen einfachen Kaffee in Rechnung stellen, müssen Sie einen Kassenbon an den fiskaltrust.Middleware senden:
{
"ftCashboxId": "cashbox-identification",
"ftPosSystemId": "pos-system-identification",
"cbTerminalId": "terminal-identification",
"cbReceiptReference": "pos-action-identification",
"cbReceiptMoment": "receipt-moment",
"ftReceiptCase": "0x4652000000000001",
"cbChargeItems": [
{
"Quantity": 1.0,
"Description": "Café",
"Amount": 2.2,
"VATRate": 10.0,
"VATAmount": 0.2,
"ftChargeItemCase": "0x4652000000000002",
"Moment": "moment-chargeitem",
"ftChargeItemCaseData": "{\"NetAmount\": 2}"
}
],
"cbPayItems": [
{
"Quantity": 1.0,
"Description": "Cash",
"Amount": 2.2,
"ftPayItemCase": "0x4652000000000001",
"Moment": "moment-payitem"
}
]
}
Dies ist eine normale Anfrage mit einem ChargeItem für den Kaffee und einem PayItem für die Barzahlung. Bitte beachten Sie, dass alle sicherheitsrelevanten Daten mit allgemeinen Wörtern ersetzt wurden (z. B. ftCashBoxId, ftPosSystemId, …). Jetzt verlässt der Kunde das Restaurant ohne Bezahlung. Sie müssen diesen Kassenbon stornieren, da Sie keine Zahlung erhalten haben. Dazu senden Sie das gleiche Ticket mit negativen Werten an den fiskaltrust.Middleware.
{
"ftCashboxId": "cashbox-identification",
"ftPosSystemId": "pos-system-identification",
"cbTerminalId": "terminal-identification",
"cbReceiptReference": "pos-action-identification",
"cbReceiptMoment": "receipt-moment",
"ftReceiptCase": "0x4652000000040001",
"cbPreviousReceiptReference": "number of voided ticket",
"cbChargeItems": [
{
"Quantity": -1.0,
"Description": "Café",
"Amount": -2.2,
"VATRate": 10.0,
"VATAmount": -0.2,
"ftChargeItemCase": "0x4652000000000002",
"Moment": "moment-chargeitem",
"ftChargeItemCaseData": "{\"NetAmount\": -2}"
}
],
"cbPayItems": [
{
"Quantity": -1.0,
"Description": "Cash",
"Amount": -2.2,
"ftPayItemCase": "0x4652000000000001",
"Moment": "moment-payitem"
}
]
}
Zwei Dinge müssen auf der Quittung geändert werden. Der Inhalt des Felds ftReceiptCase bleibt der gleiche wie beim Originalbeleg, erhält jedoch das Flag für einen stornierten Beleg. (Der Wert 4 auf Position 12). Und das Feld cbPreviousReceiptReference sollte hinzugefügt werden. Der Wert ist die Nummer der Original-Quittung.
Die Sandbox hat exakt dieselben Funktionen wie das Live-System von fiskaltrust. Sie können mit der URL https://portal-sandbox.fiskaltrust.fr/ darauf zugreifen. Bei der Sandbox können Sie sich, wie im Echtsystem, mit ihren Firmendaten registrieren, der einzige Unterschied ist: Die fiskaltrust.Sandbox dient zum Lernen und Ausprobieren aller Funktionen des fiskaltrust.Portals, ohne rechtliche Verpflichtungen einzugehen.
Während der Kommunikation mit der Sandbox, wird vom fiskaltrust.Middleware eine zusätzliche Signatur für jeden Beleg gesendet. Diese Signatur muss auf jeden Beleg gedruckt werden und zeigt eindeutig, dass der Beleg mit der Sandbox erstellt wurde.
Wenn Sie in ein verbundenes PosOperator Konto springen, sehen Sie die Enitlement-Produkte nur, falls folgende Voraussetzungen erfüllt sind.
- PosOperator-Vertrag wurde unterschrieben
- Ausreichend Entitlements sind im PosDealer-Konto vorhanden
Der Start-Beleg muss als erster Beleg an den fiskaltrust.SecurityMechanism gesendet werden. Dadurch wird die entsprechende Queue initialisiert und alle weiteren Belege entsprechend den Gesetzen gesichert. Dieser Beleg erhält nur beim ersten Mal eine aussagekräftige Antwort vom fiskaltrust.SecurityMechanism, alle weiteren Start-Belege werden ignoriert und nicht beantwortet.
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 service pour la solution cloud est payant, mais vous pouvez l’essayer gratuitement dans la “sandbox”.
Pour créer une CashBox, certaines conditions doivent être remplies au préalable :
- Un numéro de SIREN valide doit être saisi et contrôlé dans les données de base de l’entreprise.
- Un établissement valide doit être enregistré. Pour cela, l’adresse de l’établissement et son numéro de SIRET doivent être saisis et vérifiés.
Une fois ces deux conditions remplies, une Cashbox peut être créée en 4 étapes.
1ère étape :
Dans le fiskaltrust.Portail, ouvrez la section Boutique dans la barre latérale gauche. Cliquez ici sur Catalogue. Sélectionnez l’établissement pour lequel vous voulez utiliser le produit ChaîneCloud dans le champ “Id d’emplacement”. C’est une étape importante car l’établissement ne peut pas être changé par la suite!
Ajoutez le nombre souhaité de “ChaîneCloud” (Produit-N° 4652-201) dans le panier. Vous trouverez en haut de la fenêtre une icône avec votre panier d’achat afin finaliser à l’achat et ainsi activer le produit ChaîneCloud.
2ème étape :
Choisissez le moyen de paiement désiré (En mode “Sandbox”, choisissez le prélèvement automatique.) Cliquez ensuite sur le bouton vert Binding order. Une fois la commande finalisée, vous recevrez un e-mail avec la confirmation de commande et sa facture.
Vous pouvez en voir l’état dans la commande Commandes et / ou Facture.
3ème étape :
La CashBox sera créée automatiquement quelques minutes seulement après la commande. Vous la trouverez dans la commande “CashBox” du menu de configuration. Le nom commence par fiskaltrust.ChaîneCloud suivi d’un numéro de comptage.
4ème étape et dernière étape :
Cliquez sur le bouton gris rebuild configuration (flèches circulaires) à droite de la ligne de la CashBox récemment créée.
Astuce :
Pour une identification plus facile, vous pouvez modifier la description de la caisse et / ou de la file d’attente dans le menu de configuration.
Le produit ChaîneLocale permet l'utilisation du fiskaltrust.Middleware sur un POS-System avec une installation locale. Ce produit est gratuit et peut être créé à tout moment via le [fiskaltrust.Portal] (https://portal.fiskaltrust.fr/). Plusieurs conditions doivent être remplies préalablement.
Exigences
Inscrivez-vous en tant que revendeur (PosDealer) sur le [fiskaltrust.Portal] (https://portal.fiskaltrust.fr/).
Activer l'utilisateur de caisse (PosOperator)
Ouvrez le menu PosOperator et la page Vue d'ensemble puis cliquez sur la loupe dans le premier widget.
Cliquez sur le nom du PosOperator correspondant dans la première colonne pour activer le compte du PosOperator.
Entrer le SIREN et le nom de l'entreprise
Tout d'abord, un SIREN valide doit être saisi et vérifié dans les données de base de l'entreprise. Pour ce faire, vous devez compléter les données de base de l'entreprise.
Inscrivez la raison sociale telle qu'elle figure dans le registre du commerce dans le champs 1. Dans le champs 2, entrez le SIREN de l'entreprise. (En mode "Sandbox", n'importe quel numéro à 9 chiffres peut être utilisé, par exemple 987654321). Cliquez ensuite sur le bouton de contrôle 3 pour comparer le SIREN avec le registre du commerce. Enregistrez les données à l'aide du bouton situé en bas de la fenêtre.
Ajouter des établissement et le SIRET
Cliquez sur le sous-menu Outlets à la fin du menu Nom d'entreprise pour afficher la liste des établissement (points de vente).
Le premier établissement est toujours le siège social de l'entreprise, tous les autres peuvent être ajoutées. Depuis cette page, vous pouvez modifier les établissements existants ou en créer de nouveaux.
Veuillez entrer l'adresse 1 de l'établissement puis le SIRET de l'entreprise dans le champ Location Id 2 (Dans l'environnement test "sandbox", n'importe quel numéro à 14 chiffres peut être utilisé, par exemple 98765432100012. Toutefois, les 9 premiers chiffres doivent correspondre au SIREN utilisé). Vérifiez ensuite le SIRET avec le bouton situé sur le côté droit 3 et sauvegardez les données avec le bouton en bas de la fenêtre.
Créer une unité de création de signature (SCU)
Le dispositif de création de signature est la base de la sécurité et de l'inaltérabilité des données. Une fois créé, il ne peut être supprimé. Il s'agit d'un élément de base de la configuration du fiskaltrust.Middleware. Ouvrez la page SCU dans le menu Configuration.
Cliquez sur le bouton Créer pour créer une nouvelle SCU. Vous n'avez besoin que d'une seule unité de création de signature par point de vente. Celle-ci peut être utilisée pour plusieurs CashBox.
Entrez une description 1 pour la SCU et sélectionnez ensuite l'établissement 2 à lier à cette unité de création de signature. Sauvegardez les données saisies avec le bouton Enregister en bas de la fenêtre.
Créer une Queue
La queue est le lieu de stockage de tous les documents dans un établissement. Elle peut être créée et gérée dans le menu Configuration.
Créez une nouvelle Queue avec le bouton Créer. Il faut au moins une queue par établissement. Elle peut gérer jusqu'à 10 POS-Systems. Pour ce faire, elle doit être accessible à partir de chaque POS-System de l'établissmeent individuellement.
Complétez les champs dans cette fenêtre. La description 1 est uniquement destinée à vous aider à identifier la queue. Le numéro de version 2 doit être sélectionné correctement pour être conforme à la loi. L'identification de la CashBox 3 doit être unique pour chaque compte et est utilisée comme identification interne. Avant d'enregistrer, sélectionnez l'établissement approprié.
Lorsque vous choisissez un établissement, assurez-vous de toujours utiliser le bon et toujours le même. Cela ne peut pas être modifié par la suite !
Enregistrez cette configuration et ajoutez une http-URL dans la fenêtre suivante sans modifier aucune des autres valeurs puis sauvegardez la configuration.
Affecter la SCU à la Queue
Pour assurer la sécurité des documents stockés dans la queue, l'unité de création de signature doit être connectée à la queue.
Trouvez la queue récemment créée dans la liste. Il y a quatre boutons de configuration sur le côté droit. Cliquez sur le premier (le rectangle avec la flèche).
Sélectionnez la SCU que vous avez créé lors de la première étape et cliquez sur Enregistrer et Fermer.
Attention à cette étape, la SCU de cette queue ne peut pas être modifié par la suite !
Créer une CashBox
Pour connecter le POS-System avec le fiskaltrust.Middleware, vous avez besoin du conteneur de configuration virtuel CashBox.
Dans la commande CashBox du menu Configuration, vous devez cliquer sur le bouton Ajouter.
Entrez une description 1 et sélectionnez à nouveau le même établissement 2 que dans les étapes précédentes. Après avoir cliqué sur Enregistrer, vous trouverez une nouvelle CashBox dans la liste.
Cliquez sur le bouton avec le symbole de la main.
Faites maintenant glisser la queue récemment créée de la droite vers la gauche. Vérifiez que le bon établissement est sélectionné et cliquez sur Enregistrer en bas de la page.
Créer une configuration
Après chaque modification de la CashBox, vous devez concilier les modifications apportées avec la configuration existante.
Cliquez sur le bouton Rebuild Configuration (flèches circulaires) 1 dans la ligne CashBox. Vous pouvez maintenant télécharger l'un des trois launchers 2 et installer le fiskaltrust.Middleware sur votre POS-System en local.
Il est nécessaire de créer au moins un établissement afin de pouvoir utiliser le fiskaltrust.Middleware conforme aux lois françaises. En vous inscrivant sur le fiskaltrust.Portail, le premier établissement est créé automatiquement en fonction des données que vous avez saisies lors du processus d’enregistrement. Si nécessaire, vous devez les modifier ou corriger celles-ci lors de votre première connexion sur le fiskaltrust.Portail.
Tout d’abord, il vous faut vous assurer d’avoir entré un numéro de SIREN valide dans les données de base de votre entreprise. Vous pouvez vérifier / modifier le numéro, en cliquant sur le nom de votre société dans le menu latéral gauche du fiskaltrust.Portail puis sur la commande Données de base. Vous pouvez également suivre le lien suivant pour le sandbox https://portal-sandbox.fiskaltrust.fr/AccountProfile/Edit ou celui qui suit pour le système live https://portal.fiskaltrust.fr/AccountProfile/Edit.
Vous pouvez maintenant modifier ou corriger le champ SIREN. Vous devez entrer ici votre numéro de SIREN et cliquez sur le bouton à droite afin de le vérifier. En mode “sandbox”, vous pouvez saisir n’importe quel nombre à 9 chiffres.
Pour la deuxième étape, rendez vous sur la commande Etablissement dans le menu de votre entreprise. Alternativement, suivez le lien suivant pour le sandbox: https://portal-sandbox.fiskaltrust.fr/AccountOutlet ou celui ci-après pour le système live: https://portal.fiskaltrust.fr/AccountOutlet.
Vous devez vérifier l’établissement déjà créé automatiquement à partir du système. Dans un deuxième temps, vous pouvez ajouter un nouvel établissement avec le bouton en haut à droite de l’écran. Pour les établissements existants comme pour les nouveaux, vous devez entrer le numéro de SIRET pour chaque point de vente dans le champ Location ID ainsi que l’adresse du point de vente. Le numéro d’établissement doit être le même que celui utilisé dans le SIRET (chiffres 10 à 13). Le numéro d’établissement doit être unique.
Dans le fiskaltrust.Portail, vous devez utiliser les numéros fournis par les autorités françaises. Le numéro de SIREN, a entrer dans les données de base, est composé de neuf chiffres. Le numéro de SIRET, utiliser pour créer un établissement, correspond au numéro de SIREN suivi de 5 chiffres uniques pour identifier l’établissement. En mode “sandbox”, vous pouvez utiliser 5 chiffres aléatoires pour étendre le numéro de SIREN et former un numéro de SIRET.
Pour une utilisation ultérieure dans le fiskaltrust.Portail le SIRET doit être vérifié avec le bouton “Vérification des données” se trouvant à droite. SIREN et SIRET doivent impérativement avoir une coche verte sur le côté droit pour une utilisation future.
Si le reçu ne peut pas être signé par le fiskaltrust.SecurityMechanism le POS-System doit imprimer mode dégradé sur le reçu.
Lorsque le fiskaltrust.Middleware peut à nouveau signer les reçus, tous ces reçus “dégradés” doivent être saisis (manuellement / automatiquement), envoyés au fiskaltrust.SecurityMechanism et imprimés à nouveau comme reçus normaux. Ensuite, les reçus dégradés et les nouveaux reçus doivent être archivés ensemble.
Une bonne pratique consiste à envoyer un message dans le journal technique avec le contenu suivant :
{
"code": 70,
"description": "Start of degraded mode",
"moment": "2020-03-22T06:10:52.6395741Z"
}
pour documenter le début du mode dégradé. Lorsque le fonctionnement normal est rétabli, le message suivant doit être envoyé au journal technique, afin de documenter également cette situation.
{
"code": 120,
"description": "End of degraded mode",
"moment": "2020-03-22T09:23:22.6015741Z"
}
Lorsqu’un ticket est envoyé au fiskaltrust.Middleware, toutes les données sont sécurisées par le fiskaltrust.SecurityMechanism. Par conséquent, la demande est traitée et certaines données de sécurité ou données requises par la loi sont renvoyées en réponse.
Tout d’abord, le ticket doit être créé par le POS-System. Pour cela, certaines informations du POS-System lui-même ainsi que les informations d’en-tête du ticket doivent être rassemblées au format JSON. Par exemple, supposons qu’il soit vendu un café et une part de Cheesecake à un client dans un restaurant et que le paiement soit fait en espèces.
1) L’en-tête d’un ticket :
Il s’agit d’ informations générales pour le ticket lui-même. Les champs affichés ici regroupent l’ensemble des données minimum nécessaires. Tous les champs possibles sont décrits dans la documentation de l’interface.
{
"ftCashboxId": "487a5a77-fbc3-414f-8b3a-57930fb58f97",
"ftPosSystemId": "058c4299-1657-4fd2-8ce3-fbbeb317a7b3",
"cbTerminalId": "term01",
"cbReceiptReference": "ticket 2020-4456",
"cbReceiptMoment": "2020-04-05 10:49:20",
"ftReceiptCase": "5067112530745229313",
2) La liste des produits vendus :
Il s’agit d’un tableau de lignes produits pour un ticket, dans le fiskaltrust.Univers cela s’appelle ChargeItems. L’ensemble des données présenté ci-après comprend l’ensemble des données absolument nécessaire afin d’être conforme aux lois françaises. Tous les champs et valeurs possibles sont décrits en détail dans la documentation de l’interface.
"cbChargeItems": [
{
"Quantity": 1.0,
"Description": "Café, espresso double",
"Amount": 5.2,
"VATRate": 20.0,
"VATAmount": 0.87,
"ftChargeItemCase": "5067112530745229315",
"Moment": "2020-04-05 10:49:50",
"ftChargeItemCaseData": "{\"NetAmount\": 4.33}"
},
{
"Quantity": 1.0,
"Description": "Cheescake",
"Amount": 7.9,
"VATRate": 20.0,
"VATAmount": 1.32,
"ftChargeItemCase": "5067112530745229315",
"Moment": "2020-04-05 10:49:50",
"ftChargeItemCaseData": "{\"NetAmount\": 6.58}"
}
],
3) Comment le ticket est payé:
Dans le fiskaltrust.Univers, ce tableau est appelé PayItems. Il s’agit d’une liste de tous les moyens de paiement pouvant être utilisés par un client. Dans l’exemple ci-dessous, seul les données obligatoires est affichées, plus d’informations peuvent être trouvées dans la documentation de l’interface.
"cbPayItems": [
{
"Quantity": 1.0,
"Description": "Cash",
"Amount": 13.1,
"ftPayItemCase": "5067112530745229313",
"Moment": "2020-04-05 10:50:20"
}
]
}
En fonction du protocole utilisé, le ticket entier est envoyé dans le payload sous forme de JSON-String avec SOAP ou REST. Le type de protocole définit les informations d’identification que vous devez envoyer dans l’en-tête de la demande. Il s’agit généralement du CashBoxID et d’un AccessToken. Les deux peuvent être trouvés dans le menu Configuration du fiskaltrust.Portail.
Le fiskaltrust.Middleware répondra à cette demande avec une réponse sous forme de JSON-String comme ceci:
{
"ftCashBoxID": "487a5a77-fbc3-414f-8b3a-57930fb58f97",
"ftQueueID": "0f68a617-c0cd-4249-9c48-c48da217ff77",
"ftQueueItemID": "d4bfd2b0-973f-4e1a-90de-c63884cde8db",
"ftQueueRow": 298886,
"cbTerminalID": "term01",
"cbReceiptReference": "posAction444",
"ftCashBoxIdentification": "RueHelder_1(2)",
"ftReceiptIdentification": "ft48F82#T293614",
"ftReceiptMoment": "2020-04-05T11:03:58.4319402Z",
"ftSignatures": [
{
"ftSignatureFormat": 3,
"ftSignatureType": 5067112530745229313,
"Caption": "www.fiskaltrust.fr",
"Data": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.::.MEQCIC7YDBVwEoBqGtlMfUznu4ExAYZ3t6qph5_nIJXuOelHAiBge_EPSeCirPma881ElrNvGf2sGYfCPo5nkYZujs1P4w"
},
{
"ftSignatureFormat": 1,
"ftSignatureType": 5067112530745229312,
"Caption": "S A N D B O X",
"Data": "0f68a617-c0cd-4249-9c48-c48da217ff77"
}
],
"ftState": 5067112530745229312
}
La plupart des informations doivent être imprimées sur le ticket, mais le mieux consiste néanmoins à tout imprimer. Chaque signature renvoyée par le fiskaltrust.Middleware doit être imprimée. Par conséquent, les champs Caption et Data doivent obligatoirement apparaître sur le ticket. Il peut y avoir plusieurs signatures. Si cela se produit, chaque signature doit être imprimée. La signature avec le type 3 contient un JWT sous la forme d’un QR-Code déjà encodé dans le champ de données; celui-ci doit être imprimé sur le ticket avant le pied de page.
Aucune donnée envoyée au fiskaltrust.Middleware ne peut être supprimée à postériori. Pour garantir cela, un nouveau reçu est créé pour toutes les modifications effectuées. Dans l’exemple ci-dessous, nous utilisons un ticket pour annuler, mais cela peut être utilisé pour tout type de reçu.
Exemple:
En facturant un simple café à un client, vous devez envoyer un ticket à fiskaltrust.Middleware.
{
"ftCashboxId": "cashbox-identification",
"ftPosSystemId": "pos-system-identification",
"cbTerminalId": "terminal-identification",
"cbReceiptReference": "pos-action-identification",
"cbReceiptMoment": "receipt-moment",
"ftReceiptCase": "0x4652000000000001",
"cbChargeItems": [
{
"Quantity": 1.0,
"Description": "Café",
"Amount": 2.2,
"VATRate": 10.0,
"VATAmount": 0.2,
"ftChargeItemCase": "0x4652000000000002",
"Moment": "moment-chargeitem",
"ftChargeItemCaseData": "{\"NetAmount\": 2}"
}
],
"cbPayItems": [
{
"Quantity": 1.0,
"Description": "Cash",
"Amount": 2.2,
"ftPayItemCase": "0x4652000000000001",
"Moment": "moment-payitem"
}
]
}
Il s’agit d’une demande correcte avec un élément de facturation pour le café et un élément de paiement pour le règlement en espèces. Veuillez noter que toutes les données relatives à la sécurité sont masquées par des mots généraux (par exemple ftCashBoxId, ftPosSystemId, …)
Maintenant, les clients quittent le restaurant sans payer. Vous devez annuler ce ticket, car vous ne recevez aucun paiement. Pour cela, vous envoyez le même ticket avec des valeurs négatives au fiskaltrust.Middleware.
{
"ftCashboxId": "cashbox-identification",
"ftPosSystemId": "pos-system-identification",
"cbTerminalId": "terminal-identification",
"cbReceiptReference": "pos-action-identification",
"cbReceiptMoment": "receipt-moment",
"ftReceiptCase": "0x4652000000040001",
"cbPreviousReceiptReference": "number of voided ticket",
"cbChargeItems": [
{
"Quantity": -1.0,
"Description": "Café",
"Amount": -2.2,
"VATRate": 10.0,
"VATAmount": -0.2,
"ftChargeItemCase": "0x4652000000000002",
"Moment": "moment-chargeitem",
"ftChargeItemCaseData": "{\"NetAmount\": -2}"
}
],
"cbPayItems": [
{
"Quantity": -1.0,
"Description": "Cash",
"Amount": -2.2,
"ftPayItemCase": "0x4652000000000001",
"Moment": "moment-payitem"
}
]
}
Deux choses doivent être modifiées sur le reçu. Le champ ftReceiptCase reste identique à l’original mais obtient un indicateur pour l’ensemble du tickets annulé. (La valeur 4 en position 12).
Et le champ cbPreviousReceiptReference doit être ajouté. La valeur doit être le numéro du reçu annulé.
La sandbox (environement test) est, comme le système live de fiskaltrust, entièrement fonctionnelle. Vous pouvez y accéder depuis l’URL https://portal-sandbox.fiskaltrust.fr/ et enregistrer votre entreprise. La seule différence entre la sandbox et le système live est que la sandbox permet uniquement de se familiariser et d’essayer l’ensemble des fonctions du fiskaltrust.Portal et tout cela sans aucune obligation.
En utilisant la sandbox, le fiskaltrust.Middleware envoie toujours une signature supplémentaire pour chaque reçu, mentionnant l’utilisation de la sandbox. Chaque reçu imprimé en mode “sandbox” doit posséder cette signature.
Le start receipt doit être envoyé avant la première utilisation du mécanisme de sécurité. Ce reçu ne reçoit une réponse significative du fiskaltrust.SecurityMechanism que la première fois afin de commencer les calculs opérationnels.
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.