Spare Parts Demand Data Cleansing: Clean the Transaction History First

A movement export is not a demand history until each transaction has been classified against a defined demand event. Issues, returns, staging, transfers, count adjustments and campaign purchases can all look like quantities moving in or out, yet only some of them represent parts consumed in maintenance. Preserve the raw ledger, define the demand level you are forecasting, then map each transaction to a derived demand series with a traceable reason for every inclusion, exclusion or netting step.

The aim is an auditable input dataset for whoever builds the forecast. It is not a forecasting method, a reorder-point calculation or a part-number merge.

Define the demand event before touching the data

State what one unit of demand means for this analysis. Set the item, location, unit of measure and time basis. Then say which event counts: a part installed on a machine, a part issued to a work order, a part shipped to a field location, or something else. Different definitions give different series from the same export.

The forecast level also changes what belongs in the series. Oracle's Service Parts Planning documentation shows this. It separates shipment, usage and returns histories as distinct data streams. For shipment-based forecasts, it counts shipments to field technician organizations but not shipments to distribution organizations, to avoid double counting. It also says that where the plan covers only the central warehouse, the history should include all outbound shipments from that warehouse. This is one legacy system's documented behavior, not a rule for every system or fleet. The point it supports is that an outbound transfer may be demand at one level and double counting at another.

So an absolute statement such as "transfers are never demand" is unreliable. Write down the level first, then decide.

Build a transaction lineage sheet

Keep the raw export untouched and build the derived series in a separate layer. Each raw transaction gets one line that explains what happened to it.

Do not delete records and do not change the source system. Every derived number should reconcile to the raw ledger through this sheet.

Classify the common event types

The mapping depends on how your system records each event. Treat these as questions to answer for each transaction type, not as fixed rules.

• Issues to a work order. These are candidate demand, but confirm the part was actually used. An issued part can remain staged or unused.

• Returns to stock. A return of an unused issued part should offset the original issue, so link it to that issue. Do not treat a return as a negative sale of unrelated demand. A return of a defective or removed part is a separate supply stream, not a reduction in demand.

• Staging and kitting. Parts moved to a staging location have not necessarily been consumed. Keep staging separate until use is confirmed.

• Transfers between locations. Include or exclude them according to the demand level you defined, and record that choice.

• Count adjustments and corrections. These correct the record. They are not replacement events and should not enter the demand series.

• Recoveries and salvage. Parts recovered from machines or donor equipment are supply events.

• Campaign or project purchases. A one-off retrofit or planned campaign can distort an intermittent series. Tag it as exceptional instead of deleting it, so the forecasting owner can decide how to treat it.

Movement sign alone cannot make these distinctions. A negative quantity may be a use, a transfer out, a write-off or a correction.

Keep zeros and stockouts visible

Periods with no demand are data, not gaps to fill or remove. Keep them. Also flag periods in which stock was unavailable. If a part was out of stock, recorded demand may understate real need, and the forecasting owner needs to know.

Duplicate part identities are a separate problem. If one physical part appears under several numbers, resolve that first, as covered in cleaning up duplicate part numbers in a spare parts master. Do not merge events by matching quantity and date alone.

Reconcile and hand off

A small illustration shows the arithmetic. This is hypothetical and not drawn from any fleet. Suppose a raw export shows 10 issues of a part, 2 returns of unused parts linked to those issues, and 1 transfer out to another site. If the declared demand level is a single site, the derived demand is 8 units, the transfer is excluded and recorded as such, and the sheet shows how 10, 2 and 1 became 8. At a central-warehouse level the transfer could instead be demand, and the result would differ. The sheet is what makes either answer defensible.

The dataset is ready for forecasting when every raw line has a classification, the derived total reconciles to the raw ledger through the sheet, and unresolved events have a named owner. Reorder-point and trigger logic belongs in the separate task of setting reorder points for intermittent undercarriage demand, which consumes this prepared history.

Once confirmed demand and part identity reconcile, KTSU's excavator undercarriage parts collection can serve as the public reference for an item inquiry. Send the confirmed part scope and planning quantities as inquiry inputs. KTSU is not represented as operating your inventory system or providing a forecast, and a supplier inquiry does not commit either party to a quantity.