How ERP, Printer, Scanner and Packaging Line Work Together

A serialized packaging line involves at least five kinds of system: an ERP, line software, one or more coders, cameras or barcode readers, and the line's own control system. Often there is a cloud platform too. Each is good at something different, and each is tempted to take on jobs that belong to another.

This guide sets out who should do what, which system is the record for which fact, and where integrations usually go wrong.

The cast of characters

The ERP (enterprise resource planning system) is the company's business backbone: products, GTINs, production orders, batches, stock and, in many serialization designs, the authority that issues serial numbers. It works at business speed — seconds to minutes are fine.

Line software (a line gateway or edge controller) lives on the factory network. It takes serials from the ERP, feeds the coder, tracks each pack, compares camera reads, decides rejects, records carton contents and reports results back. It works at line speed.

The coder prints variable data — including the serialized code — on each pack, and acknowledges each message it handles.

The camera or barcode reader images each pack after the coder and returns what it decoded.

The PLC (programmable logic controller) runs the machinery: conveyors, sensors, reject devices, stack lights. It handles machine timing and safety interlocks.

Label printers and packing stations create carton and pallet labels — often carrying an SSCC — and capture which items go into which carton.

A cloud platform (optional) builds services around the product identity: traceability views, partner data sharing, consumer pages, authentication checks, loyalty.

Who owns which fact

The most useful thing an integration team can produce is a table like this, agreed before any hardware is bought.

Two principles sit behind the table:

1. One owner per fact. If both the ERP and line software can create serials from the same range, duplicates are only a matter of time.
2. Devices report; software decides. The coder, camera and PLC each report what they did. Line software combines those reports into a decision about the pack. No single device knows the full truth.

How a single pack flows through them

1. The ERP releases a production order and a block of serials for batch 25A117.
2. Line software downloads the serials into its local pool.
3. A sensor (via the PLC) signals a pack at the coder. Line software sends the next serial; the coder prints and acknowledges.
4. The camera decodes the pack; line software compares it with the expected serial.
5. On a mismatch or no-read, line software tells the PLC to reject; the PLC fires the reject device and a chute sensor confirms removal.
6. Verified packs are packed. Line software records carton contents and has a carton label printed.
7. Line software queues the carton registration and delivers it to the ERP.
8. Optionally, event data — aggregation of packs into cartons, for instance — flows to a traceability repository or cloud platform.

The full station-by-station story is in the journey of a serialized product through a packaging line.

Two speeds, one bridge

The ERP and the line operate at very different speeds. The line needs answers every half-second; the ERP can take seconds and occasionally much longer. That is why line software exists as a bridge: it keeps time-critical work local and synchronises with the ERP in the background. We explain the reasons in why edge software matters on a packaging line.

ERP and EPCIS are not the same thing

Teams sometimes ask whether supply-chain event data replaces the ERP. It does not. The ERP manages business transactions and stock. EPCIS is a GS1 standard for capturing and sharing event data — what happened, when, where and why — between and within companies. They answer different questions and usually coexist. See EPCIS vs ERP.

Common integration pitfalls

• Two serial authorities. The ERP issues serials, and someone also configures the coder's built-in counter. Duplicates follow.
• ERP in the real-time loop. Every print waits for an ERP call. The line stops whenever the ERP is slow.
• Silent identity changes. A new code format — for example, switching from a GS1 element string to a QR code carrying a GS1 Digital Link — is introduced at the coder without re-validating the camera, packing station and ERP mapping.
• Unclear failure behaviour. Nobody has decided what the ERP should do when it receives a carton registration twice, or what line software should do when the ERP rejects one.
• Assumed device compatibility. A coder or camera is chosen from a datasheet. Protocol, firmware, substrate, speed and reader behaviour all need testing on the actual line.

A worked example of ownership in practice

At Maison Ardent, a fictional perfume house, the ERP team wants carton registrations within a minute of carton closure. The line team wants production never to wait on the ERP. The agreed design:

• the ERP issues serials per production order and is the record for serial values;
• line software is the record for pack and carton facts until registration;
• registrations are queued locally and delivered in the background, each with a stable registration ID the ERP uses to ignore duplicates;
• if the ERP rejects a registration for a business reason, it becomes an exception on the supervisor's screen, not an automatic retry;
• a daily reconciliation compares issued, packed, rejected and returned serials across both systems.

Nothing in this design is exotic. What makes it work is that every fact has an owner and every failure has a defined response. For the serial-level detail behind it, see what happens after an ERP creates a serial number, and for how cartons and pallets carry the hierarchy forward, how individual products become cartons and pallets.