Items and serials

Every physical item you service becomes a uniquely serialised record in the item registry on the Services page. This gives each tool, gauge or wheel a stable identity you can scan, look up and price against over its working life.

Registering an item

Register an item from the Services page against the service it is coming in for, and it is given its serial there and then. An order can register its items directly too, so a service order placed in the platform does not have to be typed into the register a second time, and a batch priced in chat creates its items as you accept the rows; see Batch servicing in chat.

Registering from the order you sold it on

The best route is the one that needs no typing at all: register the item from the line on the order that sold it. Pick the order, tick the lines and say how many of each; every item is created against that line with its description, its product, its specification snapshot and the customer already filled in, and it carries the order it came off.

That is what makes a lifetime record real rather than notional. The item drawer links straight back to the order it was sold on, so a tool coming in for its fourth regrind can be traced to the day you supplied it, at what specification and at what price. A tool somebody else supplied is registered the plain way, which is why free description is still there: the traceable route is the good one, not the only one.

Registration keeps free typing to a minimum on purpose. Where a description can come from a record it does, because a register full of hand typed descriptions of the same tool is a register you cannot count anything in.

Registering is sales-grade work. Editing the definitions those items are priced against is not; see Users, roles and permissions.

The item lifecycle

An item moves through a fixed set of statuses: registered, intake, inspection, awaiting approval, in service, completed, returned and rejected. Booking in is the move from registered to intake, and it is where the promised date back is set from the service turnaround. Returned items loop back to intake for their next service cycle, so one serial accumulates its whole history.

Serials

A serial combines your organisation prefix with the next serial number, for example KBD-26-00147. The prefix defaults to the first three consonants of your organisation name and is set once. The registry supports trigram serial search, and the search box accepts scanner input directly so you can find an item by scanning it.

QR dockets

Each item carries a QR code, generated in the browser, that encodes the platform URL for that item. You can print an A6 service docket as a PDF with the QR code, the serial, the customer and the service, so the physical item travels through the cell with its record attached. Scanning that code opens the item straight from the Services page.

Event history and lifetime counts

The item detail drawer shows its attributes, free application context and linked quotes and orders, together with a full timeline. Every status transition writes a service event with the actor and a payload, so the history is complete and explainable.

A lifetime bar tracks times serviced against the maximum. If you set a maximum and the item reaches it, new service requests auto-flag "lifetime reached" as a warning and require an explicit engineer override, which is itself recorded as an event.

Why serialise at all

Servicing is the one part of this business where the same physical object comes back. A tool ground four times is not the same proposition as a new one: it is shorter, it has less coating life left, and at some point regrinding it stops being the right advice to give. None of that is knowable from a description on a docket.

A serial is what makes the object rather than the paperwork the unit of record. Scan it and you have every service it has had, who did each one, what it cost and how much life the customer agreed it had left.