Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

Version 1 Next »

Purpose of this article

Purpose of this article is to describe the implemented conceptual solution. 

The starting point

The generation of revenue is the starting point for the NF certification and related functionality. Requirements distinguish tickets (POS over-the-counter transactions) and invoices (higher amounts, customer details are known). In Maxxton context, this means:

  1. the MXTS POS module in Front Office Manager generates revenue known as Tickets;
  2. the MXTS Reservation Manager module generates revenue from guest reservations known as Invoices.

Whenever a service is delivered, there is revenue and a document is issued. This means: 

  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: 

CodeDescriptionDefinitionMXT System eventlog
20Period fiscal archivingThe event concerns the fiscal archive production of a period : day or month or other defined periodWhen creating a fiscal archive for a period
30Fiscal year fiscal archivingThe event concerns the fiscal archive production of a fiscal year periodWhen creating an archive covering a fiscal year
50Period closing (day, month)The event concerns the period closing for a day, a month or another defined periodWhen script generates daily or monthly grand totals at 00:01
60Fiscal year closingThe event concerns the fiscal year closingWhen Fiscal Year Financially Closed is checked by user in Fiscal Year module
90Detection of an integrity defect (record or signature)The event concerns the detection of an integrity defect of official documents or files electronic signatures (except for fiscal archive)When a reservation_tax_total record is adjusted and does not match the electronic signature anymore
130User rights change / user overrideThe event concerns the change of rights affiliated to a user or a group of usersWhen changing user roles and/or rights and/or rights in a role
170Cash drawer process The event concerns the gaps founded during cash drawer processThe event concerns the gaps founded during cash drawer processExecuting a cash clearance process
190Ticket cancellationThe event concerns the generation of a cancellation ticket or a credit note (negative sale)When negative revenue is registered it is registered in eventlog
250New software versionThe event concerns the software updateWhen software is changed impacting NF525 functionality and NF_VERSION is updated in database
260Data initializationThe event concerns the data initialization when the software is launched for the first timeEntry in JET when NF525 feature flag is updated from 0 to 1 (feature flag enabled)
270Compliance settings changeThe event concerns settings evolutions which can return a non‐compliant product (example : geographic localization change)Entry in JET when NF525 feature flag is updated from 1 to 0 (feature flag disabled)
410Change of data regarding the identification of the taxable company or agentThis event traces any change in the data related to the taxable company identification (change of address, change of Siret, change of company name, etc.).

When a change in AO_Description field is done 

When a different AO is linked to a resort

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. 





  • No labels