Michaelsy wrote
Probably you were just lucky. Have any changes been made in the organization? If there is no parallel access to the invoice number, then there is no problem.
Yes, changes have been made; but none of them I consider to be responsible for that.
Michaelsy wrote
A very simple workaround could be that every employee who writes invoices claims its own invoice number range. He can then manage this area independently (e.g. handwritten).
That is what we just want to avoid. Tax authorities have got some difficulties with missing invoice numbers, etc. And the last years this worked perfectly :-)
Michaelsy wrote
Another relatively easy option would be to synchronize the invoice number assignment via a manually-managed DokuWiki page. These are already protected against parallel access.
This is something I perhaps will think about; currently each invoice is noted on an individual page of which the data name is a 5-digit-auto-increment number from the numbering plugin :-) I could change it in a way that the page will be named after "2018048" f.e.. By this I could guarantee that no double numbering can occur. But up to now I cannot oversee the possible consequences; I could correct the mistake today, reported the procedure in our wiki and still hope to get some information, how this could have happened at all.
While I am thinking about this I have the following assumption:
- Computer A opens the wiki page, where he can create invoices by clicking this "submit"-button. The invoice number is shown as "2018047". But the user A is not doing anything.
- Computer B opens the wiki page, where he can create invoices by clicking this "submit"-button. The invoice number is shown as "2018047". The user now creates one invoice; "his" number increases to "201848" and he creates the 2nd invoice.
- Now user A creates an invoice, WITHOUT HAVING RELOADED THE PAGE (and by this flushing the cache or whatever, no idea), and BOOOOMMMMMHHHH, or?
I think that perhaps this could have happened.
I think that this would not have happened, if user A would have reloaded the page because in that case "he" would have been informed that number has increased in between to "2018049". If it is like this then I consider this as a bug in that function. This could/should be fixed by means of a lock, etc. What is others opinion about this?