Order numbers

[Paul-Eraman-CoopCycle]

Goal: have a code format that is non-sequential in order to minimize the possibility to confusing orders like E31D and E31E, because the sequentiality makes us only use the last two digit/letters. However, we also need something both simple for messengers and dispatch and customers, but big enough to allow for codes not to repeat over multiple months.

I am proposing:

Cooperatives pick a 2 letter prefix for each restaurant in a field in the restaurant configuration page. Ex: Eatyjet = EJ

Codes would be six digits/letters long with a - in the middle and format [prefix][prefix][number]-[num/letter][num/letter][num/letter]

Example:
EJ4-X3F
EJ2-SP9
DP7-U7C

By doing this we have 4 digits/letters that give us hundreds of thousands of options. Even a very high volume cooperative would have them rotate over large timespans like half a year which facilitates customer service and dispatch. On the backend, coopcycle can user the other ID we have that is a long unique number for database management.
Additionally, messengers will typically use the last three letter/digits for day to day use, but the prefix allows group orders to function correctly when we implement those (one order would have the same 4 digits/letters, but the pickup from EatyJet would be EJ prefix, pickup from dottorpizza with DP prefix)

Thoughts?

coopcycle/coopcycle-web#3770

[GuillaumeNaofood]

Yo'

I do agree on this.
The combo x3 [letter] - [number] - [letter] at this end, is a good one to avoid ambiguities.

But the worst case scenario that we want to avoid at all cost, is that 2 codes orders are almost the same, and can be confused with each.
So having the same 2 first letters always the same for each restaurants, let just the 3 parts of the code to have differences.
BUT it's still better compare to right now, cuz we just have the 2 last on the 4 parts of the code.

[Paul-Eraman-CoopCycle]

Thats exactly my plan, that the 3 digit code will be very unique. No similar letters (0 = O) and non sequential (no 1T, 1D, then 1E...)

[CedoSicklo]

i don't understand why we need a prefix - suffix. Is it no enough to keep the 2 first digit sequential, and the two last random (or edit a list with all the possibility and the ones we don't want close each other).
with 26 letters it's already 676 possibilities (i think more orders a coop can do in one day), and with letters + numbers it's 1296 possibilities.

[Paul-Eraman-CoopCycle]

With 2 digits we have seen that similar combinations pop up anyhow, so using 3 - 4 seems good if its not a problem

the prefix is there in large part to set up the infrastructure for group orders (one client, multiple restaurants)

[CedoSicklo]

yeah, the prefix doesn't seem to be a problem, it's just longer for messengers if they have to retain 3 or 4 digits instead of 2, but not a big deal.

[Paul-Eraman-CoopCycle]

thats what the "-" is for, so that in the pickup the riders mostly use the last 3 digits

[CedoSicklo]

sounds good, no problem for sicklo!

[Paul-Eraman-CoopCycle]

awesome, thanks!

[nadimhammami]

I think it's a very good improvement, we always thought that the actual generated codes can lead to a lot of confusion.
It seems fair enough with the prefix for the group order and also with the number of digits.
I didn't understand if with the new system the last 3 digits will surely be different or if it there would still be a very random chance that they might be similar.
In any case it's surely a very good improvement compared to now, so that's cool!

[Paul-Eraman-CoopCycle]

The idea would be to make those 3 digits very different, fully random and non-sequential

[HugoLCR]

Also, I see the need for a larger display size.

[GuillaumeNaofood]

I do agree on this ! <3

[Paul-Eraman-CoopCycle]

Definitely haha

Soon we will be redesigning this part of the app too

[alexsegura]

Sorry to come here and stop the party 🚓

In the current state of things, order numbers need to be unique.
And it's more wise to keep them unique, as I can't really predict what can go wrong if we allow them to collide.
Also, this way by telling the order number, you can find the order immediately.
If order numbers can be duplicated, people also need to know the day of the order. Without this information

Currently, the algorithm is very simple: it takes the "real" ID from the database (it's a number), and changes its base (we count in base 10, it gets converted to base 32). The kind of things you are proposing, to be implemented, need a much more complicated system with a database sequence, need to handle race conditions (need to make sure that 2 orders at the same minute/second don't share the same number)

The prefix is a bad idea IMHO, because:

• it needs yet another setting that will need to be configured for each and every restaurant
• there is no prefix at first until configured, we would need to generate it. what if all restaurants have the same starting letters?
• it makes us lose 2 digits
• it doesn't solve the original problem which is having too similar order numbers

Regarding number of digits and possible combinations, I'm always careful when I hear "this will never happen", "it's big enough".

The separator is however a good idea.
Actually, it's just UX: on the platform/app, we only show the last X digits to users. I don't know how, but then the user may, if needed, click on the "short" order number, to show the "full" order number. So, in a way, the order number is "collapsed".

To generate less predictable order numbers, we could switch to something like sqids (we are already using hashids from the same author). This will generate alphanumeric strings that do not follow each other, that we can split with hyphens, and show the last 3 for example to users. The probability of same last X digits for the same day is low enough.

[Paul-Eraman-CoopCycle]

Thanks for writing this up! We need some technical knowledge obviously.

So separating out the issues:

1. Prefixes: Nobody seems like it's something we 120% need but I also don't see any super problematic issues in what you have said it just seems sort of annoying. However, I am very nervous about when we deploy group orders, because making the logistics between multiple restaurants is the first time we are separating and combining orders. However, we are going to have to start doing this! we also will have the case in last mile about pallets that arrive as one thing to scan but then we break up, multidropoff orders have a similar situation. I wouldn't mind taking a longer look at this, but I do think that using prefixes and sufixes in a smart way is going to be a key part of making this workflow understandable both administratively and logistically for cooperatives. I can set up a workshop about this whole thing, I agree it could use some more thought.
2. Non-sequentiality: As someone who uses the platform, this is just a must. We tried the "get rid of similar symbols" path and it really really didn't help i'm sorry to say. What I see is that something quite specific has been requested many times over a long time period and because it's hard we haven't done it. But I had to leave and do an unexpected back up shift last week because someone confused 1E with 1D. So if there is a different way to get non-sequential codes in a technical manner I'm super open to any other suggestion that is easier, but the fact that it is non-sequential really is a need we can't ignore. Forgive my obvious ignorance here, but can we do something more like hashing (which randomizes) compared to division/multiplication (which keeps sequentiality)? I think your hashids / squids thing is a more realistic version of what I am saying, and if so thats great.
3. As for making repeating codes a problem for customer service. Frankly, our customer service features are pretty non-existant. We don't need code IDs in Stripe because we can filter and search well (we look for bob and 30€ and we find it no problem, no need for order IDs even). I think we have been relying on these order codes for medium to long term uses to make up for not having similar abilities in our dashboards. The order code to me is principally a day to day operational and logistics code, and the admin part is secondary. If it can be unique as well in way that help the admin stuff that's great, but we can't prioritize it over the other.

Anyways, sounds like there is a middle ground if i understand your response correctly. Could you give an example of what 50 4-digit codes would look like for orders that were created chronologically using hashids or squids?

[alexsegura]

Here is an example using Sqids to encode IDs from 50000 to 75000.

It encodes the IDs as a 9 symbols string, and splits it in pieces of 3.

50000 => J91-GQY-W8N
50001 => 0DS-CNV-F85
50002 => QY5-JQ7-ZWS
50003 => HEZ-EM3-T0Z
50004 => 90M-00P-Q1V
50005 => MSB-SQE-Z13
50006 => T18-135-QR2
50007 => W36-3K1-71V
50008 => 1MX-MQH-9J4
50009 => NCK-C60-W40
50010 => 3KR-KGM-M8Z

[Paul-Eraman-CoopCycle]

And we could do this but only using 6 of them right?

[Paul-Eraman-CoopCycle]

And eliminating confusing letters (o/0, L/i, etc)?