Neu Datenbankabfrage

[mike.com1]

Ich möchte regelmäßig einen Workflow laufen lassen, der das Alter (das Einbuchungsdatum) eines Artikels prüft und anhand des Prüfungsergebnisses Aktionen ausführt.

Also: Alle Artikel, welche länger als 3 Monate unbewegt im Lager gammeln, beschreibe eigenes Feld mit "Rabatt". Mit dem Feld kann ich dann im Shop entsprechend den Rabatt steuern.
Ist das ohne große Eingriffe möglich? Ich habe jetzt bei den Datenfeldern nur Felder gefunden, mit letzter Bearbeitung. Da wir aber Lieferantenbestand dazubuchen und regelmäßig aktualisieren, ist das Nutzlos.

Ich brauche das Datum der Einbuchung des Artikel in der WMS. Wenn das nicht Nativ geht, über ein eigenes Feld anlegen? Aber das ist auch wieder doof, wenn ich von dem Artikel mehrere habe

 

[no80]

Über ein WF ist suboptimal, da du inmer alle Artikel triggern muss.
Besser wäre ein kleines Script, welche per SQL abfragt und die entsprechenden Artikel etc exportiert.
Diese dann per Ameise importiert.

 

[frankell]

Ich möchte regelmäßig einen Workflow laufen lassen, der das Alter (das Einbuchungsdatum) eines Artikels prüft und anhand des Prüfungsergebnisses Aktionen ausführt.

Also: Alle Artikel, welche länger als 3 Monate unbewegt im Lager gammeln, beschreibe eigenes Feld mit "Rabatt". Mit dem Feld kann ich dann im Shop entsprechend den Rabatt steuern.
Ist das ohne große Eingriffe möglich? Ich habe jetzt bei den Datenfeldern nur Felder gefunden, mit letzter Bearbeitung. Da wir aber Lieferantenbestand dazubuchen und regelmäßig aktualisieren, ist das Nutzlos.

Ich brauche das Datum der Einbuchung des Artikel in der WMS. Wenn das nicht Nativ geht, über ein eigenes Feld anlegen? Aber das ist auch wieder doof, wenn ich von dem Artikel mehrere habe

Das Datum der Einbuchung allein sagt nichts aus, da braucht es dann ja noch eine Aussage, ob er im Lager gegammelt hat. Das dürfte dann ja die Anzahl der Verkäufe des Artikels im Betrachtungszeitraum sein. Aber vielleicht hast Du es auch nur verkürzt dargestellt.

Du kannst natürlich einen zeitversetzten Workflow für Einbuchungen anlegen, der für jede Einbuchung nach Ablauf von drei Monaten prüft, ob der eingebuchte Artikel verkauft wurde. Je nach Artikelmenge kann da natürlich einiges in der Worker-Queue zusammenkommen. Aber vom Prinzip her machbar. Wäre halt nur so, dass bei einem weiteren Wareneingang desselben Artikels ein weiterer Workflow drei Monate später angestoßen wird. Muss nicht schlimm sein, muss man nur mitbedenken und sich überlegen, ob das schlimm sein könnte.

Ansonsten kannst Du auch täglich (bspw. nachts) ein Skript laufen lassen, das die Aufgabe erledigt. Das schaut sich dann alle Artikel an und prüft für jeden Artikel, ob zwischen letzter Einbuchung und letztem Verkauf drei Monate vergangen sind und beschreibt dann entsprechend das Eigene Feld. Dafür sind halt hinreichende Kenntnisse der Datenbank und von SQL notwendig. Kleiner Hinweis: Eigene Felder sind datenbanktechnisch gesehen Attribute und daher auch in den entsprechenden Tabellen zu finden.

 

[P0ttwal]

Über ein WF ist suboptimal, da du inmer alle Artikel triggern muss.
Besser wäre ein kleines Script, welche per SQL abfragt und die entsprechenden Artikel etc exportiert.
Diese dann per Ameise importiert.

ja, genau so.

Also ich würde das über die Lagerumschlagshäufigkeit berechnen.
Vielleicht mit einem SQL Script einmal täglich die Artikel mit der Kennzahl exportieren und in einer extra Spalte ausgibt. Das kannst du dir dann schicken lassen oder legst es ab. Wenn du willst, kann man das dann gleich als eigenes Feld wieder importieren. Dann siehst du das im Artikel auch.

Was ich auch empfehlen kann eine eigene Übersicht in der Artikelverwaltung, dass dir die Verkäufe der letzten 90 Tage, 180 Tage und 365 Tage ausgibt. Das gab es mal hier im Forum.

 

[mh1]

Was ich auch empfehlen kann eine eigene Übersicht in der Artikelverwaltung, dass dir die Verkäufe der letzten 90 Tage, 180 Tage und 365 Tage ausgibt. Das gab es mal hier im Forum.

Für die 1.5:
https://forum.jtl-software.de/threads/verkaeufe-im-artikel-anzeigen.143423/

 

[mike.com1]

Also wenn ich ihn eingebucht habe und nicht verkauft worden ist, hat er definitiv im Lager gegammelt. Zum Verständnis, wir haben 1400 Väter. Das gibt in etwas 25000 Kinder. Es ist unwahrscheinlich, dass wir pro Kind mehr als einen da haben.

Den Rest von Euch habe ich nicht vollumfänglich verstanden. Ich will halt nur eine vollautomatische Lösung, welche mir ein eigenes Feld beschreibt, je nach Artikelalter. Optimal wäre halt: Lageralter 1 nach X tagen, Lageralter 2 nach xx Tagen, Eskalation nach xxx Tagen. Man kann ja quasi noch die Abfrage einbauen, ob er in der Zeit mal gedreht worden ist, wenn es mehr als einen Artikel davon gibt. Das wäre dann aber schon Champions League

Wie das dann umgesetzt wird, ist mir letztendlich herzlich egal. Wenn es nicht per Workflow geht, muss man auf jeden Fall noch filtern können nach Artikelnummerbeginn und Warenlagerplätzen.

 

[frankell]

Ist alles möglich. Entweder über automatische Ameisenex- und importe oder gleich vollständig über ein einziges SQL-Skript.

Was von den Lösungsmöglichkeiten am sinnigsten ist, hängt davon ab, was genau unter welchen genauen Bedingungen passieren soll.

Beispiel: Folgende unterschiedliche Ansätze führen zu anderen Umsetzungen:

Alle Artikel, welche länger als 3 Monate unbewegt im Lager gammeln, beschreibe eigenes Feld mit "Rabatt".

Lageralter 1 nach X tagen, Lageralter 2 nach xx Tagen, Eskalation nach xxx Tagen.

Unter Verwendung der Ameise bedeutet das: Will man den ersten (einfachen) Ansatz allein mit der Ameise erledigen, ist das ein mindestens ein Export mit einer Standardvorlage und ein Import. Der zweite (komplexere) Ansatz erfordert schon mindestens drei Ameisen-Exporte (mit einer Standardvorlage) und drei Importe.
Man bekommt das auf einen Export und einen Import beschränkt, aber nur unter Verwendung eines "Eigenen Exports" über die Ameise, also unter Verwendung einer SQL-Abfrage.

Noch komplexer kann es werden, wenn das Lageralter ein eigenständiges eigenes Feld sein soll, also unabhängig vom Eigenen Feld Rabatt. Und auch die Berücksichtigung dessen macht es komplexer:

Man kann ja quasi noch die Abfrage einbauen, ob er in der Zeit mal gedreht worden ist, wenn es mehr als einen Artikel davon gibt.

Noch mal: Alles möglich, auch die Champions League. Aber hochindividuell und deshalb auch kaum pauschal zu beantworten, zumindest solange nicht, wie man nicht alle Wünsche exakt definiert hat.

Auch wenn es wie gesagt mit der Ameise möglich ist, würde ich hier grundsätzlich zu einem SQL-Skript abseits der Ameise tendieren, das einmal täglich (bspw. nachts) die gewünschten Aufgaben erledigt. Hier kann - im Gegensatz zur Ameise - alles in einem Rutsch erledigt werden, auch anhand komplexer Bedingungen und (Datenbank)-Aktionen.