Neu Arbeiten mit Lieferanten EKs - Workflows und SQL

[Kugelschubser]

Moin JTL-Gemeinde,

ich habe leider zu folgendem Thema nur ältere Posts ohne wirkliche Lösung gefunden. Vielleicht kann mir hier wer weiterhelfen.
Generell bin ich in Software-Entwicklung nicht ganz unbewandert, ich hocke im 6 Semester Software-Engineering und schreibe mir aktuell selber auch einen Python-Webcrawler, der Lieferantendaten für mich ausliest sofern ich von den Lieferanten keine CSV oder XML erhalte.
Nur ist es auch so, dass mein SQL-Modul damit schon zwei Jahre her ist und ich dort eher auf Prüfungsbestehen als auf wirkliches Verständnis gelernt habe. Ich weiß also generell was SQL macht und kenne grob den Syntax, das war es dann aber auch schon. Mit Microsoft SQL-Datenbanken habe ich aber noch nie gearbeitet, nur mit MariaDB / mySQL.
Mit JTL-Workflows habe ich mich außerdem nur bedingt und mit DotLiquid an der Stelle noch gar nicht auseinandergesetzt, benötige dort also definitiv Hinweise.
Auch bin ich mir sicher, dass man das ganze auch nicht unbedingt per Workflow lösen sollte, weil dies pro Artikel einfach eine längere Bearbeitungszeit bedeutet und das bei aktuell 10.000 und angedacht 100.000+ Artikeln einfach zu lange dauern würde. Die beste Lösung wäre also meiner Meinung nach, per Workflow bei Ameisen-Import ein externes SQL-Skript anzustoßen, was die Bearbeitung deutlich schneller erledigt.
Alternativ würde es reichen, wenn

Ausgangssituation:

Geschäftsmodell ist eine Mixtur aus normalem Lagerversand und Dropshipping.

Für Artikel sind häufig mehrere Lieferanten eingepflegt, welche unterschiedliche Preise und Bestände haben.

Wir gehen als Beispiel einfach mal von folgenden Daten aus:

Lieferant A - 5 Stk. - 15.00
Lieferant B - 20 Stk. - 10.00
Lieferant C - 100 Stk. - 25.00

Was ich gerne hätte, wäre eine automatische Änderung des Standardlieferanten, wenn kein Lagerbestand mehr vorhanden ist auf den günstigsten Lieferanten mit Bestand.
Heißt anhand des Beispieles wäre es Lieferant B. Hat dieser keinen Bestand mehr, soll auf A ausgewichen werden, danach auf C. Wenn kein Lieferant den Artikel hat, soll der günstigste als Standard gesetzt werden bis irgendwo wieder Bestand vorhanden ist.

Hier habe ich bis auf die Grundlogik dahinter noch keine Idee, wie ich das angehen könnte.

Der zweite Schritt wäre dann, einmal stündlich die Preise aller Artikel auf Basis des Standardlieferanten anzupassen.
Es gibt zwar die Funktion für Preiskalkulation in der Wawi, aber diese kann nichtg auf XX.90€-Werte runden.

Hier wäre also die Grundidee, die Preise des Standardlieferanten per SQL zu exportieren, in einem Python-Script zu berechnen, und dann per SQL den Brutto-VK wieder in die Datenbank zu jagen. Das ganze dann halt einmal Stündlich als Service.

Die Grundfunktion als Pseudocode ist ja schnell geschrieben (ohne jetzt die DB-Struktur von JTL zu kennen)

for x in artikel:
ekNetto = SELECT ek_stdLieferant FROM artikel WHERE id = 'x';
vkNetto = ekNetto * 1.25
vkBrutto = math.ceil(vkNetto) - 0.10
UPDATE artikel SET vk_brutto = vkBrutto WHERE id = 'x';

Jetzt die Frage: Habe ich hier einen Denkfehler, oder ist die Lösung wirklich so einfach (natürlich dann mit mit richtigem Syntax und ordentlich in Python)?
Und wie würde ich am besten das Problem mit dem setzen des Standard-Lieferanten bei Import durch die Ameise angehen. Da komme ich noch nicht ganz auf die Lösung.

 

[Morimus]

Ich würde die Entscheidungslogik nicht direkt in der JTL-Datenbank ausführen.
Lesen per SQL für Auswertungen ist okay, aber schreibende Updates auf JTL-Tabellen würde ich vermeiden.
JTL selbst rät von direkten Datenbankeingriffen ab, unter anderem wegen Supportverlust und interner Trigger/Procedures.

Sinnvoller wäre imho:
Python sammelt und bewertet die Lieferantendaten, erzeugt daraus eine CSV mit dem gewünschten Ergebnis, und diese wird dann über die Ameise oder eine passende API zurück in JTL gespielt.
Die Ameise interpretiert zwar nicht selbst, aber sie kann die bereits berechneten Werte setzen.

 

[Kugelschubser]

Ich würde die Entscheidungslogik nicht direkt in der JTL-Datenbank ausführen.
Lesen per SQL für Auswertungen ist okay, aber schreibende Updates auf JTL-Tabellen würde ich vermeiden.
JTL selbst rät von direkten Datenbankeingriffen ab, unter anderem wegen Supportverlust und interner Trigger/Procedures.

Sinnvoller wäre imho:
Python sammelt und bewertet die Lieferantendaten, erzeugt daraus eine CSV mit dem gewünschten Ergebnis, und diese wird dann über die Ameise oder eine passende API zurück in JTL gespielt.
Die Ameise interpretiert zwar nicht selbst, aber sie kann die bereits berechneten Werte setzen.

Erstmal danke für den Input. Soll also heißen, ich würde dann eine CSV mit Produkt-Identifier (z.B. Artikelnummer) und errechnetem Standardlieferanten ausgeben lassen und diese dann per Ameise einspielen.
Das selbe dann mit etwas Zeitversatz auch für die Preisberechnung.

Die Ameise ist ja deutlich langsamer, für das Update von 18000 Artikel von einem Lieferanten braucht sie aktuell etwa 30 Minuten.
Aber gut, dann macht man das halt einmal am Tag. So häufig ändern sich die Lieferantenpreise ja glücklicherweise nicht.

 

[Morimus]

Ja, genau so würde ich es aufbauen.

Das Script sollte am Ende eine saubere CSV ausgeben, z. B. mit Artikelnummer und dem berechneten Standardlieferanten.

Bei der Preisberechnung würde ich genauso vorgehen.
Das Script berechnet anhand des relevanten EKs den gewünschten VK und gibt wieder eine Importdatei für die Ameise aus.

Wichtig wäre aus meiner Sicht aber, nicht jedes Mal alle 18.000 Artikel neu zu importieren, sondern möglichst nur die Artikel, bei denen sich tatsächlich etwas geändert hat.
Also vorher den aktuellen Zustand mit dem neu berechneten Zustand vergleichen und nur ein Delta importieren.

Das sollte mit Python gut machbar sein.

 

[Kugelschubser]

Ja, genau so würde ich es aufbauen.

Das Script sollte am Ende eine saubere CSV ausgeben, z. B. mit Artikelnummer und dem berechneten Standardlieferanten.

Bei der Preisberechnung würde ich genauso vorgehen.
Das Script berechnet anhand des relevanten EKs den gewünschten VK und gibt wieder eine Importdatei für die Ameise aus.

Wichtig wäre aus meiner Sicht aber, nicht jedes Mal alle 18.000 Artikel neu zu importieren, sondern möglichst nur die Artikel, bei denen sich tatsächlich etwas geändert hat.
Also vorher den aktuellen Zustand mit dem neu berechneten Zustand vergleichen und nur ein Delta importieren.

Das sollte mit Python gut machbar sein.

Gut, dann muss ich da nachher mal die Logik planen, insbesondere mit dem Check für die Änderung. Eventuell könnte man da ja mit den Logs aus dem Ameisen-Import arbeiten - dort habe ich die Einstellung ja gesetzt, dass nur Artikel mit Änderung zum letzten Stand der CSV neu geändert werden.
Aber nochmals vielen Dank, das gibt mir schon mal ein paar gute Ansätze, die ich ausprobieren kann.

 

[Morimus]

Gerne.

Mit den Ameisen-Logs kann man sicher arbeiten, um nachträglich zu prüfen, was importiert wurde.

Ich würde den Änderungscheck aber möglichst schon vor dem Ameisen-Import im Script machen.
Dann erzeugt das Script direkt nur noch die Artikel, bei denen sich wirklich etwas geändert hat.

Also z. B. vorher den zuletzt berechneten Stand speichern und beim nächsten Lauf vergleichen.

Artikelnummer, bisher berechneter Standardlieferant, neu berechneter Standardlieferant, bisheriger EK, neuer EK, bisheriger VK, neuer VK.

Wenn alles gleich geblieben ist, kommt der Artikel gar nicht erst in die Importdatei.
Die Ameise kann dann zusätzlich immer noch als zweite Sicherheit prüfen, ob sich wirklich etwas ändert.
Aber ich würde mich nicht ausschließlich auf den Ameisen- Log verlassen, weil du dann trotzdem jedes Mal eine große Datei durch die Ameise jagst.

So bleibt der Import kleiner, schneller und besser nachvollziehbar.