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
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. 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
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.
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.
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?
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.
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:
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.
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.
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
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
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…
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.
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
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.
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.
Yes, it is not 100% tamper proof unless you store the Md5 at a 3rd party.
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.
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
Dolibarr is doing the job quite well for my small business, but it is not so customizable without coding in PHP, adding some modules (sometimes very expensive regardless my business) or developing my own modules.
In opposite, the few I tested ERPNext and looked at the user manuel, I found a lot more possibilities for creating custom forms, customizing invoice templates, etc., to fit better my way of managing my business.
I also have a doubt about the possibility of using ERPNext for accounting, because as a French microentrepreneur, I have a simplified accounting (I only have to keep a daily record of my revenues and expenses; no analytic accounting neither double entry), and I didn’t find any “simple mode” in the account module — Maybe I missed it . Dolibarr offers a simplified accounting by default.
So I am divided over this choice, but for now I go with Dolibarr because I need that tool and I didn’t want to wait more.
I am also new to Blockchain but I do see the potential of this idea. For example I can imagine a scenario whereby every invoice created inserts rows in the MySQL database and inserts the same data in the Blockchain to create an immutable copy of the invoice. The data inserted in MySQL allows ERPNext to keep functioning as-is while the copy in the Blockchain is to satisfy the government requirements. I am not sure how realistic above scenario is, but I am sure that some variation of it will be possible. Now we have to realize that Blockchain is a still-maturing technology and we have to look at a protocol that allows millions of transactions per second at low cost. One such promising protocol is called EOS and can be found here at http://block.one block [dot] one.
Thank you for a clear and concise explanation above but as we are a Microsoft certified Retail POS Company based in Denmark and have some Partners in France, do we still need to go forward with this certification?
I would be grateful if you could shed some light over this matter please.
Thanking you in advance for your help.
Kind Regards,
Anousha Mohon.
Instead of blockchain you might consider IPFS … Inter-Planetary File System.
It appears like any other directory in your device, but when you write to it, copies are written to peer servers.
A couple of dedicated low cost VPS installations could act as immutable repositories for files written by client side browsers, backend servers or what ever.
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.
. Dolibarr offers a simplified accounting by default.