An optical order holds three objects: a serial-numbered frame, lenses made to prescription, and an assembled pair. The fields, states and handover check.
Key takeaways
- A frame is an identified unit, a lens is a made-to-spec item, and the finished pair is a third object created at assembly. Three records, not one.
- A SKU identifies a model. A serial number identifies the unit. Two frames of the same model and colour stop being interchangeable the moment one is allocated to a customer order.
- Prescription fields - SPH, CYL, AXIS, ADD, PD - are bounded numeric fields, not free text. AXIS is a whole number of degrees from 1 to 180, so a value outside that range is a capture error rather than a note.
- Order state is derived from component states, never typed in. A "ready for collection" set by a button press is the single most common reason a customer drives over for nothing.
- The handover check compares three identifiers: the order number, the serial number scanned off the physical frame, and the identity of the person collecting. If one of them was not scanned, no check took place.
An optical order touches three completely different objects: a frame that exists as one physical unit with a serial number, lenses that do not exist yet and are manufactured to a prescription, and a finished pair that only comes into being at assembly. A wrong handover almost always starts with a shop tracking all three as a single line.
Three objects, three different kinds of stock
An optical shop runs three kinds of stock side by side, and each behaves differently:
- Identified frame stock. A physical unit with a serial number or unique barcode. It can be reserved, transferred between branches and handed over, but it cannot be quietly swapped for another unit of the same model.
- Display frames. The same model in a status that is not sellable. Many shops never separate them, which is how the window display gets sold online or allocated to an order.
- Made-to-spec lenses. Not in stock at all. They are ordered from the lab against the prescription, and their lead time is what actually sets the delivery date for the whole order.
- The finished pair. Created at assembly, and existing only between assembly and handover. It is the one object the customer receives, and it is not identical to any of the three above.
- Returns under adjustment. Glasses back for refitting or repair. Not available, not on order, and not with the customer, and without a status of their own they simply drop out of every count.
The practical consequence: when an order shows the customer one line called "glasses", nobody can say whether the delay is the frame, the lab or the bench.
Why does a frame need a serial number when it already has a SKU?
Because the SKU answers "which model" and the serial answers "which unit". The difference becomes operational the moment a unit is reserved for a named customer.
A worked case: two frames of model FR-4820-BLK in stock. One is reserved against order ORD-11940 and lenses have been ordered for it. Another salesperson sells "a frame from stock" to a walk-in. If the system counts quantity only, the count drops from 2 to 1 and everything looks correct, until the bench discovers that the unit sold was the allocated one. In a system that tracks units, selling the reserved unit is either blocked or requires an explicit override.
Commercial inventory systems separate the two on purpose: Dynamics 365 Business Central defines item tracking by serial number or lot number as a property distinct from the item itself, and supports reserving a specific unit against a document. The same separation between available, committed and reserved quantities is covered at length in store and website inventory sync.
The order record: what must be filled before the lab is called
| Field | Example | Why it matters |
|---|---|---|
order_id | ORD-11940 | The identifier every movement, payment and document hangs on |
customer_id | C-0731 | Not a name and not a phone number, both change and both duplicate |
frame_serial | SN-4820-000318 | The physical unit, not the model |
rx_source | optometrist_in_store | Who produced the prescription |
rx_date | 2026-04-02 | An old prescription is a stop condition, not a comment |
od_sph / os_sph | -2.25 / -2.50 | Right and left as two fields, never one string |
od_cyl / os_cyl | -0.75 / -1.00 | The sign must be explicit |
od_axis / os_axis | 175 / 10 | Whole number, 1 to 180 |
add | +2.00 | Only meaningful on progressive and bifocal work |
pd | 63 | Pupillary distance in millimetres |
seg_height | 19 | Required for progressives, and frequently missing |
lens_spec | 1.60 AR UV | Material, coating and extras as fields, not a sentence |
lab_order_ref | LAB-88231 | The external reference that makes a status query possible |
promised_at | 2026-04-14 | The date promised, separate from the date estimated |
collection_id | PU-11940 | What the customer presents at handover |
The field most often skipped is seg_height, and skipping it is discovered only after manufacture. The field that causes the most argument is promised_at, because overwriting it without keeping the previous value destroys any ability to answer how many times the order slipped.
The order states, and who moves them
Order state is derived from component states. Nobody types it in:
- Opened - a customer and a prescription exist, no frame chosen yet.
- Frame reserved - an identified unit moved from available to reserved, with an owner and an expiry.
- Ordered from lab - an external reference exists. From here the delivery date depends on a party outside the shop.
- Lenses received - physical receipt, with a check of what arrived against the spec that was sent.
- Assembled - the finished pair now exists. Only here does the frame leave stock for good.
- Ready for collection - derived from assembly, and from nothing else. This is the moment a message to the customer is permitted.
- Handed over - after the three-identifier check.
- Returned for adjustment - an active state, not a closed one, with a counter of its own.
The gap between step 5 and step 6 is the whole thing. A shop that sends "ready" when the lenses arrive, before assembly, manufactures customers who wait a full day for nothing. The same discipline of one document chain is covered in quote, order and invoice under one identifier.
What does the handover check actually verify?
It verifies that three independent identifiers agree, and it never relies on visual recognition:
- The order identifier - scanned from the collection slip or the message sent to the customer.
- The serial number of the physical frame - scanned off the unit itself, not off the label on the bag.
- The identity of the collector - the customer, or someone recorded on the order as authorised.
All three must resolve to the same record. If the scanned serial differs from the one on the record, handover stops, even when the model, colour and size match exactly, and especially then. Two identical frames swapped between two orders produce two customers wearing lenses made for somebody else, and the complaint arrives a fortnight later.
Also recorded at handover: who released it, the time, payment status, and whether a final fitting was performed. That record is what lets you answer "who released this and when" without reconstructing it from memory, the same principle set out in garage management: parts, open work and vehicle record.
Where the mistakes come from
- Prescription as free text. "Minus two and a bit" is not a field. If a range cannot be checked, an error cannot be blocked.
- Right and left in one field. Any format that separates the eyes with a comma or a slash will be read backwards by somebody, eventually.
- Display frames counted as available. The order closes, and only then does it emerge that the unit is in the window and scratched.
- A status set by hand. A "ready" pressed in error sends a message that cannot be recalled.
- Swapping a unit without updating. A temple snaps, an identical frame comes off the shelf, and the serial on the record stays the old one.
- An expired prescription. Captured months ago and manufactured from today, with no field stopping the process.
- An overwritten promise date. With no change history, nobody knows the order slipped three times.
What to have ready before building it
- A decision on which items are managed by serial and which by quantity alone. Not every frame justifies it, but the answer has to be a policy rather than a case-by-case call.
- Validity ranges for every prescription field, including what happens on an out-of-range value: block, warn, or require a supervisor.
- A definition of who may release a reservation and when it expires on its own.
- A closed list of states, with an explicit statement of which are derived and which a human sets.
- A logging policy for changes to the promise date: previous value, reason, and who changed it.
Sources
Frequently asked questions
Does every frame in the shop need a serial number?
Not necessarily. The working rule is that a unit reserved for a named customer before handover needs unique identification, because quietly swapping it creates an error nobody can trace afterwards. Items sold straight off the shelf, with no order process in between, can stay under quantity-only management.
What do you do when the lab is late?
Update an estimated date and keep the original promised date as a separate field. Both are needed: one for talking to the customer, the other for measuring the supplier over time. A shop that stores only the current date can never say how many orders ran late or by how many days.
How do you stop a "ready" message going out too early?
By sending it from the state transition rather than from a button. If "ready for collection" is derived exclusively from assembly completion, the message cannot go out before the finished pair actually exists. That is a data-model decision, not a staff-discipline problem.
What happens when a customer changes frame after lenses are ordered?
You open a change movement instead of editing the original order: the old unit is released back to stock with a reason, the new unit is reserved, and the lab reference is rechecked against the new spec. Without that, handover runs against a serial number that is no longer correct.
Keep reading
Related service
Inventory & Purchasing
SKU-level stock, reorder rules and an approval flow that leaves a record.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.