Neu Kommissionsware --> via Chargen --> saubere Lagerbewerung aber wie?

[Huhugonzo]

Moin Moin zusammen,

ich stehe vor einer großen unternehmerischen Chance, die aber eine knifflige prozesstechnische Herausforderung in JTL WMS mit sich bringt. Ich hoffe sehr auf die Erfahrungen der Community, um hier den richtigen Weg zu finden.

Meine Ausgangssituation (IST-Status)
Ich betreibe einen Online- Shop für Second-Hand-Ware mit aktuell über 6.000 Artikeln.
Nahezu alle Artikel sind als Varianten angelegt, typischerweise mit den Ausprägungen „Gebraucht neuwertig“ und „Gebraucht minimale Gebrauchsspuren“.
Die gesamte Lagerlogistik, vom Picken bis zum Versand, wird über JTL WMS abgewickelt.

Die Herausforderung:
Ich habe das Angebot erhalten, den gesamten Warenbestand eines Hauptlieferanten, der in den Ruhestand gehen möchte, als Kommissionsware zu übernehmen. Das ist eine riesige Chance, mein Portfolio massiv zu erweitern. Das Problem dabei ist, dass ich für viele dieser Artikel bereits eigenen Lagerbestand besitze. Ich muss also einen Weg finden, meinen Eigenbestand und die neue Kommissionsware für ein und denselben Variantenartikel sauber im System zu verwalten.

Meine Ziele und zwingenden Anforderungen:

1. Saubere finanzielle Trennung: Die monatliche Lagerbewertung darf ausschließlich den Wert meines Eigenbestands ausweisen. Die Kommissionsware (mit einem Wert von 0,00 €) darf diesen Bericht nicht verfälschen, muss aber für die spätere Abrechnung mit dem Lieferanten separat auswertbar sein.
2. Absolute Pick-Priorität für Eigenware: Bei jeder Kundenbestellung muss das System immer und ausnahmslos zuerst auf meinen eigenen Lagerbestand zugreifen. Erst wenn mein Bestand für einen Artikel aufgebraucht ist, darf auf die Kommissionsware zurückgegriffen werden.
3. Effizienter Versandprozess: Für Bestellungen, die Artikel aus beiden Bestandsarten enthalten, muss eine einzige, vollständige Pickliste erzeugt werden. Manuelle Umlagerungen vom Kommissions- ins Hauptlager vor dem Versand sind aus Praktikabilitätsgründen ausgeschlossen.

Was ich bisher versucht und verworfen habe:

1. Ansatz 1: Separates WMS-Lager: Meine erste Überlegung war, ein eigenes WMS-Lager für die Kommissionsware anzulegen. Diesen Gedanken habe ich schnell verworfen, da JTL pro Auftrag nur Picklisten für ein WMS-Lager erzeugt, was bei Misch-Bestellungen zu unlösbaren Problemen im Versand führen würde.
2. Ansatz 2: Chargenverwaltung (Hier liegt mein aktuelles Problem!):

Ich besitze die Lizenz JTL WMS Pro, welche die Chargenverwaltung beinhaltet. Mein Plan war, die Kommissionsware als Charge mit einem EK von 0,00 € einzubuchen.

Mein Test: Ich habe einen Artikel über eine Lieferantenbestellung als Charge angelegt und im Bestellvorgang explizit einen EK von 0,00 € hinterlegt. Der Wareneingang in WMS verlief normal.
Das Problem: Als ich danach die JTL-Lagerbewertung aufrief, wurde der Gesamtbestand des Artikels (also meine alte Charge + die neue Kommissions-Charge) mit dem im Artikelstamm hinterlegten Standard-EK bewertet. Der EK von 0,00 € der neuen Charge wurde für diesen wichtigen Bericht anscheinend ignoriert.

Meine Kernfrage an euch
Wie habt ihr einen solchen Fall sauber gelöst?
Der logische Weg scheint die Kombination aus Chargenverwaltung (für die finanzielle Trennung) und Lagerplatz-Prioritäten (um sicherzustellen, dass immer zuerst die Eigenware gepickt wird) zu sein.

Aber wie stelle ich sicher, dass die Lagerbewertung die unterschiedlichen Einkaufspreise der Chargen (meinen realen EK vs. 0,00 €) korrekt berücksichtigt? Übersehe ich hier eine Einstellung oder einen bestimmten Report, der auf Chargen-Ebene rechnet?

Am Monatsende ist es das Ziel eine Art Export zu ziehen, was an Ware von meinem LIeferanten versandt würde abzüglich Retouren, sodass der LIeferant mir immer eine saubere REchnung über genau die ausgelieferten Waren bereitstellen kann.

Ich freue mich sehr über eure Anregungen, Erfahrungen und Lösungsansätze!


Vielen Dank im Voraus!
Lieben Gruß
Frank

 

[frankell]

Moin Namensvetter,

im durchschnittlichen EK eines Artikels steckt immer seine gesamte Historie. Das ist insbesondere bei Neuware vom Prinzip her auch nicht verkehrt, führt in Deinem Fall aber zu einer Verfälschung, die nur nicht sofort wirksam wird.

Durch das Einbuchen der Kommissionsware hat sich nur der durchschnittliche EK verändert (auf mehr Artikel verteilt), aber die Lagerbewertung insgesamt nicht. Deswegen ist das Problem im ersten Moment auch nicht sichtbar. Es verfälscht aber dauerhaft den durchschnittlichen EK und damit die Lagerbewertung nach unten. Denn in Wahrheit ist der EK ja nicht bei 0 €, sondern nur bei Nicht-Verkauf. Aber im Falle des dauerhaften Nicht-Verkaufs gibst Du die Ware wieder zurück, und dennoch steckt immer noch der 0 €-EK im Durchschnitt. Du hast also sowohl beim Verkauf als auch beim Nicht-Verkauf den durchschnittlichen EK verfälscht.

Ich will nicht so tun, als hätte ich jetzt alles komplett durchdacht, aber mir scheint eh die Herangehensweise mit Varianten für nicht zielführend, auch wenn ich es nachvollziehen kann. Der dafür vorgesehene Weg ist aber eigentlich die Nutzung von Artikelzuständen: https://guide.jtl-software.com/jtl-wawi/artikel/artikelzustaende-anlegen/

Und damit hättest Du es auch leichter, denn Du könntest für die Kommissionsware einen neuen Artikelzustand anlegen und hättest dadurch Deine gewünschten Trennungen. Wenn ich jetzt nicht etwas Grundlegendes übersehe.

VG,
Frank

 

[Huhugonzo]

Moin Namensvetter ,

vielen Dank für deine schnelle und gute Antwort!

Du hast mit deiner Analyse zum durchschnittlichen Einkaufspreis (durchschnittlicher EK) absolut recht. Daran hatte ich bisher überhaupt nicht gedacht

Leider ist dein Lösungsansatz über die Artikelzustände für mich aus zwei wesentlichen Gründen in der Praxis nicht umsetzbar:

1. Feste Struktur mit Varianten: Mein gesamter Shop mit über 6.000 Artikeln und allen angebundenen Prozessen ist fest auf der Nutzung von Varianten aufgebaut. Ein Systemwechsel auf Artikelzustände wäre ein gigantisches Projekt, das ich leider nicht stemmen kann. Ich muss also zwingend eine Lösung innerhalb der bestehenden Varianten-Struktur finden, zumal diverse Kindartikel zudem noch teilweise als Stücklistenartikeln definiert sind.
2. Identische Zustände bei Eigen- und Kommissionsware: Das ist der entscheidende Punkt. Die Kommissionsware wird in exakt denselben Zuständen bei mir ankommen, in denen ich meinen eigenen Bestand bereits führe. Ein Artikel im Zustand „Gebraucht neuwertig“ kann also sowohl aus meinem Eigenbestand stammen als auch Kommissionsware des Lieferanten sein. Würde ich einen neuen Artikelzustand wie „Kommissionsware - neuwertig“ anlegen, müsste ich quasi für jeden Artikel einen zweiten Artikel anlegen, was die Verwaltung und die Darstellung im Shop verkomplizieren und für den Kunden unübersichtlich machen würde. Das Ziel ist ja, einen Artikel im Shop zu haben, dessen Bestand sich aus zwei Quellen speist.

Was ich also benötige, ist eine Möglichkeit zur Trennung (finanziell und für die Pick-Priorität) innerhalb eines bestehenden Variantenartikels.

Deshalb erschien mir der Weg über die Chargenverwaltung eigentlich als der logischste, da er eine physische und datentechnische Trennung pro Lieferung ermöglicht, ohne den Artikel selbst aufzuspalten.

Die zentrale Hürde bleibt also: Wie schaffe ich es, dass die JTL-Lagerbewertung den spezifischen Einkaufspreis einer Charge (meinen realen EK vs. 0,00 €) berücksichtigt und nicht pauschal den Standard-EK aus dem Artikelstamm für den Gesamtbestand heranzieht?

Vielleicht übersehe ich ja eine Einstellung in der Wawi oder es gibt einen speziellen Report, der eine Bewertung auf Chargen-Ebene ausgibt?

Danke nochmals für deine Mühe und deine Gedanken!

Lieben Gruß

Frank



Ich hatte parallel folgende Nachricht vom JTL Support erhalten.

eine Lagerübergreifende Picklistenerstellung ist generell nicht möglich. Eine Alternative zum Umlagern der Artikel wäre eine Teillieferung solcher gemischten Aufträge. Setzen Sie dazu die Lieferoption "Teilliefern" über die Auftragsoptionen (siehe Screenshot). Diese lässt sich auch durch einen Workflow automatisch setzen.

Ich hatte zuerst überlegt, die Kommissionsware in einem eigenen WMS Lager zu buchen, hatte dann aber die Probleme beim Versand im HInterkopf, dass ich keine Pickliste für alle WMS Lager erstellen kann, sondern immer nur jeweils für ein WMS Lager. Das Problem wird jedoch sein, dass ich in Zukunft viele Bestellungen mit Artikeln aus beiden WMS Lagern hätte und ich es als äußerst umständlich halten würde, dass nach Bestelleingang erst eine Art Umlagerung vom Kommisionslager WMS --> Eigene WMS Lager durchgeführt werden müsste, bevor ich dann eine Pickliste, sowie den Versand über das eigentliche "Eigenes WMS Lager über EasyShipping durchführen würde.

Ich hoffe, es ist grob nachvollziehbar, vor welchem Problem ich aktuell stehe. Über jeden Tipp zur Findung einer guten Lösung wäre ich äußerst dankbar!
Lieben Gruß
Frank


Wie Sie Workflows erstellen, erfahren Sie hier:

 

[frankell]

Da beißt sich die Katze aber leider in den Schwanz, befürchte ich. Denn Du möchtest an der bisherigen Vorgehensweise festhalten, die aber dafür verantwortlich ist, dass Deine neue Anforderung nicht klappt. Irgendeine Kröte wirst Du schlucken müssen.

Du könntest nur für die Variationskinder aus dem Kommissionsbestand einen eigenen Zustand etablieren und mal schauen, ob das etwas bringt. Glaube ich aber ehrlich gesagt nicht, da die Zustandsartikel eigentlich alles vom Hauptartikel erben. Ich bin mir nur nicht sicher, ob die Änderungen am Zustandsartikel auch etwas am Hauptartikel ändern. Sollte das nicht der Fall sein, könntest Du über diesen Weg Glück haben. Müsstest Du mal mit Testartikeln durchspielen.

Ansonsten bliebe halt noch die "Manipulation" der Lagerbewertungsausgabe. Die ist ja im Formulareditor anpassbar. Das ändert aber nichts daran, dass Du den EK dauerhaft verfälschst. Um da einen tatsächlich sauberen Wert herauszubekommen, müsste der reale EK per Rückrechnung über SQL errechnet werden. Das geht natürlich, aber ist höhere SQL-Kunst.

 

[Huhugonzo]

Moin Frank ,

vielen Dank für deine ehrliche Einschätzung. Du hast recht, irgendwo beißt sich die Katze in den Schwanz und ich werde wohl eine Kröte schlucken müssen.

Der Umbau der gesamten Artikelstruktur weg von den Varianten ist für mich leider die größte Kröte und praktisch nicht machbar. Ich bin froh, nach langer Zeit eine saubere Darstellung und Logik für meinen Shop (erst Shopware, bald JTL Shop) gefunden zu haben, die für die Kunden verständlich ist. Daran möchte ich festhalten.

Deshalb möchte ich gedanklich einen Schritt zurückgehen und meine ursprüngliche Idee mit zwei getrennten WMS-Lagern noch einmal aufgreifen, aber mit einem modifizierten Prozess, der das Picklisten-Problem lösen könnte.

Mein neuer Lösungsansatz wäre ein zweistufiger Pick-Prozess:

1. Die Vorbereitung: Die "Umlagerungs-Pickliste" Ich stelle mir einen Workflow vor (entweder manuell angestoßen oder automatisiert in einem Intervall), der alle offenen Aufträge prüft.
   • Für jeden Auftrag, der Artikel aus dem Kommissionslager benötigt, erstellt dieser Workflow eine Art Sammel-Umlagerungsliste. Nennen wir sie mal "Umlagerungs-Pickliste".
   • Auf dieser Liste stehen nur die Artikel und Mengen aus dem Kommissionslager, die für die aktuellen Aufträge gebraucht werden.
2. Der erste Schritt: Das "Vorpicken" und die systemseitige Umlagerung
   • Ein Mitarbeiter nimmt sich diese "Umlagerungs-Pickliste" und pickt die entsprechenden Artikel aus dem Kommissionslager.
   • Sobald diese Artikel gepickt sind, werden sie systemseitig vollautomatisch vom Kommissionslager in mein Eigenes WMS Lager umgebucht, zum Beispiel auf einen Puffer-Lagerplatz namens "Kommissions-Übergabe".
3. Der zweite Schritt: Der normale Versandprozess
   • Nachdem die Umlagerung durch ist, befinden sich nun alle für den Versand nötigen Artikel im Eigenen WMS Lager.
   • Jetzt kann ich wie gewohnt meine reguläre Pickliste für die Aufträge aus dem Eigenen WMS Lager erstellen. Diese enthält dann sowohl meine ursprüngliche Eigenware als auch die frisch umgelagerte Kommissionsware vom "Kommissions-Übergabe"-Platz.
   • Der restliche Prozess mit EasyShipping etc. läuft komplett standardmäßig ab.

Meine entscheidende Frage an dich:

Wäre diese Vorgehensweise aus deiner Sicht in JTL vollständig umsetzbar? Insbesondere die Automatisierung der "Umlagerungs-Pickliste" durch einen Workflow, der sich idealerweise bis zur Abarbeitung immer wieder mit neuen Aufträgen selbstständig erweitert?

Der große Vorteil, den ich hier sehe: Die Lagerbewertung für mein Eigenes WMS Lager bliebe absolut sauber, da die Kommissionsware mit ihrem 0-€-Wert nur als separater Posten im Kommissionslager geführt und nie mit meinem bewerteten Bestand vermischt wird. Das Problem mit dem durchschnittlichen EK wäre damit doch vom Tisch, oder sehe ich das richtig?

Ich hoffe, man kann meinen Gedankengang nachvollziehen.

Lieben Gruß,
Frank

 

[frankell]

Ich verstehe den Ansatz dahinter. Dummerweise ändert das aber nichts an den Auswirkungen auf die Lagerbewertung, denn diese beruht weiterhin auf dem durchschnittlichen EK, welcher einheitlich, also gerade nicht gesondert je Lager ermittelt wird.

Davon mal ganz abgesehen gibt es leider keinen Automatismus für eine Umlagerungs-Pickliste. Einzig könnte man in bestimmten Abständen automatisiert bspw. eine E-Mail erzeugen lassen, die alle Artikel ausgibt, die sowohl offen in Aufträgen als auch im Kommissionslager stecken (und bei denen sonst kein Bestand existiert), damit man anhand dessen händisch die Umlagerung anlegen kann. Das ist aber nichts von der Stange, sondern individuell programmiert per SQL.

Ich würde Dir gerne etwas anders sagen können, aber die Katze jagt weiter ihren eigenen Schwanz.

 

[Huhugonzo]

Moin Frank,
DANKE für deine bisherige Geduld und die klaren Worte, auch wenn sie ernüchternd sind

Nur um es wirklich zu verstehen, da hier mein entscheidender Denkfehler zu liegen scheint: Bei der Lagerbewertung wähle ich ja im JTL-Backend vorab das betreffende WMS Lager aus, für das der Bericht erstellt werden soll.


Mein Gedanke war:
Wenn ich die Kommissionsware im Kommissionslager über den Wareneingang mit 0,00 € einbuche, dann müsste bei der Lagerbewertung, die ich ausschließlich für dieses Lager ziehe, doch im Grunde genommen zwar eine lange Liste mit Artikeln und Beständen, aber in der Summe ein Wert von 0,00 € ausgewiesen werden.

Wenn ich dann wiederum die Lagerbewertung für mein Eigenes WMS Lager ziehe, in dem meine eigene Ware mit meinem korrekten EK liegt, sollte der Wert doch genau dem entsprechen, was ich als EK hinterlegt habe.

Sollte ich diesen Punkt dann doch fundamental missverstehen und der durchschnittliche EK wird wirklich immer artikelbasiert über alle Lager hinweg gezogen, hätte ich als letzte manuelle Notlösung doch die Möglichkeit, beim Artikel selbst den durchschnittlichen EK manuell auf den vorherigen Wert wieder abzuändern, nachdem ich die Kommissionsware eingebucht habe, oder?

Ja, ich weiß, das wäre recht umständlich. Aber es wird bei den meisten Artikeln vermutlich nur einmal eine große Lieferung ins Kommissionslager geben und danach nur in sehr seltenen Fällen Nachlieferungen. Die Masse an Arbeit wäre also einmalig pro Artikel.

Zum Punkt der automatischen Umlagerungslisten: Deine Aussage, dass es das von der Stange nicht gibt, überrascht mich nicht. Wir hatten vor ca. zwei Jahren über einen externen JTL-Dienstleister eine halbautomatische Lösung für eine andere Firma umsetzen lassen. Diese hat genau das getan: Auftragsartikel aus Lager A identifiziert und eine Umlagerungsliste für die Verbringung nach Lager B erstellt. Das hatte generell funktioniert, aber mit der Zeit und durch JTL-Aktualisierungen kamen nach und nach Fehler auf.

Ich werde mich mit diesem Unternehmen wieder in Verbindung setzen und anfragen, ob eine solche Lösung mit der aktuellsten JTL-Version für meine UNternehmung robust und vor allem updatesicher umgesetzt werden kann.

Vielen Dank nochmals für deine Mühe!

Lieben Gruß,
Frank

 

[frankell]

der durchschnittliche EK wird wirklich immer artikelbasiert über alle Lager hinweg gezogen

Das ist der Fall. Einen lagerindividuellen, durchschnittlichen EK gibt es nicht.. Zumindest findet sich ein solcher nirgendwo sichtbar in der Wawi und auch nicht in der Datenbank direkt. Klar, die Rohdaten dafür sind theoretisch vorhanden, um es lagerindividuell berechnen zu können. Aber das ist schon sehr komplex, und außerdem müsste man dabei auch noch potentielle Umlagerungen berücksichtigen.

als letzte manuelle Notlösung doch die Möglichkeit, beim Artikel selbst den durchschnittlichen EK manuell auf den vorherigen Wert wieder abzuändern

Das kannst Du in der Tat machen. Ist halt nur fehleranfällig, wenn man es dann doch mal vergisst.

Aber zumindest theoretisch kannst Du einmal vor dem Einbuchen der großen Masse die Durchschnitts-EKs mit der Ameise exportieren und nach dem Einbuchen wieder importieren.

Zum Punkt der automatischen Umlagerungslisten: Deine Aussage, dass es das von der Stange nicht gibt, überrascht mich nicht. Wir hatten vor ca. zwei Jahren über einen externen JTL-Dienstleister eine halbautomatische Lösung für eine andere Firma umsetzen lassen. Diese hat genau das getan: Auftragsartikel aus Lager A identifiziert und eine Umlagerungsliste für die Verbringung nach Lager B erstellt. Das hatte generell funktioniert, aber mit der Zeit und durch JTL-Aktualisierungen kamen nach und nach Fehler auf.

Da die Datenbank frei editiert werden kann, ist es jederzeit möglich, Prozesse zusätzlich anzulegen, die nicht nativ vorhanden sind. Wenn man bspw. die in den SPs der DB zum Ausdruck kommenden Prozesslogiken von JTL versteht, kann man sich da prima einklinken. Man muss halt nur sehr genau wissen, was man tut. Und es muss einem klar sein, dass man von JTL keinen kostenlosen Support bekommt, wenn dann doch nicht alles zu 100 % funktioniert.