rm#23899 (s.auch rm#21018 und 09.10.2017, 10.10.2017, 11.10.2017 )

• Die ASN enthält 9 UEs, die auf Basis von 6 Orders erstellt wurden
  • 3 UEs waren aus einer Order (und Orderposition) erstellt
  • 2 UEs aus einer anderen
  • Alle anderen UEs wurden aus einzelnen Orders erstellt (d.h. 1 zu 1: aus einer Order → eine UE)
  • D.h. 3 + 2 + 1 + 1 + 1 + 1
• Laut dem DA Changelog (s. Anhang zum Ticket) ist einer UE am 22.11.2017 um 07:04:46 der Status “RECEIVED” zugewiesen worden. Also der ganzen DA der Status “PARTIALLY_RECEIVED” zugewiesen worden.
  • Das ist VOR dem System-Update passiert (das Update war am 25.11.2017) → Herausfinden, ob das relevant ist
  • Danach (3 Tage später - am 28.11.2017 zwischen 07:04:46 und 07:05:05) wurden allen anderen UEs der Status “RECEIVED” auch zugewiesen worden.
• Die ASN ist aus mehreren Orders erstellt worden. Wobei eine Order in mehreren ASNs enthalten ist. Vielleicht spielt das eine Rolle.
• Die UEs wurden nicht sequentiell verarbeitet, sondern in dieser Reihenfolge: 1,2,6,3,5,4,7,8,9.
  • UE 1 wurde am 22.11.2017 verarbeitet
  • Alle anderen am 28.11.2017
  • Wenn die UEs aus einer StockMovement(GoodsReceipt)-Nachricht kommen, dann müßten sie eigentlich in der “richtigen” Reihenfolge sein. Nämlich: 1,2,3,4,5,6,7,8,9.
• Im SQL-Log sieht man, dass das Lock 5 Mal gemacht wurde. 1 Mal Insert + 5 Updates (nicht 4 Updates, weil es versucht wird das aller erste Mal ein Update zu machen, und nur wenn der nicht klappt, dann macht man INSERT).
• Alle Befehle wurden von demselben Thread gemacht. Ist es ein Indiz darauf, dass alles sequenziell gelaufen ist?

(Stand 11.01.2018)

ASNs im System: ca. 1200000 (1,2 Millionen)

ASNs bei denen alle UEs auf “RECEIVED” stehen, aber die ASN trotzdem auf “PARTIALLY_RECEIVED”: ca. 1200.

Von diesen ASNs hat ca. die Hälfte (ca. 570) nur 2 UEs.

Bei ALLEN diesen ASNs mit 2 Positionen haben UEs lastChangeDate (oder wie auch immer das Feld heißt), das sich nur um 1-20 Millisekunden unterscheidet. Es gibt keine, wo der Unterschied im Bereich von Minuten ist. Das ist ein Indiz darauf, dass die UEs mit einer StockMovement geupdatet wurden (oder mit 2 die zeitlich nahe beieinander lagen). Zwei Testproben haben ergeben, dass die UEs wirklich mit EINER StockMovement-Nachricht mit mehreren Positionen geupdatet wurden.

• ASNManagerEJB.handleGoodsReceiptMessage()
• Bei den Tests ist mir aufgefallen, dass wenn die erste UX ÜBERliefert wird (tatsächlich gelieferte Menge im GoodsReceipt größer ist als ursprünglich in der ASN definiert ist), dann wird die Menge auf die nächsten UXes verteilt. Sie bekommen dann auch in der ASN Status “RECEIVED”. Das führt dazu, dass auch die komplette ASN Status “RECEIVED” bekommen kann. Das hat mich eigentlich ziemlich irritiert.
• Zu den Problemen, die Lambdas verursachen können, gibt es einige Artikel. Z.B. Java 8 Iterable.forEach() vs foreach loop (s. Antwort von Aleksandr Dubinsky), oder 10 Subtle Mistakes When Using the Streams API. Es wäre vielleicht günstig den "Collections > Parallelism" Lesson vom Java Tutorial durchzuarbeiten.

Supplier-Benutzer: TST_SE_RUAG_POVMI

Testdaten befinden sich im Verzeichnis:

D:\development\projects\rm#23899_StatusPartiallyReceivedAtDAalthoughAllUXandUEhaveStatusReceived\testdata\oneMaterial\

1. PO anpassen und importieren
   • PONumber anpassen
   • Mit JMS Client importieren
2. ASN erstellen
3. Bei der StockMovement Nachricht folgende Felder anpassen:
   • ASNNumber (und DeliveryNoteText wenn man will)
   • PONumber (rm#23899-0xx)
   • MaterialReference (2017_4901081377_0xx1 oder 2017_4901081377_0xx2)
   • DespatchAdviceUX (der Wert wird bei der ASN-Erstellung automatisch festgelegt)
   • DespatchAdviceUE (der Wert wird bei der ASN-Erstellung automatisch festgelegt)

1. PO erstellen
   • PONumber → Zufallszahl?
2. PO importieren
3. ASN auf Basis der importierten PO erstellen
4. ASN Position splitten, so dass 2 Positionen entstehen
5. 2 UX mit jeweils einer UEs erstellen
6. StockMovement Nachricht mit folgenden Anpassungen erstellen:
   • ASNNumber (und DeliveryNoteText wenn man will)
   • PONumber (rm#23899-0xx)
   • MaterialReference (2017_4901081377_0xx1 oder 2017_4901081377_0xx2)
   • DespatchAdviceUX (der Wert wird bei der ASN-Erstellung automatisch festgelegt)
   • DespatchAdviceUE (der Wert wird bei der ASN-Erstellung automatisch festgelegt)
7. Stockmovement importieren
8. Status beider UXes soll RECEIVED sein
9. Status der ASN soll RECEIVED sein (im Fehlerfall - PARTIALLY_RECEIVED)

Das Problem lies sich reproduzieren unter folgenden Bedingungen:

• Order hat eine Position
• ASN hat 2 UEs in jeder eine UX
  • 1 UE mit 2 UXes hab ich auch getestet → alles OK (d.h. es führt nicht zum Fehler)
• StockMovement hat nur eine Position, in der aber beide UX drinnen sind.
  • Wenn in der StockMovement-Nachricht 2 Positionen mit jeweils einer UX sind, dann ist alles in Ordnung (d.h. man kann den Fehler nicht nachvollziehen)

Pro UX wird eine ASN gesucht, manipuliert und gespeichert. D.h. wenn in einer StockMovement Position mehrere UX drinnen sind, dann kommt es zu diesem Fehler. Für jeweils eine wird der Status richtig berechnet, aber wir haben mehrere. Wenn alle UX in dieser StockMovement Nachricht auf RECEIVED stehen, dann kann die ASN nicht auf RECEIVED gestellt werden, da sie für die jeweils eine UX auf PARTIALLY_RECEIVED gestellt werden soll.