OB Tax Authority Guide v6.0

Tax Authority Guide v 6.
French Fiscal Certification
Tax Authority Guide v 6.0

« Openbravo Commerce Suite 3.0RR19Q3: 1.8.4503 »
« French Fiscal v 1.0.1000 »
Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0
Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 1 / 23

Version Control
Version Author Date Change
1.0 Álvaro Ferraz Torres March 1st,2018 Initial version
2.0 Álvaro Ferraz Torres May 11th, 2018 Document updated with correct template and versioning
3.0 Álvaro Ferraz Torres June 5th, 2018 Module Verification updated
4.0 Víctor Martínez Romanos Feb 5th, 2019 Adaptations required after first certification process
5.0 Álvaro Ferraz Torres Nov 28th, 2019 Add Blockchain Issue window
6.0 Patricia San Juan Oct 30th, 2020 Minor versions updated

Table of Contents
Version Control
Table of Contents
Introduction
Purpose of the document
Overview
Menu
Ticket creation
Ticket Reprint creation
Ticket Aggregation creation
Terminal Monitor creation
Archiving creation
Blockchain verification
Ticket verification
Blockchain verification
Blockchain export
Hash verification
Archiving verification
Module verification
Database securitization
Data retention
Blockchain issues

I. Introduction
B. Purpose of the document
This user oriented document has been designed with the aim of guiding Tax Authority users
through the process of learning how to use French Fiscal v 1.0.1000 module.

Openbravo agrees to keep the regulatory documents until the end of the third year following the
year in which the software or cash system ceases to be released.

C. Overview
French Fiscal v 1.0.1000 module is designed to provide “Openbravo Commerce Suite 3.0RR19Q3:
1.8.4503” with the features to fulfill conditions of immutability, security, retention and archiving of
data for tax administration audit matters, as per new French Tax Code law, starting from 1st of
January of 2018.


II. Menu
French Fiscal v 1.0.1000 module provides a new menu integrated in Openbravo ERP called “French
Fiscal” where every new window and process can be accessed.
III. Ticket creation

When creating new tickets from an initialized POS terminal, they will be added to the blockchain
together with the tax information.

POS Ticket window will show the data of every ticket created from each POS terminal.
Ticket tab shows the information of the ticket created in the POS terminal.
● Organization: store of the POS terminal where the ticket was created.
● POS Terminal: POS Terminal where the ticket was created.
● Sales Order: Sales order created by this ticket.

● Ticket Date: Date and time when ticket was created in the POS Terminal.
● Sequence Number: Sequence number indicating the place of this record in the blockchain.
● Previous Hash: SHA256 hash of the previous record in the blockchain.
● Hash: SHA256 hash value calculated from previous hash, ticket json and hash time.
● Hash Time: Timestamp indicating the date and time when the hash was calculated.
Ticket Tax tab shows the ticket taxes information.
● Rate: Tax rate shown in printed ticket.

● Taxable Amount: Tax rate base shown in printed ticket.
● Tax Amount: Tax rate amount shown in printed ticket.
● Hash: SHA256 hash value calculated from previous hash, record XML and hash time.
IV. Ticket Reprint creation

The first time a ticket is printed is actually the moment when the ticket is created in the POS
terminal. At this moment, this ticket will be included in the blockchain structure and will be shown in
the POS Ticket window.
We can later load again in the same POS terminal or in a different one this ticket, and print it again,
in order to have a copy of it. This reprint will be also included in the blockchain structure.

POS Ticket window will show the reprint information of a ticket in the Ticket Reprint tab.
● Organization: store of the POS terminal where the ticket was reprinted.
● POS Terminal: POS Terminal where the ticket was reprinted.
● Print Date: Date and time when ticket was reprinted in the POS Terminal.

V. Ticket Aggregation creation

It is possible to aggregate POS tickets daily, monthly or yearly and generate cumulative information
by POS terminal and tax rate. This aggregated information will be also included in the blockchain
structure.
Once we have launched a daily, monthly or yearly aggregation, new records will be created in the
POS Ticket Aggregation window.

Ticket Aggregation tab shows the information of the aggregations created from POS tickets.
● Organization: store of the POS terminal where the aggregation tickets were created.
● POS Terminal: POS Terminal where the aggregation tickets were created.
● Aggregation Frequency: Frequency type of the ticket aggregation: daily, monthly or yearly.
● Aggregation Date: In case of daily aggregation, date of the ticket aggregation.
● Aggregation Month: In case of monthly aggregation, month of the ticket aggregation.
● Aggregation Year: In case of monthly aggregation, year of the ticket aggregation.
● Year: In case of yearly aggregation, fiscal calendar year of the ticket aggregation.
● Starting Date: Starting date of the period aggregated.
● Ending Date: Ending date of the period aggregated.

Daily tab shows the daily ticket tax aggregation information.
● Rate: Tax rate for which daily aggregation has been calculated.
● Taxable Amount: Sum of the taxable amounts with this tax rate of every ticket aggregated
in this period.
● Tax Amount: Sum of the tax amounts with this tax rate of every ticket aggregated in this
period.
● Total Aggregation: Sum of the taxable and tax amounts with this tax rate of every ticket
aggregated in this period.
● Cumulative Total Aggregation: Cumulative sum of the taxable and tax amounts with this
tax rate of every ticket aggregated from 1 January 2018 until this period.
Monthly tab shows the monthly ticket tax aggregation information.
● Rate: Tax rate for which monthly aggregation has been calculated.
in this period.
period.


Yearly tab shows the yearly ticket tax aggregation information.
● Rate: Tax rate for which yearly aggregation has been calculated.
in this period.
period.
VI. Terminal Monitor creation

Once a POS terminal has been initialized, it will record in the blockchain a log every time the
terminal goes online or offline. Thus, we can know the periods when a POS terminal has been
working offline.

This information is shown in the POS Terminal Monitor window.
● Organization: store of the POS terminal where the log was created.
● POS Terminal: POS Terminal where the log was created.
● Terminal Date: Date and time when log was created in the POS Terminal.
● Is Online: Flag indicating if POS terminal went online or offline at this moment.
VII. Archiving creation

Archiving process will allow to export blockchained data created within a selected date range from
the database. The range can’t be greater than one year and, obviously, it’s not allowed to archive
dates in the future.
Archiving must be run from the Archiving Process window:
When launching it, French Fiscal Archiving process will start and the Process Request window will
be opened showing the process status and log.
Please note that this process doesn’t allow concurrent executions, so you might need to wait till the
previous execution is finished before trying to launch a new archiving process.

The archiving process will create a ZIP file with one CSV file per each French Fiscal table. The file
name will always follow the convention:
<Client Name>-<Start Date>-<End Date>-<HMAC digest>.zip
Each CSV will contain every record created in the selected date range in this table. This file can be
imported in any spreadsheet program, like LibreOffice Calc.

The ZIP file will also contain a TXT with some information about the archiving system and the date
and time when the archiving process was run. It also adds the SHA256 and HMAC messages digest
for each of the CSV files, that will be very useful when verifying the files integrity and authenticity.
Each archiving run will be logged in the database in a blockchain structure.

This information is shown in the POS Archiving Log window.
● Archiving Path: Absolute path of the archiving file in the system.

● Hash: SHA256 hash value calculated from previous hash, archiving file content and hash
time.
● Starting Date and Ending Date: D
ate range (both inclusive) for the archiving record.
In order to access the archives, users can directly download from the Attachments section.
VIII. Blockchain verification

There are many different mechanisms to ensure the integration of the blockchain structure that can
be run at any time.
A. Ticket verification
Every time a ticket is created in the POS terminal and synchronized with the server its integrity is
checked once again in the server. The verification is done by hashing the previous hash available in
the database, new ticket and timestamp, and comparing it with the calculated hash on the POS
terminal. If both calculated hashes match, the record is finally saved into the blockchain structure;
otherwise an alert is automatically created and, if configured, sent by email to the system account.
B. Blockchain verification
The Blockchain Verification process allows to verify the whole blockchain structure for any
blockchain entity, POS terminal and starting from any date.

This process can be run from the Blockchain Verification window.
● Blockchain Entity: Tells the entity blockchain that will be verified. If empty, it will be verified
the blockchain of every entity: OBCFR_Ticket, OBCFR_TicketTax, OBCFR_TicketReprint,
OBCFR_Ticket_AggDay, OBCFR_Ticket_AggMonth, OBCFR_Ticket_AggYear and
OBCFR_TerminalMonitor.
● POS Terminal: Tells for which POS terminals will be verified by the blockchain. If empty, the
process will be run for every terminal within the current client.
● Starting Date: Specifies the date since the blockchain will be verified. If empty, the
blockchain will be verified starting from 1 January 2018.
When launching it, Blockchain Verification Background process will start and the Process Request
window will be opened showing the process status and log.
This process will regenerate the hole blockchain for each entity and POS terminal selected, starting
from the selected date.
For each record in the blockchain, it will recalculate the record hash from the previous record hash,
the record JSON/XML representation and the record hash time.
If this hash is different from the stored one, an error will be shown in the process log for this record.

C. Blockchain export
It is also possible to export data of any blockchain entity from POS Ticket, POS Ticket Aggregation
and POS Terminal Monitor windows.
Once you select a record in any of these windows, you can click on the Export button.
● Verify Record Integrity: If checked, the JSON/XML file will be downloaded only if the record
integrity is successfully verified.
This export action will download a JSON or a XML file, with the information of a record in the
blockchain structure.
In the case of Ticket entity, the file will be a JSON. This is the ticket representation generated in the
POS terminal client, sent to the back office, stored in a database and used to generate the hash of
the ticket.
In case of any other blockchain entity (Terminal Monitor, Ticket Tax, Ticket Reprint, Ticket Daily
Aggregation, Ticket Monthly Aggregation or Ticket Yearly Aggregation), the file will be an XML. This
is the record data representation used to generate the hash of this record.
It is also possible to verify the integrity of the record being exported. If this option is checked, record
hash will be recalculated from the record previous hash and hash time and the JSON/XML being
downloaded. If this hash is different from the stored one, the file will not be downloaded and an error
will be raised.
D. Hash verification
If you want to check the hash generated by a JSON/XML file, you can use the Hash Verification
process.

This process can be run from the Hash Verification window.
● JSON/XML: JSON (for Ticket entity) or XML (for any other blockchain entity) record
representation that can be exported from any blockchain record.
● Hash Time: Timestamp indicating the date and time when the record hash was calculated.
● Previous Hash: SHA256 hash of the previous record in the blockchain. If empty, it will be
null.
● Hash: Record SHA256 hash. If not empty, the calculated hash will be compared with this
one.
When running this process, a new hash will be calculated from the previous hash, JSON/XML and
hash time.
If the hash parameter is empty, the calculated hash will not be compared and a success message
will be shown with the calculated hash.
If the hash parameter is not empty, the calculated hash will be compared with the entered one and a
success message will be shown with the calculated hash in case they are the same. In case they
are different, an error message will be shown together with the calculated hash.
E. Archiving verification
Users can check the archiving files integrity and authenticity at any moment in time using the
Archiving Verification window.
The archiving ZIP file name ends with the calculated HMAC message digest. Besides the CSV file’s
HMAC and SHA256 message digest are informed into the TXT file. Example:
TheWhiteValleyGroup_01-01-2018_31-12-2018_e2b3bdcede57342774b674fc0ff60779f51263dec709275405f8403328b3
7016.zip
OBCFR_Ticket.csv:
f39a1be53825a9a03bb2afb3a9ffd13906de22d3bb308d7d085bf5bbf14a1993 (SHA256)
fe215309a7a5a791322bcc6fb1cd3142806aea0f687d5e0b507b67a6b8a00bdd (HMAC)

OBCFR_TicketTax.csv:
a2184a43f369974503c56b222f9a4df917d8d86c05bc9fadb87ae4409627793e (SHA256)
df29f5e0fe35dd2e833056e1cd0a3cb59047565c5286c04cb34a7e7a1fa3b3d2 (HMAC)
Anyway the SHA256 message digest of a file can be easily gotten using, for example, the
sha256sum command. Example:
$ sha256sum TheWhiteValleyGroup_01-01-2018_31-12-2018_e2b3bdcede57342774b674fc0ff60779f51263dec709275405f8403328b37016.zip
3df9fc557fcfca49de0cc4b9ffc5397cd5648a7c29d2b5738991bae39ad7ff85
TheWhiteValleyGroup_01-01-2018_31-12-2018_e2b3bdcede57342774b674fc0ff60779f51263dec709275405f8403328b37016.zip
To verify the integrity of an archiving file created by Openbravo, the user just needs to enter the
file’s SHA256 message digest into the Archiving Verification window and run the process. The
system will return the calculated HMAC for this SHA256 hash.
Optionally the user can also enter the expected HMAC and the system will automatically compare it
with the calculated one and will show an error or success message. Example:
F. Module verification
Finally, we have a process to verify the integrity of the French Fiscal module and check no change
has been done to the module source code.
This process can be run from French Fiscal Module Verification window.

When launching it, French Fiscal Module Verification Background process will start and the Process
Request window will be opened showing the process status and log.
The process will calculate a hash from every file within French Fiscal module containing source
code (Bash, Java, SQL and Javascript).
These are the folders with source code files inside French Fiscal module: bin, src,
src-db/database/model and web.
The hash will be calculated from the concatenation of all these files and it will be compared with the
hash stored in the update information field of the French Fiscal module definition, in
src-db/database/sourcedata/AD_MODULE.xml file.
A success message will be shown if the hash is the same. In case they are different, an error
message will be shown.
G. Database securitization
The Openbravo instance has a security mechanism to ensure your database is not replicated,
manually modified and restored back into the instance, thus compromising the blockchain integrity.
You don’t need to do anything to configure this mechanism; it’s always enabled and it can’t be
deactivated.
If the process detects anything that might mean a security breach into your database, it will
automatically create an alert informing about the problem. If you receive an alert like this, you must
immediately inform the System Administrator that will take the necessary actions.

IX. Data retention

There are two options to deploy Openbravo, Openbravo Cloud or On-premise instances.
Openbravo cloud is a single-tenant platform as a services option that enables businesses to deploy
Openbravo solutions on virtual servers in Amazon Web Services (AWS). It can only be subscribed
in combination with an Openbravo Professional or Enterprise edition. This is Openbravo's
recommended deployment option. If choosing Openbravo Cloud option, Openbravo Cloud
operations will be in charge of the complete technical operation (operating system, database,
system software stack (server), backups policy). For additional information please review
Openbravo Operations Manual v 4.0, section “Openbravo Cloud”.
If an Openbravo client chooses to set up Openbravo on premise, that implies that Openbravo does
not host that instance but the customer. Therefore Openbravo is not responsible for backups and
restoration policies within that environment, neither database access control procedures or
database management.
In such instances, it is under the responsibility of the company using the system to keep the data
well securely stored and make sure that backups can be recovered from periodically. In other
words, the company using the system must be aware of data retention responsibility within the
scope of cash register systems legislation requirements in France.
According to that, Openbravo enforces the creation of backups at least on a daily basis and
according to the Openbravo instructions that can be found in this Openbravo wiki page Backups.
In summary, in order to configure a good backup policy of your instance, Openbravo recommends
to follow below listed steps:
1. Edit the configuration file for backups.

2. Set a schedule to perform the backups automatically, at least on a daily basis.
3. Select how many automatic backups to store.
4. As backups must be stored on different hardware, preferably on a remote storage as the
way to protect data against events such as fires or other situations which could destroy
locally store backups, it is required to configure a remote location to synchronize/copy the
backups.
5. Make sure that your company insures data retention over time by using hardware
redundancy.
For additional information please review Openbravo Operations Manual v 4.0, section “Openbravo
On Premise”.

X. Blockchain issues
In case any of the verification mechanisms raises an issue in one of the blockchains, it should be
reported in the Blockchain Issue window and informed to LNE as soon as possible.
In order to report the acknowledged issue in the application, the Add Blockchain Issue process must
be run.
This process can be run from Add Blockchain Issue window.
● Blockchain Entity: Tells the entity blockchain where the issue was found: OBCFR_Ticket,
OBCFR_TicketTax, OBCFR_TicketReprint, OBCFR_Ticket_AggDay,
OBCFR_Ticket_AggMonth, OBCFR_Ticket_AggYear, OBCFR_TerminalMonitor or
OBCFR_ArchivingLog.
● POS Terminal: Tells the POS terminal where the issue was found. This field will be empty
only in case the issue is reported in OBCFR_ArchivingLog entity.
● Description: Description of the issue found in the blockchain entity.
When launching it, a new record will be created in the Blockchain Issue window, registering the
described issue and resetting the entity blockchain.
The Blockchain Issue window will show the information about any issue found in blockchain
entities.
● Organization: store of the POS terminal where the issue was found.
● Blockchain entity: entity where the issue was found.
● POS Terminal: POS Terminal where the issue was found.
● Issue Date: Date and time when the issue was reported.
● Broken Sequence Number: Sequence number of the record with the reported issue.
● Description: Description of the issue.

The next time a record is added to this blockchain entity, the hash will be calculated without taking
into account the hash of the previous record in the chain.
Thus, blockchain will be fixed starting from this point and verification processes will not raise new
errors with next records.

OB Tax Authority Guide 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 Tax Authority Guide v6.0

Uploaded by

Copyright:

Available Formats

Tax Authority Guide ​v 6.

French Fiscal Certification

Tax Authority Guide ​v 6.0

« ​French Fiscal v 1.0.1000​ ​»

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 1 / 23

1.0 Álvaro Ferraz Torres March 1st,2018 Initial version

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 2 / 23

Ticket Reprint creation

Ticket Aggregation creation

Terminal Monitor creation

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 3 / 23

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 4 / 23

III. Ticket creation

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 5 / 23

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 6 / 23

Ticket Tax​ tab shows the ticket taxes information.

● Rate​: Tax rate shown in printed ticket.

IV. Ticket Reprint creation

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 7 / 23

V. Ticket Aggregation creation

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 8 / 23

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 9 / 23

Daily​ tab shows the daily ticket tax aggregation information.

Monthly​ tab shows the monthly ticket tax aggregation information.

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 10 / 23

● Previous Hash​: SHA256 hash of the previous record in the blockchain.

Yearly​ tab shows the yearly ticket tax aggregation information.

VI. Terminal Monitor creation

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 11 / 23

This information is shown in the POS​ Terminal Monitor​ window.

VII. Archiving creation

Archiving must be run from the Archiving Process window:

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 12 / 23

<Client Name>-<Start Date>-<End Date>-<HMAC digest>.zip

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 13 / 23

Each archiving run will be logged in the database in a blockchain structure.

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 14 / 23

This information is shown in the POS​ Archiving Log​ window.

● Archiving Path​: Absolute path of the archiving file in the system.

VIII. Blockchain verification

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 15 / 23

This process can be run from the Blockchain​ Verification​ window.

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 16 / 23

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Autor:: Alvaro Ferraz Torres Últ. modifica.:: Oct 2020 Página: 17 / 23

This process can be run from the Hash​ Verification​ window.

Proyecto:: French Fiscal Certification Cliente: LNE Versión: 6.0

Tax Authority Guide v 6.

Tax Authority Guide v 6.0

« French Fiscal v 1.0.1000 »

Ticket Tax tab shows the ticket taxes information.

● Rate: Tax rate shown in printed ticket.

Daily tab shows the daily ticket tax aggregation information.

Monthly tab shows the monthly ticket tax aggregation information.

● Previous Hash: SHA256 hash of the previous record in the blockchain.

Yearly tab shows the yearly ticket tax aggregation information.

This information is shown in the POS Terminal Monitor window.

This information is shown in the POS Archiving Log window.

● Archiving Path: Absolute path of the archiving file in the system.

This process can be run from the Blockchain Verification window.

This process can be run from the Hash Verification window.

This process can be run from Add Blockchain Issue window.