GUIDE · PRODUCTION RECORDS
How to catch errors in production records
before they reach the report.
Published · ProdCrest
Short answer. Run the same seven checks on every shift-log and ERP export before anyone reads a total: date format, product identity, exact duplicates, missing shifts, units, plausibility against machine capacity, and a cross-check against a second source. Keep every exception on a visible list with a reason. Do not repair rows silently, and do not treat a clean row as proof that the number is true.
Why errors hide in totals
A monthly output figure is usually the sum of hundreds of rows typed by different people on different shifts. Each row can be wrong in a small, ordinary way: a date written the other way round, a product named instead of coded, a row pasted twice, a shot count entered where pieces were expected. Added together, these mistakes produce a total that looks precise and is still wrong. The report rarely shows it, because a total has no place to show doubt.
The checks below come from the reconciliation behind the ProdCrest demo. The demo uses synthetic data: an invented moulding plant with four machines, three shifts and four weeks of records (334 shift-log rows, 112 work orders). Every figure on this page was produced by that synthetic dataset; none is a customer result.
The seven checks
1. Date format
What it catches: dates that can be read two ways. 03/08 is 3 August in one country and 8 March in another. A single row cannot tell you which; the whole file can, because somewhere a day above 12 settles the format.
How to run it: detect the format at file level, then convert every date to one form (YYYY-MM-DD). List rows whose date does not exist on the calendar.
In the synthetic example: 119 shift-log rows had a day and month both of 12 or less, so each was ambiguous on its own. All were resolved with the file-level format.
2. Product identity
What it catches: the same product written as a part number on one shift and as a name on another, which splits one product into two in any pivot table.
How to run it: map every entry to the part number through the product master, matching codes first and names second. Anything that still does not match goes on the exception list, not into an “unknown” bucket that quietly grows.
In the synthetic example: 106 rows named the product instead of giving the part number. All were mapped through the master.
3. Exact duplicates
What it catches: rows pasted twice, usually when a sheet is merged or a shift is re-entered after a correction.
How to run it: define the row key (date, shift, machine, product) and keep the first occurrence. Report what was dropped, so someone can confirm it really was a copy.
In the synthetic example: 4 duplicate rows were dropped.
4. Missing shifts
What it catches: shifts that ran but were never recorded. A missing row lowers the total without leaving a visible gap.
How to run it: build the expected list from the shift calendar and the machine list, then compare it with what was recorded.
In the synthetic example: 6 planned machine-shifts had no row. Their output existed only in the ERP.
5. Units
What it catches: scrap weighed in kilograms in one system and counted in pieces in another, and conversions that rely on an old part weight.
How to run it: convert with the part weight from the product master, and flag products whose master weight has not been confirmed recently. Their converted counts are estimates.
In the synthetic example: ERP scrap was recorded in kg; 2 products had a master weight older than 12 months, so their piece counts were marked approximate.
6. Plausibility against machine capacity
What it catches: numbers that the machine could not have produced. On multi-cavity moulds, the most common one is a shot count typed where pieces were expected.
How to run it: compare reported pieces with the theoretical maximum: run minutes × 60 ÷ cycle time in seconds × cavities. Agree the limits in advance. The demo flags a ratio below 0.5 (likely shots, not pieces) and above 1.1 (more than the machine can make).
In the synthetic example: 21 rows fell outside the limits. Rows that looked like shot counts were multiplied by the cavity count and marked as estimates.
7. Cross-check against a second source
What it catches: everything the first six missed, and the ones they explained. Compare the spreadsheet with the ERP per work order, not per month, so that differences cannot cancel each other out.
How to run it: join on work order (or on date and machine), agree a tolerance, and label every difference with the earlier check that explains it. A difference no check explains is labelled “unexplained”, which is the list that needs a person on the floor.
In the synthetic example: before the checks, 17 of 112 work orders differed between the spreadsheet and the ERP. The labels explained all 17: 7 shot counts, 6 missing shifts and 4 duplicates. The reconciliation guide shows what happens to the totals.
What the checks cannot tell you
A row that passes every check is consistent, not necessarily true. Checks cannot see output that was never recorded anywhere, a scrap reason chosen because it was first in the list, or a shift that was recorded honestly but ran with a different product than planned. They tell you where to look. The explanation still comes from the people who ran the shift.
Make it a routine
- Run the checks on every export, in the same order, before the report is built.
- Keep one exception list with a reason, an owner and a date for each line.
- Review the list in the weekly production meeting, next to the numbers it affects.
- Fix recording at the source when the same exception keeps returning: a drop-down for products, a fixed date format, a counter reading at shift end.
Try it on the synthetic data
The interactive demo shows the checked dashboard built from these records. The raw synthetic files are downloadable: shift log, ERP output and product master.
If your own records need this review, ProdCrest runs it as a production data review, with real data kept in your environment. Describe the report that takes too long.