Neu EAN Code, das Ende naht

[frankell]

@frankell

Du bist ja scheinbar auch ein bisschen in dem Thema Scanner, 2D-Barcodes und Auslesen von Daten daraus unterwegs.

Hast Du Dich schonmal mit den Post-Matrix-Codes auf den Briefmarken der Deutschen Post beschäftigt und wie man daraus die Trackingnummer per 2D-Scanner in die Wawi oder ins WMS bekommt?

Siehe z.B. hier: https://issues.jtl-software.de/issues/WAWI-61810 (JTL will das ja vielleicht irgendwann mal umsetzen.)

Bisher nicht, aber klingt nach einer interessanten Aufgabe. Und nach genug Zeit dafür. 2,5 Jahre sind ja nichts für ein Ticket.

Aha!? Aber das bedeutet ja eigentlich nur, dass der Scanner decodieren muss und das richtige Ergebnis an den Packtisch geben muss, wenn ich das richtig sehe!?

Funktionieren tut das schon, ist ja auch völlig unabhängig vom Packtisch/WMS. Aber ich glaube, was @intrinsicforce meint, ist, dass die Prozesse im Packtisch/WMS nicht für die Nutzung von 2D-Codes angepasst/optimiert sind. Sein Beispiel funktioniert solange, wenn es mehr als eine Charge gibt. Gibt es keine zweite, was der Scanner nicht wissen kann, und er dann halt die im Code enthaltene Charge mit übergibt, führt das zu unerwünschten Ergebnissen, weil gar keine Abfrage nach der Chargennummer kommt.

Pauschal immer das Fenster zu öffnen, wenn es nur eine Charge gibt, wird JTL sicher nicht machen. Das wäre ein für alle anderen Kunden vermeidbarer Zusatzschritt. Daher müsste es so etwas wie eine Checkbox á la "Nutzung von 2D-Scannern" geben und vielleicht noch die Auswahl, welche Angaben alle vercodet sind. Dann könnten alle entsprechenden Fenster immer aufploppen und würden durch die Scannereingabe wieder geschlossen.

 

[intrinsicforce]

Aha!? Aber das bedeutet ja eigentlich nur, dass der Scanner decodieren muss und das richtige Ergebnis an den Packtisch geben muss, wenn ich das richtig sehe!?

Möglicherweise... Habe es bislang aber nicht hinbekommen, auch wenn der Aufbau dem GS Standard entspricht, und die Werte mit FNC1 Steuerzeichen (über chr$(12)) abgregrenzt werden. Weder bei QR noch Datamatrixcode hat das geklappt. GS Steuerzeichen (29) löste das Problem auch nicht, der Packtisch erkennt das ganze so nicht. Zwei verschiedene Scanner getestet..

 

[frankell]

Möglicherweise... Habe es bislang aber nicht hinbekommen, auch wenn der Aufbau dem GS Standard entspricht, und die Werte mit FNC1 Steuerzeichen (über chr$(12)) abgregrenzt werden. Weder bei QR noch Datamatrixcode hat das geklappt. GS Steuerzeichen (29) löste das Problem auch nicht, der Packtisch erkennt das ganze so nicht. Zwei verschiedene Scanner getestet..

Aber Du schriebst doch dieses:

Danke, habe das nun auch getestet. Das ganze funktioniert beim Packtisch aber nur in einer bestimmten Konstellation. Und zwar nur dann, wenn mehrere MHD/Chargen zur Auswahl stehen.
Wie macht ihr das denn, wenn nur eine Charge gebucht ist? Wenn auf die ID/MHD/Charge jeweils ein CR-Steuerzeichen folgt, und das MHD/Chargen-Abfragefenster gar nicht erscheint, landet das MHD in das Feld für die Artikelanzahl.

Bei uns klappt es mit Artikelnummer und Seriennummer vercodet.

 

[intrinsicforce]

@frankell : In dem genannten Beispiel, das nur teilweise funktioniert, habe ich aber eben auch CR Steuerzeichen verwendet. Der JTL Support meinte die wären ungeeignet, z.B. für den Fall, dass keine Charge separat abgefragt wird. Die Codes mit dem Carriage Return lassen sich also nicht universell nutzen...

Bei euch klappt das wahrscheinlich deswegen, da eine Seriennummer immer abgefragt wird. Bei Charge/MHD verhält sich der Packtisch wie beschrieben etwas anders.

 

[frankell]

@frankell : In dem genannten Beispiel, das nur teilweise funktioniert, habe ich aber eben auch CR Steuerzeichen verwendet. Der JTL Support meinte die wären ungeeignet, z.B. für den Fall, dass keine Charge separat abgefragt wird. Die Codes mit dem Carriage Return lassen sich also nicht universell nutzen...

Bei euch klappt das wahrscheinlich deswegen, da eine Seriennummer immer abgefragt wird. Bei Charge/MHD verhält sich der Packtisch wie beschrieben etwas anders.

Genau das beschrieb ich:

Funktionieren tut das schon, ist ja auch völlig unabhängig vom Packtisch/ WMS. Aber ich glaube, was @intrinsicforce meint, ist, dass die Prozesse im Packtisch/WMS nicht für die Nutzung von 2D-Codes angepasst/optimiert sind. Sein Beispiel funktioniert solange, wenn es mehr als eine Charge gibt. Gibt es keine zweite, was der Scanner nicht wissen kann, und er dann halt die im Code enthaltene Charge mit übergibt, führt das zu unerwünschten Ergebnissen, weil gar keine Abfrage nach der Chargennummer kommt.

Pauschal immer das Fenster zu öffnen, wenn es nur eine Charge gibt, wird JTL sicher nicht machen. Das wäre ein für alle anderen Kunden vermeidbarer Zusatzschritt. Daher müsste es so etwas wie eine Checkbox á la "Nutzung von 2D-Scannern" geben und vielleicht noch die Auswahl, welche Angaben alle vercodet sind. Dann könnten alle entsprechenden Fenster immer aufploppen und würden durch die Scannereingabe wieder geschlossen.

Da müsste JTL mit ner Erweiterung ran, um es funktionabel zu machen. Wir haben den Fall noch nicht gehabt, dass uns die Seriennummern ausgegangen sind, daher kann es gut sein, dass uns das beim letzten Seriennummernartikel auch passiert.

Aber bei ner Charge passiert das natürlich viel eher, dass sie die einzige auf Lager ist.

Hast Du das mal als Featurewunsch an JTL geschickt?

 

[intrinsicforce]

@frankell Sorry, ich hatte diesen Post ganz übersprungen! Du hast die Problematik absolut richtig erkannt.

Ja, ich habe hierzu über Supportticket ein Featurerequest gestellt, das wurde aber leider konsequent ignoriert. Ticket wurde letztendlich geschlossen ohne neues Issue.

 

[frankell]

Ja, ich habe hierzu über Supportticket ein Featurerequest gestellt, das wurde aber leider konsequent ignoriert. Ticket wurde letztendlich geschlossen ohne neues Issue.

Ein Trauerspiel, wie so oft.