Document Numbers: OUT-2026-00001 and the End of 00NaN

An order number is the handle everybody outside your building uses. The client quotes it on the phone, the carrier prints it on the CMR, the bookkeeper matches the invoice to it. It has to be unique, readable, and issued the instant the order exists. For a while it was two out of three.

One counter, per tenant, per year

Every operational document number — outbound OUT-, inbound INB-, collection COL-, receiving session RECEIV- and demanufacturing job DMF- — comes from a single database function that keeps a counter per organization, per document type, per year, and increments it under a lock. The format is prefix, year, five digits: OUT-2026-00001. An empty series starts at 00001. In January the counter starts again, and the year in the number tells you which series you are looking at.

Two users, one second, two numbers

Because the counter is locked while it hands out a number, two colleagues creating outbound orders at the same moment get two different numbers, every time. And should anything ever slip past the counter, the database itself refuses a duplicate within the same organization and year. The number is a row the database wrote and will not write twice.

No side doors

Orders created through an import or the public API use the same allocation as the button in the interface. No second numbering scheme for the ERP, no override that produces a number the counter never saw. One series, one function, one rule.

Why 00NaN deserved a funeral

The old approach read the highest existing number in the browser and added one. On an empty series there was nothing to add one to, and the result was a document proudly titled OUT-2026-00NaN — what a computer says when asked to count something that isn’t a number. Two simultaneous users could also both read the same “highest” and both add one. Neither can happen now. It’s not a string. It’s a sequence.