Gelöst Mehrmengen in der Lieferantenbestellung im Sekundentakt gebucht - schlechte Verbindung des MDE´s schuld? [WAWI-36748,WAWI-46415]

[Tsuc]

Hallo JTL Team,

Heute hat uns ein Kunde Informiert, dass unser WMS-Bestand für einen Artikel nicht stimmen kann.
Nach dem ich nachgesehen habe, stimmt die Info vom Kunden. Komischerweise wurde der eine Artikel 6x im Sekundentakt eingelagert! siehe Bild



In der Wawi ist die Einstellung bei Lager->Lager->WMS-Lager->Wareneingang->Mehrlieferung-> Auf Nachfrage zulassen eingestellt


Scheinbar hat da was nicht funktioniert, sonst hätte der Mitarbeiter diesen Artikel nicht so schnell einlagern hätte können, oder?

Meine Vermutung:
Manchmal reagiert das WMS-Mobile Gerät nicht so schnell wie man gern möchte.
Evtl hat der Mitarbeiter mehrmals auf den Knopf gedrückt und auf eine Reaktion vom MDE-Gerät gewartet. Als die Verbindung wieder lief, wurden alle Buchungen nachträglich durchgeführt.
In dem Zusammenhang wurde der Mitarbeiter auch nicht gefragt ob er eine Mehrmenge buchen möchte.

Wie sieht Ihr die Sache?

Würde mich über eine Rückmeldung freuen.

Gruß
Tsuc

 

[Stetto]

Hi Tsuc,

ihr seid noch nicht auf Version 1.6, oder?

https://issues.jtl-software.de/issues/WAWI-46415
https://issues.jtl-software.de/issues/WAWI-36748
https://issues.jtl-software.de/issues/WAWI-46362

Dort haben wir bereits eine Lösung für das Problem entwickelt.

Ich müsste morgen dann mal prüfen lassen, ob wir der Fix auch mit 1.5 kompatiel ist und entsprechend vor dem Release von 1.6 zur Verfügung gestellt werden kann.

 

[Tsuc]

Hallo Stephan,

Wir sind noch auf der 1.5.34.0. Pilotkunde für die 1.6 zu werden, war uns ein bisschen zu heikel

Wenn ein Fix für die 1.5 gibt wäre das natürlich super.

Gibt es schon ein ungefähren Termin für die 1.6?

 

[Stetto]

• Aktuell arbeiten die ersten ca. 30 Pilotkunden produktiv mit Version 1.6
• Die Zahl der Piloten wird sukzessive erhöht
• Sobald genug Pilotkunden auf der neuen Version sind und positives Feedback geben, wird die Open Beta folgen
  • Da das sehr variable Kriterien sind, gibt es derzeit leider noch keinen Termin

 

[Tsuc]

Ich müsste morgen dann mal prüfen lassen, ob wir der Fix auch mit 1.5 kompatiel ist und entsprechend vor dem Release von 1.6 zur Verfügung gestellt werden kann.

Der Fix wäre schon wichtig, da uns der Händler schon auf falsche Betände hinweisen tut, ist schon ein bisschen peinlich...
Unabhänging davon, dass wir kurz vor Weihnachten das natürlich alles prüfen und korrigieren müssen...
Dazu kommt, dass jederzeit dies wieder passieren kann.

Eine positive Rückmeldung wäre gut um m.E. auch notwendig.

Offtopic: Sind auch Fulfiller als Pilotkunden die auch das FFN nutzen mit dabei?

 

[Stetto]

Ja, sogar unsere eigene JTL- Fulfillment GmbH arbeitet mit Version 1.6, sowie die entsprechenden Händler teilweise.

Nach Rücksprache mit der Entwicklung wird es den Fix leider für Version 1.5 und älter nicht mehr geben.

Der 1.6 Fix ist mit der Version 1.5 nicht kompatibel und würde großflächige Änderungen benötigen.

Um den Fehler nicht ganz auszuschließen, aber zumindest zu vermeiden, könnt ihr in den Server-Einstellungen der App > App öffnen > Einstellungen > Server > das globale Timeout erhöhen; bspw. auf >60 Sekunden.

Der Timeout und damit die Doppel-/Mehrfachbuchung dürfte so deutlich seltener bis gar nicht mehr auftreten. Grundsätzlich hängt das Problem i.d.R. aber immer mit einem Verlust der Netzwerkverbindung zusammen, also wenn sich die Mitarbeiter bspw. wähend dem Wareneingang oder der Sammelkommissionierung in einen Bereich bewegen, wo ggf. das WLAN Signal schwach ist und dadurch die Verbindung abbricht.

In der 1.6 ist hier wie im Ticket beschrieben ein "Schutz" drin, so dass diese Buchungen durch eine eindeutige "Session-ID" nicht mehr doppelt druchgeführt werden können.

 

[Tsuc]

Vielen Dank für den schnellen und Informativen Lösungsansatz

 

[Stetto]

Ah, noch ein Hinweis. Falls nicht eh schon bekannt:

Falls ihr in abgelegenen Ecken des Lagers bspw. mit Access Points o.ä. arbeitet, um die WLAN-Ausleuchtung zu erhöhen, müssen sich diese natürlich im selben WLAN-Netz befinden.

Häufig klemmen Kunden (Händler) einfach 0-8-15 Access Points, unkonfiguriert und nicht optimiert, bspw. von AVM einfach an irgendeine Steckdose.

Das führt dann nicht dazu, dass die Netzwerkabdeckung verbessert wird, sondern dazu, dass sich die WLAN-Netze gegenseitig stören und eben auch zu solchen Netzwerkabbrüchen, weil sich das mobile Gerät von einem WLAN-AP abmelden und beim nächsten wieder anmelden muss.


Die eingesetzten Access Points sollten (müssen) demnach das sogenannte Mesh, Handover, Pairing, usw. unterstützen; die Hersteller nennen die Funktion unterschiedlich. Grundsätzlich muss der AP1 dem AP2 "sagen": Hier ist ein Tablet übernimm bitte, ich bin zu weit weg."

 

[Tsuc]

Wir nutzen von Diensleister eingerichtete: Ubiquiti UniFi Access Point AC Mesh Geräte.
Da haben wir leider trotzdem das Problem.

Ich habe den folgenden Vorschlag umgesetzt. Zitat:
Um den Fehler nicht ganz auszuschließen, aber zumindest zu vermeiden, könnt ihr in den Server-Einstellungen der App > App öffnen > Einstellungen > Server > das globale Timeout erhöhen; bspw. auf >60 Sekunden.

 

[Stetto]

Ich habe den folgenden Vorschlag umgesetzt. Zitat:
Um den Fehler nicht ganz auszuschließen, aber zumindest zu vermeiden, könnt ihr in den Server-Einstellungen der App > App öffnen > Einstellungen > Server > das globale Timeout erhöhen; bspw. auf >60 Sekunden.

Sehr gut. Hat es geholfen?

 

[Tsuc]

Sehr gut. Hat es geholfen?

Dadurch, dass der Fehler immer nur sporadisch auftritt ist das sehr schwer zu sagen.

 

[Tsuc]

Sehr gut. Hat es geholfen?

Nein leider nicht. Der Fehler ist gestern 9x aufgetreten.


Folgende Fehler sind in der Ereignisanzeige auf dem Server. Vielleicht hilft das zur Fehlerfindung. Außerdem haben wir mindestens jede Minute das Problem wie hier https://forum.jtl-software.de/threads/abbrueche-bei-der-verwendung-von-jtl-wms-mobile.139311/

IOCompletionCallback
System.ComponentModel.Win32Exception (0x80004005): Der angegebene Netzwerkname ist nicht mehr verfügbar
System.ComponentModel.Win32Exception (0x80004005): Der angegebene Netzwerkname ist nicht mehr verfügbar

System.OperationCanceledException: Der Vorgang wurde abgebrochen.
   bei System.Threading.CancellationToken.ThrowOperationCanceledException()
   bei System.Web.Http.Owin.HttpMessageHandlerAdapter.<BufferResponseContentAsync>d__13.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Web.Http.Owin.HttpMessageHandlerAdapter.<InvokeCore>d__0.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware`1.<Invoke>d__0.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware`1.<Invoke>d__0.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware`1.<Invoke>d__0.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware`1.<Invoke>d__0.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware`1.<Invoke>d__0.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   bei JTL.WMS.MobileAppService.Versioning.VersioningMiddleware.<Invoke>d__7.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei JTL.WMS.MobileAppService.Logging.LoggerMiddleware.<InvokeNext>d__4.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei JTL.WMS.MobileAppService.Logging.LoggerMiddleware.<Invoke>d__3.MoveNext()

Danach kommt dann dieser Fehler:

Exception during request processing.
System.ObjectDisposedException: Auf das verworfene Objekt kann nicht zugegriffen werden.
Objektname: "System.Net.HttpListenerResponse".
   bei System.Net.HttpListenerResponse.CheckDisposed()
   bei System.Net.HttpListenerResponse.set_StatusCode(Int32 value)
   bei Microsoft.Owin.Host.HttpListener.RequestProcessing.OwinHttpListenerResponse.SetStatusCode()
   bei Microsoft.Owin.Host.HttpListener.RequestProcessing.OwinHttpListenerResponse.PrepareResponse(Boolean mayHaveBody)
   bei Microsoft.Owin.Host.HttpListener.OwinHttpListener.<ProcessRequestAsync>d__5.MoveNext()
System.ObjectDisposedException: Auf das verworfene Objekt kann nicht zugegriffen werden.
Objektname: "System.Net.HttpListenerResponse".
   bei System.Net.HttpListenerResponse.CheckDisposed()
   bei System.Net.HttpListenerResponse.set_StatusCode(Int32 value)
   bei Microsoft.Owin.Host.HttpListener.RequestProcessing.OwinHttpListenerResponse.SetStatusCode()
   bei Microsoft.Owin.Host.HttpListener.RequestProcessing.OwinHttpListenerResponse.PrepareResponse(Boolean mayHaveBody)
   bei Microsoft.Owin.Host.HttpListener.OwinHttpListener.<ProcessRequestAsync>d__5.MoveNext()

 

[Stetto]

Hallo,

eröffne bitte über das JTL-Kundencenter einen Supportfall. Hier im Forum werden wir keine Fortschritte machen.

Die Ursache des Fehlers ist ja wahrscheinlich bekannt und wie oben beschrieben für Version 1.6 behoben und für Version 1.5 nicht geplant:
* https://forum.jtl-software.de/threa...huld-wawi-36748-wawi-46415.144038/post-791052
* https://forum.jtl-software.de/threa...endung-von-jtl-wms-mobile.139311/#post-803558

Wie ich bereits schrieb, ist es ein sehr umfangreicher Fix und da in Anbetracht der großen Menge von WMS-Kunden kaum welche betroffen sind, ist die Prio relativ niedrig.

Über einen Supportfall können wir das ggf. nochmal eskalieren und prüfen und ein neues Ticket im Issue-Tracker anlegen.

Hinterlege im Supportfall auch die Links zu deinen Forumsbeiträgen.

 

[voxura]

Hallo,
gibt es dazu eine Lösung?
Wir haben das gleiche Problem und werden wohl auch nicht zeitnah auf die 1.6 updaten können.