FAQs answered for you.

For pharmaceutical serialization:

• Unit level: GS1 DataMatrix 2D barcode
• Case level: GS1-128 linear barcode or GS1 DataMatrix
• Pallet level: GS1-128 linear barcode

The barcode must encode: GTIN (AI 01), Serial (AI 21), Batch (AI 10), and Expiry (AI 17).

DataMatrix size depends on the application:

• X-dimension: Minimum 0.254mm recommended
• Module size: Based on scanning distance
• Overall size: Varies with encoded data

Follow GS1 General Specifications for exact requirements.

Decommissioning removes a serial from active status:

1. Send ObjectEvent with action DELETE
2. Set appropriate disposition (destroyed, sample, etc.)
3. Include reason code if required

Decommissioned serials cannot be used for further transactions.

Common authentication methods:

• OAuth 2.0: Token-based authentication
• Certificate-based: Digital certificates
• API Keys: Unique access keys
• Username/Password: Basic authentication

Check specific portal documentation for requirements.

For product returns:

1. Receive products with receiving event
2. Verify serial numbers against expected data
3. Update disposition (returned, sellable, destroyed)
4. Report appropriate events to portal

Returns workflow depends on country regulations.

Aggregation is the process of recording parent-child relationships between packaging levels - for example, which unit-level products are packed into which case, and which cases are on which pallet.

Aggregation is recorded using EPCIS AggregationEvents with ADD (packing) or DELETE (unpacking) actions.

Read aggregation best practices

A line-level system manages serialization on the production line:

• Serial number assignment
• Barcode printing
• Verification and inspection
• Aggregation at packaging

It interfaces with enterprise systems for data exchange.

A barcode scanner reads and decodes barcode data. Types include:

• Handheld: Portable, manual operation
• Fixed mount: Automated line scanning
• Camera-based: 2D barcode capability

For DataMatrix, you need an imager (2D scanner), not a laser scanner.

In EPCIS events:

• readPoint: The specific location where the event observation occurred (e.g., a scanner at dock door 3)
• bizLocation: The business location where objects are after the event (e.g., the warehouse)

Both are typically identified by GLN.

Key differences between EPCIS versions:

• EPCIS 1.2: XML format, widely adopted, CBV 1.2
• EPCIS 2.0: Adds JSON-LD support, sensor data, CBV 2.0

Most MENA portals currently accept EPCIS 1.2, with 2.0 support being added progressively.

An enterprise serialization system manages track and trace at the company level:

• Serial number pool management
• Aggregation data storage
• EPCIS event generation
• Regulatory portal connectivity
• Reporting and analytics

EPCIS queries retrieve event data from repositories:

• SimpleEventQuery: Search events by criteria
• SimpleMasterDataQuery: Retrieve master data

Query parameters: eventTime, GTIN, serial number, location, etc.

For product recalls:

1. Identify affected serial numbers
2. Query EPCIS repository for current locations
3. Send ObjectEvent with disposition 'recalled'
4. Track return/destruction events
5. Report to regulatory portals as required

EPCIS provides full traceability for efficient recall execution.

To obtain a GS1 Company Prefix:

1. Contact your local GS1 Member Organization
2. Complete the membership application
3. Pay the membership fee
4. Receive your unique Company Prefix

MENA GS1 offices: GS1 UAE (gs1.ae), GS1 Saudi Arabia (gs1sa.org), GS1 Egypt (gs1eg.org)

Aggregation inference means deducing child contents from parent events without explicit disaggregation:

• Scan pallet → infer all cases and units inside
• Reduces scanning requirements
• Requires accurate aggregation data

Not all portals support inference.

No. While technically the SGTIN (GTIN + Serial) would be unique, best practice is to use unique serial numbers across all products to avoid confusion and simplify tracking.

Most serialization systems generate globally unique serial numbers.

EPCIS events should be reported in chronological order. Reporting out of order may cause:

• Validation errors on some portals
• Inconsistent product status
• Failed aggregation relationships

If events arrive late, ensure eventTime reflects actual occurrence time, not submission time.