Neu Workflow - Export Lagerbestand

[kobalz]

Servus zusammen,

wir benötigen einen Workflow, der uns den Lagerbestand (also "Artikelnummer" und "verfügbarer Bestand") nach einer Änderung am Bestand irgendeines Artikels in eine CSV Datei exportiert. (Am besten wäre gleich auf unseren eigenen FTP-Server).

Leider habe ich nichts passendes bei den Workflows gefunden. Hat irgend einer eine Idee, wir wir dies abbilden können?

Danke für die Hilfe imm Voraus.

Grüße
Steffen

 

[Sawyer]

Guten Abend,

Mir ist kein Workflow bekannt der das abbildet.

Die Ausgabe bei Bestandsänderung klingt für mich auch sehr häufig. Wir realisieren dies stündlich mit der Ameise per Batch und Aufgabenplaung.

Bei bedarf beschreibe ich das gerne bei zeiten näher.

 

[svenyo]

Steht das Angebot mit der Schritt für Schritt Anleitung noch?

 

[gutberle]

Hallo Steffen,

den Lagerbestand für einen Artikel kriegst Du ja leicht über die Werte bei "Vorgang > Artikel > Bestandsübersicht" raus, und den Wert dann in eine CSV Datei zu schreiben ist eher trivial, aber ich lese oben raus, dass Du dann, wenn irgendein Artikel seinen Bestand geändert hat, eine Datei mit den Beständen aller Artikel bekommen möchtest, ist das richtig?

Dazu braucht es dann schon eine SQL Abfrage und die wäre, wenn man hier auf sich allein gestellt wäre, eher ein "SQL Programm", weil das Zusammentragen der Bestandsinformationen aus der Wawi Datenbank untrivial ist.

Netterweise hat JTL das aber schon für uns erledigt und einen SQL View geschrieben, der genau das macht. Alles, was man also machen muss, ist die Werte aus dem View einzusammeln, für CSV zu formatieren und rauszuschreiben. Hier ist die SQL Abfrage dafür, schon in Workflow geeigneter Form ...

{% capture query -%}
SELECT kArtikel, fLagerbestand, fVerfuegbar, fReserviert, fVerfuegbarGesperrt, fZulauf, fZulaufVerfuegbar, fAufEinkaufsliste, fEigenerBestand, fVerfuegbarExtern, fInAuftraegen FROM vLagerbestandEx
{% endcapture -%}
{% assign ArtikelBestand = query | DirectQuery -%}
ArtNr;IntArtNr;LagerBestand;Verfuegbar;Reserviert;VerfuegbarGesperrt;Zulauf;ZulaufVerfuegbar;AufEinkaufsliste;EigenerBestand;VerfuegbarExtern;InAuftraegen
{% for item in ArtikelBestand.Daten -%}
{% capture query2 -%}SELECT cArtNr FROM tArtikel WHERE tArtikel.kArtikel={{ item.kArtikel }}{% endcapture -%}{% assign ArtNr = query2 | DirectQueryScalar %}{{ ArtNr }};{{ item.kArtikel }};{{ item.fLagerbestand | FormatNumber: 'N0', 'de-DE' }};{{ item.fVerfuegbar | FormatNumber: 'N0', 'de-DE' }};{{ item.fReserviert | FormatNumber: 'N0', 'de-DE' }};{{ item.fVerfuegbarGesperrt | FormatNumber: 'N0', 'de-DE' }};{{ item.fZulauf | FormatNumber: 'N0', 'de-DE' }};{{ item.fZulaufVerfuegbar | FormatNumber: 'N0', 'de-DE' }};{{ item.fAufEinkaufsliste | FormatNumber: 'N0', 'de-DE' }};{{ item.fEigenerBestand | FormatNumber: 'N0', 'de-DE' }};{{ item.fVerfuegbarExtern | FormatNumber: 'N0', 'de-DE' }};{{ item.fInAuftraegen | FormatNumber: 'N0', 'de-DE' }}
{% endfor -%}

Hier werden nicht nur Deine Zielvariablen "Artikelnummer" und "Verfügbarer Bestand" geholt, sondern gleich der ganze Schwung an Bestandsdaten, aber Weglassen ist ja immer leichter als Hinzufügen ...

Der dazu passende Workflow wäre dann entweder einer (1) im Bereich "Artikel - Manuell" oder aber jeweils einer (ergo 2) in den Bereichen "Warenlagereingang > Plusbuchung" und "Warenlagerausgang > Minusbuchung" und der Workflow hätte jeweils KEINE Bedingung und als Aktion "Datei schreiben" und beim Inhalt natürlich die Abfrage von oben. Alle anderen Optionen sind nach Wunsch.

Und falls Du tatsächlich nur den Bestand des einen Artikels haben willst, der gerade geändert wurde, dann sähe die Abfrage etwas anders aus, nämlich so ...

{% capture query -%}
SELECT kArtikel, fLagerbestand, fVerfuegbar, fReserviert, fVerfuegbarGesperrt, fZulauf, fZulaufVerfuegbar, fAufEinkaufsliste, fEigenerBestand, fVerfuegbarExtern, fInAuftraegen FROM vLagerbestandEx
    WHERE kArtikel={{ Vorgang.Artikel.Allgemein.Stammdaten.InterneArtikelnummer }}
{% endcapture -%}
{% assign ArtikelBestand = query | DirectQuery -%}
ArtNr;IntArtNr;LagerBestand;Verfuegbar;Reserviert;VerfuegbarGesperrt;Zulauf;ZulaufVerfuegbar;AufEinkaufsliste;EigenerBestand;VerfuegbarExtern;InAuftraegen
{% for item in ArtikelBestand.Daten -%}
{{ Vorgang.Artikel.Allgemein.Stammdaten.ArtNrSku }};{{ item.kArtikel }};{{ item.fLagerbestand | FormatNumber: 'N0', 'de-DE' }};{{ item.fVerfuegbar | FormatNumber: 'N0', 'de-DE' }};{{ item.fReserviert | FormatNumber: 'N0', 'de-DE' }};{{ item.fVerfuegbarGesperrt | FormatNumber: 'N0', 'de-DE' }};{{ item.fZulauf | FormatNumber: 'N0', 'de-DE' }};{{ item.fZulaufVerfuegbar | FormatNumber: 'N0', 'de-DE' }};{{ item.fAufEinkaufsliste | FormatNumber: 'N0', 'de-DE' }};{{ item.fEigenerBestand | FormatNumber: 'N0', 'de-DE' }};{{ item.fVerfuegbarExtern | FormatNumber: 'N0', 'de-DE' }};{{ item.fInAuftraegen | FormatNumber: 'N0', 'de-DE' }}
{% endfor -%}

... und alles andere wäre ansonsten gleich.

ERNSTE WARNUNG:

Der obere, automatische Workflow über alle Artikel hat eine SQL Abfrage ohne WHERE Bedingung. Das ist hier zwar Sinn der Übung, eine Datenbank-Tabelle ohne Eingrenzung zu lesen/schreiben gilt aber als schlechter Stil und ist auch gefährlich, z.B. wenn Du nicht wie ich 537 Artikel hast, sondern 126234 Stück. - Wie "performant" das Ganze dann nämlich ist, ist echt fraglich und falls es wirklich Ziel sein sollte, das bei jeder Bestandsänderung irgendeines Artikels auszuführen, dann "gute Nacht Marie" ...

Ich würde deshalb dringend dafür plädieren, diese gefährliche(re) Workflow-Variante ausschließlich über einen manuellen Workflow auszulösen, also einen Artikel mit der Maus markieren, rechts unten unter Workflow diesen Workflow auswählen und schon hast Du den aktuellen Bestand aller Artikel auf der Platte.

Und falls ich Dich falsch verstanden habe und Du wolltest gar nichts anderes, dann mea culpa und um so besser ...

Gruß,
Ingmar

 

[svenyo]

@gutberle

Danke für die Rückmeldung. Die Bestandsänderung für den jeweiligen Artikel würde eigentlich vollkommen ausreichen. Jedesmal alle Artikel zu exportieren (auch die ohne Änderung) wäre tatsächlich unnötig, da hast du Recht.

Wenn ich es richtig verstanden habe, müsste ich also mit dem ZWEITEN Code die zwei Workflows anlegen ("Warenlagereingang > Plusbuchung" und "Warenlagerausgang > Minusbuchung") damit mir eine CSV-Datei erstellt wird?

Diese CSV-Datei könnte ich dann quasi mit einer Batch-Datei per Ameise im 2. Mandanten nach einem festgelegten Zeitintervall importieren lassen, richtig?
Jetzt müsste ich nur noch wissen, wie das mit der Batch-Datei & Ameise funktioniert?

Sorry bin völliger Newbie auf dem Gebiet.

 

[gutberle]

@svenyo

Ja, in dem Fall wäre es der zweite und "ungefährlichere" Workflow, den du in Plus-/Minusbuchung gleichlautend anlegen würdest. Es spricht aber auch überhaupt nichts dagegen, dass Du Dir den ersten und "gefährlichen" Workflow als manuellen Workflow anlegst, denn eine einfachere Möglichkeit, als einmal auf einen Artikel zu klicken und dann per Auswahl des Workflows aus der Liste auf einen Schlag, aber eben nur "ab und zu" mal den gesamten Lagerbestand auf die Platte zu "dumpen" gibt es nicht...

Wegen Ameise und Import per Batch schau mal hier ... https://guide.jtl-software.de/Daten_mit_JTL-Ameise_automatisch_via_FTP_importieren

 

[svenyo]

@gutberle

Ich wollte gerade die Workflows anlegen, aber als Aktion gibt es bei mir kein "Datei schreiben".
Zur Auswahl stehen nur:
- Amazon Lieferzeit/Bestand setzen
- Ausführen
- Ausgabe
- Email senden
- Werte setzen

Und nu?

 

[gutberle]

Das würde bedeuten, dass Du mit einer superalten Wawi arbeitest, denn die Option zum Schreiben von Dateien wurde meines Wissens noch vor der 1.1er Wawi eingeführt. Wenn ich Dein "Registriert seit" hernehme stehen die Chancen gut, dass Du mit der 1.0.9.1 arbeitest, denn die wurde am 4.2.2016 released, die nächste erst im März.

Falls Du wirklich mit einem solch alten Schinken arbeitest, solltest Du das gerade, wie Du selber sagst als "völliger Newbie" lieber noch einmal überdenken, denn Deine Version wäre dann 18 Monate alt und inzwischen ist viel Wasser den Rhein runtergeflossen ... - Noch dazu wird Dir dann auch niemand hier im Forum für Deine Probleme Hilfestellung geben können, denn das würde bedingen, dass man selbst auch Zugriff auf die alte Kröte hätte. Hat ~man~ aber in der Regel nicht.

 

[svenyo]

Bislang hat alles super funktioniert. Und wie heißt es so schön: Never change a running system.
Momentan arbeite ich noch mit 1.0.9.2, aber dann werde ich mal zuerst ein Update vornehmen.

 

[gutberle]

Oder Du wartest noch ein paar Wochen, bis die Wawi 1.3.x released ist, denn die soll keine oder nur minimale neue Features, dafür aber so viele Bugfixes und Stabilitätsverbesserungen wie nur möglich bringen.
Ich würde die Wawi 1.3.x damit als die korrekte Antwort auf Dein ja auch ganz richtiges "Never change a running system" ansehen. Beim Upgrade wird übrigens IMMER erst ein Backup der aktuellen Datenbank gezogen.
Sicherst Du dass, kannst Du sogar wieder zurück zur 1.0.9.2 sofern das notwendig werden würde. Was auch immer nach dem Upgrade an/in der Wawi gearbeitet wurde, wäre damit aber verloren, ist ja klar.

 

[svenyo]

@gutberle

WaWi-Update wäre geschafft. Beide Workflows habe ich angelegt, aber die Bestandsänderungen werden nur als CSV exportiert, wenn eine Minus-/Plusbuchung über Wareneingang erfolgt. Bei Erstellung eines Auftrags oder auch bei Auslieferung eines Auftrags passiert nichts.

Muss ich irgendetwas anderes einstellen, damit die CSV-Datei erzeugt wird, sobald 1 Stk. eines Artikels auch nur reserviert wird?

Bzw. eigentlich müsste es doch dann helfen, wenn ich noch einen Workflow für Auftrag erstellt anlege, oder? Auch wieder ohne Bedingung und als Aktion Datei anlegen mit obigem Inhalt

 

[gutberle]

@svenyo

So etwas wäre nur dann einfach zu lösen, wenn es einen Workflow-Trigger gäbe, der auf die Bestandsänderung eines Artikels reagiert und den gibt es ganz offensichtlich nicht.

Ich bezweifele auch, dass JTL einen Trigger implementieren würde, der allein schon bei der Erzeugung einer Reservierung reagiert. Denkbar wäre sicherlich ein Trigger für bestimmte Schwellenkriterien, also meinetwegen einen Workflow-Trigger, der reagiert, wenn der Artikel seinen Pufferbestand unterschreitet, unter 0 Stück geht, oder vielleicht auch einen, der auf Schwellen in die andere Richtung reagiert, also "wieder lieferbar" und so weiter.

Im Moment müsstest Du Dir dafür einen Workflow bauen, der auf extrem viele Einzel-Bedingungen reagiert, also z.B. auf Artikel "erstellt, geändert, gelöscht" ebenso reagiert, wie auf Auftrag "erstellt, geändert, gelöscht", auf Einkauf "Lieferantenbestellungsposition reduziert" und auch auf Versand "Lieferscheine erstellt, gelöscht, versendet" und im Zweifel habe ich sogar noch einige Bedingungen vergessen...

Und dann kommt auch noch dazu, dass praktisch alle diese Bedingungen Vorgänge zurückliefern, die gleich mehrere bis viele Artikel betreffen, Du also jedes Mal entweder für alle Artikel jeweils eine CSV oder zumindest jeweils eine CSV für alle Artikel bekämst. Ob das so zielführend und vor allem hilfreich ist, kann ich nicht sagen ...

Fazit: Das alles heißt natürlich nicht, dass das Ganze damit sinnlos geworden wäre, nur mit automatischen Workflows wirst Du hier in der Summe kein Glück haben. Was Du aber natürlich machen kannst, ist Dir gleich zwei manuelle Workflows anzulegen, einen, der einen CSV mit den Bestandsdaten des aktuell markierten Artikels schreibt und einen, der den aktuell markierten Artikel ignoriert und eine CSV Datei mit den Bestandsdaten aller Artikel schreibt.