Inaktiv "Einfache" Stücklisten ... Limits wegen Performance?

marsblau

Aktives Mitglied
7. September 2019
71
7
Wir wollten bedruckte T-Shirts als Stückliste in JTL darstellen bestehend aus zwei Komponenten, dem Ausgangs-T-Shirt und Druckdesign. Entsprechend hat die bedruckte Artikelvariante zwei Komponen (T-Shirt-Variante und Druckdesign-Variante).

So weit auch kein Problem und funktionierte. Bis man die Komponente Roh-T-Shirt in ca. 60000 Stücklisten hatte ... dann wurde die Wawi schlagartig langsam sobald eine Stückliste oder Komponente im System verarbeitet wurde, man mußte 5-10 Minuten warten bis das System wieder ansprechbar ist.

Jetzt zur eigentlichen Frage: Wenn die Stückliste nur aus einer Komponente bestehen würde, würde die Performance auch bei 500000 Stücklisten erträglich bleiben?

Alternativ müßte ich wohl die Bedruckten T-Shirts als normale Artikel führen und im Hintergrund die Lieferanten des Rohartikels hinterlegen?! Dann bleiben Stücklisten außen vor. Es gibt im Forum einen ähnlichen Beitrag aus 2015, in dem das Thema leicht angeschnitten wurde: https://forum.jtl-software.de/threa...cht-stuecklistenartikel-massen-wandeln.80489/

Habt Ihr Erfahrungen damit?
 

Thomas Lisson

Administrator
Mitarbeiter
24. März 2006
15.574
299
Köln
hi,

Wenn die Stückliste nur aus einer Komponente bestehen würde, würde die Performance auch bei 500000 Stücklisten erträglich bleiben?
Ja, da der Artikel ja dann nur aus einer Komponente besteht und nicht 60k.

Aber: Warum arbeitest du hier überhaupt mit Stücklisten? Du hast ja die bedruckten Shirts nicht auf Lager, sondern produzierst nach Bestelleingang, nehme ich an. Hast du hier an einfache Variationen gedacht?
 

marsblau

Aktives Mitglied
7. September 2019
71
7
Nur dass es nicht zu Mißverständnissen kommt ... mir einer Komponente meinte ich lediglich die zweite wegzulassen. Sprich es würde immernoch das Roh-T-Shirt als Komponente von 60000 Stücklisten im System sein, nur eben ohne die zweite Komponente "Druckdesign". Wäre es für das System dann wirklich keine übergroße Belastung mehr?

Der Vorteil der Stückliste gegenüber der einfachen Variante ... die Überlegung ging dahin dass der verfügbare Bestand dann stimmen würde, der sich auch aus den Beständen des Rohartikels im eigenen Lager oder auch des Lieferanten befindet. Habe ich ein Schwarzes T-Shirt in M auf Lager, kann ich es für jeden Auftrag mit einem schwarzen T-Shirt in M nutzen. Deswegen auch der verzweifelte Versucht mit einer Komponente zurechtzukommen.
In normalen Variantenartikeln wäre nur der verfügbare Bestand des Lieferanten verfügbar (indem der Roh-Artikel über Lieferantenartikelnummer angebunden wird), ich könnte jedoch nicht im eigenen Lager Roh T-Shirts auf Lager halten (auf Vorrat einkaufen) und diese dann egal für welches Design nutzen.



Das Bild zeigt die vorherige Strategie mit 2 Komponenten.
Bildschirmfoto 2020-03-07 um 22.49.35.jpg
---
Bildschirmfoto 2020-03-07 um 23.01.50.jpg
 

Thomas Lisson

Administrator
Mitarbeiter
24. März 2006
15.574
299
Köln
In dem Moment, wo eine Komponente in 60k Stücklisten drin ist, wirst du unweigerlich Performanceprobleme haben, da bei jeder Reservierung oder Bestandsänderung 60k Artikel in der Datenbank neu berechnet werden müssen.

Warum muss das Motiv überhaupt als Komponente angelegt sein?

Ich würde komplett von der Stückliste weg - damit kommst du hier nicht zum Ziel. Die Stücklisten sind eher als Setartikel oder einfache Produktionsartikel gedacht, deren Komponenten bestandsführend sind.

Warum nicht so: Das T-Shirt als VarKombi anlegen mit Größe und Farbe. Die Kindartikel als Konfigurationsartikel definieren. In der Konfiguration wählt man dann das Motiv und ggfs. weitere Veredelungsdinge.
 

marsblau

Aktives Mitglied
7. September 2019
71
7
Der Konfigurationsartikel löst leider nicht das Bestandsproblem wie oben angesprochen ("Der Vorteil der Stückliste ...").
Das Motiv als Komponente könnte man weglassen, da dieses auch aus der Stückliste selbst hervorgeht. Bei dieser Komponente war die Bestandsführung ausgeschaltet.

Ich hatte noch einen Denkfehler bezüglich der aufkommenden Last ganz am Anfang des Beitrags ... ich habe 60000 Stücklisten, diese sind jedoch ca. 200-250 verschiedenen Komponenten zugeordnet (das Roh-T-Shirt in verschiendenen Farben und Größen) ... entsprechend war eine Komponente in ca. 300 Stücklisten, was ich ggf. noch bis ca. 1000 gern hochtreiben würde.

Bei der Berechnung der ca. 300 Bestandsänderungen ... ist das System (i7 Prozessor 16GB RAM SSD) eingeknickt, wobei die CPU-Last bei ca. 20% lag (durch SQL Server), jedoch die Wawi für den angesprochenen Zeitraum nicht anklickbar war. Seit 26 Stunden löscht die Ameise nun die Stücklisten und hat gerade mal 2/3 von 66000 geschafft ... das System war allerdings bereits nach ein paar tausend gelöschten Stücklisten wieder benutzbar. Als würde es mit 250 Bestandsänderungen innerhalb von 1-2 Sekunden fertig, bei 300 jedoch erst nach 5 Minuten. Ich hatte wie gesagt vorher bereits ca. 50000 im System und keine Probleme ... als ich dann vor einigen Tagen noch ca. 10000 dazuwarf, fingen die Performanceprobleme sehr heftig an.