GS1 Sunrise 2027: Müssen bestehende OEM-Scan-Engines ersetzt werden?

GS1 Sunrise 2027: Müssen bestehende OEM-Scan-Engines ersetzt werden?

GS1 Sunrise 2027 bringt neue Anforderungen an die Verarbeitung von 2D-Codes im Einzelhandel. Für OEM-Hersteller mit bestehenden Seriengeräten stellt sich die Frage, ob ihre Scanlösung dafür geeignet ist. Neben der verbauten Scan-Engine spielen auch Decoder-Funktionen, Schnittstellen und die Verarbeitung der erfassten Daten im Hostsystem eine Rolle.

GS1 Sunrise 2027: Was ändert sich?

Ein OEM-Gerät ist seit Jahren im Einsatz. Die Scan-Engine ist integriert, Elektronik und Hostsoftware sind auf das Modul abgestimmt. Bisher werden EAN-13-Codes gelesen und als Artikelnummer an die Anwendung übergeben. Künftig sollen auch GS1-konforme 2D-Codes verarbeitet werden.

GS1 Sunrise 2027 verfolgt das Ziel, dass Kassensysteme im Einzelhandel bis Ende 2027 neben EAN-/UPC-Barcodes auch geeignete 2D-Codes verarbeiten können. Das betrifft insbesondere Anwendungen zur Artikelidentifikation am Point of Sale.

EAN-/UPC-Codes bleiben weiterhin nutzbar. Eine generelle Pflicht, vorhandene Scanner auszutauschen, besteht nicht. Für OEM-Hersteller wird die Umstellung relevant, wenn ihre Geräte künftig zusätzliche Codeformate unterstützen müssen. Das kann beispielsweise Self-Checkout-Systeme, Kioskanwendungen oder integrierte Scanmodule betreffen.

Code gelesen, Daten nicht verarbeitet

Eine Scan-Engine liest einen EAN-13-Code und überträgt die GTIN als numerische Zeichenfolge. Die Hostsoftware erwartet genau dieses Format und kann die Artikelnummer direkt zuordnen.

Bei einem QR-Code mit GS1 Digital Link sieht die Datenübergabe möglicherweise anders aus. Ein solcher Code kann beispielsweise diese URL enthalten:

https://example.com/01/09526064055028/10/ABC123

Der Pfadbestandteil /01/ kennzeichnet die GTIN. Gibt die Scan-Engine jedoch die vollständige URL aus, erhält die Hostsoftware keine reine Artikelnummer mehr. Eine Anwendung, die ausschließlich numerische GTINs erwartet, kann diese Daten möglicherweise nicht verarbeiten. Der Code wurde korrekt gelesen. Die Artikelidentifikation im Hostsystem funktioniert trotzdem nicht.

Je nach Scan-Engine lässt sich die Datenausgabe über Decoder-Einstellungen oder Firmware beeinflussen. Ob die Hostsoftware die ausgegebenen Daten verarbeiten kann oder angepasst werden muss, ist vom Betreiber beziehungsweise dem zuständigen Software- oder Systempartner zu prüfen.

GS1 DataMatrix und GS1 Digital Link

Auch bei 2D-Codes müssen die Datenstrukturen unterschieden werden. GS1 DataMatrix verwendet GS1-Elementstrings mit Application Identifiers. So kennzeichnet AI (01) die GTIN, AI (17) ein Verfallsdatum und AI (10) eine Charge. Ein QR-Code mit GS1 Digital Link enthält dagegen eine standardisierte URL. Auch ein Data-Matrix-Code kann eine GS1-Digital-Link-URL tragen.

Ob die vorhandene Scan-Engine diese Codes optisch erfassen und die benötigten Daten ausgeben kann, ist deshalb nur ein Teil der Prüfung. Die anschließende Interpretation und Verarbeitung der Daten erfolgt im Hostsystem und muss dort gesondert geprüft werden.

Zwei Codes, zwei Buchungen?

Während der Umstellung können auf einer Verpackung sowohl ein EAN-/UPC-Code als auch ein 2D-Code vorhanden sein. Beide können dieselbe GTIN enthalten. Erfasst das Scansystem beide Codes und überträgt die Artikelidentifikation zweimal, kann daraus eine doppelte Buchung entstehen.

Deshalb reicht es nicht aus, EAN-13 und QR-Code einzeln erfolgreich zu testen. Auch das Verhalten bei mehreren Codes im Sichtfeld muss geprüft werden. Dazu gehören die Codeauswahl und Decoder-Konfiguration der Scan-Engine sowie die Verarbeitung der Scanergebnisse durch die Anwendung.

Weiterverwenden oder ersetzen?

Bei bestehenden OEM-Geräten hängt der weitere Aufwand von der verbauten Scan-Engine und den künftig benötigten Codeformaten ab. Drei Ausgangssituationen sind dabei besonders relevant.

01

1D-Engine vorhanden

Die verbaute Scan-Engine liest ausschließlich lineare Barcodes. Künftig sollen auch QR-Codes oder Data-Matrix-Codes erfasst werden.

TECHNISCHE FOLGE

Eine geeignete 2D-Leseeinheit wird benötigt. Bauform, Arbeitsabstand, Sichtfeld und Schnittstelle müssen zur vorhandenen Gerätearchitektur passen.

NÄCHSTER SCHRITT

Vorhandenes Modul und Einbaubedingungen erfassen. Geeignete 2D-Alternativen aus dem POHL-Portfolio prüfen.

02

2D-Engine vorhanden

Das verbaute Modul kann bereits 2D-Codes lesen. Ob es die künftig benötigten GS1-Codeformate unterstützt und die erforderlichen Daten ausgeben kann, muss geprüft werden.

TECHNISCHE PRÜFUNG

Unterstützte Codeformate, Decoder-Funktionen, Firmware und Datenausgabe anhand der verfügbaren Herstellerinformationen prüfen.

NÄCHSTER SCHRITT

Test mit den künftig benötigten Codes durchführen. Bei Bedarf mögliche Anpassungen der Scan-Engine prüfen. Die Kompatibilität mit der Hostsoftware muss vom zuständigen Systemverantwortlichen bewertet werden.

03

Engine ungeeignet

Die vorhandene Engine erfüllt die Anforderungen an Codeformate, Leseleistung oder Datenübergabe nicht. Eine Anpassung reicht nicht aus.

TECHNISCHE FOLGE

Ein mögliches Ersatzmodul muss hinsichtlich seiner optischen, mechanischen und elektrischen Eigenschaften sowie der verfügbaren Schnittstellen bewertet werden. Auch Serienfreigaben und Verfügbarkeit sind zu berücksichtigen.

NÄCHSTER SCHRITT

Anforderungen und Einbaubedingungen dokumentieren. Geeignete Alternativen beispielsweise von Honeywell oder Cino prüfen und den hardwareseitigen Integrationsaufwand bewerten.

Für die erste Bewertung sind Modellbezeichnung, benötigte Codeformate und Hostschnittstelle besonders hilfreich.

Bestehende Scanlösung prüfen

Sie setzen bereits eine OEM Scan Engine ein und möchten klären, ob im Zuge von GS1 Sunrise 2027 ein Hardwarewechsel erforderlich werden könnte?

POHL Electronic unterstützt Sie bei der Bewertung der hardwareseitigen Anforderungen und prüft geeignete Scan Engines aus dem eigenen Portfolio, beispielsweise von Honeywell oder Cino.

Für eine erste technische Einordnung sind folgende Angaben hilfreich:

  • Modellbezeichnung der verbauten Scan-Engine

  • Einsatzbereich und Funktion des OEM-Geräts

  • Bisher verwendete und künftig benötigte Codeformate

  • Hostschnittstelle und, falls bekannt, Firmware-Version

Anhand dieser Angaben können wir mögliche Hardwarealternativen eingrenzen und deren optische, mechanische und elektrische Integration in das bestehende Gerät bewerten.

Die technische Eignung muss für die jeweilige Anwendung geprüft werden. Die Anpassung und Prüfung der Hostsoftware sowie der nachgelagerten Datenverarbeitung gehören nicht zum Beratungsumfang von POHL Electronic.

Arndt Kruft – Key Account OEM Komponenten bei POHL Electronic
Ihr Ansprechpartner für OEM-Scanlösungen

Arndt Kruft

Key Account OEM Komponenten

Sie möchten klären, ob Ihre bestehende OEM-Scan-Engine die künftig benötigten Codeformate unterstützt oder eine Hardwarealternative infrage kommt? Arndt Kruft bespricht mit Ihnen die Anforderungen an Scanleistung, Schnittstellen und Integration und prüft mögliche Alternativen aus dem POHL-Portfolio.

Produktanfrage

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa.