Lot & Serial Traceability with Recall

The problem

A recall is a timed exam you did not know you were sitting. A supplier notifies you that a raw material lot is contaminated, or a customer complaint points at a specific batch, and the clock starts. Regulators and major customers expect you to identify every affected finished lot, every customer who received it, and every quantity still in your own stock — quickly, and in writing.

Standard tracing dimensions in Dynamics 365 Finance & Operations get you part of the way. You can trace a batch through inventory transactions, and the standard tracing report will show you movements. What it does not give you is a consolidated genealogy that survives multi-level production, co-products and by-products, batch merges and splits during rework, and then continues cleanly out through the load, the packing slip and the invoice to the named customer and delivery address. So the exercise becomes manual: a supply chain analyst opens tracing on one batch, exports to a spreadsheet, opens the next level, exports again, and stitches the tree together by hand over two days.

Two days is not an answer. It is also not auditable — a spreadsheet assembled under pressure is exactly the artifact a regulator will question.

What ECOSIRE builds

ECOSIRE builds a genealogy and recall layer for Dynamics 365 Finance and Supply Chain Management as an X++ extension model — chain-of-command, event handlers and table extensions only, no overlayering.

Genealogy capture

A genealogy link table records parent-child relationships between inventory batch and serial numbers at the moment they are created, rather than trying to reconstruct them later. Links are captured from production picking list and report-as-finished posting (including co-product and by-product output), batch merge and split transactions, rework and disassembly orders, transfer orders across warehouses and legal entities, and purchase receipt where a vendor batch is recorded against your own. Each link stores quantity, posting date, source document and the responsible worker, so the tree carries its own evidence.

The capture runs on posting events, which means genealogy is a by-product of normal operations. Nobody has to remember to do anything extra, and there is no separate data entry step to fall behind.

Forward and backward tracing

A tracing engine walks the link graph in both directions to a configurable depth. Backward from a finished lot answers what went into this — every raw material batch, every vendor, every purchase order and receipt date. Forward from a raw material batch answers the question that actually matters during an incident: which production orders consumed it, which finished lots resulted, which loads and packing slips shipped them, and which customers and ship-to addresses received what quantity on what date. Results render as an expandable tree with drill-through into the underlying InventTrans, production order, load and CustPackingSlipJour records, and export to Excel for the regulator or customer who wants a file.

Cycle detection and depth limits keep the engine safe on real data, where rework and returns can create loops that would otherwise hang a naive traversal.

Recall workbench

The recall workbench is a dedicated form for running an incident. You start from a trigger — a supplier lot, a finished batch, a date range, a vendor, or an item and quality result — and the workbench resolves the full impact set: affected batches, quantity still on hand by warehouse and location, quantity in open orders not yet shipped, and quantity already delivered by customer. From there it drives action: place inventory blocking on the affected batches so nothing further ships, create quality orders, generate a customer notification list with contact details pulled from the standard customer records, and raise the internal tasks that a documented recall procedure requires. Each recall is a record with a status, an owner, a timeline of actions taken and who took them, so the audit trail is created as you work rather than assembled afterwards.

Performance and reporting

Tracing across several production levels on a large transaction history is a graph problem, not a report problem. The engine uses purpose-built indexed link tables rather than repeatedly re-querying inventory transactions, and long-running traces can be pushed to the batch framework so a wide recall analysis runs unattended and lands as a completed result. Genealogy links, trace results and recall records are exposed as data entities through the Data Management Framework with OData enabled, so quality dashboards in Power BI and any external compliance system read the same data the workbench uses. Everything is legal-entity aware, with cross-company tracing available where your transfers cross entities, and financial dimension defaults on recall-related postings follow your existing ledger dimension setup.

Who this is for

Regulated manufacturers and distributors running F&O with batch or serial tracking enabled — food and beverage, pharmaceutical and nutraceutical, medical devices, chemicals, cosmetics, and automotive or aerospace suppliers with serialised component obligations. It is aimed at organisations that have to demonstrate a documented recall capability to an auditor, a customer, or a regulator, and currently do it with spreadsheets.

How delivery works

This app is built to order. Nothing is pre-built and nothing is downloadable.

1. Scoping call. ECOSIRE reviews your production model, tracking dimension setup, co-product and rework flows, legal entity structure, regulatory obligations and F&O version. 2. Fixed quote. You get a written scope and a fixed price before development starts, stating exactly which genealogy sources and recall actions are in scope. 3. Build. Development runs against a matching F&O version, typically two to four weeks depending on production complexity and how many transaction sources need genealogy capture. 4. Install in test. The deployable package goes to your LCS project or ADO pipeline and is applied to your sandbox, where your quality team runs a real mock recall against real historical data before anyone signs off. 5. Production. After sign-off the same package moves to production through your release process. Existing history can be backfilled into the genealogy tables from your posted transactions where the source data supports it — scoped and quoted separately if you need it. 6. Support. A defect-fix window after go-live covers issues in the delivered code against the agreed scope.

Full X++ source is handed over to your Azure DevOps repository, so you are never dependent on ECOSIRE to keep a compliance capability running.