Two modern machines that finally talk to each other
The coder already has an API. The dynamic checkweigher too. The ERP has the work order with the variety, the batch and the shelf life. And yet, on every change someone types the batch and the expiry date by hand into the coder, and then goes back to the ERP to confirm it. With Connect, that data travels on its own and the real weight returns by the same path.
In fresh cheese the printed date is expiry, not best-before: it admits no margin.
The date is calculated from the production date and that specific reference's shelf life, which changes between varieties. And typing that by hand on every change, at the shift's most rushed moment, is the sub-sector's first source of labeling incidents:
- Two typings per change, at the worst moment — the batch and expiry are entered into the coder and then someone goes back to the ERP to confirm it, exactly when the line is pressing.
- The typical failure is always the same — the variety is changed on the line and changing the batch on the coder is forgotten, so an entire pallet leaves with the previous production's batch.
- And it is not discovered in the plant — it is discovered at the customer's platform, when the product is already out and the conversation is a different one.
It is the most frustrating gap of all: both machines are modern, both have APIs and the ERP knows perfectly well which batch and which expiry apply. Simply nobody connected them.
Connect stitching modern systems — speaking to them in their own protocol.
When both ends already have a way to communicate, stitching is not a project: it is closing a specific gap. Neither machine is replaced or reprogrammed.
When the ERP or the MES declares a work order's startup, Connect pushes to the coder the variety, the batch and the calculated expiry date. The coder confirms receipt of the data set, and that confirmation is recorded as evidence of the change.
How Connect operates on the packing line:
- The expiry is calculated, not typed — from the production date and that reference's shelf life, which changes between varieties. The calculation stops depending on someone remembering which one applies.
- A confirmation back as evidence — the coder acknowledges the data set, and that confirmation is recorded. Not only is it known what was requested to print: also what the machine says it received.
- The checkweigher returns average weight and rejects — in parallel and by the same path, towards the ERP and associated with the batch.
- Without replacing or reprogramming anything — they are spoken to in their own protocol. Neither the coder nor the checkweigher changes configuration.
- The variety change stops having a gap — variety, batch and expiry travel together from the order, so the classic misalignment between what the line produces and what the coder prints disappears at its origin.
Batch typed at the coder vs. batch pushed from the ERP
| Aspect | Modern but isolated machines | With iLEAN Connect via API |
|---|---|---|
| Manual typings per change | 2 | Zero |
| Origin of the batch and the expiry | A copy typed by a person | The ERP's work order |
| Expiry calculation | By hand, with whatever shelf life is remembered | Calculated from that reference's shelf life |
| Misalignments between ERP and physical product | The first source of incidents | Estimated reduction ≥80% |
| Where the error is discovered | At the customer's platform | It never happens |
| Changeover time | Several minutes per change | Several minutes less, on every change of the shift |
Impact estimate for your plant — to be validated with your own numbers.
The block below is an estimate to be validated against your plant's actual data. We put it forward so the committee has an order of magnitude; we refine it during the assessment.
- Fresh cheese dairy with a modern coder and dynamic checkweigher, several varieties and several changes per shift.
- Connect pilot stitching the ERP and the line via API bidirectionally. Without replacing equipment or touching the printing hardware. First value expected within a few weeks.
- Estimated payback between 5 and 10 months, not counting the value of the avoided recall. Estimate to be validated.
- A requirement to confirm: that the installed coder has an open API/RPC. Older models demand an intermediate adapter that raises the initial CAPEX without breaking the case — but it is worth knowing before, not after.
- The asymmetric lever: an entire pallet with the previous production's batch detected at the customer's platform costs, between recall and commercial conversation, far more than the pilot.
And the fair question from the quality manager
"What if the AI invents a batch or a date?" — it cannot: here the AI does not generate data, it transports it anchored. The variety, the batch and the expiry come straight from the ERP's work order, and the date is calculated with that reference's shelf life. It is an anchored task, where the best models brought the error below 1.5% [1]. And there is a read-back too: the coder confirms which data set it received, and that confirmation is recorded as evidence of the change.
[1] OpenAI paper "Why Language Models Hallucinate", 2025 — on the reliability of AI in anchored tasks.
What people ask about stitching the coder to the ERP
If both machines are modern, why is there still typing?
Because having an API is not the same as being integrated. The coder exposes its own, the checkweigher its own and the ERP its own, but connecting them usually falls outside the ERP project's scope and outside the line vendor's too, so it lands in no man's land — and gets covered by a person typing, which is the solution always available. Connect exists precisely for that gap: it replaces no system, it stitches them where both already offer a door.
Why is the date so critical in fresh cheese?
Because it is expiry, not best-before: it admits no margin. It is calculated from the production date and that specific reference's shelf life, and that shelf life changes between varieties. Typing it by hand means someone has to remember which one applies to the variety that just entered the line, at the shift's most rushed moment. When the calculation travels from the work order, that failure point disappears: the printed date is the one corresponding to what is actually being produced.
What is the typical failure this eliminates?
Always the same: the variety is changed on the line and changing the batch on the coder is forgotten, so an entire pallet leaves with the previous production's batch. It is not a careless person's error — it is the predictable consequence of asking for two synchronized manual actions at the moment of most haste. And the worst part is where it is discovered: not in the plant, but at the customer's platform, when the product is already out and a recall has to be discussed. With the variety, the batch and the expiry traveling together from the order, the misalignment never happens.
Does the coder have to be changed?
In principle no: work goes against the API it already exposes, and neither it nor the checkweigher is reprogrammed — they are spoken to in their own protocol. That said, there is a requirement to confirm before committing to anything: that the installed coder has an open API or RPC. Older models do not expose one and demand an intermediate adapter, which raises the initial CAPEX without breaking the case but changes the calculation. That is why the diagnostic's first question is always which model is installed, and we check it before giving a payback.
What does the checkweigher returning data contribute?
It closes the circle from the other side. Today the dynamic checkweigher's average weight and rejects live in the machine itself and are consulted there, or transcribed at the end of the shift. Returned to the ERP associated with the batch, that data becomes crossable with everything else: with the vat sheet, with the laboratory's results and with that same batch's pasteurization curve. It is the difference between knowing a shift had more rejects and being able to see with which blend, which draining pH and which source milk they were produced.
Does your coder have an API? We check it and give you the payback of stitching it to the ERP.
We work on your dairy's real data, not ours. We look at your coder and your ERP and size the gap. Assessment with no commitment.
See the payback of stitching it to the ERP ‹ See all 12 fresh cheese cases See food industry