I'm not sure why your "disable concurrent execution" solution isn't working (I think it should), but you could use other methods for generating unique order numbers:
If you add an AutoNumber attribute to your Order objects, it is guaranteed to be a unique number (I think it uses the same auto numbering mechanism of the underlying database that generates the database IDs). You can then use this number to generate a unique order number.
An other option would be to use Java actions, which enables many options to solve the issue (like using
java.util.UUID.randomUUID() or something similar, or using a synchronized method for generating order numbers).
You could check how many rows there are present in the database before you commit the action. So when you create your order you could call a microflow which checks how many rows are stored + 1. Before you commit you should call the microflow again to assure that the id is unique. I've used this several times and it worked.
Many thanks for your suggestion. Correct me if I'm wrong, I think it doesn't matter whether the order id is incremented from the latest id or the number of all existing orders. If 2 MFs to create the id still run simultaneously, both MF sessions still get the same beginning id.
I've already added sub MF to recheck the duplicate id to recreate the new one after the first calculation ends if duplication occur, but the problem still exists.
Just to provide more information, the reason I don't use autonumber because the id need to be reset at every beginning of the year. And in the near future, old transactions need to be archived and purged from the system. so the new id generation tends to rely on the correct selection of the latest id.