FR-Explanation of the functionality

Objectif de cet article

Le but de cet article est de décrire la solution conceptuelle mise en œuvre.

Point de départ

La génération de revenus est le point de départ de la certification NF et des fonctionnalités associées. Les exigences distinguent les tickets (POS transactions au guichet) et les factures (montants plus élevés, les détails du client sont connus). Dans le contexte de Maxxton, cela signifie :

1. Le module MXTS POS dans Front Office Manager génère des revenus appelés Tickets ;

2. Le module MXTS Reservation Manager génère des revenus à partir des réservations des clients, appelées factures.

Chaque fois qu'un service est fourni, il y a un revenu et un document est émis. Cela signifie :

1. From POS module a ticket is issued when a cash register transaction is performed

2. From Reservation module an invoice is issues when the service is delivered. i.e. when the reservation is checked_out (guest stay is over)

The documents issued to guests are compliant with French regulation. This is covered in the separate article Tickets & Invoices.

The data storing

When a sale is done, either POS transaction (grand_total_type GTT) or updating a reservation to checked_out (grand_total_type GTF), the following events are triggered to store data per Administration Organisation (legal entity):

• Transactional data (total amount, grand total type, document type, timestamp, vat amounts, vat percentages among others) is stored.

• Document ID is generated

• Cumulative counters per period (day, month year) are updated

Notes:

• As a reservation in MXTS can have 3 payer types (Customer, Paying Customer, Agent) and each reservation bill can be considered a separate invoice, the revenue is stored per payer type.

• Document ID's have a continuous sequence for tickets and invoices separately (aligned with requirement 6.1.3.3.)

• Invoices are stored with document_type INVOICE, as also cancelled bookings will lead to an amount to be paid by the guest (= invoice).

• Tickets are stored with document_type SALE (positive cash register transaction) or REFUND (negative cash register transaction)

• A description on field level for the database tables involved is available in the descriptive document in the Fiscal Archive. 

• Once an ticket or invoice is issued, it is not possible to edit the transaction or reservation anymore.

The cumulative and grand total amounts

For total revenue from tickets and invoices, cumulative totals are tracked. In reservation_tax_total table, the cumulative amounts per entry are updated:

• Daily cumulative amount (counter resets to zero after daily closing)

• Monthly cumulative amount (counter resets to zero after monthly closing)

• Annual cumulative amount (counter resets to zero after annual closing)

Furthermore, periodical grand totals are stored. In reservation_tax_total table, the following periodical grand totals are stored: 

• Daily grand total (grand_total_type GTP)

• Monthly grand total (grand_total_type GTM)

• Annual grand total (grand_total_type GTA)

The electronic signature

The records in the reservation tax tables are signed with a signature protecting the sensitive tax data. For each grand total Type, an electronic signature is created in base64url based on different parameters which are reflected in  MXT-3532 - Getting issue details... STATUS  

The first record of each grand_total_type has no previous signature, all subsequent records are linked with the previous entry, protecting each other's signatures. The signatures are encrypted with a private key. Below both examples are shown with realistic data based on the NF specifications:

Example 1 without previous signature:
0000:4.8|0009:420|0021:8.7,433.5,20200423012528,6873985,00020000120000,SALES,N

Example 2 with previous signature:
0000:2.4|0009:127,129.4,20200423012529,6885576,00020000123000,SALES,Y,WXBEZE51cXZ0NEwzRnJVbmdGUlVmdnJ5b3IrcU9yZ0cramdBTUpUZ2NhaW0wTWUvcThoZmxlbm9UeUREZzZXQWh5RjRkZWpoYUZUY2J4WCtCaVVhdHNic2ZIN2JReWkxRUttSFJUdG1DM1JITXB1OVNlSTZmOVNvWlFMM1Rmb1BOSHNncUdNcGY5dDVBclYwbEhHdnZ1dFlaQUxIcDM3Y0NjRytzUExXdW5PZWVpUEFubjVLakh6cGxmUFZTalN3N2xMZFk0MGpiYW9RbFVBYnR6N1F4cFV2aDdlZ2o3Yld1UGNyQW9LNVlDK1ZCeTlHVHZlNFlpWjY2NTlqTFBTYm11RkJNK05ZTjJNN2VETHV6QlVFWDYzZ2lWeElmcFFMeUZoaC9jOVZPY0dSUjRVTUR2c1JsbXZEcXdpenN5V045MzRwY2dsTCtOVzJjYnFtZVhsOTJRPT0=

The technical eventlog

Events in the software in scope for logging, are stored in nf525_eventlog table. Below is an overview of the events which are stored and the corresponding code: 

The financial archive

A user is able to generate the Financial Archive for a given period. In this process, the stored data is exported in a secured file with respect to the date-range provided. In this fiscal archive, the following content is available: 

• Explanatory document describing the format of the files or make reference to the documentation available for the version of the archive

• Signature document with previous and current fiscal archive electronic signature

• Archive eventlog report 

• Archive reservation_bill_snapshot_table 

• Archive NF525_reservation_tax_total 

• Archive NF525_reservation_tax

• Archive payments report (fetches data from mutation and mutation_total table, required based on 7.1.1.6. 

A detailed article is available for generating Fiscal Archives. 

The implementation of a new client

When a new client is implemented, it is important it is validated the NF settings are compliant and the software is ready to use. 

For this, an implementation checklist is in place.