Spalte löst in Vorschau nach 1 auf, im echten Durchlauf aber nach 0

Fragen und Antworten
1

Ich bräuchte mal Hilfe im Flow SH_moveEschwege:


dort werden Bestellungen abgerufen, und für jede Position ermittelt ob sie in einem bestimmten Lager Bestand haben. Das klappt im Großen und Ganzen gut, aber jetzt werden doch immer wieder Bestellungen nicht erfasst, die eigentlich passende Werte haben.


Beispielsauftrag ist 879461, sein einziger Artikel hat Bestand, wenn ich in der Vorschau die den OrderID-Filter benutze, sieht alles gut aus:

image

Diese Spalte ist eine Gruppierung der einzelnen Positionen nach Auftrag, jede hat eine 1 oder 0 je nachdem ob Bestand. Später prüfe ich dann

enoughStock!?contains('1') && !enoughStock!?contains('0')

also ob mindestens eine Position Bestand hat, und keine Position keinen. Das ist Step 17, und in der Vorschau trifft die Bedingung auch zu wie sie sollte


Wenn ich aber mit dem Debug-CSVWriter am Ende den Output von Step 12 oder 13 abgreife, kommt der Wert "0" raus, und der Auftrag wird nicht verarbeitet.


Was komisch ist: wenn ich den OrderID-Filter auf den Auftrag gesetzt lasse und den Flow laufen lasse, DANN wird der Auftrag korrekt verarbeitet. Ohne Filter hingegen nicht, obwohl er definitiv mit ausgegeben wird, siehe CSVWriter.


Ich verstehs nicht, an was kann das liegen?

Danke Daniel

2

Welche Aggregat-Funktion liegt denn auf der enoughStock Spalte beim Gruppieren? (z.B. Summe?)

Die Vorschau z.B. des DatastoreWriters hat Limitierungen, so dass nicht immer alle Daten abgerufen werden. Evtl. führt das zu dem Effekt, dass beim echten Durchlauf irgendwie eine Zeile mehr mit kommt.

Kannst du dir ggf. bei einem echte Durchlauf mal die Positionen in eine CSV schreiben und prüfen, ob da vielleicht doch ein Wert dabei ist, der dein Ergebnis erklärt?

3

Hallo,

die enoughStock pro Auftragsposition, die jeweils eine einzelne 1 oder 0 enthält gruppiere ich (nach OrderHeadOrderID) per Funktion "alle Werte auflisten", und führe dann den o.g. Vergleich darauf aus.


Die ursprünglichen Inhalte ermitteln sich aus dem Wert eines anderen Feldes, in dem ich per zählender Variable den benötigen Bestand der Position vom verfügbaren Gesamtbestand abziehe:

    <#if getVariable(OrderItemsVariantID) == "">
      ${(getStocks?number - OrderItemsQuantity?number)}${setVariable(OrderItemsVariantID, getStocks?number - OrderItemsQuantity?number)}
    <#else>
      ${getVariable(OrderItemsVariantID)?number - OrderItemsQuantity?number}${setVariable(OrderItemsVariantID, getVariable(OrderItemsVariantID)?number - OrderItemsQuantity?number)}
    </#if>

getStocks wiederum hat seinen Wert aus einem Querverweis auf einen Datastore, den ich im selben Flow kurz zuvor erst mit den Beständen der Artikel befüllt hatte.

Von daher kann das Problem auch aus dem Querverweis oder der Zählvariable stammen, es muss nicht zwingend erst die Gruppierung sein.


Wobei ich gestern den Flow ein wenig umgearbeitet habe (egtl nur Input und Output, nicht die Berechnungen zwischen drin), und ich habe zumindest heute keine unbearbeiteten Aufträge mehr feststellen können!


Ob und warum sich das jetzt gefixt hat: ich weiß es nicht.


Das komische war ja eben, dass es in einem "normalen" Durchlauf ohne OrderID-Filter zwar nicht geklappt hat, aber in dem Moment wo ich den Filter auf einen Problemauftrag gesetzt habe, war das Ergebnis wieder wie in der Vorschau (also korrekt).


Falls es wieder auftritt, werde ich die Debug-CSV die Positionen mitschneiden lassen statt der Gruppierung und mich dann wieder melden. Aber ohne konkretes Beispiel geht schlecht ;-)

4

Achso: der Abruf aus dem Datastore muss korrekt gewesen sein, ich kenn ja die Werte aus dem System, die eben besagen dass der Auftrag egtl verarbeitet werden muss.