Integrating label printing with your ERP system

When label printing is disconnected from the ERP, people bridge the gap by hand. They read a batch number off one screen and type it into a label design tool, or pick a template from a list and hope it is the current one. Each label is only as accurate as the last person who copied it.

Integrating the two removes that step. A business event in the ERP, such as a goods receipt, a completed work order or a confirmed despatch, sends a print request; the right template and printer are chosen by rule; and the label is filled from the transaction itself. This guide covers the decisions that integration involves. The same applies to a WMS, MES or LIMS, which often hold the event that should trigger the label.

1. Choose the integration pattern

Most integrations follow one of four patterns. Estates that have grown over time usually contain more than one.

• Printing from the ERP itself. The ERP’s own output management generates the label and sends it to the printer. It suits a small number of simple labels drawn only from ERP data. It becomes hard to manage when labels need data from other systems, customer-specific variants, or the same templates at sites that run a different system.
• The ERP calls a label management system. The ERP sends the event and its data through an API or web service; a label management system holds the templates, rules and printers, and returns a result. This keeps label design and control out of the ERP and lets several business systems share one set of templates.
• Through middleware or an integration platform. An integration layer the business already runs carries the event, transforms the data and passes it on. It suits organisations that already route their system-to-system traffic this way, provided the labelling interface is owned and monitored like any other.
• Through a database or file interface. The ERP writes a record to a table or drops a file (CSV, XML or JSON) into a folder, and the labelling system picks it up. It is simple and widely supported, but slower to report problems: a file that is never collected fails silently unless something watches for it.

The right choice depends on how many systems need to print, how many label types and sites there are, how the ERP is hosted, and who will support the interface. An API is not automatically better than a file. What matters is that the chosen pattern reports failures to someone who can act on them.

2. Decide what triggers each label

Every label should trace to a business event, and each event to the system that raises it.

• The event: goods receipt, production order release, work order completion, pick confirmation, despatch or a quality release
• The system that knows about it first, which is not always the ERP: a WMS often holds the pick, an MES the completed batch
• Whether the label prints automatically, or an operator confirms it at a station
• The data the event carries, and anything the labelling system must look up for itself

Triggering a label from the event, instead of asking an operator to remember to print it, is usually where most of the manual work disappears.

3. Map every field to its source

Before building the interface, list every field on every label and where it comes from.

• Master data: product descriptions, GTINs, customer part numbers and pack configurations, usually from the ERP’s item master
• Transaction data: order, batch, quantity, weight, and production or expiry dates, from the event itself
• Generated values: serial numbers, SSCCs and check digits, and which system is responsible for issuing each one
• Rules: customer- or market-specific formats, languages and label variants
• Fixed content: logos, regulatory text and symbols, held in the template

Fields that nobody can trace to a source are the ones most likely to be typed by hand today. This map becomes the interface specification and, later, the test cases.

4. Select the template and printer by rule

The integration should not depend on someone choosing the right template from a list.

• Template selection from data: customer, product family, market, pack level or label type
• Printer selection from the station, line, dock door or site that raised the event
• One data-driven template serving many products, rather than a copy per product
• Template versions approved and controlled, so each print traces to the version used

When templates and printers are chosen by rule, adding a product or a customer is a change to data, with no new label file to draw.

5. Design for failure

A label integration is judged by what happens when something goes wrong. Decide each case before go-live.

• A printer is offline, out of labels or out of ribbon
• Data is missing or invalid, such as a product with no GTIN or a date in the wrong format
• The ERP and the labelling system cannot reach each other
• A request arrives twice: it should not print twice or use two serial numbers
• A label is damaged and needs a reprint: the reprint carries the same SSCC, while a new label needs a new one

Each failure should raise an alert that reaches a named person with enough detail to act, and the interface should have an owner on both sides. Where lines must keep printing if the connection to a central system fails, local print services or queues need to be part of the design from the start.

6. Account for printers and the network

• Printers driven through their native command language, or through drivers, and what the chosen platform supports
• Fonts, graphics and stored formats on the printers that existing labels rely on
• Network access from each site to wherever the print service runs, and the latency the line can tolerate
• Print speed and volume at peak, especially where labels are applied automatically on a line
• RFID encoding, where it is used, tested with the tags actually applied

What prints correctly from a design tool can behave differently on a production printer, so test on the real hardware early.

7. Test the whole chain

• End-to-end tests from the ERP event to the printed and scanned label, for each label type and data variant
• Every failure case from step five, triggered deliberately
• Barcode verification against the relevant GS1 specification, with print quality graded to ISO/IEC 15416 for linear symbols and ISO/IEC 15415 for 2D symbols
• In regulated environments: the interface specified, risk-assessed, tested and documented as part of the computerised system, and kept under change control
• Sign-off by the owners of the data and the labels, as well as IT

Questions to settle before choosing an approach

• Which systems hold the events that should trigger labels, and which hold the data?
• How many label types, variants and sites will the integration serve, now and in three years?
• Is the ERP being upgraded, replaced or moved to the cloud, and how would that change the interface?
• Who owns the interface, and who is told when it fails?
• What must keep printing if the ERP or the network is unavailable?

Where to start

Most of these answers come from the current estate: the labels in use, where their data comes from, and the integrations that already exist, documented or not. A labelling health check establishes them before any design is recommended. From there, the integration fits within the wider design of the label management system, and the ERP, WMS, MES and LIMS integration work follows from what the operation needs. Where an existing labelling system is being replaced at the same time, the legacy migration checklist sets out the order of work.