What to Clarify About Traceability Before Automating Your Delivery Process

Can you tell me by Monday which customers received this batch? That question does not come from a consultant. It comes from a manufacturer, a regulator or a customer, and it rarely arrives at a convenient moment.

Anyone who can answer it with a database query has a well-cut data model. Anyone who can only answer it with a weekend of phone calls has an automation working one level too high. This is not a technical edge case. It is a decision about the scope of the project, and it is made before the proposal.

The item number says what was sold, the batch says what was shipped

An item number describes a product. A batch describes the goods that were actually in the box: one production run with its own expiry date and its own test documentation. For medical devices the unique device identification hangs off it, for equipment the warranty does.

Automations almost always model only the first level, and there is a reasonable explanation. At order time the batch is still unknown. The order states item and quantity, it cannot state more. The batch comes into existence later, in the warehouse, when somebody reaches onto the shelf.

That is exactly where the chain ends in most companies. The warehouse system knows. The ERP knows an order line, the CRM knows a customer, and the automation that turns all this into order confirmation, invoice and dispatch notice works from the order line. Query by item and you get an answer in seconds. Query by batch and you get a phone call with the warehouse.

Where the batch falls out along the way

A barcode on the outer carton usually carries four pieces of information: item number, batch, expiry date, quantity. What gets picked up are the item number and the quantity, because those are the two fields the target system demands. The other two are optional, and at first setup optional almost always means dropped.

Sometimes the data falls out even earlier. At goods receipt the pallet is scanned, the warehouse system records batch and expiry date, and what travels into the ERP is a total of item, quantity and delivery note number. Whatever sits in stock afterwards is a number without an origin. Everything built on top of it inherits that gap, and no check at goods issue recovers it.

Then comes the case no simple data model anticipates: one batch does not cover the ordered quantity, part comes from one lot and the rest from another. The design allows one field per line. Either the last scan wins, or a text field appears with two numbers in it, readable by a human and by no query.

With the expiry date the problem is the format. The label carries a four-digit month and year, and depending on the scanner a different notation ends up in the system. A rule such as "do not ship with less than six months of remaining shelf life" cannot compute on that, so it never gets built.

And then there are returns. Almost everywhere returns run through a process that was built later and is thinner. The item goes back into stock, the batch is not recorded, and from that moment goods sit in inventory whose origin nobody can reconstruct.

Why no acceptance test reveals this

Nothing shows up during acceptance testing because the test case is the simple case. Create an order, pick one line from one storage location, print the delivery note. One batch, one expiry date, everything fits.

The cases that break need conditions nobody creates in a test: a remainder that does not cover the quantity, a return from an old lot, a supplier changing lot size mid-year. Nobody tests a recall anyway, it sounds like a catastrophe rather than a requirement.

On top of that, the chain stays green. A missing batch does not raise an error, it produces an empty field, and empty fields do not stop a run. It only becomes visible when somebody asks backwards, and that question arrives months after go-live.

What the gap costs day to day, recall or no recall

The recall is the case everyone names and the rarest one. The others run quietly.

In clinical and laboratory purchasing a contractually agreed minimum remaining shelf life is common. If the automation knows stock levels but no expiry dates, it ships goods that are formally fine and contractually a complaint. The credit note follows two weeks later.

Stock figures can be correct and still wrong. A total says there is enough. It does not say that a large share of it expires in a few weeks, because a total knows nothing about batches. Purchasing does not reorder because stock looks healthy, and writes the goods off later.

Without an expiry date in the record, the shortest route in the warehouse also decides which batch goes out. Fresh goods sit at the front, older stock moves to the back and expires. Picking by shelf life is only possible when the date is in the system rather than only on the label.

The point raised least often sits on the customer's side. For certain products a hospital has to document which batch was used for which patient. If your delivery note arrives without a machine-readable batch, somebody there types it in. That is a reason to change supplier, and it never appears in any sales report.

How to build a process that answers the question

The batch belongs on the delivery line, not on the order. The order stays as it is, item and quantity. The assignment is created during picking and hangs off the delivery. That is two levels instead of one, and the lower one is what counts.

It is captured where it comes into existence, which means at goods receipt. Anyone planning to add batch data later at goods issue will not add it, because nobody has time there and the pallet has long been broken down.

Multiple batches per line must be representable. A delivery line receives a list of batch, quantity and expiry date. If the target system cannot handle a list, the line is split during picking. A text field with a comma in it solves nothing, it postpones the work to the day of the recall.

The expiry date is stored as a date, not as a string, and normalised to one format at scan time. A value without a day is set to the last day of the month, which is how it is meant. After that, a rule about remaining shelf life is one line of logic rather than its own project.

For items subject to batch tracking, nothing ships without a batch. That is a hard check before the delivery note prints, not a log entry. If the batch is missing, the delivery stops and somebody gets a task.

What this means for your proposal

Settle one question before the first conversation: does your range require batch or serial tracking, and where is that number created today? If the answer is that it is created in the warehouse and stays there, traceability is not an add-on to the project, it is part of the job. It costs effort at goods receipt and in the data model, and that effort belongs in the proposal rather than in the first change request.

A provider who automates your order processing without asking about batches, expiry dates and returns is pricing the simple case. That is the most common reason a cheap proposal ends up costing more than an expensive one.

Sophera Consulting looks at exactly these points before quoting, puts special cases such as split batches and returns in writing, and builds batch capture at the delivery line into the fixed price, with no subscription. The entry point is free in the automation check.