Major compliance requirement for France due to the POS module

ERPNext Selling/CRM
1

Hi everyone,

I am opening this thread because of a compliance requirement that must be fulfilled for the 1st of January 2018 in France. The purpose it to fight against VAT fraud with POS systems.
As of this date, every organization owing VAT to the Fiscal Administration should use a point of sale or cash register system compliant with the following criterion:

  • inalterability
  • security
  • data retention
  • archival

The software should be either accredited by a third party accreditor or the editor/service provider can provide a certificate of compliance.

If these requirements are not fulfilled, companies will be fined 7,500€ in case of control and the software provider (even outside of France) will be fined 45,000€ + 3 years in prison if the certificate is forged/on false grounds.

I will only present the main requirements related strictly to ERPNext and Frappe here, but feel free to contact me, especially Frappe Team, if you have french customers and you want to know more about all the hosting requirements and certification process.
In case they are not fulfilled, the law is quite clear, it will be impossible to use ERPNext in France - or there should be a version without the POS module.

My goal here is to have inputs from the community on how these issues can be technically solved and if anyone else has similar requirements.
I will open separate Github issues or flag the already open issues relevant to this thread.

I know it is specific to France, but given the scope of these requirements, they can be of interest for ERPNext and its community globally and could maybe be considered in the roadmap.


I. Inalterability

Globally, the notion of inalterability means the insurance of absence of integrity loss for all registered data.

Technically, this notion requires:

1.All transactions data should leave a transaction print with an cryptographic hash function.
Best state of the art authorized algorithms are: SHA-2, SHA-3, Whirpool, Blake
Example of state of the art data signature algorithms : RSA-SSA-PSS, ECDSA

For example the “Encryption at Rest” mecanism in MongoDB can be considered as acceptable.

To be noted: Printing an invoice is considered a transaction and each original print should be registered as such.

In short: all transaction data must be chained or sealed with a timestamped signature. This is true for all transactions data and all vouchers (archiving integrity is one of the requirement).

For ERPNext/Frappe, maybe the implementation of “Data at Rest Encryption” for MariaDB or InnoDB Tablespace encryption + a chaining process should be considered ?

_GITHUB ISSUE: Issues · frappe/erpnext · GitHub

2.If any correction is made to a transaction data it should be only with “plus” and “minus” operations and not with a direct modification of registered data.

This is already partly the case in ERPNext since we can only cancel submitted documents and create amended ones. But canceled documents should never be deleted.
There should be no possibility to delete any transaction data, i.e. even the system manager should not be able to delete documents from the “Deleted Document” list.
The Administrator may have these rights in case it is strictly reserved to a third party service provider providing the certificate.
But if the Administrator has the rights to delete documents, it should be registered somewhere, maybe visible in the generated chain.

GITHUB ISSUE: To be opened

3.Data integrity

I think there is an issue with the offline POS.
If I’m correct, LocalStorage is used to store the offline data until it is connected to the network again. It means that anyone can open their browser console and flush the storage, therefore losing the registered invoices.

There should at least be a chaining process or else, allowing to check that some data have been deleted intentionally.

_GITHUB ISSUE: Issues · frappe/erpnext · GitHub


II. Data Retention

1.All POS or cash registers must have a daily and monthly closing voucher generation process.

This closing voucher should register data like: Period Grand Total and Perpetual Total for the Accounting Period

_GITHUB ISSUE: Issues · frappe/erpnext · GitHub
EDIT: I have submitted a first PR for this issue and proposed a solution. All thoughts are welcome !


III. Archiving (12/2018)

1.An archiving mecanism has to exist and its traceability must be ensured

An archive should be maintained inside ou outside the system and the generation of an archive must be registered, chained or with a signature timestamp.
The archive should be read easily by the administration in case of control: formats can be JSON, XML, CSV, flat text,

It can be encrypted.

In ERPNext, it could be generated and preserved in the system as it would be the simplest way I guess.

GITHUB ISSUE: To be opened

I will complete these points in the following weeks.

Any input/thoughts about how these can be achieved is welcome.

5 Likes
2

Dear Charles-Henri, thank you for this topic. It is very helpful.

I currently study the question of certification of our software, and have some problems with understanding of the individual certificate. My company produces the soft and as I understand we can issue the individual certificates to our customers in France. But the question is: should our certificate be based on some other documents or standards? Or we can just confirm that the product is in line with the requirements of French law?
Can you clarify this?
Thank you.

3

Hi Tanya,

Thanks for your interest in this topic.
Which software is your company producing ?

In order to edit an individual certificate for your customers you need to make sure you respect all the criteria required by the law.
All requirements are available officially here (sorry it’s only available in french :confused:)
TVA - Régimes d'imposition et obligations déclaratives et comptables - Obligations d'ordre comptable - Obligation d'utilisation de logiciels ou systÚmes de caisse sécurisés | bofip.impots.gouv.fr

You can look at the requirements for the norm NF525 to have more detailed technical requirements.

If you are certain you respect the law (else you will be held accountable if your software doesn’t have the NF525 certificate delivered by a third party) you can edit individual attestation letters to all you customers based on the following format:

Your letter must respect this format to be valid.

Hope that helps :blush:

4

Dear Charles-Henri,
thank you for this explanation. It helped me a lot.

5

Aside from POS receipts, what about sales orders and invoicing of items sold to other businesses. How would the new VAT laws work in those cases?

I know that some of it can be avoided when the items on the purchase order are used in the creation of another product or even resold as retail. However, there are many items that businesses purchase just for the convenience of their operation and do not directly contribute to the creation of other products. For example a business office purchases hand soap and paper towels for the convenience of guests or visiting clients and they may do it on the same purchase order where they also buy boxes for packaging their new products in their small factory on the floor below the offices. Most of the time the accounting for these were handled in the accounting office by hand and submitted to the taxing authority.

How do the VAT laws handle this? How would it affect other modules in ERPNext? The VAT is normally applied to the final sale of an item just before it is consumed, right? In the case of ERPNext, these transactions are not always in the POS module. Or are they only concerned with general public consumer transactions?

BKM

6

Hi,

I have my own business in France so I am concerned by this law (even if I don’t charge any VAT because I am an autoentrepreneur, thanks for the French lawmakers :unamused: ).

I’d like to use ERPNext to manage my business and especially to make invoices. Since this new law I was looking at Dolibarr, which will be certified but is less flexible and customizable than ERPNext. If I go with ERPNest, that would certainly be with the virtual machine (provided by Frappe) running on my own server. (The only other option I am looking on is the self contained stack provided by Bitnami).

What about the compliance and certification in that case? Will I be able to get a certificate. Would all version of ERPNext be certified?

Thanks,
Nico

7

Hi @bkm,

For the moment, the law is only applicable on any POS module, but I guess they will extend it to the whole invoicing/accounting part of any software in the future.

The VAT rules are not modified, so you will continue to handle it the same way it is now. It is still supported by the end consumer.

8

Hi @nicojack,

The above analysis only proposes changes to allow a third party to give a certificate (it could be Frappe Technologies on their cloud or any service provider like myself that can guarantee the compliance of the POS module for example).

A self certificate is possible but you have to respect a certain number of criteria, like a having specific NAF Code, but it is not possible with a “Micro-Entrepreneur” status, you will need a full company (SAS, SARL, EURL, 
).

In order to do like the Dolibarr community and deliver a certificate for everyone, the developments would need to be much more complicated than my proposal. But it is not impossible if we get help from more people to do it :slight_smile:

9

I. Inalterability
All transactions data should leave a transaction print with an cryptographic hash function.
Best state of the art authorized algorithms are: SHA-2, SHA-3, Whirpool, Blake
Example of state of the art data signature algorithms : RSA-SSA-PSS, ECDSA
For example the "Encryption at Rest" mecanism in MongoDB can be considered as acceptable.

Encryption at REST is not there to certify data is right but to protect data from theft (make it useless if a copy is obtained by someone who shouldnt have it) . MD5, checksum type of hash algorithm is the right one to use because it does generate a unique code for a unique set of attribute. But doesnt necessarily help secrecy (against theft), if it is a one way encryption. Any tampering will alter MD5 and hence you can say the record has been tampered.

Therefore, I am not sure how Data at Rest Encryption" for MariaDB or InnoDB is the right solution.
Pls. help clairfy. My knowledge is only conceptual, not technical.

To be noted: Printing an invoice is considered a transaction and each original print should be registered as such.

I dont understand. What happens if an invoice is “printed” to a PDF. Is that an ORIGINAL PRINT? The more carefully you read it, the more and more ridiculous the law looks. Good for IT people, generates a lot of work and doesnt produce anything of value to the small business.

For ERPNext/Frappe, maybe the implementation of “Data at Rest Encryption” for MariaDB or InnoDB Tablespace encryption + a chaining process should be considered ?

“Data at Rest Encryption” for MariaDB or InnoDB is not the right technology. There is a difference between cryptography for authenticity and cryptography for secrecy. :slight_smile: You want the former. The technology offers the later. (my understanding)

2.If any correction is made to a transaction data it should be only with “plus” and “minus” operations and not with a direct modification of registered data.

I love it. A few days ago, people wanted to reuse invoice numbers because it needs to be sequential. Now this law conflicts the previous one on the numbering format. Because this effectively wants to net the transaction with a negative number.

I would propose a numbering system like SALE-INVOICE_1.0000
Therefore, if there it is cancelled 1.0000 is cancelled and a new one would be 1.0001 and if that is cancelled
1.0002.

Of course a brand new transaction would have SALE-INVOICE_2.0000
Then it doesnt break the serial requirement :wink:

3.Data integrity
_I think there is an issue with the offline POS._If I’m correct, LocalStorage is used to store the offline data until it is connected to the network again. It means that anyone can open their browser console and flush the storage, therefore losing the registered invoices.There should at least be a chaining process or else, allowing to check that some data have been deleted intentionally.

Same problem would be there if you wrote it down on a accounting journal and lost it in the bus/train on the way to your HQ to record it. There needs to be a general improvement in local storage, but starting with productivity benefits and then the compliance. How can this be achieved if a business was using a pen and paper? How does one do a check sum? or a block chain on it?

II. Data Retention
All POS or cash registers must have a daily and monthly closing voucher generation process.
This closing voucher should register data like: Period Grand Total and Perpetual Total for the Accounting Period

Generally for a big fortune 500 firm this is important to close the books. For Small business
this is cruel joke if it is compulsory for all. Surely there is a limit on how compliant you ahve to be depending on the size of business. Maybe for business over $2M or Euro2M , might make sense. But for a mom and pop store with Eur 5k sale a month
its a burden.

III. Archiving (12/2018)

Use dropbox. Same as backup I guess?

Finally, Any thoughts on creating a FRENCH CHAPTER and funding and then submiting back to Main Branch as a strategy? Looks like these are compulsory for certain markets and optional for others. So best kept that way. We shouldnt dont want to burden the entire eco-system at the lowest common denominator.

10

Mariadb supports sha2 [1], triple-des [2] or aes [3] as encryption method, but need that tls module be enabled in all setups.

ECDSA are supported [4], tls needed too.

The problem I do not see in the encryption support. The key is, as is well saying @Deepak_Pai, that these issues are needed in some countries, but in others not. Making it compulsory I do not think it is the best option. Now, having fingerprints of transactions on an erp can be very interesting.

[1] https://mariadb.com/kb/en/mariadb/sha2/
[2] https://mariadb.com/kb/en/mariadb/des_encrypt/
[3] https://mariadb.com/kb/en/mariadb/aes_encrypt/
[4] https://access.redhat.com/articles/1471453

11

I’ve been wondering about this though. Is the md5 hash going to be contained in the same row or table as the transaction information? In that case, can’t the person who tries to tamper with the record also overwrite the hash value to fit his modification?

12

md5 and sha1 has collisions, are not valid. For that case to avoid modfification are used ‘salt token’ [1]. That token is only known on execution time, if anyone tries regenerate hash token can’t do it without salt token.

[1] Salt (cryptography) - Wikipedia

13

In order to validate the authenticity of a transaction, doesn’t the token have to be stored somewhere?

14

Thanks for your input guys,

I am only quoting the requirements for the NF525 certification, which is considered compliant by the French Tax Administration.
I do agree with your conceptual interpretation, I think there are two points here:

  1. A hash print for each transaction + a sum of all previous hash prints could guarantee that the data has not been altered by a user.
  2. Data at Rest encryption can be interesting if you want to make sure that the user can’t access its own database (if they don’t have the access key) and therefore you can certify that he/she can’t destroy existing entry => You make some kind of black box.

In this case, the first point can be interesting for all erpnext users since it doesn’t impact the control over the database.
The second point would bring too much restriction for users outside of France.

My proposal here is to implement the former, so service providers like Frappe Technologies or others can give a certificate to french users without limiting anyone.
The drawback would be that french users would need to require the services of a third party to use ERPNext, which is not fully in line with the open-source concepts. Anyway it is important to know that even with a black box, a third party would need to issue a certificate, and the question would be who ? For Dolibarr, the Dolibarr Association (not sure of the name) will issue this certificate for everyone for example.

:smile: I don’t really understand this point either, but that’s the law and we need to be compliant
 To be honest, this part is not new, it is an already existing compliance requirement.
Anyway, an “ORIGINAL PRINT” should only be the first print, all subsequent prints should be “DUPLICATES”. We can do that with print formats without issues. The only missing point is that each time a print is generated, it should be registered in the database (SAP does it for example).

That’s fine with me, that’s why I posted it here, any advices on the right technology and right developments to do are welcome :slight_smile:

If I understand correctly, for me your proposal is identical to the actual way the system works.
SINV-00001-1 is the same as SINV_1.0001, it is just a different version of the same document. It is already compliant.

The problem is with the fact that you can definitely delete invoices in ERPNext: you cancel, then delete, then delete “DELETED DOCUMENTS”. That should not be allowed, even for the system manager.

Another point, already discussed in another thread is the fact that when an invoice is cancelled, the posting should be reversed and not deleted.

The point is to make sure that no one can maliciously delete an invoice.
To continue with your metaphor, the state wants you to buy a money transporter truck to transport your accounting journal to your HQ. If you get robbed it’s not your fault, but you have to prove that you did everything in your power not to get robbed.

I have to disagree with your statement:

If your software is not compliant, you can have all the functionalities you want, you are not allowed to use it, so it’s useless :wink:
But again, the problem is not Localstorage per se. If we find a good way to make the software compliant and to have an offline POS it would be awesome (I’m talking for french users only of course, not for everyone else who doesn’t have to be impacted)

It is already the case in France and other countries in Europe. It’s burden for small businesses, but you have to do it
 :smirk:

That’s exactly what I’m proposing. I posted all requirements here to have some feedback, which is great so far, and to see what can be implemented globally and what needs to be in an external app.
I think some requirements (like hash chaining) could benefit everyone without been a burden for anyone else. For other requirements, we can keep it outside of the core solution.

Thanks for this info, I will look into it.

15

There are methods that are based on salt like bcrypt [1] or PBKDF2 [2]

When we are talking about using that methods we are talking about ** hashing ** the information does not encrypt it. I do not know if with this approach we respect the law there, this is a very complex thing. Seeing how dolibar makes it might be a good start 


I think this law at this point is intended to make a fingerprint for the operation, instead of encrypt it. I dont known if all this requirements have relation with PCI [3] but in POS transactions instead credit cards 


Here we do same as @chdecultot with POS tickets/vouchers when physical stores are closed, online ones are done with all transactions before 23:59:59. But we sell more than 5k/month :wink:

[1] bcrypt - Wikipedia
[2] PBKDF2 - Wikipedia
[3] Payment Card Industry Data Security Standard - Wikipedia

16

I have to strongly agree that relying on browser cache for offline POS is really a worrisome. A suspicious user can easily exploit it without much need for technical expertise.

I think the POS should have its own standalone app. For desktops, I think it should be Electron app since it is cross platform (windows, linux, and mac) with same app, it its built using JavaScript, HTML, and CSS. For iOS and Android, it should be a native app. After having such apps, there should be an option to disable access to POS through browser.

1 Like
17

Thanks all for commenting back.

I have one idea to make it all work together. Blockchain! Not sure if it got mentioned. Everytransaction made sends an MD5 or whatever to a 3rd party who maintains a block chain and since every step behind is rehased, it is impossible to change an altering the checksum.

I am super new to this technology (blockchain) and can barely express the idealness of it in this situation.

If we could pool resources, we could set up a 3rd party independent block chain service. Maybe like an NGO. Anyone who subscribes to it will pretty much be left alone. Could be a very nice business oppportunity. Charge per transaction.

Any thoughts on this? :slight_smile:

Deepak

1 Like
18

Yes, it is not 100% tamper proof unless you store the Md5 at a 3rd party. :slight_smile:
Which makes this whole legal mumbo jumbo a hasty pudding legal requirement that doesn’t do any good to anyone.

Here is a good reason why SMEs in France need to go on a silent strike/protest. This is why you need a chapter to mobilize people.

19

Hi @chdecultot,

Thanks for that clarification! :slightly_smiling_face:

So I’ll continue with Dolibarr for now and see how things evolve for ERPNext.

Thanks,
Nico

20

Just curious : What was your idea behind the evaluatio of ERPNext to start with?
In other words, What was the Strength / Weakness / Opportunity / Threat of ERPNext vs. Dolibarr!
Thanks again for your insights
Regards