Lot & Serial Traceability with Recall Reporting

A supplier calls on a Friday afternoon to say one lot of raw material is out of specification. You now need to know, quickly, which of your work orders consumed it, which finished goods lots came out of those builds, which customers received them, how much is still on your own shelves, and where it is sitting. Regulators and retail customers increasingly expect that answer in hours, with documentation.

The data is already in NetSuite. Every Item Receipt, Inventory Transfer, Work Order Issue, Assembly Build and Item Fulfillment carries an Inventory Detail subrecord with lot or serial numbers. The problem is that the chain is stored transaction by transaction, not as a graph. Assembling it means a person joining saved searches by hand, one hop at a time, late at night, under pressure, with no audit record of how the answer was reached.

What ECOSIRE builds

ECOSIRE builds a traceability and recall layer inside your own NetSuite account using SuiteScript 2.1, custom record types, Map/Reduce scripts, SuiteQL queries and Advanced PDF/HTML templates. It reads standard NetSuite inventory transactions and writes a persistent genealogy structure alongside them. Your transactions are not modified and your costing is untouched.

Delivery is an SDF project and an unmanaged bundle installed into your account. Nothing is hosted by us and no inventory data leaves NetSuite.

Building the genealogy graph

A Map/Reduce script walks inventory transactions and their Inventory Detail subrecords, creating Trace Node records for each lot or serial at each location and Trace Link records for each movement or transformation between them. Receipts link a vendor lot to your inbound lot. Transfers link a lot across locations and bins. Work order issues link component lots into a build. Assembly Builds link that build to the output lot on a lot numbered assembly item. Fulfillments link an outbound lot to a customer and a sales order. Adjustments, returns, repacks and rework are handled as explicit link types so the chain does not silently break where quantity appears or disappears.

The script runs incrementally on a schedule and can be re-run for a date range for backfill, so historical transactions are traceable from day one rather than only new activity.

Forward trace

Given a vendor lot or an inbound receipt, a forward trace answers where it went. The result is a chained view from the receipt through every transfer and work order, into each assembly build and each output lot, and out through item fulfillments to sales orders, customers and shipment dates, with quantities at each hop. Quantity that never left is reported separately by location and bin, with its current inventory status, so quarantine and disposition are actionable rather than theoretical.

Backward trace

Given a finished goods lot or a serial number returned by a customer, a backward trace answers where it came from. It walks the graph in reverse to the assembly build, the component lots consumed, their receipts, the vendors, the purchase orders and the receipt dates, plus any intermediate rework or repack steps. This is the one-up one-back evidence most food, pharmaceutical and regulated manufacturing audits ask for, produced from your own transaction record rather than a spreadsheet reconstruction.

Recall events and the recall pack

A Recall Event is a custom record. You enter the trigger lot or serial and the reason, and the script assembles the trace, freezes it as a point-in-time snapshot, and produces a recall pack: affected customers with contact details from the Customer record, shipments with dates and quantities, remaining on-hand by location and bin, affected component or output lots, and the originating vendor and purchase order. The pack renders to PDF through an Advanced PDF/HTML template using N/render and is attached to the Recall Event in the File Cabinet, so what you sent to a regulator or a customer is preserved exactly as sent.

Because the snapshot is frozen, subsequent transactions do not rewrite the record of what you knew and reported at the time.

Quarantine and fulfillment blocking

Finding affected stock is only useful if it stops moving. A Recall Event can place affected lots on hold. Depending on which features your account has enabled, that means setting an unavailable Inventory Status, moving quantity to a designated quarantine bin, or both. A User Event script on Sales Order and Item Fulfillment then blocks the affected lot or serial from being committed or shipped, with a message that names the recall event rather than a generic error, so warehouse staff know why and who to call.

Release from hold is a separate, permissioned action that writes to the audit record.

Expiry, shelf life and FEFO

For lot numbered items with an expiration date on the Inventory Detail record, a scheduled script monitors shelf life against thresholds you define per item class or customer, and produces alerts and saved searches for stock approaching expiry, stock that will expire before a customer's minimum remaining shelf life requirement, and stock already expired but still available. Where you pick first expired first out, allocation suggestions surface the correct lot on the sales order.

Mock recalls

Auditors and retail customers routinely ask you to demonstrate a recall, not describe one. A Mock Recall mode runs the full trace and generates the pack without placing holds or notifying anyone, and it logs elapsed time from trigger to completed pack. That log is the evidence that your traceability process meets a stated time target, and it is stored as a record you can produce on request.

Who this is for

Food and beverage processors, contract manufacturers, nutraceutical and pharmaceutical operations, medical device makers, and any NetSuite account where lot or serial genealogy crosses work orders and assembly builds rather than being a straight buy-and-resell chain. If you only resell serialised finished goods with no transformation, native lot and serial searches may already answer your questions, and we will tell you that before quoting.

How delivery works

This is a build-to-order customisation. It starts with a scoping call covering your item structure, whether you use lot numbered assemblies, how rework and repack are recorded, which features are enabled in your account, and what your recall documentation has to contain. We then issue a fixed written quote and scope. The build typically takes two to four weeks, longer if historical backfill spans many years of transactions. Installation goes into your sandbox first, where you run a real backward trace on a real finished lot and confirm the chain matches what your quality team knows to be true. A production install follows in an agreed window, with the SDF project and unmanaged bundle handed over, plus a defined support window for defect fixes.

What this is not

It is not a quality management system, not a hosted traceability service, and not a subscription. It is a customisation of your own NetSuite account that you own outright, and it makes no claim to certify your compliance; it produces the evidence your compliance programme needs from your own records.