Simple UID

Most applications implement a UUID follow the Universally Unique Identifier specification which results in UUIDs like:

123e4567-e89b-12d3-a456-426655440000
LTngDQ4LCWnzyYwDycmTnK1IpIYp1FR0QDWm6FNvLY=

The later UUID is currently what is generated in Open Dispatch. Given EOTL’s use case of agile local logistics, it would be better to have a UUID which can be easily spoken or hand written on boxes or packages and thus simpler- thus a SUID.

Ideally this SUID should be something significantly shorter like 8 chars:

LTngDQ4L

And it might prove prudent to be able to prepend meaningful characters like

krz-LTng
prg-LTng
b0-krg-LTNG

Whereby b0 could represent Berlin, Germany and krz and prg would be smaller localties in Berlin Kreuzberg and Prenzlauer Berg respectively.

Some thoughts from Leo:

1. There is the possibility to use 2 systems in parallel. It would be helpful to have “long” UUIDs to have in the system as well as having a Shorthand ID for verbal handling at a Store. This is done for example at all (? some/most) food delivery systems.

Examples are (old foodora style) s2do-py3kz or #24. The first part of the alphanumeric s2do is the restaurant and the second the specific order code. At the same time the Order gets called out with a 2 digit number (#24) by restaurant/rider. I.e. in the system the order has a UUID and it is handled with a short code to be uniquely identified by handlers on the scene.

2. Pros and cons of various numbering systems:

The UUID form doesnt really matter too much for local handling, use whatever is practical for eg. billing.

The local handling takes some more thought. People are lazy, take shortcuts, are busy, only pretend to listen or don’t understand very well (language barriers).

Numbers are easiest to communicate, short is also important. 2 Digits seems like a large enough range. It seems unlikely that we are dealing with more than 100 seperate orders at the same time from a particular place. If for some reason we do its easily extendable. The only disadvantage with 2 digits i can think of is the german pronounciation being backward (twentyfour being spoken as four-and-twenty for no good reason whatsoever). I personnaly tend to call out the digits to be sure. An alternative could be a letter/number combination. Letters are a bit more prone to misunderstandings so just one letter and a number might work best(?) or might again leed to people taking shortcuts. Not sure.

From experience 2 digits is not problematic.

I like the idea of prepending some locality code to the numbers that will never be used in communication (because its always the same) but reduces the chances of mixing up places. Mixing up places is rare but it happens in long tired hangover days. Plus riders are Riding and not staring at their phone carefully. If you go around to both zero stress pizza and zeus pizza for hundreds of times it can (every so often) trip you up.

Something like PB-BRGS-24 for Prenzlauer Berg BRGS BRGS #24

Requires a little creativity to make 4chars (or 3 or whatever) recognizable and distinguishable.

One more reason for a restaurant code: multiple orders from different restaurants/stores.

Not sure if district is necessary but heck why not.

To wrap it up:

The local in house use of short IDs can be incorporated in the UUIDs.

E.g. prepend the seconds or minutes to the order, maybe recode that alphanumerically to make it a little shorter. So one would end up with say (prepending second unix epoch at time of writing): 1590431936-PB-BRGS-24

There will only be that one #24 at that place at that second.

Print that on receipts and people are only going to look at the last two numbers anyway.

Print those emboldened to make it even easyer. Done.