Neu Worker 2.0 - automatische Picklistenerstellung - bitte nur während der Bürozeiten

[DITH-Shop]

Moin,

Mir würde es sehr helfen wenn man dem Worker 2 beibringen könnte, das er nur während der Bürozeiten automatisch Picklisten erstellt.
Wenn ich Morgens ins Büro komme, wurden da über Nacht manches Mal >10 Picklisten für jeweils 1-2 Aufträge erstellt.
Das nervt gewaltig. Um einigermaßen zu arbeiten lösche ich die dann gebündelt um sie sofort neu zu erstellen.

Optimal wäre es wenn man irgendwo eine Bürozeit hinterlegen könnte.
Außerhalb dieser Zeiten werden (einstellbar) manche Worker-Funktionen nicht durchgeführt.
Hier wäre "Picklisten Erstellung" ein guter Kandidat. Aber auch ggf "Zahlungsabgleich" (Banken buchen auch heute noch nur zwischen 8 und 16Uhr) oder "PDF Erzeugung"

 

[forumjtlolshopag]

Ich weiß nicht was die JTL Wawi API zulässt, aber du kannst ja über die Wawi im Worker Statusübersicht den "Sub"-Prozess deaktivieren. D.h. wenn der zum Feierabend abgeschalten und erst früh eingeschalten wird, sollte es ja passen.
Über JTLDiag könnte euer Techniker die passende Datenbankabfrage auslesen, dann könntet ihr das über einen Aufgabenplaner automatisiert an/abschalten.

 

[mvh]

Moin,

Mir würde es sehr helfen wenn man dem Worker 2 beibringen könnte, das er nur während der Bürozeiten automatisch Picklisten erstellt.
Wenn ich Morgens ins Büro komme, wurden da über Nacht manches Mal >10 Picklisten für jeweils 1-2 Aufträge erstellt.
Das nervt gewaltig. Um einigermaßen zu arbeiten lösche ich die dann gebündelt um sie sofort neu zu erstellen.

Optimal wäre es wenn man irgendwo eine Bürozeit hinterlegen könnte.
Außerhalb dieser Zeiten werden (einstellbar) manche Worker-Funktionen nicht durchgeführt.
Hier wäre "Picklisten Erstellung" ein guter Kandidat. Aber auch ggf "Zahlungsabgleich" (Banken buchen auch heute noch nur zwischen 8 und 16Uhr) oder "PDF Erzeugung"

Moin. Erstelle eine Erweiterte Eigenschaft, die dir True für Burozeiten und False sonst zurückgibt und prüfe diese in deinen Workflow-Bedingungen.

 

[frankell]

Moin. Erstelle eine Erweiterte Eigenschaft, die dir True für Burozeiten und False sonst zurückgibt und prüfe diese in deinen Workflow-Bedingungen.

Nach der Problembeschreibung geht es um den Abgleich " WMS-Picklisten" des Workers und nicht um einen Workflow mit "Ausliefern"-Aktion.

Ich weiß nicht was die JTL Wawi API zulässt, aber du kannst ja über die Wawi im Worker Statusübersicht den "Sub"-Prozess deaktivieren. D.h. wenn der zum Feierabend abgeschalten und erst früh eingeschalten wird, sollte es ja passen.
Über JTLDiag könnte euer Techniker die passende Datenbankabfrage auslesen, dann könntet ihr das über einen Aufgabenplaner automatisiert an/abschalten.

Wenn es Techniker gibt, benötigen die wohl nicht JTLDiag. Und die API ist auch nicht notwendig. Aber ansonsten stimme ich Dir zu. Ein simpler SQL-Befehl jeweils zum Anschalten und Ausschalten, bspw. in einem kleinen Skript, getriggert über die Windows-Aufgabenplanung, sollte ausreichen.

 

[forumjtlolshopag]

Über Diag siehst du bei der Debugausgabe die SQL Abfragen, die die Warenwirtschaft macht. Du musst Diag nur öffnen, dort die Debugausgabe einfügen, oben erstmal auf Stop gehen, in der Wawi an die Stelle gehen wo man die Worker Prozesse deaktivieren / aktivieren kann, im Diag auf Start drücken, Worker Prozess einmal deaktivieren / aktivieren, in Diag auf Stop klicken und dann kannst du dir in Ruhe in der Debugausgabe die SQL-Abfrage entnehmen.

 

[DITH-Shop]

Moin. Erstelle eine Erweiterte Eigenschaft, die dir True für Burozeiten und False sonst zurückgibt und prüfe diese in deinen Workflow-Bedingungen.

Die Workflows haben nichts mit dem Ablauf des Workers zu tun ?! Oder kann man inzwischen den Worker mit Workflows steuern?

 

[DITH-Shop]

Ein simpler SQL-Befehl jeweils zum Anschalten und Ausschalten, bspw. in einem kleinen Skript, getriggert über die Windows-Aufgabenplanung, sollte ausreichen.

Japp - ist zwar unschön immer alles "hintenherum zu machen" - aber es hat funktioniert.
Lösung läuft über worker.tStatus und SQL Server Agent.

 

[mvh]

Die Workflows haben nichts mit dem Ablauf des Workers zu tun ?! Oder kann man inzwischen den Worker mit Workflows steuern?

Die Workflows beim Auftrag-Erstellen Event können für den Auftrag je nach Zeit über die Aktion "Lieferoptionen setzen" die WMS-Sperre setzen.
Und Nein - der Worker wird nicht direkt über Workflows gesteuert.

 

[DITH-Shop]

Die Workflows beim Auftrag-Erstellen Event können für den Auftrag je nach Zeit über die Aktion "Lieferoptionen setzen" die WMS-Sperre setzen.
Und Nein - der Worker wird nicht direkt über Workflows gesteuert.

Ich will den Auftrag aber doch nicht sperren - zumal ich dann später die Sperre wieder aufheben müsste, das ist ebenfalls nicht erwünscht.

Die Lösung geht (aktuell) aber sehr einfach, und bisher zuverlässig, über zwei SQLs die per SQL Server-Agent ausgeführt werden.
Von Montag bis Freitag wird Morgens um 8Uhr wird die WMS-Pickliste im Worker aktiviert und Abends um 17Uhr wieder deaktiviert.

Sollte ich außerhalb dieser Zeiten Langeweile haben, erstelle ich eine Pickliste von Hand im WMS

 

[mvh]

Ich will den Auftrag aber doch nicht sperren - zumal ich dann später die Sperre wieder aufheben müsste, das ist ebenfalls nicht erwünscht.

Die Lösung geht (aktuell) aber sehr einfach, und bisher zuverlässig, über zwei SQLs die per SQL Server-Agent ausgeführt werden.
Von Montag bis Freitag wird Morgens um 8Uhr wird die WMS-Pickliste im Worker aktiviert und Abends um 17Uhr wieder deaktiviert.

Sollte ich außerhalb dieser Zeiten Langeweile haben, erstelle ich eine Pickliste von Hand im WMS

Ja, Das machen wir auch sehr oft, über den SQL Server-Agent die Abfragen/PowerShell-Skripte auszuführen.
Zur Info: das sind Werte in der Worker.tStatus Tabelle:
nAbgleichstyp = gibt den Abgleichstypen an: 0= Shop, 1=Amazon, 2=Ebay, 3=Waehrungskurse, 4=Zahlungsabgleich, 5=Workflows, 6=PosServer, 7=XmlImporter, 8=JTLTrackAndTrace, 9=BiAbgleich, 10=JtlFfn, 11=Scx, 12= Connector, 13=Nutzungsdaten, 14=Repricer, 15=WmsPicklistenErstellen, 16=ProductionStockCalculation, 17=PdfErzeugung, 19=WmsAutostoreCleanup.
kZiel = Für die Abgleichstypen Shop, SCX und Connector=dbo.tShop.kShop, für Repricer=dbo.pf_user.kUser und sonst -1.
nStatus = Gibt den aktuellen Status an: 0=Beendet, wird aber beim nächsten Start automatisch ausgeführt, 1=Wird gestartet, 2=Wird ausgeführt, 3=Erfolgreich ausgeführt, 4=Mit Fehlern ausgeführt, 5=Wird gestoppt, 6=Gesperrt, 7=Deaktiviert.

 

[DITH-Shop]

Ja, Das machen wir auch sehr oft, über den SQL Server-Agent die Abfragen/PowerShell-Skripte auszuführen.
Zur Info: das sind Werte in der Worker.tStatus Tabelle:
nAbgleichstyp = gibt den Abgleichstypen an: 0= Shop, 1=Amazon, 2=Ebay, 3=Waehrungskurse, 4=Zahlungsabgleich, 5=Workflows, 6=PosServer, 7=XmlImporter, 8=JTLTrackAndTrace, 9=BiAbgleich, 10=JtlFfn, 11=Scx, 12= Connector, 13=Nutzungsdaten, 14=Repricer, 15=WmsPicklistenErstellen, 16=ProductionStockCalculation, 17=PdfErzeugung, 19=WmsAutostoreCleanup.
kZiel = Für die Abgleichstypen Shop, SCX und Connector=dbo.tShop.kShop, für Repricer=dbo.pf_user.kUser und sonst -1.
nStatus = Gibt den aktuellen Status an: 0=Beendet, wird aber beim nächsten Start automatisch ausgeführt, 1=Wird gestartet, 2=Wird ausgeführt, 3=Erfolgreich ausgeführt, 4=Mit Fehlern ausgeführt, 5=Wird gestoppt, 6=Gesperrt, 7=Deaktiviert.

Wichtig ist eigentlich (für meinen speziellen Fall)

nRequestStatus
0 für Start Anfordern
1 für Deaktivierung anfordern

 

[mvh]

Wichtig ist eigentlich (für meinen speziellen Fall)

nRequestStatus
0 für Start Anfordern
1 für Deaktivierung anfordern

nRequestStatus ist ein Feld in der tSetup-Tabelle. Das wird benutzt, wenn der neue Status angefordert wird - kann aber auch unter Umständen vom Worker "abgelehnt" werden, dann bleibt er auf 0.
Ich beschreibe tStatus-Tabelle, wenn der Status quasi "gesetzt" wurde.

 

[DITH-Shop]

nRequestStatus ist ein Feld in der tSetup-Tabelle. Das wird benutzt, wenn der neue Status angefordert wird - kann aber auch unter Umständen vom Worker "abgelehnt" werden, dann bleibt er auf 0.
Ich beschreibe tStatus-Tabelle, wenn der Status quasi "gesetzt" wurde.

DAS allein hat bei mir nicht funktioniert. Wurde dann vom Worker immer überschrieben und trotzdem gestartet.

nRequestStatus versenden wird vom Worker selbst abgearbeitet und dann der neue Status zurückgegeben.
Läuft bei mir seit ein paar Tagen - einwandfrei.

DECLARE @nRequestStatus_0 int = 0; --1 = Deaktivierung angefordert / 0 = start angefordert
DECLARE @kMandant_0 int = 1;
DECLARE @nAbgleichstyp_0 tinyint = 15;
DECLARE @kZiel_0 int = -1;
UPDATE [eazybusiness].[Worker].[tSetup]
SET nRequestStatus = @nRequestStatus_0
WHERE kMandant = @kMandant_0 AND
nAbgleichstyp = @nAbgleichstyp_0 AND
kZiel = @kZiel_0;

 

[Jamara]

Danke für die mir neuen Ideen.
Ich habe zeitgesteuerte Workflows bisher immer auf zwei Arten gemacht:

Möglichkeit 1 - Zeitversetzte Workflows nutzen
Durch das verzögern werden die Workflows auch grundsätzlich nur vom gleichem Worker ausgeführt, bei mehreren Nutzern unerlässlich.

Angenommen man möchte nur an Wochentagen Workflows ausführen:
Für jeden Tag einen Workflow erstellen:
Diese zeitversetzt laufen lassen: Bedingung: wenn Wochentag Sonntag dann führe Zeitversetzt aus, Montag ab 8 Uhr.
Für Nur Werktagszeiten: Wenn Montag 18:00 dann führe aus Dienstag Früh um 8 Uhr zum Beispiel.

Möglichkeit 2 - eigene Felder Wiederholung
Angenommen man möchte einen Workflow zu einem bestimmten Datum aus einem eigenen Feld ausführen:
Die Bedingung ob das Datum dem aktuellen Datum entspricht muss jeden Tag geprüft werden.
Man kann hier einen Workflow ausführen der einen manuellen Workflow ausführt der wiederum einen anderen manuellen Workflow ausführt.

Workflow 1 startet den ersten manuellen Workflow 2
Dieser prüft dann mithilfe einer erweiterten Eigenschaft ob das Datum erreicht ist, wenn ja führt er Workflow 3 aus, der die gewünschte Aktion ausführt, wenn nicht, ruft er sich selbst zeitverzögert um einen Tag aus, um die Bedingung morgen erneut zu prüfen.
Bzw. braucht man dann noch ein verstecktes Feld "Workflow ausgeführt", damit die Endlosschleife durchbrochen wird, wenn die Bedingung zutrifft

Allgemein wären Zeittechnisch programmierbare Workflows für die man auch eigene Felder nutzen kann, sehr wünschenswert, oder zumindest Wochentagbedingung.

Hoffe die Grundideen sind rübergekommen, bei Interesse gerne Nachfragen.

Beste Grüße
Philipp

 

[mvh]

DAS allein hat bei mir nicht funktioniert. Wurde dann vom Worker immer überschrieben und trotzdem gestartet.

nRequestStatus versenden wird vom Worker selbst abgearbeitet und dann der neue Status zurückgegeben.
Läuft bei mir seit ein paar Tagen - einwandfrei.

DECLARE @nRequestStatus_0 int = 0; --1 = Deaktivierung angefordert / 0 = start angefordert
DECLARE @kMandant_0 int = 1;
DECLARE @nAbgleichstyp_0 tinyint = 15;
DECLARE @kZiel_0 int = -1;
UPDATE [eazybusiness].[Worker].[tSetup]
SET nRequestStatus = @nRequestStatus_0
WHERE kMandant = @kMandant_0 AND
nAbgleichstyp = @nAbgleichstyp_0 AND
kZiel = @kZiel_0;

Moin. Nur Zur Ergänzung. RequestStatus akzeptiert folgende Werte:
NULL = keine Anforderung, 0 = Start, 1 = Stop (Deaktivierung), 2 = Neustart