Batch-to-Batch Traceability for Melting and Foundry Plants
An interactive prototype of a warehouse and traceability system for melting production, where many lots feed one heat and one heat yields many products.

Batch-to-Batch Traceability for Melting and Foundry Plants
Results
The Challenge
Ordinary warehouse software assumes lots stay intact: receive lot A, store lot A, ship lot A. Melting breaks that. Several raw lots plus recycled internal scrap go into one heat, and one heat produces several finished lots. The relationship is many-to-many, so a traceability report has to come from a graph, not a table. Recall questions make it harder, because forward tracing is both more difficult and more valuable than backward tracing.

What the Prototype Shows
The prototype walks through four stages: raw material receiving, the heat, two-way traceability, and loss and yield. Each lot carries its supplier, original weight and inspection result, with weights read from electronic scales rather than typed. Choose any finished lot and you see what it was made from. Choose any raw lot and you see which products and orders it reached.
- Raw material receiving with inspection status
- Heat as its own entity with furnace, shift and operator
- Backward trace to supplier, forward trace to delivered orders
- Loss and yield per heat, per furnace and per supplier

Key Design Decisions
Four points are built in from the start. The heat is its own record, not a pair of receipt and issue slips. Loss is calculated at heat level and allocated back to each input lot in proportion to its contribution, which exposes real yield per supplier. Recycled scrap creates cycles in the graph, so the trace algorithm handles loops by design. Forward and backward tracing are treated as two separate problems.
Plant Floor Reality
The whole system runs on a server inside the plant, and data leaves only when pushed out through an API. In a plant with furnaces, losing the internet rarely matters. A handheld losing its link to the local server due to interference matters more. Handhelds keep a local queue and sync later, and each action carries a unique ID so repeated syncs create no duplicates.
- Append-only ledger: corrections are new records referencing the old one
- Every weight stored with scale, time, operator and raw value
- ERP and accounting read through the API and never write into the trace chain

Delivery Plan
The proposed rollout has five phases, and each is accepted on its own. Survey and material-flow mapping come first, then the traceability core running alongside the current process. Next are scale, barcode and handheld integration, then loss and yield reporting, then ERP and accounting APIs. If the work stops after phase two, what was built still runs.
Got a similar project?
Tell us about it. First consultation is free.