An order in our system can be in eleven different states.
The buyer only ever sees one of them.
Getting that one right is harder than it sounds.
Buy three packages for three properties in one go. By lunchtime one is finished, one is still being assembled, and one is sitting with somebody in the office who has to read it before it goes out.
So what does the order say?
The old answer is that a person sets it by hand. A person who is, at that exact moment, in a meeting.
Ours is worked out again from scratch every time any line item moves:
→ all of them finished → Ready
→ some of them finished → Partially ready
→ none yet → Processing
Nobody types it. So nobody forgets to.
A status a human has to remember to update isn't a status. It's a rumour.Underneath, each line item runs its own ladder — pending, processing, verifying, on hold, ready, failed, unavailable — so an order can be honest about the two thirds of it that worked.
One rule overrules all of that. If an order has been refunded, a late finish cannot quietly flip it back to Ready. Those states are guarded.
When money is going out, the money wins.Then the boring bit that saves you.
The moment somebody pays, we freeze a copy of what they bought: the package exactly as configured that day, the options, the price, every fee.
Edit the catalog next month and last month doesn't move.
A year later somebody will ask what exactly they bought. The order still knows.
History is not a live query.Next: the same order page, on the day the answer isn't Ready at all.