Reflexion on the french SAPIN LAW application

[flotho]

Dear Community,

I would like to start a thread regarding the SAPIN french law. From now the french administration is not really explicit about the ways to certify the Odoo solution. Does anyone has some legal info?

Here are some of the resources I found :

• http://revuefiduciaire.grouperf.com/article/3661/hb/20160919173548859.html
• https://www.april.org/point-detape-sur-la-nouvelle-reglementation-des-logiciels-de-gestion-et-de-comptabilite

Some part of the law seems to be easy to certify : Hosting / Backup / Recovery are easy for the community partners to be certified.

Regarding the durability of the datas I think we have a problem with the POS. From now the POS has been designed to be working without network and all the datas are stored inside the browser database. This point could be an issue if you consider how easy it is to get the datas from the internal database (and what about the debug mode allowing to flush the orders!!!) I have some little ideas on those points :

• Find a way to block some inappropriate operation from the POS (like in debug mode)
• Find a way to store every transaction in the POSBox from the POS
• Find a way to protect the browser database with encryption
• Find a way to deliver browser application with options preventing the user from acceding to the internal database.

None of those solutions looks enough for me(everything in the client part could be changed by an experienced user/ ethic hacker).

Odoo seems to have started a reflexion on this : https://github.com/odoo-dev/odoo/commits/9.0-l10n_fr-certification-lpe . It looks like Odoo is considering that only the account_cancel module could be a problem.

Some partners have started a reflexion, (BTW thanks to Sébastien Morelle) : https://anybox.fr/blog/logiciels-de-caisse-certifies

Maybe we could start a thread here https://odoo-community.org/groups/france-24

Any feedback would be appreciated.

Regards

[fgi-odoo]

@jcchoquet Yes as we said the module will be released before, as well as the access to the Odoo certificate.

The POS payments are saved in draft payment statements. The idea is to lock such statements to not edit them. When the POS session is closed by the user, those statements are confirmed and posted. I think it's fine to compute cumulative payment amounts on confirmed journal entries only, and not on unconfirmed payment POS statements. Otherwise it would make the logic complex. What's your opinion on that?

Regarding the payments registered on invoices, journal entries are posted straight away. So our solution would work fine as well.

[jcchoquet]

ok, great. for the POS, the problem is if the session is not closed ? I think the POS payments must be confirmed and posted immediately, because a unconfirmed statement can be cancelled ? see the topic 20.

Yes to compute cumulative payment amounts on confirmed journal.

[fgi-odoo]

It would mean a payment statement per transaction (rather than per session), and important changes in the code to do so. I don't like it. However making such POS statements non editable (to not cancel them) is easy to do. Users would still have to close POS sessions everyday, so that new payments would be included in daily cumulative totals. It seems to me this condition could be explicitly written in the system so that the users know how to be compliant.

[sisalp]

2017-10-26 16:25 GMT+02:00 fgi-odoo notifications@github.com:

It would mean a payment statement per transaction (rather than per session),

For me, it is the most important point this law is about. Everytime a ticket is paid, the controller wants to see a new and definitive record and updated daily totals.

[jcchoquet]

@sisalp, I'am agree with you. for me the POS payments must be confirmed and posted immediately...

[fgi-odoo]

Nothing requires to post them, but to lock them. We can warn in the report for the controller that sessions opened before today are not closed yet. Same on the POS session we can add a blocking warning if a user tries to launch a session once the opening day passed. This is much cleaner than hacking the way payment statements are posted. It seems to us this would fit the new requirements. If you think it wouldn't, could you please elaborate? Thanks!

[sisalp]

2017-10-26 17:36 GMT+02:00 fgi-odoo notifications@github.com:

Nothing requires to post them,

Correct, posting is not the requirement

but to lock them.

Wrong, the requirement is to record every payment with timestamped data in its definitive form.

We can warn in the report for the controller that sessions opened before today are not closed yet. Same on the POS session we can add a blocking warning if a user tries to launch a session once the opening day passed.

The warning 'hey, something is ongoing which is not fully recorded" is equivalent to "no, I don't conform because I cannot show data of the latest payment and its irreversible impact of totals".

It is the main test of the document I pointed already : Controller makes a new payment and editor shows that it is recorded definitively and that daily total is updated. Any attestation just claims this test succeeds under any conditions. In practice, any control will start this way: the controller buys something, pays and gets the ticket. Now, he says "Hi, I'm the controller, please show me where my payment data are recordered"

Nevertheless, I may miss the point in your question. Good news is that if the payment is definitively recorded, nobody cares when/how it is copied to the accounting.

This is much cleaner than hacking the way payment statements are posted. It seems to us this would fit the new requirements. If you think it wouldn't, could you please elaborate? Thanks!

Clean is not a requirement. Easy-to-control is a requirement.

hope it helps.

[fgi-odoo]

@sisalp "Controller makes a new payment and editor shows that it is recorded definitively and that daily total is updated." > I don't read that in the rules. Could you give the official text you refer to?

Here is the only paragraph I found about that:

170 Les systèmes de caisse doivent, de plus, prévoir obligatoirement une clôture journalière et une clôture mensuelle. Pour chaque clôture - journalière, mensuelle et annuelle (ou par exercice) - des données cumulatives et récapitulatives, intègres et inaltérables, doivent être calculées par le système de caisse, comme le cumul du grand total de la période et le total perpétuel pour la période comptable.

So I don't see anything missing in our specs. Cumulative totals are for each closing, not for each transaction. Let me know if I missed something.

[sisalp]

2017-10-27 9:00 GMT+02:00 fgi-odoo notifications@github.com:

@sisalp "Controller makes a new payment and editor shows that it is recorded definitively and that daily total is updated." > I don't read that in the rules. Could you give the official text you refer to?

you may be correct, I maybe over specify. In the Condition 15 of the LNE certification process, the software must pass this test : Clôture journalière :

s'authentifier sur le dispositif avec le rôle desti né à l'utilisateur du dispositif ;

réaliser des opérations d'enregistrements sur cette période journalière ;

accéder aux données d'enregistrement ;

vérifier la bonne génération d'une clôture journal ière.

Which means that there is a closing action before total is updated.

Here is the only paragraph I found about that:

170 Les systèmes de caisse doivent, de plus, prévoir obligatoirement une clôture journalière et une clôture mensuelle. Pour chaque clôture - journalière, mensuelle et annuelle (ou par exercice) - des données cumulatives et récapitulatives, intègres et inaltérables, doivent être calculées par le système de caisse, comme le cumul du grand total de la période et le total perpétuel pour la période comptable.

So I don't see anything missing in our specs. Cumulative totals are for each closing, not for each transaction. Let me know if I missed something.

No you are right. Reading again the test procedure, totals are verified at closing time.

[fgi-odoo]

Eventually we suggest to compute cumulative & perpetual amounts on a new "Closing" object, based on sales entries (journal type = Sale) and not on the payment entries as I initially said. Indeed the rule requires it on revenue, not on payments. So it seems to us that open invoices should be taken into account as well.

[tkFontaine]

@fgi-odoo About certificate, I'm not sure to understand, you said first

And for sure this would not happen before 2018.

And then

Yes as we said the module will be released before, as well as the access to the Odoo certificate.

So will it be available before 1st January 2018 ?

Then, is it possible for you to explain what will you do for POS sales ? You can offline sell in POS, so the sales is store in your browser cache ==> User can access to it and modify sales. It should not be able to.

[fgi-odoo]

@tkFontaine What we do for POS is explained here: https://github.com/OCA/l10n-france/issues/105#issuecomment-336907598

Yes our module will be available soon, for sure before January 1st. We are currently finishing the development. We will share the pull request asap so that you can take a look and provide your feedback.

One idea at the beginning was to prevent users from using the POS offline, so that they were not able to modify the cache entries. Not sure we have to go that far. It might annoy users in case of server disconnection. The law clearly stipulates that a "man of the art" will always be able to crack the system. I'd like to hear the opinion of the other fellows.

[sisalp]

2017-11-02 11:04 GMT+01:00 fgi-odoo notifications@github.com:

One idea at the beginning was to prevent users from using the POS offline, so that they were not able to modify the cache entries. Not sure we have to go that far.

What is sure is that as soon as a payment is done by the customer, payment information must be definitively recorded. (see recent posts, and indeed, I was wrong about the totals). If you can do this with off-line POS, it is OK. You don't seem to do it.

[jcchoquet]

@sisalp I'm Ok with you, a payment is done by the customer, payment information must be definitively recorded, for the POS or a simple invoice.

[sisalp]

2017-11-02 14:09 GMT+01:00 Oxilia-info notifications@github.com:

@sisalp I'm Ok with you, a payment is done by the customer, payment information must be definitively recorded, for the POS or a simple invoice.

sorry, in order to avoid over-specification, I did not say that., It seems that if direct payments are all recorded on the POS, you do not need anyhing specific on onvoice.

[jcchoquet]

No no, I say just that Accounting is also in of the scope for the sales "BtoC", as the POS..

[sisalp]

2017-11-02 15:07 GMT+01:00 Oxilia-info notifications@github.com:

No no, I say just that Accounting is also in of the scope for the sales "BtoC", as the POS..

I think it is important to make it clear that we do not agree on this point.

[jcchoquet]

for you, Accounting is also in of the scope, ok?

[sisalp]

2017-11-02 15:49 GMT+01:00 Oxilia-info notifications@github.com:

for you, Accounting is also in of the scope, ok?

For me, Accounting has its own rules to follow Accounting is not concerned by Sapin Law One can use Odoo POS and not use Accounting.

Nevertheless, I don't know how POS is to be secured and missed some discussions around Odoo. If securing the whole Odoo is the strategy to get the POS safe, it may be a solution, but it is not the requirement from the Sapin's law. When I installed the POS alone, I got 34 modules installed, which may indicate that the POS function is deeply nested in Odoo.

[jcchoquet]

accounting no, but invoicing and payment registrer are concerned.. this is the responses of DGFIP (in french):

[sisalp]

2017-11-02 18:20 GMT+01:00 Oxilia-info notifications@github.com:

accounting no, but invoicing and payment registrer are concerned.. this is the responses of DGFIP (in french):

Please don't reopen the box :-( These points have been discussed thousands of times since two years. Just consider we disagree about what the requirement is for Odoo. Next step is to check how Odoo will conform to certifications tests, for example those in the test procedure I mentioned. This is what the discussion is about today.

[jcchoquet]

Why ? these points don't have been discussed since 2 years, because the DGFIP FAQ with the new rules is late July 2017. For that Odoo will conform to certification, all th rules must be respected!

[sisalp]

2017-11-02 19:15 GMT+01:00 Oxilia-info notifications@github.com:

Why ? these points don't have been discussed since 2 years, because the DGFIP FAQ with the new rules is late July 2017. For that Odoo will conform to certification, all th rules must be respected!

The document you extract is also obsolet. The law has been quite deeply amended in september. I just bet that Odoo know what they have to do while I don't see clearly where they plan to go regarding conformance to official test procedures. For sure, it is too late to discuss what this law is about, but just imho.

[jcchoquet]

the responses of DGFIP are late October 2017. Odoo takes responsibility with this certification, so I hope they know what to do... case to follow...

[tkFontaine]

@sisalp you said

The law has been quite deeply amended in september

Where did you see that ? Is there a new document ?

[sisalp]

2017-11-03 4:30 GMT+01:00 tkFontaine notifications@github.com:

@sisalp you said

The law has been quite deeply amended in september

Where did you see that ? Is there a new document ?

A final text is probably available because the 2018 law is now approved. For the detail and a enlighted comment, see for example (in french): https://philippe.scoffoni.net/loi-de-finance-2016-concerne-ou-pas/

Nevertheless, all 2017 evolutions were about "who is impacted" and which functions of the software must conform. It also limited the abusive interpretation the administration was trying to enforce.

We've always aknowledged that POS was the target. It was unclear whether a backoffice software could be impacted. It is now clear that only POS is concerned, and also that any direct payment has to be recorded on a certified POS or cashbox. Nevertheless, IIUC, Odoo seems to secure at backoffice level, maybe because back and front are too intricated in Odoo, I don't know. Securing the server is accepted by the law despite possible exploits.

There is no change I'm aware of about the conformance tests themselves. If the Odoo POS passes the tests, its is OK, that's it.

[jcchoquet]

Odoo seems to secure at backoffice level, because the sales "BtoC" are in the scope of law, that's it. Actually,The "private" taxable person is not subject to the invoicing obligation within the meaning of Article 289 of the CGI. "(4) « 3° bis Si elle effectue des livraisons de biens et des prestations de services ne donnant pas lieu à facturation conformément à l’article 289 et enregistre ces opérations au moyen d’un logiciel ou d’un système de caisse, utiliser un logiciel ou un système satisfaisant à des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données en vue du contrôle de l’administration fiscale, attestées par un certificat délivré par un organisme accrédité dans les conditions prévues à l’article L. 433-4 du code de la consommation ou par une attestation individuelle de l’éditeur, conforme à un modèle fixé par l’administration ; »"

[jcchoquet]

@sisalp , if you have a reference that says the opposite, we are interested.

[sisalp]

Le 3 novembre 2017 à 10:52, Oxilia-info notifications@github.com a écrit :

Odoo seems to secure at backoffice level, because the sales "BtoC" are in the scope of law, that's it.

Please don't make answers for them. It makes the question even more complicated.

Actually,The "private" taxable person is not subject to the invoicing obligation within the meaning of Article 289 of the CGI. "(4) « 3° bis Si elle effectue des livraisons de biens et des prestations de services ne donnant pas lieu à facturation »"

It is self-explaining for me, and I don't see how it relates to the discussion. I'm afraid we have open this endless discussion again. I'll try not to react anymore on reactions on my reactions...

[PatrickSUDOKEYS]

Hello chanel Sorry for my late arrival on this subject. At SUDOKEYS, we agree with the general position, only the POS is concerned. The initial law is modified by the « Communiqué de presse n°22 du 15 juin 2017, Gérald Darmanin, ministre de l'Action et des comptes publics » Stipulant : "Face à l’inquiétude exprimée par les entreprises, notamment les plus petites d’entre elles, quant à la mise en œuvre au 1er janvier 2018 d’un dispositif de la loi de finances pour 2016 visant l’usage de logiciels de caisse, de comptabilité et de gestion certifiés, le Ministre de l’Action et des Comptes publics Gérald DARMANIN a décidé de le recentrer et de le simplifier. Seuls les logiciels et systèmes de caisse, principaux vecteurs des fraudes constatées à la TVA, seront ainsi concernés. Sans réduire son efficacité pour lutter contre les fraudes permises par l’apparition de logiciels permettant d'effacer des recettes enregistrées, la redéfinition du périmètre de l’obligation permet d’alléger la complexité induite, tant pour la mise en conformité initiale que pour le quotidien des entreprises. Cette modification fera l’objet de mesures législatives d’ici la fin d’année, pour une entrée en vigueur du dispositif comme prévu au 1er janvier 2018. Les entreprises qui n'auraient pas encore effectué cette mise en conformité de leur logiciel de caisse ont ainsi 6 mois pour y veiller. Le Ministre de l’Action et des Comptes publics demande à l’administration fiscale d’accompagner les entreprises dans la première année d’application des nouvelles règles."

It should be noted that this amending law is still not published

So I know there are different interpretations as precise @jcchoquet 

but we must think of the general spirit of fighting against the VAT cheating of traders at the level of their POS, for example http://www.fiscalonline.com/Logiciel-obligatoire-au-1er.html the lawyer Corinne Lecocq (our emblem anyway;) she explains : « Sont principalement visées les activités dispensées d’émission de factures, offrant une possibilité de dissimulation de recettes en espèces. C’est ce que l’administration vient de préciser afin d’éviter les incompréhensions des TPE/PME. Dans son communiqué de presse du 15 juin 2017, le Ministre précise en effet que seuls sont visés les logiciels de caisse. » donc une vision différente de vos interlocuteurs @jcchoquet 

And reminder, indulgences will be passed to the tax inspectors for the first year

For the certification, an attestation of the publisher can be sufficient but the ideal step would be a certification via one of the 2 accredited organization : LNE ou AFNOR Patrick

[jcchoquet]

Hello @PatrickSUDOKEYS , actually according to the interlocutors, the versions are different, it's not easy.

[lap-odoo]

Hi All,

@fgi-odoo and I would like to clarify some important things regarding the Certification for the French Accounting.

1. The user will have the right to choose to install a module to certify the accounting. If the module is not installed, they won't be able to download the certification.

2. If this module is installed, it will apply on ALL accounting entries (not only the ones generated by the PoS). So all the accounting entries will be unalterable (and will receive an hash).

3. Moreover, there are some additional requirements in the law. This will be implemented in the module (regarding the closing balance of the sales entries and the inalterability of the PoS orders).

I hope this clarifies the situation

[PatrickSUDOKEYS]

Thank you Laura It's clear. Odoo decides to go further than the law is top we will be ready for the future Just a link to an LNE educational webinar : http://webinars.lne.fr/consommation/logiciels-caisse/index.asp?utm_source=signature&utm_medium=signature_webinar&utm_campaign=webinar_logiciels_caisse_fev17 Patrick

[sisalp]

2017-11-08 16:29 GMT+01:00 Laura Piraux notifications@github.com:

@fgi-odoo and I would like to clarify some important things regarding the Certification for the French Accounting.

I guess that "French Accounting" is a shortcut, for LFP2016. "Sapin's law" will not concern accounting by itself.

If this module is installed, it will apply on ALL accounting entries (not only the ones generated by the PoS). So all the accounting entries will be unalterable (and will receive an hash).

So I understand here that tickets and payment information from the POS are recorded in the accounting journals, and therefore, Sapin's law constraints are moved from POS to accounting journals.

Thank you for this precision, if I got it correctly.

As a side consequence and just because it has been discussed here, I don't think off-line POS is possible because my understanding is that the POS will fail to pass the most important test of LNE procedure (n° 5 IIRC). Things are so complex that I hope I'm wrong.

[lap-odoo]

@sisalp : That's right, as the PoS is creating accounting entries, we ensure the protection of these accounting entries. But we will also ensure that the PoS Orders are unalterable.

[legalsylvain]

Hi @lap-odoo and @fgi-odoo. Thanks for this work with the community. It is very appreciated if Odoo SA can work with OCA on some technical points as l10n fr certification.

I realized some months ago a work to certify V8.0 Odoo PoS, regarding some points. The PR is here : https://github.com/OCA/l10n-france/pull/108 In a few words : -> it is a backport of the behaviour of the Odoo module l10n_fr_certification made by Odoo SA for the V9.0. -> the code has been splited in 3 modules. l10n_fr_certification_abstract that provides a mixin model to certify any odoo model. (account.move, stock.picking, pos.order) = generate a new sha1, based on the data of an object, and the sha1 of the previous object. -> a module l10n_fr_certification_account that make the same thing as the Odoo 9.0 module. the aim is to have a module that generate the same sha1 as the Odoo SA V9.0 module to have the possibility to switch from the OCA version to the Odoo version. (BTW I fixed a bug in the core here : https://github.com/odoo/odoo/pull/18175) -> a module l10n_fr_certification_pos to certify pos.order as for account.move AND add extra PoS features. (possibility to block offline features, AND / OR possibility to write the sha1 on the pos bill). This part was not covered by the original work of Odoo SA. See @qdp-odoo https://github.com/odoo/odoo/pull/16935#issuecomment-301832280 remarks in May.

By the way, @qdp-odoo, did you took the time to check this PR ? (https://github.com/odoo/odoo/pull/16935#discussion_r126893261)

I'm available to work together on developpment. (sharing code, reviewing PR). Just let me know. In all cases, it's important that OCA V8 algorithm renders the same result (for the sha1 computation) as the V9 / V10 Odoo SA modules. otherwise, it will not be possible for OCA 8.0 customers to migrate into a standard Odoo version. (EE / CE)

kind regards.

[fgi-odoo]

We will provide the PR link asap (on Odoo 9). We are finalizing it. In the meantime here is the draft of the related documentation, summarizing all the features: https://docs.google.com/document/d/1zAA_Qe2H7fCPvGbH_ztuMoNNzmT3xOmX__xF5Ugi2F8/edit?usp=sharing

[legalsylvain]

Thanks @fgi-odoo. I added some comments / questions in your docs. Please ping me when you have a PR ready to review. Note : what the name of the new module ? (fr certification for pos). i'd like to avoid collision with the OCA 8.0 PR. regards.

[sisalp]

2017-11-09 15:37 GMT+01:00 fgi-odoo notifications@github.com:

We will provide the PR link asap (on Odoo 9). We are finalizing it. In the meantime here is the draft of the related documentation, summarizing all the features: https://docs.google.com/document/d/1zAA_Qe2H7fCPvGbH_ztuMoNNzmT3xOmX__xF5Ugi2F8/edit?usp=sharing

Thank you for the information. On the technical side, it is difficult to undertsand how is proven the coverage of the requirements. I guess you do have this picture on your side. On the organizational side, certificate and probably attestation also, requires some documentation about how the requirements are met and also how the editor is organized to manage versioning of the software and evolutions of the regulation. As Odoo is not (AFAIK) ISO 9001, it may require some care. For this, the end-user is not responsible, the attestation is considered as the proof that Odoo can answer to this kind of inquiry.

Anyway, it's good to know that we can propose a solution to our users.

[sisalp]

2017-11-09 16:04 GMT+01:00 Sylvain LE GAL notifications@github.com: i'd like to avoid collision with the

OCA 8.0 PR.

Can you update us about what has been achieved in the community regarding this regulation ?

[fgi-odoo]

Here is the PR: https://github.com/odoo/odoo/pull/20581 Related doc (in draft, more technical details to be added): https://docs.google.com/document/d/1zAA_Qe2H7fCPvGbH_ztuMoNNzmT3xOmX__xF5Ugi2F8/edit?usp=sharing

We look forward to your feedback! Thanks!

[fgi-odoo]

Who got the chance to test the module? We would like to hear from you to finetune before launching it. Thanks in advance!

[jcchoquet]

I have a community version 9 but without POS, I can just test this module: https://github.com/odoo/odoo/tree/35f299a0f899d48ff28e1b2d9e1a819231a8c2fb/addons/l10n_en_certification ?? or not?

[legalsylvain]

hi @fgi-odoo. I'll take a time to test your PR this friday. Thanks for asking the point of view of the community. regards.

[flotho]

Hi @legalsylvain

@gaelTorrecillas and I will block our friday to test this with you. we could start early in the morning

[legalsylvain]

and reviewing #108 too ? ;-)

[robinshakty]

Hi all, I can also have some free time to test the PR on friday. We have several customers with different settings (single, restaurants, multi-sessions syncing, ...). I was in touch with @legalsylvain since a couple of days for a future project based on these new modules. For i @fgi-odoo, do you imagine available modules for v10 for the end of the year ? Do you have a git repository where I can download the modules in dev ? Regards

[fgi-odoo]

@jcchoquet I don't have access to your link. Anyway you can test both modules with your v9 community version with just POS installed.

@robinshakty the plan is to forward port the modules to v10 and v11 as soon as we are done with the last refinements. To do so, we wait for the feedback of the community. Yes for sure this will be released for all the versions by the end of the year.

We are a bit short of time but thanks to your commitment, I hope we will come up with a final and completed solution within days. Thank you all!!

[flotho]

Hi @robinshakty , @legalsylvain , @fgi-odoo

We're about to start the tests with @gaelTorrecillas. Could we do a summary of the environment and plan tests ? What is the appropriate process ? I propose to Test the PR of @fgi-odoo https://github.com/odoo/odoo/pull/2058 first and then the #108 of @legalsylvain ?

Regarding the tests on the https://github.com/odoo/odoo/pull/20581, my interpretation is to proceed like this :

1. Check the hash generation of any account.move from account, POS etc...
2. Check that it's not possible to modify invoices, payments, account.move once posted, deeply through the API
3. Check that automatic closing works correctly as proposed in @fgi-odoo document https://docs.google.com/document/d/1zAA_Qe2H7fCPvGbH_ztuMoNNzmT3xOmX__xF5Ugi2F8/edit#heading=h.7e2xt3e5ild0
4. Test the process that identify which part of the move is modified

@fgi-odoo, @legalsylvain maybe you could give us additionnal subject to test.

Regarding the test for @legalsylvain POS PR #108, If I understand well

1. Latest Odoo v8 pulled from Odoo
2. Latest code from the @legalsylvain PR : https://github.com/OCA/l10n-france/pull/108
3. Check that 3 modules are installed : l10n_fr_certification_abstract, l10n_fr_certification_account, l10n_fr_certification_pos
4. (The test of the PR of @fgi-odoo https://github.com/odoo/odoo/pull/20581 will be backported in the v8, once tested)
5. Check that the hash code appears on documents
6. Check option to prevent printing in offline mode,

Anymore proposals will be appreciated.

regards

[robinshakty]

Hi all, Firts of all, many thanks to the team for the job.

I just finished th first tests of these 2 modules. 1 . Install modules : ok, with no open pos session 2 . check inalterability before opening pos session : ok (message 'there is no order ...) 3 . Open pos session and creates several pos orders : ok

4. Check inalterability before closing pos session : ok 'Successful test ! The point of sale orders are guaranteed to be in their original and inalterable state From: Main/0004 (Receipt ref.: Commande 906069612) recorded on 17/11/2017 09:08:21 To: Main/0007 (Receipt ref.: Commande 906486460) recorded on 17/11/2017 09:14:55'
5. Close and post pos session : ok
6. Check inalterability of journal entries after closing pos session : ok 'Successful test ! The journal entries are guaranteed to be in their original and inalterable state From: CSH4/2017/0002/1 (ref.: POS/2017/11/17/03) To: FAC/2017/0004 (ref.: POS/2017/11/17/04)'

7.Check the 3 Cumulative Grand Total : KO - they are not updated after the pos session closure. I understood there is a cron to update them, btw I think these 3 Cumulative Grand Total have to be updated when one close and post the pos session.

In another way, I liked how @legalsylvain did the backport in v8 with a custom view to check the hash in a new pos order page and with printing the partial hash on the pos receipt.

Finally, to maintain an absolute inalterability, with managing backups and restores, I think it would be interesting to export and sign an xml file of the pos order in a path to define in the config file, just after saving the pos order (or invoice ...) in the database. It is just an idea...