Don't allow new invoices to have a date before last validated invoice.

[rdoursenaud]

Feature request extracted from #3170.

This is a standard regulation in most countries (and in France for sure) to want invoices in a sequential chronological order. This is currently not enforced in Dolibarr.

Proposed workflow:

• Create an invoice as usual
• At validation
  • Check last validated invoice date against invoice to validate
  • If invoice date is > to last validated invoice date: do validation
  • Else: ask user for another date and recheck

As simple as this feature may seem, it can be prone to a race condition in a multi user environment like Dolibarr.

@Dolibarr/owners Do we already have a system in place to prevent race conditions when writing to the database?

We should introduce this as experimental and test it thoroughly before integration.

[aspangaro]

@rdoursenaud

No, no, no ! The ref of an invoice must be in a sequential chronological order but for the date : no ! (In France for sure).

You can block a period when the fiscal year is finished but a date can be inferior to an another date who are most older.

In french :

• http://vosdroits.service-public.fr/professionnels-entreprises/F23208.xhtml
• http://vosdroits.service-public.fr/professionnels-entreprises/F31808.xhtml

[rdoursenaud]

Huh? numéro unique basé sur une séquence chronologique continue

Chronological but not by date, WTF? Do we use the same language? https://fr.wiktionary.org/wiki/ordre_chronologique

This is not open for interpretation. Chronological is a pretty specific word and used in conjunction with sequential it leaves no place for doubt.

[eldy]

I agree with @aspangaro The "chronological" is used to mean counter increase always. But the date of invoice, no. Imagine this apply to date of invoice. If a user is on holiday and enter its invoice into system 2 days after vacation, then he can't set the date of invoice correctly jut because another employee entered another invoice with a date higher when he was on holiday. Having such a rule will lead of deadlock situation.

[aspangaro]

@rdoursenaud

Yes it's ambiguous. For me, the continous sequence concern number. The page of tax authorities has been recently updated. The FEC norm change many thing and for the moment I have one control with tax autorities, the tolerance for date is one month, time to realize VAT declaration.

You can modify an invoice or cancel it and use the same date for the new invoice when the date is very close. If the are a new invoice meanwhile...

[elarifr]

we all agree that chronolgical number is ok and there is no issue about that.

@eldy , @aspangaro date is really subject to interpretation. i repost here this text where i says "Numérotation La numérotation des factures est représentée par un numéro unique basé sur une séquence chronologique continue, sans rupture." and this is what is not clear to me : "Il ne doit pas être possible d'émettre des factures à posteriori." what i understand that you are not allowed to have invoice dated before a previous one !

@eldy , if an employee made an invoice Sept 1, you can't come Sept 4 and make an invoice Aug 27 : for me this is clearly "a posteriori". next invoice should be only at least Sept 1.

@aspangaro nice to heard they allow one month tolerance

so maybe it should stay allowed in dolibarr and add an alert box in such case and confirm f this is user choice ....

[aspangaro]

I waits for the return of a colleague who assisted a training "file FEC, security and procedure in the ERP". I think it's interessant for the future of Dolibarr.

[rdoursenaud]

Ah the joys of tax laws, always opened for interpretations and tolerances. Until they're not and the authorities f*ck you to the bones. That being said, I think you're right on the money on this one @aspangaro. The law texts (linked at the bottom of your references) don't mention anything about chronologique nor date except it should be on the invoice. That's why I hate those dumbed down versions of the law, they always change the meaning enough to get you confused or even doing it wrong. Been there done that. I'm looking at you Pôle Emploi. But section 6 and 10 of the article 242 nonies A of Code général des impôts, annexe 2, CGIAN2 makes it pretty clear that backdating invoices is not an option.You have to add the date of the work to the document. Going full-circle again… I think that's what you've been looking for @elarifr. Looking forward to the FEC training insights @aspangaro.

[eldy]

@aspangaro What is "file FEC, security and procedure in the ERP". Can you point me to a page of such formation ?

@rdoursenaud Entering an invoice with a date lower that when you enter it into the computer is "for me" not backdating. Backdating is when you make an invoice with a date that is before the date the invoice should have been entered into the system.

A hidden option is however welcome, even if in the real life, i can't see how a company can work in real life with such an option on.

[elarifr]

Hi Eldy, the "FEC" (Fichier Echange Comptable) are a file standard for the french DGI. http://www.impots.gouv.fr/portal/dgi/public/popup?espId=2&typePage=cpr02&docOid=documentstandard_6619 Apply to accounting software Maybe the DGI plan to extend to ERP/CRM software too ?

[marcosgdf]

At least in spain the number must be both sequential and chronological. There is a penalty if they detect it…

[rdoursenaud]

@eldy I understand the business case very well, believe me. But that's not what the tax administration wants. What they want is for you to input your invoices in a chronological order to avoid fraud and make their verification job easier. The rationale being that you have no reason except fraud to not invoice in a FIFO manner. And quite frankly, I think they're right there.

[vabeltran]

Definitively in some countries (like in Spain) it is not allowed to create a new invoice dated before a previous one.

So, as far as I know it would be possible to create an option to be activated/deactivated in the config menus, so you will be able to activate this restriction in your deployment if this applies in your country, right?

Is there anyone working on it, or something like that? If not, I could adapt our own one to merge with future versions.

[github-actions[bot]]

This issue is stale because it has been open 1 year with no activity. If this is a bug, please comment to confirm it is still present on latest stable version. if this is a feature request, please comment to notify the request is still relevant and not yet covered by latest stable version. This issue may be closed automatically by stale bot in 15 days (you should still be able to re-open it if required).