Rotable Spare Part Data Model: Fields, States and Pool Size

Key takeaways

• A consumable leaves stock once, a rotable comes back, so a quantity on hand cannot describe one. You track it by serial number and by state, and the state decides whether it counts as stock.
• Pool size is set by repair turnaround and removal rate, never by price. Worked below: twelve positions removed once every 24 months need 3 spares at a 60 day turnaround and 5 at 120 days.
• Repair cost belongs to the serial, not the part number. Worked below: SN‑00318 has absorbed 6,590 euro against a 9,400 euro replacement and should be scrapped, while SN‑00322 at 2,320 euro should not.
• When a vendor ships a replacement before it receives the failed unit, the count reads one too high until a core_owed flag closes it. Worked below: 0.44 of a unit carried all year that the plant does not own.
• Worked below: the same fifteen serials give a pool availability of 20.2% or 6.6%, depending on whether units in transit and in repair are counted. The gap is 2.00 units and 13.6 percentage points.

A consumable is consumed, a rotable comes back

A filter leaves the storeroom once and never returns. A gearbox leaves, fails, comes off the machine, goes away for repair and arrives back on the same shelf months later.

That difference breaks every piece of quantity based stock logic. Quantity on hand, reorder point and consumption per work order all assume the part is gone.

A rotable is not gone, it is somewhere in a loop. So the record you need is a serialised unit with a state machine on it, plus the events that move it.

What this page covers that the others do not

Our guide to repairable versus consumable spare parts owns the concept, the economics and why a float exists. This page does not repeat that argument.

This page specifies the record: the fields, the states, the allowed transitions, the pool arithmetic and the year end reconciliation.

Three neighbouring pages own the rest. The downtime consequence of a missing part, including fill rate and the wait reason code, belongs to spare parts availability and downtime.

The storeroom as a whole is spare parts management. Where an installed rotable hangs is the asset hierarchy data model, and the removal itself the equipment failure record data model.

The same object wearing three hats

A rotable is three things at different moments, and most systems model one. Fitted, it behaves like an asset, with a position, a meter and a history.

On the shelf it is stock, with a location and a value. In the repair loop it is the subject of a work order, with labour, cost and a test certificate.

Four records, and why they are not one

Plants that struggle with rotables hold them as a part number with a quantity, and keep the serials in a spreadsheet beside it.

The pool holds the policy, the unit holds the truth, the exchange holds the moment, the repair order holds the money.

The rotable pool record

The pool is the part number level record. It carries no quantity of its own, because the quantity is derived by counting units in the right states.

Six of those carry the weight. Skip them and you size the pool by argument instead of arithmetic.

pool_size is derived and never typed. It counts units in any state except scrapped, and a typed copy will disagree with the serials within a month.

The rotable unit record

This is the serialised individual, and the whole model hangs on it. One row per unit, from purchase to scrap.

Five of these never make the first version, and all five cost money later.

life_meter makes a rotable comparable with an asset. A unit fitted for three spells has three readings in and three out, and its life is the sum of the differences.

The exchange event

An exchange is one moment: a unit comes off a position and another goes on. It is where most models are thin.

removal_reason separates a failure from a planned pull. A unit robbed to keep a neighbouring machine running is not a reliability event, and counting it as one ruins the removal rate.

Keep the list short: failed, suspected, planned overhaul, modification, robbed, removed in error. Six reasons a technician can pick in three seconds beat forty nobody reads.

The repair order on a removed unit

A repair order is a work order whose subject is a part, not a machine. That detail is why many systems cannot hold rotables at all.

tat_days runs from the removal to back_in_store_at, not from the vendor's dates. A vendor measuring goods in to goods out reports a true number that is half the one you live with.

outcome has three values and no fourth: serviceable, beyond economic repair, scrapped. A repair order with no outcome is a unit nobody can find.

The state machine

Seven states cover a rotable's whole life. The last column is what most systems never model, and it is what makes an availability number honest.

One state out of seven counts as available stock. A system that adds up every row not installed is reporting six states as if they were the first.

In transit is the state plants leave out, and it hides the longest. A unit in a crate is neither on the machine nor on the shelf, and left unmodelled it sits wherever looks tidiest.

Allowed transitions and what each must record

A transition that records nothing can be reversed by anyone, with no trace. Each move below has a required payload.

The last move is legal only when the unit was pulled for access or a modification, then tested. Scrapping is legal from anywhere, because a unit can be condemned on inspection.

Notice that no transition fires by itself. A person moves a unit and the system records what they did, the same rule that governs a work order.

How many rotables you actually need

Pool size is a queueing question, not a budget question. Two inputs matter: how often a unit comes off, and how long it takes to come back.

Work it through on one pool. ROT‑4471 is the drive gearbox GBX‑160 fitted to twelve mixer positions in a food plant.

Two of those are assumptions, tested later. The 24 month interval and the 60 day turnaround came from the maintenance manager's memory, not from data.

Step 1: how many units are away at once

Six removals a year, each away 60 days, means the loop holds 6.0 multiplied by 60 divided by 365 units at any moment.

That is 0.99 units, the pipeline quantity, and it is a long run average rather than a ceiling.

Step 2: turn the average into a fill rate

If the number away were always 0.99 you would hold one spare and never be short. Removals arrive at random and cluster.

Model the number away as a Poisson variable with that mean. The fill rate is the chance that it stays at or below the spares you hold.

Two spares miss the 95% target, three clear it. The pool is 12 fitted plus 3 spares, 15 units.

A stricter convention counts the arriving removal too and adds one spare to every answer. Pick one and write it on the pool record.

Step 3: the number that moves the answer

Hold the removal rate at 6.0 a year and change only the turnaround.

Halving the turnaround to 30 days saves one spare, 9,400 euro of capital. Doubling it to 120 days costs two more, 18,800 euro, for the same machines and the same failure rate.

At 120 days, four spares give 94.98% and miss the target on the exact figure. A number that rounds to 95.0% has not reached 95%.

Nothing in that arithmetic used the price of the unit. Cost decides whether you can afford the answer, never what the answer is.

Cost follows the serial, not the part number

Two units of one part number can have completely different histories, and a part number cost report averages them into one harmless figure.

ROT‑4471 has a replacement cost of 9,400 euro and a scrap threshold of 65%, which is 6,110 euro of cumulative repair.

The bad actor

SN‑00318 has been repaired four times, and each repair looked reasonable on its own quote.

The total passed the 6,110 euro threshold at the fourth repair, unseen, because each quote was compared with 9,400 euro rather than with the running total.

The fifth quote is 2,050 euro. Approving it takes the serial to 8,640 euro, or 91.9% of a new one.

The good one, and what the average hides

SN‑00322 carries the same part number and a very different history.

SN‑00318 costs 5.58 euro for every day it runs, SN‑00322 costs 1.13 euro, almost five times less, for the same part in the same plant.

Now average them the way a part number report does. The two serials carry 8,910 euro between them, so the average is 4,455 euro, or 47.4% of replacement, under the threshold.

The average says the part number is fine, and both underlying decisions are then wrong. The field that prevents it is cum_repair_cost on the unit, summed from actual_cost on that serial's repair orders.

The scrap rule, written down

Scrap when any one of three conditions holds, and record which one fired in scrap_reason.

1. Cumulative cost plus the current quote passes the threshold. Compare the running total with replacement_cost multiplied by scrap_pct, never the single quote alone.
2. The repair count passes max_repairs. Some units are condemned by how many rebuilds the casing will take, whatever the arithmetic says.
3. The vendor returns an outcome of beyond economic repair. That is a decision, so store it as an outcome and a cost, not as a deleted row.

Core tracking and vendor exchange

Some vendors do not repair your unit. They ship a serviceable one from their own pool and expect the failed unit back, which they call the core.

The first assumption that breaks is identity. Under vendor exchange the unit you get back is not yours, so a system waiting for SN‑00712 to return will wait forever.

The second is the count. Under advance exchange the replacement lands before the failed unit leaves, so the plant holds both.

The 23 days when the count is wrong

Take pool ROT‑4620, a drive motor with nine units. The vendor ships SN‑00905 on day zero against failed unit SN‑00712.

For 23 days the pool holds ten serials and owns nine. A report that counts rows reads one unit too high, every time.

At seven exchanges a year that is 161 unit-days, or 0.44 of a unit the plant does not own. On a float of three spares, that is 15%.

The field that stops it is core_owed, paired with ownership on the unit. While it is true the incoming unit belongs to the vendor and is excluded from the count.

core_due and core_charge close the loop on the money. Miss the return window, typically 30 days, and the vendor invoices the full core charge, here 4,200 euro.

Worked example: one pool, one year, reconciled

ROT‑4471 from 2025-07-01 to 2026-06-30, which is 365 days. The pool opened with 15 units: twelve fitted and three on the shelf.

The arrangement is repair and return, so the same serials come back and the year reconciles unit by unit.

1. Every serial, on the machine and off it

SN‑00318 was scrapped on 2026-03-31, so it was in the pool for 274 of the 365 days. Every other serial was in the pool for all 365.

Pool unit-days are 14 multiplied by 365, plus 274 for the scrapped serial, which is 5,384. It reconciles: 4,296 plus 1,088 is 5,384.

Twelve positions across 365 days are 4,380 position-days. Units were fitted for 4,296, so a position stood empty 84 days, or 1.9% of position time.

Those 84 days are machines that could not run for want of a gearbox. What that costs in minutes belongs to spare parts availability and downtime.

2. Where the off-machine days went

The 1,088 off-machine unit-days split across four states. This split decides the availability number.

The bottom three lines are the repair loop and add to 730 unit-days. Only the top line, 358 unit-days, was a unit anybody could have fitted.

3. Pool availability, two defensible ways

Define pool availability as the share of pool unit-days in which a unit could cover the next removal. Two systems compute it from the same rows and disagree.

The first is what a quantity based system does by default: anything not issued is stock. The second counts only the state that can cover a removal.

In units of the year the gap is exact. 1,088 divided by 365 averages 2.98 units on hand, 358 divided by 365 gives 0.98 units, a difference of 2.00 units.

That gap is the repair loop, to the day. It is why a plant that believes it holds three spares behaves like one holding one.

Neither number is dishonest. Reporting either without naming the states it counted is.

4. What the year says about the assumptions

Seven removals happened, against the 6.0 the model predicted. Six loops completed inside the year and one ended in scrap.

The assumed turnaround was 60 days and the measured mean is 92.0 days, 53.3% longer. Those six loops add to 552 days, and SN‑00318 spent 178 more before it was condemned.

The removal interval was wrong in the same direction. 4,296 fitted unit-days divided by 7 removals is 613.7 days, which is 20.2 months, not 24.

5. Resizing the pool from its own history

Run steps one and two again with the measured numbers. Seven removals a year at a 92 day turnaround put 1.76 units in the loop at any moment.

The plant holds three spares and its own history asks for four. Three buy 89.7%, not the 95% the policy demands.

Five of the seven removals found a unit on the shelf, which is 71.4%. Seven events cannot measure a 90% fill rate, so treat it as a flag.

Two doors are open. A fourth spare costs 9,400 euro, while pulling the turnaround back to 60 days restores the original design with no spare at all.

Look at where the 730 loop days went first. Awaiting despatch and transit are 282 days, or 38.6% of the loop, and neither involves a repair technician.

Five questions to ask a vendor about rotable data

Ask for a demonstration, not an answer. Each takes five minutes in a real system.

1. Show me two units of one part number with different repair costs. If the cumulative figure lives on the part number rather than the serial, the scrap decision cannot be made in the system.
2. Put a unit in transit. Then show the stock figure and say whether that unit is in it. A model with no in-transit state will surprise you at the worst moment.
3. Run an advance exchange in front of me. Receive a replacement before despatching the failed unit, show the count staying flat, then age the core and show the overdue list.
4. Remove a unit and refit it on a different machine. The life meter must carry across both spells, and each machine's history must show the serial fitted at the time.
5. Export twelve months of one pool. Ask for serial, state, state start, exchange id, repair cost and outcome as columns. If the state history is not exportable, it is not really stored.

Before a shortlist, read what is a CMMS and equipment maintenance software, then the CMMS data model.

Labour on a repair order follows the maintenance labour data model, and the removal should raise a record in the equipment failure record data model.

How Fabrico helps

Everything above is a specification to test a shortlist against, not one product's feature list. Here is the honest split.

What Fabrico holds today: an inventory catalogue with min and max levels, deliveries, stock-takes, and consumption booked against the work order that used it.

Parts and machines carry QR codes that technicians scan from the iOS, Android or web app. Suppliers are listed in the catalogue, without supplier messaging.

Work orders are raised and confirmed by your team, never by the system on its own. Approvals, the audit log and analytics with Excel export sit behind them.

The REST API and the SAP and ERP connectors are how a separate serialised repair loop would exchange data with it.

What Fabrico does not have today: serial number tracking of individual units, a rotable pool, an exchange record, a repair order whose subject is a part, and core tracking.

None of the fields above exist in Fabrico under those names. Fabrico also does not do predictive maintenance, production planning or scheduling, and it does not reorder parts on its own.

Where it earns its place is the layer underneath: asset history, the work orders that removed and refitted the unit, and parts consumed per job (see spare parts management).

Want to see how far your rotables fit a real storeroom system? Book a 30 minute demo with a Fabrico consultant, no commitment, or contact us with your questions.