OB Functional Specification File v6.0

Functional Specification File v 6.
French Fiscal Certification
Functional Specification File v 6.0

« Openbravo Commerce Suite 3.0RR19Q3: 1.8.4503 »
« French Fiscal v 1.0.1000 »
Proyect: French Fiscal Certification Customer: LNE Version: 6.0
Author: Victor Martinez Last Mod: Oct 2020 Página: 1 / 24

Version Control
Version Author Date Change
1.0 Victor Martinez Nov 3rd, 2017 Initial version
2.0 Victor Martinez May 9th, 2018 Document updated with correct template and versioning
3.0 Victor Martinez Jan, 25t, 2019 Adaptations required after first certification process
4.0 Álvaro Ferraz Torres Nov 28th, 2019 Adapt print log
5.0 Patricia San Juan Oct 30th, 2020 Minor versions updated and correct listing of LNE Protocol rev 1.4
requirements
6.0 Patricia San Juan Jan 25th, 2021 Fiscal Module “major” version explanation

Table of Contents
Version Control
Table of Contents
Introduction
Purpose of the document
Overview
General solution
New module
Tax Authority access
Hashed blockchain as security mechanism
Securizing blockchains
Ticket flow in online mode
Ticket flow in offline mode
Ticket hash authenticity
Terminal online/offline monitor log
Ticket print log
Closing and Aggregation of data per Tax Rate and POS Terminal
Data export
Archiving
Robustness and auditor’s checks
LNE technical requirements implementation

1: Regulatory documentation.
2: Additional documentation.
3: Data to be recorded
4: corrections
If corrections (changes or cancellations) are made to transactions in any way, these corrections are effected by
recording new payment data through “more” or “less” operations, rather than through direct changes to the
payment data recorded.
5: Training/Test mode
6: Annual, monthly and daily closures
7: Cumulative and summary data
8: Data inalterability
9: Securing receipts
10: Data archiving
11: Archiving frequency
12: Archiving integrity
13: Purge
14: Partial Purge

14: Operation traceability

16: Data conservation
17: Archive conservation
18: Centralised system
19: Tax authority access to payment data.
20: Identifying the fiscal scope
21: Identifying major and minor versions

I. Introduction
A. Purpose of the document
This document describes the way “Openbravo Commerce Suite 3.0RR19Q3:1.8.4503 version” will
be adapted to support Article 286-I-3 bis of the French Tax Code (FTC) requirements, to be certified
in France.
The document is split in two main sections:

● First section contains a general vision of the new architecture, flows and windows to be
developed for the Openbravo Commerce Suite 3.0RR19Q3:1.8.4503 version
● Second section goes over LNE protocol rev 1.4 requirements, and describes the design
solution to implement to fulfill each of them.
Openbravo Commerce Suite is the Openbravo solution for retailers. It is a responsive web and
mobile POS, backed by a complete back office functionality.
More information can be found in our home page and wiki.

B. Overview
French Certification functionality is designed to provide Openbravo Commerce Suite starting from
3.0RR19Q3:1.8.4503 version, with the features to fulfill conditions of immutability, security, retention
and archiving of data, as per French Tax Code law, starting from 1st of January of 2018.

II. General solution

A. New module
All the functionality related to the French Certification described in this document will be distributed
as a module that must be installed by any retail company operating in France, on top of Openbravo
Commerce Suite, starting from 3.0RR19Q3:1.8.4503 version
This new module will be named as “French Fiscal”, as it will enable Openbravo Commerce Suite to
support inalterability, security, retention and archiving conditions required by French Tax Authorities.
The source code of “French Fiscal v 1.0.1000” module will be the code to certify by the accredited
body located in France, “Laboratoire National de Métrologie et D’essais (LNE), according to LNE
standard version 1.4.
Openbravo will use the source code and the obfuscated jar library of the parts that controls
inalterability, security, retention, and archiving; to generate a hash code that will be displayed as
part of “French Fiscal v 1.0.1000” module.
The source code of “French Fiscal '' module is the code to be certified by the LNE, and therefore
represents the fiscal scope of Openbravo cash register system.
For additional information, please review the OB Technical Specification File version 7.0, where the
source code and all technical details of the French Fiscal module are described.
B. Tax Authority access

“French Fiscal v 1.0.1000” module will include a new “backend role” with full access to the windows
and processes explained in this document.
This role will be the one to associate to tax authorities auditor users, and it will mainly allow to:
● Access and review each sales ticket, payment information, print log and terminal monitor log
created since January 1st, 2018.
● Access and review cumulative and perpetual information available by day, month and year
(fiscal or natural year).
● Export any of the sales tickets or cumulative/perpetual information.
● Verify the integrity and inalterability of the exported data.
● Verify the integrity and inalterability of the archived data.
In order to access the archives, the tax administration will have to contact
"support@openbravo.com" to make the request which will be treated within 3 working days.

C. Hashed blockchain as security mechanism

Each sales ticket and each cumulative information (by day/month/year), will be stored in the
database in a hashed blockchain structure, where each record is linked to the previous one through
its hash.
This methodology ensures from one side that the record itself hasn’t been altered, and from the
other side that the record history is always constant.
Each entity (ticket, ticket print log, closure by day, closure by month, closure by year and terminal
monitor log) will have a unique chain per terminal.
The general algorithm to store any entity in a blockchain will be:

1. The record that we want to store in the blockchain structure is created either from the POS
terminal (ticket, ticket print log and terminal monitor log) or from the backend (closure
information by day/month/year).
2. The system gets the previous-record-in-chain hash for this terminal and entity.
3. The system generates a standard XML representation of the record (or JSON in case of
tickets).
4. The system concatenates the previous hash, the XML/JSON representation of the record
and the timestamp, and generates a hash using HMAC based on SHA256 algorithm.
5. Finally the record is stored in the database along with the previous record hash, the
calculated hash and the timestamp.
6. The database controls this record can’t be updated or deleted through a trigger so the
blockchain is stable.
SHA256 hash is generated using DigestUtils and javax.crypto in Java, and forge library in
JavaScript.
D. Securizing blockchains
Database triggers in charge of controlling the blockchains are not compromised into the instance.
However there could be the case where a user could try to recreate the blockchains in a separate
database and dump & restore into the production instance.
To avoid this Openbravo runs a background process scheduled on a daily basis that saves into a
hidden and signed file in the filesystem the first and last hashes of each blockchain.
The process also verifies whether these hashes are still available into the database. If they are not
found, it might represent an external alteration of the chain, so an alert is raised to inform about the
security breach.

E. Ticket flow in online mode

The POS terminal (cash register) is a web and mobile client application that works in online mode.
In this mode the flow is:
1. The POS terminal creates and prints the ticket.
2. The ticket, payment information and print datetime is immediately hashed in a blockchain
structure and synchronized with the backend.
3. The backend receives the ticket and payment information which is stored in the backend
database along with the blockchain information (previous hash, hash and timestamp).
F. Ticket flow in offline mode

In case of network failures, the POS terminal can temporarily work in offline mode. The flow in this
case is exactly the same as in the online mode, with the only difference that the synchronization
with the backend takes place as soon as the terminal is back online.
It is important to understand that while in offline mode, POS terminal does not allow to modify
tickets, but to create new ones.
Web POS terminal is not able to work offline more than 72 hours straight.
Companies have the ability to disable offline mode and to work only in online mode.
G. Ticket hash authenticity

Ticket hash is generated using a SHA256 HMAC algorithm based on a secret and the hash of the
previous ticket to ensure hash authenticity and integrity.
This secret is shared between client and server and it is stored encrypted and obfuscated in client
storage and in the jar library backend code.
The JavaScript code in charge of reading the encrypted and obfuscated secret is also obfuscated.
H. Terminal online/offline monitor log

The POS terminal automatically detects when the connection is lost and enters in offline mode,
logging that event. When the system is back to online mode, that event is also logged and the POS
terminal is synchronized with the backend.
That means that the system always keeps track of the POS terminal status (online, offline).
“French Fiscal v 1.0.1000” module will store online/offline log in the database for each Web POS
Terminal, by using the blockchain methodology explained before, therefore this information is
secured and always accessible to the Tax Authorities.

I. Ticket print log

When a sales ticket is printed, the software automatically registers this event and saves it in the
blockchain structure of the POS terminal from where the ticket was printed, the datetime and the
ticket itself.
This information will also be available for the “Tax Authorities”, therefore “Tax Authorities” can know
how many times and when a ticket was printed, as well as from where it was printed.
J. Closing and Aggregation of data per Tax Rate and POS Terminal
Daily aggregation will be automatically launched when running the cash up process from the POS
terminal. Web POS terminals will be forced to run cash up and daily aggregation every day.
“French Fiscal v 1.0.1000” will also allow the user to manually run “periodical” closing by month
and/or year. In case of year aggregation, the user can either select the closing to be executed by
fiscal year or by natural year.
“French Fiscal v 1.0.1000” module will provide a new window where the user can select the desired
closing period and date.
The process will generate cumulative information with the following dimensions:
● POS terminal
● VAT rate
Above means that cumulative information will be calculated by terminal and VAT Rate, up to a
concrete day/month/year.
As part of the aggregation, “French Fiscal v 1.0.1000” module will calculate and store the
“perpetual” amount (i.e. grand total sales amount from January 1st, 2018 to the closing date) per
terminal and VAT Rate.
The aggregated records will be secured in a blockchain structure by terminal, with the same
mechanism as the one explained before for sales tickets.
K. Data export
Any record secured in a blockchain can be exported as XML if required. This includes:
● Tickets with payment and taxes information.
● Print log records.
● Online/Offline monitor records.
● Aggregated/Cumulative information.

Export process will be executed directly in the UI, by using a specific button placed in the window
where the record is shown.
While exporting a record, the user has the possibility to automatically check the record’s integrity
and authenticity. If so the system will automatically:
1. Concatenate previous hash in the blockchain with the XML content to be exported and the
timestamp logged along with the HMAC authentication code.
2. Calculate on the fly the hash of this record using the SHA256 based HMAC algorithm
3. Compare it with the hash stored in the blockchain
4. Show an error in case of mismatch, that would mean that the record has been modified.
L. Archiving
Records created in Openbravo are always accessible directly in the UI. It’s important to understand
that Openbravo never deletes or purges records that are inside a blockchain. Once a record is
saved in the database inside a blockchain structure, it is kept there forever. This behavior allows the
user to easily browse and check old records in the same way as current ones.
Additionally, a new process is included within “French Fiscal v 1.0.0” module to allow:
1. Run an archiving process for a selected date range (maximum of one year).
2. Verify the archiving files integrity & authenticity.
Archiving runs work in the following way:

1. Open the Archiving Process window and select the date range to archive. It can’t be greater
than one year, and the range must be always in the past.
2. A description can be optionally added.
3. Press Done button and the process will start in the background.
4. For each blockchain table in the Openbravo database, the process exports to a CSV file
every record created during the selected date range in this table.
5. It also creates a TXT file with the archiving system information and current date and time.
For each of the CSV files it also included both the HMAC and SHA256 message digest.
6. The TXT and CSV files are included into a ZIP file, which is attached to the POS Archiving
Log window in a blockchain structure. The ZIP file can be directly downloaded at any
moment in time from the POS Archiving Log window.
7. The ZIP file name follows this convention:
<Client Name>-<Date From>-<Date To>-<ZIP file calculated HMAC>.zip
Archiving file verification works in the following way:

1. The ZIP file name ends with the calculated HMAC message digest. Besides each CSV file
HMAC is informed into the TXT file.
2. The user that wants to verify either the ZIP archiving file or a concrete CSV file integrity and
authenticity must open the Archiving Verification window.

3. In this window he must enter the SHA256 message digest for the ZIP/CSV file to verify.
Please note that the SHA256 message digest can also be easily gotten using external tools
if necessary.
4. Optionally he can enter also the expected HMAC available either in the ZIP file name, or in
the TXT file
5. When pressing Done, the system will calculate & print the HMAC for the introduced SHA256
message digest, so the user can easily compare it with the expected one. If both matches, it
means the file hasn’t been compromised.
M. Robustness and auditor’s checks

As explained in the previous points, the records stored in the database are linked to a blockchain by
terminal structure.
Database triggers ensure that blockchains are never altered, by updating or deleting existing
records, or by adding new records in the middle of a chain.
“French Fiscal v 1.0.1000” module will provide five mechanisms to ensure the robustness of the
blockchain and the inalterability of the stored data:
1. A record integrity check while exporting, as explained before.
2. A new window where the user/auditor can enter a stored hash, the content of the record
(XML/JSON) and the timestamp. Once done, the system will calculate the hash and
compare it with the stored one.
3. A new window where the user/auditor can enter SHA256 checksum of any archiving file (ZIP
or CSV) and, optionally, the expected HMAC. Once done, the system will calculate the hash
and compare it with the entered value. Thus the user/auditor can easily check if the archiving
file is correct.
4. A process that will recalculate, for a concrete chain, all of the block hashes based on the
block data, and check that the block hashes stored are valid.
5. A background process always running that detects any corruption or alteration of the
blockchain records in the database. The process stores the first and last hashes in a secret
location in the filesystem and checks whether these hashes are still available in the
database. If the hashes are not found in the database it might represent a security issue, so
an alert is created and sent by email.
Besides, each time a blockchain record is added to the database, the integrity of this record will be
automatically checked as follows:
1. Concatenate previous hash in the blockchain with the record JSON/XML and the timestamp
logged.
2. Calculate on the fly the hash of this record using HMAC.
3. Compare it with the hash stored in the blockchain.
4. Create an alert in the system in case of mismatch, that would mean that the record has been
modified.
5. System Administrator will receive a mail in case an alert has been created.


III. LNE technical requirements implementation

This chapter refers to the second section of the document, that is to explain the way Openbravo
plans to fulfill each LNE Protocol requirements of LNE standard v1.4, through “French Fiscal v
1.0.1000” module, and the regulatory and complementary documentation provided.
For a better understanding of this section, it is highly recommended to read the first section of this
document, as it provides a global vision of our proposed solution.
Please also note that some requirements are duplicates or added details of previous ones. In those
cases the answer given will refer to previous answers.
1: Regulatory documentation.
The cash register system must be accompanied by documentation describing its design,
operation, maintenance and use. The documents listed below are covered by the tax
authorities access rights and are written in French, separately and entitled as follows.
- the OB General Design File version 3.0
- the OB Functional Specifications File version 5.0
- the OB Technical Specification File version 7.0
- the OB Organisational File version 1.0
- the OB Maintenance File version 4.0
- the OB Operational File version 5.0
- the OB User Guide version 8.0
- the OB Tax Authority Guide version 6.0
2: Additional documentation.
Additional documentation comprises all documentation meeting the technical requirements
of the LNE standards version 1.4, that is not part of the regulatory documentation. It is
written in English.
Besides this, a main document is provided, French Certification Master Document v 1.0,
describing the organisation of the documentation and listing the relevant documents,
paragraphs and page numbers for each technical requirement.
- a description of the entire product can be found in the OB General Design File version 4.0
- a description of the part of the sw concerned by the certification can be found in the OB
Technical Specification File version 7.0
- unambiguous identification of the sw can be found in all documentation
- a description of the algorithm used for integrity, security, and unalterability functions can be
found in the OB Functional Specifications File version 5.0
- a description of the user interface, menus, and dialogue boxes can be found in the
Openbravo Web POS User Guide v 2.0

- an overview of the hw associated to the sw or system, such as block diagrams, computer

type, network, and so on can be found in the OB Operational File version 5.0
- an overview of the part of the operating system used, aspects related to the security of the
operating system used, such as protection, user accounts, and privileges, as well as tools,
sw, methods, or algorithms used to strengthen security can be found in the OB Operational
File version 5.0
- the user guide can be found in the Web POS User Guide
- design specifications can be found in the OB Technical Specification File version 7.0
- test plans can be found in the French Fiscal module Test Plan v 4.0
- An explanation of the “French Fiscal” module source code can be found in the OB Source
Code 3.0
3: Data to be recorded
The cash register system must record all payment data related to the execution of a
transaction and its payment. The data must be recorded, at the latest, at the point of
calculating the total amount for the transaction prior to the payment.
Openbravo keeps track of the following information:

● Sales tickets. All the information the printed ticket has, like products, prices, taxes,
payments, full address of the establishment, etc.
● Print log: logs each new print of the ticket with the timestamp.
To review where to find data relating to payments, visit the OB User Guide version 8.0, section
“Ticket Creation”, page 11, and the OB Technical Specification version 7, sections “New Ticket”,
“Ticket Taxes” and “Ticket Reprint”.
4: corrections
If corrections (changes or cancellations) are made to transactions in any way, these
corrections are effected by recording new payment data through “more” or “less”
operations, rather than through direct changes to the payment data recorded.
The way to modify a ticket will be using the existing "Cancel and Replace" functionality, where the
original ticket is kept as it is.
This functionality creates two new tickets:
1. A copy of the original ticket with all the amounts in negative. This is the ticket that cancels
the original one (minus).
2. A new ticket with the correct positive amounts (plus).
Note that the original ticket is already in the blockchain for this terminal so it is never updated. The
two new tickets will also be added to the blockchain ensuring its inalterability.

5: Training/Test mode
Data generated or simulated through a “training”, “test”, “acceptance”, “pre-production” or
other mode or environment that permits the recording of fictitious transactions must be
recorded and secured as payment data but explicitly identified as being issues from this
mode
There is no training/test mode in the Openbravo Commerce suite, therefore this requirement is not
applicable.
6: Annual, monthly and daily closures

The cash register system must include daily, monthly and annual closing functions. The
cash register system mustn’t be able to record new transactions, modify or cancel a
transaction across a closed period.
Openbravo will implement new process that allows the user to accumulate data for the following
frequencies:
● Day.
● Month.
● Year (natural or fiscal year).
The aggregation of data will have the following dimensions:

● POS Terminal.
● Tax Rate.
Each aggregated record (by day, month or year) will include “perpetual” information, up to when this
aggregated record was created.
For example if we close up to February 3rd, 2018, as daily closing, Openbravo will generate:
1. As many records as terminals.
2. For each terminal, as many records as tax rates.
3. And finally for each of the records by terminal and tax rate, the system will store:
a. February 3rd, 2018 cumulative data.
b. Perpetual data from January 1st, 2018 to February 3rd, 2018 (February 3rd, 2018
included).
Daily closure is done automatically by the cash register system.
Monthly and annual closures must be done manually by the user. The user is notified of the need to
perform the monthly and annual closures in the OB User Guide version 8.0.

7: Cumulative and summary data

For each closing, the cash register system must record the cumulative total for the period
and the perpetual total like any other payment data.
For cumulative data we will also use the same algorithm for hash calculation and blockchain
explained in the next section (see #8 ).
See #6 for an example about calculating cumulative and perpetual data.
Closures include cumulative total for the period and perpetual total.
Counter is never reset to 0 in case of updating the POS.
Count is reset to 0 just in case the POS is changed by a new one.
8: Data inalterability
All payment data defined in the previous requirements must be conserved and secured in
such a way that it cannot be altered.
The mechanism we use to ensure inalterability of data is blockchain methodology, where each
record is linked to the previous record within each POS terminal. Besides, database triggers will
ensure no modifications in the blockchain are allowed.
Our algorithm for hashing will:

1. Take previous calculated hash for the linked record within the terminal.
2. Create a XML representation of the current record (ticket, aggregation of data, closure, etc.).
3. Take the timestamp when this hash is going to be generated.
4. Concatenate the 3 registers and create a hash by using HMAC SHA256 algorithm.
5. Store inside the database previous hash + current hash + timestamp.
This process will be automatically executed when synchronizing a ticket from the POS terminal to
the central server.
In online mode this process is executed as soon as the ticket is printed.

In offline mode the hashing of the ticket is executed as soon as the ticket is printed, but the
synchronization and storage in the backend database will be executed as soon as the terminal is
back to online mode. Web POS terminal is not able to work offline more than 72 hours straight.
Data is conserved and secured in a hash chain using a fingerprint mechanism with key
(HMAC-SHA-256).
Several mechanisms are included to verify the integrity of the recorded data. Also a protective
mechanism against data being restored to a previous state is included.
There will be a process that checks from the beginning of the chain, that each record in the chain
hasn’t been altered.
The way to do this is to calculate the hash of the very first record in the chain and keep on
calculating the hash of the rest of the records, by following the chain order,
This process will be a manual process that can be launched at any time.
These are some optional parameters when launching the process:

● Terminal.
● Entity: Ticket, Ticket line, etc.
Besides, a new window will be available where the user can manually specify:
● Previous HASH (mandatory field)
● XML content (mandatory field)
● Timestamp (mandatory field)
● HASH (optional field)
● Calculated HASH (read only field). Openbravo will calculate the HASH with the algorithm
explained in previous points.
The user can either manually check it is the same as the original hash or he can enter the expected
HASH so the system can compare it with the calculated one and show an error if mismatch.
Finally, there is a background process always running that tries to detect any alterability in the
database. It stores the first and last hashes for each entity in a secret place on the filesystem and
tries to find them back in the database. If not found it might represent a database alteration, so an
alert is created.
9: Securing receipts
The cash register system must allow to unequivocally identify and distinguish receipts
issued prior to payment between those issued after the payment has been made. Any receipt
that is reprinted should bear the word “duplicata” [duplicate]. The system must provide

secure traceability of receipts (both definitive and provisional) printed and reprinted. The
information included in the receipts must be consistent with the payment data recorded
securely by the cash register system.
Receipt template has been modified to highlight and therefore distinguish "unpaid" receipts, from
"paid" receipts". Same way receipts template has also been modified to add the word “duplicate”
whenever a receipt is re-print.
Every time a provisional or definitive ticket is printed or reprinted, a new record is added to the
blockchain structure and secured as explained in section #8. This record includes the POS terminal
from where the ticket was printed, the datetime and the ticket itself.
10: Data archiving

The cash register system must provide an archiving function intended for users enabling the
export of uneditable, time-stamped payment data in an open format. In the event of a change
of cash register system, the cumulative and summary data must be archived.
Each record (either individual or aggregated) always has creation and update dates by default.
All records are stored in the database using an immutable blockchain structure. See Hashed
blockchain as security mechanism section.
Old records are always available and linked to the same blockchain and tables than current records.
Records are never deleted.
Openbravo will provide an archiving process. When the archiving process is run, a log is created in
the database using the blockchain structure. This log stores the date range that has been archived,
the ZIP file name created, the previous hash and timestamp used in the hashing of this archiving
and the HMAC generated for this archiving.
Archiving ZIP file also includes a TXT file with information about the system and the date and time
when this archiving was run.
See Archiving section for details.
11: Archiving frequency

The archiving function must enable users - at any point in time - to access or generate
archives for any past period of time. The period of time covered by one archive should not
be greater than one calendar year or one tax year.
See #10 above

Each archiving is logged in a database using a blockchain structure, storing the range dates
archived (always less or equal than a year), the path of the archiving file created and the date and
time when the archiving was run. The archiving file name also provides, as part of the name, the
range date that includes.
12: Archiving integrity

The data contained in the archive must be identical to the original uneditable data from
which it was created and the archive must include a reliable mechanism that is independent
of the archive conservation medium, guarantees this integrity and permits checking.
The integrity and security of the records in the blockchain can always be checked in three different
ways: when exporting the records, by using a window where the hash is calculated on the fly and
can be compared to the stored one, and by checking the blockchain integrity from the first to the last
record in the chain. See Robustness and auditor’s checks and condition #10 for details.
Every archiving is logged in the database using a blockchain structure.
It is also possible to verify the integrity of an archiving file at any moment, generating again the
SHA256 hash for it and comparing with the hash stored in the Archiving Log blockchain through the
Archiving Verification window.
The archives can be accessed and downloaded directly by the Openbravo UI in the POS Archiving
Log window, or alternatively connecting to the server by a system administrator and a secure SSH
connection.
Archiving exports database records to CSV files, in a format that is readable by a human. CSV files
are compressed in a ZIP file in the system itself.
In case of an audit, it is possible to download the ZIP file from the system, extract it using the
original password and read the CSV files.
The tickets are visible in JSON format contained in the CSV mentioned above.
The JSON can be made easily readable by using the site http://jsonviewer.stach.hu by clicking on
the "Format" tab.
The following variables correspond to the important data contained in the tickets:
● "Product" for products
● "Deletedlines" for add / delete movements.
● “Deletedpayments” for add / delete payments.

● "Taxes" for the details of each type of tax.

● "Orderdate" for the order date
● "Description" for product labels
● "Qty" for quantities
● "Price" for prices
● "Currency $ _identifier" for the currency used
● "Posterminal $ _identifer" for the used terminal
● "Documentno" for the ticket number generated
● "BP" for user information
13: Purge
If the cash register system has a payment data purge function associated with the need to
free up memory, this must compulsorily generate an archive containing all of the payment
data to be purged and conserve it pursuant to Requirement 17 below, prior to performance of
the purge.

Openbravo never deletes data. No purge procedure exists.
14: Partial Purge

The purge function must not delete cumulative and summary data or operation traceability
data from the cash register system. This data must remain conserved for an indefinite
period of time, and must be secure, in the cash register system.
Openbravo never deletes data. No purge procedure exists.

All records are always available in the database. Archives are retained in the system itself.
15: Operation traceability

The cash register system must provide secure traceability of archiving, purging and data
recovery operations by logging the time, date and identifier of the POS used for the
operation, on the system, for each of these operations.
Archiving operations are recorded in the system including the date and time when the operation was
done, as well as the POS used.
This archiving log data is conserved and secured in a hash chain using a fingerprint mechanism
with key (HMAC-SHA-256).

Several mechanisms are included to verify the integrity of the recorded data.
16: Data conservation

All payment and traceability data as well as evidence of its inalterability must be stored for
six years (from the date of the final transaction of the tax year). Cumulative and summary
data as well as traceability data must be stored in the system. Payment data (excluding
cumulative, summary data and traceability data) may be conserved in either the system itself
or in the archives
Individual records (payment data), cumulative, summary and traceability data is never removed from
the system. Besides that all of them are secured by the blockchain algorithm. See previous points
for details (#8 and #6 ). Same applies to archiving records. See Archiving section for details.
Besides the above, Openbravo never deletes old data. Old records are always available in the
database and UI.
Anyway, hardware minimum requirements are described in OB Operations Manual v 4.0 document
to ensure data is retained with no disk space problem for both Openbravo deployment options
“Cloud” and “On-Premise”. The size of the estimated database for a 6-year period is about 3.25 TB
for the largest client of the "Cloud" version. This one is managed internally and can not arrive at
saturation, the storage space being monitored every day internally with a margin of error
consequence of several GB.
On the "On-Premise" version it is up to the customer to check the available disk space on the server
and the terminals. This must comply with the minimum technical requirements specified in the
documentation (see Operating Manual v4.0).
In the rarest cases, a server with 160 GB of disk space for 10 terminals can cover 6 years of data at
a rate of 5 MB per day and per terminal (which gives about 11GB).
160 GB is the minimum recommended by Openbravo in the documentation.
17: Archive conservation

Archives must be conserved in such a way as to guarantee the integrity and availability of
the archived data for inspection, for six years (starting from the date of the final transaction
for the tax year).
Openbravo never deletes data. All records are always available in the database. No purge
procedure exists. Archives are retained in the system itself. The archives can be accessed and
downloaded directly by the Openbravo UI in the POS Archiving Log window, or alternatively
connecting to the server by a system administrator and a secure SSH connection.

18: Centralised system

When data conservation is ensured via a centralised system, the cash register system must
include reliable mechanisms demonstrating the completeness and traceability of payment
data transmissions. The system must be capable of managing a dropped connection
between the centralised system and the terminals and ensuring that the POS terminals
cannot carry on functioning indefinitely without a connection to the centralised system
Communications between the terminals and the main server must be done via secure HTTPS
connection.
The system provides a log about the online/offline status per terminal (see Terminal monitor
online/offline log section).
In online mode, sales tickets are immediately synchronized with the backend (see Ticket flow in
online mode section).
In offline mode, sales tickets are synchronized with the backend as soon as the terminal is back
online.During the offline mode it’s not allowed to modify or delete tickets.
Web POS terminal is not able to work offline more than 72 hours straight.
See Ticket flow in offline mode section for details
By definition, ticket document sequence by terminal can’t have gaps, so ticket numbers are always
correlative. Backend stores the timestamp when the ticket was created in the POS terminal and the
timestamp when it was synchronized with the backend.
The authorities will be provided with a role (see Tax Authority access for details), that allows full and
real time access to the synchronized tickets and the online/offline monitor log, both stored in a
secure blockchain structure. With this information tax authorities can verify current and past status
for each terminal.
19: Tax authority access to payment data.

The cash register system must provide a mechanism allowing the tax authority access to all
of the payment data recorded. The editor must provide the tax authority with an automated
means of checking the integrity of the payment data. The manufacturer must provide the
relevant tax authority with a user manual in French that gives details of the procedure for
accessing the data as well as a clear description of the operation of the tools used to access
this data and check its integrity. This access shall not compromise the security of the
payment data.

A new role for Tax Authorities will be created with read only access to all payment data. This role
will also be allowed to run every integrity verification mechanism.
When exporting data, such a role will have the possibility to check the integrity of the exported
records. To do that, when exporting each record, the exporting system will calculate on the fly the
hash using our hashing algorithm based on HMAC, and it will compare it with the hash stored in the
database. In case both hashes are not equal, the process will throw an exception informing the user
about the inconsistency.
See Tax Authority access section for details
Finally, a user manual in French will be provided, describing all details of the procedures for
accessing the data as well as a clear description on how to access this data and check its integrity.
For additional information please review OB Tax Authority Guide version 6.0
20: Identifying the fiscal scope

The editor must clearly define the fiscal scope of their cash register system and list all of the
source code files, libraries, drivers and modules impacting the functions and requirements
set forth in this standard.
See New Module section for details, and the OB Technical Specification File version 7.0.
21: Identifying major and minor versions

The cash register system must be clearly identified by a major version number and a minor
version number inextricably linked to the cash register system. These version numbers must
be easily accessible from the cash register system’s standard user interface.
Any change to the code in the fiscal scope or configuration affecting compliance with the
requirements in this standard must result in an increase of the major version number. The
editor must generate and provide the fingerprint of each major version.
Openbravo solutions are released on a quarterly basis. In the case of the Openbravo Commercial
Suite (Openbravo for Retail) versions are released as 3.0RRXXQY, where:
● XX is the year
● and QY the quarter of the year.
Each of those quarterly releases are linked to a corresponding major version and minor version as
“1.8.XXXX”, where:
● 1.8 is the major version
● and XXX are the minor versions

For additional information, review the Openbravo Release Notes wiki page.
Openbravo solutions are built on a platform that provides a core set of technologies that allow
extending Openbravo to fit business needs or even legal requirements, through modularity.
A module is a piece of additional functionality that can be deployed on top of Openbravo solutions.
Examples of modules are those required to properly adapt Openbravo to different languages and
legal or fiscal requirements.
Therefore, and as already mentioned in the section "New Module", all the requirements related to
the French Finance Law mentioned above, will be implemented and therefore distributed as a
module to be installed by any retail company operating in France.
This new module will be named “French Fiscal” module. Starting from its version 1.0.0, French
Fiscal module will enable Openbravo Commerce Suite, starting from its version 3.0RR18Q4:
1.8.3901, to support inalterability, security, retention and archiving conditions required by the French
Tax Authorities.
The source code of the “French Fiscal'' module is the code certified by the LNE, and therefore
represents the fiscal scope of Openbravo cash register system.
French Fiscal module is released as 1.0.XXXX, where:

● 1.0.1000 is the major version
A verification mechanism will be included to check that no change has been done in the fiscal scope
of the module. For additional information see the OB Technical Specification File version 7.0,
section Module Verification.
These version numbers can be accessible from the cash register system’s standard user interface,
after log in, by using the menu option “Backoffice”. Once in there, the user will have to navigate to
the menu options “Help” and then “About”.

OB Functional Specification File v6.0

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OB Functional Specification File v6.0

Uploaded by

Copyright:

Available Formats

Functional Specification File ​v 6.

French Fiscal Certification

Functional Specification File ​v 6.0

« ​French Fiscal v 1.0.1000​ ​»

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 1 / 24

1.0 Victor Martinez Nov 3rd, 2017 Initial version

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 2 / 24

LNE technical requirements implementation

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 3 / 24

14: Operation traceability

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 4 / 24

The document is split in two main sections:

More information can be found in our ​home page​ and ​wiki​.

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 5 / 24

II. General solution

B. Tax Authority access

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 6 / 24

C. Hashed blockchain as security mechanism

The general algorithm to store any entity in a blockchain will be:

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 7 / 24

E. Ticket flow in online mode

F. Ticket flow in offline mode

G. Ticket hash authenticity

H. Terminal online/offline monitor log

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 8 / 24

I. Ticket print log

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 9 / 24

Archiving runs work in the following way:

Archiving file verification works in the following way:

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 10 / 24

M. Robustness and auditor’s checks

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 11 / 24

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 12 / 24

III. LNE technical requirements implementation

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 13 / 24

- an overview of the hw associated to the sw or system, such as block diagrams, computer

Openbravo keeps track of the following information:

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 14 / 24

6: Annual, monthly and daily closures

The aggregation of data will have the following dimensions:

Daily closure is done automatically by the cash register system.

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Author: Victor Martinez Last Mod: Oct 2020 Página: 15 / 24

7: Cumulative and summary data

Counter is never reset to 0 in case of updating the POS.

Count is reset to 0 just in case the POS is changed by a new one.

Our algorithm for hashing will:

In online mode this process is executed as soon as the ticket is printed.

Proyect: French Fiscal Certification Customer: LNE Version: 6.0

Functional Specification File v 6.

Functional Specification File v 6.0

« French Fiscal v 1.0.1000 »

More information can be found in our home page and wiki.

See Archiving section for details.

See #10 above

See Archiving section for details.

See Archiving section for details.

See Tax Authority access section for details