Gelöst Neues Feature: GS1-128 / EAN-128: Wir beginnen mit der Entwicklung für dieses Feature [WAWI-10752]

[Stetto]

Die Entwicklungsarbeiten für die Unterstützung von GS1-128 und EAN-128 haben begonnen!

Was ist euch bei der Unterstützung besonders wichtig? Was ist ein Must Have? Was ist ein Nice to have? Was ist ggf. ein No Go? Eure Meinung interessiert mich.

Welche Dialoge sollten zwingend, welche optional die Funktion unterstützen und in welchen Dialogen ist es überflüssig?

Im ersten Schritt wird die Funktion in JTL- WMS und JTL- Packtisch+ integriert, im Anschluss zieht JTL-WMS Mobile 2.0 nach und als letzten Schritt (noch offen) wird das Feature ggf. auch für JTL-Wawi zur Verfügung stehen.

Bitte kommentiert hier oder im JTL-Issue Tracker euer Feedback und eure Meinungen!
https://issues.jtl-software.de/issues/WAWI-10752

 

[Stetto]

Hi zusammen!! Schaut bitte mal hier rein: https://forum.jtl-software.de/threa...s-mobile-wawi-10752.109041/page-2#post-612200

Wir haben mit der Entwicklung des GS1-128 / EAN-128 begonnen und benötigen viel viel Feedback von euch! Schickt uns eure Barcodes! Beispiele. Fotografiert oder eingescant.

Welche Felder verwenden eure Lieferanten, wie schaut es bspw. aus, wenn ein GS1-128 Barcode eine Menge 5 enthält, aber nur eine Seriennummer übergeben werden kann?

Euer Feedback ist gefordert!

 

[Marc Völker]

Denke Menge 5 und eine Seriennummer wird es nicht geben, weil es keinen sinn macht, mir wäre aktuell auch nicht bekannt, dass man bereiche mehrfach definieren darf, um so z.B. 5 Seriennummern zu realisieren.
Ich denke die wichtigesten Bereich, oder auch Application Identifier sind

01 GTIN 14 für Artikel
02 GTIN 14 für Stückliste
10 Charge
15 Mindesthaltbarkeit
21 Seriennummer
241 Artikelnummer (wenn man das mal so nennen kann)
30 Stückzahl
310 netto Gewicht (Artikel mit Einheiten im Gewichtsbereich)
311 Länge (Artikel mit EInheiten im Längenbereich)
315 Volumen Liter
314 Flächen m2
316 Volumen Kubikmeter
Hier natürlich auch abwandlungen in anderen einheiten, wie inches feet und yards, welche sicher auch vorkommen können, und dann umzurechnen sind
Denke die 330-349 können aus gelassen werden, da es sich hier um Gebinde handelt
37 Gebinde größe
Da kommen dann sicher auch die varianten für die einheiten oben noch auf gebinde größe bei
400 Lieferantenbestellnummer

Denke das wären so die wichtigsten die klappen sollten.
Ich denke hier wäre aber auch die Ausgabe ganz wichtig, so dass man den GS1-128 als Code128 und GS1-DataMatrix auch drucken kann. Aktuell müsste man die Optische Nummer, und die Codierte getrennt generieren, find das Relativ aufwendig, gerade bei Informationen die eine feste länge haben. z.B. EAN in 01 welche auf 14 Stellen aufgefühlt werden muss, mit führenden NULLEN.
Bitte beachten, die (01) wird im Code ja anders dargestellt, + das CHAR(12) welches bei Teilen mit Variabler Länge genutzt wird.

Wir haben hier vor allem Interesse für die Produktion an dem ganzen. Da wir so viele Informationen zu einer Position leicht durch den kompletten Prozess schleppen können.

 

[Marc Völker]

Was ich im übrigen dann auch für Relativ wichtig erachte, Etikettendruck im Wareneingang, da sollte die Variable für Charge / MHD direkt verfügbar sein. Bzw sogar eine Variable die direkt den GS1-128 darstellt. Und sich dabei natürlich auch auf den aktuellen Wareneingang bezieht, man kann hier natürlich mit SQL tricksen, um an MHD und Charge zu kommen, hat man aber 2 Plätze die parallel den gleichen Artikel einbuchen, war es das Und das sollte bei ner direkt integrierten Lösung natürlich nicht sein, da muss dann was her, was direkt auf an hieb klappt.

Ansonsten hatte __simone__ hier https://forum.jtl-software.de/threa...h-und-jtl-wms-mobile-wawi-10752.109041/page-2 schon was gutes mit den Workflows geschrieben,
da ihr sicherlich nicht alle Informationen, welche im Barcode kodiert werden können (weit über 100 hab ich mal gelesen) um bedingt selber auswerten könnt, wäre es gut, wenn der Barcode mit allen Informationen, vielleicht nur eben aufgeteilt in seine AI + Wert in Wareneingangs und vielleicht auch Ausgangs Workflows verfügbar sind, so dass man hier vielleicht ein Individuelles Mapping von einzelnen Informationen machen kann, und direkt darauf reagieren, oder externe Prozesse damit füttern, die dann diese Informationen weiter verarbeiten können.
Sprich Wareneingang macht, was es direkt kann, führt Workflow aus, der dann im nachgang noch änderungen ermöglicht, bzw über Programmaufrufe / Web Requests externe Sachen ansprechen. Wenn ich das so richtig interpretiert habe, enthält der GS1-128 ja auch keine Stammdaten, sondern alle angaben betreffen die aktuelle Lieferung, wo der gerade drauf ist.

 

[Michael Vogel]

Nur eine kleine Anmerkung zu deinem Text, der GS128 code enthält als erstes immer die EAN Nummer und diese ist artikelspezifisch und nicht lieferungsabhängig.
Bestens beschrieben werden die verschiedenen EAN Codes auf folgender Seite:
www.activebarcode.de

 

[Marc Völker]

Nur eine kleine Anmerkung zu deinem Text, der GS128 code enthält als erstes immer die EAN Nummer und diese ist artikelspezifisch und nicht lieferungsabhängig.
Bestens beschrieben werden die verschiedenen EAN Codes auf folgender Seite:
www.activebarcode.de

Das ist korrekt, aber er kann genauso auch Lieferungsabhängige Informationen enthalten.
Kannst ja mal unter
https://www.gs1-germany.de/common/downloads/gs1_tech/2025_datenbezeichnerkonzept.pdf
gucken.

Datenbezeichner um die 400 sind Lieferungsabhängig, und eben Optional.

Und noch eine Anmerkung, Als erstes die EAN Nummer ist nicht mal gewährleistet, sie kann auch das letzte element sein

 

[Michael Vogel]

Das ist korrekt, aber er kann genauso auch Lieferungsabhängige Informationen enthalten.
Kannst ja mal unter
https://www.gs1-germany.de/common/downloads/gs1_tech/2025_datenbezeichnerkonzept.pdf
gucken.

Datenbezeichner um die 400 sind Lieferungsabhängig, und eben Optional.

Und noch eine Anmerkung, Als erstes die EAN Nummer ist nicht mal gewährleistet, sie kann auch das letzte element sein

Ja auch Du hast recht, ich beobachte unsere EAN Codes schon eine ganze Weile und mir ist noch keiner untergekommen, der die Artikel EAN an das Ende gestellt hat, sowohl bei Konsumer-Artikeln oder auch bei unseren Branchen-Spezifischen.
Die Frage wird seien müssen wie weit man den Aufwand betreiben möchte um jede denkbare Kombination abzudecken. Meiner Meinung nach sollte man einen Standard einrichten und lieber auch andere Internationale Codes wie aus den USA usw. berücksichtigen.
Man sollte die Nutzer vielleicht mal befragen welche Codes bei Ihnen vorkommen.

 

[Stetto]

Man sollte die Nutzer vielleicht mal befragen welche Codes bei Ihnen vorkommen.

Der Bedarf kommt meistens zu uns. Und EAN-128 ist ja erstmal ein ganz klarer Standard.

Hast du andere Wünsche? Welche Codes verwendet ihr? Was benötigt ihr?

 

[Michael Vogel]

Der Bedarf kommt meistens zu uns. Und EAN-128 ist ja erstmal ein ganz klarer Standard.

Hast du andere Wünsche? Welche Codes verwendet ihr? Was benötigt ihr?

Der GSI-128 / EAN 128 ist der am häufigsten verwendete mit Verfallsdatum und Charge, das wäre schon absolut ausreichend. CR-Code wäre schön aber nicht zwingend.
Ich wollte mit meinen Anmerkungen hier nur verhindern, das ein zu großer Aufwand betrieben wird, ohne das diese Sonderfälle öffter auftreten
Ich habe gelesen, der EAN 128 soll mit der Version 1.5 kommen, wann ist damit zurechnen ? Wir bekommen im nächsten Jahr ein neues Medizinproduktegesetzt und da werden wir diesen Code im großen Umfang nutzen müssen, außerdem würde es uns den Weg dahin jetzt schon deutlich vereinfachen, da wir jetzt schon häufig Chargen und Verfallsdaten mitführen und unsere Produkte mit diesem Code ausgestattet sind..

 

[Stetto]

Einen Termin kann ich leider noch nicht nennen, auch wird es vermutlich Version 1.6 - es schiebt sich etwas anderes als 1.5 dazwischen. Das Feature ist für JTL- WMS und JTL- Packtisch+ soweit fertig und wird mit den neuen Aufträgen ausgeliefert. Der erste Pilotkundentest mit der neuen Auftragsverwaltung soll noch dieses Quartal erfolgen.

 

[Richy77777]

Das wäre super, dann könnten wir uns die lästige Eingabe von der Haltbarkeit bei Großen Wareneingängen in WMS sparen.

 

[Stetto]

Die Entwicklung ist soweit abgeschlossen und wird mit JTL-Wawi 1.6 ausgeliefert.

 

[Michael Vogel]

Die Entwicklung ist soweit abgeschlossen und wird mit JTL-Wawi 1.6 ausgeliefert.

Was bedeutet das jetzt ? Version 1.6 ist noch nicht einmal in de Issue Datenbank enthalten.
Wann kommt dann die Version 1.6 ?



Gesendet von iPad mit Tapatalk

 

[JTL_fwenzl]

Die Version, die nach aktuellem Plan als JTL-Wawi 1.6 erscheinen wird, ist im Issue-Tracker zur Zeit noch als "develop-1.5" zu finden.
Diese wird zeitnah noch umbenannt.

Frohe Ostern!

Gruss,
Frank

 

[mitscho]

Der Bedarf kommt meistens zu uns. Und EAN-128 ist ja erstmal ein ganz klarer Standard.

Hast du andere Wünsche? Welche Codes verwendet ihr? Was benötigt ihr?

Datamatrix

 

[Stetto]

Datamatrix ist ja nur ein Barcode-Typ wie CODE-128 oder QR-Code - also kann individuell mit Inhalt gefüllt werden.

Wenn ihr also "GS1-DataMatrix" verwendet, ist der Inhalt identisch wie einer GS1-128 (EAN-128) würde also mit JTL- WMS korrekt verarbeitet werden können - sofern es euer Scanner dann unterstützt.

 

[Michael Vogel]

Hallo Herr Handke,
Datenmatrix des GS 128 ist ja Standardisiert, siehe https://www.activebarcode.de/codes/eanucc128.html
In unserem falle ist dort meistens codiert (01) EAN (17) Verfallsdatum (10) Chargennummer oder seltener (21) Seriennummer enthalten, oder aber (01) EAN getrennt davon (17) Verfall (10) Charge, weiterhin diverse Combis von Ausländischen Produzenten, welch sich aber alle in der Codierung wie dem obigen Link bewegen.
Der QR Code ist da nicht ganz so interessant und wird nicht von allen Herstellern genutzt und kann ja auch nicht jeder Sacnner lesen. Aber auch da meistens EAN / Charge/ Verfall oder Serienummer,

Lesen kann der Scanner das auch jetzt schon nur es kommt halt nicht in den entsprechenden Feldern der JTL an, außer der EAN Code.

 

[Stetto]

Wie gesagt, der Standard besagt nur den Inhalt des Barcodes, der Typ ist hierbei nicht interessant.

Der Code: 010123456789012815051231 kann also sowohl als Code-128, EAN128, GS1128, DataMatrix oder QR-Code verwendet wird.

Lesen kann der Scanner das auch jetzt schon nur es kommt halt nicht in den entsprechenden Feldern der JTL an, außer der EAN Code.

Ja, das ist korrekt. Das Feature steht auch erst ab JTL-Wawi 1.6 zur Verfügung, so wie es Frank vier Post weiter oben schon geschrieben hat.

 

[Stetto]

Der QR Code ist da nicht ganz so interessant und wird nicht von allen Herstellern genutzt und kann ja auch nicht jeder Sacnner lesen.

Sofern wir nicht die Themen mischen - jeder Scanner der DataMatrix lesen kann, kann auch QR-Code lesen. In beiden Fällen handelt es sich um 2D-Barcodes. EAN und Code-128 sind 1D-Barcodes.