This is a very boring topic. But a topic that can just kill Open Food France if we don’t work on it.
There are three major laws/norms that appy to us in France (some at EU level), and that today we don’t comply with.
Especially, a new one concerns the certification of any “point of sale system” (online also), and it’s appicable on 1st January 2018. (the official reason is to fight VAT fraud, I have some doubts about the efficiency of that measure, but anyway…)
We will ask for a derogation to gain some time so that we can align with the norm and get certified. BUT all our users are going to ask us a certificate on our conformity (they legally have to), and if we are not able to give them thise certificate, they won’t be allowed to keep using Open Food France to manage their food hub.
I have told about it to our various users and potential users, so they know we have taken this issue seriously and are working on it. The impact on the OFN code is not trivial, but the good point is that this could be an opportunity to improve a lot some part of the system that a bit “border line” at the moment.
I’m gonna try now to summarize those very boring thing, and for those who want to go further here is a link to an even more boring document with extracts from the law and attempt of understanding if we are compliant or not and what we should do (it is in a “draft” mode sorry about that)
Some of those obligations are EU obligation to come for next May. I precise for every item if it concerns only France or EU and what is the due date.
A- VAT fraud conformity (Fr - 1st Jan. 2018)
1- All the source data for the establishement of a payment must be inalterable. That includes orders, delivery notes, invoices, and of course payments. Any adjustment on an order or any modification on a payment must appear as “-” and “+” and never change the original data.
The big issue on OFN is that today whatever modification we make on an order change the original order. So if I issue an invoice at 1pm, make an adjustment on the order, I can reissue the invoice at 1:30 PM, the invoice will have the same number, but be different. Legally we shouldn’t be able to touch the original order, we should track the modification and all that should appear in the invoice with “+” and “-” for any adjustments we made. If we issue an invoice it should be “locked”. If another adjustment is made afterward if we issue a new invoice the first one should be void and a second one shoud be created with a different number. If a re-issue an invoice already issued it shoud be marked as “duplicate”. We also miss a “delivery document” that sums up all what is been delivered (that can differ from the original order, if a product was missing for instance)
Same for the payement, it is not as bad as if I cancel a payment I still have the trace of the payment. BUT I shouldn’t be able to do that, if a payment have been accepted, I should only be able to void or refund.
2- We need to provide our users with daily / monthly and yearly “closing”. Which means that should be able to extract and archive the various transactions made during the day, the month or the year, line by line + a summary of the total for the period + a summary of the total since the begining of the fiscal year + a perpetual total (since the hub started using the OFN)
I think we could probably deal with that through some new report allowing the hub to extract and save those data. The only thing is that once that is done it should “lock” the given operation, so no modification should possibly happen one a transaction after the closing action have been done. A bit like when you close the account at the end of the fiscal year, after you cannot change anything on the accounts for that period.
If a hub coordinator manages multiple hubs (legal entities) he can extract aggregated data at the coordinator level. That should work with our report logics.
3- A test / dummy transactions must be marked as such.
Today when we make demo or when a hub test the platform they always do fake transactions. But in case of a control, they appear today in the system just as real ones. We need to have a way to mark a transaction (from order to payment) as “test/dummy”. If you print a receipt or an invoice from those dummy transactions the template should show the “dummy” info backward.
B- Data protection (Fr - already applicable)
4- All personnal data relative to commercial activities shouldn’t be kept more than the legal duration.
In France for instance, invoices, receipts, payments, etc. should be kept for 6 years. And we can archive the info before but they need to remain accessibe in case of a tax control.
I would suggest to archive the info after 3 years but let them accessible by the hub manager (through the possibility to download an archive ? Or list archived transactions?) And after 6 years that could simply be delete. I would suggest we notify the hub manager so that he can make sure he downloaded the archive, if he wants to keep them beyond that legal duration.
5- Users data shouldn’t be kept more than 3 years afer the end of the commercial relationship.
So any data relative to the user, email, address, etc. should be delete and the user anonymized at least.
6- User accounts that are inactive should be deleted after a certain period of time.
For instance I would suggest to delete them after 3 years same as precedent point. We can plan a process like send an email to the user saying “You have an account on OFN but have not used it for the ast three years. We are about to delete it and all the personnal information attached to it. If you want to keep your account alive click [here]”.
7- All cookies information should be delete after 13 months. Information relative to analytics trackers and cookies must be communicated to the user, we must have the user agreement or at least write that in the terms and conditions and allow them to refuse to be tracked.
I don’t know how to implement that but I guess some tech person will know;-)
C- Data protection (EU - May 2018)
There are some EU harmonization regarding data protection that will be applicable from next May.
8- Explicit consent for any data we collect
I don’t think we do ask that for cookies for instance for now ?
9- Right to data portability
I think we are pretty ok here, the data belong to the user and they can extract them or ask an extraction at any moment, right ?
10- Privacy by design
We should collect the minimum data necessary. I think we are pretty ok, we just need to make it possible not to collect address and phone when it’s not necessary and we’ll be ok I guess (see customizable checkout discussion for instance)
11- New compliance tools
we’ll need to implement and maintain a register of treatments (can be done collectively on Discourse? we have started this discussion that could be a base but we will need to clearly state what is done and what remains to do), notify any security branch (this needs to be done at national level I guess), certify the treatment (how? security audit?) and maybe adhere to some “code of conduct” (do you know one relevant?).
12- Declaration within 72 hours in case of data violation
This will have to be done at national level.
If we want OFFrance to stay alive and thrive, we’ll need a plan, especially for the A part… and as we share the code we need your agreement to incude that in the priorities to come. We need to have a plan, I can try my best to get a derogation, but I need to tell that we do have a plan and can fix that for instance for Jan 2019.
To be sure that this diagnosys is all right, we are going to pay for a specialist lawyer, so that we are sure before we start any work that all that is needed, and that it is sufficent for us to get that certificate.
In terms of data protection, that will fuel the discussion on deletions. I guess every local instance will have it’s own rule regarding data protection, but who can do can less, so I would say let’s protect better the user data, and everyone should be happy ?
Looking forward to read your comments… and @Augustin let’s find a lawyer to review all this work I have done and see if what we plan here is tuned, I’m not at all a specialist and it is soooo boring to read those legal texts …
Add up info:
Source text on EU data protection: http://ec.europa.eu/justice/data-protection/index_en.htm
Apparently as soon as one of your users is a EU citizen you need to respect that law, wherever your company is based.