Neu SQL Query: Attributwert auf Stückliste vererben

[SebiW]

Hallo zusammen,
wir arbeiten derzeit daran Seller Fulfilled Prime umzusetzen. Dazu haben wir unser WMS Picksystem auf die Versandgrößen der DPD Pakete angepasst (XS-XL).

Nun zu meinem Problem: Die meisten unserer Amazon Artikel sind Stücklisten, die sich aus einem Standardartikel und einem Beilegeartikel zusammensetzen. Der Standardartikel hat als WMS Funktionsattribut jeweils die Pickgröße gesetzt.

Was ich nun gerne tun möchte: Ich würde gerne via SQL Query ein Attribut in den Stücklisten befüllen, und zwar mit jeweils dem größten Wert aus den enthaltenen Stücklistenkomponenten.
Also im Sinne von: Stückliste enthält Artikel mit Komponenten XS XS M L ->
schreibe beim Vater L in ein Funktionsattribut.

Darüber möchte ich dann als Workflow beim Eintrudeln der Prime Bestellungen die richtige Versandgröße zuteilen.

Für Eure Hilfe wäre ich sehr dankbar!

 

[Rico Giesler]

@gutberle Sowas ist doch wieder was für dich oder?

 

[SebiW]

Mhh wirklich keiner eine Idee wie man das umsetzen könnte?

 

[gutberle]

@SebiW - Ich denke, das ließe sich schon lösen, ich verstehe aber noch nicht so recht, wo und für was schon alles Attribute existieren, und ob die maximale Größe z.B. in das WMS Funktionsattribut des Vaters oder in ein separates Attribut beim Vater geschrieben werden soll?- Vielleicht kannst Du noch mal ein klein bißchen ausholen, was schon da ist, was wo geprüft werden soll und was dann geschrieben werden soll? Zum Beispiel auch, WANN diese Schreiberei passieren soll, bei der Anlage der Stückliste, bei Änderungen, manuell???

Das Arbeiten mit Merkmalen und Attributen in Stücklisten ist von SQL/ DotLiquid aus auch leider alles anderes als simpel, weil es hier immer um viele Ecken geht. Deshalb braucht so etwas zumindest ein bißchen Ruhe zum Nachdenken und ich bin leider noch bis Ende der Woche geschäftlich in Portugal unterwegs und ständig eingespannt, so dass ich mir das Problem zwar schon anschauen kann, aber leider erst am kommenden Wochenende, wenn ich wieder in DE bin, sorry.

 

[SebiW]

Hey @gutberle , danke erstmal für Deine Antwort.
Und erstmal halblang, ich finde es super, dass Du so enorm hilfsbereit bist aber das letzte was ich (oder wie ich hoffe irgendjemand) hier erwartet ist dass Du Dir Freizeit um die Ohren haust um bei einer Abfrage zu helfen!
Also mal ganz ruhig, danke für Deine Hilfe und wenn Du mal Zeit hast Dir die Frage anzusehen super gerne, aber in Portugal hast Du sicher besseres zu tun als Queries zu schubsen

Zum Thema:
Was das ganze machen soll: Wir hinterlegen bei einzelnen Artikeln die WMS_Lagereigenschaft in der Logik der Amazon SFFP Paketgrößen, also XS bis XL.
Allerdings sind unsere Amazon Artikel selbst fast ausschließlich Stücklisten, die sich aus Standardartikeln zusammensetzen.

Wozu ich den Workflow verwenden möchte ist folgendes:
Wenn ein Artikel ein Amazon Set ist (eindeutig und einfach bei uns identifizierbar) möchte ich ein weiteres Attribut (Prime Versandgröße) mit dem größten Wert befüllen der bei den Stücklistenkindern hinterlegt ist.
Im Endeffekt brauche ich also eine Abfrage der Werte die sich in dem Attribut WMS_Lagereigenschaft bei den Stücklistenkomponenten befinden.
Da sollte dann eine Liste zurück kommen die bspw so aussieht "XS;XS;M;L"
Die würde ich dann via if else einfach reduzieren im Sinne von
if queryergebnis contains XL
xl
elsif queryergebnis contains L
L usw.
Das wollte ich dann einfach via Wert setzen in das dafür angelegt Prime Attribut bei der Stückliste schreiben.

Aus diesem Attribut leite ich in einem anderen Schritt dann das automatische Setzen der richtigen Paketgröße bei einem SFFP Versand ab, das ist allerdings schon komplett implementiert, bei den bisher bereits vorhandenen Artikeln habe ich das händisch gelöst, auf längere Sicht ist mir das aber zu gefährlich weil ich ein vergesslicher Hund bin.

Den Workflow würde ich wahrscheinlich sowohl bei Artikel erstellt als auch bei Artikel geändert einstellen.

 

[gutberle]

Hi @SebiW,

Du kennst Dich in der Zwischenzeit ja schon selbst sehr gut aus, also spare ich mir das viele Geschreibe über das wo und wie, nur soviel, dass die Abfrage natürlich in die Aktion und dort in einer Erweiterte Eigenschaft gehört.

Sie liefert dann gleich die maximale Packgröße aller Stücklistenkomponenten im Klartext zurück, oder "NB" für "nicht bekannt", falls kein bekannter Packgrößen-Code gefunden wurde oder aber "NV" für "nicht verfügbar" falls gar nichts gefunden wurde.

{% capture query -%}
SELECT MAX(CASE WHEN t1.cWertVarchar = 'XS' THEN 1
          WHEN t1.cWertVarchar = 'S' THEN 2
          WHEN t1.cWertVarchar = 'M' THEN 3
          WHEN t1.cWertVarchar = 'L' THEN 4
          WHEN t1.cWertVarchar = 'XL' THEN 5
          ELSE 0 END) AS nSize  
    FROM tArtikelAttributSprache AS t1
    JOIN tArtikelAttribut AS t2 ON t2.kArtikelAttribut=t1.kArtikelAttribut
    JOIN tAttributSprache AS t3 ON t3.kAttribut=t2.kAttribut
    JOIN tStueckliste AS t4 ON t4.kArtikel=t2.kArtikel
    JOIN tArtikel AS t5 ON t5.kStueckliste=t4.kStueckliste
    WHERE t1.kSprache=0
        AND t3.cName = 'WMS_LagerEigenschaft'
        AND t5.kArtikel={{ Vorgang.Allgemein.Stammdaten.InterneArtikelnummer }}
{% endcapture -%}
{% assign MaxPackGroesse = query | DirectQueryScalar -%}
{% case MaxPackGroesse -%}
{% when 1 -%}
XS
{% when 2 -%}
S
{% when 3 -%}
M
{% when 4 -%}
L
{% when 5 -%}
XL
{% when 0 -%}
NB
{% else -%}
NV
{% endcase -%}

Eigentlich kann man das viel eleganter direkt in SQL lösen, aber dazu hätte ich eine Tabellenvariable gebraucht und JTL blockiert leider grundsätzlich alle "gefährlichen" Befehle wie UPDATE, INSERT, etc. in DotLiquid und sicherlich auch in den Vorlagen JTLDirectQueries. Das macht hier aber natürlich keinen Sinn, weil die Gültigkeit einer Tabellenvariable genau auf die Laufdauer der Abfrage beschränkt ist. Schaden kann man damit also keinen anrichten ...

Ich will mal ein bißchen bohren ob hier nicht in Zukunft ein bißchen mehr Intelligenz möglich wäre, die prüft, ob das Ziel des gefährlichen Befehls eine JTL-Tabelle ist. Der Name einer temporären Tabelle beginnt immer mit # und der einer Tabellenvariable immer mit @, eine reguläre Tabelle aber NIE mit einem der beiden Buchstaben, eine Unterscheidung wäre also eigentlich trivial. Gleichzeitig wäre es ein Riesenschritt nach vorne, wenn man mit den Beiden oder zumindest mit Tabellenvariablen arbeiten könnte, denn das würde viele Dinge möglich machen, die derzeit schlicht nicht gehen. - @Rico Giesler, kannst Du hier helfen, die richtigen Ohren zu finden?

Gruß,
Ingmar

 

[Rico Giesler]

@gutberle
Hast eine Nachricht dazu bekommen...

 

[SebiW]

Hallo gutberle,
wie immer stehe ich erschlagen vor Deiner Hilfe. Vielen Dank! Du nimmst mir damit eine riesen Sorge von den Schultern. Großartig.
Ich fürchte ich werde le Chef erklären müssen, dass aus der Kaffeeplantage ein Südseeinsel werden sollte
Danke nochmal,
Viele Grüße
SebiW

 

[Rico Giesler]

@gutberle
Ich hab mal zu deiner Idee mit den temporären Tabellen ein Ticket erstellt welches hier eingesehen werden kann https://issues.jtl-software.de/issues?query=WAWI-21742
Hier dürft ihr wie immer eure Stimme und Kommentare abgeben.
Allerdings müssten sich dafür schon ein paar Leute finden, denn derzeit ist es nur als Idee aufgenommen.

 

[gutberle]

Danke Rico, hab schon mal gleich dafür gestimmt ...
Gruß, Ingmar