Serialization and GS1 DataMatrix: What Matters in Line Integration

The small square code on a medicine pack is really a data packet that is printed, read, verified and recorded within a few seconds. Doing that without errors for thousands of packs an hour depends on printers, cameras, line software and enterprise systems working in harmony, and software is what creates that harmony.

In this article we explain what is inside the code, how data flows on a serialization line, and what we pay attention to when integrating it.

What is serialization?

Serialization means giving every saleable unit, usually a pack, a unique identity. It goes one step beyond batch-level tracking: instead of "10,000 packs from this batch", you track "this single pack with this serial number". That makes counterfeit prevention, recalls and stock visibility far more precise. As Laetus's serialization page puts it, every package becomes findable at any point in the supply chain.

What is inside the code?

The 2D code used on medicines for human use in Turkey is a GS1-compliant DataMatrix. According to the Turkish barcode and 2D code guideline, it carries four core data elements, each starting with a two-digit prefix called an application identifier (AI):

• (01) GTIN: the product's 14-digit Global Trade Item Number
• (21) Serial number: unique to that pack
• (17) Expiry date: in YYMMDD format
• (10) Batch number

A small but critical detail: the group separator

Serial and batch numbers have variable length. To tell where one field ends and the next begins, a "group separator" character (GS, ASCII 29) sits between them. The FNC1 character at the start of the code signals that the content follows GS1 rules.

A surprising share of the errors we see in the field come from here. A handheld scanner translates the separator into a different character, a middleware strips it, or a screen loses it during copy and paste, and suddenly the serial and batch numbers are mixed up. That is why we keep code parsing in one tested component and test it with different scanner configurations.

How data flows on a serialization line

Serialization systems are usually described in levels, and equipment makers describe their offerings the same way. VISIOTT, for example, refers to Level 2–4 software and ERP integration as part of its serialization solutions. In simple terms:

1. Device level: printer, camera, reject unit, sensors.
2. Line level: line software that hands out serial numbers to the printer, reads camera results and rejects bad packs.
3. Site level: manages several lines; work orders, serial number pools and production records live here.
4. Enterprise level: ERP, product master data, work orders, stock and shipping.
5. External systems: for Turkey, İTS and other stakeholders.

Most of our work sits on the bridges between these levels: getting the work order from ERP to the line correctly, retrieving produced and verified serial numbers from the line, removing rejected packs from the list, and preparing the result for İTS notification.

What we pay attention to in integration

Serial number management

Serial numbers should be random and hard to guess, and never repeat for the same GTIN. Where they are generated, which line and work order they are allocated to, and how unused numbers are returned must be designed clearly from the start.

Verification results

When the camera cannot read a code, or the content does not match what is expected, the pack is rejected. The "good" and "rejected" lists from the line software must reach the enterprise side completely, and a rejected pack's serial number must never appear in a notification. We cover integration with camera and verification systems in a separate article.

Samples and rework

Samples pulled for quality control, reprinted packs and products rejected later are part of real life. If the software does not offer clear workflows for these, operators invent workarounds, and workarounds mean inconsistent records.

Preparing for aggregation

Packs are usually grouped into cases and pallets right afterwards. Serialization data is the input to aggregation, so the two steps should be designed on the same data model.

Master data consistency

Master data such as GTIN, product name, pack type and units per case usually lives in the ERP, with a separate copy in the line software. A small difference between the two comes back as a code printed for the wrong product or a count mismatch during aggregation. That is why we make sure master data comes from a single source and changes reach the line in a controlled way.

Maintenance and change control

Every software change on a validated line goes through the manufacturer's change-management process. That is why we prefer small, testable and reversible changes. We also provide maintenance and support for existing serialization software.

How we start a line integration project

The first step is always to see the floor and follow the data. We trace a work order step by step from the ERP to the printer on the line, then to the camera, the reject unit and back to the enterprise system. Along the way we look for answers to these questions:

• Where are serial numbers generated, and how are they distributed to the line?
• In what form do camera results reach the line software, and when are they passed to the enterprise side?
• What happens when the line stops, a work order is interrupted or the batch changes?
• When do operators intervene manually, and is that intervention recorded?

After this map, the work usually falls into two types. The first is building a missing bridge, for example automating the transfer of work orders and results. The second is making an existing bridge reliable by adding logging, an error screen and retries. Either way, we work first in a test environment, then on a limited line, and review the results together.

The right technology in the right place

Line-level software needs stable, real-time behavior, while the enterprise level needs integration flexibility and reporting. Different technologies may be the best fit for each. We are not tied to one stack; for every level we look at modern, long-lived options. See the scope of our pharma serialization and İTS service.

Frequently Asked Questions

What data does a pharma 2D code contain in Turkey?

GTIN (01), serial number (21), expiry date (17) and batch number (10), encoded in a GS1-compliant DataMatrix.

Why does the group separator matter?

It separates the variable-length serial and batch fields. If it is lost or translated incorrectly, fields get mixed up and notifications fail.

What happens to serial numbers of rejected packs?

Rejected packs must not be included in notifications. The reject list from the line software has to reach the enterprise side completely and be kept on record.

Can you build software for our existing serialization line?

Yes. We work on integration with existing line and site software, maintenance, root-cause analysis and filling in missing workflows.

Facing a similar challenge? Tell us about your project and we'll get back to you within one business day.

All product and company names are trademarks of their respective owners; softhan is not an authorized representative or partner of these companies.