Torek Parts inventory software
Updated
A workshop parts store answers three questions: how many parts we hold, which job they went to, and what a particular machine cost as a result. A spreadsheet answers only the first — and only until somebody forgets to update the file.
In Torek parts are written off straight onto a work order: the mechanic marks what was used, and the balance and the unit’s cost settle in the same action.
| Question | Notebook | Spreadsheet | A store in the system |
|---|---|---|---|
| How many do we have? | Go and look | If the file is fresh | The balance, as it stands now |
| Where did it go? | No idea | A line of text | To a specific job and a specific machine |
| What did it cost that unit? | Not countable | Manual totalling | On the history, automatically |
A practical note: a store stays accurate on one habit — “took a part, marked it on the job”. If marking is awkward, the shelf and the system will part company within a week; which is why it has to work on a phone, in the workshop, in a few seconds.
For a scheduled service the parts are known in advance, and that is worth using. A job can carry a list of planned parts, each one either reserved from stock or flagged as short, so before the machine comes in you can already see whether the job is ready to start. Recurring services do not have to be assembled by hand every time: a service template is a named parts kit applied to a job in one step. At completion the mechanic confirms what was genuinely used, and only that comes off the shelf.
When a part is not there at all, the job does not have to guess. The mechanic can reserve it as back-ordered from the mobile app, the job history records “waiting for part”, and as soon as stock comes in — a closed purchase request, a return or a manual receipt — the oldest waiting reservation is filled first, the history shows “parts arrived” and the assigned mechanic is notified.
A store without a queue of jobs is only a list of shelves. The value appears when parts move through the work order system and settle into a unit’s cost alongside mechanics’ hours — the same picture that fuel tracking fills in from the other side.
A retail store sells; a workshop store feeds repairs. So the key question here is not “how much was sold” but “which job and which machine did the part go to”.
Without that link you can calculate neither the true cost of a repair nor the true cost of keeping a unit on the road.
The balance in a spreadsheet only changes when somebody remembers to change it. At workshop pace that means the file says one thing and the shelf says another.
The second problem is the write-off: a spreadsheet row does not say which job and which machine the part went to, so the cost stays in one undifferentiated pot.
By one route only: the part is written off onto a specific work order, and the work order belongs to a specific asset. Then the balance settles itself and the cost lands where it belongs — in that unit’s history.
Then the job says so. Planned parts sit on the work order with their own state, and a line with nothing available is shown as short rather than quietly booked out — so the manager can see what is holding the job up.
Parts that have to be bought go onto a purchase request with a supplier and quantities, which moves from draft through submitted and approved to ordered. Closing it receives the goods into their store locations automatically.
A mechanic can also reserve a missing part as back-ordered from the mobile app. The job history then shows “waiting for part”; when stock arrives the reservation activates by itself in queue order, and the assigned mechanic gets a “parts arrived” notification.
With a list of the parts used most — filters, oils, pads — and the rule that every part used is marked on the job. A full stock count is worth doing once the flow is running, not before it.
A walkthrough with your own parts list and a real flow of jobs.
Get in touch